Demystifying Container-related Terminology


Much of the posts in this blog are deeply technical in nature with lots of discussions around software and coding principles. So I thought I would take a step back and demystify some of the terminology that is used in this space.

We will provide a Level 100 knowledge on:

  • Containers and Vitualization
  • DevOps
  • Microservices
  • Cluster managers and cluster orchestrators
  • Platform as a Service

Along the way, we will encounter a few discussion points as seen below:

Click image for full size

snap0001

Figure 1: Discussion Points

Why Containers?

One place to start is explaining why containers are attractive. The most popular answer is, “Containerization contributes significantly to the streamlining of DevOps.”

Click image for full size

picture1

Figure 2: Containers and DevOps

  • The world of containerization plays a key role in solving one of the most difficult problems facing businesses – consistently deploying updates to software with increasing velocity
  • Deployment velocity is crucial in the world of mobile and web computing
  • It is well documented that frequent software releases leads to happier customers, employees and increased revenue to businesses.
  • This has given rise to the notion of DevOps
  • DevOps is the practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes
  • Containerization supports the ability to package up applications and all of their dependencies with the application itself, thus guaranteeing that the application will behave the same way wherever it is deployed
  • Virtualization helps companies by running multiple operating systems on a single server
  • In many scenarios, however, VMs generally support one application per OS, due to potential conflicts with dependencies (versions of external DLLs, for example)

Containers also make it possible to deploy applications on a generic virtual machine that does not to be preconfigured to support that application. This provides more flexibility because an entire pool of VMs can be treated generically, making it possible to leverage any of the virtual machines, not just ones that are prepared to accept a specific application

Click image for full size

container-landscape

Figure 3: Container Landscape

  • Containerization paves the way for many applications to run in a single OS
  • Skeptics argue that traditional virtualization is sufficient
  • But experts contend that containers offer a more robust alternative than traditional VMs when supporting continuous delivery and continuous integration
  • Containers can provide code updates and bug fixes are tested and deployed within minutes rather than hours or days
  • Containers also enable instant scale, as they take micro seconds to instantiate, as compared to a VM which can take minutes
  • The core goal is to solve business problems faster than competitors, while reducing risk and adhering to regulatory and compliance issues

Microservice Architecture

Much of what you’re about to see below is fairly well documented. I’m including it here for completeness.

As you read this, keep in mind that, although not required, containers often play a key role in microservice architectures. Containers make a lot of sense for microservices, as they encapsulate dependencies in the application together, simplifying the management and update of each microservices.

Problems with typical 3-tier architectures

Click image for full size

3-tier-arch

Figure 4: 3-tier Architecture

Microservices were created to overcome some of the challenges listed below. But that doesn’t mean necessarily that 3-tier architectures are bad. Rather, there are some scenarios where a microservices architecture overcomes difficult problems.

Here are some of the challenges with 3-tier architectures:

  • One single code base
    • Stuck in same technology stack (Linux, JVM, Tomcat, Libraries)
      • Cannot enjoy best of breed
    • Big deployments
    • Overwhelming complexity
    • Requires close coordination across the tiers
  • Grows gradually and begins to lose architectural integrity
    • Separation of concerns, layers become rigid
  • Difficult to find, identify, and fix bugs across tiers
  • Difficult to scale
  • Difficult to deploy
  • IDEs become unresponsive and slow as codebase becomes too large

What are Microservices?

The image below depicts what a micro services architecture might look like. You can think of each of the functional areas here as being fully decoupled other functional areas, connected only through a standard http-based API.

Click image for full size

microservices

Figure 5: Example of a Microservices architecture

Let’s spell out some of a microservice’s key characteristics:

  • Microservices are not broken into tiers, such as the database tier UI tier, etc.
  • Rather, they are broken down by function (ie, inventory, delivery, ordering,
    carts, checkout, etc)
  • Monolithic apps can be decomposed functinally manageable and independently deployable components
  • Each service has its own maintenance, monitoring, application servers, and database
  • Each service has its own code repository and development team
  • Each service can be scaled independently
  • Communication with http, rest, JSON

Disadvantages of microservices

There is always a downside. Here are the ones for microservices.

  • Team Communication Overhead
  • Formal documentation overhead
  • Dev Ops complexity
  • Increased Resource use
  • Increase Network communication
  • Marshalling and Unmarshalling
  • Network Security
  • Production monitoring

More information can be found here:

http://martinfowler.com/articles/microservices.html

PaaS or Containers

There is a fair amount of confusion about what platform as a service (PaaS) means in the context of containerization. The conversation typically gets more confusing when the notion of orchestration is added.

These terms have become overloaded over the past few years and drawing distinctions among them be challenging. Let’s focus on what the terms mean initially, then attempt to differentiate them.

Containers

Let’s begin with the term, container. A container allows you to package your application into a standardized unit for software development. Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run: code, runtime, system tools, system libraries – anything that can be installed on a server.

Cluster orchestration

Containers along with the associated applications are generally run inside of a cluster. Deploying and running containers on a cluster is the job of a cluster manager or orchestrator. The popular orchestration technologies today for running Docker containers include: (1) Mesos; (2) Docker Swarm; (3) Kubernetes. Of the three, Mesos has been around the longest. Kubernetes and Docker Swarm have only been around three years or less, while Mesos has been around since 2009. They are often described also as cluster managers. They are also described as cluster orchestrators. With varying degrees of completeness these cluster managers or orchestrators also provide the ability to scale, recover from failure, and treat a set of virtual machines as a single pool of compute resources.

PaaS

Platform as a service is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app. Developers just worry about their application in its data, with little concern for anything else like the underlying virtual machines and compute stack, often including the ability to scale as well as recover from failure.

Azure Container Service (ACS)

ACS can be thought of as a combination of the three previously describe technologies: (1) Containers (2) Cluster Managers; (3) PaaS. The Azure Container Service is Microsoft’s container scheduling and orchestration service for its Azure cloud computing service.

Comparisons

Here is where things get a little tricky. The Azure Container Service allows you to easily provision a Docker Swarm or Apache Mesos (DC/OS) cluster that supports Docker containers in just a few mouse clicks or in an easy to execute script. ACS completely abstracts your need to worry about the provisioning of underlying virtual machines and to install the under allowing cluster orchestration technologies. As the developer, you can take any existing Docker container and deploy it into the service in a matter of minutes. So in a sense it has some platform as a service capabilities to the degree that the cluster creation and software installation is fully automated.

Conclusions

The hope is that you understand the similarity and differences among the following terms:

  • Containers
  • DevOps
  • Microservices
  • Cluster managers and cluster orchestrators
  • Platform as a Service

Comments (0)

Skip to main content