Docker brief intro

• Lots of small changes
• Heterogeneous platforms and languages
• Environments (Development, Production)
• Zero downtime
• Rollback
• Monitoring
• Infrastructure as Code
• Continuous Delivery
• Infrastructure and Application Metrics

One of the biggest use cases and strongest drivers behind the uptake of containers are microservices.

Microservices are a way of developing and composing software systems such that they are built out of small, independent components that interact with one another over the network. This is in contrast to the traditional monolithic way of developing software, where there is a single large program, typically written in C++ or Java. When it comes to scaling a monolith, commonly the only choice is to scale up, where extra demand is handled by using a larger machine with more RAM and CPU power. Conversely, microservices are designed to scale out, where extra demand is handled by provisioning multiple machines the load can be spread over. In a microservice architecture, it’s possible to only scale the resources required for a particular service, focusing on the bottlenecks in the system. In a monolith, it’s scale everything or nothing, resulting in wasted resources.

In terms of complexity, microservices are a double-edged sword. Each individual microservice should be easy to understand and modify. However, in a system composed of dozens or hundreds of such services, the overall complexity increases due to the interaction between individual components. The lightweight nature and speed of containers mean they are particularly well suited for running a microservice architecture. Compared to VMs, containers are vastly smaller and quicker to deploy, allowing microservice architectures to use the minimum of resources and react quickly to changes in demand.

• Use declarative formats for setup automation, to minimize time and cost for new developers joining the project
• Have a clean contract with the underlying operating system, offering maximum portability between execution environments
• Are suitable for development on modern cloud platforms, obviating the need for servers and system administration
• Minimize divergence between development and production, enabling continuous deployment for maximum agility
• And can scale up without significant changes to tooling, architecture, or development practices

One codebase tracked in revision control, many deploys

Explicitly declare and isolate dependencies

Store config in the environment

Strictly separate build and run stages

Execute the app as one or more stateless processes

Export services via port binding

Scale out via the process model

Maximize robustness with fast start-up and graceful shutdown

Keep development, staging and production as similar as possible

Treat logs as event streams

Run admin/management tasks as one-off processes