Docker brief intro
Table of Contents
- Provides an additional layer of abstraction
- Isolates an application's view
- The Twelve-Factor App
- The Ultimate Goal
Provides an additional layer of abstraction
and automation of operating-system-level virtualization on Windows and Linux.
Figure 1: Docker Logo
Isolates an application's view
of the operating environment, including process trees, network, user IDs and mounted file systems, while the kernel's cgroups provide resource limiting, including the CPU, memory, block I/O, and network.
Shipping code to the server is too hard
Deployment and Delivery Challenges
- Lots of small changes
- Heterogeneous platforms and languages
- Environments (Development, Production)
- Zero downtime
- Infrastructure as Code
- Continuous Delivery
- Infrastructure and Application Metrics
Microservices as a Remedy
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.
The Twelve-Factor App
is a methodology for building software-as-a-service apps that fit into these:
Requirements declaration points
- 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
Build, release, run
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
The Ultimate Goal
A single deployable file, which is under version control, verified by checksum and simply runs without any additional dependencies.
blog comments powered by Disqus