通过消除基础设施负担来释放每个开发者和工程师的创造力，这是软件创新未来的关键。
译自 The Hidden Toll of Infrastructure on Developer Productivity 。
对于现代软件团队来说，一个肮脏的小秘密正在削弱他们的生产力：基础设施配置和管理不断分散开发者编写代码的注意力。但解决这个问题需要重新思考长期以来的假设。
过去，开发者编写应用程序并“抛过墙”给基础设施团队进行部署和运行。这种痛苦的分裂导致问题出现时摩擦和互相指责。
DevOps 运动通过基础设施即代码和左移测试等实践承诺要解决开发者和基础设施之间的分裂。但这已经足够远了吗？
provisioning 云资源、配置网络、管理 API 等基础设施任务仍然是时间黑洞，分散了开发者的注意力。
例如，一个简单的 “Hello World” 应用程序需要大量脚手架才能在 AWS 上运行——S3 存储桶、Lambda 函数、IAM 角色等等。对于本应只有几行代码的东西，Terraform 的脚手架文件可以轻松达到数百行。
生产应用程序通常有成千上万行仅专门用于云基础设施资源，而不是核心逻辑。作为开发者，我们喜欢编写代码，而不是配置。但基础设施的持续分心妨碍实现流程。
我亲眼目睹了这一点，在大型企业中，从 IT 或平台团队获得新的环境需要几周时间，因为变更审批流程和工单队列。开发人员会浪费时间切换上下文或等待，而不是编写代码。
调查显示，开发者花费高达 20%-60% 的时间用于集成和管理基础设施。这就是说每周可以致力于新功能的时间只有一到三天！
有人可能会争辩说，开发人员应该自己处理基础设施任务，作为向左转移的一部分。然而，这忽略了在应用程序和基础设施模式之间强加给工程师的不必要的上下文切换。
开发人员应该易于访问基础设施，但不应要求他们手动配置它。我们必须重新思考如何交付环境和资源以释放开发者的生产力。
具有前瞻性的组织不仅在左移测试，还在左移基础设施配置。开发人员在代码中描述意图和依赖关系，它会自动配置所需的资源，恰到好处。
随着基础设施需求的满足，开发人员避免了切换上下文。他们声明要求，系统在后台处理提供的复杂性。
这使基础设施更接近开发者，而无需强制他们自己成为基础设施专家。自动化使他们能够专注于编写业务逻辑并快速交付价值。
自动化基础设施配置不仅有助于开发者——它还使平台工程团队能够专注于安全性、治理和可靠性，而不是工单。
当开发人员可以自助满足其生产力需求时，它会减轻平台团队从重复、手工集中配置任务中解脱出来。用于基础设施请求的时间大幅下降。
随着配置的自动化，平台团队可以看到整个基础设施生命周期。他们可以左移安全扫描并实施治理护栏。云成本也变得透明。
对于没有专门平台角色的小团队来说，自动化提供了知识韧性。
开发人员避免了仅一个人掌握基础设施知识的风险情况。这种专业知识得以保留，从而使他们能够继续专注于提供功能。
从根本上说，我们需要使基础设施配置与现代软件团队的期望保持一致，以释放生产力。开发人员应该轻松访问准备就绪的环境，而不需要切换上下文。
前瞻性的解决方案正在出现，以采用这种向左转移理念。一些提供基于意图的基础设施即代码与自动配置。其他通过 CLI 提供自助服务环境。
检查这些创新方法可以帮助组织重新思考基础设施交付，而不仅仅停留在传统模型和手动工单上。现代生产力需要按需基础设施。
软件创新的未来取决于增强开发速度和流程。重新思考我们交付基础设施的方式是释放工程创造力、加速发布周期并使客户欣喜的关键。现在是时候将开发者生产力作为一流优先事项了。
如何诊断低效的基础设施交付是否会拖慢您的开发人员和平台团队？考虑以下任何症状是否听起来熟悉：
- 开发人员花费大量时间配置云资源和环境。
- 在应用程序代码和基础设施之间进行大量上下文切换。
- 由于变更审批流程，新环境需要数周的准备时间。
- 缺乏对基础设施使用和成本的可见性。
- 基础设施知识集中在一两个人员身上。
- 依赖部落知识来管理基础设施。
这些功能失调越多，您的组织从重新想象如何交付基础设施以最大限度地提高生产力中获益越多。
寻找方案：
- 提供自助服务基础设施配置。
- 允许在代码中声明式地描述基础设施需求。
- 根据需要自动配置云资源。
- 在所有主要云提供商之间一致工作。
- 为 FinOps 提供云成本可见性。
- 与开发人员 IDE 和工作流程集成。
- 具有预构建的模板和治理护栏。
- 支持逐步引入传统基础设施。
虽然向左转移可能会使开发人员不堪重负的基础设施责任，但新一代解决方案旨在以对开发者友好的方式向左转移配备，方法是自动化配置过程。这种方法提供了云可移植性和一致性，允许开发人员专注于代码而不是基础设施。反过来，开发者的生产力得到释放，平台团队的效率得到改进，创新得以加速。
按需配置基础设施最终允许开发人员专注于最重要的事情——快速为企业提供价值。平台团队可以将重点放在安全性、合规性和优化基础设施消耗方式上。
从手动集中的配置转向智能自动化，整个 IT 都会受益。但这需要对传统假设持开放态度。基础设施的未来必须与软件交付的未来保持一致。
从根本上说，我们建立 Nitric 的目的是与赋予开发者权力以更快交付的向左文化保持一致。我们认为软件创新的未来依赖于通过消除基础设施负担来释放每个开发者和工程师的创造力。
如我之前所述，在亚马逊网络服务上部署的生产级 “Hello World” 应用程序可能需要数百行基础设施即代码配置来配置所有必要的云资源，如 S3 存储桶、Lambda 函数、API 网关、IAM 角色等。 Nitric 的版本将这些样板文件减少到仅应用程序代码的五六行核心代码。
如果这个愿景让你产生共鸣，请今天查看 Nitric。我们热衷于把开发者从苦差事中解放出来，以便他们可以专注于将想法变成现实。我们希望您加入我们的使命，因为我们会继续改进开发人员的体验。让我们知道您的想法。