Docker and VMWare
blog.docker.com
blog.docker.com
Looking at their docs (https://docs.docker.com/installation/windows/) their idea of "running on windows" is "running in a virtualbox linux vm, on windows".
That really rubs me the wrong way and I'm surprised that the HN community lets it slide.
It's talking about being able to use the same container technology on a "choice of deployment from laptops to bare metal to VMs to private and public clouds."
Let's face it- Microsoft Windows is really just a legacy OS now... They either need to switch to a UNIX-derived kernel, which would allow for native docker support (amongst a million other advantages that come from sharing a sensible common infrastructure with other OSes) or they are headed for the dustbin of history pretty soon.
Lets be honest. How many people are deploying WebLogic on Docker? How about SAP? How about any large enterprise back office application at all?
You see, Windows Server serves an entirely different market. The kind of applications being deployed on OS level virtualisation just don't get deployed on Windows anyways. About as close as you are going to get are Java applications which even then are usually deployed on a point of abstraction like an application server. (At the end of the day RHEL is still much more common for big Java apps)
That is not to say that Windows would not benefit from some sort of OS level virtualisation, only that it means absolutely nothing that they don't have it right now (or even for a few years).
Windows Server will continue to dominate back office deployments ad infinitum.
As much as I dislike Windows, there is a whole world of "enterprise" software running on Windows that isn't going away. SQL Server and Active Directory come to mind as Microsoft products being heavily and actively invested in by the enterprise.
If you're in the Ruby/Python/Go/Docker/whatever echo chamber it's easy to miss the other echo chambers out there. There are tons of companies out there still making a decent living from developing and maintaining software in curiously tenacious tech like Delphi, FileMaker and MUMPS.
Right, those are the very definition of legacy software... so where is your disagreement with me?
The comment you're replying to didn't say it wasn't useful for the "average start-up with at most a couple of Rails apps" - it said it's less useful ("not nearly as much of a value-add") compared to a large enterprise.
When your entire environment runs on half a dozen VMs you have much less to gain by faster/easier provisioning then when you're running tens of thousands.
FTFY.
after an announced partnership between the major tech players and Docker.
I take it back and the more the merrier.
In my view one of the key reasons to do it is to use AWS or the like. Until they have full Docker support on bare metal that is.
P.S. There are other reasons, e.g. Docker makes it difficult to create a separate publicly visible network interface. But these I feel will go away soon as well.
… on a couple of microbenchmarks when you define “CPU” to mean “I/O”. Even if you ignore the question of whether KVM performance is the same as VMware's (hint: no), most of the the charts in that paper contradict such a broad statement.
In fact, the article says "KVM has much higher overhead, higher than 40% in all measured cases." - saying nothing of "VMware-like virtualization" or VMware ESXi at all.
While it's true that containerized "virtualization" traditionally has less overhead than a hypervisor like ESXi, the difference is increasingly small and in most environments negligible, especially considering the added features and flexibility of ESXi vs containers.
From my experience and tests, the performance difference between an app in a container running on bare metal vs the same app running in VMware has been insignificant, so to say that there is a 40% performance penalty is probably disingenuous.
http://googlecloudplatform.blogspot.com/2014/08/containers-v...
The ease of use of Docker and the ubiquitousness of Linux make for a disruptive combination.
The 'technically worse, but faster and cheaper' combination Docker offers compared to virtualization is exactly what The innovators dilemma talks about.
VirtualBox would only be a "threat" to Workstation/Fusion. Products like that make up a small part of VMware's revenue. Enterprise is where the money is (products like vSphere, ESX, NSX).
Simply put: people need transparency in dynamic, modern infrastructure and they don't get it from 'put me in the middle' commercial vendors. Nor does the complexity cost of the mystical one size fits all virtualization solution magically dissipate when marketers invoke the ancient spirits of enterprise requirements.
VirtualBox isn't better in anyway then VMWare - except it is cheaper. That isn't really enough on its own (and there are plenty of more viable competitor of zero cost is all that matters: Xen, KVM, etc etc).
OTOH, Docker is cheaper, faster, much less resource intensive, and less secure. That's disruptive, and much more difficult for VMWare to fight than another conventional virtualization competitor.
It's not clear that this is true. Until Hyper-V and XenServer came out, ESX was really the only supported x86 server hypervisor available.
Besides, it feels like the fad around paravirt is over. There's a fair argument that its original server-side popularity was mostly a hack around 'doze's crappy install/config procedure, and 'doze is dying off.
Now we're left with containers, KVM and VirtualBox... the desktop replacement of VMWare workstation being the final nail in the coffin for its dwindling userbase.
Docker, Inc. offers Docker-related products and services and is creating a network
of certified professional support, training, and services providers. We are
committed to keeping Docker open source under the Apache 2.0 license.
How about VMware Workstation?
So very surprised by this!
You might be thinking of https://news.ycombinator.com/item?id=8146536
Maybe it's true for now, but containers may be enough security in the future.
[0] http://googlecloudplatform.blogspot.ca/2014/08/containers-vm...
Docker has their use cases: lightweight! PaaS! incremental push! 12-factor apps!
VMs have their use cases: Strong isolation! online migration! completely portable! consolidation for traditional applications!
So no, Docker will probably live alongside, next to, holding hands with, traditional VM environments, in much the same way that J2EE apps coexist with Rails.
But, the other reason that VMware won't want to buy Docker is that over the long run, these technologies become increasingly commoditized. VMware's hypervisor was innovative when it first launched, and these days, you can argue that you can get much the same functionality from KVM or Hyper-V - or even in this case, LXC and Docker for a different set of use cases.
Instead, VMware needs to make money on their management tools. Ideally, those management tools will be managing VMware's hypervisor, but they can't be afford to be so choosy. So, instead, they want a "first among equals" relationship with various open source technologies so they can be in the mix in every environment, even those where they haven't sold their hypervisor.
That's why they won't buy Docker - they don't want to sell the platform, they want to manage everyone's platform.
(note: everything I said is my own opinion, not that of my employer. We are coop-etitors with VMware in some of our business, and hence, I've got a conflict of interest I feel obligated to disclose).
ps. Just to be clear, I think there is still a need for virtualization.
Isolation of one trusted application from another trusted application for ease of configuration? Or did you have other forms of isolation in mind?
This is not true at all. Docker fits a very, very specific use case, and is a very small subset of what we use VMs for. To enhance Docker to cover those cases you would eventually end up with VMs.
That said; there is a huge command line, shell and APIs available for power users, for people who want the next level of certification from VMware (VMware Certified Advanced Professional) you need to know how to do common GUI tasks via CLI and troubleshoot via CLI.
There is a surprising amount of tools under the hood, but if you want to compare it to something Linux based I'm going to speculate that it isn't as extensive.
If my colleagues are just misinformed, that's one thing, but I'm hearing this feedback from people I generally trust. I'd love to have a neutral opinion on the CLI toolset quality.
The PowerCLI stuff is way better. It has comprehensive coverage of everything the GUI does and conforms to Powershell conventions. In my experience it is lacking for nothing.
http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vcli....
ManagedObjectReference dcmor = cb.getServiceUtil().GetDecendentMoRef(null,"Datacenter",dcName);
AFAIK there are also lots of Perl examples floating around too, which may be nicer for the traditional admin.
I did a project in pyvmomi and I was very impressed with its flexibility.