开放的云让业务更“闪亮”

对于服务和技术上的新发明及重大改进，人们一般首先着眼于自身的领域（尤其是以迎合市场为第一要务的软件厂商）。云计算也不例外。例如，IBM 提出了 Rainmaker 技术来帮助企业创建云，Rainmaker 技术为此定义了软件和硬件的协同工作。然而，软硬件的协同工作却是用一种非常专有的方式实现的，这正是隐藏在细节中的魔鬼。

现在，我们不再承受得起让市场来为我们（也就是最终用户）做决定。就像此次金融危机的情况一样，缺乏监管往往会导致巨大的灾难。如果我们对于云计算采取同样的放任态度，那么就会丧失掉业务上可能得到的关键利益。谨以本文分享我的一些想法：敏捷和新的市场规则如何深入地改变了我们“消费”IT 的方式。

我呼吁创建面向用户并且独立的云社区。这个社区将会集中人才并支持他们从用户的角度来清晰地定义关于云应该是什么的需求，而且还会支持当前的开源云项目之间的协作。我们需要尽我们所能来避免云计算中新的事实上的巨头垄断（不能让几家公司组成的小圈子掌管云世界（或者它们发明的什么新词），Amazon、SaleForce.com、Google、Microsoft、IBM、HP 都不行）。我们已经有了 SOA 的教训。

信息技术已死，敏捷业务技术永生 [1]

业务要敏捷才能生存，它需要“开放的、易于部署和互操作”的 IT 解决方案。在大多数公司中，如果一个人不在 IT 部门内部工作的话，那么他就不会关心信息技术，而敏捷的业务技术则会长久存在。典型的产品管理团队总是在寻找在完美时机具有完美成本的完美技术，用来在完美的时间内以完美的价格将完美的产品发布到完美的渠道中。“完美”是个业务术语，把它换成 IT 语汇就是“敏捷”、“快速”和“成本效率高”。让我们直面现实，我们都知道软件即服务（SaaS）被用在核心业务系统中（ Line Of Business，LOB），从而减少内部的 IT 资源和 IT 成本。除了控制成本，各 LOB 还想通过“按需”选择和配置所需工具，将业务的兴败也控制在自己手里。业务技术，即可自定义的业务过程及其在云中的实现，应运而生。

敏捷的普及性会影响 IT 过程和组织，影响 IT 开发和测试工具和技术，并且最终会影响 IT 运营和架构。在下面的小节中我们会展示一些例子，从而概述一下有多少种不同的力量集中在“云计算”这一点上。

IT 过程和组织中普遍的敏捷

我们公司在两年前发现了敏捷这个词，从此我们就再没有以原有的方式构建过软件。像 Scrum、XP 这些方法，以及精益管理都提高了产品的质量，并且缩短了将产品推向市场的时间。当我们具备了真正想要成功的意愿，并且应用了它们的时候，那些过程框架就会使组织功能障碍浮现出来，并且提供了重要的结果。

我们总是需要对过程框架进行自定义，并使其与特定的环境相适应，但同时总是要遵循一些关键的原则。一般需要提到的原则有：团队成员之间的沟通和信任、IT 团队中的业务（产品所有者）整合，经常在有规律的和及时定义的间隔中（sprints）发布和部署软件，以及持续地寻找各种浪费并找到节省资源的方法。

IT 开发和测试技术中普遍的敏捷

让我们来回顾一下 IT 开发和测试技术当前的进展，它们可以被认为是敏捷的催化剂：

• 动态软件服务生命周期管理——在特定的技术领域中，软件服务的生命周期可以用更动态的方式进行管理（例如对于 Java 基础服务的 OSGi，或者带有微内核的操作系统服务）
• 应用程序虚拟机——Java 的 JVM 和.NET 的 DLR 使我们可以创建作为平台的网络，并且降低编程语言和执行平台之间的耦合。应用程序还可以被隔离成与操作系统紧密结合的包，根据需要来重新部署。（例如，可参见 VMWare 瘦应用或者 AppZero ）
• 动态编程语言——新一代的原生动态编程语言（像 Ruby ）使得软件开发变得更容易，这是通过为特定的虚拟机对原生语言进行改写（JVM 上的 JRuby 或者 DLR 上的 IronRuby ），或者通过在虚拟机之上使用动态编程语言（像整合在 Java 和 C#代码中的 Clojure 或者 Scala ）达到的。
• 测试工具——测试仍然是考虑的重点，因为它已经被证明是可承受和敏捷的 IT 关键元素之一。测试也是消耗时间、易于出错并且很消耗资金的。现在你可以“直接编码（code directly）”或者“快捷的”功能测试、单元测试、模拟测试、负载测试、压力测试、行为驱动测试等等。大多数工具（ Fitnesse 、 Selenium 、 Fitnium 、 jMeter 、 The Grinder 等等），或者市场上可用的测试 API（xUnit， Rspec ， jwebunit , DBUnit 等等）都已经成熟（大多数都是免费的）。现在在云上可以提供负载测试，只要支付一定费用就可以最真实地模拟用户访问高峰的情况（像 SOASTA 、 BrowserMob 、 KeyNote 、 LoadStorm 、 CloudTestGo 等等）。
• 持续的测试和构建——几套可靠的集成工具就可以支撑起敏捷的骨架。 Hudson 或者 Cruise Control 可以用来管理测试和构建任务，并与 Sonar 或者 Xdepend 集成来完成代码质量评估，不要忘了 Ant 或者 Maven （如果需要，可以和 Nexus 或者 Archiva 一起来管理构建产品库）、 Subversion 、 Checkstyle 、 Findbugs 、 Cobertura 、 PMD 、 FxCop 等等。像 Electric-cloud 或者 Atlassian 等商业套件会为安装提供便捷的方法，并且已经在其中集成了构建和测试平台。代码质量现在也可以作为服务来提供（像 Kalistic 或 Metrixware ）。
• 模型驱动方法——对象管理组织（OMG）仍在改进 UML 的规范（现在是 2.1 版）并推出各种 UML 扩展（像最近的 SysML ，描述软件部署和架构）。OMG 现在越来越深入地参与到业务相关技术的标准化工作中。微软对将在 Visual Studio 2010 中实现的 OSLO 和 UML 投入了巨大的资金。
• 模型驱动引擎工具——在市场上有大量支持模型驱动方法的工具，付出的成本在完成两三个项目之后可收到较好的回报。例如，我们可以看一下针对泛型模型驱动的主数据模型（MDMs）的 Orchestra 网络 ebx 平台，针对自动应用程序开发所提供的 Obeo 或者 Sodius ，以及为建模服务提供的直接模型执行所提供的 E2E 。
• 软件即服务（SaaS）——如果你可以与其他客户共享应用，而支付的费用只是个零头，那又何必自己开发和部署应用程序？越来越多的公司已经接受了按需提供的 CRM 服务（使用 salesforce.com ，或者 Oracle CRM on Demand ）、敏捷计划（ Rally Software ）、人才管理（使用 SuccessFactors 或者 Plateau Systems ）。
• 整合即服务—— Boomi 或者 CastIron 已经提供了大量适配器来与 Saas 应用或者在 Saas 应用之间做整合。显然，这个领域所有主要的软件整合厂商不久就会让他们的产品发展起来（ Informatica on demand 、 TIBCO Silver 和 Microsoft Azure 都是这样做的）。然而 ，开源整合方案（如 WSO2 ）暂时还不能提供真正的云，这不免令人有些奇怪。

贯彻到 IT 运维中的敏捷

给数据中心购买一台新服务器，并且安装完毕通常需要三个月的工作。在此我还没有提到安装 DBMS 簇集或者设置 VLAN。在同一台服务器上安装多个应用程序会导致某些副作用（需要使用的软件的版本、配置冲突），更不用说部门组织之间的冲突了。

IT 运维中的敏捷产生于新一代的数据中心，绿色 IT 的要求（降温和电力）、虚拟化技术（提高硬件上运行的虚拟机的密度）、以及共享的基础设施（负载平衡、存储、防火墙、安全设备等等）。

将敏捷原则的适用范围扩大到 IT 运维也造就了“敏捷运维”（这种实践可称为“持续部署”）。

让我们看一下基础设施领域的现状变化得多么迅速，如今它已经被作为服务来提供了（Infrastructure as a Service）：

• CPU 虚拟化——CPU 都有多个核心，而新的 CPU 可以提供虚拟化的指令加速。你可以向 Amazon 、 RightScale 、 ElasticHosts 、 Rackspace 请求几十个 CPU 来运行你的工作环境。
• 针对私有云的服务器虚拟化——现在硬件服务器被虚拟化，并且可能会根据需要来部署和克隆。 Platform VM Orchestrator 、 VMware VSphere 、 Citrix Cloud Center 和 Red Hat 企业虚拟化管理器都是用作虚拟服务管理的商用工具，他们也将目标指向私有云。私有云可以部署在云中，也可以基于开源的平台（如 Enomaly 、 Eucalyptus 或者 Nimbus ）来部署。
• 虚拟机的可移植性——互操作性不仅是关于云之间接口的标准化，而且是关于虚拟机的可移植性的。 DMTF 开放虚拟化格式（OVF）是正确方向上的第一步，但该标准创建的时候并未预见到云需要，因此，关于标准的战争才刚刚开始。就现状而言，将虚拟机从 Vmware 的 VMDK 格式转换为 OVF、Xen 或者是亚马逊的 AMI 格式，并不是一件容易的事情。
• 网络即服务——网络必须被作为核心基础设施服务来提供，为网络资源（如 IP 地址、DNS 名字等等）提供完全自动的生命周期管理。网络服务应该是敏捷和区分工作负载的，这是通过支持 VM 的快速策略需求达到的。
• 轻量级的执行平台——当前的趋势是提供完全整合且轻量级的平台，这个平台可以作为服务提供（它们被命名为平台即服务，或者 PaaS）。多家公司试图改变软件开发和交付的游戏规则，包括 Google 的 App Engine 、 Microsoft 的 Azure 、 Force.com 的 AppExchange 和云平台。还有些平台自有（on premise）和租用（on demand）两种方式都支持，比如 Zend 的 PHP 服务、 SpringSource 和 MuleSoft 的 Java 服务，以及 Heroku 、 Aptana 和 EngineYard 的 Rails 服务。
• 随需而变的数据库——随需而变的数据库被分为两类：键 / 值数据库，像作为Web 服务的BigTable 和亚马逊的 SimpleDB ；或者关系型数据库，像 MySQL（在 Joyent 或者 Amazon EC2 之上）或者 SQL Server ( SQL Azure )
• 云整合平台——混合型的云提供商可以创建和管理你的公有、私有的云（像 Abiquo , OpenNebula , Elastra 或者 Appistry CloudIQ ）

想要得到关于云革命更多的信息，你可以阅读 CSC Leading Edge Forum (LEF) 上新近关于这个主题的报告。

云的支持和阻碍

在云中，部署和运维都可以更敏捷，并且更好地在统一的流程中贯穿起来。但是不是意味着我们任意创建一个应用程序，就能将其部署到 Windows Azure 或者 Google Application Engine 上呢？我们还需要关心应用程序的代码将被部署到什么地方，以及它需要多少个 CPU 来支持负载吗？我们还需不需要操心应用程序的“XX 性”，为此耗费大量时间，冒着出错的风险，额外增加不必要的代码？应用程序的业务和技术事件是否都经过良好地设计安排，以满足必要的弹性需求？我想你已经知道了答案。这个答案也解释了为何 LOB 们没有一拥而上大规模地采用云。

那么什么是采纳云的主要阻碍呢？

1. 云技术还不够成熟——已经提出的云技术大多还处于测试阶段，主要是专有技术，不可互操作。（互操作性的测试例子可以在这里找到），并且还没有迎合 IT 运维的需要（现在的技术主要针对开发者）。因此将应用程序和它的数据从一个 PaaS 提供商转移到另一个需要大量的工作。这是厂商闭锁的典型表现。
2. 云技术的研究还处于起步阶段——EU 委员会最近启动了 Reservoir 项目来“为基于服务的在线商务提供基础”，而 HP、Intel 和 Yahoo 则响应了 OpenCirrus 的“云计算研究试验台，它被设计用来支持在全球、多数据中心的规模上对服务的设计、供应和管理的研究”。
3. 云的互联还没有成网——在扁平的世界中，每个解决方案都需要从开始时就面向全球范围。在领域中主要的参与者仍然在他们的数据中心投入巨大，想要将它们的安装遍布全球（并且他们应该是绿色的！），关键在于敏捷的网络框架对于云资源的敏捷性、可移植性以及响应的支持，以及对于创建更高级别的服务像灾难恢复和 / 或容错的支持（更多细节请参见 infoblox webinar ）。当前，我们在云之间还有太多的蓝天。此外，还没有任何解决方案能够实现广播。
4. 还没有可用的大型服务器或者数据库——几乎不可能提供大型的机器（例如带有 12 个 CPU 和 64G 持续内存的）或者超大型的关系型数据库。
5. 云的成本模型是弹性的——当前，很难预测云资源的成本，因为它们会与需求相适应。使用模式而不是峰值模式（以及冒着超额提供的风险，那意味着使用上的不充分）的付费方式很难销售给公司的财务和 IT 审计团队。另外，由于财务掌管着世界，只有我们能够让他们满意，他们才不会拒绝。那也是为什么微型公司是云的第一批用户，因为他们的结构是有弹性的，并且随着业务而增长（他们的预算也是有弹性的）。不管怎样，所有的研究都显示，如果你拥有自己的硬件（但是将来价格会下跌），那么随需而变的云架构的稳定状态成本（没有长期的合同或者特定的谈判）一般是更重要的。
6. 现在的 **** 云服务等级协议（SLA）几乎不可能实现——所有者不希望让承担关键业务的应用冒任何风险，谁都不能指责他们。不过已经有一些研究项目正在开展中（例如，参见 SLA@SOI ）
7. 安全性和灵活性还有待研究——我们正在从数据中心（data center）转到数据（私有的、公有的、混合的）的中心（centers of data）。和通常一样，让云适应一些特定的严格的安全需求需要一些时间（参见云安全联盟）。例如，美国政府需要提供商的数据和应用程序必须位于该国国内（Google 就创建了专门的数据中心来满足这个特殊的需求）。EU 对于与公民相关的数据也持有非常谨慎的态度。
8. 核心业务系统中组织上的改变是深远的——谁会去做之前由系统和 DBA 管理员所做的工作？ ITIL 是关于如何处理有弹性的改变的吗？如果停电了，那么我会检测到它吗？应该如何应对呢？

这些阻碍都对主要的参与者提出了要求，首先他们要定义自己的服务，即便需要专利接口或者技术。他们的目标是要尽快争取到市场份额，并推广他们的标准。作为用户，这对于我的核心业务系统意味着什么呢？厂商闭锁的风险当前对于证明这样的行动太重要了，特别是因为它没有被有吸引力的成本模型所支持。除了 TIBCO，他还不清楚如何为 Silver 定价，大多数其他的厂商也都遵循了相同的方法（定价也几乎一样）。

避免 IT 系统危机

为了加入更多的竞争，并且让新的革新的和独立的参与者不断出现，我们必须：

• 说服所有云厂商基于不同类型的用户（政府、教育、工业、国防等等）和他们的需要（我们应该为大型的计算网格制定不同的价格，并使用共享网络服务器的负载均衡集群来实现外部的门户，等等）来创建商业化的云产品，
• 找到正确的组织来保证对日益增长的云系统实施恰当的管理，这样做的目的是为了避免将来的 IT 系统危机。
• 确保对云资源的访问是公平的，而不管客户端的大小和位置如何（从在家里工作的小型开发者到拥有成千上万员工的跨国公司都一视同仁）。全球的云部署会对世界范围内的敏捷和合理利用的 IT 资源做出贡献，并且为减轻南北半球之间的技术鸿沟做出贡献。
• 确保云提供商所提出的解决方案的合理利用性和互操作性，从而降低在云中对核心业务系统所做的投资流失的风险。
• 确保对遵守规则的云提供者的激励（例如，降低他们所要缴纳的税费，赋予他们某部分像教育或者政府之类关键的市场等等）
• 计划并为训练和指导成千上万的已经失业或者可能在将来失业（这是由经济破坏性创新组织所呼吁的）的 IT 人提供资金。
• 为创建强大并且独立的开源系统（像 Apache、或者 OW2，它刚刚与 OSA 合并）提供资金和支持。开源公司的速度和数量或者当前购买的项目团队是市场统一（SpringSource 就是绝佳的例子）的清晰信号，并且会延伸到将来的几个月中。我们应该保护一些关键的资源，并在可能的时候在公共的范围内对其进行维护（例如，关键的 Sun 技术以及像 Java、mySQL 或者 OpenSSO 之类的产品）。

现在，让我们不要限制业务敏捷性的将来，这需要经过云专利解决方案所形成的孤岛时期，使其相互连接来支持最大可能的优势（像对于航线，其中今天某些航线被取消来达到目标），而并不是为了支持最好的可能的网（像现在对于 Internet 的情况）。革新也是通过黑客因素达到的（取得、理解、提升、发明……）

让业务技术在云上闪亮

一些独立的相关人员需要敏捷的业务过程，他们正在改变业务和 IT 小组合作和交付的方式。现存的信息系统过于复杂，以至于几乎不可能让它们根据业务命令做出反应。现在是吃掉这个大象 [2] 的时候了，每次一口。信息技术不再是通往成功的康庄大道。IT 应该注入到业务中，从而创建业务技术。我们可以创建平滑的变更管理和让组织的发展适应敏捷的世界，这只需要遵循一些关键原则，其中最重要的如下所列：（这也创造了 SHINE 原则）

• （S）小即是美——小的团队负责业务服务的所有方面。以小团队（6 到 10 人）的形式工作，他们会负责很好地定义业务领域，这些领域是从开始到交付生产的子集。因此，如果你想要使用云，那么最好的方法就是转而采用面向服务的方法（如果 SOA 已死，那么采用基于服务的方法），并且以垂直组织的形式实现业务服务。这样我们从头到脚都是敏捷的。对你的应用程序使用持续部署，这意味着经常、安全地对其进行测试部署。在此可以使用自动化，并且这是我们所推荐的。
• （H）多向性是你的朋友——你可以任意地使用最适合的技术来适应业务需求，但是你需要完全掌握它们。使用你想要的语言，你想要的平台（作为服务或者不作为服务），你需要的人等等来开发你的应用程序。最后，你只需要对推向市场的时间和你的服务的质量负责。
• （I）带有开放 API 的接口——你应该尽可能地在各处提高敏捷性，特别是在业务服务或者过程边缘处。你应该清晰地定义消息的语义，并创建可理解的、安全的（参见 Google 安全数据连接器作为例子）、并且易用的接口。应该重用开放的标准，并且提出开放的 API 来让你的服务在其它的云中也闪亮（SHINE）。还要为将来考虑跨云的接口（例如统一的云接口或者 OCCI ）。应该基于业务价值链，那些服务也可能是动态或者静态安排的，以提供更复杂或者更细粒度的服务（那本身也可以作为服务提供）
• （N）推动你的云——当需要的时候创造合作竞争（合作并且竞争）的形式，从而为你的客户提供最好的服务。亚马逊正让它的供应商使用它的平台，并且为任何商品指定他们想要的价格。使用我的平台，使用我的过程，使用我的主数据，提高我的市场份额，让客户和供应商使用我的服务，总之给我费用并让我的客户更高兴。要记住长尾理论，敏捷并不意味着短期。
• （E）伸缩性、敏捷、适应性——为了从云计算模型中获益，业务应用程序和服务应该（重新）设计和（重新）构建，以在其核心具体表现出伸缩性。伸缩性需要来适应短期的冲刺（适应性），并且使带有大量需要计算的资源的长期的批处理工作成为可能（敏捷）。

