Page 37 - BP_202011
P. 37
图2表示模板、脚本和策略保存
在一个公共存储库中，可以适当地移
交给各个全球存在点，即云区或数据
中心。然后，每次操作都可以被推入
（或从存储库中拉出）到相关的位置
和职能部门。
一切即代码
一种类似的方法是将解决方案的
所有组件作为代码处理的操作。通过
将配置与源代码一起存储在存储库中
并作为虚拟环境，可以在需要时循环
图2 代码库包含模板、脚本和策略，可以被适当地管理（版本控制管理）。而当需要更新或更
或重新创建代码集。在这个模式中甚 改时，项目将被分发到全球存在点（云或数据中心）。
至系统设计也可作为代码存储。
一切即代码（EaC）模式减轻了为每个功能活 上）它们是如何与一个或另一个资源接口。这些工
动或任务安装物理硬件和连接的要求。在以云为中 具进一步让用户指配哪些资源是需要的、参数限制
心的环境中，这显然是不现实的，也是不可能的。 （量和持续时间）以及应该如何配置这些资源执行
因此，以前需要的专门的物理技能和设计师方法被 选定的任务和活动。
转换为一个代码就绪的环境。 在平台即服务（PaaS）架构中，用户可以使
本地云应用程序一旦被移交给物理修改，就改 用特定平台的用户界面分配或创建资源集，然后在
变了整个成本模式，使得启动“虚拟”基础设施变 整个操作过程中管理这些资源。同样，第三方解决
得容易，与位置无关。 方案提供商将制作图形用户界面(GUI)产品来管理
云和虚拟基础设施，并将这些产品销售给用户。然
常见的表述 而，缺点是，这些产品本质上是“受限于”（特定
与IaC类似，EaC模式也有类似的有益表述。 的）服务，需要在最初的规范、设计和测试上进行
可重复性（包括从一个云提供商转移到另一个云提 大量的投资，然后才能推广到服务。
供商的能力）允许精确地重建能够进一步利用新特 虽然可以说，一旦配置好，PaaS操作是可行
性（比如更快的性能或更低的每周期成本）的环 的——而且很可能被移植到到其他云提供商——但
境。可以大规模地开发、验证经测试的基础设施代 该模式没有那么灵活。当云的内部模式中出现系
码（通过计算建模），然后带着它将快速运行并符 统变化时，需要维护的应用程序被升级。有时这
合设计要求的期望、信心和保证，直接推广到制作 些变化会影响PaaS应用程序，有时PaaS会“自适
中。 应”。这一切都与类型、使用和应用程序有关，都
对服务器配置漂移的恐惧、不确定性和怀疑因 是当时为特定服务部署的。
素（FUD）几乎完全消除了。这些新模式几乎可以
自愈到任何水平——包括如果服务器停止运行或需 编码技术演进
要打补丁以保持可操作性时进行完整的重新部署。 通过开放访问云的虚拟“活动部件”，IaaS和
由于整个基础设施是以代码形式开发的，所以在检 PaaS模式正在发生变化。以前，基于代码的开发
测到异常时，可以启动一个没有交叉依赖性的系统 仅限于一组代码级的专家，新的时代正在发展到集
镜像，保持业务不中断。 成机器学习和人类可读的做法，从而变得更加普遍
和更富有成效。
基础设施工具 云服务的早期采用者认识到对动态基础设施平
要使云解决方案切实可行，它们需要是动态 台的需求，现在正在改变他们的内部应用程序，以
的。基础设施资源属于这一类。这类似于拥有无限 实现他们自己的自供应和配置能力。对于那些位于
的修补和改组能力，而无需人类主动操纵这些功 私有（非公有云）数据中心的系统，一旦用户/操
能。根据他们的功能集，每家云提供商可能都有自 作员了解了流程、模式、做法和可访问性，他们最
己的IaC或EaC“特点”。 终就可以安排自己的服务器结构，构建自己的服务
这样的工具集允许云计算客户指定他们需要 器模板，并提高在不中断工作的情况下升级运行中
的基础设施资源，而不必真正理解（逻辑上或物理 的服务器的能力。 B&P
37
