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.
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.
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.
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:
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:
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:
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!