概念框架注重精确定义基础设施组件，实现细节被分离并独立管理。
译自 Navigating the Evolution: Infrastructure as Catalog 。
从起步到现在，基础设施管理的演变过程是一次变革性的旅程。过去，基础设施管理有点像试图搭建一个复杂的多米诺骨牌。你必须在各种脚本和方法中左右周旋，目的是让所有部分恰如其分地组合在一起。这需要专业人员，他们精通自己的技术——云服务、组织架构和所有最新的开发工具。尽管你多擅长，这往往也只是短暂的胜利，因为技术进步随时会来改变游戏规则。
当DevOps登场时，它被视为救世主。技术社区对此欢欣鼓舞并接受了它，特别是因为它致力于三大核心领域:处理基于云的基础设施和数据库的确定流程，简化部署和交付流水线，以及获得顶级的运行时环境监控。这确实有所帮助，但像技术领域的任何事物一样，总有“下一个”。在这种情况下，那就是基础设施即代码(IaC)。
基础设施即代码(IaC)作为另一项革命性理念出现，它提供了一种结构化语言来编码基础设施需求。IaC 永远改变了传统基础设施管理的方式。尽管IaC有陡峭的学习曲线，还有细微失误或错误带来的严重后果，但它仍激起了热情。这有点像拥有一辆超级跑车，但我们必须小心不要将它开到极限，以免发生事故。由于固有风险，使IaC普及存在挑战，需要严格的防护措施才能实现任何形式的开发人员自助服务。
由于压力和焦虑，许多人对IaC的最初兴奋很快就消失了。这导致项目要么延迟，要么未完成，要么充斥着临时解决方案。这凸显了对准确抽象级别的需求，引出了基础设施即目录(InCa)的出现。这标志着基础设施管理演变中的又一个重要里程碑。
基础设施即目录(InCa)是一个概念框架，关注精确定义基础设施组件，而实现细节被分离并独立管理。网络、Kubernetes、服务和数据库等架构组件被建模为意图，每个意图都有特定的模式来定义其类型和结构。InCa 将吸收IaC的所有优点并使其更简单直观，更易于管理。
InCa 旨在增强架构的透明度和理解度。所有参与基础设施管理的人都可以通过目录理解架构。它可以轻松地在预设的防护措施内执行操作。平台工程师可以轻松修改实现，在不同的云服务和提供商之间进行选择。这种方法不仅可以解决 IaC 中固有的普及难题，还可以消除对额外工具的需求，从而减轻对更改目录的担忧。InCa 将确保所有更改都是可审计、可逆转和彻底记录在git中的。
那么，InCa 对我们 DevOps 的三大核心问题有何帮助?
使用 InCa，基础设施和数据库等组件以具有独特轮廓的“意图”方式捕获。这样，我们不仅记录我们需要什么，而且表达得很清晰。此外，将“什么”与“如何”分离，给予平台工程师根据需要在不同云服务之间切换的灵活性。这是关于使我们的技术环境尽可能适应变化。
不需要眯眼猜测。目录为我们列出了所有内容。这种透明度将确保在建立流水线时，不仅高效而且更易于管理。由于每个人都在同一页面上，开发人员可以协作调整配置，在部署过程中培养团队合作精神。
这是 InCa 真正发挥作用的地方。其设计使我们可以轻松集成监控工具，确保系统始终处于最佳状态。通过在“意图”中内置监控，我们不再需要最后一刻设置工具。这是一种更流畅、更贴合的方法，可以确保我们的运行环境受到持续监控，及时发现并解决问题，防止问题升级。
想象一个世界，来自全球各地的技术专家聚集分享和共同创建实现方案。使用 InCa，我们可以拥有一个巨大的存储库，其中这些“意图”被翻译成适应不同云提供商的版本。这不仅仅是解决问题，更是创新并推动可能性的边界。
基础设施管理的历程是持续演进的，从集成各种脚本的阶段，到IaC的出现，再到基础设施即目录(InCa)的概念化。InCa 旨在通过提供正确的抽象级别和目录表示来增强架构理解度而脱颖而出。这种创新模式将促进社区合作、快速创新和透明可审计的操作，许诺一个更高效、更可靠和更包容的基础设施管理未来。