Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why Bare Metal Is Challenging VMs in Microservices Deployments

DZone's Guide to

Why Bare Metal Is Challenging VMs in Microservices Deployments

We talked to Jeff Chou, CEO of container infrastructure company Diamanti, about VM-based containers reducing utilization and efficiency.

· Microservices Zone ·
Free Resource

Learn why microservices are breaking traditional APM tools that were built for monoliths.

Jeff Chou is CEO of Diamanti, a company focused on container infrastructure, with a founding executive team out of Cisco and Veritas. Over the past 15 years, server virtualization has become the preferred method of application deployment in the enterprise datacenter. Popular hypervisors, such as VMware ESXi and Microsoft Hyper-V, are ubiquitous. Diamanti’s CEO sees microservices and containers pushing the market towards bare metal and shares his vision for how that will transform enterprise infrastructure and the implications for VMs.

Let’s start with your take on the overall threat to virtual machines and VMware, posed by containers and microservices?

In some ways the threat of containers to virtual machines is like asking how worried the train industry should have been when the airline industry was born. You’re always going to have trains for some jobs because airlines don’t solve everything, and that’s how I see the relationship between containers and virtual machines. But containers will also take away some of VM market share, just as airplanes attracted passenger transportation and limited the upside of trains. Right now VMware is trying to protect its turf by convincing people to run containers on a hypervisor -- which makes about as much sense as running an airplane on top of a train.

Talk about those early enterprise container deployments you are seeing that are attempting to run containers on top of virtual machines.

Many of the first movers on containers have attempted to run them on legacy virtual machine infrastructure. It’s very awkward and doesn’t scale cleanly. It’s totally understandable why anyone would want to leverage existing assets and know-how to support the most interesting new wave of developer innovation of the decade -- containers and microservices. But VMs are not the answer.

As a starting point, many open source, distributed computing frameworks, big data frameworks and even the hottest distributed databases were not designed to run in a virtualized environment. Many of them were designed to run on bare metal, containerized. In fact, it’s not good if you run on them on virtual machines.

More broadly, the benefits of bare metal compared to virtual machines I think is an education process that’s still in its infancy. While containers and microservices are becoming common fare according to almost every recent survey, what we’re seeing is that it’s the much smaller slice of that pie who are getting to the production deployments and learning the hard way that the economics and performance obstacles of virtual machines do not play well with the applications constructed as microservices running in containers.

Explain some of those challenges.

Well for starters, when you deploy containers on top of an existing virtual environment, you are layering one form of virtualization on another, and typically the team using the container environment is different than the team that manages the virtual machine assets -- so you always have that developer-operations loop to resolve, and unnecessary obstacles in deployment cycles. That does not play well with the modern continuous development, CI/CD best practice approach.

Performance-wise, VM-based containers reduce utilization and efficiency. They have much lower density. Containers running inside of a VM contend for its CPU, memory and I/O resources, and that “noisy neighbor” problem drives customers to solve it by running just one container per VM.

And of course, the licensing costs associated with virtual machines and the entire stack of providers that have their fingers in that pie. The ‘V’ Tax is already a major burden on enterprise IT budgets, and one of the goals of containers from my point of view is not just developer agility. For many enterprises, it’s also a path to more open source consumption and more freedom of choice throughout the stack.

What do you think is holding back enterprises from adopting more bare metal?

As container and microservices adoption has grown and enterprises have seen increasingly challenging infrastructure problems related to supporting containers, I think more of the ecosystem is naturally making its way to bare metal, because they see consensus in the ecosystem that running containers on bare metal is the ideal model.

I think there’s an interesting point to be made when you consider the origins of VMware versus the origins of containers and microservices. Each approached the opportunity from different angles. For VMware, it was never about the application, it was about the infrastructure - and they had a long run of proprietary and uncontested control of that management stack. But for containers, the target of the movement was all about the application. The container infrastructure and management stack have had many different players and influences in its early evolution--because it is an open source evolution. Mainstream enterprises do not have the system resource engineering armies of the web-scale early adopters of containers, and they await more mature tooling and support that allows them to consider bare metal, and that’s the audience that Diamanti is addressing as we build out the next generation of infrastructure that’s specifically for running containers and microservices architecture-based applications on bare metal.

Record growth in microservices is disrupting the operational landscape. Read the Global Microservices Trends report to learn more.

Topics:
microservices ,containers ,vmware ,software architecture ,virtual machines

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}