下载掌阅APP，畅读海量书库
立即打开
当开始在公有云中构建时，你基本上是从零开始：没有现成的云数据中心、没有防护措施、没有财务管理工具和流程、没有灾难恢复或业务连续性计划，只有一张空白的画布。传统的做法是使用数据中心已有的工具、流程和组织结构，并将它们应用到云中，但这通常会导致灾难。
当在云上迁移、重构或创建新的应用程序时，它们会被部署到一个全新的虚拟环境中，这与人们习惯的数据中心环境截然不同。在数据中心中如何管控工作的流程和策略通常经过了多年的发展，伴随这些旧有流程而来的是一大堆从未打算支持在云端运行软件的工具。如果这些工具不是云原生的，或者至少不是“云友好”的，那么要让它们在云中有效地（或者完全地）工作可能需要一个痛苦的集成期。这就给软件开发带来了阻力，还会产生不必要的复杂度，从而增加成本、降低性能，甚至降低弹性。所有这些都会让端到端的软件构建和发布自动化过程带来挑战，有时甚至是不可能的。
IT团队在设计云策略时需要提出的问题应包括：
让我们来看几个例子。在“命令和控制”反模式中，一个常见的目标是保持现有的私有化部署日志方案不变，而不是转移到云原生方案。如果这么做，所有日志都必须通过私有通道从公有云发送回数据中心。这将产生数据传输的成本，并对数据中心产生不必要的依赖项。此外，这些遗留的日志方案通常会依赖于其他的软件解决方案和流程，反过来又会在云端和数据中心之间产生不必要的（有时是未知的）依赖项，从而导致云中断。
还有另一个例子。我的团队在对一个客户的工具进行评估后，推荐了一些可以更好地在云中工作的工具，并建议他们使用更适配云的方案来取代现有的工具。入站网络流量监控是我们建议替换的工具之一，但管理该工具的团队因固守而拒绝：他们习惯使用旧工具，不想管理两个工具。这给在该公司公有云中运行的所有应用程序和服务带来了单点故障。有一天，该工具发生故障，公司所有的云端应用程序也都发生了故障。
这里的教训是，过度依赖不太适合云的工具将妨碍你在云转型上付诸的努力，并导致本可避免的错误和中断。与其留在舒适区，不如着手降低对数据中心的依赖，并有计划地减少任何可能发生的故障。
随着企业对云方法论的重新思考，得出一种新的运营模型能够拉近领域专家间的距离，进而减少以上事件的发生。
多年来一直在构建和运行数据中心的企业常常面临从物理基础设施的采购、安装、维护和运维（“电力VP”思维）到云思维（云端基础设施即服务）的转变。表1-1展示了使用云所需的一些思维变化。事实上，右边的云原生方法论并不是你在云旅程的第一天就能得到的东西，它们代表了你应该争取的东西，以及随着时间的推移应该努力采用的东西。但是如果你的团队一直停留在数据中心的设计思维中，就会失去云所能带来的很多价值。
表1-1：传统数据中心思维与云原生思维的对比
当你买房时，你是在投资一块土地和土地上的所有物理结构，你需要负责所有的维护、美化、清洁、除雪和其他房屋所有权附带的内容。然而当你租房时，你要为你在出租房的居住时间付费，物业维护是房东的责任。租房和买房之间最大的区别是，作为房屋的居住者，你有不同的控制权。
当你使用云时，就是在租云提供商的“房子”，你所管控的内容与在自己数据中心中管控的内容非常不同。对于那些在自己整个职业生涯中定义、设计和实施他们所负责的管控流程和技术的人来说，将一些管控权转移到第三方很可能跟移交你精心修复和翻新的房子一样充满挑战。
审计师和GRC可能是最难以理解云上责任共担的两个团队。他们有一组用于审计物理数据中心的流程和管控措施，并希望能够在云中应用这些精准的流程和管控措施。问题是他们并不能。为什么？因为数据中心是属于云服务提供商（CSP）的，比如亚马逊或谷歌，它们有责任确保你与其他客户的数据安全。你是否希望竞争对手在你运行软件的谷歌数据中心里来去自如？当然不会。
在图1-2所示的责任共担模型中，CSP负责基础设施层的日志记录和审计，而不是客户。一家CSP的熟人曾经跟我说有个客户坚持要拿到CSP的所有日志，他希望将日志传输到他公司的集中日志方案中。客户已经习惯了被要求存储这种类型的信息以用于审计，因此他们根本就不会改变。最后，我不得不解释，在新的责任共担模型中，这些数据将不再对他们可用。他们必须教育他们的审计团队，并调整他们的流程。
图1-2：责任共担模型
需要说明的是，要求客户存储这些日志的政策仍然有效，彻底改变的是如何在云中满足这项政策。如果审计师和GRC团队不能改变思维方式，接受满足政策要求的新方式，他们的公司可能还不如不使用公有云。但是审计师或GRC团队真的能够阻止整个公司去采用云计算吗？
在数据中心的世界里，团队通常围绕与基础设施相关的技能领域进行组织：存储、网络、服务器、操作系统、安全等。在云端，大部分基础设施都是抽象的，开发人员可以通过调用API来使用。在数据中心思维中，如果你需要存储，就要创建一张工单，并让另一个团队执行各种任务来维护物理基础设施，如存储区域网络（SAN）。然而在公有云中，开发人员可以将存储作为一种服务来访问，并且能够简单地编写代码来“置备”必要的存储。
为了构建安全、兼容和弹性的网络，数据中心具备网络团队，它们使用第三方供应商提供的设备、路由器、网关和其他工具。在云中，上述工具提供的大部分特性都可以作为服务来使用。对于云提供商没有提供的网络安全必要的功能特性，作为SaaS或按需付费模式的第三方解决方案可以提供。这些可以直接从供应商或CSP的市场进行采购，而且通常不会购买实体资产。购买软件，每年支付购买总价四分之一维保费的日子已经一去不复返。在云计算中，你只为使用的内容付费。
在云计算之前，我参与的几乎所有的研发都会部署在公司的自有数据中心。每一个技术栈都有负责该技术的专家。数据库管理员（DBA）安装和管理来自Oracle、Microsoft和Netezza等供应商的数据库软件；中间件软件由系统管理员安装和管理，如IBM的Websphere、Oracle的WebLogic和Apache Tomcat；安全团队负责各种第三方软件解决方案和设备；网络团队负责物理和软件网络解决方案。
因此，每当开发人员想要使用不同于标准技术栈中提供的解决方案时，都需要进行大量的论证。必须预先购买解决方案、采购和实施合适的硬件、与供应商敲定合同条款、进行年度维护费用预算，以及为实现和管理新的组件栈进行培训或雇用员工和顾问。
如果你不想受旧有思想和流程的约束，在云中能够更快地完成新组件栈的采用，尤其是当这些组件栈是CSP的原生组件时。例如：
我们假设有一家虚构的大型零售商Acme Retail，它已经在Oracle上标准化了所有在线事务处理（OLTP）数据库的需求，并使用Teradata来满足数据仓库和NoSQL的需求。这时一个新的业务需求出现了，它需要在接下来的4个月里建立一个文档存储数据库。
在旧模式中，采用文档存储数据库将需要新的硬件、软件许可、磁盘存储和许多其他的组件栈。Acme的员工必须花费大量的精力和成本，审批、采购、实施和防护所有相关的硬件和软件。此外，Acme还需要雇用或培训DBA来管理这类数据库技术。
现在让我们看看在公有云中有多么简单。Acme是AWS的一家顾客，AWS提供了文档存储数据库的托管服务。那么上面提到的大部分步骤都被完全地移除了，Acme不再需要担心硬件、软件许可、额外管理数据库服务的DBA或新的磁盘存储设备。事实上，它根本不需要采购任何服务。Acme所需要的只是学习如何使用文档存储数据库的API，然后就可以开始构建自己的解决方案了。
假设Acme雇用了一个咨询团队来交付新特性。咨询师建议购买MongoDB作为首选的文档存储数据库，以满足存储和查询文档的需求。Acme以前没有使用过MongoDB，这意味着它必须走采购流程。然而，在Acme当前的流程集中，不可能在短短4个月内获得批准、获取所有硬件和软件、培训或雇用DBA以及实施数据库。因此，Acme决定利用现有的Oracle数据库（关系型数据库引擎）来解决这个问题。这并不理想，因为关系型数据库不是存储和检索文档的最佳解决方案，文档存储数据库才是专门为该用例打造的。不过，Acme至少可以利用现有的数据库技术在截止日期前完成任务。
以上的决策过程在项目与项目之间不断重复：由于旧有流程的限制，Acme总在不断寻找次优解决方案，技术债务因此也在不断增加。
现在，让我们看看如果Acme决定在公有云中采用数据库即服务解决方案，这一切会有什么不同。
当在云中的沙盒环境中进行了一些测试之后，顾问确定CSP平台上的文档存储管理服务非常适合Acme的需求。他们可以立即开始构建解决方案，因为该数据库已经可以按需付费来使用，并具备自动伸缩功能。
利用组件栈即服务可以将项目的时间轴缩短几个月，它允许你以更低的风险采纳新技术。也许最重要的是，你不必再因为采用新组件栈的传统方式所带来的挑战而做出技术妥协。
使用服务提供商的组件栈为架构师提供了更大的灵活度，对所有IT领域来说，理解这一点很重要。如果他们不理解，很有可能会最终将遗留的约束强加给他们的云架构师，并最终在云上构建产生新技术债务的次优绿地解决方案。