讨论：公有云、私有云、混合云

该小组讨论还以 OTN ArchBeat 随身播的形式提供。

与会人员

Oracle 全球企业架构项目副总裁，经常在 OTN 架构日和其他活动上发表演讲。

Oracle Cloud 主管架构师，负责设计 Oracle 的软件即服务和平台即服务这两个公共的基础架构。

Oracle 按需点播平台副总裁。

Oracle 中间件/应用程序管理和云计算的架构师。

我们在谈论公有云、私有云、混合云时我们到底指的是什么？这些术语究竟是什么意思？

我认为这个问题的答案看似显而易见，但深入讲起来却有点复杂。

公有云是一种脱离办公场所、交由他人管理、为他人所有、以服务的形式提供的资源。

私有云针对的是那些寻求同样的动态灵活性、供应等等，但出于这样或那样的原因，不愿将其置于公共服务的企业。私有云可能完全由企业管理，或者企业也可以找一些支持人员以专用私有云的形式对其进行管理。

混合云是两者的结合体，我认为某些复杂性正是来源于此。混合云有多种不同的类型或模式。有的采用功能分布，即将不同功能置于不同位置，例如企业可能会将开发置于私有云，而将生产置于公有云。

有的采用负载分布，人们通常将其称之为混合云的涅磐，即将一个应用程序运行在两个地方。对于复杂的有状态应用程序来说，同步状态将是一项非常复杂的工作。

还有一种也是采用功能分布，但却将持续工作流或应用程序的不同部分分别置于公有和私有云中。典型的 Internet 应用程序就是将目录引擎置于自有数据中心的私有位置中，同时将支付引擎置于其他地方。而且，这种模式正愈来愈多地应用于企业应用程序，企业可能会在私有云中运行 ERP 系统，同时会从公有云中使用 CRM 或其他类型的应用程序。

我来大概定义一下我们说的“云”指的是什么，这个问题值得多说一点。

“云”这个概念的重要特征之一就是，它是您能以自助方式获取的一组资源。它是自助式的，您可以以统一的方式获取一组统一的资源。这是 DevOps 或 NoOps 运动的一部分。根据云类型的不同，资源也有所不同。从 IaaS、PaaS、SaaS 类型的提供者那里，您将获得不同资源。但重要的是，您的最终用户可以在他们需要时请求资源、自行获得资源、为他们所使用的资源付费以及返还资源。“付费”在公有云中有可能意味着付真实的货币，在部门之间有可能意味着付虚拟的货币。

总而言之，基本的概念就是您能够根据需要以自助方式执行以前需要与 IT 部门人员互动才能执行的操作 — 以构建某种自定义的基础架构。

我认为私有云和公有云之间重要的区别之一体现在控制与安全这个概念上。以往较为追求与众不同、希望拥有更多控制权、更高安全性的这类客户现在可能会更偏向于选择私有云提供的服务。那些较为关注拥有成本、灵活性或可伸缩性的客户往往更偏向于选择公有云服务。

我想这绝对是 Oracle 努力在我们的服务中发挥的优势之一：提供全方位服务、发挥我们软件体系的潜能以及提供各种选择来满足客户需要。这样，那些有着高安全性或定制需求的客户可以选择在其自有数据中心的私有云上运行。而没有这些特殊要求的客户可以选择使用 Oracle Cloud。介于两者之间的客户可以选择在一种云上执行一些操作，在另一种云上执行其他一些操作。

如果您的重要知识产权是以数据而非代码的形式存在的，那么您可能更愿意在公有环境下使用虚拟数据来执行测试和开发，此时数据的安全性并非首要考虑因素，但是，您可能会选择在自有数据中心的私有云上进行生产，这样您就可以感觉到这些数据的整个生命周期完全在您的掌控之下。

把刚刚总结出来的这两个观点结合起来就非常有意思了。

许多人看着现有的开发人员云，心里却想着按需自助式服务能够实现刷完信用卡即可在 5 分钟之内获取 20 个节点。然而，由于 Ajay 提到的那些问题（安全问题、治理问题），难道我真的希望开发人员下载他们希望下载的任何资源、运行可能存在问题的软件吗？不！我希望加入某种企业应有的治理模型。这样，企业云计算的自助服务虽然更可能需要几小时而不是 5 分钟才能完成，但这相对于以前需要几天或几周时间而言已经好很多了。

