您永远不能指责 IT 停滞不前。缓慢而笨重的软件项目已成为历史，而基础设施比五年前的可用性要高得多——并且为了一致性而进行了编纂。瓶颈已经转移。今天，让我们所有人放慢速度的一个关键领域是通过多年的工作实践和经验开发的可信流程。
无论是否存在瓶颈，消防水带仍在企业 IT 上。此博客探讨了您现有的流程资产和负债，并推荐了将企业应用程序映射到 DevOps 的操作过程。
让我们首先看看近年来 IT 如何以敏捷的速度发展。随着敏捷软件开发宣言的发布，种子于 2001 年播下。这承诺个人和交互高于流程和工具，工作软件高于综合文档，以及客户协作高于合同谈判。 2008 年，Hudson 持续集成 (CI) 工具面世，提供更快的速度和易用性。到 2012 年，我们看到了虚拟化的出现（以及随后的广泛采用）。
网络时代给我们带来了像 Twitter、Uber、YouTube 和 Airbnb 这样的年轻、渴望的独角兽组织——通常由车库里的两个人诞生。这些公司并没有背负 40 年的遗留技术，而是渴望采用敏捷方法。有些人天生就有。他们的创新、智慧和有限的遗产促成了我们今天使用的一些最流行的 DevOps 技术和工具。从 2010 年开始出现的基础设施即代码——例如 Puppet、Chef 和 SaltStack——都促进了更快的创新和 DevOps 的发展，我们甚至现在看到下一波敏捷性以容器和微架构的形式兴起。
在这种背景下，我们有企业坚持使用 30 年、40 年或更长时间的遗留基础设施。这些公司依赖相互依赖的应用程序，这些应用程序在多年的开发和业务收购活动中紧密耦合在一起。在这些类型的应用程序中，多种技术被捆绑在一起，不同的团队跨越不同的地域工作，并且存在很强的相互依赖性和严格的规则和规定。
受困于遗留基础设施的企业需要对其发展战略采取行动。随着技术、服务器、设备和集成数量的增加，复杂性将不断增加。 IT 消费化继续推高客户期望。在应用程序的上下文中，开发过程有所增加，而交付时间预期有所下降。
工艺选择
那么，您如何才能将这些遗留企业应用程序映射到 Agile 和 DevOps，并应对对新应用程序的大量需求？好吧，有三种向后移植的选择可供选择。
1.重写应用
我不能是认真的……可以吗？好吧，如果应用程序相对较小且简单，那么有时重新编写或重新构建它是有意义的。但通常这对于大型任务关键型应用程序和遗留系统来说不是一个可行的选择。重写是昂贵的、需要时间的、充满风险的、对业务有破坏性的，并且需要大量的资源——这就是为什么很多时候这个选项首先被取消的原因
2. 尝试编纂
您可能会考虑放弃现有的手动和脚本化部署流程，并使用 Chef、Puppet、SaltStack 或其他替代方案“编纂”。所需的投资有时是低端的开源替代品，风险肯定低于重写应用程序。然而，编纂仍然意味着放弃现有的可信流程和部署流程的重新架构。用大型企业系统尝试这样做确实会消耗大量时间、资源和注意力。此外，它可能极其复杂且容易出错。竞态条件、传递依赖和许多其他重要示例非常丰富，尤其是当需要特定顺序的流程和跨层同步作为这些流程的一部分时。
3. 自动化现有流程
通过 自动化现有流程 ，您可以真正控制应用程序、版本和环境变化的复杂矩阵——比前两种方法更快，风险也大大降低。您受益于产品包和提升路径，因此您可以确信部署的内容是正确的。工作流提供了一种标准的、有质量保证的方式来一致地部署变更。部署模型确保将正确的设置和配置应用于每个环境。
通过 业务自动化 ，您可以真正开始与那些年轻、充满活力的组织（车库里的两个人）保持同步，而不会被多年遗留基础设施拖累。
