Become a cloud-native developer

tuna@apache.org

http://meetup.com/docker-hanoi

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

Docker, Microservices, DevOps

Kubernetes crazy fan

Golang, OCaml, Chapel

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.

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

Container and container image

The abstractions needed for the development of distributed applications.

Container ⟺ Object.

Three types of container design patterns

Single-container patterns.

for container management.

Single-node patterns.

For cooperating containers.

Multi-node patterns.

For distributed algorithm.

Single-container patterns

Container boundary

Container interface

Container provides a natural boundary for defining an interface.

Much like object boundary.

Traditional container interface is extremely limited.

run()

pause()

stop()

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

SIGTERM, SIGKILL

Provide priority

High-priority containers guaranteed to run even when the cluster is oversubscribed.

Low-priority containers have to wait until resources become available.

Replicate yourself - scale up

Etc.

https://github.com/opencontainers/runtime-spec

Single-node patterns

Consist of symbiotic containers that are co-scheduled as an atomic unit onto a single machine

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/

1. Sidecar

2. Ambassador

3. Adapter

Sidecar

Sidecars extend and enhance the main container.

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:

Main container can continue serving even if the sidecar has failed.

Container is the unit of deployment:

Allows each piece of functionality to be upgraded and rollbacked independently.

Note: version compatibility.

Ambassador

Ambassador proxy communication to and from a main container.

It presents an application with a simplified view of the outside world.

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.

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)

Multi-node patterns

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

1. Leader election

2. Work queue

3. Scatter/gather

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.

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/

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 ???

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

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.

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

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.

Scatter/Gather containers

Questions ?