Ambassador Pattern
can be reused, separate the logic from the application
single-node pattern
shard service
nginx
can be reused, separate the logic from the application
single-node pattern
shard service
nginx
This is the content from chapter 2 in Designing Distributed Systems.
Usually, we deploy a new container along with the application container, instead of deploying the application container alone, for realizing some functions(proxy, monitor, etc.). We call this the sidecar pattern. It belongs to the single-node pattern.
We can realize such functions with the sidecar pattern: proxy, monitoring, and synchronization as PaaS.
For example, we have a legacy backend application only support HTTP. Now if we want to use HTTPS, we can use the sidecar SSL proxy container to handle HTTPS requests and forward them to the old legacy service.
Check figures above, with the sidecar application, developers can easily update the configure file or repository codes.
We can deploy a sidecar container with the same IPC namespace as the original application container. We then collect the resource usage from the sidecar container and expose a port from the sidecar container for metrics collection.
We follow these three rules to build our sidecars: