很多使用DevOps的企业在见证了一些DevOps的积极挑战之后，发现他们自己仍处在高度敏捷的应用开发和仍然笨重的IT运维之间的尴尬场景。那么事件驱动型的计算能否打破跨越这层鸿沟呢？
在事件驱动的世界里，用户行为、感应器或者其他应用或服务的消息都会触发工作（流）。这和目前主流的预定义了一系列要执行步骤的程序性编程模型大不相同。
坐落在纽约的一家在线求职网站WayUp的DevOps架构师Jonathan Eunice说：“这简直就是颠覆了世界。使用程序性编程的时候，程序驱动了一切；使用事件驱动编程的时候，用户、结果以及事件驱动了一切。”
在最近的几年，许多云计算供应商开始提供基于事件的自动化服务。最著名的要数Amazon Web Services (AWS) 的Lambda了，用户可以在不需要提供服务器的前提使用它运行代码。业界专家相信这种事件驱动型的服务可以让现在的软件开发更加敏捷，反应更快速和达到自动化基础架构运维，这会使DevOps天平达到一定平衡。
Evan Powell，是一家位于加利福尼亚州帕洛阿尔托市的事件驱动软件制造商StackStorm的CEO，该公司很自豪自己已经在例如Netflix之类的客户中扮演着很重要的角色。他说：“‘事件驱动型计算’对于生产力需要提升的公司来说是很基础的，他们的厂家会告诉他们，‘嘿，快使用Agile吧！’，但是只要运维并没有以Agile方式运行，Agile还是远远不够的。
Powell还指出，在当今闭环的自动化过程中，使用很小一段代码来做基础架构的自动化反应允许用户在现实环境中开发应用和管理他们的资源时候更加具有生产力，更加Agile。
Power说：“我想这就是缺失的部分。”
事件驱动在起作用
将自动化产品引入到生产环境中的IT专家会很同意这个评价的。
Seamus James，旧金山一家在线服装零售商Bentabrand的软件工程师称，“好的程序员并不总是好的服务器管理员。”
“我们不希望他们陷于服务器管理的困难之中。Amazon和Lambda在剔除这些困难，让程序员专注于写程序，毕竟这才是我们应该做的事情。”
事件驱动的自动化也让人力很难管理的大型计算资源管理起来更容易些。举个例子，Betabrand第一次使用Lambda也是因为销售的合伙企业拥有一个很受欢迎的游戏博客，博客产生的流量将Betabrand网站背后的以传统托管环境搭建的服务器冲垮了。
James说：“这个事情对我们的服务器造成了损伤，并宕机了大概20秒。”
与此同时，James和他的团队将Jaws平台（现在改名为Serverless了）部署在AWS Lambda函数上，使用Simple Storage Service(S3)，并且利用命令行接口将所有可以Lambda自动化的部分绑在了一起。Betabrand使用这种框架彻底检查它的Web架构来适应流量高峰。
具体来说，Betabrand需要做的第一步是将公司页面设计拆解成托管在S3上的静态网页。
然后，为了在某些产品变得可用的时候能通知对这些产品感兴趣的用户，Betabrand设置了Lambda函数来收集邮箱地址，并将这些邮箱地址添加到DynamoDB数据库中去。这样子Betabrand可以在网页达到了百万级独立用户访问的时候捕获销售头羊，而不至于将服务器弄垮。
James说，“没有比配置这个更简单的了。”再加上Amazon的免费服务之后，初始的费用只需要7美分。
James说：“如果加上了S3带宽费用的话，这个价格会上升到200美金，不过如果和横向扩张Web服务器来达到同样带宽对比的话，这是微不足道的。”
VidRoll是另一个亚马逊的客户例子，该公司使用事件驱动型计算来满足大型基础架构的管理。在公司的技术计算平台上每个月都需要处理数百万的事件，而且这个数字还在增长。刚开始每个月处理40亿数据点；在今年的六个星期内，这个数字上升到400亿；几个星期后，达到了2000亿。
VidRoll的CTO James Young在Lambda的beta版本的时候已经开始使用Lambda了，他说：“如果你需要加速你的服务器并且管理所有高峰的流量，那么你会很难管理大范围的网络影响。”在几个月的时间内，他们4个人组成的公司已经步入正轨，并且能每个月处理400亿事件。
Young说：“使用Lambda可以让我们并不需要担心如何让服务器一直保持可用的状态。”因为工程师可以通过他们的代码很快地把问题解决，而不需要协调开发和运维团队。
事件驱动型计算对于一些管理员没办法到达服务器所在地的情况来说很有必要，不过这需要依赖于对事件分析频繁的更新。这也是Edvan，一家瑞典公司所做的“聪明的”加速。Edeva使用Iron.io提供的软件即服务让位于加速带的服务器发送数据到运行在AWS的中央分析系统中，并对数据进行处理。
负责在Edeva设置Iron.io基础架构的咨询师John Eskilsson说，“集成到Yii软件开发架构的简易性和它对Python语言的早期支持让服务器的远程管理对开发者更加友好，无论这个服务器在不在AWS上。”
Eskilsson说：“这样子使用软件即服务是有意义的，因为这样你就不需要管理所有这些多余的服务器了。”
面向群众的消息队列
在某种程度上说，旧的东西会变成新的。对于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称，对于一些迫于将自有架构迁移到云上的企业，事件驱动型计算可能在架构变更上太过跳跃了。但是容器技术提供了一种更Agile的方式来将传统的基础架构迁移到自动、云的环境。
事实上，Young的公司已经进行了一些开发，能让他们的应用架构在Lambda和Docker之间进行切换，好让应用随着Lambda的发展得以保全。Young说：“容器是有意义的，因为它比起需要维护一个完整的服务器是一个更好的抽象品。”
StackStorm公司的Powell称，IT企业在开发者的生产力和运维自由度之间会有不同的偏好。
基于容器的计算对于将负载向内部云的迁移来说有更多的潜力。相反的，类似Lambda的东西有来自厂家的锁定。Powell称，“简单地说，你的业务逻辑至少需要有一个应用需要运行在Amazon as a service上。”
文章评论
好文章，内容言简意赅.禁止此消息：nolinkok@163.com