DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • What Is API-First?
  • Create a Multi-Tenancy Application in Nest.js, Part 4: Authentication and Authorization Setup
  • Are You Tracking Kubernetes Applications Effectively?
  • While Performing Dependency Selection, I Avoid the Loss Of Sleep From Node.js Libraries' Dangers

Trending

  • Failure Handling Mechanisms in Microservices and Their Importance
  • My LLM Journey as a Software Engineer Exploring a New Domain
  • Solid Testing Strategies for Salesforce Releases
  • Scaling InfluxDB for High-Volume Reporting With Continuous Queries (CQs)
  1. DZone
  2. Data Engineering
  3. Data
  4. Microservices Patterns: Sidecar

Microservices Patterns: Sidecar

Learn about Microservice architecture and single responsibility principle, know more on how to achieve it using sidecars.

By 
Sameer Shukla user avatar
Sameer Shukla
DZone Core CORE ·
Oct. 04, 21 · Analysis
Likes (19)
Comment
Save
Tweet
Share
16.1K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Microservices sidecar

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. 

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

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.

microservice Library

Opinions expressed by DZone contributors are their own.

Related

  • What Is API-First?
  • Create a Multi-Tenancy Application in Nest.js, Part 4: Authentication and Authorization Setup
  • Are You Tracking Kubernetes Applications Effectively?
  • While Performing Dependency Selection, I Avoid the Loss Of Sleep From Node.js Libraries' Dangers

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!