概念
微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務是需要與業務能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設計是錯誤的，那么，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發現，其中的指導建議是非常實用的。在決定將所有組件組合到一起時，開發人員需要非常確信這些組件都會有所改變，並且規模也會發生變化。服務粒度越粗，就越難以符合規定原則。服務粒度越細，就越能夠靈活地降低變化和負載所帶來的影響。然而，利弊之間的權衡過程是非常複雜的，我們要在配置和資金模型的基礎上考慮到基礎設施的成本問題。
現狀
微服務作為一項在雲中部署套用和服務的新技術已成為當下最新的熱門話題。但大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。
企業和服務提供商正在尋找更好的方法將應用程式部署在雲環境中，微服務被認為是未來的方向。通過將套用和服務分解成更小的、鬆散耦合的組件，它們可以更加容易升級和擴展，理論上是這樣。
特點
微服務的基本思想在於考慮圍繞著業務領域組件來創建套用，這些就套用可獨立地進行開發、管理和加速。在分散的組件中使用微服務雲架構和平台使部署、管理和服務功能交付變得更加簡單。
微服務是利用組織的服務投資組合，然後基於業務領域功能分解它們，在看到服務投資組合之前，它還是一個業務領域。
微服務這一概念出現於2012年，是因軟體作者Martin Fowler而流行，他承認這並沒有精確地定義出這一架構形式，雖然圍繞業務能力、自動化部署、終端智慧型以及語言和數據的分散控制有一些常見的特性。
服務平台
開源工作流平台 “Imixs-Workflow“發布了一款新的微服務架構，作為工作流來管理解決方案。Imixs的微服務（ Imixs-Microservice）提供了一個工作流封裝成微服務架構。這一服務可以獨立於其背後的技術，綁定的任何業務套用中去。這允許業務套用改變業務邏輯的時，不用更改任何代碼。這業務目標可以通過工作流模型控制。
Imixs的微服務是基於Imixs的工作流引擎（ Imixs-Workflow Engine）的複雜功能構建的，它可以以多種不同的方法來控制業務數據。Imixs的微服務可以傳送電子郵件推送訊息、日誌業務交換，還可以確保所有類型業務數據的安全。
Imixs的工作流模型可以給業務處理模型（Imixs-Workflow Modeller）中的每琴單獨狀態設計一個ACL。這許可了高度複雜的業務應用程式，並在每個流程實例周圍駐起了安全層。
開發工具
Seneca是構建微服務框架的工具，然後把它們構建到測試和部署的devops工作流中。構建和部署基於服務的應用程式都很好，但卻無法維護，這一點很折磨人。還要在服務周圍實現一些 持續交付模型的形式，然後使用它來管理並發布更新——這是一個比編寫代碼理棘手的問題。
使用微服務構建現代化應用程式是很有意義的，因為它讓你既利用了擴展橫向擴展架構，也利用縱向擴展架構；還額外得到API的組合，且在整個業務中可重複利用。可能，每一分鐘構都在交付新服務，這樣你就必須擁有一個敏捷的且回響的應用程式平台，這一平台一直在不斷改進中。
