Mesos, Yet Another Cloud OS?
Mesos, Yet Another Cloud OS?
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
YARN stands for Yet Another Resource Negotiator. According to Hortonworks, it is “the architectural center of Hadoop.” YARN is the stack layer that allows multiple processing engines, with varying workloads (streaming, SQL, batch, machine learning etc.) to run on top of the Hadoop file system, HDFS.
Before YARN there was another resource negotiator, Mesos
(Hence the “yet another” in YARN)
Is Mesos yet another cloud OS?
In fairness to Mesosphere, their marketing doesn’t stray into the hyperbole of calling Mesos a Cloud OS (maybe a data center OS or a distributed systems OS). This makes sense because it would probably confuse people. However, they do talk about running your infrastructure “like one big computer” and running distributed applications “as if they were apps being launched on a laptop.” It seems clear this is a hugely ambitious endeavor by a company who have the vision to match.
In the past I’ve compared the hype around Docker Inc. to the fuss in 2012 around the billion-dollar acquisition of Nicira by VMware.
Now it seems clear that Mesosphere is a better candidate to wear the Nicira Most Disruptive Startup crown.
If Mesos is for resource scheduling across a cluster – how does this lead to the OS analogy?
The answer starts with the description on the Apache Mesos site, where Mesos is described as a distributed systems kernel, drawing parallels to the Linux kernel (in the same way that the Linux kernel gets confused with GNU/Linux OS). Running on this kernel is a set of frameworks (daemons or services in the OS-world) that allow people to build applications. These include Marathon (distributed init), Chronos (distributed cron), and Hadoop (distributed file system).
The kernel analogy makes more sense when you view Mesos as abstracting “CPU, memory, storage and other compute resources away from machines (physical or virtual).”
The architecture is shown above, so I won’t repeat the description of how this works in terms of masters, slaves, schedulers etc. The diagram is lifted from the Apache project site with has a pretty clear description (which you can see here).
The concept of resource offers is the key to the architecture’s efficiency.
By allowing the frameworks to decide which resources to consume – subject to a plugin module in the master that defines the policy for applying (fair-sharing, Dominant Resource Fairness as per the DRF paper etc.) – multiple frameworks can compete for cluster resources.
In my next blog post I will focus on how to write a framework, including the role of the scheduler, executor, and how they are both implemented.
There is a ton we can cover in this area. In future posts I’ll dive into Google’s Kubernetes (with it’s promise of “elastic distributed microservices”) and why the Mesosphere team were so quick to ensure it was seen as being part of the Mesos ecosystem rather than a competing framework (embrace and extend maybe?).
I’d also like to why Mesosphere is working so closely with a customer like HubSpot but don’t seem to have embraced Singularity (at least not yet). Along the way we’ll move from the 20,000 ft view and get stuck in the weeds: we’ll explore isolation with LXC vs lmctfy, how to go about securing access to your cluster, how to write Mesos frameworks, and of course we need to look into how you make Singularity’s log watcher play well with Logentries!
Published at DZone with permission of Trevor Parsons , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.