Tech Insights
5 Minute Read

Containers enable consistent deployment and execution

Containers are popular with both developers and operators because they offer a simpler way to achieve deployment and execution consistency. They can also help to improve development and operations (DevOps) team handoffs.

What are containers?

A container running on a machine is simply a process on the host operating system like any other. So what makes containers so popular? It's how the process is isolated and restricted. This is done in a very specific way that simplifies development and operations.

Containers isolate and abstract resources

“Containers promise faster app delivery cycles with better runtime execution, and ultimately lower production infrastructure costs.”

Robert Stroud
Principal Analyst Infrastructure and Operations, Forrester

Why containers matter

When containers began gaining popularity, wrote: “Containers are a solution to the problem of how to get software to run reliably when moved from one computing environment to another. This could be from a developer's laptop to a test environment, from a staging environment into production and perhaps from a physical machine in a data center to a virtual machine in a private or public cloud.”

Deployment consistency reduces time to market

Uniquely developing and packaging every application—plus its dependencies—to handoff to operations for deployment can be a time-consuming and costly process for enterprises. Containers couple code and processes—the app, as well as libraries, binaries, and configuration files—together to improve consistency and speed in pushing new applications and updates into production.

Execution consistency improves quality

Because code and processes are prepackaged to conform to release and management processes, teams can improve the quality of releases and thus, boost customer satisfaction.

Easier developer-to-operator handoff speeds delivery

Without having to customize each delivery, developers and operations (DevOps) staff have more time to focus on doing what they do best: developing business-critical applications and ensuring robust app delivery.

“What are the reasons for opting to use container technologies?
(Such as Docker, rkt, CoreOS)?”

Saurabh Gupta. "Containers and VMware Tanzu" 2016.

A closer look at container technology

Containers have their roots deep in the history of the Linux operating system. Containers make use of the kernel features of Linux. The core underpinnings of containers in Linux—cgroup, namespaces, and filesystems—operate in a somewhat isolated area. The magic of containers is in how these technologies combine together for maximum convenience.

Cgroup, or control group, is a mechanism to organize processes hierarchically and distribute system resources along the hierarchy in a controlled and configurable manner. Namespaces control what view of the virtual machine (VM) a process can have. Namespaces allow a process to treat a global resource as if the process had its own isolated instance of that resource.

Once Linux controls what a process can do (cgroup) and what a process sees (namespaces), it controls the file system the process has access to by mounting it in the namespace of the process. Additionally, the process can have read-only access to most of the file system and read-write access to a small part of it. These file systems are at the core of the concept of an “image”: an image (e.g. a Docker image) is just a set of serialized file systems with some configuration and metadata. When an image is deployed as a container, the container process gets the image’s file systems expanded as a mounted file system in its namespace.

Although one company often dominates the conversation about containers because of its developer-friendly user experience, open source container projects—including the Docker project—enable any organization to take advantage of the model. The standards body, Open Container Initiative (OCI) has created a clear specification for an image:

What to keep in mind if you’re considering containers

Nearly synonymous with containers, “Docker” as a term connotes many things:

  • a short-hand word used to represent container technology
  • a commercial venture-backed startup company: “Docker, Inc.”
  • an open source container project without a foundation governance model, “Docker project”
  • the brand for a commercial product produced by Docker, Inc.
  • the name often used for the popular open source runtime “Docker Engine”
  • a container image format known as a “Docker image”
  • a developer desktop tool-chain to simplify development and packaging “Docker for Mac & Docker for Windows”

There are other container sources.

There are open source container projects, as well as a host of other commercial products available to create containers. You will need to decide what format is best for your organization.

Containers and virtualization are complementary.

To increase security and isolation, containers can be run in lightweight virtual machines. The hardware infrastructure (e.g., networks, servers and storage) required to support containers is more easily managed by virtualization.

Container orchestration does not make a platform.

A platform is a suite of capabilities that work together to offer developers and operators a simple way to deploy, monitor, manage, scale, secure, and connect applications. However, container technology is an important part of an enterprise platform: it is central to how applications are deployed and managed, but the systems that provide these capabilities are additive on top of the core container technology for running applications.

If you use containers, you will still need a robust deployment platform.

Like virtualization, where hypervisors and machine images are not a full virtualization platform, container technology is one piece of a larger set of responsibilities needed for an enterprise platform. DevOps teams have found that simply taking an image and creating a workload out of it as a container is not the full solution—for example, containerizing a workload does not automatically give DevOps the suite of features that teams would like with respect to capabilities such as high availability, auto scaling, traffic routing, and logging. Proven, integrated platforms like VMware Tanzu Application Service give teams these capabilities.

Stay current on important topics

Newsletter signup

If you use containers, you will still need an enterprise-grade security and management platform.

Taking an image and creating a workload out of it as a container also does not provide DevOps teams with an enterprise-grade experience because inherently containers lack capabilities such as security, high availability, application lifecycle management and more. For any organization seeking scale, security, and deployment consistency, an enterprise platform is required to provide the capabilities needed to run a workload as a container.

