前言

如之前【航司IT爆发的原动力 (5)】：，中所述，虚拟化、容器化、无服务器等已经是航司航企涉猎的范围了，乃至还曾涉及超融合等概念。但是如何将这些技术设施部分的部署和选型定位好，是需要根据业务应用的诉求和方向而针对性的建设的，而不是无服务方式将完全替代容器化，或未来不存在虚拟化等等的情况。

虚拟机&虚拟化

对虚拟机的需求

服务器应用程序的部署变得越来越复杂，因为软件可能有多种类型的需求：

依赖于已安装的软件和库依赖于正在运行的服务依赖于特定的操作系统依赖于资源（例如最少的AVA数量可用内存（“需要1GB可用内存”）；能够绑定到特定端口（“绑定到端口80和443”）

要解决这些问题，主要的技术答案是：在单独的虚拟机上运行每个应用程序。但是其关键的促音是应用程序的概念，已经不是单一程序代码所完成的或实现的，其已经是“Combined”的二进制实现了，用搭积木再适合不过了。然而并不是抨击哪些非要自己一行一行编写代码来实现从底层到上层的程序员们，关键是我们所生活的世界和交付，是人财物时间来约束的。

虚拟化

虚拟化提供了一个硬件抽象层，它可以根据每台服务器的应用程序的特定CPU、内存、存储和网络需求进行调整。如果没有虚拟化，应用程序和操作体系结构团队将设计、获取和安装每个应用程序所需的服务器、存储和网络。

操作系统虚拟化

一次只能有一个操作系统。减少操作系统的扩展减少内存消耗最适合的场景与其他操作系统不能很好地共存的应用程序单个工作负载SaaS示例：与virtuzzo容器并行Sun Solaris容器OpenVZUnix chroot命令Linux V-Server

裸机管理程序 / Bare Metal Hypervisor

最适合异构环境开发和测试环境虚拟桌面传统服务器整合虚拟化对硬件（CPU、内存、存储）的访问，例如让Intel和AMD一起工作。每个虚拟机都有一个客户操作系统，从而减少服务器扩展示例：Citrix XenServer（Linux）kvmParallels服务器vmare esxMicrosoft Hyper-VXen裸机虚拟化技术（hypervisor）

管理程序类型

类型1、本机或裸机管理程序：这些管理程序直接在主机硬件上运行，以控制硬件并管理客户机操作系统。因此，它们有时被称为裸机管理程序。IBM在20世纪60年代开发的第一个管理程序是本机管理程序。例如：Citrix XenServer、Microsoft Hyper-V和VMware ESX/ESXi。类型2或托管管理程序这些管理程序与其他计算机程序一样在传统操作系统上运行。来宾操作系统在主机上作为进程运行。类型2管理程序从主机操作系统抽象出客户操作系统。例如：vmware工作站、vmware播放器、virtualbox、parallels desktop for mac和qemu

虚拟化技术

操作系统虚拟化：Linux vserver、lxc、openvz虚拟化软件：kvm、qemu、vmware、virtualbox、virtualp c、xen et bochs裸机管理程序：Citrix XenServer、hyper-v、kvm、parallels ras、proxmox ve、vmware esx（vSphere、vCloud），xen

Hyperconverged Integrated System

集成系统是服务器、存储和网络基础设施的组合，与管理软件一起销售，便于组合单元的供应和管理。

集成堆栈系统（ISS）：与应用软件集成的服务器、存储和网络硬件，以提供设备或类似设备的功能。示例包括IBM pureApplication System、Oracle Exadata数据库机器和Teradata。集成基础设施系统（IIS）：服务器、存储和网络硬件集成，以提供共享计算基础设施。示例包括VCE Vblock、HP ConvergedSystem和联想Converged System（以前称为pureflex）。超连接集成系统（HCI）：紧密耦合的计算、网络和存储硬件，无需常规存储区域网络（SAN）。示例包括GridStore、Nimbox、Nutanix、Pivot3、规模计算和Simplivity。容器

