超越IaC：解决云计算中的关注点分离问题
内容提要
本文探讨了使用托管服务和基础设施即代码（IaC）部署和管理云资源时面临的挑战，并使用实际示例进行说明。它讨论了代码和IaC之间的手动同步需求，应用代码和IaC脚本之间的耦合，更新测试的必要性以及部署和配置问题的风险。文章介绍了基于代码的基础设施（IfC）作为一种更好的方法，为基础设施需求和使用提供了明确定义的接口。它通过一个真实世界的示例展示了IaC和IfC之间的差异，并强调了使用IfC实现的降低复杂性和改善关注点分离的优势。
延伸解读
关注点分离的常见误解
许多团队认为将应用代码和基础设施代码（如Terraform）分开存放就实现了关注点分离。但文章指出，真正的分离意味着一个模块的变更不会强制其他模块变更。在示例中，从SNS切换到EventBridge需要同时修改应用代码、IaC脚本、测试和配置，表明表面分离下存在严重耦合，导致系统脆弱。
更换托管服务的连锁反应
文章以SNS换EventBridge为例，详细说明了更换托管服务时需修改应用代码（替换库、调整API调用和错误处理）、IaC脚本（更新资源定义和权限）、测试（重写mock和事件类型）以及配置（环境变量名需严格匹配）。这些变更不仅工作量大，还引入部署风险，如环境变量拼写错误或IAM策略问题，可能直到运行时才暴露。
IfC如何实现更好的分离
基础设施从代码（IfC）通过定义明确的接口来分离应用架构与部署架构。应用开发者使用抽象API（如Nitric Topics API），无需了解底层服务细节。当更换服务时，只需调整基础设施层（如切换Nitric provider），应用代码和测试保持不变。这降低了复杂性，使应用和基础设施团队能独立工作，同时保留对底层服务的控制。
Q&A
基础设施即代码（IaC）存在哪些主要问题？
IaC存在应用脆弱性和关注点分离不足的问题，导致资源管理混乱和手动同步需求。
什么是基础设施从代码（IfC），它如何改善IaC的缺陷？
IfC通过提供明确的接口，将应用架构与部署架构分离，从而降低复杂性和改善关注点分离。
在更换云服务时，IaC和IfC的变化有什么不同？
使用IaC时，应用代码、IaC脚本和测试都需要修改，而IfC则可以将变化限制在基础设施层，其他代码不受影响。
缺乏关注点分离会导致哪些风险？
缺乏关注点分离可能导致系统脆弱，修改一个模块时需要同时修改多个模块，增加了出错的风险。
如何通过IfC实现更好的关注点分离？
IfC通过抽象基础设施细节，使应用开发者无需了解基础设施，确保应用与基础设施的独立性。
在使用IaC时，如何避免手动同步的需求？
通过采用IfC，应用开发者可以独立构建和测试应用，减少对IaC脚本的依赖，从而避免手动同步。