几种云之间其实是一种密不可分的关系。它起始于管理的角度。即使您的负载和部署暂时介于这两者之间，也可以至少在开始时采用一种统一、托管的方法，从技术管理的角度对性能、可用性、所有典型应用程序管理方面以及流程、合规性以及 Jim 刚刚谈到的治理方面进行控制。我这是从企业经理和 IT 管理的角度来谈它，但我认为这是解决混合挑战的首攻方向。

首先，可以全面查看各种部署，无论是公共的还是私有的。然后让这两者之间的应用程序支柱真正有更多流动性。有些是一伸手就可以够到的，有些则是更长远的想法，可能需要更改应用程序的架构方式才能真正充分利用它们。此时我们不仅仅是在公有与私有意义上谈论混合，因为要实现最大可用性，还可能是任何广泛分布的应用程序部署。

但无论所谈论的是两个不同公共提供商，还是一个公共提供商、一个私有提供商，或者是在单一公共提供商内部，我们所谈论的是能够充分利用提供商的全球规模和所有全球地理分布。我们已经见到了效果。有些人运用得非常好，能够克服 Amazon 不久前发生的一些停机，而有些则运用得不好。

因此从某种意义上来说，这并不是通常认为的那种混合，因为您始终是在一个公有云提供商中，但在分布非常广泛的云基础架构上分布的技术挑战仍是一样的。

许多人假定：“好，我只需各处做点简单的虚拟化就可以得到一个云了”。这里的潜在挑战之一是增加了复杂度，以前我只有一个节点，现在有十个虚拟节点。因此，如果您还是像以前那样行事，则可能复杂度越来越高，而有违您当初希望建立云时的初衷。

正如 William 所提到的，您必须有些原则，如提高标准化水平以便以同样的方式在所有这些不同位置运行同样的应用程序，大力提高集成和抽象水平，以及考虑提升到管理整个该平台上的服务而不仅是体系底层的部件。

是的，完全正确。该模型需要做出权衡。下面是从我阅读相关研究时中摘录的一些我十分喜欢的引言和想法。

传统计算机管理与云中计算机管理的比较。在传统计算机管理中，您非常珍惜您的计算机，它就像您的一个宠物。您为它取名字，在它生病时负责照料它，直到它恢复健康。云中的计算机则像一头牛。您为其编号，它出问题时，只需用另一台将其代替即可。正是这种稳定的心态，使得您可以快速获取资源，启动资源，关闭资源，并执行一些以前因系统需要细心照料和保持完好而从来不敢做的事情。

就像是 A/B 测试，对吧？您现在觉得云上的部署不错了吧，您可以在数分钟内轻松建立这些复杂系统或将其还原回去。在此之前，您需要有一个非常周密的测试计划和非常周密的滚动策略来执行测试，因为在升级时只有一次机会。当建立另一个系统是这么容易时，只需建立一个就是了。然后进行测试。如果不能奏效，则将其还原即可。并行运行也很容易，很棒。

还有另一条类比我非常喜欢（一种直达模型核心并解释了为什么要有这种既不见得轻松也无必要每个人都要进行的大规模迁移的原因）— 出自 Pat Helland，Helland 先生就职于 Microsoft，他在分布式系统社区已有很长一段时间。他把云比作套房公寓并把传统数据中心比作生活住宅。

搬到套房公寓，您可以享受高效率和非常棒的服务。您可以住在视野开阔的摩天大楼。有人给您倒垃圾。随时有人为您提供极好的服务，但同时您也必须放弃一些东西。不能再在院子里养鸡，也不能把房子刷成粉红色。因此您获得的服务比以前强很多，并获得按需使用的弹性和可伸缩性。但必须放弃的事情之一是完全控制。您必须习惯统一和标准化，但与这些限制相伴的是，您可以极大地提高可用服务的品质。

我想知道在采用周期中开始称之为牛计算是不是一件非常遥远的事情？

如果考虑到那么远，那话就长了。

迄今为止，在描述所有这种情形时，您们使用了汽车类比，还提到了粉红房子、牛、小猫什么的......

您是要我们再去找一个吗？

我们还是不谈这个话题吧。

迁移到云时的另一个思想转变是不要再考虑单个事物而是要开始考虑事物群。也就是，不再考虑牛，而是考虑不同的牛群。如果您是一个大农场主，则有多个农场要管理。

