{"id":3139,"date":"2018-12-03T07:00:21","date_gmt":"2018-12-03T01:30:21","guid":{"rendered":"http:\/\/www.upnxtblog.com\/?p=3139"},"modified":"2020-05-11T20:51:23","modified_gmt":"2020-05-11T15:21:23","slug":"8-container-design-patterns-that-you-should-know","status":"publish","type":"post","link":"https:\/\/www.upnxtblog.com\/index.php\/2018\/12\/03\/8-container-design-patterns-that-you-should-know\/","title":{"rendered":"8 Container Design Patterns that you should know"},"content":{"rendered":"
<\/div>

With the increasing adoption<\/a> 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<\/a>, Kubernetes<\/a>, and other container platforms.The foundation work was actually done by\u00a0Brendan Burns<\/strong>\u00a0and David Oppenheimer<\/strong> in their container design patterns\u00a0paper<\/a>, this post summarizes the key design patterns.<\/p>\n\n

#1.Side Car Pattern<\/h2>\n

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.<\/p>\n

Use Case: Can be used for Runtime debugging, observability, reliability, logging, and security<\/em><\/p>\n

\"Side
Image – Side Car Pattern<\/figcaption><\/figure>\n

#2.Ambassador pattern<\/h2>\n

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.<\/p>\n

Use Case: Situations where you have to offload \/ Proxy requests to other containers\u00a0<\/em><\/p>\n

\"Ambassador
Image – Ambassador pattern<\/figcaption><\/figure>\n

#3.Adapter Pattern<\/h2>\n

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.<\/p>\n

Use Case: Cases where you have to standardize output and interfaces across multiple containers<\/em><\/p>\n

\"Adapter
Image – Adapter Pattern<\/figcaption><\/figure>\n

#4.Work Queue Pattern<\/h2>\n

This pattern allows to handling of arbitrary processing code packaged as a container, and arbitrary data, and build a complete work queue system.<\/p>\n

Use Case: Situations that warrant work queue based system<\/em><\/p>\n

\"Work
Image – Work queue pattern<\/figcaption><\/figure>\n

#5.Self Awareness Pattern<\/h2>\n

This pattern describes situations where an application needs to introspect and get metadata about itself and the environment where it is running.<\/p>\n

Use case: Cases where you need to retrieve application metadata\/environment variables<\/em><\/p>\n

\"Self
Image – Self Awareness Pattern<\/figcaption><\/figure>\n

#6. Scatter\/gather Pattern<\/h2>\n

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.<\/p>\n

Use case: Fan out the request out to a large number of servers to perform computations in parallel, Common in search engines.<\/em><\/p>\n

\"Scatter\/gather
Image – Scatter\/gather pattern<\/figcaption><\/figure>\n

#7.Custom Controller Pattern<\/h2>\n

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.<\/p>\n

Use Case: Situations where you have to watch for changes to objects and act on it<\/em><\/p>\n

#8.Initializer Pattern<\/h2>\n

Init containers allow separation of initialization related tasks from the main application logic.<\/p>\n

Use Case: Span out initialization tasks to separate containers<\/em><\/p>\n

\"Initializer
Image – Initializer Pattern<\/figcaption><\/figure>\n

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.<\/em><\/p>\n

References :<\/h2>\n

Design patterns for container-based distributed systems<\/a> by\u00a0Brendan Burns, David Oppenheimer<\/p>\n

Like this post? Don\u2019t forget to share it!<\/strong><\/em><\/p>\n

Additional Resources :<\/h2>\n