亚马逊是这种模式的极端例子：向后兼容所有事情。每个团队全副武装后前进。一切完全独立，没有团队可以预测其他团队的情况。它使得AWS的产品成为可能。然而，它带来了大量的技术开销，以及不那么亲和的工作文化。
谷歌走向另一个极端。他们的monorepo允许更多团队之间的耦合，库是共享的。他们通过极度的工具化来弥补——测试，重构工具，自定义版本控制和构建系统，甚至整个编程语言。成千上万的工程师在为谷歌的基础设施工作，所以他们通过技术开销来实现并头前进。
平凡如我们，平衡一下吧
对于谷歌亚马逊之外的我们来说，公司里有7-1000个工程师，不能过于极端化。我们不禁要问：哪里的一致性比较重要?哪里的一致性会阻碍我们前进?
目标和方向上的一致性是非常重要的。我们建立了相同的业务，所追求的业务结果最好也是相同的。
一致性在后端可能会造成严重后果。当需要协调发布时，当不能在无法预测是否影响其他团队的前提下升级库时，当数据库变化可能打破一个系统关键性生产时——这些都可能会导致系统瘫痪。所以不要让团队彼此共享数据库或者库。
利用共享的工具和专业知识呢?如果每个团队运行自己的数据库，这些箭头会迅速变宽，除非他们克扣了检测和冗余——然而这样会导致系统非常脆弱。我们并不想在系统挂掉后重构一切。
答案是宽箭头和高箭头兼而有之。当它们在内部服务时，共享的工具非常棒。让数据管道服务合作伙伴以及向团队汇报。让数据库团队为其他团队提供支持良好的数据库实例。(它们仍然是单独的数据库，但是现在我们有共享的工具来与之合作，数据管道让彼此同步。)
绿色、红色和蓝色箭头窄而高，几乎全部填满工作，一些线将它们彼此连接。紫色和一个新的黑色箭头宽且短，工作充分。宽箭头(内部服务)巧妙地与高箭头(产品团队)进行沟通。
敲黑板，总结
避免共享代码库，除非你像谷歌那样有完美的测试覆盖率，或者像亚马逊那样有一整个团队负责支持向后兼容的库。
避免共享数据库实例，但是要建立内部团队支持常见的数据库工具。
鼓励分享想法，在一个组织内人们随机的交流拥有巨大的潜力。弄明白其他团队在做什么，可以完善自己的方向以及提升开发速度。
在目标结果、为什么做以及如何做上达成一致。在同一个方向上，独立地前进。
每一个组织都是一个分布式的系统，哪怕我们彼此就坐在旁边。协调使得共同工作成为可能，却不是全无代价。在你的组织成长过程中注意权衡，因为一致性越来越无用，也越来越花费巨大。新人的加入需要更多的协调成本。让团队按照他们各自的方式前进，只要在一个大方向上是一致的就可以。
分布式系统很难，然而我们可以做到。
作者：Jessitron 文章来自： http://blog.jessitron.com