Apcera Continuum

  • Chris Swan
  • 孙镜涛

2013 年 11 月 25 日

话题:DevOps语言 & 开发架构

随着 11 月 14 号新网站的开通,云初创公司 Apcera 让自己的 Continuum 产品对公众更加的清晰可见。

Continuum 将会和 Pivotal 的 Cloud Foundry 开源 PaaS 平台较量,后者是在 Apcera 的创建者 Derek Collison 的帮助下创建的。虽然在最近发布的商业版Pivotal CF中 Pivotal 已经可以和 VMware 所提供的已有的企业基础设施集成,但是 Apcera 关注一个更加整体的基于策略的方式。在一篇介绍性的博客文章“我们为什么会在这里”中,Collison 写道:

为了让企业 IT 在创新方面超越它的竞争者,需要把政策放到前面和中心,成功地在一个平台中混合交付模型(IaaS、PaaS、SaaS),并且能够进行通信的语义识别。

现在,PaaS 依然是第一代云计算模型,制定它的目的是为了让开发者活的更容易。PaaS 不会处理关键的企业需要,例如管理、政策、承诺、身份认证、身份、安全、审计等内容。我们会发现,使用 PaaS 的人越多,那么对于它的限制我们理解的就越多。虽然 Dev 和 Ops 都在加速发展,但是从来都没有一个单独的、完整的企业级平台能够让所有的交付模型可以顺从地工作在一起。直到现在,我们都还不清楚它将怎么发生。

尽管 Apcera 已经开源了一些组件,例如gnatsd(一款高性能 NATS 服务器,Continuum 中使用该服务器处理消息),但是它已经选择了不走对市场开源的路线。Collison 已经承诺随着时间的发展他们将会开源产品的更多部分,同时也解释了为什么 Continuum 不会完全开源的原因:

生态系统参与是一个微妙的平衡。在我之前从 Google 内部到 VMware 的努力中,设法实现这一目标有不同的工具。常见的已经成为桌面筹码的一个是开源工具、软件或者平台。人们认为这会驱动发展,但是我却不这样认为,解决生态系统的参与度和培养需要长期的时间。

例如,如果一个系统是开源的,但是却没有有意地将其彻底构建为可编程、可扩展、可组合的,那么不同的生态系统成员将会按照不同的方式驱动该平台,这会导致一个隐含的分支问题,你的版本很快就会偏离主干,合并回主干所需要的成本会越来越高。从现在市场上主要以开源的方式驱动生态系统参与的许多流行的 IaaS 和 PaaS 解决方案中我们就能够看到这一点。

Apcera 为 Continuum 示范的一些功能看起来非常像Docker的轻量级虚拟化方式。Collison 解释了引擎内部的真正原理:

在 Continuum 中所有的事情对于我们而言都仅仅是一个工作、一个平台运行、管理、监控、允许用户更新、作报告和治理的工作负载。在我们的理念中、我们的平台和 OS、传统的应用、使用现代框架的 Web 或者移动应用之间并没有什么不同。

为了实现上面提到的诸多目标这些事情都需要隔离。对于这一方面 Apcera 始终都在强调隔离上下文(Isolation Contexts)。隔离上下文一直都是孤立的、绝缘的、自治的。我们相信实现这一目标的方式有很多,从使用一个管理程序进行全虚拟化到 Linux Container 或者 Solaris Zone 这样的轻量级实现,甚至包括像 Bromium 这样的公司所推广的直接由硬件 CPU 驱动的微任务(micro-task)虚拟化。

我们在实现第一个版本的时候使用了底层基元到 Linux Container,并且将会有更多。多元化和混合是规范,一种方式并不能满足所有需求。失败在我们的定义中是自治的,这对我们来说非常重要。我们所说的自治是:系统中的每一个工作都仅能够与被允许的和策略定义的端点进行通信。这种策略从物理访问延伸到了网络层、寻址、发现和通信协议的语义识别。

再次声明,这是一个非常强大的模式。有些人已经将它称为应用程序 SDN。我们相信我们是第一个真正处理这一问题的领导者。当然,作为一个现代平台,这一切对于用户而言都是透明的,并且随着事情的变化、移动和重启,Continuum 将会为你处理所有无差别的繁重工作,同时为系统中的所有状态转变提供安全审计日志。因为策略被构建进了架构的核心中,所以客户从第一天开始就得到了可见性、洞察力和顺从性。

Apcera 是Go编程语言的早期采用者,平台广泛地使用了该语言。同时 Cloud Foundry 已经将它们的路由器(Router)、日志系统、健康管理器和CLI等组件迁移到了 Go 语言上,以便于利用该语言对高并发应用程序的适合性。

查看英文原文Apcera Continuum

DevOps语言 & 开发架构