In this article, we have explored Sidecar Design Pattern in System Design along with its advantages and disadvantages and a real System Design example using Sidecar Design Pattern.
Table of Content:
- Issues in traditional design patterns
- What is a SideCar design pattern?
- Shared Volume
- Shared Network
- Advantages of SideCar Design
- Disadvantages of SideCar Design
- System Design Example
Containers are rising in popularity as it helps package an application and developers can move and deploy the application anywhere with very less hassle. Containers help reduce labors , increase flexibility, provides agility and in general makes the management of applications so much easier.
However how do we know if we are using containers effectively or not , that is where design patterns come into play. Design patterns exist to help common problems with containers as it provides a planned architecture of the applications so that everyone can understand what is going on.
In this article we are going to look upon the sidecar design pattern in containers.
Issues in traditional design patterns
Multiple applications oftern require some common functionalities like monitoring , logging , configuration etc. If they are tightly coupled within the main application there is no isolation between the services and a downtime of the application results in a downtime for all the services.
This leads to a close interdependence within the application.
Moreover lets say two applications A and B having a monitoring service within each of the application interlocked with the amin application , to upgrade the monitoring service each monitoring service of each application has to be upgraded and in case of downtime the entire services of the application is down.
Considering the above image Application A and B have the same services integrated within them which are tightly coupled (dotted line represents features). To upgrade our monitoring service we have to upgrade Monitoring A and Monitoring B individually (they are the same type of service) , if one of the application A or B fails the rest of the services associated with them also fails. This system is prone to failure and not flexible.
What is a SideCar design pattern?
Seperating the functionalities of an application into different processes can be viewed as the sidecar pattern. The sidecar pattern allows developers to add multiple capabilties to the application without any additional configuration or third party components in the main application.
The simplest example of a sidecar pattern is a single node two containers architecture.
The first container is the application container which contains the main application or the core logic of the application. The application would not run without this container.The second container is the sidecar container which adds functionality to the application container. The sidecar container shares a number of resources with the application container like volumes , network etc.
The sidecar container can provide functionality like adding HTTPS to a legacy application , perform monitoring or logging etc.
The communication between the containers happend by sharing a common resource the most popular being shared volume or network.
When the main application container and sidecar container use a common volume or disk it called a shared volume. A good example of this is using fluentd to read logs from a main application container in which fluentd reads the logs and produces them in a cleaner format.
In this example the file-app container which is the main application writes its logs and fluentd parses the logs and outputs them in a better pattern. Both the containers shares the file directory in the host.
When the main application container and sidecar container share the same network to perform communication it is an example of shared network. A good example of this would be using a webserver like flask with a message queue like rabbitmq.
Here the flask server runs in port 5000 and a rabbitmq container runs alongside it in the same network (containers in a docker compose share the same network by default).
Advantages of SideCar Design
- A sidecar container is independent of the main application container , it does not depend on the framework or language used by the main container hence there is no need to create a different sidecar contianer for every language.
- The sidecar is able to access the same resources as the primary application
- It provides loose coupling between the application code and the platform.
- Code duplication is reduced in a microservice architecture since there is no need to write configuration code inside each container.
- Sidecar container still runs even though main application may have a downtime.
Disadvantages of SideCar Design
- There are lots of communication between the containers which can be difficult to debug or detect issues in between inter process communication.
- This pattern can only be used for container based environment.
- Due to the large number of containers as sidecar containers the memory requirement is very high.
System Design Example
Let us look at a simple implementation of this design
This is a data processing application , the main application is in the center which is connected to a database . There are two sidecar containers , the log collector shares a common volume with the main application . The main application writes its logs to the common volume and the sidecar container reads the logs and displays them in a GUI based format.
Since the application has to do a lot of data processing and modelling which is a very heavy task it has a data processor sidecar container attached to it which processes and cleans the data and models it and returns the result to the main application.
With this article at OpenGenus, you must have the complete idea of SideCar Design Pattern and how to use it in a real System Design problem.