产生这个讨论的动力是好的软件架构能带来敏捷。尽管面向服务的架构（SOA5 ）因为过于复杂、臃肿和粗糙的实现而被一些组织看作肮脏的词汇，但软件系统由小型微服务6 构成仍呈一种增长趋势，每个服务只专注做好一件事。一个微服务通常可能不到100行代码。如果需要改变，服务可以用另一种语言重新编写。这种架构风格以多种方式提供了敏捷。小型、松耦合的组件和服务可以孤立地构建、修改和测试，甚至根据需求变化移除和替换。因为能够加入新组件、服务并在需要时扩展，这种架构风格也很适合非常灵活和可适配的部署模型。
5 Service-Oriented Architecture,http://en.wikipedia.org/wiki/Service-oriented_architecture 。——译者注
6 http://www.infoq.com/presentations/Micro-Services
然而，天上不会掉馅饼。构建一个这样的软件系统需要时间、精力和准则。很多人也不需要这种水平的适应性和敏捷性，这就是为什么你看到那么多团队构建的软件系统实际上整体感强得多，各部分捆绑在一起并以单一单元部署。尽管更易于构建，然而这种架构风格在面对变化的需求时通常要花费更多精力去适配，因为功能往往交织在代码库中。
不同的软件架构提供不同层次的敏捷
在我看来，两种架构风格各有优缺点，应该在权衡利弊之后，再决定是构架一个整体系统还是几个微系统。和IT行业中所有的事情一样，在这两者之间也有中间地带。抱着实用主义的想法，你总能选择构建一个由很多定义好的小组件构成，但仍作为单一单元部署的软件系统。这也让你有可能在将来轻松地迁移到微服务架构。