我们在《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上。”