当您迁移到云计算时，不再以单个计算机为对象，不再给计算机命名。但要开始考虑执行特定功能的机架、区或模块，或机架组。作为动态资源管理的资源池。在应用程序中，开始做同样的事情。您不再考虑 20 个必须单独安装的不同应用程序，而是开始考虑设计模式、架构模式，并尝试分组和作为一个过程安装整个应用程序而不是分为 20、30、50 个不同步骤。

我越来越认为上升到考虑组、区、池和模式是迁移到云的一个重要思想转变。

我们还将见到各种相关人带来利益与易用性之间的更加平衡。当人们要托管自己的软件时，我们将为其构建软件平台，为他们提供所需的东西以及想要的所有特性。我们尝试满足他们的请求。当谈到软件平台现在是具有两个非常不同的相关人（用户和将运行它的人，无论是在公共或私有设置中）的东西时，则当您构建和定义该平台以及定义这些架构模式时，您确实必须要考虑它们对两方的影响。

不能只强调“哦，这能大大提高开发工作效率”。因为您必须查看等式的背面，这对一个尝试以绝对无需手动管理的完全自动化且非常资源高效的方式托管的人意味着什么。在定义应用程序接口、定义应用程序模式时所做的某些权衡是不同的，因为它们还受托管和操作方面以及使这些尽可能高效的要求的严重约束。

当您提到用户、云操作者和构建者等角色时，就有那么点意思了。云潜在地创建一个重构的需要和需求 — 不仅是在硬件和软件方面，而且还在谁使用什么的角色和标识方面。您插入了一个中间层。不仅仅是引入物理系统的人，还有系统操作员和最终用户。现在您有了云操作者、云开发者，您需要定义几组新的角色，并且在某些方面其定义是对其他角色的分区，即中间层。这是对经典提供者与消费者模型的修改。

现在您有了一个提供者和消费者链。我有一个云基础架构的提供者；消费者是平台开发者。平台开发者成为应用程序的提供者。应用程序是为作为最终消费者的最终用户提供服务的提供者。但您必须要考虑这些角色以及谁在云中负责什么。

因此，基于您的描述，听起来甚至像“范式转换”这样一个非常陈旧的词就可以非常贴切地描述这种情况。我们所谈论的显著变化不仅是技术层面的，而是关于企业 IT 的组织方式。

它至少在规模上是一个范式转换。我们以前一直在做这些事情。倒回 20 年 — 抽象、设计、模式、虚拟化，这是 IT 最近二三十年的核心功能。但现在是将这一切聚合在一起，并真正考虑将您的业务提升到一个新的水平。过去手动需要数天时间完成的任务现在通过脚本只需要几分钟即可完成。您以前应付一台计算机要花费数小时，现在只需几分钟即可应付一百台计算机。

这就是范式转换。的确需要您以不同方式进行思考和操作。但很多事情其实都是您一直在做的。

我同意。虽然云的早期概念始于虚拟化的概念以及某些整合的概念，但无论是从 IT 的角度还是从 IT 所提供服务的消费者的角度而言，现在的焦点转移为：“云可以为我的业务做些什么？”早期的问题是：“云可以为我提供什么 IT 服务？”大多数讨论是关于将资本费用转移为运营费用，这是在两年、三年、四年、五年以前的事了。

随着大多数此类公有云（针对性非常强，非常专注于应用程序，它们非常专业化、非常标准化）的出现，消费者对云有了不同的预期：“我将如何开展业务？我将如何交互？私有云与公有云之间有什么集成服务？如何更好地执行分析？如何更好地进行开发？因此这是关注点的转换。我认为这也是前面谈到的观点：现在不仅涉及系统管理员和应用程序管理员和数据库管理员。还将涉及不只是为基础架构还为业务提供监督和管理服务的管理员。

是的，最早提及“云计算”的场合之一是大约 6 年前在 Wired 的 Eric Schmidt 访谈中，内容是关于 Google 构建了什么。但他们构建的方式与运行传统应用程序的方式并不相同。他们构建的方式是运行其业务所依赖并享誉世界的大规模索引引擎。因此 Ajay 刚才提到的内容很重要，云能够使您基于可用的资源规模在分析、业务分析、分析消费者行为或建模规模等方面做些以前无法做到的事情。

