This content is part of the Essential Guide: Containers-as-a-service providers take some pressure off IT

Container as a service providers compete with distinct strategies

IT shops contend with changes to networks, monitoring, storage and other ops to deploy containers, and that's where major cloud providers will gladly step in.

While developers can control everything that happens within Docker containers, they rely upon operations personnel to build and maintain the container environment. It's not a task suited for every company, so container as a service providers offer an alternative.

Creating a Docker container is an isolated, virtualized process. Developers use Docker tools to build images that represent models for one or more containers. These containers move easily across different host servers and staging and production environments without any additional configuration.

Application developers love Docker containers' agility and flexibility. Within minutes, a developer can use Docker Engine, Dockerfile and Docker Compose to build n-tier application pods that include databases, app servers and web servers in any combination they need. But then it has to run somewhere.

You need a clustering tool to ensure high availability for these containers. Who's going to set that up and maintain it: the operations team or one of several container as a service providers?

The DevOps model -- in which development, operations and QA use continuous integration and continuous delivery (CI/CD) practices to bring products to market faster-- naturally fits with container implementation, from dev through test to production deployment. These organizations will select and implement tools to run containers on bare metal or inside virtual machines (VMs), and on private or hosted infrastructures.

On-premises deployments that lack a solid, dependable backbone for the container environment will create problems. For many businesses, where siloed IT and bureaucratic SNAFUs make agility difficult, teams may decide to pursue a container as a service (CaaS) hosted solution rather than create this backbone in-house.

The role of containers as a service

Containers as a service providers are cloud vendors that create a cloud service delivery model in which users pay for a preconstructed suite including orchestration, high availability, image registries and integration with the CI/CD pipeline.

CaaS falls between infrastructure as a service (IaaS) and platform as a service (PaaS). Containers are different from virtual machines, the hallmark of IaaS, which rely on a virtualization layer that encapsulates the OS. At the same time, containers give developers richer control over the containerized app's environment than PaaS typically grants.

There's an ecosystem of container management and orchestration tools that support container as a service offerings, including Docker Machine, a deployment tool used to install the Docker Engine on local or remote hosts; Swarm, Docker's native container orchestration tool; Kubernetes, Google's container orchestration tool; Mesos, from Apache; fleet, CoreOS's cluster management tool; and Nova-Docker, OpenStack's Docker driver.

All three of the major public cloud providers -- Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform -- chart a CaaS course for users, each taking different tacks.

Amazon EC2 Container Service

With Amazon Elastic Compute Cloud Container Service (ECS), AWS hosts the container cluster and configuration management system in its global web of data centers. This allows an organization to focus on building and deploying images and containers, instead of worrying about operational details.

There is no additional cost associated with ECS beyond the typical AWS assets for IaaS workloads: Elastic Compute Cloud (EC2) virtual machine instances, Virtual Private Cloud networking and Elastic Block Store storage.

ECS uses AWS' APIs to manage the user's containers; not a standard orchestration platform like Google Kubernetes or Docker Swarm. The Blox open source framework sits on top of Amazon ECS and helps developers extend the capabilities of the container service.

Amazon EC2 Container Service window
Figure 1. Amazon ECS is easiest for organizations that are already proficient with AWS for workloads.

Microsoft Azure Container Service

Microsoft has become bold about not only embracing competitors, but also open sourcing much of its core technology, as evidenced in its choices as a container as a service provider.

To wit, the Azure Container Service (ACS) engine is hosted on the code repository management platform GitHub, offering a choice of container orchestration engines for workloads, including Google Kubernetes, Apache Mesos (DC/OS) or Docker Swarm.

Like Amazon ECS, Microsoft ACS pricing has no additional charge beyond the runtime for the Azure cloud resources underpinning the code.

Microsoft Azure Container Service interface
Figure 2. Microsoft Azure Container Service provides great flexibility in terms of which orchestration engine to use.

Google Container Engine

Because Google invented the Kubernetes container orchestration and cluster management product, it makes sense that the Google Container Engine (GKE) service forces users down that particular path.

GKE pricing starts off similarly to ACS and ECS -- the user pays for the back-end computing power -- but it differs once use surpasses six nodes per cluster. As of this writing, Google charges $0.15 per runtime hour, on top of the standard computer resource fees for the volume.

Kubernetes for Google Container Engine
Figure 3. Google Container Engine relies on Google's Kubernetes tool.

Private cloud

As compelling as CaaS is, some businesses are resisting the public cloud due to data sovereignty and security issues. There are options, such as tools from OpenStack or Docker Datacenter, for IT shops unwilling to hand the reins to public container as a service providers.

While these products enable a private CaaS cloud, they can't obviate the problem that fuels interest in containers as a service from the public cloud providers; developers are still often hampered by a reliance on slower moving IT operations teams.

Next Steps

A potentially cloudy future in multicloud

Dive deeper into public CaaS offerings

Should containers run on VMs or bare metal?

Dig Deeper on Managing Virtual Containers