动态基础设施平台简介

本文将介绍各种类型的动态基础设施平台，这类平台为置备和管理核心基础设施资源提供了基础。我们的目标是理解为了有效地支持基础设施即代码，平台需要提供哪些典型能力、服务模型以及功能。

1、什么是动态基础设施平台

动态基础设施平台是提供了计算资源（具体包括服务器、存储和网络），并且支持程序化分配和管理这些资源的系统。

表 1 列出了不同类型的动态基础设施平台及示例。以 AWS 为例的公有 IaaS（基础设施即服务）和以 OpenStack 为例的私有 IaaS 产品是众所周知的例子。但基础设施也可以使用诸如 VMware vSphere 的虚拟化系统进行动态管理，尽管这些虚拟化系统不符合“云”的定义（本文稍后将给出“云”的定义）。还有一些组织用诸如 Cobbler 或者 Foreman 之类的工具自动化置备和管理裸机硬件。

表 1：动态基础设施平台样例

动态基础设施平台是云、虚拟机还是裸机都不重要，重要的是可以用脚本和工具自动地创建和销毁基础设施中的元素，报告它们的状态并管理元数据。

本文稍后将会讨论不同类型的平台以及如何选择平台。

实现你的动态基础设施平台

尽管像 AWS 这样的公有基础设施云是动态基础设施平台最知名的范例，但许多组织实现了自己的私有基础设施云。本文侧重于介绍在已有的平台上构造基础设施，因此不会讨论如何构建你自己的基础设施平台。尽管如此，本文还是会帮助你理解基础设施即代码对平台的要求。

2、对动态基础设施平台的要求

基础设施即代码的意思是如何把基础设施当作软件系统，这就意味着动态基础设施平台需要具备某些特征。这个平台需要具备如下特征：

• 可编程；
• 按需获取；
• 自服务。

接下来将会详细讨论这里的每个特征。

NIST 定义的云的特征

美国国家标准和技术协会（NIST）发布了关于云计算的精彩定义。它列出了云的 5 个基本特征：

• 按需自服务（置备）；
• 广泛的网络接入（可以通过“标准的机制”从网络上接入）；
• 资源池（多租户）；
• 快速的弹性伸缩（可以快速甚至自动添加和删除元素）；
• 可度量的服务（可以对资源的使用计费）。

动态基础设施平台的定义要比云宽泛一些。资源池不是基础设施即代码的要求，也就意味着计费不是必需的。

2.1 可编程

动态基础设施平台必须是可编程的。用户界面是很方便，而且大部分虚拟化产品和云服务商都会提供。但是脚本、软件和工具必须能够与平台交互，这就需要可编程 API。

即便使用开箱即用的工具，大部分团队最终还是至少写了一些自定义脚本和工具。所以基础设施平台的 API 必须能够好好支持团队习惯使用的脚本语言。

大部分基础设施平台通过网络 API 暴露其管理功能，其中 REST API 因其易用性和灵活性而最为流行（见下图）。

基于 REST API 编程或者编写脚本相当灵活，但使用封装了 API 细节的特定语言类库也会很有帮助。这些库提供了类（class）和结构（structure）来表示基础设施的元素以及对它们的操作。动态基础设施平台的开发者通常提供至少几种语言的 SDK，还有一些开源的项目为多个平台提供了完备的 API，例如 Ruby 的 Fog 和 Python 的 Boto 库。

脚本示例：使用动态基础设施平台 SDK

例 2-1 使用了亚马逊 AWS Ruby SDK 来创建一个 EC2 实例。

require 'aws-sdk'

@client = Aws::EC2::Client.new(:region =>  'eu-west-1')

@client.run_instances({
  image_id: 'ami-903686e7',
  instance_type: "t1.micro",
  min_count: 1,
  max_count: 1
})

@client.describe_instances()[:reservations].each { |reservation|
  reservation[:instances].each { |instance|
    puts "Instance #{instance.instance_id} is #{instance.state.name}"
  }
}

这个脚本首先用 API 创了一个 client 对象，这个对象打开了一个 AWS 认证的会话。它从在脚本运行之前就设定好的环境变量中读取了 AWS API 密钥，然后透明地完成了认证。

run_instances 接口调用指定了用来创建新实例的 AMI、实例的大小，以及启动多少个实例。

