需求：每家公司都在變成數位公司#

• 無論起源為何，每家公司都正在變成數位公司。這場轉型要求交付 API 與服務，供行動應用、物聯網（IoT）裝置，甚至自駕車輛與自主系統消費。
• 這些系統的關鍵性（criticality）持續升高，意味著線上系統必須為冗餘、容錯與高可用而建；同時商業需求又要求高度敏捷——快速開發並推出新軟體、迭代既有應用、實驗新的使用者介面與 API。
• 這些要求匯流的結果，是待建構的分散式系統數量增加了一個數量級。

但建構這些系統的難度依然過高：開發、更新與維護一套分散式系統的整體成本太昂貴；而具備相應能力與技能的人，數量又遠遠不足以應付持續成長的需求。

歷史：每一次抽象層的躍進，都擴大了開發者的圈子#

• 軟體與科技發展史上，每當這種局面出現，就會有新的抽象層與軟體開發模式應運而生，讓建構軟體更快、更容易、也更可靠。
• 這件事首先發生在編譯器與程式語言誕生時，後來又發生在物件導向程式語言與受控程式碼（managed code）出現時。
• 每一個這樣的時刻，技術發展都把專家的知識與實務結晶成一系列演算法與模式，讓範圍大得多的實務工作者得以套用。

當下：又一次轉型的時刻#

• 我們再度站在技術轉型的關口：對分散式系統的需求，遠遠超過我們交付的能力。
• 所幸技術發展又給出了另一套工具——容器與容器編排——讓分散式系統的開發變得更快、更容易。
• 這些工具若能與本書描述的模式與實踐結合，期望能同時做到兩件事：提升現有開發者所建系統的品質，以及——更重要的——培養出一整批全新的、有能力建構這類系統的開發者。

展望：不要再從零開始#

Sidecar（邊車）、Ambassador（大使）、分片服務、FaaS、工作佇列等模式，可以成為現代分散式系統賴以建立的地基。

分散式系統開發者不該再各自從零打造系統，而應共同協作於那些構成我們集體部署之系統基礎的經典模式的可重用共享實作。

唯有如此，我們才能滿足今日對可靠、可擴展 API 與服務的需求，並為未來一整批新的應用與服務賦能。