如果你是一个媒体创作单位，你希望充分利用通过内容创作各个阶段的潜在机会。其中之一是开发一组针对特定工作流程要求的可重复的需求，这样就更容易实现“常规”模式下操作。
　　当同时或独立运行多组进程时，定制或复制这些运行模式的能力是有益的。云服务或内部数据中心可以为这些机会提供有效的渠道；但是，必须根据基础设施中的系统变化进行重新配置，这可能会非常耗时、复杂，特别是日常流程和简单更新也需要专门的资源。
　　通过机器可读的定义文件配置和管理数据中心是所谓基础设施即代码（IaC）的前提。IaC不支持直接的物理硬件配置或构建在交互式配置工具上的解决方案，而是使用运算中心的、基于机器语言的“文件”来管理那些计算进程。
　　在基于云的解决方案集中，IaC使用模板部署资源，也就是文件既人可读，也机器可读，并且指示系统实际上自动地自行配置其功能。云服务提供商提供这样的IaC解决方案集作为“内置选项”——用户可以使用或忽略它。
　　基本上，一旦创建了代码模板，云系统就会接受这些代码指令并将其派发到云的资源中，无需用户进一步直接干预。为了实现目标而更新调出资源或替换任何处理器链的要求都被作为后台功能处理，本质上成为一种“不插手”的操作。图1描述了从用户到服务（无论是在云中还是在本地数据中心）的工作流程基本要素。
　　IaC好处
　　IaC对应用的好处包括可见性、稳定性和可扩展性。其它好处包括安全性、验证、可重复性等。
　　当在模板的每个实例中都使用相同的设置时，就可以实现安全的可重复性。某一配置是稳定的并准备运行的验证，可以确保如果出现故障，可以将基础设施转回到已知状态，而不会导致组件的灾难性崩溃。根据规定的工作流程，操作可以继续或暂停。
　　可见性让用户获得帐户上使用了哪些资源的清晰参考点。如果某些意外更改（例如错误设置或意外删除资源），IaC部署中使用的稳定机制可以结合使用当前或以前的控制管理版本帮助解决该更改问题。
　　可扩展性同样重要。建立一个围绕可重复使用的代码集库将产生模板化模型，它可以轻松地分发给全局多个服务。如果某一地区需要增加意外的交付作品，那么最近的云端口可以以可能在另一个相隔较远的站点使用的模板为基础，快速运转服务和基础设施。如果存储库可以在另一个区域投入使用，用户就不一定需要将数据传输到另一个站点。
　　图2表示模板、脚本和策略保存在一个公共存储库中，可以适当地移交给各个全球存在点，即云区或数据中心。然后，每次操作都可以被推入（或从存储库中拉出）到相关的位置和职能部门。
　　一切即代码
　　一种类似的方法是将解决方案的所有组件作为代码处理的操作。通过将配置与源代码一起存储在存储库中并作为虚拟环境，可以在需要时循环或重新创建代码集。在这个模式中甚至系统设计也可作为代码存储。
　　一切即代码（EaC）模式减轻了为每个功能活动或任务安装物理硬件和连接的要求。在以云为中心的环境中，这显然是不现实的，也是不可能的。因此，以前需要的专门的物理技能和设计师方法被转换为一个代码就绪的环境。
　　本地云应用程序一旦被移交给物理修改，就改变了整个成本模式，使得启动“虚拟”基础设施变得容易，与位置无关。
　　常见的表述
　　与IaC类似，EaC模式也有类似的有益表述。可重复性（包括从一个云提供商转移到另一个云提供商的能力）允许精确地重建能够进一步利用新特性（比如更快的性能或更低的每周期成本）的环境。可以大规模地开发、验证经测试的基础设施代码（通过计算建模），然后带着它将快速运行并符合设计要求的期望、信心和保证，直接推广到制作中。
　　对服务器配置漂移的恐惧、不确定性和怀疑因素（FUD）几乎完全消除了。这些新模式几乎可以自愈到任何水平——包括如果服务器停止运行或需要打补丁以保持可操作性时进行完整的重新部署。由于整个基础设施是以代码形式开发的，所以在检测到异常时，可以启动一个没有交叉依赖性的系统镜像，保持业务不中断。
　　基础设施工具
　　要使云解决方案切实可行，它们需要是动态的。基础设施资源属于这一类。这类似于拥有无限的修补和改组能力，而无需人类主动操纵这些功能。根据他们的功能集，每家云提供商可能都有自己的IaC或EaC“特点”。


　　这样的工具集允许云计算客户指定他们需要的基础设施资源，而不必真正理解（逻辑上或物理上）它们是如何与一个或另一个资源接口。这些工具进一步让用户指配哪些资源是需要的、参数限制（量和持续时间）以及应该如何配置这些资源执行选定的任务和活动。
　　在平台即服务（PaaS）架构中，用户可以使用特定平台的用户界面分配或创建资源集，然后在整个操作过程中管理这些资源。同样，第三方解决方案提供商将制作图形用户界面（GUI）产品来管理云和虚拟基础设施，并将这些产品销售给用户。然而，缺点是，这些产品本质上是“受限于”（特定的）服务，需要在最初的规范、设计和测试上进行大量的投资，然后才能推广到服务。
　　虽然可以说，一旦配置好，PaaS操作是可行的——而且很可能被移植到到其他云提供商——但该模式没有那么灵活。当云的内部模式中出现系统变化时，需要维护的应用程序被升级。有时这些变化会影响PaaS应用程序，有时PaaS会“自适应”。这一切都与类型、使用和应用程序有关，都是当时为特定服务部署的。
　　编码技术演进
　　通过开放访问云的虚拟“活动部件”，IaaS和PaaS模式正在发生变化。以前，基于代码的开发仅限于一组代码级的专家，新的时代正在发展到集成机器学习和人类可读的做法，从而變得更加普遍和更富有成效。
　　云服务的早期采用者认识到对动态基础设施平台的需求，现在正在改变他们的内部应用程序，以实现他们自己的自供应和配置能力。对于那些位于私有（非公有云）数据中心的系统，一旦用户/操作员了解了流程、模式、做法和可访问性，他们最终就可以安排自己的服务器结构，构建自己的服务器模板，并提高在不中断工作的情况下升级运行中的服务器的能力。B&P