投资于健壮的基础设施工作流自动化，可以减少阻力，帮助企业构建可扩展的产品。
译自 Can Automated Infrastructure Eliminate Job Tickets?，作者 Aditya Gune 在ReveCom Media Inc.担任作家和分析师，并且是Jetty的软件工程师。他拥有俄勒冈州立大学的计算机科学硕士学位，几乎有十年的软件构建经验，包括...
曾经有一段时间，开发人员编写的代码与其运行的基础设施非常接近。基础设施简单到工程师可以处理整个技术栈。这意味着他们可以同时管理用户体验、业务逻辑和服务器。但是企业软件发生了巨大变化：多个环境、云的兴起以及在可扩展性、监控和测试方面的巨大需求增加，使得产品工程师更难以按需创建、访问和管理基础设施。
事实上，随着产品规模的扩大，其基础设施变得越来越庞大且复杂（更多的服务和模块，以及每个服务和模块的复杂性增加），这使得管理本地环境变得困难。在初创阶段或A轮融资阶段，产品通常由一到两个服务组成。在这个阶段，几个服务可以轻松在本地运行或部署到云中的测试实例。然而，一个更成熟的产品，收入超过200万美元，很可能由多于五个服务组成，分布在多个环境中，许多开发人员排队使用它们。
进入基础设施工作流自动化领域。有了它，那些没有时间或专业知识来启动与其生产环境密切匹配的云基础设施的产品工程师可以利用自动化来完成这项工作。如果开发人员在运行时需要某些东西，他们不再需要等待支持工单或DevOps专业人员介入——或者更糟糕的是，自己设置它。他们可以绕过这一步骤，自动化该过程，立即获得自助选项。
这里发挥了基础设施即代码（IaC）的作用，允许开发人员在代码文件中声明性地定义、提供和管理云基础设施。这比手动导航云用户界面进行配置要节省时间，也更少出错。然而，IaC仍然需要开发团队付出相当的努力。
使用IaC设计应用程序需要积极的基础设施规划和代码对齐。尽管有积极的设计，应用程序与基础设施之间强大而松散统一的关系带来了复制的挑战。平台工程肩负着弥合这一差距的责任，但普遍的自助基础设施概念往往会削弱这些连接。将云原语集成到应用程序层中，而不是管理单独的实体，有助于实现天然云感知的应用程序，简化优化云解决方案的部署。相反，基础设施工作流自动化允许使用实际的代码来进行IaC。
使用Nitric框架将模式提取为可重用库。
对于缺乏强大平台团队的初创公司或小型企业，产品工程师花费在尝试启动基础设施上的每一分钟，都是本可以用来构建增收功能的时间。强大的自动化可以使产品工程师能够扩展产品，而无需担心如何提供他们所需的基础设施。开发人员可以——也应该能够——调用自动化工具，根据代码定义提供基础设施。
使用实际代码进行IaC。
以一个案例为例，当软件即服务（SaaS）产品刚刚起步时，它们的平台、基础设施和构建系统都有些不稳定。在这个阶段，开发人员需要灵活性来实验并决定哪种技术堆栈最适合他们的产品需求。手动管理复杂的云流程，如启动虚拟私有云（VPCs）和Amazon Elastic Container Service（ECS）集群，手动管理隐私和访问控制规则，并确保正确的资源扩展，这些都阻碍了开发人员创新的能力。
代码驱动的基础设施自动化可以从一开始管理这些，使产品工程师能够发挥他们的优势：通过构建客户想要的功能来增加收入。
借助智能的、代码驱动的平台，如开源的Nitric框架，产品工程师可以迅速而敏捷地通过在代码中引用关键基础设施来进行声明性设置。这已经被证明比努力应对繁琐的AWS或Microsoft Azure界面更快速、更简单，而这些界面只有少数人有正确管理的专业知识。通过该平台，澳大利亚健康科技公司Drop Bio Health作为Nitric的客户报告称，其AWS云账单减少了60%，部署速度提高了12倍，并实现了其他效率改进。
基础设施自动化还提高了创业公司以精益、以产品为中心的团队的安全性和风险状况。不正确设置基础设施可能会带来巨大的安全风险。在2001年，Gartner发现大多数IT安全问题是由于手动配置软件的错误。20多年后，这种威胁并没有改变。
许多人手不足的初创公司被迫接受绕过安全最佳实践的风险，直到他们建立起一个能够安全配置和管理基础设施的平台团队。这导致了更高的风险配置文件，这在许多公司遭受隐私泄漏的数量上得到了证明。但为了更快地进入市场而牺牲安全并不总是一个选项。
在金融科技、保险和医疗等受到严格监管的行业中，公司必须付出努力来精心管理它们的云资源。对于精益创业公司而言，这可能严重减少工程师用于构建产品的时间。
相反，自动化的配置可以通过将安全规则应用于基础设施来弥合这一差距，直到组织能够投资于管理更大更深层次基础设施所需的平台工程人才。
那些已经拥有平台团队的大型公司仍然从自动化中获得显著好处，因为它使得可靠性工程师（SREs）能够专注于他们自己的优先事项，而不是不断地满足产品工程师的需求。因此，对于那些已经拥有平台工程团队的公司，投资于基础设施自动化可以使他们的平台团队专注于自己的优先事项，如容器化、云迁移和IaC，而不是花时间配置新的微服务。
特别是IaC的采用产生了实质性的好处。但是它有很高的采用惯性，特别是对于具有大型或分布式架构的公司而言。尽管IaC的采用在平台工程领导的优先事项列表中排得很高，但组织通常难以实现目标。SRE团队通常过于忙碌，为产品工程师建立和拆除资源，以至于无法改变配置工作的方式。
问题在产品扩展时只会变得更加严重。与为小型产品建立单个计算实例不同，更大的架构涉及更复杂的元素，如无服务器计算、弹性存储和权限管理。这意味着平台工程师需要花费越来越多的时间手动创建、保障和清理基础设施，以满足产品工程团队的需求，而这又牺牲了推动他们自己倡议的进展。这些不断的需求累积效应使得工程领导越来越倾向于采用基础设施自动化。
基础设施自动化对技术组织还可以带来非技术方面的好处。对于平台工程领导而言，减少繁琐工作使得更容易吸引和留住顶尖人才。找到熟练的SREs已经很困难了，如果他们大部分时间都花在重复性的琐事上，要留住他们就更加困难。他们应该致力于挑战性的倡议，如可观察性或容器化，从而推动公司和他们自己的职业向前发展。
如果技术领导者觉得没有危机，他们通常不愿引入新技术。但采用基础设施自动化套件既是预防，也是治疗。它不必对路线图造成破坏。年轻的公司有一个优势，即可以在构建产品时包含自动化。
然而，即使是规模逐渐扩大的初创企业和中期初创公司，在其产品规模扩大、遗留系统需要更替或重构时，也可以相对轻松地实现自动化的配置工作流。在这个阶段引入基于代码的基础设施自动化作为逐步改进SRE技术栈的一部分，将为未来的开发铺平道路。即使将自动化限制在新创建的服务中，也比不做任何事情好，这让工程师们对工具链有了经验，并增强了领导层对这种方法有效性的信心。
无论何时引入，为基础设施投资强大的工作流自动化都可以减轻各种规模的技术组织的负担。这使得平台工程师和产品工程师都更容易工作。最重要的是，它让公司能够专注于其核心使命：构建可扩展的产品。