最近我听说了关于 Lokad 的事儿，这是一家“闪亮”的德国小公司。Lokad 正在交付业务技术，专门从事对销售的软件、需求以及通话量的预测。有了云，他们可以在一个小时之内对一个主要的德国零售商完成预测的计算（业务 SLA 是由客户所影响的），而不用花费几个小时，并且成本也很低。Lokad 在 Azure 上做了投资，即便那时 Azure 还处于 Beta 阶段，并且真正使用微软的网络和worker 服务定义重新构建了他们的应用程序。他们可以提供所需要的尽可能多的资源（但并非总像他们那样强大，10 个单CPU 的虚拟机，每台带有2GB 的内存与一台带有20GB 内存的10CPU 的机器是不一样的），来做一些之前不可能的事情（由于计算时间的原因），现在甚至还支持创建和实现更加复杂的算法来提供更好的预测（由于计算时间不再是问题，而且软件的架构也不再一样）。

像IBM 等公司也在着力于创建新的“闪亮”的业务技术服务。大规模混合（M2）是对混合模型的扩展，它“集成了上G、上T 甚至上P 的非结构化数据，这些数据来自于基于网络的存储库，释放并丰富使用你选择的非结构化信息关机架构的数据（LanguageWare,OpenCalais 等等），让你在特定的、用户定义的上下文中（像 ManyEyes ）探索并虚拟化这些数据。IBM 还开发了改进的敏捷过程，来帮助客户们使用 M2。首先它通过两到三小时的简介来识别需求，并且看怎样才能最好地使用 M2。然后，使用一天半的时间来设置基础服务，并花费两到四天的时间来完成实现。

用于管理业务技术的云操作系统

核心业务系统传达的第一个需求是对业务技术全面的印象。你怎样才能够让不同的利益相关者接触并理解公司的敏捷的和有弹性的资产呢？接受这样的观点，当前还要应付关于云的标准的战争以及互操作性的缺乏，我们能做什么呢？

我们主张应该发明一种新型的分布式操作系统，用来支持“即时的”IT。然后它会让你向云发出指定并对其加以控制（不仅仅是一台机器）。这种云操作系统会能够在云中管理的任何实体上完成操作（像创建服务器、添加数据库、转移数据、部署应用程序等等）。我们预想下面的关键实体需要由这个操作系统来管理：

• 服务器——提供 CPU 周期
• 应用程序——连接组合资产和部署的软件资产
• 存储——提供低级别的二进制存储（可以使 SAN、NAS 或者一个内容管理系统）
• SVN——用来管理代码 / 配置的版本
• 服务——作为业务可执行资产管理，并传送价值（真正的钱）
• 接口——用来定义可执行的资产之间的所有通讯
• 缓存——基于需求可以使用多个缓存工具和技术。如果平台的一部分执行核心，他可能对于应用程序是透明的
• 事件和规则——为了支持和控制有弹性的行为
• SLA——用来定义和管理 SLA

让我们用简单的例子来说明我们能够预想作为 Scrum 用户故事的控制的级别。在公司中将会开始包括两个应用程序的新项目（一个是基于前提的，一个是基于需求的）。我们需要运行这个项目，并使其在公司的云上成为现实。对于这项工作，如果能够使用命令行的解释器会非常棒。因此，第一个目标是要使用一组命令，并且在云操作系统上拥有专有的云适配器，用来在正确的 API 中解释命令（就像我们回到了 EAI 的时代……）。为了管理业务技术，并且提供整体的印象，我们需要采集关于应用程序组合、将要部署的应用程序代码、应用程序配置以及非功能性需求和将要使用的有弹性的基础的信息。所有这些都在一个地方被管理和整合，即云操作系统（也被 3tera 叫做元操作系统）。

为了在伪代码中构建我的小例子，我试着重用了在云提供商的 API 中已经提供了的命令，以添加管理组合资产和添加企业架构所需要的属性所需要的数据。这里需要找到跨多个域的最一般的共同特性：

 
CREATE DOMAIN myPortfolio               ; my logical domain name composed of two applications
<strong>ADD</strong> myPortfolio APP1 Critical OnPremise ; APP1 is a critical application - app. portfolio
<strong>ADD</strong> myPortfolio APP2 Maintain OnDemand  ; APP2 is in maintenance mode - app. portfolio
 
