freshidea - Fotolia
For all the positive changes they have seen, many DevOps shops still find themselves caught between highly agile app development and still-cumbersome IT operations. Could event-driven computing bridge that gap?
In the world of event-driven computing, work is triggered by events such as user actions, sensors or messages from other applications and services. That's in contrast to the dominant procedural-programming model that defines a series of steps to be carried out.
"It's really about turning around who is driving the bus," said Jonathan Eunice, a DevOps architect at WayUp, an online job board in New York City. "In procedural programming, the program is driving the bus. In event-driven programming, users and results and things are driving it."
In recent years, several cloud providers have begun to offer event-based automation services. The most well-known of these is AWS Lambda, which runs code without users having to provision any servers. Industry experts believe that event-driven services such as these could take today's software development techniques and add more agile, reactive and automated infrastructure operations, balancing out the lopsided DevOps equation.
"[Event-driven computing] is fundamental to folks getting the kind of productivity boost that they're all being offered by their vendors telling them, ‘Hey, go agile!'" said Evan Powell, CEO of StackStorm, an event-driven software maker based in Palo Alto, Calif., which boasts big Web-scale players such as Netflix among its customers. "Agile isn't enough if you don't have ops acting in an agile way."
Modern, closed-loop automation that uses snippets of software code to reactively automate the infrastructure allows users to make the process of developing apps and managing their underlying resources more productive and agile in the real world, Powell said.
"I think it is the missing piece," Powell said.
Event-driven computing in action
IT pros who have put event-driven automation products into production agree with this assessment.
"Good software developers are not always good server administrators," said Seamus James, software engineer for Betabrand, an online clothing retailer in San Francisco. "We don't want them bogged down in the difficulties of server administration. Amazon and Lambda are taking out a lot of that difficulty and allowing software developers to write software, which is what we are supposed to do."
Event-driven automation also allows for easier management of computing resources at a scale that is too large for humans to keep up with. For example, Betabrand first put Lambda to use when a marketing partnership with a popular gaming blog generated traffic to Betabrand's website that overwhelmed servers in a traditional hosting environment.
"It demolished our servers," James said. "Took them down in like 20 seconds."
Meanwhile, James and his team had run across the Jaws platform (now rebranded Serverless Framework), which deploys AWS Lambda functions with the Simple Storage Service (S3), and ties together all the pieces Amazon has available for Lambda automation in a command line interface. Betabrand used this framework to overhaul its Web infrastructure to accommodate the traffic spike.
The first step was for Betabrand to break down the company's page design into a static website hosted on S3. Then, in order to notify customers when products they are interested in become available for purchase, Betabrand set up a Lambda function that collects email addresses and adds them to a DynamoDB database. This allowed Betabrand to capture marketing leads as one million unique visitors hit the website, without overwhelming the infrastructure.
"It couldn't have been easier to get that configured," James said. And the initial bill, taking into account Amazon's free tier of services? Seven cents.
That number grew to about $200 once S3 bandwidth costs were factored in, but the costs were still paltry compared with scaling out Web servers to accommodate the traffic, James said.
VidRoll is another example of an Amazon customer using event-driven computing to achieve infrastructure management at massive scale. The company processes billions of events per month in its advertising technology computing platform and has seen rapid growth. At first, it was processing 4 billion data points per month; within six weeks this year that grew to 40 billion, and a few weeks after that, 200 billion.
"There are these network effects of scale which are very difficult to manage if you have to spin up your own servers and manage all of the peaks and spikes of traffic," said James Young, CTO for VidRoll, which began using Lambda early in the beta. Within months, the company was on track to process 40 billion events a month with a team of four people.
"Having the ability to use Lambda allowed us not to have to worry about the underpinnings of how to keep the servers up," Young said. Engineers can also resolve problems with their code quickly, without having to coordinate across dev and ops teams.
Event-driven computing is also necessary when servers are located in places administrators can't reach, but rely on frequently updated event analytics to function. That's the case for Edeva, a Swedish company which makes "smart" speed bumps. Edeva uses a software-as-a-service offering from Iron.io to allow servers in remote speed-bump locations to send data to a central analytics system for processing, which runs on AWS.
John Eskilsson, a consultant to Edeva who set up the Iron.io infrastructure, said its easy integration into the Yii software development framework and its early support for the Python language have made the remote management of servers both on and off AWS much more developer-friendly.
"It just makes sense to use a software as a service like that so you don't have to manage all these extra servers and so on," Eskilsson said.
Message queuing for the masses
In some ways, what's old is new again -- for Iron.io and StackStorm's products, old-fashioned message queuing is central to how the software operates. Iron.io even sells a separate message queuing product called IronMQ, which triggers events in sister software called IronWorker.
However, there are some differences, said StackStorm's Powell.
"The ability to go out to your systems, see how they're performing actively or passively, take that back and then make decisions as to whether that is something that is actionable, all of that precedes then dropping [data] in the queue," Powell said. "The difference is the transformation and the conditional logic on the way in, and then having the proper [infrastructure] hooks on the way out."
StackStorm's product is meant to be wholly managed by the user, but cloud services can further streamline and abstract the message-queuing elements from users, to the point where applications can appear to run without requiring any servers at all.
One example of where cloud event-driven computing services can take the heavy lifting out of automation is by eliminating the need for applications to poll the environment looking for changes to kick off automation, said Lambda user Theodore Kim, director of SaaS operations for Jobvite, a talent acquisition software maker in San Mateo, Calif.
It's unclear whether the AWS Lambda service uses polling or message queuing somewhere in the back end, but to the user, Lambda functions appear to kick off immediately, without needing to wait for polling to take place.
"In the old days we'd drop [data] into a queue and poll against that, whereas with Lambda…it's immediate," said Kim. "It's kind of a black box, where it's all handled by the Lambda service. And for us, it looks like it executes as soon as an event is triggered."
Could event-driven computing upstage microservices?
As event-driven computing catches on, it's bumping up against another exploding software development trend: containerization using Docker, and developing software in terms of microservices.
Like event-driven automation, containers and microservices also promise application flexibility, automation between components and scalability. Event-driven computing and Docker aren't necessarily mutually exclusive technologies. In fact, to scale out containers in its EC2 Container Service, Amazon recommends a workaround involving Lambda to trigger the creation of new containers. Still, there can be considerable overlap between event-driven computing and containers when it comes to making architectural decisions.
"When we scale this out, I'm not afraid at all of moving over to a Docker-based deployment," said Edeva's Eskilsson. "But the integration I've made into the Yii framework for pushing code up to Iron.io, it's so streamlined I have frankly not seen the need to do [containers]."
For enterprise organizations who must adapt a legacy architecture to the cloud, event-driven computing may be too big an architectural leap, said VidRoll's Young, and containers offer a more agile way of porting a legacy infrastructure into an automated, cloud-agnostic world.
In fact, Young's company has developed the ability to flip-flop the architecture of its application between Lambda and Docker, to hedge its bets as its scales up with Lambda. "Containers make sense because they're a better abstraction than having to maintain a complete server," Young said.
IT shops will have different preferences as it comes time to balance another high-level computing equation: developer productivity vs. operational freedom, said StackStorm's Powell.
Container-based compute has a higher potential for inter-cloud portability of workloads, whereas things like Lambda "are up there with data gravity in terms of sources of lock-in," Powell said. "Literally, your business logic at least in that one app is being run by Amazon as a service."