產生這個討論的動力是好的軟件架構能帶來敏捷。儘管面向服務的架構（SOA5 ）因為過於複雜、臃腫和粗糙的實現而被一些組織看作骯髒的詞彙，但軟件系統由小型微服務6 構成仍呈一種增長趨勢，每個服務只專注做好一件事。一個微服務通常可能不到100行代碼。如果需要改變，服務可以用另一種語言重新編寫。這種架構風格以多種方式提供了敏捷。小型、松耦合的組件和服務可以孤立地構建、修改和測試，甚至根據需求變化移除和替換。因為能夠加入新組件、服務並在需要時擴展，這種架構風格也很適合非常靈活和可適配的部署模型。
5 Service-Oriented Architecture,http://en.wikipedia.org/wiki/Service-oriented_architecture 。——譯者注
6 http://www.infoq.com/presentations/Micro-Services
然而，天上不會掉餡餅。構建一個這樣的軟件系統需要時間、精力和準則。很多人也不需要這種水平的適應性和敏捷性，這就是為什麼你看到那麼多團隊構建的軟件系統實際上整體感強得多，各部分捆綁在一起並以單一單元部署。儘管更易於構建，然而這種架構風格在面對變化的需求時通常要花費更多精力去適配，因為功能往往交織在代碼庫中。
不同的軟件架構提供不同層次的敏捷
在我看來，兩種架構風格各有優缺點，應該在權衡利弊之後，再決定是構架一個整體系統還是幾個微系統。和IT行業中所有的事情一樣，在這兩者之間也有中間地帶。抱著實用主義的想法，你總能選擇構建一個由很多定義好的小組件構成，但仍作為單一單元部署的軟件系統。這也讓你有可能在將來輕鬆地遷移到微服務架構。