作者 | Massimo Re Ferre
译者 | 姚佳灵
编辑 | 张婵
AWS 不同级别的计算抽象是怎样的？
去年我加入 AWS 的时候，我想找到一个方法，以尽可能简单的方式从计算角度解释 AWS 为用户提供所有的产品。有很多方法来细细讲解，但是，我想跟大家分享一下我创造的“可视化”的方法。
我把计算域定义为“拥有 CPU 和内存容量，允许运行特定语言编写的任意一段代码的所有一切”。你的定义范围也许因定义的方式而异，但是，这个定义的范围足够宽泛，应该能涵盖很多不同的解释。
我的故事中一个关键部分是介绍业界在过去的 20 年间所见证的不同级别的计算抽象。
职责分离我的方法始于一条线。在云环境中，这条线定义了使用者和供应商这两个角色之间的边界。在云中，有些事由 AWS 做，还有些事由使用者做。这些职责范围的不同取决于你选择使用的服务。
上面这条线是倾斜的原因是，它需要和不同的计算抽象级别相切。如果想一下在过去 20 年间 IT 行业所发生的事，我们已经看到了大量不同的计算抽象，这些计算抽象改变了人们消耗 CPU 和内存资源的方式。这一切都始于 1980 年代的物理（X86）服务器，然后，我们看到了业界在逐年添加抽象级别（比如，虚拟机管理程序、容器、函数）。
抽象的级别越高，云供应商就越能增加价值，并且可以让消费者脱离非战略活动。很多这样的活动往往是“无关紧要的重活”。我们把这个定义为 AWS 使用者必须做的事，但是不一定能将其与他们的竞争者区分开来（因为这些活动是特定行业的筹码）。
我们发现，为了支持 AWS 上数百万的使用者，我们所提供的服务需要具有一定程度的灵活性，因为要满足很多不同的模式、用例和要求。
实例（或虚拟机）抽象这是我们早在 2006 年就引入 AWS 的第一个抽象。亚马逊弹性云计算（Amazon Elastic Compute Cloud，简称 Amazon EC2） 是允许 AWS 客户在云中启动实例的服务。当客户使用这个级别的抽象时，他们对客户操作系统及以上应用（中间件、应用程序等）和它们的生命周期负责。AWS 负责管理硬件和虚拟机监控程序，包括它们的生命周期。
同一级别的还有 Amazon Lightsail，它是“开发人员、小企业、学生以及其他需要简单虚拟专有服务（virtual private server，简称 VPS）解决方案的用户开始使用 AWS 最简单的方法。Lightsail 为开发人员提供计算、存储、网络容量和功能以在云中部署、管理网站和网络应用程序”。
下图显示了这两个服务在我们可视化中呈现出来的样子：
随着微服务的兴起，在过去的几年里，一种新的抽象方式席卷了整个行业，那就是容器。容器不是新技术，几年前 Docker 兴起的让更多的人开始使用容器。你可以把容器看作是具有软边界的独立环境，其中包含你自己的应用程序以及运行它的软件依赖项。而实例（或 VM）虚拟化硬件，以便运行专门的操作系统，容器技术又可以虚拟化操作系统，这样你可以运行具有不同（通常是不兼容）软件依赖性的独立应用程序。
现在是棘手的部分了。基于容器的现代解决方案通常用两个主要的逻辑部分实现：
-
容器控制平面负责暴露 API 和接口，以定义、部署容器并对容器进行生命周期管理，有时也被称为容器编排层。
-
容器数据平面负责提供容量（如 CPU/ 内存 / 网络 / 存储），以便这些容器可以实际运行和连接到网络。从实际的角度来看，它通常是 Linux 主机或 Windows 主机，容器可以在其中启动并连接到网络。
可以说，在特定的计算抽象中，数据平面是关键，但是了解控制平面部件也一样重要。
亚马逊于 2014 年发布了产品级的容器控制平面，该容器控制平面被称为 AWS ECS，它“是一个具有高扩展性、高性能的容器管理服务，支持 Docker……使用亚马逊 ECS，你将无需安装、操作和扩展集群管理基础架构。”
在 2017 年，亚马逊还宣布有意发布基于 Kubernetes 的新服务，也就是 EKS （Amazon Elastic Container Service for Kubernetes）。Kubernetes 是开源容器控制平面技术。亚马逊 EKS 于 2018 年 6 月初上市。
与 ECS 一样，EKS 旨在把 AWS 的客户从不得不管理容器控制平面的重任中解放出来。过去，AWS 的客户在 EC2 抽象之上启动 EC2 实例以及部署和管理自己的 Kubernetes masters（masters 是 Kubernetes 运行控制平面主机的名字）。但是，我们认为，很多 AWS 客户将把管理这一层的重任交给 AWS，这是通过 ECS 或 EKS 来实现的，具体情况取决于他们的用例。
到目前为止，我们已经讨论了容器控制平面。那么容器数据平面呢？它通常是客户管理的一组 EC2 实例。容器控制平面由 AWS 管理，而容器数据平面由客户管理。有人可能会对此产生争议，通过 ECS 和 EKS，我们已经提高了控制平面的抽象级别，但是，我们还没有真正提高数据平面的抽象级别，因为数据平面仍然由常规的 EC2 实例构成，这些实例是由客户负责的。
以下是容器控制平面和容器数据平面服务呈现出来的样子：
在 2014 的 re:Invent 大会上，AWS 引入了另一个抽象层：AWS Lambda。Lambda 是一个执行环境，允许 AWS 客户运行单个函数。因此，无需管理和运行整个 OS 实例来运行代码，也无需在用户构建的容器中跟踪所有的软件依赖项来运行代码，Lambda 允许上传代码，大规模的运行则交给 AWS。
Lambda 的特别之处在于事件驱动模型：不仅可以直接调用 Lambda（比如，通过亚马逊 API 网关），而且可以根据在另一个 AWS 服务中的事件触发一个 Lambda 函数（比如，一个到亚马逊 S3 的上传或在亚马逊 DynamoDB 表中的更改）。
使用 Lambda，你将无需管理运行函数之下的基础架构，无需跟踪物理主机状态和机群容量，无需修补运行该函数的操作系统。简而言之，无需在无关紧要的重活上耗费时间和金钱。
这就是 Lambda 服务呈现出来的样子：
也称为“无抽象”。
在最近的 2017 年的 re:Invent 大会上，我们发布了亚马逊 EC2 裸机抽象实例（预览版）。该服务于 2018 年 5 月向公众开放。
“……（AWS 客户）希望访问物理资源，因为这样应用程序可以利用底层硬件功能，比如 performance counters 和 Intel® VT，这些功能在虚拟环境中不总是受到全面的支持。另外，客户也是希望访问在硬件上直接运行或在非虚拟环境中获得授权和支持的应用程序。”
这就是裸机亚马逊 EC2 i3.metal 实例呈现出来的样子：
i3.metal 是基础 EC2 实例类型，处于 VMware 的 VMware Cloud on AWS 服务之上。现在，我们给所有 AWS 用户提供裸机实例的能力。但这并不意味着你可以开箱即用加载自己选择的虚拟机管理程序，但是，你可以处理一些用传统 EC2 实例无法做到的事。
更严重的是，我经常被问到的一个问题是，用户是否可以自己在 i3.metal 上安装 ESXi。这个如今还做不到，但是，我有兴趣听听你的相关用例。
完整的容器抽象（缺少更好的术语）现在我们已经介绍了所有的抽象，是时候回头看看我们是否可以给 AWS 的客户提供其他的优化 。当我们在讨论容器抽象时，我们说到尽管有两个不同的全托管容器控制平面（ECS 和 EKS），但是没有数据平面的托管选项。
有些客户曾经（并且仍然）对能完全控制所述实例感到高兴。也有一些客户一直想要摆脱管理基础设施生命周期的业务（无关紧要的重活）。
AWS Fargate 是一个生产级的服务，给 AWS 容器控制平面提供计算容量。实际上，Fargate 正在让容器数据平面落入“供应商空间”职责范围。这意味着公开给用户的计算单位是容器抽象，而 AWS 将透明地管理下面的数据平面抽象。
这是 Fargate 服务呈现出来的样子：
现在，ECS 有两种“启动类型”：一种称之为“EC2”（您的任务被部署在用户管理的 EC2 实例群上），另一个被称为“Fargate”（您的任务被部署在 AWS 管理的 EC2 实例群上）。
总结文中介绍了 AWS 上可用的抽象级别，AWS 客户如何根据其用例以及他们的云成熟度来使用这些抽象。想提升和转型的客户可能更倾向于使用处于图片左侧的服务，而采用更成熟的云原生方法的客户可能对使用处于图片右侧的服务更感兴趣。
总的说来，客户倾向于使用更高级别的服务来摆脱管理非差异性活动的业务。例如，最近，我和对使用 Fargate 感兴趣的客户进行了交谈。Fargate 符合 ISO、PCI、SOC 和 HIPAA 的标准，这对于他们来说可以节省大量的时间和金钱，因为在审计过程中它更容易指向一个 AWS 文档，而不需要为一个 DIY 容器数据平台构建合规配置。
总结一下，这是我们的可视化呈现，其中包含所有可用的抽象：
作者简介
Massimo 是 AWS 的首席解决方案架构师。他在从操作系统虚拟化技术着手，在 x86 生态系统方面有约 25 年的专业经验，最近，他一直在研究应用程序架构在云计算领域的发展。Massimo 个人博客地址：www.it20.info，推特账号：@mreferre