CloudBees 推出 Hudson-as-a-Service

阅读数:1458 2010 年 9 月 15 日

话题:Java敏捷持续集成云计算DevOps语言 & 开发架构文化 & 方法

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