Library vs Service vs Sidecar
All software applications are composed of re-usable elements. The objective and functionality of these reusable elements vary from infra level concern to security level concern to business capabilities.
The purpose of this article to compare different approaches that are used for building and deploying these reusable elements.
1. Library
This is the most widely used approach for reusing the code. The reusable code is developed and released as library. In this approach, client application defines library as direct dependency, uses the provided APIs and ship its code along with main application logic. The code for library and main application logic is executed as part of same process/container.
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
The next most widely used pattern is to define services for re-usable functionalities. In this approach, application makes network calls to invoke another service using request-response mechanism. The code for service and main application logic is executed in different pods/server instances.
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
The sidecar pattern is a single-node pattern made up of two containers. The code for side car and main application logic is executed as part of different process/container but is deployed in same pod/server instance together.
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
The above mentioned approaches — Library, Service and Sidecar can all be used together for an application for achieving the desired results. A application can use library for making database calls, use sidecar for distributed logging, and service for providing authentication functionality. The development team needs to weigh in the pros and cons and then chose the right solution.
References
https://www.atlassian.com/engineering/atlassian-critical-services-above-six-nines-of-availability