在本访谈中，您四位介绍了采用云将给企业带来的一些相当广泛的变化。随着采用的进行，这种影响将如何继续？5 年或 10 年后企业会变成什么样？

一切都将是混合云，IT 部门可能变成多个公有云和私有云的代理，而不是单一的开发者。

我正看到一种新架构的兴起。除了专注于 IT 层的资源整合和优化外，新架构将支持混合模型，它更多关系到跨越多个云模型的协作。它更多的是关于如何在云中为许多移动应用程序、许多社交应用程序保持移动性，然后最终使云成为分析中枢。因此我开始见到在协作方面、移动性方面、社交和分析方面发生这四种变化。

真实的答案是，我不知道。5 年后，许多我们现在熟悉的东西都会或多或少发生变化。更多移动性，甚至更多虚拟化，包括公有云提供商托管的虚拟化。我认为还会有许多我们现在见到的应用程序，要么是因为它们未发生变化，要么是因为它们虽然发展了但还是用于解决跟当前同样的问题。但从全局上看，一切看起来就完全不同了。肯定会有新种类的应用程序，因为它们将用于移动及其他使用情形，但更重要的是因为它们将利用新的、更高的抽象模型，这将给应用程序用户带来更高效的整体托管体验。

我所不知道的是，与 SaaS 相比，有多少会转向 PaaS？很明显，我们将隐藏越来越多的基础架构底层技术。但人们编写的代码是否会与他们今天所编写的代码非常类似 — 只不过是针对带新应用程序架构的新框架？或者说，我们是否离我们一直追求的不用再编程、只配置一下即可的梦想更近了呢？所有功能都以过去称为模块和软件包的形式提供，现在则为可以订阅的 PaaS 服务。可以对这些服务进行配置、集成，直至无需编写任何代码即可得到应用程序。

很明显，这只能是不切实际的梦想。但云可以让我们离该梦想近到什么程度呢？在何种程度上我们将从非常普通的应用程序托管平台（在此可以运行应用程序、可以运行 web 应用程序、可以存储数据、可以发送消息）迁移到可以称为 SaaS 或 PaaS（您可以使用的非常专业化的平台、应用程序服务）的这类远比以前更丰富的环境中呢？

针对这些非常专业化的服务编写的应用程序是不是会看起来不同？我认为在 5 年内，将会有一个大变化。5 年后我们将在这个方向上走多远？

结合 William 和 Ajay 刚才提到的两点可以看出，当您开始转变时，您将不必开发、关注、维护和管理商品化的服务（应用程序），而是将其移到某种云上，并且越来越将该服务作为软件即服务来消费，不必再将任何内部开发工作专注于竞争差异化的应用程序、业务分析、移动人力管理等等。因此，最终您会将这些事情分割成变得更抽象、更商品化的东西，使得您不必专注于可能仍在忙于开发的差异化业务功能。

我喜欢这种观点。这有助于思考在核心竞争力和差异化与越来越多的编写自己的代码实在没有意义的想法之间做出区隔。我认为这是对其进行组织的一个好办法。

您可以为架构师提供什么建议或推荐来帮助确保他们可以在此浪潮中乘风破浪，并随着这一潮流的推进在云行业中占有一席之地？

正如 Jim 所说，他们需要认识到自己是否处于真的必须创建新的东西、创建特殊的东西、创建必须优化且必须自己拥有的东西的情况。他们能自我克制，尽管您可能是能够构建伟大作品的优秀架构师，但不值得那样做。价值定位并不在于此，您应真正努力重用已有的东西，甚至尝试将需求和资源可用性相对应，因为您的可用资源最好专注于其他领域。

我不能确定相对组织中的其他人，这有多少是架构师的责任。但我认为能够做出这种决定并选择正确的架构和正确的工具集将是在该环境中取得成功的必要条件之一。

我们经历的转换之一是从批处理转换为连续处理。现在我们将从前台供应转换为连续动态供应。因此架构变成一个连续过程。

在旧办法中，您将构建前台架构，因为正如 Mark 前面所谈到的，您与特定计算机有密切关系：为该计算机命名且在该计算机上运行应用程序。如果该计算机出现故障，则必须修复该计算机。所有该架构在整体项目生命周期的早期阶段完成。

