When your product is dubbed the DC/OS, as in the data center operating system, it may seem like a rather bold statement. DC/OS has the potential to really hit the mark in a number of ways in achieving this in my opinion. Through this little miniseries of posts we will take a look at the DC/OS platform, and walk through a real deployment and usage on a couple of different underlying platforms.
The Basics of Apache Mesos
Apache Mesos is an open source project which was built to become a distributed systems kernel which would be deployed across multiple nodes, and can be consumed through a common abstraction for allowing scheduling, and resource management. All done via open APIs, and across multiple underlying infrastructure platforms.
In other words, the goal is to become an application-oriented operating system which can leverage scalable physical and cloud environments.
Why DC/OS over Mesos?
Mesosphere is both a company, and an Enterprise platform which has an open source version available via DC/OS. The additional layer which resides on top of the Mesos core is what adds the real value. It is much more than just another layer. It is designed to provide additional management features which leverage the Mesos architecture, including a GUI management, monitoring, logging, and some additional security capabilities.
The decision to present DC/OS as a commercial offering was a positive step to embracing the platform under a supported deployment structure, but saw much more growth in recent months now as the launch of the fully open source edition of DC/OS was launched. This launch was paired with the announcement of a powerful partner ecosystem that included the likes of Microsoft, Cisco, HPE, NetApp and more. The list is a veritable eye chart when trying to post it, so it’s best to view it directly over at the Mesosphere community page to see who the growing list of supporters are.
The open source platform born from these initiatives can be found on GitHub and is has definitely become a popular environment as the industry looks to the future. There is a great potential for a truly infrastructure-agnostic and scalable operating system for applications and containers could be launched and managed.
What Runs on DC/OS?
The most common use-cases to date have been containers and Big Data platforms, such as Docker, Hadoop, Spark, Cassandra, and more. The list will continue to grow as we see the evolution of the platform. When you open the doors to containers, it suddenly moves the question of “what runs on DC/OS?” to “What are the limitations?” which is something we will dive into fully in an upcoming post.
As always, it is as important to know what can run, as well as what may not be entirely appropriate to run because of potential pitfalls and challenges. At this point, we are concentrating on the two very important use-cases which includes the Big Data story, and the container story.
It is quite possible to run other “traditional” workloads in DC/OS if encapsulated into containers, but that raises the usual question. of what are the real appropriate uses for a containerized hosting platform. Container environments are geared towards creating distributed networking, security, and orchestration capability on top of the underlying OS.
Now that we have a sense on what we can run, there is another big question.
Where do I run DC/OS?
When we talk about infrastructure-agnostic, the truth is found when a real cross-cloud and cross-OS set of deployment options are available. As you can see from this point in time snapshot, there are a few ways to get your DC/OS environment up and cooking:
There are a few different deployment models that we will map out to illustrate how to create and consume Mesosphere DC/OS environments both on-premises and in the cloud. This should help to give you a taste of ways that you can begin looking at this platform as a potential part of your IT portfolio.
DC/OS Architecture in a Nutshell
Think of DC/OS as a client, which requests resources from a scheduler, which submits the request to the Mesos Master, which replies with a resource offer based on what is available to provide the resources to service the task. The client will then create a Marathon app request to the Mesos Master, which submits to the Agent to locate the target environment, and the Executor launches the task itself.
Confused yet? Don’t worry. It’s like evaluating the cycle of an engine turning over by tracing the intake, compression, ignition, exhaust cycle of engine cylinders.
The environment looks best in pictures, so we will illustrate that in a little more detail in our next post. And with that, our next step will also be to deploy it and see just what DC/OS looks like in action. Join us for our next post as we get DC/OS on AWS deployed and spin up our first containers to see just how it all works.