; Let's Begin with APP1
APP1 CREATE                        ; Definition of my APP1
APP1 IMPLEMENTS CustomerOnBoarding ; Link APP1 with Business Process
APP1 STATUS = Production           ; APP1 is in production mode (portfolio)
 
; Automated cloud based deployment
APP1 SVN https://mycompany.com/svn/myPortfolio/app1.xml
APP1 REQUIRES JVM 8.x               ; (we are dreaming ..)
APP1 SCALABILITY HORIZONTAL DYNAMIC ; Elasticity, create CPU when needed
APP1 PREFERRED AWS, RIGHTSCALE      ; Elasticity, Preferred Cloud suppliers
APP1 RULE "COST < $200 PER DAY"     ; Elasticity, Rule for elastic cost containment
APP1 SLA = 99.9                     ; Elasticity, Rule for elastic cost containment
 
; Automated cloud based DBMS creation and data load
APP1 DATA SCHEMA                 https://mycompany.com/config/myPortfolio/Data/DataSchema.xml
APP1 DATA LOAD                   https://mycompany.com/config/myPortfolio/Data/DataDump.dat
APP1 DATA COMPUTE GRID MAPREDUCE https://mycompany.com/config/myPortfolio/Data/grid/MapReduce.cfg
APP1 STORAGE EXTEND ON DEMAND ; Elastic Storage
APP1 STORAGE DR ENABLED       ; Storage with Disaster recovery
 
; Security information
APP1 SECURITY SSO
APP1 SECURITY OPENId
APP1 INTERFACE WITH APP2 USING HTTPS
 
; Service call
APP1 USE APP2         ; dependency management at architecture level
APP1 USE Service1 https://mycompany.com/config/myPortfolio/service1.wsdl
APP1 USE Service2 https://mycompany.com/config/myPortfolio/service2.wsdl
 
; Monitoring
APP1 MONITOR on MonitTweeter #APP1 ; monitoring is done through a Twitter-like interface
APP1 END
 
; Then
APP2 ATTACH APP2 https://www.app2.com/                      ; APP2 is in on Demand 0
APP2 IMPLEMENTS CustomerProfile                             ; Link APP2 with Business Process
APP2 NEED OpenID                                            ; APP2 is using OpenID
APP2 Certificate https://mycompany.com/certificate/app2.key ; Requires certificate
APP2 END
END Domain MyDomain

云操作系统——回归基础

业务技术革命驱动的虚拟化是整体上的（服务器、存储和网络）。云需要并行和分布式的操作系统能力，这将会迫使我们忘记本地的操作系统为中心的样子（微软的 Windows 7 可能会是他最后一个操作系统）。我们还应该对于大量已经可用的关于分布式监控、配置和架构的动态映射进行重用。

显然，我们会提议创建特定的轻量级的类似于 Linux 的微内核，它是为云所优化的。它应该可以自如地运行在多种类型的处理器上，并且能够运行当前市场上大多数的虚拟机上（或者至少能够通过网络与他们交互）。每个微内核都将会运行在一个处理器或者 CPU 核心上。中心的系统会收集数据并且对其进行动态关联，以使分布式系统适应当前的状态（在分布式的系统中收集全局的状态具有很重要的价值），并且在需要的时候发出远程的命令（在 steroids 上分布 OSGi）

最基本的方法已经开始在世界范围内实行，以解决这些关键的问题。其中最有前途的有：

