> The idea of the integration is to make it easier, faster and more efficient to include Docker containers when developing applications with the Microsoft tool set. Docker CEO Scott Johnston says it’s a matter of giving developers a better experience.
What they actually mean is the opposite. They want to make Azure the easy choice when developing with Docker. They go on to say it can take hours or days to get the integration set up manually.
If Azure “just works” and the other clouds take days to get integrated, owning Docker would let them make Azure integration a priority while neglecting or sabotaging integration to other clouds. The gap gets bigger and Azure feels even more like the obvious choice if you want to get anything done.
IMO one of the major cloud vendors will buy Docker this year. Microsoft seems like the obvious choice right now.
> If Azure “just works” and the other clouds take days to get integrated, owning Docker would let them make Azure integration a priority while neglecting or sabotaging integration to other clouds. The gap gets bigger and Azure feels even more like the obvious choice if you want to get anything done.
Which is a playbook they've demonstrated as recently as last October, on Mover[1]. It used to allow you to migrate data between a whole host of sources and destinations, and the guides/help docs even still reference those capabilities. Microsoft acquired it and made it free, but have turned it into a one-way tool: the only supported destinations are now Azure, Sharepoint, and OneDrive.
> Docker is really cool! Everyone is talking about Docker!
Stupid MS. They should have known that they cannot think that anything developed outside MS is cool. We have a cult thing going here, and MS you are not invited!
> We at Microsoft like Docker, too! (But Docker obviously screws us pretty hard, since the whole ecosystem is built around the Linux kernel. Windows isn't great at this type of isolation.)
No, they are saying that OS virtualization is a necessity for Azure, and that they've adopted the Docker container format because it applies equally well to Linux, Windows or any other operating system. There is nothing inherent Linux about Docker, and there is certainly NOTHING tying it to the Linux kernel, contrary to your claim. But they should have known that they are not welcome in the cult, so they should have developed their own container format?
> We don't like being left out of the Docker container party, so we're going to create _two_ things that are Almost As Good As Docker Containers!
No - they are creating Docker containers for Windows which is equivalent to Docker containers for Linux, using the same format, the same API and allowing for existing tools to be used. Is that bad?
And they are also creating a specialized Virtual Machine capable of hosting a single container so that we can decide at deployment time whether we want a) higher density but less isolation or b) lower density but higher isolation. Which - to be honest - makes perfect sense, as that decision is mostly about trust of the environment in which you deploy and should not in any way affect how the container is developed and packed.
> (1) A new package format, "Windows Server Containers," that we're calling a container, even though it doesn't actually offer containment. Containers can mess with other containers.
They are called containers because it is Docker containers. Containers are a way to ship configured applications with minimal concern about the configuration of the host. They isolate your application from specifics on the host, including isolation from what else is running on the host.
The security concerns about containers (yes Linux containers as well) are well understood. Containers share the operating system, and thus there is a higher risk of cross-container contamination compared to virtual machines (VMs).
Contrary to your Linux cult view, security of (Linux) containers is not perfect. As Mark Russinovich points out, a simple privilege escalation (seen any of those lately, hmm?) could allow complete cross-container compromise.
Mark Russinovichs comments about trust of the environment makes perfect sense. Make sure you trust the containers running on your system. If you developed those yourself or obtained them from a trusted source - fine. If they are controlled by some less trusted entity, then assume that they - or someone who comprimises them - could be hostile and try to gain access to other containers.
> (2) The same old Windows Server virtual machines, but we're going to call them "Hyper-V Containers." Yeah, they're just VMs. Separate kernels in memory and all of that.
You misunderstand the point. Yes, the Hyper-V container is based on existing virtual machine technology. Nothing new there. The point is that you can use such a single-container VM as an alternative target at deployment time.
If you develop an application (say, a website) and package it as a container, you can deploy it to a container-aware OS. But if you are deploying it alongside untrusted containers, you'll want a higher degree of isolation, regardless of OS. That's where Hyper-V containers comes in.
> We know neither of these offer what you wanted. But good news! You can use the same container format for _both_ of these new almost-a-container systems.
Yikes.
It is exactly what a lot of us want. It may not be what the cult wants, but let's be honest here: Microsoft could never produce anything the cult would want.
Take a cue from Linus Torvalds and get a cure for your Microsoft hate disease. Containers are cool, and they offer great value, also on Windows. Be proud that a technology popularized on Linux also proliferated to Windows - that is if you had anything to do with.
> but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing
From the Google/Amazon/Microsoft POV, that's part of the point.
From the CoreOS/Docker POV, the fact that the container technology that the major cloud hosts support is going to define their market whether they participate or not is probably why they have an incentive to participate.
> It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker
Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform. From the advantage of also being one of the players defining the standard, and one of the key implementers of the basic software, which will give them an advantage in implementing management software.
> I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me
Sure, they want to seek differentiation. But they probably don't want differentiate themselves as "the vendor of the container technology that isn't backed by any of the major cloud hosts", when there is a container technology that is backed by those hosts.
> Microsoft is undoubtedly A containerization leader at this point
If that was remotely true then what product/service does Microsoft offer that is remotely comparable with Docker/Kubernetes and is neither Docker or Kubernetes?
> What is the motivation and benefit for running containers without docker?
I believe that Docker bet the company on the wrong business model. Therefore knowing that you can run containers without Docker can be desirable, as it gives you options in case Docker turns out to be not viable.
Docker made it easy to build and run containers from the command line. This technology was released at the right time and in the right place. And it got huge traction. Docker used this traction to get a very large amount of VC capital. Therefore they now need to show a very large return.
How do you go about achieving that large return? A common way to do this is to use one piece of technology that is popular as an anchor to lock customers into an entire stack. And then you monetize the stack, which is easier as it has higher value. The technology in this case is the container runtime, and the stack would be an full enterprise grade container orchestration system.
This strategy worked for others. Microsoft was a master in this. VMware as well, and so is Oracle. The reason I believe it will not work for Docker is:
1. The anchor technology is open source. Microsoft managed their lock-in via Windows, VMware via ESX, Oracle via their DB. It worked because those are proprietary. In the open source world you can just take Docker.
2. Even though the technology is open source, you can still try the ecosystem approach where you exploit certain network effects attached to your distribution of the code that protect you (e.g. vendor certifications). This is what worked for Red Hat. In my view it is unlikely to work for Docker. I don't think certifications are required as most container apps today are not vendor apps. And I would not know what else they could use.
3. For orchestration solution they are engineering against Google's Kubernetes. With all respect for Docker, this is going to be very hard as Google has a huge amount of experience in this area.
4. Due to Docker's need to protect their business model, there is no true community in the sense that there is an open exchange of ideas. The docker agenda prevails over technical decision making (like: should you have a docker daemon? Should Swarm be part of the Docker Engine?). Contrast that with Kubernetes which run in a very open manner by Google. This is why OpenStack got the traction, and why Eucalyptus and CloudStack died off. OpenStack had the most open community.
All of this can lead, IMHO, to a situation where Docker will not succeed in delivering Swarm as they see it. Kubernetes will become the default container orchestration system, and Docker is relegated to a small place in the stack. This situation would make it hard for Docker to justify their valuation.
> Google and Microsoft seem to have really started betting on Docker
I still remember the days when I learned docker for the first time and everything worked like magic. And I appreciate Docker for that.
However, I am not so sure if Google/Microsoft developers are happy with Docker nowadays. It was the best container runtime 3 years ago, but today I have much more pleasant experience with other runtimes like cri-o. I would say, the added abstraction layer of container runtime interface in Kubernetes is a sign, that they want to explore better solutions to replace docker.
> However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible.
That's great to hear as it means it has served its initial intended purpose.
We take it for granted now, but the mere concept of doing this so easily in 2014 was really exciting stuff, especially when the workflow of build->publish to N cloud services is measured in minutes/seconds not hours/days.
> My instinct is that people at MS are freaking out right now about Docker specifically.
All, right, why would you say "freaking out" specifically? MS has a habit of adopting good ideas from elsewhere, and I don't think containerisation is any exception. Maybe they see not supporting it as a strategic weakness, but shoring up strategic weaknesses is business as usual for any large company, not "freaking out". Throwing chairs is freaking out.
We know that .Net is rolling out containerisation features in 2015, including but not limited to docker integration. Going all in on any tech is an odd way to "freak out about it".
>I wonder why they haven't been bought out by Microsoft or Google, if nothing else then just for the talent.
Because they received an insane valuation years ago and probably aren't even worth break-even on their funding rounds. Google already has far more K8s knowledge internally than anyone at docker, so what would be their gain?
MS did try to buy them back in 2016 but Docker pulled an Jerry* Yang and said no [1]. I don't see why MS would bother at this point, they are also headed down the k8s path, and anything they needed from an expertise perspective they likely already received through their partnership agreement [2].
> Personally I have hard time understanding the benefits of running docker in public cloud, you still run a VM you still pay for that VM. It just one extra abstraction layer which increases complexity of your infrastructure and also reduces performance.
Simpler deployment and basically forcing "12-factor", as well as easier development environment setups. Nothing you can't achieve with other tooling, but it's nice to be able to guarantee that your dev environment is identical to your prod.
> I don't use Docker to deploy, because it's just a single executable file (and a bunch of templates, though I'm looking at embedding those). One of the reasons I'm reluctant to go down the Docker road is because it's going to add more time to my deployment.
Yeah, I don't advocate Docker for its own sake, but my organization deploys everything via Kubernetes because it's simpler than having a bespoke orchestration strategy/toolchain for each project, but if you're a one-project shop then containerization probably doesn't add a lot of value (although I still haven't figured out a streamlined, reliable way to provision/configure VMs).
> So, with Docker we now indiscriminately add an additional layer of complexity on top of existing applications regardless of the actual problems this might solve.
I agree that it adds an extra layer of complexity but it also provides a lot of things out of the box (like isolation, separation of concerns, platform agnostic deployments, reproducability and lot more) which makes the life of a developer so easy. If he wants to deploy his application, instead of SSHing into the server, installing the dependency, managing the lifecycle of his application. He just needs to dockerize his application and rest assured that it will run irrespective of the platform on which it is put to run as long as it has docker running.
I think what it boils down to is what you expect a tool to do and if it really solves some hard hitting problems you have with your development life and took away your nightmares then it is totally fine to invest in it and chill.
> Microsoft gave a big pile of cash to Docker to figure out how to make Windows based Docker images.
Actually Microsoft has been contributing quite a bit to the OCI (Open Container Initiative), as well as Docker. So they have been putting in the work. I'm not really partial to Microsoft, but they do have some good engineers that are working on free software.
Oh, you never wrote tooling and you dont have a jobbing engine? Well, that's the complaiing that you can't get an an Uber because you did not download an app. It is sort of funny because every single shop that is "oh containers!" either creates them manually ( slow and painfully ) or just uses random ones developers find.
> There is a reason containers exist and that every large cloud platform has adopted them, including Microsoft adding support in Windows.
It is the same reason why Whole Foods sells sushi: that's teh way to sell salmon for $85/lb to hipsters. Hipsters hate buying salmon for $22/lb but they love the rolls.
> Now they'll own the entire stack and have a great integration story for enterprises. Even though containers have been around 3+ year's in the form of docker, corporations still don't have a scooby on how to integrate their existing deployment and development workflows.
I second this. If its a legacy stack, enterprises struggle to fully containerize their apps and commit to deploying with a container orchestration layer like OpenShift or Kubernetes. IMHO, we need more enterprises to get over this barrier, than view it as a passion project by over eager devops' teams...
What they actually mean is the opposite. They want to make Azure the easy choice when developing with Docker. They go on to say it can take hours or days to get the integration set up manually.
If Azure “just works” and the other clouds take days to get integrated, owning Docker would let them make Azure integration a priority while neglecting or sabotaging integration to other clouds. The gap gets bigger and Azure feels even more like the obvious choice if you want to get anything done.
IMO one of the major cloud vendors will buy Docker this year. Microsoft seems like the obvious choice right now.
reply