我們在《DevOps系列一：認識事件驅動型計算》中介紹了事件驅動型計算對現代世界的影響。本文是系列二，對比事件驅動型計算與容器和微服務。
面向群眾的消息隊列
在某種程度上說，舊的東西會變成新的。對于Iron.io和StackStorm公司的產品來說，老式的消息隊列是軟件運行的核心。Iron.io甚至還單獨銷售一款消息隊列產品IronMQ，這個產品能觸發姐妹軟件IronWorker的事件。
但是，StackStorm公司的Powell說新的消息隊列跟以前還是有一些不一樣的，“新的消息隊列從你系統發出去，查看系統運行效果的好壞，并返回決策是否應該執行什么（任務）。所有的這些都需要預定義并且寫入隊列中。不同之處在于返回方式的變化和條件邏輯的變化，以及從適合的出口出去的方式。”
StackStorm的產品是打算讓用戶完全管理的，不過云服務可以從用戶那里將消息隊列元素進行合理化和抽象化，可以達到看似應用無需任何服務器就能運行。
Lambda用戶Theodore Kim，也是Jobvite（一家軟件制造商）的SaaS業務主管說，基于云的事件驅動型計算服務能承擔自動化重任的其中一個原因是它不需要應用調查環境，尋找發生的改變，以觸發自動化。
AWS Lambda服務在后臺是使用輪詢還是消息隊列不得而知，但是對于用戶來說，Lambda函數是馬上就可以開始工作的，并不需要等待輪詢。
Kim說：“以前，我們需要將數據放到隊列中，并且對其進行輪詢。Lambda卻是立即起作用的。它就像是一個黑盒，所有的事情都會被Lambda服務處理，但是在我們看來，有事件觸發時，它馬上就執行了。”
事件驅動型計算會超過微服務嗎？事件驅動型計算越來越火了，它正在追上另一個火爆的軟件開發趨勢：使用Docker的容器，以及基于微服務的軟件開發。
就像事件驅動的自動化一樣，容器和微服務也能承諾應用的靈活性、組件間的自動化和可擴展性。事件驅動型計算和Docker并不是完全獨立的技術。事實上，在EC2 Container Service里，亞馬遜也建議引入Lambda來觸發對容器的創建，并對容器進行橫向擴展。
Edeva公司的Eskilsson說：“當我們進行橫向擴展的時候，我并不擔心遷移到基于Docker的開發環境。但是對Yii框架進行整合，并讓代碼推送到Iron.io，是很合理的一件事情。因此坦誠來講我并沒有看到（使用容器的）需要。”
VidRoll公司的Young稱，對于一些迫于將自有架構遷移到云上的企業，事件驅動型計算可能在架構變更上太過跳躍了。但是容器技術提供了一種更敏捷的方式來將傳統的基礎架構遷移到自動、云的環境。
事實上，Young的公司已經進行了一些開發，能讓他們的應用架構在Lambda和Docker之間進行切換，好讓應用隨著Lambda的發展得以保全。Young說：“容器是有意義的，因為它比起維護一個完整的服務器來說，是一個更好的抽象品。”
StackStorm公司的Powell稱，IT企業在開發者的生產力和運維自由度之間會有不同的偏好。
基于容器的計算對于將負載向內部云的遷移來說有更多的潛力。相反的，類似Lambda的東西有來自廠家的鎖定。Powell稱，“簡單地說，你的業務邏輯至少需要有一個應用需要運行在Amazon as a service上。”
京公網安備 11010502049343號