 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
CloudBees sponsored this podcast.
For the first 12 years of Gwen Shapira’s career, she worked on relational databases, where she learned all about both their power and limitations. In The New Stack Makers interview, Shapira, a system architect at Confluent, excitedly shares how event-driven architecture literally breaks down those limitations and redefines the boundaries of service responsibilities.
Event-driven architecture is part of the broader industry trend of separating components and streamlining processes so that releases are faster and organized around user activity. It’s all about pulling apart applications into components — usually, microservices — that you then chain together to better service business needs through the publishing of, listening to, and reacting to those events.
Gwen Shapira on the Power of Event-Driven Architecture
A simple example that Shapira offers is in the insurance space, where an address change can alter the risk of a customer, which then should trigger a quote recalculation. Traditionally this set of data is recalculated nightly or weekly with batch architecture — you know, when you’re told, “We’ll get back to you in five business days.”
Or there’s the request-response approach which, when someone updates that address, the address service will then request the quote service for a recalculation. The request needs this response because otherwise there’s no proof of recalculation.
“When you think about things in terms of responsibility, why is the change of address service responsible for quotes?” Shapira said.
She calls these “behavior leaks” — if the quote service is down, then the address couldn’t be updated. And you end up with extremely complex chains of responsibility.
In event-driven architecture, each service is simply in charge of publishing its change of state. So the change-of-address service just has to broadcast that a user changed its address, which then is recorded in an event stream. All the other services are continuously listening to those events and then react to it.
Within this redefining of boundaries, the user address and quotation services have completely isolated logics and the address-changing service doesn’t need to know about the quotation service. As soon as a change of address occurs, the respective service publishes all the address changes, and then services can react to that event, like the quote service updating.
Event-driven architecture is part of the trend, along with behavior-driven design and domain-driven design, where there’s a shared language between business and software planning and design.
Shapira says event-driven architecture gives “you this shared language to help have those conversations. You can go to people in your business and say: What are the important events? What are the things that happen in the world, in the business, that have a big influence that we need to publish that we need to have an ongoing record of?”
From there, the business conversation moves towards: When this event happens, what’s the expected reaction?
Event-driven architecture is more efficient because there are less dependencies for changes and uptime.
“In the old world, you have a lot of coordination which ends with a lot of overhead in your business processes. Once you’re fully event-driven, you can be a lot more independent,” Shapira said.
Although she reminds us that this takes away the need for us to have to talk to other teams in order to move forward, we can and should, of course, communicate — there’s just less holding us back between those important conversations.
The events just act as a kind of contract. Once these boundaries around user behavior are created, Shapira says event-driven architecture allows for more experimentation, opening up for progressive delivery efforts like blue-green deployments, canary testing and A/B testing.
And then, once you continue into the most complicated of data streams and processes — machine learning and artificial intelligence — the possibilities of event-driven architecture explode.
Photo by Xan Griffin on Unsplash.
