Docker Container Overview for Business Leaders

This deck provides a narrative around containers that is geared towards business leaders.

  • While there might be a good amount of technical content here, it’s really more about explaining the lay of the land, how things fit together, the value proposition / business value of containerization.
  • Toward the end we will have a discussion around cluster orchestration and what that means in the context of Azure.

Click image for full size


Figure 1: Introduction

By now it should be obvious that containers have a substantial amount of mind share in the software press.

  • With so much hype around Docker containers one cannot help but consider the Gartner Hype Cycle, which attempts to capture the perceptions and reality of a given technology.
  • As you can see from the chart below, technologies typically undergo a period of inflated expectations, only to be followed by a downward slope into the trough of disillusionment, whereby the promises of the technology fall short of reality.
  • At some point, a realistic perception of the technology gains momentum and technologists become productive using it.
  • In the case of Docker Containers, it is a lively debate to consider where we are on this hype cycle.

Click image for full size


Figure 2: The Gartner hype curve

Before we can describe the value of containers, let’s take a few moments to really explain what containers are.

  • Some might argue that containers are simply another form of virtualization.
  • However, that would be a fairly narrow interpretation of what they really offer.

Click image for full size


Figure 3: What are containers?

A good starting point is to describe what containerization means.

  • Conceptually, it is very simple.
  • It’s a way of bundling an application with everything that it depends on it.
  • Historically, when deploying an application, IT operations make sure that all the application dependencies are present on the virtual machine where the application will be running.
  • Containerization means that that an application’s dependencies are bundled with the application itself.
  • That makes it possible to deploy an application just about anywhere without any requirements about what exists on the destination computer where the application will be running.
  • The key take away is that if an application runs well on one computer, copying the container to another computer should also work reliably and predictably.

Click image for full size


Figure 4: What is a container?

One way to think about containerization is by comparing it to traditional virtualization through virtual machines.

  • On the left you can see that applications A, B, & C each run in the own copy of the operating system, so that they can enjoy the necessary isolation from other running applications.
  • But this overhead of having to run a guest OS for each application is slow and cumbersome.
  • Contrast this to the right side of the diagram where containers are used.
  • With containers there is just one host operating system that is shared among each of the 3 applications, where each application runs in its own container.
  • The Docker Engine takes care of providing the isolation and run-time semantics for each of the 3 applications, making sure that they work harmoniously on a single operating system.
  • Another value beyond making deployment a better experience, a container (along with its application)can boot in sub-second times.
  • In contrast to traditional virtualization, which can take a few minutes to start an application in its own guest OS.

Click image for full size


Figure 5: Comparing traditional virtual machines to containers

Let’s get really concrete about why containers are so powerful.

Click image for full size


Figure 6: Why containers are so powerful

The purpose of this image is to clearly illustrate the difference between traditional virtualization and containerization.

  • The left side of the diagram shows the traditional world, where dependencies that exist at the virtual machine level are shared among applications.
  • The problem with this is that if you change a dependency for one of the applications, the other applications may fail.
  • On the right side of the diagram you see that each container with its application brings its own copies of the dependency.
  • This allows you to run multiple applications on the same virtual machine, each with its own dependencies included.
  • The risk of failure is much lower in this scenario with containerization.

Click image for full size


Figure 7: Understanding dependency risk

The main reason for the rising container use is the fact that it streamlines the deployment of applications in the production.

  • For the reasons cited previously, and makes sense that predictable application behavior across developer staging and production is ideal.

Click image for full size


Figure 8: It's about DevOps

The big question everybody is asking is at what point will this approach to computing hit mainstream enterprise adoption.

  • There are signs that this is taking place now, but not at the full-scale that many expect.
  • There is clear evidence that this is happening with developers and in test environments.
  • But there still some hesitancy for production workloads.
  • There are concerns around security and the fact that much of this technology is only a couple of years old.

Click image for full size


Figure 9: Containers and the enterprise

One of the new architectural patterns that is emerging is called micro service architectures.

  • The traditional three-tier monolithic application.
  • Many contend that microservices are simply a rebranding of service oriented architectures (SOA).
  • Like anything else, there are scenarios where this architecture is ideal.
  • Being able to decompose an application into smaller chunks makes a lot of sense, especially in scenarios where you want to be able to scale certain portions of an application separately, the ability to choose the appropriate data store and language for that scenario, and be able to develop independently of other parts of the application overall.

Click image for full size


Figure 10: The future of the enterprise

The diagram below depicts the basic ideas.

  • Notice that, for example, an application like Uber can be broken down into different services, such as trip management, billing, and more.
  • Each of those areas would have a separate development team with separate application development and deployment pipelines.

Click image for full size


Figure 11: Defining microservices

One of the misconceptions out there is that Docker created the concept of the container. Let’s explore the timeline of containers.

Click image for full size


Figure 12: The evolution of containerization

Surprising to most is that containers have been around for decades.

  • You can go all the way back to 1979, where chroot enabled an application to have its own copy of the file system, allowing a number of applications to run on one host OS, each application having its own clean copy of the file system.
  • This evolved into the ability for isolation of CPU, network, and memory.
  • In other words, it went just beyond segregating the file system.
  • Later incarnations supported the ability to throttle applications and constrain them to use specific amounts of CPU, network, memory, and storage .
  • Finally, Docker came around in 2013 and standardized the concept of the container across multiple Linux distributions.
  • And more recently Microsoft has been building in container support for Windows operating systems.

Click image for full size


Figure 13: Containerization timeline

What did Docker do and almost become synonymous with the concept of containers?.

Click image for full size


Figure 14: The spike in popularity

It’s clear that economics can explain almost anything.

  • Containers do more than just lower cost.
  • They also increase business value by increasing deployment velocity.

Click image for full size


Figure 15: The economics of containers

High performing IT operations reduce the amount of unnecessary work, due to failures in the application delivery process.

  • In addition, they accrue less technical debt, meaning that software rewrites do not compromise the architectural integrity of applications.
  • Often times, companies spontaneously apply last-minute changes to software to reduce downtime in production.
  • Scrambling to fix software under pressure often results in architectural decay, also know as technical debt.

Click image for full size


Figure 16: The DevOps pipeline

Containerization only solves half the problem.

  • When you think about letting your applications across hundreds of hosts, you run into a number of challenges.
  • First is the challenge of knowing where to run the application, based on its hardware requirements and availability across the cluster.
  • Second, being able to scale the application up and down across the cluster is necessary depending on changing workloads.
  • Third, recovering from failure and rescheduling the application in a different location is also important.
  • The terminology used to describe this type of software is called cluster orchestration or cluster scheduling.

Click image for full size


Figure 17: Managing containers in a cluster

There are three dominant players in the space today as seen below. Each come with their own advantages and disadvantages.

  • I usually recommend customers to experiment with each, choosing the one that suits requirements best.

Click image for full size


Figure 18: Cluster orchestrators

An obvious question at this point is, “What can Azure do to support containers and cluster orchestration?”.

Click image for full size


Figure 19: azure support for cluster orchestration

There are a number of different paths you can take with cluster orchestration in the context of Azure, as seen below.

  • The easiest choice to get started is using the Azure Container Service, explained in detail in my other posts.

Click image for full size


Figure 20: How Azure supports orchestration

Today the Azure container service supports Docker Swarm and DC/OS.

Click image for full size


Figure 21: The Azure container service

This concludes our presentation around the overview of containers. If you have any other ideas to make this post better, please email them to me at,.

  • Thanks for reading.

Click image for full size


Figure 22: Wrapping up