每一个生产工程团队都熟悉这种模式：一个新项目的开始总是充满活力，产品目标明确，截止日期也相当紧迫，团队自然希望尽快完成工作，交付出客户能够使用的成果。
然而，真正的麻烦才刚刚开始。基础设施必须进行配置，CI/CD流程也需要搭建，敏感信息需要妥善管理，监控系统需要安装，数据库需要部署，日志记录功能需要配置，安全策略需要落实，网络规则也需要重新审查。
往往要花费数周时间，用户才能看到任何有用的成果。许多组织将这种情况视为正常现象，他们称之为“工程工作的严谨性”，并认为这个操作准备阶段只是软件开发流程中的一部分而已。
但实际上并非如此。
对于那些已经在运行生产系统的团队来说，每个新项目都要重新搭建基础设施，这种做法纯粹是浪费资源。这本质上是一种重复性的操作工作，却被包装成了一种工程学科。
真正值得思考的问题不是“如何加快这一准备流程的速度”，而是“为什么我们还要自己去做这些事情呢？”
这时，平台即服务模式就能改变这种思考方式。一个优秀的PaaS平台会将工作的起点从“重新搭建基础设施”转变为“立即开始交付产品”。因为新项目的开展应该更贴近客户的实际需求，而不是先从基础设施建设入手。
在本文中，我们将探讨为什么许多生产团队会浪费时间为每个新项目重复搭建相同的基础设施，PaaS如何帮助消除这种浪费，以及对于大多数项目来说，是否还有必要继续花费精力去管理复杂的基础设施。
我们将会讨论的内容：
大多数团队并非被聘用来负责基础设施建设工作的
软件团队的存在目的是为了解决业务问题。客户并不关心Kubernetes配置文件的结构是否优雅，也不欣赏那些设计精良的Terraform模块，更不会对精心编写的网络配置规则表示赞赏。
客户关心的是实际成果：更快的系统上线速度、更准确的推荐方案、更顺畅的支付流程、更少的错误以及更简单的工作流程。
然而，许多工程团队却花费了大量时间去完成那些客户根本看不到的工作。
这些团队反复创建部署管道、配置开发环境、管理证书、搭建监控系统，并调整各种基础设施设置。
基础设施确实很重要，可靠性与安全性同样重要。
问题在于重复劳动。如果每个项目都独立地构建相同的操作系统，那么这些组织就会不断重复建设内部基础设施，却从不承认这一点。
这种做法已经变得如此普遍，以至于各个团队几乎都没有意识到它的存在。但反复重建同样的基础设施，并不能体现任何运营上的成熟度，反而只会导致整个组织的效率低下。
AWS提供的基础设施组件并不能带来竞争优势
许多团队将拥有云服务视为一种战略优势。但实际上，拥有Kubernetes集群并不会带来差异化的竞争力，管理IAM规则也无法为客户创造价值，编写基础设施相关的代码更无法增强市场地位。
这些都属于实施细节，然而许多组织却投入了大量精力去管理它们，仿佛它们是企业的核心资产一样。
有些团队在不知不觉中，实际上已经变成了半专业的基础设施维护机构。他们的工程师们逐渐承担了越来越多的运营职责，最终维护系统所花费的时间反而超过了开发新产品所需的时间。
这种发展模式的结果往往是可预见的：基础设施规模不断扩大，运营复杂性不断增加，交付速度却不断下降。由于这些变化是逐渐发生的，因此没有人会真正注意到这些问题。
一个团队最初可能只使用一个Kubernetes集群，随后又建立了另一个开发环境，更多的部署管道被添加进来，各种工具也被陆续引入，日志记录系统也变得杂乱无章，不同产品的监控机制也各不相同。
最终，这些团队会花费越来越多的时间去维护那些他们原本并不打算拥有的基础设施。
大多数团队不应该负责管理Kubernetes
Kubernetes已经成了一种工程文化。它出现在各种架构图、会议演讲中，也被列在招聘要求里和内部发展计划中。人们往往觉得采用Kubernetes是不可避免的。
但“规范化”与“必要性”并非同一概念。许多组织选择采用Kubernetes，只是因为行业趋势使得它看起来成了理所当然的选择，并非因为他们的业务需求确实需要这种复杂的架构。然而，这样的结果其实是可以预见的。
中小型团队最终却不得不去维护那些为大规模运营环境设计的运维系统。
他们需要维护YAML配置文件、网络设置、部署策略以及各种运维工具，才能最终实现产品的实际价值。而这种做法竟然被人们视为理所当然。
PaaS改变了起点
传统的基础设施建设方式迫使团队从底层开始进行设计：首先考虑服务器，然后是操作系统、网络架构、部署系统，最后才是监控机制。应用程序的开发则放在这些步骤之后。
PaaS颠覆了这一顺序。开发者首先关注应用程序和业务目标，而平台会负责处理所有的运维复杂性。
团队不再问“我们该如何配置资源？”而是开始思考“我们要解决什么问题？”。这看起来只是一个小小的变化，但实际上它彻底改变了整个开发流程。
项目从产品开发阶段就开始启动，而非从基础设施建设阶段开始，这种做法大大缩短了产品上市的时间。
重复性工作会滋生隐藏的组织浪费
重复利用被视为基本的工程原则。基础设施不应得到特殊对待——一次构建，多次使用。
PaaS其实就是将软件工程的原则应用于操作系统之中。
标准化通常比灵活性更有效
工程团队往往抗拒标准化，因为他们担心会失去控制力。每个项目看起来都是独一无二的，每个系统也似乎都有所不同，因此人们认为追求灵活性是合理的。
但过度的灵活性往往会引发运营混乱：不同的团队会以不同的方式部署应用程序，日志记录的结果不一致，各个系统的监控机制也不相同，安全措施的实现标准也会出现差异。
文档会变得零散不堪，新员工的培训进度会变慢，事故响应的难度也会增加，系统的复杂性还会逐渐累积。
PaaS虽然会带来一些限制，但许多工程师会本能地抗拒这些限制。其实，有用的限制往往能提高工作效率。
可预测的部署模式能够减少混乱，统一的监控标准有助于更快地排查故障，一致的环境也能降低认知负担。
开发人员不必再花费精力去了解不同基础设施之间的差异，而是可以把更多时间用于实现产品功能。
这种一致性会带来显著的效益。
平台团队能产生倍增效应
许多组织将PaaS理解为购买某个供应商的产品，但它们忽略了其真正的意义。
PaaS的本质在于创建可重复使用的功能模块。有些组织会购买现成的平台，而另一些则会自行构建内部平台，但原理都是一样的。
一个平台团队只需构建一次系统，之后其他所有人都能从中受益。这样一来，就不需要几十个产品团队各自独立地解决运营问题了，而是有一个专门的团队来集中专业知识，开发出可重复使用的解决方案。
这种模式带来的效果是非常显著的：一次部署上的改进会加速后续所有版本的发布，一次监控机制的优化会提升所有应用程序的性能，一次安全措施的加强也会保护到每一个团队。
平台团队能够为整个组织带来巨大的价值。如果没有这种模式，专业知识就会分散且难以得到有效利用；而有了它，这些知识就能得到整合和放大。
更便捷的启动流程能激发更多创新
运营中的各种障碍会影响人们的行为。当开展新项目变得成本高昂时，组织就会变得谨慎起来，团队也会避免进行实验，一些小想法似乎就变得风险太大，原型开发的必要性也会降低。
长此以往，创新的速度就会放缓。这并不是因为组织缺乏创意，而是因为启动新项目的成本太高了。
那些使用成熟平台的团队很清楚这种关系：减少启动过程中的障碍会鼓励更多的实验，小型项目也就更容易得以实施，学习周期也会缩短。
由于测试这些新想法的成本大幅降低，新的创意就会更加频繁地出现。当开展某项工作的难度降低时，组织就能创造出更多的机会。
PaaS降低了创业过程中的种种障碍，而这种改变也会影响企业的文化氛围。
在哪些情况下专门化的控制措施才是真正必要的
当然也存在例外情况。对于那些处理海量数据的大型平台、高度专业化的机器学习系统，以及那些需要根据特定需求进行定制的环境来说，可能确实需要拥有对底层基础设施的直接控制权。
有些工作负载确实需要更深入的运营管控能力，但这类情况属于例外，并非普遍现象。太多团队将原本为极端情况而设计的复杂基础设施架构视为标准操作流程，从而沿用了这些做法。
实际上，大多数生产环境中的应用程序并不需要定制化的编排层，大多数团队也不必拥有Kubernetes这样的平台，更没有哪个工程团队需要在发布软件之前花费数周时间来搭建基础设施。
因此，我们应该把“不需要进行这些复杂操作”作为默认假设。
从零开始其实是一种失败的行为
许多组织已经将那些不必要的运营障碍视为正常现象：漫长的配置流程被人们接受，基础设施的重复建设成了常态，云技术的复杂性也被视为理所当然。
最终，这些团队会停止质疑这种现状，认为工程开发就是应该这样进行的。但事实并非如此。
如果发布一款新应用之前需要花费数周时间来进行基础环境的搭建，那么这样的开发方式根本不符合工程学科的规范。
我们的目标从来都不是成为一家专注于基础设施建设的公司，而是尽快发布软件产品。