大多数工程团队最初并不是为了管理基础设施而开始工作的。他们通常是带着某个产品创意、客户需求或业务问题来开展工作的。
基础设施之所以会被纳入考虑范围，是因为它是一种实现目标的手段。需要配置服务器，需要设置数据库，还需要保障网络的安全性。起初，这些工作看起来是必要的，甚至会让团队感到自己拥有了更多的掌控力。
但随着时间的推移，这种掌控力反而会变成一种负担。
最初可能只是编写几个Terraform脚本或通过云控制台进行一些操作，但很快就会导致责任范围不断扩大。
团队最终会发现自己需要维护部署流程、排查网络问题、定期更换访问凭证、为系统打补丁，还要处理那些与他们的产品逻辑无关的突发事件。
这就是基础设施所带来的隐性负担。它不会出现在你的预算清单中，但每天都会消耗工程师的时间、精力，还会导致他们无法集中注意力去完成其他工作。
我们将讨论的内容：
基础设施不是一次性投入的成本
团队们常犯的一个错误就是将基础设施视为一次性的设置任务，认为只要完成这些设置就可以万事大吉了。
但实际上，基础设施是一个持续变化的系统。它的状态会随着业务规模、流量模式、安全威胁以及团队架构的变化而发生变化。
你引入的每一个组件都会带来一系列后续的运维工作。例如，负载均衡器不仅仅是一个简单的负载分配工具，它还需要进行配置调整、监控、故障转移规划以及定期升级；数据库也不仅仅是存储数据的工具，还需要考虑备份策略、数据复制问题、索引设计以及性能优化等等。
即使使用了基础设施即代码工具，维护负担也不会消失。这些工作虽然被固化成了代码形式，但依然存在。工程师们仍然需要审查各种变更，管理系统的状态，处理系统出现的问题，并在故障发生时及时作出响应。
这些成本会悄然累积起来。它们表现为交付周期变长、新工程师的入职培训时间增加，以及部署过程中风险上升。在冲刺计划中这些影响可能并不明显，但它们确实存在。
认知负荷问题
在基础设施管理中，最常被忽视的一个方面就是认知负荷。
现代系统极其复杂。分布式架构、微服务、容器编排以及多区域部署都引入了诸多抽象层次，工程师必须理解这些概念才能正常工作。
当一个团队负责自身的基础设施时，每位工程师都会在一定程度上承担这种复杂性带来的责任。即使有专门的平台工程师，应用程序开发人员也需要具备足够的知识，以便能够排查问题并安全地部署变更。
这种频繁切换工作内容的行为会带来实际的代价。例如，当工程师在开发某个功能时，他们还必须考虑容器资源限制、网络规则、可观测性方面的问题以及系统可能出现故障的情况。这样一来，他们就无法专心专注于业务逻辑的实现。
认知负荷会降低团队的工作效率，增加出错的可能性，还会使系统变得更难以理解。同时，它也会减少工程师们用于开发那些真正能提升产品竞争力的功能的时间。
可靠性其实比看起来更难实现
在生产环境中运行基础设施意味着必须确保其具备较高的可靠性。这包括保证系统的正常运行时间、降低延迟、保障数据完整性，以及及时响应各种故障事件。许多团队都低估了实现这些目标的难度。
高可用性并不仅仅意味着增加冗余措施。它还需要精心设计、进行测试，并持续进行验证。故障转移机制必须得到有效测试，监控系统也必须经过调整，以便能够准确检测出问题而不产生不必要的干扰。此外，还必须制定并执行相应的故障响应流程。
一旦出现问题，其后果会立刻显现出来。工程师们会被牵扯进故障排查工作中，客户也会受到影响，业务指标也会下降。之后还需要进行事后分析，并制定相应的补救措施，而这些措施往往又会进一步增加基础设施的复杂性。
随着时间的推移，团队会逐步建立各种防护机制和工具来提升系统的可靠性。然而，每添加一层防护措施，管理的工作量就会相应增加，系统变更的难度也会提高，出现意外后果的风险也随之增大。
这就是自我管理基础设施所面临的悖论：你为提高可靠性投入得越多，系统就会变得越复杂，维护这种可靠性的成本也就越高。
安全与合规性要求总是在变化
安全也是另一个需要持续关注的方面。威胁在不断演变，最佳实践也在不断更新，合规性要求也会变得越来越严格。
当你自己负责管理基础设施时，你就必须时刻关注这些变化。这包括为系统打补丁、管理访问权限、对数据进行加密、审核日志记录，以及及时处理各种安全漏洞问题。
即使是很小的漏洞也可能带来严重的后果。配置错误的权限设置、过时的依赖关系，或者暴露在外的接口都可能导致安全问题。采取预防措施需要持续不断的努力，而一旦出现问题，其代价可能是灾难性的。
合规性要求为基础设施管理增添了另一层复杂性。对于那些处于受监管行业中的团队来说，他们的基础设施必须符合特定的标准。这通常意味着需要进行文档编制、审计，并采取一些超出基本安全措施范围的管控措施。
所有这些工作都是必要的，但它们并不会直接提升你产品的价值。实际上，这些都是你在使用基础设施时不得不承担的“隐性成本”。
控制的错觉
团队之所以继续自行管理基础设施，主要是因为他们认为这样就能掌握控制权——他们可以自定义一切设置，可以根据自己的具体需求进行优化，而且也不需要依赖外部平台。
从理论上讲，这种想法确实没错，但实际上，这种所谓的“控制权”往往被夸大了。大多数团队其实并不需要在基础设施层面进行深度定制，他们真正需要的是系统的可靠性、可扩展性以及行为的可预测性。
你获得的这种“控制权”，实际上是以承担更多责任为代价的。每一个自定义设置都需要后续维护，每一次优化措施也都必须被持续监控。任何偏离标准操作模式的行为，都会增加出现问题的风险。
在很多情况下，团队最终会重复开发那些在第三方管理平台上就已经存在的功能。他们花费大量精力构建用于部署、扩展和监控的内部工具，却不得不长期维持这些系统。
问题不在于你是否能够自行管理基础设施，而在于你是否真的应该这么做。对于大多数中小型团队来说，根本就不应该自己去管理基础设施。如果这不能成为你的竞争优势，那么这种做法只会分散你的精力。
在哪些情况下自行管理基础设施才是合理的
说没有任何团队应该自行管理基础设施是不正确的。在某些情况下，这样做不仅合理，甚至是必要的。
那些对性能或延迟有极高要求的大型系统，往往需要对其基础设施进行深度定制和精细化管理。像Netflix或Uber这样的企业会投入大量资源来构建自定义的基础设施，因为这些优化措施能够带来显著的成本节约或用户体验的提升。
同样地，在受到严格监管的环境中工作的团队，也可能需要对数据的存储地点、审计要求以及安全边界进行严格控制。在某些情况下，合规性规定或内部风险管控政策会限制第三方平台的使用，这时自行管理基础设施就成为了唯一可行的选择。
还有一类企业，对于它们来说，基础设施本身就是其产品的重要组成部分。云计算服务提供商、开发平台公司以及数据基础设施供应商就是典型的例子。对于这些企业而言，建设和运营基础设施并不是什么次要任务，而是它们的核心业务所在。
最终，那些拥有成熟平台工程团队的组织，当他们能够将复杂性从应用程序开发人员的工作中剥离出来时，就能够为拥有基础设施这一投入找到合理的理由。在这种架构下，内部平台的功能与PaaS类似，但会根据该组织的具体需求进行定制。
所有这些情况背后的共同点都是规模、专业化或战略必要性。只有当基础设施的运用能够带来明显的竞争优势，或者能够帮助解决其他方式无法解决的约束问题时，管理基础设施才是有意义的。
但对于大多数中小型团队来说，这些条件都并不适用。他们构建的基础设施并不能使他们的产品具备区别于竞争对手的优势，同时仍然要承担所有的运营负担。
PaaS作为替代方案的崛起
平台即服务这一模式彻底改变了传统的开发方式。团队不再需要直接管理基础设施，而是将应用程序部署到一个能够处理所有底层复杂性的平台上。
使用PaaS后，诸如资源配置、扩展性管理、负载均衡以及补丁应用之类的工作都被抽象掉了。工程师们可以将精力集中在代码和配置上，而无需关注服务器和网络细节。
这并不意味着所有的运营工作都消失了，只是责任发生了转移——平台提供商会承担这些繁重的任务。你的团队因此能够使用标准化且经过充分测试的基础设施，而无需自己负责构建和维护它。
PaaS还能减轻开发人员的认知负担。开发者可以通过更加简洁的界面进行操作，部署过程也变得更加可预测，而且系统通常还具备良好的监控功能。这一切都使得团队能够更快地推进工作，并且更有信心地完成各项任务。
更重要的是，PaaS能够使基础设施更好地满足应用程序的实际需求。团队不需要先设计基础设施然后再将应用程序适配到其中，而是可以直接定义自己的应用需要什么，平台会据此提供相应的支持。
Heroku是第一个将PaaS推广到主流市场的公司。由于Heroku即将停止服务，我转而使用了Sevalla，因为它更加简单易用，而且新功能的更新速度也非常快，尤其是那些辅助开发工具。以下是一些替代方案列表。
速度就是竞争优势
在大多数市场中，速度都是至关重要的。能够快速推出新功能、及时响应用户反馈并不断优化产品设计，这些都是非常重要的竞争优势。
然而，基础设施的管理往往会拖慢这一进程。任何变更都需要协调处理，部署操作也存在风险，而调试问题也会占用大量的开发时间。
通过减轻基础设施方面的负担，PaaS使得应用程序的交付速度得到了显著提升。团队可以更频繁地进行功能更新，也可以大胆尝试新的开发思路，而无需担心底层系统的稳定性问题。此外，遇到故障时，他们也能更快地恢复运行。<这不仅仅关乎工程效率的问题，它还会对业务成果产生直接影响。更快的交货速度意味着能够生产出更好的产品，让客户更加满意，从而帮助企业在市场竞争中占据更有优势的位置。
成本其实比云服务费用更高
当团队评估基础设施策略时，他们通常会关注直接成本，例如云服务费用、预留实例以及资源使用情况等，并对这些方面进行优化。
然而，基础设施所隐藏的代价往往属于间接成本。这些成本包括维护工作所占用的工程时间、功能延迟所带来的机会损失，以及系统故障和安全事件带来的风险。
这类成本较难量化，但它们通常比直接成本要高得多。一次系统故障可能会耗费数天的工程开发时间，功能延迟可能会影响收入，而安全漏洞则可能损害企业的声誉。
从表面上看，PaaS似乎更加昂贵，但实际上，当把这些隐藏的成本因素考虑进去后，它往往能降低总体成本。因为它将支出从运营维护方面转移到了产品开发上。
重新审视所有权问题
关键问题并不在于工具或技术本身，而在于所有权的问题——你的团队应该拥有哪些资源，又应该将哪些职责委托给他人呢？
你的产品才是你的核心资产，它是你在市场竞争中的核心竞争力。虽然基础设施非常重要，但它仅仅是一种支持产品的手段而已。
如果继续由团队自己管理基础设施，他们就会承担一些与自身目标并无直接关系的责任，从而付出时间、精力以及风险这些“隐藏的代价”。
PaaS为重新平衡这些关系提供了途径。它使团队能够将基础设施相关的管理工作委托给他人，从而专注于创造价值。
这种转变并不总是一帆风顺的，它需要改变思维模式、使用工具以及优化工作流程。但对于许多团队来说，这确实是一个必要的步骤。
因为基础设施的真实成本，并不是你支付给云服务提供商的费用，而是如果你自己来运营这些基础设施所需付出的各种代价。
订阅我的 应用人工智能资讯通讯，了解如何构建和部署真正的人工智能系统。其中会包含实际项目案例、可直接投入生产的代码，以及问答环节。你也可以 在 LinkedIn上与我联系。