Sidecar as the name suggests is a service attached to the main application to enhance its features.
As a general rule the side car doesnt contain any business logic but enhances and supports the main application.
The sidecar and the main application are always deployed as a single unit , in a single pod.
Things to keep in mind while designing a sidecar is :
1. Both the containers should be deployed in a single pod
2. Both the containers should be deployed on a single machine.
3. Sidecar containers share the same resources as the main application.
Use cases (not limited to below):
1. Adding HTTPS support to a legacy HTTP application
This is a classic example of sidecar where there is an existing application, which needs to be migrated from HTTP to HTTPS. But due to any number of reason (starting from legacy code to dependancy on some onscure third party module which doesnt support HTTPS) , this migration is not possible by conventional menas.
So the best way is to create a sidecar which exposes some endpoint (with HTTPS) to the outside world and have the sidecar reroute the HTTPS as an HTTP request to the business application.
The business application wil be hosted as HTTP request, but should be accessible only as a localhost endpoint, internal to the pod.
The most simple way to achieve this adding a nginx server as the sidecar container with necessary certificates and routing configurations.
2. Dynamic configuration with sidecar.
Almost all the applications rely on properties file for configuration details. Traditionally the properties file is deployed/placed along with the application. But with advent of microservices and 12 factor app, it is highly recommended that all the configurations are version controlled and read from the cloud itself.
There is an application conatiner and a config manager sidecar container deployed together as a single unit. Initially the application container starts and reads configuration from local filesystem. All the while, the sidecar config manager reads the properties from cloud and syncs the same with the local filesystem. If any discrepancies are found, the local file system is updated accordingly. Once the updation is done, the sidecar sends a “SIGNAL” to indicate the properties have changed and the application needs to restart or read the updated properties
Best practices for Sidecars
1. Parameterize the containers, so that the same sideacars can be used across applications as plug and play, by simply passing the parameters while starting
2. Use APIs for communication between sidecar and main application. This ensures the complete separation of logic and clear boundaries between the two
3. Document the functionalities of the conatiner (for obvious reasons) stating what the container does