Container design patterns are emerging as microservices and containerization become more popular. Single-container patterns like container boundary and interface define how containers are packaged and interact. Single-node patterns like Kubernetes pods and sidecars schedule related containers together on one machine. Multi-node patterns coordinate distributed containers, such as using leader election sidecars to select a replication leader, work queues to distribute tasks, and scatter/gather to parallelize computations across nodes. These patterns abstract away infrastructure details and provide reusable solutions for containerized applications.

1. Become a cloud-native developer
tuna@apache.org
http://meetup.com/docker-hanoi

2. Tu Nguyen
Master student @ University of Basel,
Switzerland
Docker Hanoi organizer
Apache Software Foundation committer
Kubernetes committer
Solution Architect @ FPT-Software
Interests:
Open-source cloud computing lover

4. Design Patterns
1980s-1990s: Object-oriented programming revolutionized software
development.
Why design patterns ?
Encode best practices.
Simplify development.
Make the application more reliable.
Make it easier for less experienced programmers to produce well-engineered code.

5. Which design patterns are suitable for today ?
Trend
Popularity of microservice architectures.
Popularity of {public} clouds.
Built from containerized software components.
Distributed applications running on distributed systems.
Emergence
A new design pattern which abstracts away the low-level details of code for developing
containerized applications.
Container Design Patterns

6. Three types of container design patterns
Single-container patterns.
for container management.
Single-node patterns.
For cooperating containers.
Multi-node patterns.
For distributed algorithm.

7. Single-container patterns
Container boundary

8. Container interface
Container provides a natural boundary for defining an interface.
Much like object boundary.
Traditional container interface is extremely limited.
run()
pause()
stop()

9. Container interface
The interface is generally becoming richer.
Expose information
Application-specific monitoring metrics
Logs, events
Healthcheck
Configuration
Standard lifecycle
Create, start, stop, kill, delete
Graceful termination https://github.com/opencontainers/runtime-spec

10. Single-node patterns
Consist of symbiotic containers that are co-scheduled as an atomic unit onto a single machine

11. Kubernetes Pod
What is K8S pod ?
A pod is a group of one or more containers which are relatively tightly coupled, co-located, co-
scheduled, and run in a shared contexts.
Shared contexts ?
Share IP address
Share port space
Find each other via localhost
Have access to shared volumes
http://kubernetes.io/docs/user-guide/pods/

12. 1. Sidecar
2. Ambassador
3. Adapter

13. Sidecar
Sidecars extend and enhance the main container.

14. Sidecar
Benefits
Container is the unit of resource accounting and allocation:
Main container can be configured to provide low-latency responses to queries.
Sidecar container is configured to trigger when the server is not busy.
Container is the unit of packaging:
Separating containers make it easy to divide responsibility for different development teams.
Container is the unit of reuse:
Sidecar can be paired with numerous different main containers.
Container provides failure boundary:

15. Ambassador
Ambassador proxy communication to and from a main container.
It presents an application with a simplified view of the outside world.

16. Ambassador
Benefits
Developers only have to think and program in term of their application connection to a localhost
single server.
Developers can test their application standalone by running a real instance on their local
machine.
Developers can reuse the ambassador with other applications that might even be coded in
different programming languages.

17. Adapter
In contrast to Ambassador.
Adapters present the outside world with a simplified, homogenized view of an application.
Standardizing output and interfaces.
Ensure all containers in the system have the same adapters interface. (ex: monitoring interface)

18. Multi-node patterns
Modular containers make it easier to build coordinated multi-node distributed applications.

19. 1. Leader election
2. Work queue
3. Scatter/gather

20. Leader election
One of the most common problems in distributed systems.
Replication
Commonly used to share load among multiple instances of a component.
Replication in distributed application
Need to distinguish one replica from a set as the “leader”.
The other replicas are available to quickly take the place of leader if it fails.

21. Leader election
Typical leader election
A set of candidates is identified.
These candidates all race to declare themselves the leader.
One of the candidates win and becomes the leader.
The leader continually “heartbeats” to renew their position.
Other candidates periodically make new attempts to become the leader.
Raft consensus algorithm
https://raft.github.io/

22. Leader election
How to apply `leader election` to my app?
Import leader election libraries
https://raft.github.io/
They are generally complicated to understand and use correctly.
They are limited in particular programming languages.
Will container design pattern provide a better solution ???

23. Leader election with sidecar pattern
A set of leader-election containers, each one co-scheduled with an instance of
the application that requires leader election

24. Leader election sidecar
Container image
gcr.io/google_containers/leader-elector:0.4
Opening a HTTP endpoint at port 4040
curl http://localhost:4040
{"name":"(name-of-pod-leader-here)"}
Benefits
Can be built once and reused by application
developers
Regardless of programming languages.

25. Work queue
Container interfaces run() and mount() make it fairly straightforward to
implement a generic work queue framework.
Developers only have to build a container that can take input data on the
filesystem, process and give output.
Queue

26. Scatter/Gather
Commonly used in parallel computing
The root “node” fans the request out to a number of “leaf” nodes to perform computations in
parallel
Each “leaf” returns partial data, and the “root” gathers data into a single response.

27. Scatter/Gather containers

28. Questions ?