Microservices Patterns: Sidecar

A properly designed Microservice should follow the Single Responsibility Principle, hence it’s important to segregate the common functionality which should be reused by other services in the architecture. The Sidecar Pattern advocates increasing modularity by identifying common functionalities in each service and either club them in a library or move them to a separate service.

As the name suggests Sidecar, which Is a one-wheeled device attached to the side of the motorcycle, scooter, etc., similarly Sidecar Pattern advocates the separation of cross-cutting concerns and remove them from the actual service and push them to a separate module, library, or service and these functionalities then will be reused by other services in the architecture.

The Article discusses what kind of functionalities can be the candidate or can be treated as a Sidecar in the Microservice architecture, along with approaches of the implementation and Pros and Cons of Sidecar.

Sidecar Candidates

The Aspect-Oriented Programming brought this interesting concept of separating the cross-cutting concerns, in a nutshell, remove the common functionalities from the code and focus only on the business logic, what is the point of repeating the same code in every method/function within the service. 

The Sidecar pattern is similar in nature the only difference is, Sidecar pattern talks in terms of Microservices. It becomes more important to abstract out the common piece of code because of obvious reasons of enhancing the code at the commonplace will reflect the change in every service, along with that in Microservice’s we must deal with a bigger problem of log aggregation, monitoring, debugging to name the few. 

Some of the most important candidates are 

• Log Aggregation
• Security
• Error Handling and taking necessary actions afterward of either publishing an error log or pushing an Error Event to a Kafka Topic or a Queue for Monitoring. 
• The common functionalities in a project are something like the Entity (Database Models)  or a business-specific logic which is used by other services as well.
• Configuration changes of Services or Database configuration, Kafka Configuration, Queue Configuration required by other services as well to Function. 
• Caching requirements if any. 

All these common functionalities/Sidecars can be attached to service just like a Sidecar attached to the motorcycle.

Advantages and Disadvantages

Advantages

The biggest advantage of implementing this pattern is that all the common functionalities are available to all the services in the architecture, it significantly reduces the complexity in the architecture by abstracting the common functionalities in a different layer. 

Microservice is polyglottic in nature, these common functionalities can be developed using the technologies or Programming languages best suited for that specific operation.  

Pattern implicitly avoids code duplication since we don’t need to write this repetitive code in every service. 

Loose Coupling between services and the Sidecar candidates. 

Disadvantages

Separate maintainability of the Sidecars it can either Library or a Separate Service. 

If we have a huge number of Sidecars in the application, then it can impact the performance of the service. Need to identify whether the Sidecar functionality needs to be scale independently from the main service, if yes one needs to host these Sidecars as a separate service. 

Implementation Approaches

Keeping Sidecars in a Separate Library

The most common approach is to keep the Sidecars in a separate library and importing these libraries individually in a Microservices, for example keeping Database models in a separate library and then importing these models via the library to all the microservices, there are various build tools like Maven, Gradle, SBT, etc. can be used for configuration. 

There are a couple of downsides to this approach. 

Sidecar Overload

Imagine maintaining multiple Sidecars in a project like logging, caching, configuration, security all present in architecture can create a problem of Sidecar overload in all the Microservices. 

Version Inconsistency

Maintaining the correct version of each library would be a nightmare for the developers, imagine the cache-lib Sidecar has the latest version of 1.1 which is being used by Service A but we forgot to mention the correct version in Service B which is still using the cache-lib version 1.0 can create significant inconsistencies within the application and these inconsistencies are difficult to debug and identify. 

One solution to this problem is to create one Uber library that contains all these Sidecar libraries then all we need to do is to maintain the correct version of the Uber library across the Microservices, we need to ensure that Uber library is updated with the latest versions of Sidecars, for example, the cache-lib 1.1 should be available in the Uber Library. 

Keeping Sidecars as a Separate Service

Another approach is to maintain the Sidecars in a separate Service each. But it can create serious performance issues to invoke service calls for every operation, but ideally, we don’t generally create a service for logging or for the common functionalities. Security, Caching can be the ideal separate Service Candidate. 

The biggest downside of this approach is optimizing the inter-service communication always for better performance always. In that case, it becomes like another Microservice in the Architecture which always requires Scaling, monitoring which kind of defeat the purpose of Sidecar.

Conclusion

The sidecar pattern is a very useful and neat pattern that keeps the Cross-Cutting concern away from the actual Service Implementations, a properly designed Microservice should always follow the Single Responsibility Principle and the Sidecar pattern compliments the SRP principle by keeping away the repetitive functionalities. Every design principle has advantages and disadvantages, the hybrid approach of maintaining the Sidecar in a library as well as keeping the most important functionalities should be maintained in a separate Service.