Sidecar pattern use cases
Essence of pattern is that you have main container and sidecar container. They run on the same Pod, so they share networking and storage resources. Let’s discuss in what cases it can be useful.
Proxy server
Sidecar pattern behave like proxy for main container. It does not perform any business logic. For example, you can add HTTPS to your old service without changing service itself.
Dynamic configuration
Sidecar container acts like API for changing configuration. Service, in turn, should have some mechanism to fetch changes.
Reusable functionality
Sometimes it is useful to extract some common (more likely technical) service logic into separate container. You can implement, for example, resource monitoring service once and use it for all services, regardless technologies they based on.
Extending service API
You can implement new API in separate service and deploy it as sidecar. It is useful if:
- you have not access to application sources
- application based on legacy technologies
- application sources are too legacy to try change it
Summary
Basically, Sidecar pattern is useful when you can’t modify container, but want to implement some new functionality or want to implement some reusable technology-agnostic functionality.
Top comments (0)