Mike Coleman

To Use Physical Or To Use Virtual: That is the container deployment question

I have had a version of the following conversation more than a few times with community members trying to sort out where to run their containerized apps in production:

User: So, where should I run my containers? Bare metal or VM’s

Me: It’s not a question of “either / or” – that’s the beauty of Docker. That choice is based solely on what’s right for your application and business goals – physical or virtual, cloud or on premise. Mix and match as your application and business needs dictate (and change).

User: But, surely you have a recommendation.

Me: I’m going to give you the two word answer that nobody likes: It depends.

User: You’re right, I don’t like that answer.

Me: I kind of figured you wouldn’t, but it really is the right answer.

There are tough questions in the world of tech, and the answer “It depends” can often be a cop out. But in the case of where to run your containerized applications it really is the best answer because no two applications are exactly the same, and no two companies have exactly the same business needs.

Any IT decision is based on a myriad of variables: Performance, scalability, reliability, security, existing systems, current skillsets, and cost (to name just a few). When someone sets out to decide how to deploy a Docker-based application in production all of these things need to be considered.

Docker delivers on the promise of allowing you to deploy your applications seamlessly regardless of the underlying infrastructure. Bare metal or VM. Datacenter or public cloud. Heck, deploy your app on bare metal in your data center and on VMs across multiple cloud providers if that’s what is needed by your application or business.

The key here is that you’re not locked into any one option. You can easily move your app from one infrastructure to another. There is essentially zero friction.

But that freedom also makes the process of deciding where to run those apps seem more difficult than it really is. The answer is going to be influenced what you’re doing today, and what you might need to do in the future.

So while I can’t answer “Where should I run my app” outright, I can provide a list of things to consider when it comes time to make that decision.

I’m sure this list is far from complete, but hopefully it’s enough to start a conversation and get the gears turning

Latency: Applications with a low tolerance for latency are going to do better on physical. This something we see quite a bit in financial services (trading applications are prime example).

Capacity: VMs made their bones by optimizing system load. If your containerized app doesn’t consume all the capacity on a physical box, virtualization still offers a benefit here.

Mixed Workloads: Physical servers will run a single instance of an operating system. So, you if you wish to mix Windows and Linux containers on the same host, you’ll need to use virtualization

Disaster Recovery: Again, like capacity optimizations, one of the great benefits of VMs are advanced capabilities around site recovery and high availability. While these capabilities may exist with physical hosts, the are a wider array of options with virtualization.

Existing Investments and Automation Frameworks : A lot of the organizations have already built a comprehensive set of tools around things like infrastructure provisioning. Leveraging this existing investment and expertise makes a lot of sense when introducing new elements.

Multitenancy: Some customers have workloads that can’t share kernels. In this case VMs provide an extra layer of isolation compared to running containers on bare metal.

Resource Pools / Quotas:  Many virtualization solutions have a broad feature set to control how virtual machines use resources. Docker provides the concept of resource constraints, but for bare metal you’re kind of on your own.

Automation/APIs: Very few people in an organization typically have the ability to provision bare metal from an API. If the goal is automation you’ll want an API, and that will likely rule out bare metal.

Licensing Costs: Running directly on bare metal can reduce costs as you won’t need to purchase hypervisor licenses. And, of course, you may not even need to pay anything for the OS that hosts your containers.

There is something really powerful about being able to make a decision on where to run your app solely based on the technical merits of the platform AND being able to easily adjust that decision if new information comes to light.

In the end the question shouldn’t be “bare metal OR virtual” – the question is which infrastructure makes the most sense for my application needs and business goals. So mix and match to create the right answer today, and know with Docker you can quickly and easily respond to any changes in the future.

Read more by Mike Coleman in this series:

 

Check out these resources to start learning more about Docker and containers:

 


 

Learn More about Docker

, , ,

Mike Coleman

To Use Physical Or To Use Virtual: That is the container deployment question


One Response to “To Use Physical Or To Use Virtual: That is the container deployment question”

  1. Tindur

    1) Can docker engine be striped over multiple bare metal servers like the hypervisor can to create single shared pool of resources from all underlying metal servers?

    2) In a scenario where I have only one OS for all my apps, all apps would be containerised, but I wouldn't want to be orchestrating multiple VM's. Would it make sense to run my entire zone (e.g. app tier) in one big fat vm?

    Reply

Leave a Reply

Get the Latest Docker News by Email

Docker Weekly is a newsletter with the latest content on Docker and the agenda for the upcoming weeks.