Use of Sidecars to Microservice Communication

 Recently I attended Analysis Design Architcture conference (https://adaconf.org/) where listened to talk named "Future Proof Software Architecture: Microservices". That reminded me my experience of using sidecars as part of a microservice architecture in one of my previous projects( Australian Bank). So I decided to write down some of the key points and insights that came out of that experience. 

firstly, let's start with understanding why we might want to move beyond traditional API gateways. API gateways traditionally handle everything from TLS termination to authentication, authorisation, and traffic routing. They're like the swiss army knife of API management - doing lots of things in one place. But here's the problem - as our microservices architectures grow more complex, having all these responsibilities in a central gateway becomes a bottleneck.

So let's see what are sidecars - think of them as your microservice's personal assistant. Instead of routing all traffic through a central gateway, each service gets its own lightweight proxy that handles network communication, security, and observability. The beauty of this approach? Each service becomes more self-contained and secure.

Here's what makes sidecars particularly powerful:

• They handle network concerns right next to your service
• Security becomes distributed rather than centralised
• Independent upgrades and configurations become possible
• Integration with service meshes like Istio becomes seamless

If you're working with Kubernetes (and who isn't these days?), implementing sidecars becomes even more straightforward. Service meshes like Istio automatically inject these sidecars into your pods, handling everything from configuration APIs to storage. Pretty simple, ah?

One of the most exciting aspects is how sidecars work with client stubs generated from OpenAPI documents. Rather than enforcing request schemas through API gateways, developers can focus on writing business logic while the stubs handle all the tedious stuff - body serialisation, validation, and other concerns. It's a game-changer for developer productivity.

The cost benefit analysis is crucial here. Yes, implementing service meshes and sidecars adds some overhead, but the benefits in terms of network resiliency and traffic management are substantial. For most use cases, especially in enterprise environments where security and reliability are paramount, the investment pays off.

Let me share a practical tip we learned working on that project, when implementing sidecars, consider using battle-tested HTTP proxies (eg: nginx or Envoy). These tools have proven themselves in production environments and offer the reliability you need for critical systems.

The shift from centralised API gateways to distributed sidecars represents a natural evolution in microservices architecture. For many organisations, especially those dealing with complex security requirements or needing fine-grained control over service-to-service communication, sidecars provide a more flexible and maintainable solution.

Remember, though, that technology choices should always align with your specific requirements and SLAs. While sidecars offer compelling benefits, they're not a silver bullet. Evaluate your needs, consider your team's capabilities, and make the decision that best serves your use case.