• ** Deltacloud ——** 开源的（LGPL）API，它抽象了云之间的不同之处。框架使得云的提供者能够很容易地将他们的云添加到 Deltacloud 通用的 API 中。它能够作为云操作系统的整合层。
• Kaavo 的随需而变的架构和中间件（IMOD）——它提供了能够掩盖云的异质性的应用程序。所有的部署和配置信息都存储在单独的文件中。这个文件被分为两个部分。一部分定义了应用程序的静态工件（层、服务器），而另一部分指定了当应用程序被载入的时候，IMOD 引擎所要执行的动作。这个动作的流程控制被定义在速率模板的表单中。
• ** Cloudloop ——** 一个为云存储提供的统一的、开源的 Java API 以及命令行函数，它让你可以存储、管理并且在所有主要的提供商之间进行同步。
• ** 3tera AppLogic 系统——** 用于创建私有的云。它是运行在 Red Hat linux、Xen 和 AppLogic 的 orchestration 系统上的互联的系统的簇集。基本的构建块叫做“设备”，它可以是虚拟机（运行在其它操作系统上），也可以是应用程序。
• EU 委员会资助的 ** XtremeFS ——** 它是一种新的开源云文件系统，这个项目研究如何将点对点（P2P）通信架构的优势与像 Akamai 那样的内容传送网络（CDN）的优势相结合。
• 过程虚拟机——一个简单的为了构建和执行过程图的 Java 类库。它作为所有类型的工作流、业务流程管理（BPM）以及组合过程语言的基础。

企业架构永远不会一样

云将会迫使企业架构拥有对弹性系统的整体上以及尽可能动态的认识。之前的方法中，我们使用专门的工具（像 Aris 、 Mega 、 Casewise ）静态地载入 IT 的横向数据，这些方法将不再可用。企业架构、应用程序的组合以及架构的管理的整合，是保持对域状态有全局的认识并且看到它在业务价值链上的影响的绝对需求。

运行在自治的架构上的弹性应用程序将会对旧的设计、部署、测试、写文档以及维护 IT 系统的方式提出挑战。尽管如此，我们需要创建钩子来让我们的 IT 足够敏捷，从而对新的业务决策做出快速的反应（在向云或者它的继任者做大的跨越之前）。

业务过程的描述、整合和优化在将来会越来越重要，它会在 LOB 的组织中创造新的工作机会。相反，技术架构师、构架专家以及计划和资产经理的工作会越来越难以区分。

结论

我希望通过简单的“闪亮”原则，你能够按照自己的步骤来使用云计算；我们已经知道，云计算还不成熟，并且随着应用程序的开发和部署需要一些返工。但是，现在已经是让你的企业为云做准备的时候了。

从虚拟化到私有云是向应用程序所有者提供自我服务能力的基本步骤。它提高了灵活性，减少了推向市场所需的时间，同时也提高了管理的复杂度，因为它添加了又一个抽象层。还需要有过程和工具来管理这个层。

使用云的最大优势在于你不需要创建处理异常的峰值的能力。虽然如此，你可以有意地来这样设计，从而得到随之而来的弹性命令和好处，用来更快地或者用一小部分成本来完成工作。

如果我们将云交给 IT 厂商的手中，因为他们试图让业务相信使用它能够降低成本（这还需要验证），那么我们会再一次失去创建持续敏捷的公司的机会，而内部的 IT 只是会扩展到稍微敏捷一些的外部供应商。现在是设置或者用户一个组织的时候了，它能够确保对日益增长的云系统的管理。这里的目的是要避免在将来发生 IT 整体危机。

我真的希望，在不久的将来，会存在像我描绘的那样的操作系统。我无法预见严格的技术上的整合问题，它可能会阻止那样的操作系统的实现。此外，采用一种敏捷的方法，其中实体的粒度以及它们的功能性和非功能性的属性都被很好地界定，会让我们更容易、更快地成功。这个操作系统将能如何对多种事件作出表现（反应），它需要多聪明才能避免过分工程化，仍然需要研究和讨论。

[1] “My View: IT To BT”，George F. Colony，Forrester 公司的 CEO，2006 年 8 月 18 日（ http://blogs.forrester.com/colony/it-to-bt.html ）

[2] Eating the IT elephant, moving from Greenfield Development to Brownfield，Richard Hopkins 和 Kevin Jenkins 著，IBM 出版社，2008

关于作者

William El Kaim 是一家大型欧洲旅行社的首席 IT 架构师，定居在法国巴黎，网志在 http://blog.resilient-it.com/ 。

声明：本文中所有观点仅代表个人，与公司无关。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。