这个脚本接着调用 describe_instances 接口，列出这个账户在该区域拥有的所有 EC2 实例。它会打印出所有实例的 ID 以及状态。

2.2 按需获取

对于基础设施即代码来说，动态基础设施平台支持资源的即时创建和销毁非常关键。

这看起来理所当然，但实际上却不总是这样。一些托管服务提供商和内部 IT 部门声称他们提供的是云服务，但是却需要提出申请，并实际由人来完成这些工作。对使用基础设施即代码的组织来说，其托管平台必须能够在几分钟甚至几秒内满足置备请求。

计费和预算的结构也需要合理设计，以支持按需、累积的收费。传统的计费是基于以月或年计的消费承诺。动态基础设施不应需要长期的承诺，计费周期最多按小时计。

组织可能会做出购买或租借固定硬件池的长期承诺。但是当从这个池中置备虚拟实例时不应该有额外的花费，特别是长期花费。

2.3 自服务

自服务在按需获取之上对基础设施平台额外增加了一些要求。基础设施用户不仅应该能够快速获得资源，还应该能够依照自己的需求调整和定制这些资源。

这和中央式团队（或者一组团队）为需要基础设施的团队设计方案的传统方式截然不同。在传统方式下，即使是新建 Web 服务器这样的常规需求也会涉及详尽的申请表格、设计、规格文档以及实施计划。

这就像买了一盒子乐高积木，但是却让店员来决定如何组装。这阻碍了需求团队获得所使用基础设施的所有权，也阻碍了他们学习如何按照自己的需求改造并逐步改进基础设施。

随着云的出现，有些中央式基础设施团队提供了自服务资源，但是选项却很少。例如团队可以创建 3 种类型的服务器：Web 服务器、应用服务器和数据库服务器；其中安装的软件都是特定版本，且不能定制这些服务器。

这就像只能买事先组装好的乐高积木玩具，而且是粘在一起的。对于需要定制方案的团队，比如要为应用程序优化 Web 服务器的团队，这于事无补。对于需要全新方案的团队，比如要让软件运行在另一个不同应用服务器上的团队，可能就更不走运了。

基础设施即代码假设并要求团队使用脚本和工具自动化地指定、置备并调整资源。这让使用基础设施的团队能够围绕他们的需求进行调整和演进。

基础设施即代码为被迫扮演守门人的中央式团队提供了其他的选择。基础设施用户拥有能够轻松、常态化地修改其基础设施的能力，意味着他们能够快速地修正错误。此外，针对变更的自动化测试和预发布，可以降低中断其他服务的风险。

3、平台提供的基础设施资源

基础设施管理拥有许多活动部件。动态基础设施平台提供了 3 种主要的基本组件：计算、存储和网络。如下图所示：

大部分平台提供的服务列表远远超出这 3 种，但其他服务几乎都只是这些服务的各种变化（例如不同类型的存储）或者在它们之上的服务组合。例如服务器镜像管理（支持计算的存储）、负载均衡（网络，可能基于计算实例）、消息（网络和计算）和认证（在计算实例上运行的应用程序）。甚至像 Kinesis 这样无服务器的计算服务，也是通过在常规的计算资源上运行任务来实现的。

3.1 计算资源

计算资源就是服务器实例。任何动态基础设施平台都能创建和销毁虚拟机，还有一些服务和功能让服务器管理更容易、更强大。

构建、配置和管理服务器的系统和流程占用了基础设施团队大部分的时间和注意力，因此，大多数云服务器管理的书籍，其内容都会专注于这些方面。

3.2 存储资源

虚拟化基础设施消耗了数量惊人的存储 —— 动态创建服务器吞噬磁盘空间的速度非常惊人。基础设施平台需要为服务器、快照、模板等分配磁盘空间，同时还要使运行在这些服务器上的应用程序和服务有存储可用。

云平台需要透明地管理服务器资源的磁盘资源分配 —— 虽然这是平台的实现细节，但是创建服务器的人或者流程不应该考虑它存储在哪里。虚拟化平台可能不会透明地提供存储，所以置备服务器的脚本可能需要查找空间足够的存储池，然后将其分配给新的实例。

