对于任何一个力，都存在着一个与其大小相等方向相反的反作用力。这个物理学上的牛顿第三定律也同样适用于IaC：虽然这一服务是有优势的，但它也带来了一些问题。
本文是针对混合云和多个云管理使用基础设施即代码系列中的一部分。
基础设施即代码是一个强大的工具，它可以帮助简化混合云和多个云的管理工作，因为它能够实现服务器、容器以及虚拟机的部署与配置操作的自动化。但是，它也可能会导致出现低效过程、部署错误以及常见混乱等问题。那么，用户应当如何解决实施能够确定成功与否的基础设施即代码所带来的挑战呢?
在实施基础设施即代码过程中，大多数企业所遇到的第一个挑战就是在开发人员和运营团队之间创建一个和谐融洽的平稳关系。在过去，开发人员在为应用程序设置托管平台时几乎很难有所作为。这就会带来问题，尤其是在从应用程序测试到实际生产的过渡过程中更是如此。在大型企业中最常用的开发运营工具能够有助于推动开发团队和运营团队之间的协作。但是，对于那些缺乏开发运营理念与工具以及相关企业文化的公司来说，实施一个混合云或多个云可能是第一次需要这样一种合作。
如果企业用户在开发初期就将应用与特定平台相互关联，然后让这些平台需求推动基础设施策略贯穿整个应用程序生命周期管理直至最后生产，那么实施一次基础设施即代码还较为容易完成的。此外，当虚拟平台数量是可管理时，这一目标也是较为容易实现的。这些虚拟平台是应用开发的目标，它们可用于在所有云中或者数据中心资源(应用就是在数据中心资源上运行的)上部署应用。仔细定义这些虚拟平台并让开发团队和运营团队使用它们作为各自工作的重点。
不要模糊不同角色之间的界限
第二个挑战就是确保基础设施即代码和开发运营团队在混合云和多个云管理策略中各司其职，正常发挥合适的作用。开发运营主要关注应用程序部署，而基础设施即代码则主要负责资源配置管理。亚马逊网络服务(AWS)提供了开发运营工具Chef作为其云服务的部署管理工具，这一事实表明两者之间的界限有可能会发生模糊。事实上，最常见的基础设施即代码工具是开发运营的一部分。这一状况可能会造成开发团队和运营团队之间的持续混乱。
除非用户纯粹出于服务器整合的目的来使用云服务，希望还需要开发运营来实现部署自定义和应用程序生命周期管理的简化。对于企业用户来说，如果没有正确好用的工具集，那么部署多层次、多组件应用程序并保持一致地正确协调应用程序响应云计算或数据中心故障将是一项非常困难的任务。即便用户并不立即需要所有的开发运营能力 ，那么也可以选择一个开发运营工具，例如Chef、Puppet、Ansible或Salt等，然后采用其基础设施即代码方法。
不要千篇一律地对待所有的云服务供应商
当使用基础设施即代码来简化混合云和多个云管理时，第三个挑战就是解决不同云托管环境之间的差异性问题。大多数用户最终将使用一个混合云计算模式或多个云模式，而其中很多人已经这样做了。每一家公共云供应商都有一个不同的管理框架，他们报告问题的方式也不一样，如果发生错误所需要采取的补救措施也不相同。管理这些问题将让开发运营所部属的和基础设施即代码所控制配置的应用程序之间的界限变得模糊起来。
按照用户开发运营工具供应商的建议来区分定义，何种情况由基础设施即代码层来处理，何种情况在开发运营层作为“事件”上报。确定用户所计划做出的任何变更是否会影响如何部署虚拟平台，或者如何部署应用程序本身。在第一种情况下，可考虑重新部署资源，例如虚拟机或容器;而在第二种情况下，可考虑重新部署应用组件。例如，如果用户必须扩展应用程序中一个组件，那么相关变更必须发生在开发运营层，但如果用户必须更换故障组件，那么有可能应在基础设施即代码层实施这一操作。
云供应商有不同的网络服务，这一事实就带来了下一个挑战。基础设施即服务和基本容器服务在应用镜像外提供了最小的中间件。但是一些供应商(例如AWS和微软Azure)提供的网络服务从本质上说就是云托管的中间件。云供应商提供这些网络服务的形式各有不同，或者在某些情况下，他们甚至都完全不提供这些网络服务。
由于不同的托管环境无法提供相同的功能，所以应用无法具备跨不同托管环境的可移植性。如果不可能在多家云计算供应商之间实现网络服务的一致性，那么应当明确命名虚拟平台以表明它们是不可移植的。如果用户所使用的所有平台上必要的网络服务可用，但需要不同的部署配置，那么用户可以使用基础设施即代码脚本程序来为用户虚拟平台定义多个托管选项。
不要碎片化实施基础设施即代码
实施基础设施即代码的最后一个挑战就是配置外部的小修小补。让基础设施即代码在断开连接的碎片环境中正常运行是非常困难的，同样让企业在缺乏基础设施即代码工具或脚本程序的情况下做出某些配置变更也是非常不容易的。例如，运营团队经常会在不更改基础设施即代码脚本程序或模式的情况下做出一些配置变更以适应新的软件版本。这就意味着这些脚本程序将不再部署托管配置的正确版本。
解决这个问题需要执行严格的运行纪律。如果没有通过正式的变更管理系统将这个变更记录在册，那么运营团队就绝不应当对系统或云配置做出这样一个变更操作。当他们确实需要做出变更时，他们应当修改基础设施即代码脚本程序并按要求重新配置，然后将相关变更登记在册。无论何时运营团队修改了基础设施即代码的脚本程序，他们都必须将这个变更反馈给开发团队以便针对应用程序需要验证该变更。
基础设施即代码是基于配置管理和开发运营的一种发展，但他也是一个新兴的范例。为基础设施即代码的未来做好规划是非常重要的，否则用户将面临无法发挥混合云和多个云管理部署全部潜力的风险。
本文作者：佚名
来源：51CTO
