微服務（Microservices）是現時企業開發應用程式的新方法。到底微服務有甚麼特點？CA Technologies API Academy 的 API Architecture 主席 Mike Amundsen 早前便來港分享了微服務的議題。
速度、安全乃微服務主要好處
微服務把大型單一（monolithic）的應用程式分拆為低耦合度（loosely coupled）的功能，並以 API 來互相存取。隨著 Agile 和 DevOps 的概念興起，微服務亦日漸流行。
各人對微服務有各種定義，Amundsen 則稱之為「於受限範內能互相操作、獨立部署的組件（independently deployable component of bounded scope that supports interoperability）」。現時已有不少企業使用，如 Netflix、Amazon、Spotify 等。
他續指，每間企業使用微服務的原因不盡相同。Netflix 透過微服務來把單一的系統分拆並遷移到雲端，加快系統測試和發布；Spotify 卻是應用於團隊中，使他們能更自主地拓展服務。不過總括而言，微服務能促進創新、加快速度、減低成本、避免技術負債（technical debt），「大規模地協調（harmonise），而非平衝（balance）速度和安全」。
微服微著重可替換性
Amundsen 指出微服務對於大型的項目較為理想，而且應以目標為本，如 Netflix 的微服務就以影片沒有緩衝為目標。另外，微服務著重「可替換性（replacability）」，即是開發者不會修改微服務的程式碼，而是整個換掉。這樣服務便可以在短時間內作小規模更新，降低風險。假如服務要在一段時間後推出大規模更新，除了有技術負債的風險之外，程式出現問題的話開發者便要花若干的時間檢查。
他續指，微服務的系統設計應考慮五個因素，即服務、解決方案、過程和工具、組織以及文化，當中後三者是關於「人」。Amundsen 又以 Netlfix 為例闡述人的因素如何影響設計，指他們內部需時 6 個月來批准一個項目遷移到雲端。
Amundsen 又說，設計時應把過程、產出和人劃一化。他補充，這其實是一個取捨，如把「人」劃一化會失去創新的機會，但效率可上升。
他亦告誡出席者，不應為加入一些很「有形」的功能而使系統變得複雜。
開發團隊少人為佳
最後 Amundsen 分享了有關開發團隊和創新的看法。他指出團隊的成員數目愈多，程式的錯誤亦會愈多，因此成員數目應保持少數，除可改善程式亦可促進溝通。Amundsen 更引用 Amazon CEO Jeff Benzos 的「2 Pizza Rules」總結：如果兩塊簿餅不能餵飽團隊成員，即是團隊太大了。
他又指企業應勇於創新，因為只有肯面對風險的企業才會成功；企業失敗的話則是一個學習的機會。Amundsen 引用 Google 作例子，指公司 20% Time 的概念讓員工於空餘時自由創新，從而製作一些未經計劃的創新產品。
