Evaluate the Mesos architecture for massive container deployments
In addition to supporting large-scale IT deployments, Mesos takes a unique approach to data center and cloud resource pools that can benefit both containerized and noncontainerized apps.
Kubernetes is in the container spotlight, but Apache Mesos and its associated tools underpin many of the largest and most complex enterprise deployments. Consider the Apache Mesos architecture early on for a major container deployment -- a switch from one set of tools to the other is messy.
If it aligns with long-term requirements, adopt Mesos instead of Kubernetes or other options for complex, distributed IT deployments.
Editor's note:Apache Mesos, an open source cluster manager, forms the basis for Mesosphere DC/OS, a commercial product. The Mesos architecture, as a distributed systems kernel, is reminiscent of the Linux kernel. Mesosphere DC/OS works with the container orchestrator Marathon but isn't exclusive. Kubernetes distributions compete with Mesos and Mesosphere, but Mesosphere also offers a Kubernetes-as-a-service option in DC/OS. Therefore, Mesosphere users can deploy Kubernetes clusters. DC/OS, available in standard and enterprise versions, is sold based on node count, and the company offers two support packages.
The Mesos approach to container orchestration
Most container orchestration tools rely on a master/agent structure. Each resource has an agent process -- controlled by the master -- that manages how containerized applications deploy, fail and scale. Admins can tune each agent process to a specific hosting environment through a plugin that adapts orchestrators to the required APIs.
App deployment must take resource demands into account, which means the orchestrator must have the hosting framework's details. In Kubernetes container orchestration, clusters and replica sets facilitate resource management, but resources remain tightly coupled to the orchestrator.
Mesos takes a different approach. There are still agents and masters, but the Mesos architecture creates a two-layered structure. The bottom layer is Mesos, including Mesosphere DC/OS, and abstracts all hosting resources into a single model or API set. This abstraction includes a virtual overlay network that's fully integrated and scalable. The top layer -- orchestration -- manipulates the bottom layer. Mesos orchestration can occur through Marathon or Kubernetes.
Benefits of Mesos
These two independent layers represent one of the most compelling benefits of the Mesos architecture. The bottom layer hides the complexity of resource pools based on different technologies and cloud providers. This means orchestration at the top layer doesn't need to consider those issues at all; a change to the resource pool's location or the addition of a new cloud platform or data center doesn't significantly alter the orchestration process.
Applications can be modeled in the abstract, decoupled from resources, and vice versa. Mesos abstracts resources, including hosts and databases, as well as other application services, from any source, which enables it to then group or collocate resources for optimal performance -- without added orchestration complexity.
Enterprises that can't commit all their applications to containers can use this same orchestration tool across a deployment, including hybrid workloads that span the data center and external cloud providers -- an operations benefit.
This separation of application and resource orchestration also supports application-aware scheduling. This term, often used with Mesos, means that every application can be scheduled, orchestrated and managed based on its particular requirements. The resource structure and orchestration processes are insulated from resource locations, and a workbooklike configuration description contains everything Mesos or Marathon needs to deploy and manage applications -- whether they're stateful or stateless.
But the Mesos architecture isn't limited to containers. Enterprises that can't commit all their applications to containers can use this same orchestration tool across a deployment, including hybrid workloads that span the data center and external cloud providers -- an operations benefit.
Mesos can also run at enormous scale. Most of the web-scale companies, such as Facebook and Twitter, have abandoned proprietary hosting and orchestration software for Mesos, as it can scale applications and resources independently of each other to a global scope. Operations practices also scale appropriately alongside the deployment, without nonstop changes to make them work.
Marathon vs. Kubernetes
Unlike Kubernetes, the Mesos-centric orchestration service -- Marathon -- eliminates all resource-layer scalability and redeployment issues. This is because Mesos creates a uniform framework for hosting, so scaling and redeployment occur independently of the resources they use. With Kubernetes, integration is required to respond to the full range of resource or application conditions. While it's possible to use Kubernetes with Mesos, don't let orchestration-specific strategies creep into a container deployment, because that would defeat Mesos' abstraction benefits.
Kubernetes will still be the preferred option for many enterprises. It's widely adopted, well-understood and rapidly gains Mesos-like capabilities through additional open source project work. Also, integration between Kubernetes and managed Kubernetes services in the public cloud gets stronger every day. For average-scale deployments, don't rule Kubernetes out.
That said, large container deployments need resource abstraction. Operations teams with no plans to use Mesos and Marathon need to look at control plane and resource abstraction extensions to Kubernetes. An independent virtual network overlay that manages addressing and routing through the entire resource pool is particularly important. Otherwise, there's a risk of network addressing problems at scale and as deployments spin up and down in the real world.
