数据基础设施越多，问题越多

无论数据基础设施位于云端、本地还是二者皆有（通常称混合），在手动配置时都要花费大量时间。在编辑器中输入命令并进行非常详细的配置需要深入掌握各种技术。在过去20年中，DevOps团队在编码和部署数据基础设施方面取得了重大进展，这是现代数据基础设施的重大进步。DevOps赋予了应用的扩展能力，但仅此而已。换言之，它并没有降低编写一个完整数据库服务器部署脚本所需的技能。现在只是（按需）通过模板和脚本来重复执行相同的操作而已。组件之间缺乏连通性及整个应用技术栈缺乏全面描述的问题始终存在，亟待解决。

如同解决工程问题一样，可以把这个大问题分解为若干易于处理的小问题。第一个小问题是资源管理。我们创造出很多适合大规模作业的方式，但这些方式从根本上都是为了尽量高效地管理计算、网络和存储的，如图1-3所示。这3个目标关乎每个应用都需要的关键资源，也是驱动增长的“燃料”。毫无疑问，它们是将资本转化为正常应用的关键资源。理智地使用资源能获得回报，反之则需要付出高昂的代价。无论在哪里运行应用，计算、网络和存储都是最基本的单元。区别在于，在本地运行应用时，一切资源都由自己购买并且归自己所有。而在云上运行应用时，这些资源都是租借别人的。

图1-3 云应用的基础资源：计算、网络和存储

第二个小问题是全部技术栈形成一个整体。DevOps提供了很多管理单个组件的工具，如果将这些组件连接起来，那么有望带来惊人的效率提升。这种模式类似于在桌面上封装应用，在数据中心层面上运行应用。为此，围绕云原生应用已经建立起完整的社区。这些应用与我们一直部署的应用极为相似。不同之处在于，现代云应用不具有业务逻辑的单一流程，而需要进行复杂的协调工作，以确保众多容器化进程可以安全、可靠地进行通信。存储必须匹配应用的当前需求，但也要确保应用的稳定性。只是部署无状态应用，不在同一个控制层面上管理数据，听起来很不完整，事实上也的确不完整。将应用组件分解到不同的控制层面上会让事情变得更加复杂，并且与理想的云原生背道而驰。