关于亚马逊最被误解的教训是初创公司应该构建自己的云。这种结论现在回想起来似乎很聪明，但却完全忽略了背景。亚马逊之所以建造基础设施，并不是因为它是一家以此为使命的科技公司，而是因为其主要业务的规模需要市场尚未提供的解决方案。产品后来出现了。值得学习的不是结果，而是其背后的推理：基础设施决策不断积累，而公司的增长上限往往是由在需要该上限之前很久就做出的选择决定的。
亚马逊真正教的是什么
当亚马逊开始构建其内部计算平台时，问题不在于品牌知名度或产品策略。它是可操作的：在内部推出新服务需要数周时间，因为每个团队都必须从头开始配置服务器。解决方案是标准化和抽象。副作用是，外包后会重新定义整个行业。
焦点不是AWS本身。只是亚马逊建立了运营优势来解决实际问题，并且这种优势变得有市场，因为它确实优于市场上现有的产品。试图复制这条道路而不解决原始问题的公司往往会以无回报的开销而告终——为了基础设施而基础设施，这与本课程应该教授的内容相反。
随着时间的推移累积的决定
软件架构具有长记忆性。当用户数达到 100 万时，选择 10 个用户可能会产生足够的摩擦，导致迁移变得不可行。并不是因为当时的选择是错误的——考虑到上下文，它通常是最合理的选择——而是因为依赖关系成倍增加，重写的成本也随之增加。
Google 构建了 Bigtable，因为传统的关系模型无法扩展到网络索引。 Facebook 开发 Haystack 是因为传统文件系统对于数十亿张小照片来说效率低下。在这两种情况下，定制的基础设施都不是从不成熟的战略赌博中产生的；它源于现有基础设施根本无法克服的具体限制。
对于初创公司来说，这意味着观点的转变。问题不是“现在哪种基础设施看起来更强大？”但“今天做出的哪些决定将来要扭转会付出更大的代价？”有些选择很容易替换——[数据库0、云提供商、前端框架。其他人创建的依赖关系多年来遍及整个代码库和操作流程。
战略基础设施与商品的区别是什么
有一个经常被忽视的重要区别：有些基础设施是任何提供商都可以同等提供的，而有些基础设施的具体实施可以创造真正的优势。混淆这两个类别是一个代价高昂的错误，无论是低估第二个类别还是高估第一个类别。
身份验证、事务性电子邮件发送、基本监控、CI/CD 管道：这些都是商品。价值在于让它们可靠地工作，而不是从头开始构建它们。这些领域的工程支出通常是伪装成技术严谨性的机会成本。
现在，提供推荐的数据管道、针对特定用户行为进行调整的搜索引擎、在竞争对手停滞不前的情况下提供流畅体验的延迟架构——这些都是内部构建的候选者。不是因为它更便宜，而是因为通用市场解决方案往往代表了公司无法接受的质量上限。
在您需要之前投资哪里
最有用的规则是在拥有专有数据的内部构建，并且结果的质量直接由实施的质量决定。在这些领域，市场解决方案和精心设计的内部解决方案之间的差异转化为业务指标——转化率、保留率、每用户收入。
建立自己的风险模型而不是使用第三方评分的金融科技初创公司不仅节省了 API 成本，还积累了第三方供应商无法复制的有关其特定客户组合的专有知识。在需要全球规模之前投资视频分发基础设施的内容平台正在争取时间：当需求到来时，学习曲线已经被覆盖。
时机和决定本身一样重要。如果您还没有足够的数量来验证需求，那么尽早投资于基础设施是一个不成熟的选择。后期投资是增长的成本，因为迁移会中断产品并需要数月的重写。目标是在瓶颈出现之前确定瓶颈将出现在哪里——这需要诚实地了解业务的哪一部分真正与众不同。
基础设施作为内部产品
大型科技公司做得很好但初创公司很少考虑的事情之一就是将内部基础设施视为产品。这意味着拥有专门的团队、采用指标、路线图，最重要的是，拥有明确期望的内部用户。
内部工程平台的概念超越了 DevOps，涵盖了其他团队使用的整个工具、抽象和服务层，其存在正是为了解决组织规模问题。当一家公司有二十名工程师时，基础设施可以通过非正式的约定来解决。有了 200 个，缺乏明确定义的抽象层就成为了瓶颈：团队重复解决方案、标准出现分歧、入职变得昂贵。
早期投资这一层的决定所带来的回报在短期内很难衡量，但当公司试图在十八个月内将规模扩大一倍时，回报就会明显显现出来。不进行这项投资的代价是开发速度、产品质量，通常还包括工程周转率。
另请阅读
- [负载测试和业务模型：如何在扩展之前评估容量1
- [初创公司申请-日常清单2
- [面向初创公司的应用程序：扩展之前真正重要的清单3
- [应用程序的云计算：当您的产品驻留在云端时会发生什么变化4
- [如何扩展应用程序：每日比较5
- [人工智能能源危机：数据中心消耗对基础设施决策者意味着什么6