共享类库是整个服务运行过程中最需要的部分；另一方面，这些类库总的来说也可以被认为是“一种平台”。包括像Spring、Guava和那些通常被用在路由消息和日志记录里的类库。在最后，一个系统的性能优劣取决于是否具备100+类库的组合。如果一个服务不能和系统进行互动的话，只能说明这些类库的可用性有问题，Christensen称这种情况为分布式单体架构。
本质上来讲，你所做的那些将成本花在分布式系统上的事情，其实只是在网络上推广单体架构，但是并没有从微服务架构里面获得任何好处。至于丢失的这些好处就包括多语言特点，也就意味着你所开发的这个服务错过了利用最好的技术来解决特殊问题的可能性，包含组织上和技术解藕方面的问题。解决处理了这些问题有助于团队进行技术升级，而不需要在第一时间去获得授权。
不妨在这里简单介绍一下单体架构应用（Monolith），网上对微服务进行介绍的文章常常以单体架构开始。这里也不例外，只有在知道了单体架构的不便之后才能更容易地理解微服务架构模式所具备的各种优点。
开发出来的服务应该是什么样子呢？通常情况下，这个服务所对应的代码是由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时，这些项目会被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。
接下来，开发者需要将该WAR包上传到Web容器中进行解压，并重新启动服务器。在执行完这一系列操作之后，对服务的编译及部署流程也就完成了。如果按照单体架构组织的代码来运行的话，会生成一个包含了所有功能的WAR包，因此在对服务的容量进行扩展的时候，我们只能选择重复部署这些WAR包来扩展服务能力，而不是仅仅扩展系统瓶颈的组成。
但是这种扩展方式极大地浪费了资源。比如（上图）：在一个服务中，某个组成的负载已经达到了90%，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20%。
由于单体架构服务中的各个组成是打包在同一个WAR包中的，因此通过添加一个额外的服务实例，可以将需要扩容的负载降低到45%，但是也使得其它各组成的利用率更为低下。可以说，所有的不便都是由于单体架构服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是微服务架构模式。
Don’t Repeat Yourself的字母缩写DRY对很多人来说都不陌生，意即不要重复造轮子。在共享代码的业务逻辑中，孤立的去部署变化条件的方式正在被摒弃，因为这种做法会直接影响服务执行代码的效果。Christensen强调共享代码在服务边界里面是相当完美的，可是一旦泄漏的话，就会有潜在的耦合可能性。Sam Newman在他的新书《Building Microservices》里提到：
The evils of too much coupling between services are far worse than the problems caused by code duplication。
服务之间太多的耦合所带来的弊端，远比简简单单复制代码所带来的问题还要严重很多倍。
Christensen认为可替代的解决方案就是采用稳定的协议，隐藏所有的实现细节，只将数据契约和网络协议暴露出来，在不依赖服务实现的前提下，用户都能够使用任何技术和编程语言，这才是网络该做的事情。Christensen还指出，虽然在如日志记录、分布式跟踪、路由等领域没有强制的标准化需求，但还是应该启用独立的类库，这样用户才有权选择是否使用这些网络服务。
Christensen认为，这样的低级错误是很容易经常性犯的，因为我们都知道如何使用共享类库，我们也常常在短期内进行优化来达到更高效率。他还说，虽然推迟解藕的成本较高，可是解决方案也是有的，努力在刚开始的时候就把合适的工具用在合适的地方，物尽所用才能发挥最大效果。
在最后的问答过程中他提到，使用一个大的框架无可厚非，只要这个框架被当作内部一个独立的服务使用就行，但如果整个系统的架构不采用这个大的框架也并无大碍，因为这会避免出现长期耦合。微架构或者SOA架构真正发挥所长的地方在于，根据彼此独立部署的逻辑服务，这些逻辑服务可以独立于其他服务进行扩展，而且能够实现独立的故障切换。
红帽公司中间件部门工程副总裁Mark Little博士也曾说过：“我在微服务架构方面担心的问题之一就是，你有一个整体式单体架构应用，假设你随意把它分解成多个服务，到头来就会分解得过细，最后会有10个、100个甚至1000个微服务。但是这些微服务又彼此高度依赖，以至于如果某一个服务出现故障，其余服务很有可能也会出现故障。这种情况下，你将一无所获。你有999个服务就在那里干等着另一个服务恢复正常运行之后才能工作。”
