开放云将使业务焕然一新

当人们发明或改进新的服务或技术时，他们通常会将精力集中在自己的领域上（尤其是那些首先想迎合其市场的软件供应商）。 云计算也不例外。 例如，IBM将Rainmaker技术定义为可以协同工作以帮助企业创建云的软件和硬件。 而且，像往常一样，魔鬼活在细节中，软件和硬件将以非常专有的方式协同工作。

如今，我们再也负担不起让市场再次为我们（最终用户）做出决定了。 就像金融危机一样，缺乏监管通常会导致巨大的灾难。 如果我们采用相同的云计算方法，企业将失去他们可能获得的大部分关键利益。 本文旨在温和地分享我对敏捷性和新的市场规则如何深刻改变我们“消费” IT方式的看法。

我想呼吁创建一个面向用户的独立云社区。 该社区将集中和利用人才，以从用户的角度定义对Cloud的明确要求，同时使当前的开源云项目之间实现更好的协作。 我们需要尽一切可能避免在云计算中出现新的事实雅尔塔（几个公司无法管理云世界：亚马逊，SalesForce.com，谷歌，微软以及任何IBM或惠普会提出的建议）。 我们已经看到了SOA发生了什么。

信息技术已死，敏捷业务技术万岁[1]

业务需要敏捷才能生存，并且需要“开放，易于部署且可互操作的” IT解决方案。 在大多数在IT部门之外工作的公司中，信息技术已不再是人们关注的，敏捷业务技术的长期存续期。 一个典型的产品管理团队总是在完美的时机以完美的价格寻找完美的技术，以在完美的时间将完美的产品交付到完美的渠道，以完美的价格。 “ Perfect”是一个业务术语，可以在IT措辞中通过“敏捷”，“快速”和“具有成本效益”来映射。 坦白地说，我们都知道软件即服务（SaaS）被用作业务线（LOB）以减少内部IT资源和IT成本。 除了成本之外，LOB还希望通过选择和配置“按需”所需的工具来恢复对命运的控制。 业务技术是可定制的业务流程及其在云中的实现的组合，将继续存在。

敏捷普及将影响IT流程和组织，IT开发和测试工具与技术，并最终影响IT运营和基础架构。 在以下各节中，我们将提供一些示例来概述有多少种不同的力量聚合到一个焦点：云计算。

IT流程和组织中的普遍敏捷性

敏捷是两年前我的组织发现的一个词汇，我们永远不会以相同的方式来构建软件。 Scrum，XP和精益管理等方法都提高了生产资产的质量，并缩短了上市时间。 当以真正的成功意愿应用这些过程框架时，它们会暴露组织的功能障碍并提供重要的结果。

流程框架始终需要自定义并适应特定环境，但始终遵循一些关键原则。 通常引用的原则是：团队成员之间的沟通和信任，IT团队内部业务（产品所有者）的集成，经常在规则和及时定义的时间间隔（冲刺）内发布和部署软件，并持续寻找任何浪费以及丢弃它们的方法。

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

让我们回顾一下可以视为敏捷催化剂的IT开发和测试技术的最新进展：

