使用基础设施即代码(IaC)，捏可以编写有关基础设施计算，存储和网络要求的声明性说明，然后执行该声明。这与平台即代码(PaC)有什么不同?
任何应用程序的技术堆栈都分为三层，即包含裸机实例，虚拟机，网络，防火墙，安全性等的基础层;具有操作系统，运行时环境，开发工具等的平台层;当然还有包含应用程序代码和数据的应用程序层。典型的技术运维团队除了可以部署代码外，还负责基础层和平台层的部署，监控和管理任务。
云计算的兴起，首先让基础层得以抽象化。借助基础架构即服务(IaaS)模型，IT/运维团队只需通过云即可立即配置云基础架构。AWS、微软Azure、谷歌GCE，阿里云等都提供广泛的IaaS服务，如AWS EC2。在其上的是平台即服务(PaaS)模型。基础设施提供商在云上提供平台层，包括云操作系统，开发工具，数据库管理等。比如你熟悉的AWS Beanstalk，Azure CDN，Google App Engine之类的PaaS服务也广受欢迎。
实际上，运维团队还自己构建PaaS平台，将选定的功能子集整合到与其现有的基础架构兼容，或具有自定义工作流程的功能。如果你使用容器化或微服务范式，这可能会让你变得乏味且笨拙。
在构建基于微服务的应用程序中对规模，一致性，可重复性，可共享性和可审计性的需求，迫使运维团队考虑采用新方法来处理基础层和平台层。正是针对这些担忧，出现了基础架构即代码(IaC)和平台即代码(PaC)的概念。
基础架构即代码
基础架构即代码通过软件而不是物理硬件配置或其他工具来管理和配置基础架构。使用IaC，你可以编写有关基础设施的计算，存储和网络要求的声明性说明并执行。然后，自动化引擎(如AWS Cloud Formation和Terraform之类的工具)将通过抽象的IaaS API捕获声明/代码来为你配置它。
结果，无论是交付管道的自然组成部分，还是为了响应特定事件而自动扩展，供应基础设施的速度都将显著提高。如果你使用dev，QA，staging，prod等多种环境，则使用同一代码库启动基础结构可确保一致性，并通过减少错误配置，停机等风险等来节省大量时间和可能的麻烦。变更管理也变得非常重要，而且更简单。你可以编写代码来更新基础结构，并具有完整的版本控制。
这对云上的容器化应用程序特别有影响：
容器化和微服务启动了数百个小型应用程序，而不是像以前的开发范例中那样使用少数大型实例。在这样的规模下，开发过程将存在时间滞后，从而严重影响敏捷性。
在多云部署中，数百/数千个应用程序的可重复性对于交付一致的客户体验至关重要。
云计算的付费机制，使其谨慎地根据需要动态扩展和缩减基础架构，在这种规模上几乎无法手动进行管理。
使用基础架构即代码，云本机应用程序可以大规模地具有一致，可靠且受版本控制的基础架构。但是，仅IaC并不能提供最佳的应用程序生命周期管理经验。该平台仍需要由运维团队进行配置和管理。IaC是通过将抽象作为基础层API的包装程序来实现的，因此，开发人员将需要为每个抽象提供新的CLI。
为了获得流畅的开发人员体验，仅IaC还远远不够。我们需要平台即代码。
平台即代码
平台即代码(PaC)是平台层的抽象。PaC允许将有关平台层的声明性说明，包括应用程序的开发和操作所需的操作系统和其他工具写入代码并执行。
本质上，PaC允许开发人员定义自己的平台。也就是说，为应用程序提供定制的执行环境。对于每个应用程序来说，这可能是不同的环境，它们有多少个。如果Kubernetes是你选择平台，则可以像编写应用程序代码一样为平台元素编写YAML声明。
与IaC不同，PaC通过抽象实现为Kubernetes API扩展，而不是通过k8s API编写包装器。因此，PaC抽象成为一流的实体，允许开发人员使用kubectl和YAML提供声明性指令。
自动化所节省的时间和精力不言而喻。但是，在Kubernetes上PaC的真正价值在于，即使开发人员正在为其K8s集群创建自定义平台堆栈，它也将具有可重复性和可控制性。这将确保应用程序的开发/生产的奇偶性。所有平台元素，例如YAML文件，管理员清单等都是可共享的。使用Kubernetes Operators还可以在多云环境中一致地部署。
平台即代码范例，已实现了大规模，高效，一致，可重复的企业应用交付。通过通用语言进行协作，使开发(Dev)和运维(Ops)更加紧密。最重要的是，它为下一代开发生命周期工具铺平了道路。它提供了迭代开发，优化的工作流，轻量级的客户端工具，可用于生产的CI/CD管道和以应用程序为中心的部署自动化。