Docker：package once deploy anywhere。

Docker是一个开放平台，供开发人员和系统管理员构建、发布和运行分布式应用程序。由Docker引擎、便携式、轻量级运行时和打包工具，和Docker Hub、用于共享应用程序和自动化工作流的云服务组成。Docker使应用程序能够从组件中快速组装，并消除开发、QA和生产环境之间的摩擦。

容器，或者称为操作系统级虚拟化，是一种轻量级的虚拟化方法，只提供应用程序按预期运行和运行所需的最低限度。不在管理程序上运行的超简约虚拟机。

通常捆绑到容器中的项目包括：应用程序、依赖项、库、二进制文件和配置文件。将应用程序进行容器化使其能够通过抽象操作系统和物理基础设施在不同的环境中可靠地运行。

容器化应用程序与其他容器共享主机操作系统的内核，操作系统的共享部分是只读的。在容器内，通常有单个可执行服务或微服务。

容器是操作系统虚拟化的产物。

轻量级虚拟环境，将一组进程和资源（如内存、CPU、磁盘等）与主机和任何其他容器进行分组和隔离。隔离保证容器内的任何进程都看不到容器外的任何进程或资源。一次只能运行一个应用程序（或微服务），在主机操作系统上以独立进程运行：便携式且高效、降低内存消耗。最适合场景：多租户应用程序、弹性应用程序（自动缩放）示例：Docker、Coreos、Jeos、Rancheros、Snappy Ubuntu Core、Redhat Atomic、Mesosphere DCOs，vmware photon container os container container application（s）x86服务器SAN/NAS/DAS

然而此概念并不是全新的。

两种技术的融合

其是两种现有的捆绑技术

LXC：linux容器，允许单个进程以比常规的unix进程更高的隔离级别运行。用于此目的的术语是集装箱化：过程称为在集装箱中运行。容器支持以下级别的隔离：文件系统：除非专门装入容器的文件系统，否则容器只能访问自己的沙盒文件系统（chroot-like）。用户名称空间：容器有自己的用户数据库（即容器的根不等于主机的根帐户）进程名称空间：在容器中，只有容器的进程部分可见•网络名称空间：容器拥有自己的虚拟网络设备和虚拟IP（因此它可以绑定到它喜欢的任何端口）不占用其主机端口）。AUFS：高级多层统一文件系统，可用于创建联合、写时复制文件系统。资

DevOps的资产

Docker允许每个开发团队使用他们认为合适的任何语言、框架或运行时来实现服务。他们将服务投入生产的唯一要求是向运营团队提供Docker映像（加上Yaml文件中的一些基本运行配置）。

运营团队的职责现在仅限于简单地构建和维护用于部署Docker容器的管道，而无需关心每个容器实际包含的代码。Docker镜像的内容完全由开发团队负责。这允许运营团队专注于核心部署问题。此外，这种安排允许开发团队进行扩展。可以添加越来越多的开发团队，只要我们坚持每个可交付服务必须捆绑在Docker镜像中的规则，我们就不会向运营团队添加额外的认知负载。

Docker的优点和缺点

Docker的优点资产在构建时被构建成不变的镜像不依赖于第三方存储库的部署时间Docker注册表简单且易于扩展依赖性简单、明确且直接回滚很小Docker的误解如果我学习Docker，那么我不需要学习其他系统的东西！每个Docker容器只能有一个流程！如果我使用Docker，那么我不需要配置管理（CM）工具！我必须使用Docker才能获得这些速度和一致性优势！

Docker的优势

非常轻。启动Docker容器的CPU和内存开销非常小，速度非常快。几乎相当于开始一个常规的过程。不仅运行容器速度很快，还可以构建图像和对文件系统进行快照。Amazon lambda是在Docker上构建的，服务的使用每100毫秒计费一次。它在已经虚拟化的环境中工作。您可以在EC2实例、rackspace虚拟机或virtualbox中运行docker。在Mac和Windows上使用Vagrant。Docker容器可移植到运行Docker的任何操作系统。无论是Ubuntu还是CentOS，如果Docker运行，则容器运行。从虚拟机到容器

虚拟机在两个方面都很昂贵

钱你需要预测你需要的实例大小，因为如果你以后需要更多的资源，你需要停止虚拟机来升级它（或者过度支付你最终不需要的资源）。除非您使用Solaris区域，例如可以动态调整大小。时间与虚拟机相关的许多操作通常很慢！启动需要几分钟，快照需要几分钟，创建图像需要几分钟

容器与虚拟机

虚拟机包含完整的操作系统和应用程序。基于虚拟机监控程序的虚拟化是资源密集型的，一个虚拟机可以占用几个GB，这取决于来宾操作系统。虚拟机使用管理程序共享和管理硬件，而容器共享主机操作系统的内核以访问硬件。虚拟机有自己的内核，它们不使用和共享主机操作系统的内核，因此它们在深层次上彼此隔离。驻留在同一服务器上的虚拟机可以运行不同的操作系统。一个虚拟机可以运行Windows，而隔壁的虚拟机可能正在运行Ubuntu。容器由主机操作系统绑定，同一服务器上的容器使用相同的操作系统。容器正在虚拟化底层操作系统，而虚拟机正在虚拟化底层硬件。

为什么要使用容器

平均容器大小在数十MB的范围内，而虚拟机可以占用数GB。因此，服务器可以承载比虚拟机多得多的容器。运行容器比运行虚拟机占用的资源更少，因此您可以在同一服务器上添加更多的计算工作负载。提供容器只需要几秒钟或更短的时间，因此，数据中心可以对用户活动的激增做出快速反应。容器使您能够轻松地为流程分配资源，并在各种环境中运行应用程序。使用容器可以减少开发、测试和部署应用程序和服务所需的时间。测试和错误跟踪也变得不那么复杂，因为在本地、测试服务器或生产环境中运行应用程序没有区别。容器是一种非常经济有效的解决方案。它们可能会帮助您降低运营成本（减少服务器、减少员工）和开发成本（为一个一致的运行时环境开发）。基于容器的虚拟化对于微服务、DevOps和连续部署是一个很好的选择。

容器的风险

安全：容器共享内核、主机操作系统的其他组件，它们具有根访问权限。这意味着容器与虚拟机之间的隔离性要比虚拟机小，如果内核中存在漏洞，也可能危及其他容器的安全性。虚拟机只共享管理程序，与容器的共享内核相比，管理程序的功能更少，更不容易受到攻击。系统硬件以虚拟化的形式呈现给虚拟机，因此入侵、病毒和其他恶意活动不能传播到其他虚拟机。操作系统的灵活性较低：您需要启动一个新的服务器，以便能够运行具有不同操作系统的容器。尽管具有任何类型操作系统的虚拟机可以在同一服务器上彼此相邻。对于宿主提供者来说，这可能不是问题，但对于复杂的企业应用程序来说，这可能是一个严重的约束。联网：以充分隔离的方式部署容器，同时保持适当的网络连接是复杂的。

容器技术堆栈

容器提供商

基于Unix/LinuxDocker是最流行的容器技术，LXCLXDSolarisRKTBSDMicrosoft提供两种容器解决方案Windows服务器容器和Hyper-V容器。与Docker一样，Windows Server容器与容器主机和其他容器共享内核，而Hyper-V容器则不同。

容器编排

容器编排平台允许用户在大型集群中轻松部署、管理和扩展基于多容器的应用程序，而无需担心哪台服务器将承载特定容器。

容器集群编排仍然是一个非常有竞争力的空间：

亚马逊ECSApache MeosAzure容器服务CoreosDiegoDocker SwarmHashicorp NomadKubernetesMarathon开放堆栈Magnum

云计算本地基金会（CNCF）

云本地计算基金会是一个Linux基金会项目。容器包装：为了提高整个开发人员的体验，促进代码重用和简化操作。动态管理：由中央编排过程积极调度和管理，从根本上提高机器效率。

面向微服务：与通过服务端点明确描述的依赖关系松散结合，以实现应用程序的整体灵活性、可维护性正如OCI针对容器图像可移植性一样，CNCF针对云应用程序可移植性。管理下的项目KubNeNET：一个开放的系统，用于自动部署、缩放和管理容器化的应用程序。普罗米修斯：一个开源系统监控和警报工具包，最初构建于SoundCloud。

容器网络

目前有两个为Linux容器配置网络接口的建议标准：

容器网络模型（cnm）是Docker提出的规范，由LibNetwork等项目采用，集成了Cisco Contiv、Kuryr、Open Virtual Networking（OVN）、P等项目和公司。项目：Calico、Vmware和Weave。容器网络接口（CNI）是coreos提出的容器网络规范，并被Apache Meos、Cloud Foundry、Kubernetes、Kurma和Rkt等项目采用。还有由Contiv Networking、Project Calico和Weave等项目创建的插件。•这些模型通过培养提供高级网络功能的第三方供应商的创新生态系统来促进模块化、可组合性和选择。•网络微分段的编排可以成为连接、分离和交换网络的简单API调用。

接口容器可以属于多个网络，每个容器可以在不同的网络中发布不同的服务。

容器网络模型：libnetwork是cnm规范的规范实现。

libnetwork在docker守护进程和网络驱动程序之间提供接口。网络控制器负责将驱动程序与网络配对。每个驱动程序负责管理其拥有的网络，包括向该网络提供的服务。每个网络有一个驱动程序，多个驱动程序可以与连接到多个网络的容器同时使用。驱动程序定义为本地（内置到libnetwork或支持docker）或远程（第三方插件）。本机驱动程序为无、桥接、覆盖和Macvlan。远程驱动程序可以带来任何数量的功能。驱动程序还定义为具有本地作用域（单主机）或全局作用域（多主机）。

容器网络接口：CNI是作为最小规范创建的，与许多网络供应商工程师一起构建，以作为容器运行时和网络插件之间的简单合同。

JSON模式定义了CNI网络插件的预期输入和输出。多个插件可以同时运行，一个容器连接由不同插件驱动的网络。在配置文件中以JSON格式描述网络，并在调用CNI插件时实例化为新名称空间。CNI插件支持两个命令，用于在网络之间添加和删除容器网络接口。添加在创建容器时由容器运行时调用。当删除容器实例时，它会被容器运行时调用。

容器网络CNI与CNM：

两者都民主化了可使用哪种容器网络类型的选择两者都是基于驱动程序的模型或基于插件的模型，用于创建和管理容器的网络堆栈。两者都允许多个网络驱动程序处于活动状态并同时使用•每个驱动程序都提供网络到该网络驱动程序的一对一映射。这两种模型都允许容器加入一个或多个网络，并允许容器运行时在其自己的命名空间中启动网络，分离将容器连接到网络和网络驱动程序的应用程序/业务逻辑。这两个模型都为网络驱动程序（创建、配置和连接网络）和IPAM（配置、发现和管理IP地址）提供单独的扩展点，即插件接口。

然而CNM：不提供对容器网络命名空间的网络驱动程序访问。这里的好处是libnetwork充当冲突解决的中介。仅支持Docker运行时引擎。使用CNI的简单方法，人们认为创建CNI插件比创建CNM插件更容易。

CNI：确实为驱动程序提供了对容器网络名称空间的访问。支持与第三方IPAM集成，可用于任何容器运行时。

开放容器倡议 / Open Container Initiative

OCI是一个轻量级的开放式治理项目：在Linux基金会的支持下形成的，目的是围绕容器格式和运行时间创建开放的工业标准。于2015年6月22日推出。

OCI旨在将生态系统融合到开放标准中用户应能够一次性打包其应用程序，并使其与任何容器运行时一起工作•该标准应满足最严格的安全和生产环境的要求该标准应与供应商无关，并且应进行开发。在open中oci当前包含两个规范运行时规范（runtime spec）：概述如何运行磁盘上解包的“文件系统包”。镜像规格（镜像规格）。在高层，OCI实现将下载OCI映像，然后将该映像解包到OCI运行时文件系统包中。此时，OCI运行时包将由OCI运行时运行。

是否分支（Fork）

关于从Docker中分离的讨论现在正在几个Docker生态系统供应商和最终用户之间进行。对于Docker对Docker引擎的管理感到失望，公司的技术人员正在探索解决支持企业Docker部署的各种问题的方法。正在考虑几个选项，包括完全分支开源Docker引擎的可能性。根据最近讨论的一些消息来源，红帽、谷歌、Coreos、华为和两个大型终端用户客户等公司的代表都参与了讨论。

Docker产品管理

我们从Docker生态系统中反复听到的一个担忧是，Docker的激进发布计划如何使第三方系统提供商与他们自己的客户群发生冲突。Docker始终打破后端兼容性。Docker将其Docker引擎用作一种产品，而不是社区用来构建自己服务的组件。这种基于产品的方法意味着，当Docker引入新的创新或合并SWA等组件时，运营商必须修复后端兼容性的中断。RM进入Docker引擎。随着Docker最近在Docker 1.12中加入Docker Swarm，长期酝酿的挫折达到了顶点。使用Swarm，Docker Engine允许用户使用开发人员熟悉的命令行结构和语法来管理复杂的集装箱化应用程序，而无需额外的软件。Docker编排功能是可选的；它们必须由用户激活。尽管不选择加入可能会导致向后兼容性问题。

Redhat CRI-O（ex.ocid）

Redhat CRI-O，以前命名为开放容器主动守护进程（open container initiative daemon，ocid）是一组项目，为Kubernetes提供了通过Docker运行时核心版本（“runc”项目）获取和运行容器镜像的能力，该版本已根据Kubernetes的需要进行了修改。并且是kubernetes标准容器运行时接口的实现。为了运行容器，守护进程需要能够拉、存储和执行容器映像。

CRI-O可以成为容器引擎的参考实现：

为大规模运行OCI容器提供免费和开源选项。它将包括runc，基于libcontainer的容器运行时，Docker将其捐赠给OCI作为免费标准使用。它还将包括将图像推送到容器注册中心托管的存储库并从中提取图像所需的代码。它将支持coreos构建的容器网络接口，用于独立于承载容器的引擎建模插件。•然而，OCID提出的组件称为OCI运行时。Kubernetes容器运行时接口（CRI）的实现，允许Kubernetes直接启动和管理开放容器计划（OCI）容器。OCID不是为了能够构建OCI映像而实现的，因此您仍然需要Docker来实现这一点。

从高层来看，CRI-O的范围是：支持多种镜像格式，包括现有的Docker镜像格式；支持多种方式下载镜像，包括信任和镜像验证；容器镜像管理（管理镜像层、覆盖文件系统等）；容器进程生命周期管理。

从容器到单核

云计算开创了将大型数据中心的计算资源出租给多个（可能是竞争对手）租户的业务。

云的基本启用技术是操作系统虚拟化：允许客户在物理机（即独立计算机）的共享集群上复用虚拟机（虚拟机），启动标准操作系统内核，运行未修改的应用程序，就像在物理机上执行一样。早期云计算增长的一个关键驱动因素是服务器整合。现有的应用程序通常安装在单独未充分利用的物理主机上，虚拟化使将它们打包到较少的主机上成为可能，而无需进行任何修改或重新编译代码。尽管操作系统虚拟化毫无疑问是有用的，但它为已经高度分层的软件堆栈添加了另一层。所有这些层都位于应用程序代码之下。

容器确实代表了虚拟机的一大进步：

非常小的虚拟机，通过从虚拟机本身删除冗余或不必要的操作系统元素，允许更高的服务器密度。完美打包的虚拟机堆栈，可轻松传输、复制和控制，确保高度可移植性。小型虚拟机软件栈，消除了构建大型版本特定操作系统栈的问题和繁琐。极快的启动时间，可以促进更灵活的基础设施，允许更大的自由度来响应当前的需求。

Docker的两个主要问题：

安全性。“共享内核”策略的安全攻击面在“共享内核”本身中有其最薄弱的环节。如果一个恶意黑客试图破坏共享内核，那么使用该共享内核的所有实例都可能受到危害。Docker管理在生产中管理Docker和容器的复杂性是其采用带来的更大挑战之一。

所以这都需要高效、快速、易于管理和安全的解决方案：

将应用程序与操作系统分离将操作系统功能分解为模块化库仅链接应用程序所需的系统功能将替代平台从单个代码库中锁定

什么是单核 / Unikernels

是从模块化堆栈中构建的专用机器镜像，将系统库和配置添加到应用程序代码中。

每个应用程序都编译成自己的专用操作系统，运行在云或嵌入式设备上，也称为“库操作系统”或“云操作系统”Unikernels实现几乎没有传统操作系统的功能；只够启动它所支持的应用程序。将Docker-like容器系统的许多优点与虚拟机监控程序的安全足迹以及每个虚拟机内更小的攻击面结合起来。Micro-Container

Docker使您能够将应用程序以及应用程序的所有依赖项打包成一个良好的独立映像。然后可以使用该映像在容器中运行应用程序。问题是你通常打包的东西比你需要的要多得多，所以你最终得到的是一个巨大的图像，因此是一个巨大的容器。大多数开始使用Docker的人将使用Docker的官方存储库作为他们选择的语言，但不幸的是，如果你使用它们，最终会得到大尺寸的镜像。你根本不需要这些镜像附带的所有东西。

微容器

微容器只包含运行应用程序和应用程序本身所需的操作系统库和语言依赖项。不要从任何东西开始，而是从最低限度开始，并根据需要增加依赖性。

微容器的优点

尺寸：占地面积小、快速/容易分发。由于其尺寸，从注册中心下载镜像更快，因此可以更快地分发到不同的机器。

提高了安全性：容器中的代码更少/程序更少意味着攻击面更少。而且基本操作系统更安全。这些好处与Unikernels的好处类似，没有任何缺点。

如何构建微容器

所有Docker镜像的基础镜像是“草稿”镜像。它基本上没有任何内容。这听起来可能毫无用处，但如果您可以像使用go或c那样将应用程序编译为具有零依赖性的静态二进制文件，那么实际上您可以使用它为应用程序创建尽可能小的镜像。这几乎是您所能得到的最小值。草稿镜像+应用程序二进制文件。

并不是所有人都在使用Go，所以您可能会有更多的依赖性，并且您需要的东西比草稿镜像多一点。Alpine Linux作为一个面向安全、轻量级的Linux发行版和一个很好的包系统来添加依赖项。

无服务计算的兴起

2012年，Ken Fromm在读写网上写道：“为什么软件和应用的未来是无服务器的”。术语“无服务器”并不意味着服务器不再参与其中。这仅仅意味着开发人员不再需要对它们进行如此多的思考。开发人员的重点从服务器级别转移到任务级别。经常被称为：服务功能或FaaaS。

新的应用程序体系结构

前端革命：移动设备上的厚客户端本机应用程序以及基于HTML5的富浏览器Web应用程序（使用MVC框架，如AngularJS）的强大功能使开发人员能够通过协调任意数量的云服务来替换大型和复杂的应用程序他们传统的基于服务器的应用程序后端。如今，几乎所有您能想象的服务都启用了HTTP，并支持安全使用的标准身份验证令牌交换协议。

后端定制：独特的业务需求，需要自定义代码或新的方式来协调后端的其他一些云服务。需要能够添加“功能”，能够对事件作出反应，实现、补充或扩展“后端”核心服务。

