CloudBees 推出 Hudson-as-a-Service

CloudBees 推出了他们第一款 PaaS 产品——HaaS（Husdon-as-a-Service），把持续不断的项目编译和测试引到云中。通过“按需”使用云中弹性的服务器资源，它能够更好地分配构建项目所需的工作负载，从而降低构建时间。CloudBees HaaS 协同现有的 GIT 或 SVN 存储库一起工作，同时它也能提供私有的、安全的 SVN 或 GIT 存储库，以及 Maven 存储库。

HaaS 的基础是 CloudBees 的 PaaS 的基础设施。正如他们自己对它的定位：

在 CloudBees，我们认为云是一种新型平台，在这里应用程序能随时调整，以降低硬件和 IT 成本。然而，要想全面实现该目标，必须要有真正天然的云基础设施。

怀揣这种理念，他们为 PaaS 设定了一组需要实现的目标，包括：

• IaaS 无关性——支持多种 IaaS 供应商，对客户透明。
• 开放性——使用开放的、标准化的、自由的 / 开源的技术，包括数据格式。
• 平滑性——致力于让应用程序开发变得更加简单，降低开发相关的其他所有费用，如持续的 Scale-DUO（scale-down, scale-up, scale-out）[译注：scale down 是缩减；slale-up 和 scale-out 都是扩展，但是 slale-up 是在一个硬件盒子内通过增加内存或 CPU 的方式扩展，而 scale-out 则是增加盒子的方式进行水平扩展]。
• 真正地应用——扫清阻碍应用程序部署到云中的各种限制和约束。

首款 HaaS 方案就包含了上述各项特征，而且，他们计划随着新服务及特性的加入，增加更多这类特性。

为此，InfoQ 采访了 Sacha Labourey，CloudBees 的 CEO 兼创始人，他就我们提出的以下问题进行了作答：

采用持续集成（continuous Integration，简称 CI）的方式领导一个公司是一个非常大胆的举动，你是如何做出这个决定的呢？

CloudBees 的目标是提供能够覆盖整个应用程序生命周期的云平台，从开发、登台 (Staging)、QA、生产以至维护。所以，始于 CI 是非常可取的。原因有两个方面： 一方面，它的确是要解决大多数开发团队所面临的痛点（如，人们永远缺乏完成 CI 工作的足够能力）；另一方面，它不会影响现有的运行时环境，因为在运行时环境的域中作出的决定更战略，更长远。 所以，我们首先通过为开发者提供一个与应用服务器（AS）无关的 SaaS 解决典型的 IT 痛点之一，其限制非常少。我们的 PaaS 也是基于此构建的。一旦我们的 PaaS 准备好了，我们的客户将能在 CloudBees RUN@cloud 上轻松地测试他们的应用程序。而且，因为应用程序是在我们的 PaaS 平台上进行构建与测试，所以我们将能轻松地自动获知这些应用是否与 CloudBees 兼容。

此外，CloudBees HaaS 使用了我们的 PaaS 子系统（如我们的动态配置引擎），所以，我们的 SaaS 实际上是我们的 PaaS 的第一个客户。

能给我们列举一些您准备支持的开发技术吗？比如，nosql、关系型数据库系统，Web 服务等？

我们分离 Java 平台本身与其所依赖的资源。Java 平台将能提供一个高质量的 EE 环境所能提供的所有的典型服务，但是却免除了具体的“Web 服务器”、“VM”和“应用服务器”等概念。我们将提供完全虚拟化的 Java 平台，它以高度整合的方式提供各种服务，你不需要去定义某种特定类型的节点个数。我们要让平台尽可能的平滑，它将为你解决所有典型的 IT 相关的工作，从扩展性（集群）到高可用性，这些都以对客户透明的方式升级。你只需关注你的应用即可，其他的由我们处理。

有哪些手段可用来保护多租户基础设施环境下的数据安全？

最初的实现将大体上采用进程分离的技术（以及人们熟知的 OS 技术来确保用户以及进程间的隔离）。此外，我们还评估了一种进程内的多租户基础设施，其资源利用率可能更高，它将是一种迭代的进程。不过，我们需要衡量这一因素的关键程度，这是我们的设计的核心部分。对于数据，我们遵循最佳实践，而且用户相关的数据至少是加密的。

您能展开谈一下一致的 Scale-DUO 基础设施及其特性吗？

我们所称的“Scale-DUO”（及 Scale -Down, -Up, -Out），也就是平台能够非常精确地动态分配资源以满足当前负载的能力。打一个比方，它与你从电力供应商那里获取电能非常类似：当你插入一个设备时，你就能得到更多的电力，不多也不少，使用多少付多少费用。将这个类比继续延伸，当下的 IT 环境中，你需要提前若干个星期告诉电力供应商，你需要多少电量、需要那种设备的电、业务还只能以 10,000 瓦特为单元来购买。若希望开发变得更加敏捷，不再依赖于滞重的 IT 流程，我们必须要做的更好。

您所预见的企业从使用 Hudson 的方式转向完全基于云的开发平台的进程将会怎样，对于目前简单配置 VM 的方法而言，这无疑是一个很大的跨越，和我们分享一下您的看法？

这种转型没必要一蹴而就。企业首先会寻找能够消除他们痛点的方法，一个接一个，而云可能为大多数这些问题提供最佳的解决方案。而且，一旦开发流程的最关键部分出现在云中时，企业为寻求统一的开发总线，将其他部分移入云中就是时间上的问题了。但是，时有发生的那种强制的转型，将资产拆分在两端并保持很长一段时间的做法，这是不可取的。这就是为什么 CloudBees 在提供集成的开发环境同时，有要求每一小块能独立地插入到第三方系统（本地系统或云系统）中的原因。

对自动测试的支持，您是如何打算的？按需分配的硒网格似乎是完美的解决方案，而且在你的构想中你曾提到，这也是从开发到生产转型过程中所缺失的一块。

没错！我们目前的产品是一个很好的基础，而在此之上，今后我们还会提供更多的新服务。对与下一步将提供的服务，我们已经有一些具体的想法了。对于每个新增服务，我们有可能自己实现，也可能与合作伙伴一起实现。

请您分享使用 CloudBees 之后你们自己的开发 / 流程的改进？

我们所有的开发流程都是在线完成的。因为我们是从无到有的，所以我们从使用 GitHub 服务开始，一旦 CI 完成之后，我们也会使用它。我们非常接近于使用了一个完全云化的 CloudBees 的登台环境（HaaS、PaaS 配置、记账和付款、生产等），通过一个独立的 Amazon 账户直接从我们的代码存储库中访问我们的 HaaS。我们显然是一个无 IT 化的公司，我们没有自己的服务器，完全依赖于 SaaS 服务进行开发和运作（包括 salesforce.com、Loopfuse、Zendesk、PagerDuty 等）。

欲了解更多 CloudBees HaaS 产品的相关信息，查找他们即将推出的 PaaS 新特性，请访问他们的网站： www.cloudbees.com

查看英文原文： CloudBees introduces Hudson-as-a-Service