Microsoft Launches Azure Container Service with Mesosphere DCOS, Drawing its Distinction with Google
If Google’s Container Engine will be characterized by the presence of the Kubernetes orchestration platform, Microsoft’s container engine will be identifiable by the presence of Mesosphere DCOS. In a joint announcement Tuesday at an all-new, Azure-focused convention called AzureCon, Microsoft and Mesosphere said they are extending their partnership in such a way that DCOS, the dazzling orchestrator built atop Apache Mesos, will be a preferred orchestrator made available on the new Azure Container Service.
“This is the ability for customers to bring containerized applications and deploy them into Azure, with just a few clicks setting up their cluster,” states Microsoft’s Azure CTO Mark Russinovich, speaking with The New Stack.
“We partnered with Mesosphere to build that container service on top of Mesos and the open source parts of DCOS … We felt this was an awesome partnership we could enable here, by extending out Container Service onto something open, rather than building it on proprietary technology.”
The Many-Worlds Hypothesis
DCOS will not be the default option for managing container workloads on Azure’s new service. But as Russinovich tells The New Stack, there will be no such default option. (Just a reminder to our readers that this is Microsoft we’re talking to.)
“In this initial release of the Container Service, we’re agnostic about the way that management of the deployment of those applications onto the cluster happens,” says the Azure CTO. “Different people will build different solutions, and one of the possibilities is that they’ll use something like DCOS layered on top of it. Another is that they’ll use some continuous integration/continuous deployment pipeline through Visual Studio to deploy applications to the cluster, in a more DevOps-oriented world. Then you’re probably still going to have locked-down, vigorous IT scenarios where some IT administrators are deciding what gets deployed and managing things, disconnected from the developers.
“I think you’re going to see the full spectrum,” he continues. “One of the benefits of us building on top of Mesos is that the ecosystem is building up to support all of these different cases.”
It’s an agnosticism that developers, especially from the Linux side, will not immediately associate with Microsoft. At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.
When Windows Server was still perceived as having at least a toehold on data centers’ infrastructure, Microsoft helped cement IT-driven deployment as a best practice. It produced application deployment systems exclusively for admins, and hard-wired those systems into System Center, its main admin toolkit. The proper workflow between devs and admins was baked into the company’s team integration tools, whose very names implied the difficulty of their relationship: for instance, System Center Management Pack for Microsoft Visual Studio Team Foundation Server 2010 Work Item Synchronization.
In the modern world, a competitive cloud service provider has no choice but to offer container deployment. This means addressing developers and giving at least the hope of deployment control to them.
Microsoft will stay out of the political end of this for now, embracing and extending its new corporate philosophy. But what about Mesosphere, which has already proven itself to be a champion of developer-centered deployment?
“It’s really going to depend on how the organization really wants to run their containers,” says Ben Hindman, Mesosphere’s founder and Apache Mesos’ creator, also speaking with The New Stack. “There could be an administrator who’s taking in people’s containers, and using the interfaces in DCOS for launching those containers; or it could be something like Jenkins, or some other kind of continuous integration setup, possibly connected directly from Visual Studio. DCOS is not going to be so opinionated that it forces an organization to deploy it in one way or another. It’s just going to make those deployment strategies be as streamlined as possible.”
Regrouping
Now that there are more options than ever before for rapidly deploying scalable containerized systems to public clouds, are we likely to see a change in how containerized workloads are designed? Hindman believes the major architectural changes that needed to have happened, have already happened.
“In the Linux world, if you were writing a LAMP stack application, the expectation was that you had Apache and MySQL on the exact same machine, and you’ve coded them up in that way, you’re better off breaking up the application. Even at Twitter, the application was a monolithic application, but it was for Linux, and we still had to spend a lot of time breaking that up into microservices. So that mentality applies from both perspectives [Windows and Linux]; it’s really about how you think about architecting the app.
“With microservices architecture, it will be the case that there will be different components, some written for Linux and some for Windows, and they will still be communicating and talking together,” Hindman continues.
“That’s the whole premise of the microservices architecture: You can break up the pieces into these communicating components, and you can focus on the right technology to solve the job, but then you need a way to deploy all these apps and enable them to communicate together.”
“The education, I think, is on defining those interfaces, and understanding how you want to break up the components. Our job, once you’ve written a component, [is to ensure] you can run those things as efficiently and effectively as possible. That’s where Azure Container Service and Apache Mesos and Mesosphere really come together.”
Feature image: “Keep going, you’re almost there” by Christopher Michel is licensed under CC BY 2.0.
