"Running our service just on top of VMs (virtual machines) would be ugly," he says. "I couldn't envision doing it without containers."
Container hype is sweeping across the cloud computing and virtualization industry. Many developers have realized the advantage of the lightweight way of packaging application code and in turn big-name tech vendors, from Amazon Web Services, Red Hat, IBM and even VMware are jumping aboard the container bandwagon.
And it's leading some to wonder: Will the rise of containers mark an end to virtualization and virtual machines
+MORE AT NETWORK WORLD: How to get more out of your virtualized and cloud environments | 10 open source tools to make Docker even more powerful +
A structural disruption
"There is a structural disruption happening right now," says Bryan Cantrill, the CTO of cloud provider Joyent, which is a heavy user of container technology. "We're now doing to VMs what VMs did to physical machines."
Containers are not a new technology: the earliest iterations of containers have been around in open source Linux code for decades. But in the past year they've captured the hearts and minds of many developers for building and running applications. Containers isolate specific code, applications or processes. Doing so gives whatever is inside the container a neat envelope for managing it, including moving it across various hosts. Whereas you can think of a virtual machine slicing up a server into multiple operating systems, containers run atop the OS so unlike a VM, they don't require an OS to boot up when they're created. In essence they can virtualize an operating system to provide a more lightweight package of an application compared to a VM.
Cantrill says that means it's best to run containers on bare metal servers, meaning one that does not have a hypervisor and virtual machines. "VMs (virtual machines) just don't make sense in a container world," he says, noting that Joyent has built its SmartOS operating system that powers it cloud on containers.
So will the rise of containers kill the VM
"I don't think Bryan is alone in thinking that," says Jay Lyman of the 451 Research Group. But, Lyman's not quite ready to declare VMs dead. "The reality is that VMs are part and parcel of enterprise IT today and nothing will be replacing them or killing them off anytime soon."
Instead, containers are good in some situations, but they're not a panacea. "You have to think of containers as another weapon in the arsenal of cloud developers," says David Linthicum, a respected industry pundit and consultant at Cloud Technology Partners. "They fit well in some situations, but not all."
Determining where and when to use containers may be the big question then.
A natural fit
For Macreery of Aptible, containers were a natural fit for his company's hosting platform for sensitive health care data. The company, which started in 2013 and made its product generally available a year later, uses Amazon Web Services' Elastic Compute Cloud (EC2) service, and runs Docker container images on top of those cloud-based virtual machines. Because the company deals with sensitive healthcare information, Aptible creates a separate virtual private cloud (VPC) running containers for each customer.
Containers allow significantly easier management compared to if Aptible was just using virtual machines. For one, containers provide consistent design architecture for all the data Aptible manages -- everything is stored in containers. If customers or Aptible need to update anything then a new container is created and launched, which takes less than a second. VMs, on the other hand, can take up to a minute to boot up. The flexibility of containers is another benefit: Aptible is able to spread multiple containers over a single virtual machine, or spread a large container over multiple VMs, if needed. The point though is that it's much easier for Aptible to manage its service when all of the data and apps look the same, because they're packaged neatly into containers. They act as a least common denominator.
That architecture works well for Aptible, but having consistent services may not be a reality for everyone. Gartner analyst Lydia Leong says even with the rise of containers, users with heterogeneous environments that include multiple operating systems and different security controls will likely still use a VM-focused architecture. Containers need to all run on the same OS and can't be mixed between Linux and Windows, for example. But, there's no reason why a large enterprise environment could have a mix of virtualized servers, bare-metal physical hosts with containers mixed into both.
Getting started
So how do you get started with containers Vendors in the cloud and virtualization market have jumped on containers in a big way. Docker, which is an open source project for spinning up containers and the name of a company, has been central to the container movement recently. Other open source projects like Google's Kubernetes, help manage multiple containers and are gaining popularity as well.
Take Amazon Web Services, the market-leading IaaS company last fall announced the Amazon Elastic Container Service (ECS), and just this month the company made it generally available. After an AWS customer spins up a container, ECS will take care of scaling them and providing a central management portal for keeping track of them.
Microsoft this month released a new "nano" operating system that will support containers running on Windows OS (read more about Windows Server Container here.)
Expect other companies to come out for support of containers too. VMware, for example is the predominant purveyor of virtualization software and has announced initial commitment to supporting containers. Mathew Lodge, one of the company's cloud executives, says that running containers inside a VM allows users to maintain the security and management controls they are used to while using the new technology. Running containers directly on bare metal would require the provisioning of network and security connections, which the VM can handle in a management system like its software.