Major considerations before containerizing a service
Do not overload the containers with multiple services
If required, use the "Sidecar Pattern".
Take help of dependency injection using external configuration and evaluating it on runtime.
Design the containers for failure and short-life.
So, here in this post, we are going to talk about the Sidecar pattern we follow to break down an application into separate containers on services level.
Basically, the application will have following two things on broader level -
a) Parent service - Core functionality
b) Auxiliary services - Telemetry, Logging, Proxy etc.
Problems in different approaches
Problems if they are kept together -
Single point of failure
Problems if they are separated -
Increased complexity (but of course flexibility)
According to the documentation provided by Microsoft, it states that
Co-locate a cohesive set of tasks with the primary application, but place them inside their own process or container, providing a homogeneous interface for platform services across languages.
What is basically means is -
Keep the processes separate, into different containers. But due to the proximity and involvement of share resources - latency issue can be resolved.
Flexibility is also there due to minimal interdependency.
Disclaimer - All the posts on this blog are written to cater the need of quick read. If more insights are required, please refer the official document. Happy learning!