Docker and the Three Ways of DevOps

WHITEPAPER | DOCKER AND THE THREE WAYS OF DEVOPS
Docker and the First Way
Velocity
Developer Flow
Developers who use Docker typically create a Docker environment
on their laptop to locally develop and test applications in containers.
In this environment, they can test a service stack made up
of multiple Docker containers. Container instances spin up at an
average of around 500 milliseconds. Multiple Docker containers
converged as a single service stack, like a LAMP stack, can
take seconds to instantiate. Convergence is the interconnection
information that needs to be configured between the instances,
for example a database connection info or load balancer IP’s.
Contrast this to non-container virtual instances running as multiple
hosts. An alternative non-containerized environment can take anywhere
from 2 to 10 minutes to spin up and converge depending
on the complexity. The end result with Docker is that developers
experience less context switch time for testing and retesting and
resulting in significantly increased velocity.
Integration Flow
Docker can streamline a continuous integration (CI) with the use
of Dockerized build slaves. A CI system can be designed such
that multiple virtual instances each run as individual Docker hosts
as multiple build slaves, for example. Some environments run a
Docker host inside of a Docker host (Docker-in-Docker) for their
build environments. This creates a clean isolation of the build out
and breakdown environments for the services being tested. In this
case, the original virtual instances are never corrupted because
the embedded Docker host can be recreated for each CI slave
instance. The inner Docker host is just a Docker image and instantiates
at the same speed as any other Docker instance.
Just like the developers’ laptop, the integrated services can run
as Docker containers inside these build slaves. Not only are there
exponential efficiencies in the spin up times of the tested service,
there are also the benefits of rebasing multiple testing scenarios.
Multiple tests starting from the same baseline can be run over and
over in a matter of seconds. The sub-second Docker container
spin-up times allow scenarios where thousands of integration tests
occur in minutes that would otherwise take days to complete.
Docker also increases velocity for CI pipelines with Union FileSystems
and Copy on Write (COW). Docker images are created using
a layered file system approach. Typically only the current (top)
layer is a writable layer (COW). Advanced usage of baselining and
rebasing between these layers can also increase the lead time
for getting software through the pipeline. For example, a specific
MySQL table could be initialized at a certain state and could be
rebased back to the original state in the container image for each
test therefore providing multiple tests with accelerated efficiencies.
Deployment Flow
To achieve increased velocity for Continuous Delivery (CD) of
software, there are a number of techniques that can be impacted
by the use of Docker. A popular CD process called “Blue Green
deploys” is often used to seamlessly migrate applications into
production. One of the challenges of production deployments is
ensuring seamless and timely changeover times (moving from one
version to another). A Blue Green deploy is a technique where
one node of a cluster is updated at a time (i.e., the green node)
while the other nodes are still untouched (the blue nodes). This
technique requires a rolling process where one node is updated
and tested at a time. The two key takeaways here are: 1) the total
speed to update all the nodes needs to be timely and 2) if the
cluster needs to be rolled back this also has to happen in a timely
fashion. Docker containers make the roll forward and roll back
process more efficient. Also, because the application is isolated
in a container, this process is much cleaner with far less moving
parts involved during the changeover. Other deployment techniques
like dark launches and canarying can benefit from Docker
container isolation and speed, all for the same reasons described
earlier.
Variation
A key benefits of using Docker images in a software delivery pipeline
is that both the infrastructure and the application can both be
included in the container image. One of the core tenants of Java
was the promise of “write once run anywhere”. However, since
the Java artifact (typically a JAR, WAR or EAR) only included the
application there was always a wide range of variation, depending
on the Java runtime and the specific operating environment of the
deployment environment. With Docker, a developer can bundle
the actual infrastructure (i.e. the base OS, middleware, runtime
and the application) in the same image. This converged isolation
lowers the potential variation at every stage of the delivery pipeline
(dev, integration and production deployment). If a developer tests
a set of Docker images as a service on a laptop, those same services
can be exactly the same during the integration testing and
the production deployment. The image (i.e., the converged artifact)
is a binary. There should be little or no variation of a service
stack at any of the stages of the pipeline when Docker containers
are used as the primary deployment mechanism. Contrast this to
environments that have to be built at each stage of the pipeline.
Alternatively, configuration management and release engineer
scripting are often used at each stage of the pipeline to build
out the service. Although most automation mechanisms are far
more efficient than a checklist built service, they still run the risk of
higher variation than binay Docker service stacks. These alternatives
to Docker containers can yield wider variances of stability
therefore increasing variation. A Dockerized pipeline approach delivers
converged artifacts as binaries and therefore are immutable
starting from the commit.
WHITE PAPER / 5