What Are Azure Containers -- For IT Pros

In this post, I’ll discuss what Azure Containers can do and how they can be used and managed in Azure. The intended audience for this post are IT pros, such as consultants, engineers, operators, and architects.
 

Relevance

Microsoft was quite blunt about the importance of containers at the recent Ignite conference. Jeff Woolsey, a Principal Program Manager at Microsoft for the Cloud and Enterprise Division, repeatedly stated that containers are the new virtualization. 10+ years ago, machine virtualization changed how we deployed applications and services in the data center. The role and importance of machine virtualization will continue, sometimes in different places (public cloud, for example), but operating system virtualization (containers) has started to penetrate the market.
Containers offer near-instant deployment and are a great way of moving legacy code into a DevOps lifecycle. Deployment times are shortened, maintenance is easier, and scale-out/in is possible in seconds; this is why large enterprises such Ticketmaster use container technology, why SQL Server for containers was released, and why Microsoft has put so much effort into developing container technologies in Windows Server 2016 and Azure.

What Are Containers?

Machine virtualization, such as Hyper-V or ESXi, creates a partition for each operating system deployment. Each partition simulates a machine using software and gives the illusion of multiple physical machines running instead of a single host. For each application, you’ll have one or more virtual machines, each with its own OS to configure, patch, and maintain. As much as you optimize the deployment process, a large file copy will take place and an OS specialization will take time to run.
From the developer’s point of view, virtual machines are still in the realm of the IT department, and that means getting a new development or test environment is going to be slow and painful. From the business’s point of view, when they look for a new service, the devs are going to be telling them that IT is the bottleneck!
 

 
Containers are a relatively new kind of virtualization called operating system virtualization. Machine virtualization takes a single machine and simulates lots of machines. Containers take a single operating system installation (physical or virtual machine) and simulate lots of operating system installations.
Microsoft once started building its own management framework for containers but after consulting with the community of container customers, they instead decided to rely more on their partnership with Docker, an established brand in the containers world.

 
Containers are built from an image repository, such as Docker Hub or your own private registry. Operators can download images, make them available to container hosts, and then deploy new container instances in a matter of seconds (thanks to a linking process instead of file copies). Developers can use stock images and specialize them with runtimes, plugins and their own code, creating their own versioned images that can be near-instantly deployed.
The result is that developers can work in a more dynamic world, quickly able to deploy new services and new versions of services. When you work via DevOps you can use tooling to control and orchestrate the release and versioning process.

Containers in Azure

There’s nothing stopping you from deploying a Windows or Linux virtual machine in Azure and enabling containers in it. If you want to experiment, that’s fine, but if you want a production system, then you’ll use one of three containers solutions:

• Azure Container Service (ACS): ACS is the primary way to use containers in Azure, capable of scaling out to tens of thousands of containers. This is a developer and operator infrastructure because it is based on a cluster of virtual machines that host the containers. Typically, ACS is best for Linux-based containers. ACS is driven by tools from the open source world, so you will need to understand these systems.
• Azure Container Instance (ACI): ACI made lots of headlines recently, being promoted as a cheap serverless way of doing containers. ACI is based on a per-second rate but is really only cost effective for burst capacity. The normal capacity should use one of the other container solutions and any extra capacity could be deployed using ACI.
• Service Fabric: Windows and Linux containers can use Service Fabric but it is based suited to Windows. Under the covers of the fabric, is a scale-set cluster of virtual machines.

Tools

You can use Docker’s command line tool for small-scale management but once you deploy containers at scale, you will need an orchestration solution. A number container orchestrators, all sourced from outside of Microsoft, can be used to deploy and control containers in Azure:

• Docker Swarm: A solution that scales well up to 100-200 node clusters.
• Mesos DC/OS: which is popular with some very large container users, such as Twitter.
• Kubernetes: This is a solution that was originally developed by Google and contributed to the open source world. Can you believe that Google code is running in Azure? Kubernetes used by companies such as Ebay and SAP.

Which is the right one to use? Based on what I’ve read, that’s like asking a room of techies if they prefer Linux or Windows, VMware or Hyper-V, SQL Server or Oracle. Each orchestrator has certain features, benefits, and limitations. I think you really need to understand the big picture to decide on an orchestrator:

• Container types
• Continuous integration (CI) system
• Continuous deployment (CD) solution

 

Learning

If you are a server/virtualization admin in a company that is adopting containers, then you will probably be involved. There’s a lot to learn and potentially most of that resides in the management and CI/CD (DevOps) space. You’re in for a fun time!