我发现自己在亚历克斯·拉塞尔（Alex Russell）的帖子《柠檬市场》中不断点头：
复杂性商人知道他们的环境并不典型，但他们销售高度专业化的工具，就好像它们通常是合适的一样。他们明白，大多数网站缺乏严格的延迟预算、专门的性能团队、鹰派的管理审查、防止回归的船门以及关键用户旅程的端到端测量。他们明白扩展 JS 驱动前端的唯一方法是在控制复杂性方面进行大量投资，但没有警告任何客户。
他谈论的是 JavaScript 框架以及它们在生成高性能 Web 前端方面的失败。但令人惊讶的是，其中有多少也适用于后端世界。用微服务替换 SPA，用 Kubernetes 替换 React，您也几乎解决了该领域的问题。
我愿意相信我们陷入的陷阱并不完全是这些供应商的错。我可以想象这样一个场景：一些开发人员对 React 感到好奇，将其用于小型项目，认为这是最好的选择，并开始与其他人分享。这项技术足够复杂，既可用又有趣，而且有足够的血统，很容易说服其他人采用它（“Facebook 和谷歌使用这项技术，他们是为世界一半人口服务的亿万富翁。为什么要怀疑技术他们？”）
最终它得到了主流采用，尽管存在问题，但由于两个特征，它成为任何新事物的默认选择。首先是与学习这些框架相关的沉没成本，并证明与它们战斗所带来的战斗伤痕是合理的。
二是害怕返工。我怀疑大多数组织忘记了许多大型科技公司都是从有效的 LAMP 堆栈开始的。由于用户需求，他们必须用现有的产品替换它，而且这个决定很容易，因为他们每秒收到的数百万个请求给他们的软件带来了压力。
我怀疑今天的组织觉得有必要跳过简单的技术堆栈，直接转向可以为数十亿用户服务的东西，只是为了避免未来需要重写应用程序。当然，由单个 Web 服务器和 PostgreSQL 数据库处理的服务器端渲染网页现在足以为这 100 个 DAU 提供服务，但有一天可能会增长到 30 亿用户，我们现在需要为这种可能性做好准备（即使它没有实现）。
所以我完全理解我们现在所处的困境。但这并不能解释为什么这些供应商首先不遗余力地推广这项技术。他们为什么不坦率地说明他们为了有效利用这项技术而进行的巨额投资呢？为什么不透露他们为什么要花这么大的力气，而不是吹捧“DOM 很慢”或“亚马逊使用微服务”之类的属性？
我很想知道，但也许稍后。我首先要处理一些 Kubernetes pod。