• 动态软件服务生命周期管理 -可以在特定技术领域内更动态地管理软件服务生命周期（例如， OSGi用于基于Java的服务或带有微内核的OS服务）
• 应用程序虚拟机 -Java JVM和Dotnet DLR使得创建Web作为平台以及分离编程语言和执行平台成为可能。 也可以将应用程序隔离在与操作系统相关的一致软件包中，并按需重新部署（例如，请参阅VMWare瘦应用程序或AppZero ）
• 动态编程语言 -新一代的本地动态编程语言（如Ruby ），针对特定虚拟机（JVM上的JRuby或DLR上的IronRuby ）的本地语言改编或基于Java之上的动态编程语言，可简化软件开发。虚拟机（例如集成在Java和C＃代码中的Clojure或Scala ）
• 测试工具 -测试已被证明是可持续和敏捷IT的关键要素之一，因此测试仍在考虑之中。 测试也是费时，容易出错并且在经济上花费巨大的。 今天，您可以“直接编码”或“表达”功能测试，单元测试，模拟测试，负载测试，压力测试，行为驱动测试等。大多数工具（ Fitnesse ， Selenium ， Fitnium ， jMeter ， 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规范（现在为V 2.1）和UML概要文件（例​​如最近描述软件部署和基础结构的SysML ）。 值得注意的是，OMG现在越来越多地参与标准化业务相关技术。 微软在OSLO上投入巨资，并将在Visual Studio 2010中实现UML
• 模型驱动的工程工具 -利用模型驱动的方法的工具在市场上很多，经过两个或三个项目后，具有成本效益。 例如，查看用于通用模型驱动的主数据模型（MDM）的Orchestra Networks ebx平台 ，用于自动应用程序开发的Obeo或Sodius ，用于自动遗留现代化的Blu Age Software和Metaware ，用于直接执行模型化服务的E2E
• 软件即服务（SaaS） -如果您可以与其他客户共享应用程序并仅支付使用成本的一小部分，为什么要在内部开发和托管应用程序？ 越来越多的公司正在采用按需CRM（通过salesforce.com或Oracle CRM on Demand ），通过Rally软件进行敏捷规划，或者通过SuccessFactors或Plateau Systems来进行人才管理系统）
• 集成即服务 - 布米或铸铁已经在提供适配器的大量用或SaaS应用程序之间的集成。 显然，该领域的所有主要软件集成供应商都将很快恢复其报价（ 按需提供Informatica ， TIBCO Silver和Microsoft Azure ）。 但是，令人惊讶的是，开源集成供应商（如WSO2 ）及其生态系统尚未提供真正的云产品

IT运营中的普遍敏捷性

在数据中心购买服务器并进行安装通常需要3个月的时间。 而且我什至没有在谈论安装DBMS集群或设置VLAN。 在同一台服务器上安装多个应用程序可能会导致一些副作用（所使用的软件版本，配置冲突），更不用说组织战了。

IT运营的敏捷性来自于新一代数据中心，绿色IT约束（散热和能源），虚拟化技术（硬件上虚拟机密度不断提高）以及共享基础架构（负载平衡，存储，防火墙，安全设备等）。

通过扩展敏捷连续性以涵盖IT运营，还可以创建敏捷性（这种方法可以称为持续部署）。

让我们看看基础架构的发展速度如何，以及今天如何将其作为服务（基础架构即服务）提供：

• CPU虚拟化 -CPU具有多个内核，新的CPU提供虚拟化指令加速。 您可能需要数十个CPU才能在Amazon ， RightScale ， ElasticHosts ， Rackspace等上运行工作负载。
• 私有云的服务器虚拟化 -硬件服务器现已虚拟化，可以根据需要进行部署和克隆。 Platform VM Orchestrator ， VMware VSphere ， Citrix Cloud Center和Red Hat Enterprise Virtualization Manager是用于虚拟化服务管理的商业工具，因此旨在构建私有云。 私有云可以托管在云中，也可以基于开源平台（例如Enomaly ， Eucalyptus或Nimbus ）
• 虚拟机可移植性 -互操作性不仅与云之间接口的标准化有关，而且与虚拟机的可移植性有关。 DMTF开放虚拟化格式 （OVF）是朝着正确方向迈出的第一步，但这并不是在考虑到Cloud的情况下创建的，因此对标准的战争还没有结束。 与所说的相反，将您的VM从Vmware VMDK转换为OVF，Xen或Amazon AMI，并使其在任何地方运行都是不容易的
• 网络即服务 -必须将网络启用为核心基础结构服务，以提供网络资产（例如IP地址，DNS名称等）的全自动生命周期管理。 通过利用VM明确的策略要求，网络服务应具有敏捷性并了解工作量
• 轻量级执行平台 -当今的趋势是提供一种完全集成的轻量级平台，以作为服务提供（它们称为平台即服务，即PaaS）。 多家公司正在尝试更改软件开发和交付游戏的规则，例如使用App Engine的Google ， 使用Azure的Microsoft或使用AppExchange和Cloud Platform的 Force.com 。 其他的都可以在内部和按需使用，例如Zend上PHP， SpringSource和MuleSoft上的Java，以及Heroku ， Aptana或EngineYard上的Rails。
• 按需数据库 -按需数据库分为两个组：键/值数据库，例如作为Web服务的BigTable和Amazon SimpleDB 。 或关系数据库，如MySQL（在Joyent或Amazon EC2上 ）或SQL Server（ SQL Azure ）
• 云集成平台 -混合云提供商可以创建和管理您的公共云和私有云（例如Abiquo ， OpenNebula ， Elastra或Appistry CloudIQ ）

有关云革命的更多信息，您可以阅读有关此主题的最新CSC Leading Edge论坛（LEF） 报告 。

云推动者和抑制者

在云中，部署和操作可以在同一流程连续性中更敏捷，更好地链接。 但这是否意味着我们可以创建一个应用程序并将其部署在Windows Azure或Google Application Engine上？ 我们是否仍然需要关心应用程序代码将部署在何处以及需要多少CPU来维持负载？ 我们是否仍然需要管理应用程序-ilities，这很耗时，容易出错并且在我的应用程序中需要其他和不必要的代码？ 应用程序的业务和技术事件是否经过精心设计和关联，以提供所需的弹性？ 我想您已经知道答案了。 这可能就是LOB尚未赶上潮流并大规模采用云的原因。

那么阻碍云采用的主要因素是什么？

1. 云技术还不够成熟 -提出的云技术仍然处于beta模式的频率仍然很高 ，主要是专有的，不具有互操作性（可以在此处看到互操作性测试的示例）并且还不适合IT操作（今天它主要针对开发人员） ）。 因此，将带有数据的应用程序从PaaS供应商转移到另一供应商需要大量的工作。 供应商锁定综合症
2. Cloud Technology Research尚处于起步阶段 -欧盟委员会刚刚启动了Reservoir项目，以“为基于服务的在线经济奠定基础”，而HP，Intel和Yahoo赞助了OpenCirrus “旨在支持研究的云计算研究测试平台”在全球多数据中心范围内设计，配置和管理服务”
3. Intercloud尚未完全实现网格化 -在平坦的世界中，每个解决方案都需要从一开始就具有全球影响力。 该领域的主要参与者仍在对其数据中心进行大量投资，并试图在全球范围内安装它们（它们应该是绿色的！）。 敏捷的网络基础架构对于实现云资产敏捷性，可移植性和复制以及创建更高水平的服务（如灾难恢复和/或容错） 至关重要 ，详情请参见infoblox网络研讨会 。 到今天为止，我们在云层之间仍然有很多蓝天。 另外，还没有实现多播的解决方案
4. 尚无大型服务器或数据库可用 -几乎不可能配置大型计算机（例如，具有12个CPU和64 Gb的连续内存）或超大型关系数据库
5. 云成本模型具有弹性 -如今，很难预测云资产的成本，因为它们会适应需求。 很难将按使用付费模型（而不是按高峰模型进行配置）（以及冒过度配置的风险，这意味着利用率不足）很难卖给公司财务和IT审核团队。 而且，既然金融支配着世界，那么在我们让他们有信心之前，他们就会抵抗。 这也是为什么微型公司是云的第一个用户的原因，因为微型公司的结构是灵活的，并且随着业务的增长而增长（它们的预算也是灵活的）。 无论如何，所有研究都表明，按需云基础架构的稳态成本（无长期合同或特定的协商）通常比拥有自己的硬件更重要（但价格将来会下降）
6. 今天，几乎无法实现云服务水平协议（SLA） -关键业务应用程序所有者不想承担任何风险，没有人会责怪他们。 但是，一些研究项目已经启动（例如，参见SLA @ SOI ）
7. 安全性和合规性受到严格审查 -我们正在从数据中心转移到数据中心（私有，公共，混合）。 像往常一样，需要花一些时间使云适应某些特定的严格安全要求（请参阅Cloud Security Alliance ）。 例如，美国政府要求供应商的数据和应用程序应位于自己的土地上（Google刚刚创建了一个专用的数据中心来满足此特定要求）。 欧盟在处理与公民数据隐私有关的任何事情时也非常谨慎
8. LOB组织变革很深刻 -谁来做系统和DBA管理员以前完成的工作？ ITIL如何应对弹性变化？ 如果我遇到故障，我将如何检测到它并做出React？

那些阻碍者推动着该领域的主要参与者首先定义自己的服务，即使需要专有接口或技术也是如此。 他们的目标是尽快占领最大的市场份额并制定标准。 作为用户，这对我的LOB意味着什么？ 今天，供应商锁定的风险太重要了，无法证明采取此举是合理的，尤其是因为它没有有吸引力的成本模型作为后盾。 除TIBCO（尚不清楚如何定价白银）外，其他大多数供应商都采用相同的方法（价格几乎相同）。

避免IT系统性危机

为了灌输更多的竞争并让新的创新和独立参与者脱颖而出，我们必须：

