BT

Event-Driven Microservices at O'Reilly Software Architecture Conference NY

| by Mark Little Follow 13 Followers on Mar 04, 2018. Estimated reading time: 3 minutes |

As reported by Joab Jackson, at this year's OReilly Software Architecture Conference in New York there was a focus on event-driven microservices. As Joab discussed, Chris Richardson gave a keynote on "Events on the outside, on the inside, and at the core":

Even current enterprise systems are driven around events he said. An airline delays a flight, a pharmacy fills a prescription. A delivery is scheduled. Some events are time-based: an invoice was not paid on time. Events allow separate applications to collaborate: any state changes within an application could, in fact, be an event, one that could be consumed by another application. A monitoring service could analyze a stream of events emitting from another application, checking to ensure the pattern of events is normal. Event-driven design is a way of extending applications without modifying them, Richardson explained.

We've covered event-driven microservices in the past, for example when Marius Bogoevici spoke about cloud-native streaming and event-driven microservices, or when Satyajit Ranjeev gave a retrospective on putting them into practice. The general agreement seems to be that event-driven architectures represent the right next step for microservices but do introduce another level of complexity. As Joab reports:

While initially, the move to an event-based architecture sounds easy, it does require a certain shift in architecture mindset, noted Cornelia Davis, Pivotal senior director of technology and author of the forthcoming book Cloud Native, in her keynote talk. Microservices, by their very nature, are an extreme form of distributed computing, Davis said.

Christian Posta wrote about some of the pros and cons a few years ago and then more recently he had this to say on the subject during one of our virtual panel sessions:

I think as you scale out systems like we talk about with microservices, they tend to exhibit characteristics we see in other Complex Adaptive Systems (stock markets, ant colonies, communities), to wit: autonomous agents, independent decision making, learning/adaptation driven by feedback, nonlinear interaction, etc. In systems like that, events, message passing, and time are all critical enablers that tend to look like the "async" model. IMHO making time the focal point between these systems (as well as the fact our communication channels may not be reliable) force us to deal with reality up front and make for a model we know scales in other applications.

Davis picks up on the theme of asynchronous distributed systems by suggesting that timeouts and retries, used successfully in traditional RPC based systems, may not be the right abstraction:

In an inherently unreliable distributed systems environment, the abstraction of promises may be a better fit than retries, however. Various components generate their own events, which populate a materialized view for the Web server through a serialized stream of events, or changes. “You can think of promises as event-handlers,” Davis said. An event handler will complete a step “if and when I need to,” she said.

A slight aside, but those who are interested in understanding some of the problems inherent in asynchronous systems should read the paper by Fischer, Lynch and Paterson on "Impossibility of Distributed Consensus with One Faulty Process."

Clearly the current focus around functions-as-a-service has an overlap here too. As we've reported in the past, these architectures are inherently event-driven and are also being seen as a natural evolution for building microservices. In fact, Joab reports that Davis had this to say on the subject:

“Events can trigger functions, and that is a very natural way of doing functions-as-a-service."

In conclusion, we do seem to be moving into an era where event driven microservices are becoming the architectural approach to be used first and we should expect to see more conferences and workshops, and ourselves, covering best practices, best frameworks and stacks, and examples of success and failures.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT