基础架构即代码与平台即代码

使用基础设施即代码（IaC），您可以编写有关基础设施的计算，存储和网络要求的声明性说明并执行。这与平台即代码（PaC）相比如何？这两个概念是如何发展的？

以最简单的形式，任何应用程序的技术堆栈都分为三层：包含裸机实例，虚拟机，网络，防火墙，安全性等的基础层；具有操作系统，运行时环境，开发工具等的平台层；当然还有包含您的应用程序代码和数据的应用程序层。一个典型的运营团队除了可以部署代码之外，还负责基础层和平台层的供应，监视和管理。

云计算的兴起首先使基础层抽象化。借助基础架构即服务（IaaS）模型，IT /运营团队只需单击一下按钮即可立即配置云基础架构。AWS EC2，Azure VM和Google CE是当今使用最广泛的IaaS服务。随之而来的是平台即服务（PaaS）模型，该模型抽象了下一层。基础设施提供商自己开始提供平台层-操作系统，开发工具，数据库管理等。诸如AWS Beanstalk，Azure CDN，Google App Engine之类的PaaS服务广受欢迎。

实际上，Ops团队还开始构建自己的PaaS，将选定的功能子集整合到与现有的基础设施兼容或具有自定义工作流程的位置。如果您使用容器化或微服务范式，这可能会变得乏味且笨拙。

在构建基于微服务的应用程序中对规模，一致性，可重复性，可共享性和可审计性的需求迫使运营团队考虑采用根本性的新方法来处理基础层和平台层。正是针对这些担忧，出现了基础架构即代码（IaC）和平台即代码（PaC）的概念。

基础架构即代码

基础架构即代码恰好就是罐头上所说的：通过软件而不是物理硬件配置或其他工具来管理和配置基础架构。使用IaC，您可以编写有关基础设施的计算，存储和网络要求的声明性说明并执行。然后，自动化引擎（如AWS Cloud Formation和Terraform之类的工具）将通过抽象的IaaS API捕获声明/代码来为您配置它。

结果，无论是交付管道的自然组成部分还是打算根据特定事件进行自动扩展，置备基础设施的速度都将显着提高。如果您使用dev，QA，staging，prod等多种环境，则使用同一代码库启动基础结构可确保一致性，并通过减少错误，错误配置，停机等风险来节省大量时间和可能的麻烦。变更管理也变得非常重要更简单-您可以编写代码来更新您的基础结构，并具有完整的版本控制。

这对于云上的容器化应用程序特别有影响。

• 容器化和微服务启动了数百个小型应用程序，而不是像先前的开发范例中那样使用少数大型实例。在这种规模下，开发过程将存在时间滞后，从而严重影响敏捷性。

• 在多云部署中，数百/数千个应用程序的可重复性对于交付一致的客户体验至关重要。

• 云计算的货币机制使其谨慎地根据需要动态地扩展和缩减基础设施-在这种规模上手动管理几乎是不可能的。

使用基础架构作为代码，云本机应用程序可以大规模地具有一致，可靠且受版本控制的基础架构。但是，仅IaC并不能提供最佳的应用程序生命周期管理经验。该平台仍需要由Ops团队进行配置和管理。通过将抽象编写为基础层API的包装器来实现IaC，因此，开发人员将需要为每个抽象提供新的CLI。

为了获得流畅的开发人员体验，仅IaC还远远不够。我们需要平台作为代码。

平台即代码

平台即代码（PaC）是平台层的类似抽象。PaC允许您将有关平台层的声明性说明（包括应用程序的开发和操作所需的OS和其他工具）写入代码并执行。

本质上，PaC允许开发人员定义自己的平台：也就是说，为您的应用程序提供定制的执行环境。对于每个应用程序，这可能是不同的环境，有多少个应用程序。如果Kubernetes是您的平台，则可以像编写应用程序代码一样为平台元素编写YAML声明。

与IaC不同，PaC通过抽象实现为Kubernetes API扩展，而不是通过k8s API编写包装器。因此，PaC抽象成为一流的实体，允许开发人员使用kubectl和YAML提供声明性指令。

自动化所节省的时间和精力不言而喻。但是，在Kubernetes上PaC的真正价值在于，即使开发人员正在为其K8s集群创建自定义平台堆栈，它也将具有可重复性和可控制性。这将确保您的应用程序的开发/生产奇偶校验。所有平台元素（例如YAML文件，操作员清单等）都是可共享的。使用Kubernetes Operators，您还可以在多云环境中一致地部署。

平台作为代码的范例已实现了大规模，高效，一致，可重复的企业应用交付。通过通用语言进行的协作使Dev和Ops更加紧密。最重要的是，它为下一代开发生命周期工具铺平了道路-它提供了迭代开发，优化的工作流程，轻量级的客户端工具，可用于生产的CI / CD管道和以应用程序为中心的部署自动化。