• 说服所有云供应商根据不同类别的用户（政府，教育，工业，国防）及其需求（我们应该以不同的价格定价庞大的计算网格，以及负载均衡的共享Web服务器集，以实现Extranet门户）构建商业云产品等）。
• 寻找合适的组织以确保对成长中的云生态系统进行适当的治理，以期避免将来发生IT系统性危机。
• 无论客户端的大小和位置如何，都可以确保对云资源的公平访问（从在家工作的小型开发人员到拥有数万名员工的国际公司）。 全球云部署将有助于在全球范围内传播敏捷和可持续的IT资源，并有助于缩小南北技术差距。
• 确保云供应商提出的解决方案的可持续性和互操作性，以减少失去LOB在云中进行的投资的风险。
• 向符合法规的云提供商保证一些激励措施（例如减少他们所支付的税款，为他们提供关键市场的一部分，如教育或政府等）。
• 计划并资助数千名失业或将来可能失业的IT人员的培训和辅导（称为“经济学破坏性创造”）。
• 资助并支持强大而独立的开源生态系统（例如刚刚与OSA合并的 Apache或OW2）。 最近收购的开源公司或项目团队的步伐和数量是市场整合的明显标志（SpringSource是一个很好的例子），并将在未来几个月继续。 我们应该保护一些关键资产，并在可能的情况下将其维护在公共领域（例如，关键的Sun技术和产品，例如Java，mySQL或OpenSSO）。

这次，让我们避免不得不跨越云专有解决方案的孤岛，而这会限制业务敏捷性的未来，这些孤岛相互关联以实现最大可能的利润（例如航空公司，为了实现这一目标，今天取消了一些航线），而不是为了实现最好的网状网（就像今天的Internet一样）。 创新还来自可入侵性因素（获取，理解，改进，发明）…

使业务技术能够在云上发光

要求敏捷业务流程的自主利益相关者正在改变业务和IT团队协作和交付的方式。 现有的信息系统是如此复​​杂，以至于几乎不可能使它们对业务需求做出React。 现在是时候吃大象[2]了 ，一次咬一口。 信息技术不再是成功的有效途径。 应该将IT注入业务中以创建业务技术。 如果您遵循一些关键原则，就可以进行顺畅的变更管理和适应组织的发展，从而迈向敏捷世界，其中最重要的一些原则将在下面继续介绍（并沿用了SHINE原则）：

• 小号商场是美丽的 -小团队负责的公司服务的各个方面。 从成立到生产，与负责定义明确的业务领域子集的小型团队（6至10人）一起工作。 因此，如果您想使用云，最好的方法是转向面向服务的方法（如果SOA已死，则采用基于服务的方法）并在垂直组织中实现业务服务。 从上到下都是敏捷的。 使用连续部署，这意味着经常安全地测试和部署您的应用程序。 现在可以进行自动化并推荐了
• ^ h eterogeneity是你的朋友 -你可以自由使用最适合的技术，业务需求，但你会完全负责的主管。 使用您想要开发应用程序的语言，您想要的平台（是否作为服务），所需的人员等等。最后，您将仅对上市时间和服务质量负责
• 我与覆盖整个院落开放API -增加灵活性只要可能，特别是在业务服务或进程的边缘。 明确定义消息的语义，并创建可理解，安全（例如，请参阅Google Secure Data Connector ）和易于使用的界面。 重用开放标准并提出开放API，以使您的服务在其他人的云端闪耀。 还考虑未来的云间接口（例如统一云接口或OCCI ）。 根据业务价值链，还可以动态或静态地安排这些服务，以提供更复杂或更细化的服务（可以本身作为服务提供）
• ñudge你的云 -必要的，以提供最好的服务给您的客户，当创建竞合（合作与竞争）。 亚马逊允许供应商使用其平台并提出他们想要的任何商品的价格。 使用我的平台，使用我的流程，使用我的主数据，增加我的市场份额，让客户和供应商使用我的服务，无论如何都要给我收费，并使我的客户更快乐。 并记住长尾巴，敏捷并不意味着短期！
• Ëlasticity，敏捷，应变能力 -从云计算模式的好处，业务应用和服务应该是（重新）设计（重）建为了将弹性在他们的心脏。 需要弹性来适应短期峰值（弹性）并启用具有计算所需的大量资源的定期批处理作业（敏捷性）

我最近听说了一家闪闪发光的法国小公司Lokad的例子。 Lokad正在提供业务技术，并且专门研究用于销售，需求和呼叫量的预测软件。 借助云，他们能够在一小时内为法国一家主要零售商进行预测计算（由客户强加业务SLA！），而成本却只有几分之一。 Lokad投资了Azure（即使当时仍处于beta版），并确实使用Microsoft Web和worker服务定义重建了其应用程序。 他们能够提供所需的尽可能多的资源（但并不总是像它们想要的那样强大：10个具有2GB的单CPU VM不等于10个具有20GB的CPU计算机），以完成以前无法做的事情（ （由于计算时间而异），甚至现在还支持创建和实施更复杂的算法以提供更好的预测（因为计算时间不再是问题，并且软件体系结构也不相同）。

像IBM这样的编辑器也正在从事SHINE的新业务技术服务。 大规模混搭（M2）是mashup范式的扩展，它“集成了基于Web的存储库中的千兆字节，太字节或PB级的非结构化数据，并使用您选择的非结构化信息管理架构（LanguageWare，OpenCalais等）提取和丰富了这些数据。 。），让您可以在特定的用户定义上下文（例如ManyEyes ）中浏览和可视化这些数据，IBM还开发了一种适应性强的敏捷过程来帮助客户使用M2，首先需要两到三个小时的简介，以识别需求并了解如何最好使用M2。然后，需要1.5天来设置基本服务，而需要2到4天才能完成实施。

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

LOB表示的第一个要求是对业务技术的系统愿景。 您如何使不同的利益相关者访问并了解公司的敏捷和弹性资产？ 接受将解决今天围绕云标准的战争以及当前缺乏互操作性的想法，该怎么办？

我们认为应该发明一种新型的分布式操作系统来实现“及时” IT。 然后，它将让您命令和控制您的云（而不仅仅是一台机器）。 该Cloud OS将能够在云中管理的任何实体上执行操作（如创建服务器，添加数据库，传输数据，部署应用程序等）。 我们预想以下关键实体将由此操作系统管理：

• 服务器 -提供CPU周期
• 应用程序 -将投资组合资产与已部署的软件资产联系起来
• 存储 -提供低级二进制存储（可以是SAN，NAS，内容管理系统）
• SVN-用于管理代码/配置版本控制
• 服务 -作为业务可执行资产进行管理，并交付价值（硬美元）
• 接口 -用于定义可执行资产之间的任何通信
• 缓存 -根据需要可以使用多种缓存工具和技术。 如果平台执行核心的一部分对应用程序可能是透明的
• 事件和规则 -用于启用和控制弹性行为
• SLA-用于定义和管理SLA

让我们以一个简单的示例来表达我们可以设想为Scrum用户故事的控制级别。 该公司将启动一个具有两个应用程序的新项目（一个在内部，一个在需求）。 我们需要运行此项目，并使其在公司云上变为现实。 最好的方法是使用命令行解释器。 因此，第一个目标是要使用一组命令，并在云OS中集成专有的云适配器，以便以正确的API转换命令（似乎我们回到了EAI……）。 为了管理业务技术并提供系统的愿景，我们应该收集有关应用程序产品组合，要部署的应用程序代码，应用程序配置和非功能性要求以及要使用的弹性基础结构的信息。 所有这些都在一个地方（即Cloud OS）（也称为3tera称为meta-OS）进行管理和聚合。

为了用伪代码构建小示例，我尝试重用了云供应商的API中已经可用的一些命令，添加了管理产品组合所需的数据并添加了企业体系结构需求所需的属性。 这里需要的是在多个域中找到最常见的分母：

CREATE DOMAIN myPortfolio               ; my logical domain name composed of two applicationsADD myPortfolio APP1 Critical OnPremise ; APP1 is a critical application - app. portfolio
ADD 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

Cloud OS-回到地面

业务技术创新驱动的虚拟化是整体的（服务器，存储和网络）。 云需要并行和分布式的操作系统能力，这将迫使我们忘记以本地操作系统为中心的愿景（Microsoft Windows Seven可能是其同类产品中的最后一个操作系统）。 我们还应该重用许多有关分布式监视，配置和基础架构动态映射的功能。

一个明显的建议是创建一个特定的轻量级的类似Linux的微内核，该内核将针对云进行优化。 它应该能够在多种类型的处理器上本地运行，并能够运行市场上当前的大多数虚拟机管理程序（或至少通过网络与它们进行互操作）。 每个微内​​核将在每个处理器或CPU内核上运行。 中央系统还将收集数据并动态关联这些数据，以使分布式系统适应当前状态（在分布式系统中收集全局状态并不容易）并在需要时发出远程命令（类固醇上的分布式OSGi）。

胚胎计划已在世界各地启动，以解决其中一些关键问题。 一些最有前途的包括：

• Deltacloud-开源（LGPL）API，抽象了云之间的差异。 该框架使云提供商可以轻松地将其云添加到Deltacloud通用API。 它可以用作Cloud OS的集成层
• Kaavo的基础设施和按需中间件 （IMOD） -提供了一种可掩盖云异构性的应用程序。 所有部署和配置信息都存储在一个文件中。 该文件分为两部分。 第一部分定义了应用程序（层，服务器）的静态构件，第二部分指定了在启动应用程序时IMOD引擎要执行的操作。 以Velocity模板的形式定义动作的流程控制
• Cloudloop-用于云存储的通用开源Java API和命令行工具，可让您在所有主要提供商之间存储，管理和同步数据
• 3tera AppLogic系统 -用于创建私有云。 它是运行Red Hat Linux，Xen和AppLogic编排系统的互连系统的集群。 虚拟机（运行来宾操作系统）和应用程序的基本构建模块（称为“设备”）
• 欧盟委员会资助的XtremeFS-一种新的开源云文件系统，该项目研究如何将对等（P2P）通信体系结构的优势与Akamai等内容交付网络（CDN）的功能相结合
• Process Virtual Machine-一个简单的Java库，用于构建和执行流程图 。 这是所有工作流，业务流程管理（BPM）和编排流程语言的基础

企业架构将永远不会相同

云将迫使企业架构师对弹性系统具有系统的，尽可能动态的愿景。 在专用工具（例如Aris ， Mega ， Casewise ）中静态（或绘制）一些IT景观数据的先前方法将不再可行。 企业架构，应用程序产品组合和基础架构管理的集成是绝对必要的，以保持对域状态的全球视野并了解其对业务价值链的影响。

在自主基础架构上运行的弹性应用程序将挑战设计，部署，测试，记录和维护IT系统的旧方法。 尽管如此，我们仍需要创建挂钩，以使我们的IT足够敏捷以快速制定新的业务决策（在向云或其继任者大跃进之前）。

将来，业务流程的描述，集成和优化将越来越重要，这将在LOBs组织中创造新的工作机会。 相反，技术架构师，基础架构专家以及计划和项目组合经理的工作将越来越交织在一起。

结论

我希望通过应用SHINE的简单原理，您将能够按照自己的步调使用云计算。 了解到云计算仍不成熟，在开发和部署应用程序时可能需要做一些修改。 但是，现在是为企业准备Cloud的正确时机。

从虚拟化到私有云基本上是向应用程序所有者提供自助服务功能的一步。 它增加了另一层抽象，因此增加了灵活性，缩短了上市时间并增加了管理复杂性。 仍需要流程和工具来管理这一层。

使用云的最大优点是您不必构建处理异常峰值的能力。 但是，您可以有针对性地设计弹性需求，并从中受益，从而更快地完成工作或花费很少的成本。

如果我们将云交给IT供应商，因为他们试图说服企业使用它来降低成本（这仍有待证明），我们将再一次失去创建一家持续敏捷的公司和内部机构的机会。只是将IT外部化为敏捷程度更高的外部供应商。 现在是时候建立或倡导可以确保对不断发展的Cloud生态系统进行治理的组织了。 这里的目标是避免将来出现IT系统性危机。

我确实希望在不久的将来，将有一个像我刚才概述的那样的操作系统。 我没有预见到严重的技术集成问题会阻止其实现。 此外，采用一种敏捷方法，对实体的粒度及其功能和非功能属性进行合理的范围划分，可以轻松实现快速获胜。 该操作系统如何能够对几种事件进行动态（重新）React，以及如何避免过度设计，仍然有待研究和讨论。

[1] Forrester首席执行官George F. Colony的“我的观点：从IT到BT”，2006年8月18日，（ http://blogs.forrester.com/colony/it-to-bt.html ）

[2]吃着IT大象，从Greenfield Development到Brownfield，Richard Hopkins和Kevin Jenkins，IBM Press，2008年。

翻译自: https://www.infoq.com/articles/cloud-shine/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1