最近，有一个叫 Marathon的项目进行了开源，它的设计宗旨就是让用户在同一组服务器之上，更智能地运行多种应用程序和服务——Hadoop、Storm，甚至一个标准的Web应用。Marathon出自于一家初创公司 Mesosphere之手，这家公司主要就是想构建一个数据中心操作系统，不过这个系统是运行在 Mesos集群管理软件之上，这也是 Twitter基础设施的重要组成部分。该公司的联合创始人是前Airbnb的工程师Florian Leibert（也曾在Twitter工作过）和Tobias Knaup。
Marathon只不过占据了Mesosphere的一小部分，但是Leibert表示它很重要且有着非常大的吸引力。就目前而言，云计算和大数据的发展趋势已经从巩固阶段跳转到问题的解决阶段，未来可能需要多个分布式系统去处理那些特定的任务。
在阐述Marathon之前，我们应该了解一下它的发展历程：
网格计算将何去何从？
其实早在“云计算”的概念泛滥之前，像“网格计算”和“集群计算”这些专业术语与“请求式”联系的更紧密一些。思路也很简单：很多组织机构（比如银行和研究所）都有着大量的服务器，他们希望尽可能高效地利用这些机器，那么通常也意味着这些服务器会形成一个资源池（当然也可以称之为“云”），进而确保每一个应用程序或者任务都能得到它所需要的资源，而且还是按需分配。不再像以往的模式——为每个应用程序配置一个小集群，然后使用一个大集群托管所有的东西，这也是Platform Computing（ 在2012年3月被 IBM收购）几年前对其私有云的定位。
然而，这一概念从未真正进入到主流企业之中，因为这些企业在很大程度上会选择虚拟服务器，而且倾向于考虑亚马逊EC2模式的虚拟服务器来配置自家的私有云。不过随着分布式计算的发展，尤其是 Hadoop等云平台的出现，大大改变了互联网企业的IT环境，那些通用的“网格计算”或者“集群计算”的理念再次得到了回归。
不可否认，其中有一部分原因在于，管理不同的IT环境已经变得十分的复杂：这里运行的是分布式的Web应用，那边还有一个Hadoop集群，甚至某个角落的服务器上还跑着Storm或者Spark，冷不防的你就有了3个集群，而且每一个都需要维护。当然这些复杂性的问题不会出现在Google、Facebook或者Twitter的管理者面前，毕竟他们玩的就是 “效率和自动化”的游戏。
Mesos的架构
这些互联网“巨头”都有自己的软件来处理越来越多的工作负载：谷歌使用的是Borg（尽管该公司已经发表了一个尚未部署的Omega系统的研究论文）；Twitter使用的就是Mesos；Facebook的系统称之为Corona（主要用于 Hadoop的工作负载设计，但该公司希望扩展到多种框架上）。
连线的Cade Metz撰写了一篇博文，其中详细介绍了Mesos、Borg和Omega，读者可以 点击阅读。当然，如果和硬件关联不上，那么类似 Mesos这样的软件毫无价值，即使很多大公司都很喜欢这个系统。Airbnb是一个Mesos的忠实用户，他们使用Mesos来管理完全运行在AWS上的工作负载。
为什么Marathon很重要？
Mesos仅仅是适用于集群的管理，这意味着它可以隔离不同的任务负载。但是仍然需要额外的工具来帮助工程师查看不同系统上运行的工作负载。不然的话，如果某些工作负载消耗了所有资源，那么重要的工作负载可能就难以及时地获得资源。
Twitter也构建了一个工具叫Aurora（也在计划进行开源）来处理这个问题，包括Airbnb也有一个名为 Chronos的工具。Mesosphere的创始人Leibert 和Knaup在Airbnb的时候就负责构建Chronos这一工具。Marathon是一个“元架构”，它可以让Mesos和Chronos变得更好用，随着Mesos一起运行，并且在运行工作负载的同时提供了更高的可用性，让用户可以添加资源以及自动的故障转移。
不像Chronos在Mesos之上调度作业，Marathon让Chronos在Mesos的内部进行运行，通过这种方式，Chronos也变成Marathon所管理的一项工作。Chronos的优势在于处理和调度Hadoop作业和其他短期的任务，而Marathon则可以直接管理Chronos和那些长期运行的Web服务。Marathon甚至可以运行多个实例。
A cluster running three distinct applications
The same cluster, after one node died
从更广的层面而言，像Marathon这样的项目将来可能会在SDN（软件定义的网络）、存储，甚至是数据中心有更大的作为。Mesosphere公司也正试图通过软件管理的商用硬件来取代那些昂贵的硬件设施。