【51CTO.com快译】Joyent率先举起了容器支持的大旗，而后又得到了Docker方面的认证。尽管技术水平出众，但像Joyent这样一款独立的公有云方案是否能够在市场上闯出一片天地?
凭借着自己记者的身份，我得以接触到技术业界当中那些最具智慧的头脑——而且不仅仅是拜读他们的文字，还能够与其面对面交流。今年10月，我更有幸在Couchbase Live NY大会上与Joyent公司CTO Bryan Cantrill直接沟通。
Cantrill是那种很有天赋的技术人员，他能够在不自觉中将枯燥的专业内容变得娱乐化，并在极为平常的表述中达成技术宣传的目的。只要一开口，他就能够对计算机技术的发展历史如数家珍，并很好地切合当前的讨论话题。上次遇到这么风趣的技术牛人还是在我为JBoss效力的时候，Marc Fleury也拥有这样的出众魅力。
那些PaaS尚未成型的岁月
在分享与Cantrill的交流内容之前，让我们首先聊聊背景信息：2012年，我曾经在一篇名为《我到底该选择哪款PaaS方案?》的文章中提到，SaaS不会快速转变为PaaS。
而在那之后，Cloud Foundry用了很长时间来重新编写并推广PaaS方案，但其始终未能受到高度重视。红帽公司的OpenShift实现了可观的改进成效，不过其并不属于真正的公有云方案，而且直到今天也未能真正在世界范围内普及。我甚至都快忘记了Heroku的存在，目前提起云计算我们能够想到的似乎只有Amazon以及新兴的微软与谷歌。
不过如今情况开始有了转变：Docker正在迅速兴起。Docker允许我们在享受大部分PaaS优势的同时，继续保留对软件层以及使用规范的控制能力(因为我们都不希望在部署应用时被服务供应商所牢牢束缚)。
Node项目成员打造出的非Amazon云成果
尽管Cantril所在的Joyent公司向来以“Node.js项目成员”所建立而为人所知，但这家年轻的企业并没有始终沉迷于过去的辉煌当中。Joyent公司是一家云服务供应商，其同时提供计算与存储选项，且拥有自己的多座数据中心。该公司还销售与Cloud Foundry以及OpenShift相似的受支持开源环境，但这套环境完全基于容器技术构建而成。
用Cantrill的话来说，Joyent公司优于或者说至少走在了市场的前面：
| " Joyent公司在不合适的时间点上选择了正确的发展道路，而且该时间点还持续了相当长时间。我们是一家真正以容器技术为核心进行产品构建的企业，而且坚 信基于容器机制的虚拟化技术将大有可为。不过我们走得太远，把市场远远抛在了身后。直到大概去年，整个市场才突然醒悟过来并意识到“嘿，容器技术是个好点 子，我们都应该表示欢迎。” |
在Cantrill的表达当中，我产生了一种强烈的既视感：将Docker与Solaris Zone联系起来。作为Sun公司的前任员工，Cantrill当然很清楚这段掌故，而且他自己也曾经有过这方面的感受。不过Joyent公司不仅能够准确地定义什么是错的，更有能力弄清什么是对的。当然，Cantrill也以非常客观的态度承认Joyent是一家知名度相当低的公有云供应商，而他也面临着一场艰苦的影响力提升战：“我们不是Amazon，我们也不是OpenStack，我们仍然默默无闻。”
但在另一方面，OpenStack本来也不是个值得效法的对象。Cantrill将OpenStack比作了当初的Solaris CDE;虽然有一些企业试图以其为核心进行开发，但几乎没有任何一位参与者得到了理想的成果。而尽管OpenStack项目吸引到了远远超过CDE的支持者数量，但Cantrill认为OpenStack的时代已经成为过去：
我认为人们当下已经开始意识到这一点。OpenStack代表的是一波已经过气的技术革命。而我们正将精力更多集中在我们认为将代表未来革命的成果身上。这在目前也许只能算是一种希望，但在明天却可能呈现出一股容器技术浪潮，并体现为一整套基于全容器机制的堆栈。我们坚信这一点，而我们所开发的软件全部为开源项目。
与其它厂商一样，Joyent公司也同时拥有公有及私有云产品。Joyent公司的容器技术Triton能够提供内核原生容器功能，但同时亦支持Docker软件包。Joyent方面还宣称其具备裸机运行能力——毕竟Triton的开发基础正是拥有数十年发展成熟度的Solaris Zone。
考虑到用户往往倾向于在Amazon环境之上运行Docker镜像，这类容器型虚拟化方案本身也需要以虚拟化形式运行。总而言之，掏出钱包给AWS付钱吧!相比之下，Joyent不仅在CPU与资源使用成本方面低于Amazon，同时所需的资源总量亦将有所削减——毕竟我们用不着干将容器运行在虚拟机之上这种没必要的蠢事。
这是一套与EMC殊为不同的非Hadoop/非S3存储方案
SAN实在是种很傻的事物。将我们的存储资源从计算体系当中各设备的每块磁盘中剥离出来并散布到整个网络，这简直就是一套专用形式的客户端-服务器计算机制。很明显，我们应该采用具备弹性的新型软件设计方案，而对那些单纯用磁盘堆叠并模拟而成的所谓“弹性”说不(抱歉，戴尔，说的就是你)。
而这正是Joyent公司走在时代前列的重要表现之一——同时也略微领先于HDFS、EMR以及S3——也就是Manta，一款集成有计算机制的对象存储解决方案：
我将向大家列举我们利用Manta所实现的具体效果，我们已经将其引入日常工作，但市场对其尚未做好准备——正因为如此，我们并未对其积极宣传，因此客户可能还接受不了这样的方案。总而言之，它的作用在于提供对容器存储资源进行拆分的能力。如此一来，我们就能够拥有一套与S3类似的对象存储体系——但如果大家只希望对存储对象进行计算处理而非将其移动到对象存储之外，则能够直接在对象所在的位置建立容器系统。
讽刺的是，我发现Cantrill似乎并不相信在一台设备当中塞进大量磁盘驱动器，而后通过网络进行连接，最终对所有接口进行粘接的作法是什么好主意：
不，我认为这种集中化存储设计不是什么好东西……应用程序能够计算; 因此将存储与计算资源硬性拆分开来根本没有必要。这种思路只是符合人们的思维习惯，而且确实能够为计算机制带来一种比较良好的特性——即临时性。一旦某台设备出了问题，大家可以将其启动另一台，因为计算与存储并非处于同一设备之中。这确实不错，但好消息也就这么多了。毕竟计算资源在那、存储资源在这的设计本身就存在弊端，而且需要强调的是，大家还需要为此对可能出现故障的组件进行没完没了的优化——但事实上，这些组件本身可以说是我们能够买到的最可靠的东西了。我得再说一次，目前基础设施当中最不靠谱的东西就是传统磁盘驱动器，但它们在真正出现故障之前都有质量保证周期，这意味着我们至少能够对其做出较准确的更新管理预期。
在Manta的帮助下，大家可以通过API建立起存储体系并运行由R、Python、Node.js、Perl、Ruby、Java、C/C++等各类语言编写而成的大规模并行流程。另外，Manta还支持流媒体。不过Manta有着自己的既定任务，它不是Spark、当然也不是Hadoop。
不过我们还要考虑到，历史也许会在Joyent身上重演。如果没有兼容性API以及强大生态系统的支撑，Manta也许最终只会成为另一项走得太快、导致市场无法跟上的早夭技术。很明显，走得快一点不是坏事，但如果快到人们无法理解或者底层技术优越性不足以构建起拥有吸引力的生态系统，那么消亡将只是时间问题。
单单更好就够了吗?
当初Joyent公司刚刚开发出自己的容器技术时，尚不存在任何既定的行业标准或者基于Linux的API。Docker的横空出世创建出了客观层面的执行标准，也使得人们开始争取投向容器技术的怀抱——而这又从另一个角度为Joyent创造了市场空间。
也许当Spark成为业界领先的API时，Manta也会拥有同样的效果。之所以值得肯定，是因为Manta确实拥有出色的设计且具备开源属性，因此它应该能够抓住相当一部分用户的眼球——毕竟它确实优于HDFS、SAN或者其它现有围绕虚拟化建立起来的规模化存储方案。
不过生态系统的构建在很大程度上属于一项社会性任务，而非单纯的技术或者经济性事物。拥有更好的技术是否就足以帮助Joyent实现突破性的市场影响力?目前这家年轻的企业面对着众多巨头的压迫：Amazon、Hadoop/Spark及其相关项目，而每一种方案都希望成为人们眼中的核心“混合云”实现途径。所以，单单更好就够了吗?这一切还有待时间的检验。
原文标题：Joyent: The Docker-friendly cloud you’ve never heard of
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