服务器和PaaS有什么不同

PaaS可以看作是无服务器的第一次迭代。您仍然需要考虑所需的资源，但不必管理它们。使用无服务器，您甚至不需要提前考虑需要多少容量。

使用无服务器，你可以将你的应用程序分解成一小块，而不是使用一个可以在PaaS上运行的单片应用程序。你必须将你的应用程序分解成独立的小程序或函数。例如，API中的每个端点都可以是单独的函数。这些功能是按需运行的，而不是像在PaaS上运行的应用程序一样全时运行。从运营的角度来看，将应用程序分解为功能的好处在于，您可以相互独立地扩展和部署每个功能。

从微服务到功能

微服务背后的理念是将单片应用程序分解为小型服务，以便您能够独立开发、管理和扩展它们。FaaS通过将事情细分得更小，从而进一步推进了这一步。趋势很明显，工作单位越来越小。我们已经从整体到微服务再到功能。

无服务器生态系统

云平台：Amazon lambda、Google云功能、hook.io•IBM Bluemix、OpenWhisk、Iron.io、Microsoft功能、WebTask。框架：Serverless：开放源代码命令行工具和标准语法，可轻松在AWS lambda、Azure功能、Google云功能上构建无服务器架构，etc.apex：apex让您轻松构建、部署和管理AWS lambda功能sparta：AWS lambda微服务的Go框架其他：deployd和iopipe工具：Leveros、Stamplay和Syncano等工具展示了许多潜力提供无服务器微服务协调层的新产品，引入了身份验证和用户权限、后端脚本、第三方API集成、消息和工作队列管理、数据管理和通道等功能创建应用程序的界面。

无服务器体系结构的好处

无服务器体系结构消除了对服务器堆栈的管理以及任何必须进入堆栈上下扩展的问题/计划。所有这些过程都是自动化的，您只需支付使用的计算时间。经济效益：理论上，您应该通过消除雇佣员工来支持服务器和其他基础设施来降低成本。如果应用程序流量激增，您也可以节省成本，因为无服务器架构不必为这种闲置付费，而是只允许您为实际消耗的CPU周期付费。nd代码只在需要时运行。AWS支持流行的编程语言：AWS支持JavaScript、Java、Python和JRube。缩短开发时间：DevOps资源可以放弃“操作”，只关注“开发”。

无服务器问题

无服务器架构通常被认为是平台即服务的下一个发展方向，使组织能够专注于应用程序代码，而服务提供商则可以管理所有其他内容，包括后端堆栈组件。•但是，尽管无服务器架构有许多好处，但也必须考虑一些严重的缺点。简单地说，Serverless不适合所有人。供应商锁定。准备好根据您使用的无服务器架构使用不同的组件和实现方法。不容易迁移旧版。运行在无服务器平台上的应用程序需要重新设计，并且大部分时间需要重新编码。没有清晰的蓝图或路线图。尽管无服务器架构得到了热情的支持和快速发展。没有清晰的技术标准和有限的选项。尽管能够使用许多最流行的语言编程，但考虑到所有可用的语言都可以进行编码、编译，无服务器计算仍然有限在传统环境中运行。结论

基于容器的虚拟化是一种正在以惊人的速度被采用的颠覆性技术！虚拟机仍然被认为是一种更成熟的技术，具有更高的安全级别，许多团队更习惯于与它们合作。虚拟机通常更适用于单片应用程序和安全问题超过轻量级解决方案需求的场景。基于容器的虚拟化是针对微服务体系结构风格的更好的解决方案，应用程序的功能分为定义良好的小型独特服务。容器和虚拟机不相互排斥，它们可以看作是互补的解决方案。Netflix云就是一个很好的例子，其中容器在虚拟机中运行。然而无服务器似乎是下一步。

从更普遍的角度来看，这一进展代表了一个连续体，将导致无服务器架构和其他更有效的管理复杂性的方法，即单核技术。我们见证了微服务的诞生，那么则需要我们近跟下一个风口。