Adding 4 'sidecar' containers to an ASP.NET Core minimal API to maximize self-containment
While working on my API: erwinkramer/bank-api, I saw an opportunity to self-contain functionality, in order to be more portable and standardized, resulting in an API that is able to effectively run in a lot more environments without being dependent on the platform functionality, whether that be on bare metal, a Kubernetes platform in AWS, or something like Azure Container Apps in Azure.
This resulted in 4 sidecar containers;
(1) OpenTelemetry Collector sidecar for telemetry (obviously), logging and tracing. No direct integration with Azure Log Analytics in code needed anymore, this functionality is still in preview in Azure, but this makes it able to simply change configs when you're moving clouds.
(2) Dapr sidecar for abstracting the way secrets are fetched from a secret store.
(3) S3Proxy sidecar for abstracting the way blob storage is accessed.
(4) Envoy based sidecar for facading the API, where I added a Coraza OWASP WAF implemented as Envoy Go Filter.
The first 3 help in making your core API stay the same code-wise. So, no matter where you run it (Azure, AWS, OVH) the ASP.NET code for logging, accessing secrets from any secret store (Key Vault, Kubernetes secrets, HashiCorp Vault) or accessing blobs from any store (Azure Storage, filesystem, GCS) stays the same. The last one (envoy), makes it able to streamline all inbound handling of any deployed app or api in an organization, regardless of where it's hosted.
The API and its code are fully available in the repo mentioned, including a live demo deployment to experience the complete setup.
For people experienced in Kubernetes, you might be questioning: why not use Envoy Gateway, the Dapr Operator or a Gateway deployment pattern for OpenTelemetry? But the point is, they are highly dependent on the Kubernetes platform configuration, which you might have much less influence on, especially in highly managed environments. Regardless, the setup doesn't force you into having to use the sidecars as-is, but by having a sidecar-first approach, it allows you to mix-and-match easily between centralized and self-contained components.