即使服务器空间的分配是透明的，但仍然会有些局限。有些可能是硬性的局限，取决于你的组织在私有云上挂载了多少物理的磁盘空间。有些可能是预算的局限，特别是使用公有云服务时 —— 只要你的信用卡能扛得住，它可以交付惊人的磁盘空间。

因此，基础设施团队管理好磁盘空间的使用非常重要。至少需要将用量和费用信息通过仪表盘清晰地展示出来，这样人们就知道什么时候应该检查并剔除不需要的资源。清理旧模板和快照的自动脚本会很有用。

除了计算资源所需的存储，动态基础设施平台还需要为运行于其上的服务和应用程序提供存储。大部分云平台提供两种类别的存储服务：块存储和对象存储。

1、块存储

块存储卷可以像本地磁盘一样挂载在服务器实例上。云平台提供的块存储服务的例子包括 AWS 的 EBS、OpenStack 的 Cinder 和 CGE 的持久磁盘。

服务器实例通常有一个根卷（root volume），这就是服务器启动和运行的地方。但是服务器也可以挂载和卸载额外的持久化卷（persistent volume）。它们的存在可以比某个特定服务器的生命周期还长，这对于管理持久化数据和连续性策略特别有用。

块状卷看起来是一个本地的磁盘驱动器，但是理解这层抽象背后的实际情况很重要。这些磁盘卷通常是从网络存储中分配的，所以可能有时延的问题。最好的方式是研究其实现方式，运行测试来模拟你的用例，并且调整配置和使用存储的方式以获得合适的性能。

2、对象存储

许多云平台提供对象存储服务，其中的文件可以在基础设施的不同地方存储和访问，甚至可以公开使用。亚马逊的 S3、谷歌的 Cloud Storage、Rackspace 的 Cloud Files 以及 OpenStack 的 Swift 都是此类存储。

对象存储通常是作为长期存储设计的，比块存储的可靠性更高、成本更低，但是时延会更高。它适用于存储需要从多个服务器上访问的制品，块存储与之不同，只能从挂载它的服务器上访问。

3、网络文件系统

基础设施团队经常需要在多个服务器实例之间更直接地共享存储。一种方式是使用像 NFS 或者 SMB/CIFS 之类的文件共享网络协议。服务器实例可以挂载本地或块存储，并让其他服务器挂载和使用。早在虚拟化环境出现之前，人们就一直在使用这种文件服务器技术了，但是决定在虚拟化或云化的基础设施上使用这些技术之前还是要小心求证。

如果“本地”的文件系统本身就是从网络上挂载的，再在网络上共享这个文件系统会增加一些无谓的开销和复杂度。在云主机上使用传统的网络文件系统也产生了额外的管理复杂度和开销。这些文件服务器技术不一定能够很好地处理经常添加和移除的文件服务器节点，使得连续性面临重重挑战。

诸如 GlusterFS、HDFS 或 Ceph 的分布式和（或）集群式文件服务工具的设计使之更适合在动态基础设施中使用。它们确保了文件在多个服务器节点间都是可用的，也能更平稳地应对服务器节点的添加或移除。但是也不要假设这能完美解决问题，你不仅一定要对性能和延迟进行测试，而且还要针对集群变更的影响以及失败场景进行测试。

在决定使用何种特定的技术和工具之前，想清楚使用场景。我看到过至少一个团队实现了复杂却脆弱的 GlusterFS 集群，仅仅是为了实现容错，也就是当第一台服务器出故障的时候，另外一台灾备服务器能够确保数据继续可访问。直接使用平台内建的服务，如块存储复制，通常更加简单、可靠。

3.3 网络资源

动态基础设施平台需要管理内部元素之间以及与外部网络的网络互通。在基础设施中添加和删除服务器，需要更新网络路由、负载均衡池和防火墙规则。

大部分虚拟化或者云化的基础设施平台都提供动态、虚拟化的网络来处理网络互通。然而这些平台通常都安装和运行在拥有自己网络基础设施的更大资产之上。为了让动态基础设施平台中的元素和其他部分无缝地在一起工作，需要对接周边的网络。

很多时候，可以直接通过静态的方式配置周边网络，将流量转发到基础设施平台。当外部网络比较简单时，这就可以工作得足够好。像安全、路由和负载均衡这样复杂的逻辑可以由动态平台处理。目标是避免为了支持动态基础设施的变更而对网络基础设施进行手动变更。

当然，自动化配置周边网络也是可能的，这样就能够容易地处理动态基础设施的变更。这给网络资产带来了基础设施即代码的所有好处：可重复性、持续测试以及一致性。

网络设备供应商正在改进他们对软件定义网络的支持。有些设备也许不能直接和虚拟化或云平台对接，但是基础设施定义工具可以用来编排不同的平台，从而针对计算资源的变更对网络定义进行相应的修改。

自动化网络设备配置

虽然供应商已经开始支持软件定义网络，但很多已有的网络设备还是不易于自动化配置。很多网络团队习惯于在命令行界面手动修改配置，这样做有几个明显的缺陷：

• 很容易出错，潜在地引发宕机；
• 不容易确保设备之间的配置是一致的；
• 依赖备份来重现配置，不容易跨设备进行移植；
• 即便是常规的变更，也需要由很了解特定设备的人来完成。

采用了基础设施即代码的团队会寻找自动化配置的方法以绕开这些问题。首先需要理解特定设备的不同配置方式，然后考虑如何自动化管理设备的各种选项。

大部分网络设备有导入配置文件的选项，通常是通过 TFTP。在这种情况下，可以把配置文件签入 VCS 系统中，并使用 CI 或者 CD 服务器自动将其应用到设备上。

一种更精巧的方法是在上传配置文件之前动态地生成它。这允许对网络和其余的基础设施一起进行自动定义。例如，在设备添加时设置防火墙和负载均衡的配置。

不管采用何种方式，拥有能够自动应用配置并进行正确性测试的测试设备都是必要的。这样可以应用变更管理流水线。有时一些特定的设备太过昂贵，让团队没法承担测试实例。在这种情况下，任何负责任的团队都应该确保能够对基础设施的关键部分做例行测试。

4、动态基础设施平台的类型

随着越来越多的供应商和初创公司加入，构建动态基础设施平台的方式在不断增加并变化着。下面的内容涵盖的分类可作为一个有用的起点，帮你进一步考虑适合于所在组织的方式。这个分类大致基于本文前述 NIST 云定义中提及的云部署模型。

4.1 公有 IaaS 云

公有云是由供应商构建和运行的标准云服务。计算资源会在供应商的客户之间共享，你只需要为自己使用的部分付费。例子有亚马逊的 AWS、微软的 Azure、Digital Ocean、谷歌的 GCE 和 Rackspace Cloud。

4.2 社区 IaaS 云

社区云是为有限的客户群体构建和运行的云服务（例如为政府部门服务的云）。云服务可能会为了满足这个群体的特定需求做一些调整，例如遵循某个安全标准。它也有可能对访问进行限制，比如确保不能在与社区外部客户共享的系统和硬件上存储或传输客户数据。

取决于具体的商业模式，可能运行社区云的供应商不管实际的使用量，只按照总体的可用容量收费；也可能每个客户只为自己使用的容量付费，未使用的容量就由供应商负责处理。

4.3 私有 IaaS 云

私有云是为单个组织的多个客户（例如公司内不同的部门或团队）构建和运行的云服务。可能会有供应商为该组织构建、运行甚至托管私有云，但是其资源不会和其他组织共享。即使并不是所有的资源都会被占用，公司也一般为整个可用的容量付费。根据各部门的需要和预算，公司可能会有内部的收费或者容量限制。

和所有的云一样，私有 IaaS 云也会以自服务的模型允许客户自动地按需置备资源，这些资源会被自动地创建和销毁。一些组织搭建了不具备这些特征的虚拟化基础设施，却也称之为私有云，但实际上这只是手摇式虚拟化。

私有 IaaS 云服务产品包括 CloudStack、OpenStack 和 VMware 的 vCloud。

云服务的类型：IaaS、PaaS 和 SaaS

术语 IaaS、PaaS 和 SaaS 可以用来理解云服务的不同服务模型。从允许多个用户共享计算资源这点来讲，它们每个都是云，但是其用户却截然不同。

NIST 对于这三个服务模型做了非常清晰、有用的定义。现描述如下。

软件即服务（SaaS）

在最终用户之间共享的应用程序，可能是面向最终用户的，比如网页版的电子邮件软件。但是实际上有一些 SaaS 产品是面向基础设施团队的，包括监控甚至配置管理服务器。

平台即软件（PaaS）

让开发者构建、测试并托管软件的共享平台。它抽象了底层的基础设施，这样开发者就不需要操心应用程序或者数据库集群应该分配多少台服务器，因为平台都已经搞定了。许多 IaaS 云提供商提供的服务本质上是 PaaS 的服务元素（例如亚马逊的管理数据库服务RDS）。

基础设施即服务（IaaS）

共享的硬件基础设施，系统管理员可以用其为各种服务构建虚拟的基础设施。

4.4 反模式：手摇云

手摇式虚拟化基础设施是指使用虚拟化工具来管理硬件资源，但是这些资源没有以自服务或者动态的方式提供给用户。我曾看到有组织用昂贵的虚拟化软件这么做，甚至使用了像 VMware vCloud 这样具备云服务能力的软件。他们保留了陈旧、中央化的模型，需要服务器的用户必须填写请求表单。IT 人员会按照 SLA 花几天时间创建每个服务器，然后为用户提供登录细节。

不管使用了多么昂贵、先进的软件，如果服务模型既非动态也非自服务，那么它就无法支持基础设施即代码。

4.5 混合云服务

简单地说，混合云就是指一部分基础设施运行在私有云上，另一部分运行在公有云上。有一种严格来说不算混合云但也很常见的做法，就是把一些服务运行在云化的基础设施上，再集成一些以传统方式管理的基础设施上的服务。

这种混合基础设施的出现有下面这些原因。

• 因为监管或者安全需求，一些数据需要保存在更为受限的环境之中。
• 一些服务有可变的容量需求，托管在公有云上充满吸引力；另外一些服务则相当固定，没有必要运行在公有云上。
• 将已有服务从传统的基础设施上迁移出来的投入也许没那么合理。如果组织仍处于采用公有云的早期阶段，那就更是如此了。但是在很多情况下，可能有一定数目的服务永远不适合迁移到公有云上。

4.6 裸机云

有了虚拟化基础设施，多台虚拟服务器可以在单台物理服务器上运行，而且可以根据需要在物理服务器之间切换。这有助于最大化利用可用的硬件。但是在很多情形下，操作系统仍然需要直接运行在硬件而不是虚拟机上面。幸运的是，即使在这些情形下，依旧可以应用基础设施即代码。

对于给定的应用程序或服务，有很多原因可以解释为何在硬件上直接运行也许是最好的选择。虚拟化增加了性能开销，因为它在应用程序和所使用的硬件资源之间增加了额外一层抽象。

在一台虚拟机上运行的进程有可能影响运行在同一台主机上的其他虚拟机。举例来说，当一台虚拟机上的数据库执行密集的操作时，它可能独占了 I/O，这对于其他 VM 来说可能是个问题。这种类型的竞争对于需要保证一致性能的应用程序来说非常不妙。

甚至连抽象本身都可能会引起问题。比如软件假设挂载的磁盘是本地磁盘，但实际上磁盘是从网络上的 SAN 挂载的，这可能会产生问题。

当然，即使进程在虚拟机上运行得很好，宿主系统本身也需要好好地管理。基础设施即代码的实践可以帮助保证 Hypervisor（虚拟机管理程序）和基础设施平台的管理服务一直处于一致、易重建、全面测试、已更新的状态，就像基础设施的其他元素一样。

综上所述，团队需要能在硬件层运行的自动化动态基础设施平台。它需要拥有本文前面提到的能力，包括能够置备和分配计算资源、存储和网络。它应该是可编程的、动态的，而且要支持自服务模型，只有这样才能用脚本完成这些活动。

有些工具可以用来在裸机上实现动态基础设施平台，包括 Cobbler、FAI、Foreman 和 Crowbar。这些工具可以利用 PXE（preboot execution environment）规范启动一个从网络上下载的基础操作系统镜像，这个镜像接着会运行一个安装程序去下载并启动操作系统安装镜像。这个操作系统安装镜像会运行一个脚本，使用类似 Kickstart 的工具配置操作系统，接着可能运行 Chef 或者 Puppet 之类的配置管理工具。

通常，触发服务器来使用 PXE 启动一个网络镜像，需要在这个服务器启动的时候按一个功能键。这对于无人值守安装可能有点棘手，但是许多硬件供应商都有无人值守管理功能（lights-out management，LOM），可以远程甚至自动地完成安装。

许多情况都需要裸机基础设施，例如高性能的数据库服务器需要使用直接连接服务器的存储，此时精巧的动态存储就没有必要了。在其他情况下，存储区域网络（SAN）以及相关的技术和产品可以用来置备和分配存储。现在，与此相关的精巧的存储虚拟化产品也越来越多。

为了支持动态基础设施，管理网络硬件设备的配置是个特别的挑战。例如，为了适应请求而自动创建或销毁的服务器也许需要在负载均衡器上进行添加或者移除。网络设备的自动化配置比较困难，尽管许多设备都可以通过网络（例如 TFTP 服务器之类）加载配置文件。

团队能够也确实构建了针对硬件网络设备的自动化构建、测试和配置文件加载工具。幸运的是，正如先前所说，蓬勃发展的软件定义网络（SDN）运动正指引着厂商，为客户提供更多便利，甚至制定了跨供应商的标准。

5、如何选择动态基础设施平台

看过了动态基础设施平台为了支持基础设施即代码所要满足的特征，以及不同类型的平台之后，让我们来探讨选择平台时的重要考量因素。

5.1 公有还是私有

建议把组织的 IT 基础设施迁移到公有云上时，需要关注下面这些问题。

1、安全和数据保护

要迁移到公有云上，首要的关注点通常是安全。不像普通的托管服务专门提供商，云服务提供商在物理的硬件、网络和存储设备上托管的不仅有你自己组织的数据和计算资源，还有其他客户的。这些客户中的一些可能是你的竞争对手，还有一些可能是希望找到薄弱环节访问机密数据或者破坏你所在组织的犯罪分子。

但是许多组织都成功、安全地使用着公有云，包括处理敏感金融交易和客户数据的大型商业机构。例如，亚马逊自己的电子商务机构、Suncorp1 和 Tesco2。把数据放在专门的硬件里，甚至是专门的数据中心里并不能保证安全。有不少著名公司在私有数据中心里丢失了成千上万的客户信用卡数据，还有更多的这类事件不为大众所知。

不管使用公有云、外部供应商还是内部 IT，从来没有什么可以取代好的安全策略和实施。你的团队需要针对自己的服务全面考虑安全风险和威胁模型，然后将这些理解应用到不同的托管选项中，制定出最佳的方式。在许多情况下，混合基础设施可能适合用来隔离某些类型的数据和操作。

2、对托管位置的法律约束

一些组织限制了数据和系统托管的位置。来自政府的合同可能会要求系统托管在本国，或者禁止托管在其他某些国家。一些地方的隐私法不允许将用户数据传输到对数据使用保护没那么严格的国家。

例如，运行在欧洲的系统将数据存储在没有强个人隐私法的国家（比如美国）是违法的。当我在与欧洲公司的合作之中使用 AWS 时，需要注意确保数据只存在 AWS 的欧洲区域。

你的组织需要理解哪些约束是适用的。如果确实有这些限制，你需要知道云服务提供商在哪里托管你的系统和数据，还需要确认他们有足够的保障措施以遵守这些限制。不仅对于 IaaS 云服务提供商是如此，对于你使用的监控、电邮和日志聚合等服务也是如此。

3、对于可变容量的需求

你需要清楚组织的容量需求，并且理解独占的基础设施与供应商的共享资源池分别对容量需求的影响。使用公有云服务的一个重要好处是可以很快地调整你的容量，而且只为你需要使用的容量付费。

这对于使用水平会变化的服务很有用。在每天或者每周的周期之中，服务常常会出现差异很大的高峰和低谷。商业软件的使用在工作时间会非常多，在晚上和周末却非常少。娱乐应用通常有相反的周期规律。零售服务在每年年假之前的一段时间会比一年中其他时间需要更多的容量，特别是在西方国家。

另外一个使用共享资源的例子是快速增长的服务，比如新产品。当特性和营销带来一波又一波的新客户时，服务需求通常呈跳跃性增长。对于新的业务和产品来说，为可能用得上也可能用不上的固定容量付费是有风险的，所以能在仅当需求明确的时候快速增加容量是极为有帮助的。

虽然公有云模型可以非常完美地处理变化的容量和快速的增长，但有些提供专属基础设施的厂商可能也能满足这些需求。拥有很大硬件库存或者高效供应链的厂商也许可以保证在非常短的周转时间内为你的基础设施增加专用的硬件容量。他们也许会愿意提供短期服务，例如只在几天或几周内为特定的事件添加硬件。

4、自己构建云服务的总体成本

已有基础设施、数据中心或知识的沉没成本是自行托管的常见驱动力，却并不合理。迁移到云上并且舍弃已有的投资听上去有些浪费，但这确实是一个沉没成本谬论。和在不远的将来迁移到另一个地方相比，固守已有的硬件逼自己继续投资很有可能贵得多。

比较托管成本的一个常见错误是只计算硬件的价格。管理硬件基础设施需要技巧和时间，更不要说管理上的精力。在决定自己建造或保留自己的硬件以及相关基础设施之前，确定对总体成本的计算是合乎现实的。

5、商业产品还是差异化

IT 的许多方面看起来外包出去更便宜，但这却有很高的风险，削弱了组织快速、有效响应的能力。托管，特别是硬件层面的托管，并不在此之列。基础设施的置备已经变得像商业产品一样，到了具备编程接口，可以按照标准化、可互换、自动化的方式提供服务的程度。

极少有公司能够将知道在服务器上安装何种型号硬盘的能力变成竞争优势。只有少数公司能在数据中心运营上构建起足够的能力，比谷歌、亚马逊或者微软更便宜、更敏捷。

这并不是说没有组织可以在数据中心领域借助创新和专长构建有竞争力的产品，只是要认清你的组织是否属于其中一员。

管理云和虚拟化供应商

公有云服务供应商提供了“买定离手”一刀切式的服务。小一些或者专有云服务供应商可能会提供一些定制化的服务，比如更好的支持和咨询服务，或者针对更小目标市场调整后的服务。有些供应商甚至会在你选择的数据中心上创建和管理私有云。这在那些主流公有云服务商还没有提供数据中心的国家（比如中国）还是比较有吸引力的。

不幸的是，许多 IT 服务提供商快速地将一些服务产品贴上“云”的标签，这些产品对于那些寻求在动态基础设施之上管理软件基础设施的客户来说并不合适。就像本文前面描述的那样，你的动态基础设施平台需要是可编程、动态并且自服务的。

对那些假设虚拟机数量固定的定价模式和合同要保持戒心。置备一台机器不应该需要变更申请、发起工单或者任何的人工干预。虚拟机的成本不应该是固定或者长期的，按小时计费在云市场中是很常见的。

5.2 云的可移植性

当计划迁移到基于云的基础设施上时，一个常常出现的需求是避免锁定在单个云供应商。有些工具集和产品可以使云平台之间的迁移更容易。然而需要特别小心，避免花费了大量的时间和精力之后，发现迁移到另外一个云供应商仍然复杂、昂贵且充满风险。

对可移植性能够达成的目标保持现实，这点很重要。这个需求背后的主要驱动力来自管理未来替换云供应商的风险，并且通过降低潜在迁移的成本和风险，保留迁移可行性的选项。在这种情况下，没有必要保证迁移是零代价的。

确保可以无痛地离开某个云供应商的方法只有一个，那就是从一开始就构建一个跨供应商的基础设施。所有的服务都应该运行在多个云供应商上，所有的变更都应该应用到所有的云上，所有的数据都做好复制。要确保使用中的服务（不是部署成冷备份的那种）都具有可操作性。这个策略的额外好处就是可以容忍单个云供应商的错误。

在多个云上运行消除了迁移和锁定的风险，但是显著增加了实施和运行基础设施前期与过程中的成本和时间。

可移植性技术

如果系统运行在单个云平台上，有一些技术可以使未来的迁移更容易。

一个技术是避免使用厂商特有的功能。这有一个缺点：你可能错失一些或许能够在构建和运行系统时节省时间与成本的功能和服务。记录下基础设施使用的厂商特有服务也许就足够了，然后在迁移的时候找一个提供相似服务的厂商，或者做一些定制实现来替代这些服务。

一旦系统在第一个云上成功运行并投入使用，组织就可以将逐步重构系统提上日程了，目的是逐渐降低对厂商的依赖。

这凸显了另外一个更易于迁移到未来厂商的重要策略，那就是具备容易、自信地重构基础设施和服务的能力。一旦确保通过快速、经过严格自动化测试的过程对基础设施进行了变更，团队就可以自信地在不同的云平台上进行重构。

重点在于，构建能够响应不断变化的需求（包括改变部分基础设施的供应商）来改变基础设施的能力，比尝试构建一个在未来不会发生变化的基础设施（即使涌现出了未知的需求）要更为现实和强大。

有一些工具和技术对迁移有帮助。一些厂商提供了自动化处理基础设施的工具和服务，可以处理与特定云服务集成的细节。这意味着你的基础设施可以在任何该厂商支持的云上运行。当然，缺陷就是你可能会被这个可移植性工具的厂商锁定。

容器化可能对降低云供应商锁定有帮助。应用程序打包从底层的服务器中抽出和应用相关的配置和文件，这样它们就能更容易地在新的托管环境中运行。但是重度容器化的基础设施需要工具和服务来管理和编排容器，所以走这条路的团队需要考虑如何在云平台之间移植这些工具和服务。

最后一个避免锁定的潜在策略就是，使用在非私有平台上运行服务的厂商。换句话说，如果云平台是使用标准的虚拟化软件构建的，而其他竞争厂商也使用了这个软件，那它的迁移就可能比从私有平台上迁移要容易一些。

6、与云和虚拟化的“机械通感”

Martin Thompson 从一级方程式赛车手 Jackie Stewart 那里学到了“机械通感”（mechanical sympathy）这个术语并把它用在 IT 中。像 Stewart 一样成功的赛车手对于赛车如何工作有着与生俱来的理解，所以能发挥赛车的最大性能并且避免失误。对于 IT 从业人员来说，越是深入、全面地理解系统技术栈底层的硬件如何工作，越能熟练地发挥其最大性能。

软件的历史就是在抽象之上再逐层抽象。操作系统、编程语言和虚拟化都曾通过简化计算机系统与人的交互而帮助人们变得更有效率。你不需要担心某个特定的变量保存在哪个 CPU 寄存器里，不需要考虑如何分配堆载以避免不同的对象互相覆盖，也不需要操心某个虚拟机运行在哪个硬件服务器上。

除了你需要的时候。

硬件仍然潜伏在抽象之下，理解 API 和虚拟 CPU 单元外表之下发生的事情很有用（见图 2-3）。它有助于你构建的系统优雅地处理硬件错误，避免隐藏的性能瓶颈，并且打通潜在的“通感”——使软件能够匹配底层的系统，从而工作得比那些草草写就的软件更可靠、更有效。

例如，Netflix 的团队知道一部分 AWS 实例的性能要比平均水平差很多。这可能是硬件原因，也可能是因为他们凑巧和其他运行不佳的系统共享了硬件。所以他们写的置备脚本会立刻测试每个新实例的性能。如果性能达不到标准，这个脚本就会销毁这个实例，然后再次尝试创建一个新实例。

理解平台中的硬件服务器所使用的典型内存和 CPU 容量可以帮助你设计虚拟机的大小，从而获得虚拟机的最大性能。一些团队尽管不需要所有的容量，还是会通过选择 AWS 实例的大小来使他们独占整个硬件服务器的概率最大化。

理解存储选项和网络连接有助于确保磁盘读写不会成为瓶颈。这不是选择最快的可用存储这么简单的问题。选择性能最高的 SSD 本地磁盘对于可移植性、成本甚至资源的可用性都有影响。

这需要对整个架构栈“上下求索”。软件和基础设施的架构、设计和实现需要基于对硬件、网络、存储以及动态基础设施平台实际架构的理解。

基础设施团队应该寻找并通读所有与其所使用平台有关的白皮书、文章、会议演讲和博客。从供应商那里引入专家来评审你们的系统——从高层的架构设计到具体的实现细节。一定要问你们的设计和实现如何在他们的硬件基础设施上工作。

如果使用自己组织管理的虚拟化基础设施，更没有理由不协作。确保从全盘的角度来设计你的软件和基础架构，并且持续测量和修改，从而尽可能获得最好的性能和可靠性。

7、总结

有了动态基础设施平台，下一步就是选择和实现一些工具，用来定义和管理平台提供的资源。关于这个主题，我们以后有机会再详细讨论。