Your platform decision will be either build or buy.

Since the core notion of containers is devoid of any notion of the capabilities of a platform, your enterprise operators will be left having to bring these capabilities in on their own, either by writing their own tools or by pulling together a disparate set of tools, utilities, and products at varying levels of maturity from other sources and suppliers.

Cloud Foundry has worked with containers from the very beginning.

The original rationale for Cloud Foundry, which still holds true today, was anchored in two core ideas:

  • The ability to better utilize the underlying infrastructure
  • The ability to provide consistent, production-ready, resilient environments for developers in a highly productive and easy-to-use manner

Standards exist for container image format and runtime.

The Open Container Initiative (OCI) collectively works on helpful standards around a container image format and runtime. Developers and operations benefit from portability for containerized applications, while members benefit from member contributions. Pivotal (now part of VMware) was a founding member of the OCI.

Containers & Buildpacks

Cloud Foundry supports both developer-built containers and platform-built containers. Which option you use depends on how you prefer to manage your application dependencies and updates. With platform-built containers, Cloud Foundry uses buildpacks to package application lifecycle management. With developer-built containers the update lifecycle is handled outside the platform.

Developer-Built Containers Versus Platform-Built Containers

Developer-built containers
Platform-built containers
Deploy applications as a container. Developers take the source code and all dependencies and wrap in a container definition. This package is deployed to the target environment.
Deploy application as code. Developers deploy raw or compiled source code that is packaged by the buildpack and published to the target environment.
Developer identifies middleware. In a container-based deployment, developers choose a base image, language dependencies, and middleware components that make up the portable image. The runtime environment takes and runs that container.
Platform handles middleware. Instead of developers selecting and configuring language runtimes and middleware, the buildpack assembles the container from a known good definition. The runtime environment takes and runs that container.
Bring your own language. Containers can include most any Linux-based technology inside. Developers have wide latitude as to which languages and dependencies to include.
Language support dependent on existing buildpack. While there are buildpacks for all major modern languages, a developer is constrained by the available buildpacks. There is an option, however, to construct a custom buildpack.
Developer is responsible for lifecycle management. If there are bugs or updates to language runtimes or middleware, it’s up to the developer to update the container and redeploy it to the target environment.
Platform handles much of the lifecycle management. Platforms such as VMware Tanzu Application Service can take buildpack-based applications and update deployed containers to the latest runtime and middleware without developer involvement.

Containers at VMware

The Cloud Foundry project has been working with containers since 2011. We’ve been running containers in production since the initial commercial product launch—first with Warden, then Garden, and now Garden-runC.

Most recently, we launched VMware Tanzu Kubernetes Grid Integrated Edition, production-grade Kubernetes that allow enterprises to reliably deploy and run containerized workloads across private and public clouds. TKGI eases Day 2 operations burdens for container orchestration with built-in high availability, monitoring, automated health checks, and more.

Commitment to OCI

Pivotal (now part of VMware) was a founding member of the Open Container Initiative (OCI), a lightweight, open governance structure (project), formed in 2015 for the express purpose of creating open industry standards around container formats and runtime. The OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.

VMware’s work with containers is completely aligned with the purpose of the OCI. The first important milestone was to adopt OCI runC as Cloud Foundry’s core container runtime. All supported versions of Tanzu use runC. Learn more about OCI and Pivotal (now part of VMware).

A Complete Platform for Container Deployment

Cloud Foundry’s elastic runtime is a proven solution for container orchestration, scaling today to nearly 250,000 containers in a single cluster. VMware Tanzu Application Service is a complete platform that takes payloads from developers—either as compiled artifacts like jar and war files, or as pre-built container images—and provides a complete system to schedule and run these payloads.

Tanzu provides all the auxiliary services of a platform (e.g., load balancing, high availability, auto scaling, and unified logging). Developers can deploy (and redeploy) their apps manually using the cf push command. Increasingly, teams want to automate this process with continuous integration/continuous delivery (CI/CD) pipelines.

Tanzu utilizes containers extensively (after all, VMware is an active contributor and supporter of the OCI). However, containers are only a part of the system. Tanzu orchestrates containers with ease—and of course, a cloud native platform is much more than container orchestration. Tanzu includes many sub-systems acting together to coordinate, monitor, and support containers.

Cloud Foundry’s secure containerization is also part of a platform-wide, industry-leading security system for protecting apps in the cloud. The addition of AppArmor (a Mandatory Access Control System (MAC) and part of the mainline linux kernel that restricts a given program’s access inside a container to system resources like network, disk, etc.) and Seccomp (a Secure Computing Mode that is also part of the mainline linux kernel and restricts the set of system calls a program inside a container can access) to Tanzu’s existing container security and platform security, together with practices like Rotate, Repave, and Repair, can combine for dramatic improvement to default security postures and operational security.