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