而到现在，该架构被部署到不同位置。您有许多前台完成的架构，目的是创建基础架构和平台、构建云和平台资源，或安装软件即服务。但然后执行对运行时架构的后期绑定。此时是动态重新供应资源的机会，将新业务工作流中先前内置的应用程序组件聚合在一起。这再次回到 James Martin 所说的最终用户计算。您有能创建运行时工作流的最终用户架构师。

另一件事是有些架构甚至在您做出购买决定之前就已经完成了。你看看我们集成设计的系统就会知道，中间件云服务器 Exalogic 和数据库云服务器 Exadata 自带了许多您用于构建于数据中心的架构，这些结构已由供应商构建好了，您可以作为一个整体购买它们。因此现成的架构比比皆是，但它们都是以前架构的延续，而不只是一次谨小慎微的运用。

变化之一（同样，假设是云或因为架构的规模和复杂度）是在体系各种级别使用了集群技术。自下而上（像在网络中一样）直到应用程序，现在能够提供对某种高可用选项的集群已经成为一项基本要求。因为云要求提供按需供应和按需提供容量。当您将这些要求转换为架构设计原则时，这将转换为在所有级别对集群技术的需要，以便可以提供想像或实际的按需提供容量的能力。这是其一。

其次，我在架构转换中所注意到的还有对提供自助服务选择的需要。假设有供应软件，以前是可以花 21 天时间来供应新硬件的。现在最终用户希望有可自助的选择。这不再只是一个信息板了。这是一个设计原则，这是因为您需要更改架构以便在开始提供其中一些特性时能够区分什么是用户定义视图、什么是内部视图以及什么是业务视图。

这便是我开始想到的两方面。应该还有许多其他方面，但我认为这两个是最重要的。

这里的焦点问题是 API。这是一个非常明显但尚未充分了解的领域，着眼于聚合和管理一组 API，能够在它们之间保持一致性以真正实现管理良好、监视良好和编排良好的应用程序进程。虽然我们已经获得所有组成部分，但我认为与几年前相比，还是非常、非常不成熟。

作为架构师，您的工作就是了解哪些是您实际构建的可增添独特价值的东西，并找到正确的构件来进行搭建。对于我们这些提供云的人来说，挑战在于找到正确的工具包来武装这些架构师，对不对？因为与住宅的想法相比，构建在套房公寓上时您必须放弃某些东西，但同时获得了这么多非常棒的服务。但这些服务只有在它们是人们需要并且可以使用的服务时才是非常棒的。如果您对其强加限制但并不为其提供良好的服务，则是迫使他们搬到贫民窟。

因此作为云构建者，我们的挑战是通过使服务统一化、易于使用并真正对各种各样的用户可插拔而构建越来越高级的服务，以在越来越高的抽象层级从外部获得正确的工具包。

IaaS 概念一直最易于采用的原因非常明显，因为它最接近于人们习惯使用的东西。这一过去的抽象远远更加卓越，但它尚未完全发展，至少未均衡发展。因为该抽象级别更高，您必须放弃更多才能达到该级别。因此难以找到最佳位置：“是的，这给了我多很多的东西，我愿意放弃我过去所拥有的东西”。我认为我们尚未找到 PaaS 层的魔法最佳位置。

有许多有趣的东西引起了关注，但没有一个达到 80% 的用例。是否能够达到 80% 用例或者它是否真正意味着总是将有各种 PaaS 想法和平台将非常有趣。

这些观点在讨论中引入了若干设计原则。正如 Mark 刚才所说，什么才是正确分类级别？随着抽象级别的提高，您必须将各组物件构建在一起。因此您开始作为一个架构师从可重复设计模式和模板角度来进行思考。您所考虑的不是十个单件，而是一块一块的东西。因此，软件管理工具以及您思考设计的方式将使您考虑安装一个架构而不是安装十个不同的单件。

我认为还有一种转换，即封装组件、找到架构组件的正确规格，并将架构模式转换到此新的物理世界。Ajay 提到了集群；您必须在云中创建一种构建集群的方式。如果您过去是在自供应此特性，它需要彼此对话的专用计算机。您可以构建一个集群，一个轻量型集群，来平衡环境中两个节点的负载。但如果是在动态环境中这样做，则无法确定您刚供应的这两个虚拟机是在同一计算机上还是在不同计算机上。

因此，在云中，必须创建使用池、域或区域的概念，以使您可以在虚拟世界中构建您先前在物理世界中所构建的东西。