8 Container Design Patterns that you should know

With the increasing adoption of containers and microservices in the enterprises, there is a need now to focus on structuring the containers and other distributed building blocks so that we can solve some of the common design challenges.In this post, we take look at some of the key design patterns that could be used in Docker, Kubernetes, and other container platforms.The foundation work was actually done by Brendan Burns and David Oppenheimer in their container design patterns paper, this post summarizes the key design patterns.

#1.Side Car Pattern

In this pattern, the sidecar is attached to a parent application and provides supporting features for the application. The sidecar also shares the same life cycle as the parent application, is created, and retired alongside the parent.

Use Case: Can be used for Runtime debugging, observability, reliability, logging, and security

#2.Ambassador pattern

Ambassador containers proxy communication to and from a main container. For example, an application that is speaking the Memcache protocol with a twemproxy ambassador. The application believes that it is simply talking to a single Memcache on the localhost, but actually twemproxy is sharding the requests across a distributed installation of multiple Memcache nodes elsewhere in the cluster.

Use Case: Situations where you have to offload / Proxy requests to other containers 

#3.Adapter Pattern

In contrast to the ambassador pattern, which presents an application with a simplified view of the outside world, adapters present the outside world with a simplified, homogenized view of an application. They do this by standardizing output and interfaces across multiple containers.

Use Case: Cases where you have to standardize output and interfaces across multiple containers

#4.Work Queue Pattern

This pattern allows to handling of arbitrary processing code packaged as a container, and arbitrary data, and build a complete work queue system.

Use Case: Situations that warrant work queue based system

#5.Self Awareness Pattern

This pattern describes situations where an application needs to introspect and get metadata about itself and the environment where it is running.

Use case: Cases where you need to retrieve application metadata/environment variables

#6. Scatter/gather Pattern

Initial request would be sent to the main container, this container then fans the request out to a large number of servers to perform computations in parallel. Each container returns partial data, and the main container gathers this data into a single response to the original request.

Use case: Fan out the request out to a large number of servers to perform computations in parallel, Common in search engines.

#7.Custom Controller Pattern

Controller watches for changes to objects and act on those changes to drive the cluster to a desired state. You can also implement custom logic and extend the functionality of the platform.

Use Case: Situations where you have to watch for changes to objects and act on it

#8.Initializer Pattern

Init containers allow separation of initialization related tasks from the main application logic.

Use Case: Span out initialization tasks to separate containers

By now you would have got a good idea on the basics of container design patterns. If I have missed out on any of the patterns or if you have come across anything, let me know in the comments section.

References :

Design patterns for container-based distributed systems by Brendan Burns, David Oppenheimer

Like this post? Don’t forget to share it!

Additional Resources :

• Take a free course on Building Scalable Java Microservices with Spring Boot and Spring Cloud
• Kubernetes tutorial – Create simple cluster & Deploy app
• Kubernetes tutorial – Scale & perform updates to your app
• Kubernetes tutorial – Create deployments using YAML file