In a clear move for the very center of the container/workload orchestration market to which Kubernetes has recently been attempting to stake its claim, Mesosphere announced on Tuesday that its commercial version 1.9 release of its Data Center Operating System (DC/OS) would include two unabashedly competitive features. One is support for a kind of self-administered server clustering called pods.
The second is an eye-opening open source services market, available from a console directly inside DC/OS, called the Universe Service Catalog. Think of the Universe Service Catalog [pictured above] as a direct connection to Mesosphere’s idea of a stack, which would include persistent data services, as well as CI/CD platforms including Jenkins.
“If you look at what’s happening with other platforms — especially with public cloud providers — everyone’s making open source accessible, but they’re doing it on their terms,” said Peter Guagenti, Mesosphere’s chief marketing officer, in a conversation with The New Stack. “What happens a lot inside of public cloud is, they’re taking open source and calling it something else with their name on it, but it’s still open source behind the scenes.
“Whereas, what we’re trying to do here is expose the ecosystem,” Guagenti continued. “If you really look, the combination of public and private cloud infrastructure with open source, has really been the root of the explosion of innovation that we’ve had over the last ten years… So it’s not just being able to get access to these projects. It’s being able to get access to these companies.”
In recent weeks, the Cloud Native Computing Foundation — originally founded around Kubernetes — has been making good on its 2015 pledge to nurture the development of a cohesive stack around scalable services delivery. Now Mesosphere is making a counter-argument that more established firms may be in a better position to present a robust services stack than a group of startups and that all enterprises need to get on board with the stack are a good word of introduction.
Ed Hsu, Mesosphere vice president of product marketing, tells us a story about how, during recent developer conferences, he asks attendees whether they’ve used Spark, Cassandra, or Kafka. Most everyone raises a hand. Then he shows a video clip of one of these data services being installed through DC/OS’ new portal using a “one-click” process.
“I ask the room, was your experience installing those services like this? And I always get a huge laugh,” said Hsu. “Because for most developers who know these technologies, it is hard to get these things up and running. And they’re not even getting them running on the same clusters; they’re running in separate clusters, because these distributed systems were never designed to pool with each other.”
The inclusion of a kind of “apps market” may make DC/OS more feature-comparable to cloud-based container staging environments like Amazon’s EC2 Container Service. Hsu and Guagenti acknowledged that Mesosphere has an interest in appealing to more Fortune 1000-class customers; and with each of them, it’s usually the CIO — whose opinion is more easily swayed by photographs than code samples — who makes purchasing decisions.
Up to now, Mesosphere’s Marathon scheduler (which is now part of DC/OS) has utilized a concept called a service group. This has been a way to wrap a namespace around a group of services so that a policy engine can control access to services on a per-user level. Its rather general name, though, implied it could be used for much more.
Beginning with version 1.9, DC/OS is leveraging this concept to enable pods — groupings of related containers that share resources. In this case, they’re the resources controlled by the service group designation.
“Pods do not replace service groups,” explains a company blog post Tuesday. “They add another abstraction for deploying applications that can also be used within a service group. So now you [have] the flexibility of building a service group that consists of single container application and a multi-container pod at the same time.”
A future archeologist, parsing Mesosphere’s choice of language in its documentation alone, may conclude it was the sole inventor of the pod concept. No one today is under that impression, and certainly Mesosphere’s representatives aren’t making any pretenses.
Still, the blog post goes on to explain DC/OS pods may be used as sidecars, or packages of services that containerized applications tend to use frequently, such as message queue clients and SSL encryption. The concept came to fruition a few years ago in the Kubernetes realm, for exactly the same purpose, and it’s been called into question a few times for running contrary to the end goal of distributed systems: for replicating and attaching services rather than distributing them and managing their communication.
But the Mesosphere post reveals an important point: If organizations are to adopt distributed systems environments at all, they’ll need a way to bring along the monolithic, client/server applications from the previous era. And they’ll expect their necessary resources to be attached nearby, just as though they were all being shipped on ancient 200MB hard drives.
I asked Ed Hsu whether DC/OS’ pods will feature a similar kind of delegated agent system as Kubernetes, which utilizes kubelets as agents that are responsible for managing the status of containers within their respective pods. His response suggests that Mesosphere does not believe that such a system of delegation is in keeping with the architecture of DC/OS. . . for now. There will be a line of communications with DC/OS pods, established by way of the DC/OS API.
Never in the history of computing has an entire market assembled together around any single vendor or any single platform… willingly. With distributed systems dominated by open source, even the appearance of platform domination is frowned upon, especially by the dominant platform. So it should be no surprise to anyone that in this market, a plurality of alternatives have taken shape.