Though Docker containers can be run on private cloud infrastructure, many users naturally want to run them in public cloud platforms. This brings you the benefits of the cloud-like scale, economy, and simplicity. It also avoids the hassle of having to manage the lower layers of your infrastructure and frees you to focus on what really matters - your apps and services.
Managing Docker in the Cloud - What Matters
When running Dockerized applications in production, the criteria stay the same, but how they play out in production is what differs with containers. Let’s look at a few of these criteria and what changes with them.
The first reason most users shift to Docker containers is to take advantage of the scalability it brings. As your app reaches millions of users, VMs are tardy and slow to respond to spikes in traffic, and hyper-growth. By contrast, containers can easily be scaled out or scaled back to meet changing demands.
When running Docker containers in the cloud, you want to be able to run thousands, or hundreds of thousands of containers seamlessly. This is easier said than done. Though Docker enables scale, and it makes managing infrastructure easier at scale, it brings a different type of complexity.
Containers are ephemeral in nature and support dynamic workloads. With the constant creation and destruction of containers, you need to ensure high availability for the applications and services they support. Additionally, performance lags should be handled with container-centric load balancing.
Load balancing between containers in the cloud is similar to traditional load balancing, where the workload is shared across multiple instances. Only in this case, the pace of load balancing is much more frantic considering the dynamic nature of containers. The load balancer needs to be aware of the health of containers across all regions and route requests to the instances that are most likely to process the task fastest. AWS ELB is a great example of a load balancer that has evolved to support container workloads.
Vendor lock-in is a concern especially for enterprises moving to the cloud. With the complex backend systems and long-running applications, they have a lot to lose by switching infrastructure. At the same time, as they adopt containers, they want to enjoy the benefit of portability that containers promise. While containers bring portability within the development pipeline, portability between cloud providers is yet to become a reality.
As you configure cloud infrastructure to run Docker containers, you want to have the flexibility to switch between cloud providers. But this is easier said than done due to the unique characteristics of each cloud provider. When you choose a cloud vendor’s container service, it follows that you also adopt their unique take on tools for identity and access management (IAM), security, networking, and storage. Moving the container to a different cloud vendor would mean a change to all these aspects of running Docker in the cloud.
While there are obstacles to cloud portability, it’s easier to move between clouds than between hardware servers. Your application code, its binaries and libraries are still isolated from the infrastructure and can be ported over to the other cloud vendor as is. This is a big advantage when running Docker in the cloud. With the recent adoption of Kubernetes as the standard for cloud-based container deployments (Amazon’s EKS, Azure’s AKS and Google’s more mature GKE) some of the differences between container cloud deployments have diminished, showing a trend of improving cross-cloud portability.
Perhaps the most important decision when running Docker in the cloud is where to host them. There are numerous options to choose from and the number keeps growing. If you’re already committed to a cloud vendor you need to consider how your operations and costs will change with the move to containers. If you run a hybrid setup of both a private datacenter and public cloud infrastructure you need to think of how to manage containers across both platforms.
There are numerous vendors providing container management services, popularly known as container as-a-service (CaaS). Let’s look at each option and assess how they stack up with the others.
For deployment, Docker Cloud leverages Docker Swarm and can deploy containers on its own Docker Cloud platform or any public cloud platform. While this is a good option for a developer environment, for production workloads many organizations find themselves committed to a public cloud vendor like AWS where they host much of their other infrastructure. In this case, a CaaS service from one of the public cloud vendors is an attractive option to host Docker containers.
With cloud vendors, the norm is to run your containers within VMs. In the case of AWS, this means running containers within EC2 instances.
The biggest benefit of going with a cloud vendor like AWS is that the container service is deeply integrated with their cloud platform. This means you can easily leverage services like IAM for access management, S3 for storage, and CloudTrail for API logging.
AWS has recently announced full support for Kubernetes as it adopts the now-industry-standard for container orchestration. Its new Elastic Kubernetes Service (EKS) service makes it easy to run Kubernetes in production by simplifying setup and management of Kubernetes clusters. Once an app is deployed on EKS, AWS handles automatic scaling and high availability. EKS constantly monitors masters and automatically replaces unhealthy ones.
To bring up the advantage of portability, AWS touts that EKS can handle any existing Kubernetes workload whether on-premise or in any other public cloud. They promise easy migration to EKS promising that your EKS Kubernetes clusters will be fully compatible with Kubernetes community tooling such as Kubectl.
Related to EKS, AWS also announced a very interesting add-on to its ECS service called Fargate. It’s a bit like AWS Lambda for containers. Fargate’s biggest strength is that it completely abstracts away the underlying infrastructure leaving you to focus on your containers and applications instead. You still have control over what goes in your containers, who has access to them, how they’re networked, and how they handle workloads. But the drudge of configuring the perfect infrastructure to power all this is no longer required. You can just define the required CPU and memory and Fargate ensures you always have those resources available for your containers.
Azure Container Service (AKS)
AKS particularly focuses on making it easy to get started in as quick as 5 minutes, and thereafter, making it easy to install new upgrades and patches, and simplifying scaling of clusters.
Azure still supports other orchestrators on AKS, so if you want to use Mesos or Swarm or Nomad, you can. Kubernetes is the most preferred way of running Docker containers in the cloud, and in this sense, Azure is on the right track in focusing on Kubernetes.
Azure also offers Azure Container Instances that makes it extremely easy to get up and running with containers in the cloud. ACI doesn’t have a graphical interface, as of yet. It works only via the Azure CLI, and lets you spin up a container instance with a single command. It’s in preview stage and isn’t very well integrated with the rest of the Azure Cloud platform. However, its strength lies in its simplicity. It’s meant to be the fastest way to get up and running without having to configure any VMs, or deal with container tools. All you need is your application code and you can package it in a container and push it into production with just a single command. While the service is not yet ready for prime time, it’s surprisingly simple to get started with, and is especially great for those who are just getting started running Docker in the cloud.
Google Kubernetes Engine (GKE)
GKE delivers the most upstream version of Kubernetes and focuses on automating much of the Kubernetes management tasks.
Like its competitors, GKE integrates into other Google Cloud services for access management, security and more. It also provides unique features like preemptible virtual machines that are low-cost instances with a short lifespan suitable for running batch jobs.