Library vs Service vs Sidecar

1. Library

Pros

  • Latency : The code in library is executed in the same process as that of main application so there is no network latency.
  • Availability : The overall availability is high as there is no network partition (CAP theorem).
  • Ease of use : Very simple to use.
  • Environment context: Environment context (Memory, CPU etc.) is accessible to library as they are part of same container.

Cons

  • Resources: Resources such as memory, CPU etc. are shared with main application. This means that performance of library can have side effect on main application.
  • Technologies : Library used in library is same as that of main application and due to this if an organization has diverse set of applications then multiple implementations will be required for each language.
  • Maintainability : Any bug fixes in library requires code changes and testing across all the client applications.

Service

Pros

  • Resources: The application and services are deployed separately so resources are not shared. The resources can be optimized for both application and service independently.
  • Maintainability : The service can be released independently when it comes to bug fixes. No version upgrades are required.
  • Technologies : The service can be developed using any technology of choice that fits its purpose.

Cons

  • Ease of use : Services have relatively less ease of use in comparison to library.
  • Latency: The latency is significantly higher as application and service are distributed and network call is required for invocation.
  • Environment context: Environment context (Memory, CPU etc.) of main application is NOT accessible to service as both runs independently in separate instances.
  • Availability : The overall availability will be lower as compare to Library due to network partition.

Side Car

Pros & Cons

  • Maintainability : The Sidecar can be released independently when it comes to bug fixes.
  • Technologies : The Sidecar can be developed using any technology of choice that fits its purpose.
  • Latency: The latency is lower as comparison to services but is higher than libraries. The anti-pattern for this approach is to make all re-usable component sidecars as this will lead to significant impact performance impact.
  • Resources: The application and Sidecar are deployed to-gather so resources are shared but resource limit can be set separately for side car for preventing the over-use by side car. The anti-pattern for this approach is make all re-usable component sidecars as it will lead to huge overhead for resource configuration management.
  • Ease of use : Sidecar have relatively less ease of use in comparison to library and can be simpler to use as compare to service if CI/CD pipeline support this out of the box.
  • Environment context: Environment context (Memory, CPU etc.) is accessible to sidecar as as it’s part of same pod/server instance. This allows side car to do application performance monitor etc.
  • Availability : The availability will be higher in comparison to services as there is no real network partition. In general, the availability would mainly depend on communication protocol between main application and side car. E.g. if protocol is fire and forget then failure in sidecar won’t have cascading side effect on main application.

Summary

References

Software Architect

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Preparing your site for Drupal 9

Creating an Auto Scaling Group in EC2

What The Docker

The Cost of a Byte

Make your microservices independent

Top 6 cloud-native application development trends to transform your business

CS371p Spring 2022 Blog #3: Lilia Li

Send Terraform Drift Status To Slack Channel

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Atul Agrawal

Atul Agrawal

Software Architect

More from Medium

5 Design Patterns for Building Observable Services

Four ideas to level up your service architecture

Let’s Talk about Microservices “Owning” their Data

Testing your Software Architecture