Part 3: Docker vs hypervisor in tech tussle SMACKDOWN

We see you by the virty containers, VMware

Comment If you're willing to start from scratch, give up high availability, the ability to run multiple operating systems on a single server and all the other tradeoffs then Docker really can't be beaten. You are going to cram more workloads into a given piece of hardware with Docker than with a hypervisor, full stop.

From the perspective of a cloud provider – or an enterprise large enough to run like one – that's perfectly okay. Many of the workloads they run don't need have a lot of the fancier hypervisor-based goodies anyway. They use in-application clustering, or applications that have been recoded for public cloud computing.

You're not vMotioning around AWS, and given that it has taken VMware until about the middle of 2015 to get a production version of lock-step fault tolerance with more than one vCPU out the door, don't be expecting that on a non-VMware public cloud provider any time soon. (You can also bet VMware is going to charge a pretty penny for it.)

It's in the tech

Hypervisors are marvels of advanced infrastructure with tools, techniques and capabilities that containers like Docker may never be able to match. How, exactly, do you move a containerised workload between servers with dramatically different kernel versions or different hardware without adding a hypervisor-like layer of abstractions?

How will containers scale over time as the existing generation of servers live side-by-side with the next and workloads get transitioned? There are a lot of unanswered questions, and it will be years before we're sure how containers will fit in the overall technology puzzle.

The flip side is that Docker is in a lot of ways more responsive to customer needs than most hypervisors out there. Not only are the core developers still passionate about "their baby", but the community that has sprung up around it borders on evangelically religious. There is no end of energy for all things Docker, and those with the energy are among the brightest minds we've ever produced.

Docker is easy to use, though not because of management tools, APIs, documentation or slick marketing. Docker is easy to use because the sorts of workloads you want to run on Docker come as a push-button-simple deployment from an "app-store" like interface.

Some of these "app packages" are officially supported. Most are community driven. But they are easy to find, easier to use and easy to repackage into a template and go from your single testbed to a cloud of thousands of instances.

Hypervisor vendors can be reasonably viewed as being obsessed with providing the most flexible and resilient infrastructure possible. To contrast, Docker is the evolution of an obsession with not wanting to manage or maintain infrastructure, but instead to get on with the business of actually using that infrastructure to do something useful.

Containers will ultimately be used in tandem with traditional hypervisors and even public cloud services, forming a new(ish) basic service offering to the masses and allowing us to do something we've done for some time that little better.

And versus or

Make no mistake, however, like the public cloud before them, containers are an "and", not an "or" technology. Hypervisors were an "or" technology. Wherever hypervisors went, they massively displaced bare-metal computers and rendered then endangered, if not extinct. Containers are not – I repeat emphatically not - that disruptive.

Docker may be snapped up by a tech titan. Given VMware's interest in the company, it may well find a home inside VMware. Similarly, containers may ultimately be (or, in my experience, rather frequently are) deployed inside hypervisors.

This lets administrators use the hypervisor underneath to achieve the sorts of underlying infrastructure wizardry at which hypervisors have excelled, while putting some or all workloads that require a similar environment into a single VM as a means of boosting efficiency. A compromise, if you will.

Containers may end up deployed on some metal servers for certain classes of workloads while others live on hypervisors for decades to come. Right now, there's just no way to know exactly how it will play out. *

Personally, I expect it will be different for each organisation. Containers offer us the ability to make choices about risk versus efficiency. Hypervisors help us deal with risk: the risk of cramming so many workloads into a single system, the risk of a system failure, or of needing fully fault tolerant capabilities.

Hypervisors help us deal with the realities of heterogeneous environments and the fact that not everything is a web-based workload, or ready to be recoded for "scale".

30-year old software still runs in many of the world's organisations today, and there's absolutely no reason to expect the same won't be true 30 years from now. Hypervisors give us the ability to deal with that in a way that containers never will. ®

* If history is any guide VMware probably has a skunkworks operation working on building a Docker competitor directly into the hypervisor right now. VMware doesn't do "partnership" in these areas for particularly long before it either buys up a relevant company or rolls its own version. These spats can get particularly nasty.

Microsoft's rapid acceptance of Docker has muddied the crystal ball a bit, and made the pressure on VMware all the more intense. ®

Want more?

Read part 1, 2 and the final instalment of this four-part series:

Part 1

Part 2

Part 4

Other stories you might like

  • US won’t prosecute ‘good faith’ security researchers under CFAA
    Well, that clears things up? Maybe not.

    The US Justice Department has directed prosecutors not to charge "good-faith security researchers" with violating the Computer Fraud and Abuse Act (CFAA) if their reasons for hacking are ethical — things like bug hunting, responsible vulnerability disclosure, or above-board penetration testing.

    Good-faith, according to the policy [PDF], means using a computer "solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability."

    Additionally, this activity must be "carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services."

    Continue reading
  • Intel plans immersion lab to chill its power-hungry chips
    AI chips are sucking down 600W+ and the solution could be to drown them.

    Intel this week unveiled a $700 million sustainability initiative to try innovative liquid and immersion cooling technologies to the datacenter.

    The project will see Intel construct a 200,000-square-foot "mega lab" approximately 20 miles west of Portland at its Hillsboro campus, where the chipmaker will qualify, test, and demo its expansive — and power hungry — datacenter portfolio using a variety of cooling tech.

    Alongside the lab, the x86 giant unveiled an open reference design for immersion cooling systems for its chips that is being developed by Intel Taiwan. The chip giant is hoping to bring other Taiwanese manufacturers into the fold and it'll then be rolled out globally.

    Continue reading
  • US recovers a record $15m from the 3ve ad-fraud crew
    Swiss banks cough up around half of the proceeds of crime

    The US government has recovered over $15 million in proceeds from the 3ve digital advertising fraud operation that cost businesses more than $29 million for ads that were never viewed.

    "This forfeiture is the largest international cybercrime recovery in the history of the Eastern District of New York," US Attorney Breon Peace said in a statement

    The action, Peace added, "sends a powerful message to those involved in cyber fraud that there are no boundaries to prosecuting these bad actors and locating their ill-gotten assets wherever they are in the world."

    Continue reading

Biting the hand that feeds IT © 1998–2022