在我们在世界上拥有的大多数应用程序中，也许90%的应用程序都是由一种整体的方法完美地服务的；因此，为了避免过度工程，我们应该从一个简单的体系结构开始，并随着需求的出现而对其进行进化，兰迪·舒普在2018年的反应性首脑会议上宣布。在他最近发表的演讲中，他描述了他与公司的经历，这些公司一开始很小，然后成长为大型全球互联网公司，他们的架构在那段时间是如何演变的，以及他在创办新公司或新产品时从IT角度提出的建议。

舒普，有在eBay、谷歌和Stitch Fix工作的经验，目前是We Work的工程副总裁。他的第一个例子是eBay，它于1995年开始作为一个为期三天的周末项目，不是作为一个企业的概念（PoC）的证明，而是看看是否有可能在网上做一些有趣的事情。今天，它第五次完全改写了基础设施，并将该公司描述为一套多语言的微服务，并补充说Twitter和亚马逊都经历了类似的演变。

从某种形式的单一服务开始，最后以一套微服务结束，这是大公司的一种常见模式，并注意到这种模式有两个部分-没有人从微服务开始，在一定规模以上，每个人都以微服务结束。

提到的公司都很大，Shoup指出，在其规模上工作的架构对大多数公司来说是完全不合适的。大多数应用程序都是通过一种单一的方法来完美地服务的，而Shoup在构建新的应用程序或系统时的建议是开始简单，并根据需要进化体系结构。他喜欢这样说：

对于Shoup来说，大多数公司和产品的共同进展曲线包括一个想法和开始阶段，一个分布式系统可能相关的缩放阶段，以及通常的优化阶段：

在想法阶段，Shoup声称我们根本不应该有任何花哨的架构-我们只是原型。为了避免过度设计，我们应该不断地问自己：“我们试图解决什么问题？”这一阶段的目标是尽快探索解决方案空间，并以最低成本：

如果可能的话，他建议我们尽量远离所有技术，例如使用谷歌广告查看是否有点击，或者使用纸质原型或Excel电子表格。

当进入启动阶段时，目标是满足近期客户的需求，并尽可能便宜地这样做。通常在这个阶段只有一个团队，由4-6人组成.他们的工作时间很短，也许3-4个月.这方面的一个论据是，在构建什么样的特性方面，往往很难看到遥遥领先。我们只需要一个最小数量的架构，足以让我们前进。舒普强调，它仍然不是关于缩放；我们应该使用简单和熟悉的技术，并且肯定是一个整体体系结构-一个应用程序和一个数据库。基础设施应该是最小的，而不是自己建造的。相反，他建议使用平台作为服务（PaaS）或类似的技术。

在这一点上使用整体结构的优点包括：

除了缺乏扩展和单一的故障点，单片的一个主要缺点是模块化的执行不好。这是可行的，但它需要编程和团队纪律。但舒普指出，在这一阶段，这些都不值得关注。尽管如此，当我们看到需要准备缩放时，他认为通过在单片中使用组件或模块来遵守模块化纪律是值得的。这将简化今后的修改或替换为外部服务。

看看什么时候我们可能需要重新组装这块巨石，Shoup经历了一些警告指标：

当我们进入扩展阶段时，目标是保持领先于快速增长的业务，并保持我们的应用程序正常运行。在组织背景下，我们现在通常会增加团队的数量，并在更长的时间范围内工作。通常还需要引入可重复的过程。

在技术背景下，扩展阶段通常意味着转向规模化的技术。通常，我们现在开始将服务从单片机中分离出来，尝试减少单个数据库上的负载是非常常见的，例如通过创建某些数据的只读副本。这也是常见的，从分离特殊服务开始，如支付和计费，并引入事件队列或消息总线。

对于Shoup来说，这通常也是考虑是否应该将我们的整体迁移到小型独立组件中的时候，我们今天称之为微服务。我们还必须考虑使用的单个主存储是否仍然是存储数据的正确方法。在QCon纽约2017Shoup展示了如何将单片应用程序增量迁移到微服务和几个不同领域的独立存储机制。

在《可伸缩性的艺术》一书中，描述了一个三维可伸缩性模型（AKF ScaleCube），其中三个轴代表不同类型的缩放：

最后一步是优化阶段，舒普强调，如果达到，这是一个成功的标志。目标是保持一组功能，但无用的资源，也许更少的团队。我们也有一个更长的时间范围，也许2-5年。