Why Flow Architectures Will Change How We Approach Systems Availability

 Event-driven approaches to integration (such as what I describe in Flow Architectures: The Future of Streaming and Event-Driven Integration) promise to change the way we solve a lot of problems in enterprise applications. Certainly the move to real time integration will change the speed at which we engage customers. However, an engineer named Scott Havens gave an interesting presentation at DevOps Enterprise a few years ago that opened my eyes to another interesting effect.

One of the biggest challenges in distributed systems is managing the effects of dependencies on the functionality of the system as a whole. Take, for example, a web application that must return a value calculated from data provided by several external sources. Havens used the example of a retail inventory availability service.


In a traditional service-oriented model, this task would be handled through a number of cascading service calls, starting with the service tasked with returning the final value, followed by calls to each of the external services that are providing relevant data. All of this would be done through request-response APIs (perhaps using REST), and possibly done in a synchronous fashion, meaning the calling service would have to wait for the called service to respond before continuing.

In a traditional (poorly designed) API service, this means that a failure in any of the service dependency calls would result in a failure for the service overall. Availability would then be a function of the availability of each service in the call chain, as noted in Havens's slide below.


That math is expensive. To maintain a reasonable 99.98% uptime (about 56 minutes downtime per year), Havens had to require the calling services to maintain 99.999% uptime (about 5 1/4 minutes downtime per year)—a considerable expense.

Note that call response times have a similar dependency. Each dependency service has to respond quite quickly in order for the availability service to meet its own objective.

Havens then turned his attention to what an architecture looks like in which dependencies stream their data to the availability service as events. He pointed out that a service that collects current state data and retrieves that current state locally is pretty much identical to a lookup table, so why not just use a lookup table? This would mean the only dependency that the availability service would have is a call to a very simple, very available local data set.

Thus, Havens pointed out, the streaming architecture availability service isn't dependent on the services supplying inventory data in order to meet a client request. As you can see, this changes the math completely.

In fact, I would point out that the availability service doesn't even need to know ahead of time of the existence of any given inventory data supplier. By providing an API to which suppliers can send data, this retailer can simply collect relevant data through a stream processor built for that purpose, and update the lookup table as needed.

The result is a much cheaper architecture for achieving the same availability.

But…

Now you have a new problem. How do you know you've received all of the valid data required to correctly calculate availability for any given item? What happens if there is an error processing an event, or a supplier has an issue on their end of the connection? How can you be sure your service is accurate?

This is the challenge we will see increasingly in the new world of event-driven architectures used for cross-organization integration (aka "flow"). Our stream processors are going to have to be cognizant that we may not even be aware that there is a problem in collecting and processing data. Part of the flow interfaces and protocols will be mechanisms for connection (or even subscription) monitoring, error handling, and possibly even data verification.

This is one of those big challenges that lead me to believe that wide-spread flow adoption is as much as a decade out. There are solutions today—patterns for stream management and even platforms with awareness of this problem—but there aren't any standards. It will be important that situational awareness be simple and reliable before businesses can trust event streams for their most important (or even innovative) functions.

I welcome your thoughts on this, as it is an interesting challenge, and one which I am sure many of you have been faced with. How do you think accuracy and completeness will be managed in a complex event-driven systems environment?

As always, I write to learn, so feel free to reach out on Twitter at @jamesurquhart, or in the comments below.

Comments

Post a Comment

Popular posts from this blog

How AWS EventBridge API Destinations Are A Flow Innovation

Image
The new API destinations feature of AWS EventBridge introduces a simple mechanism for defining how events processed by EventBridge should be packaged and sent to third party web APIs using standard HTTP verbs, such as GET, POST, and others. (Most commercial APIs are REST APIs, which use these verbs.) By defining some basic connection, authentication, and data formatting information using straight forward wizards and templating mechanisms, EventBridge can automatically create the right HTTP calls every time it processes a relevant event. I highly recommend reading this blog post from AWS's James Beswick to get a better understanding of how this all works. Why is this important news? Because AWS has just made nearly the entire API economy a valid set of consumers for your event streams without requiring you to write any code. Do you want Twiilio to consume a customer's exceptions stream so that it can text them the information in a timely manner? Just create an API destinatio...
Read more

Flow and the Future of Software Development

Image
Think about the ways in which the software development process resembles the flow of water running downhill. Ideas are the tiny drops of potential value that gather into features and architectures which then feed backlogs. From there, developers create code and configuration—thus adding value—which  then merges with other flows. Work done in the combined flow gains more and more value until it is presented to those that convert all that value into desired outcomes: profit, or perhaps mission success. OK, it's a bit of a corny analogy, but it represents my mental model of the challenges that developers face while creating any significant enterprise or commercial software system. First, the challenge is to convert potential energy (a worthy idea or demonstrated need) into kinetic energy (the increasing value of the solution to the end user) via a metaphorical force of gravity (the desire for the aforementioned profit or mission success). The other thing I picture is that water runnin...
Read more

Two Ways To Evaluate Which Event-Driven Architecture is Right for Your Flow Systems

Image
The event-driven platforms market is a confusing place. In fact, there is an entire appendix in Flow Architectures: The Future of Streaming and Event-Driven Integration dedicated to evaluating much of that market and it's almost a third of the book. Thus, it is no surprise that developers and architects not experienced with eventing systems struggle to identify the best platform for their applications. I've identified one method for making a selection in the book, which I will update in this blog post to reflect what I have learned since the book came out. I used a model based on the types of event streams, which works extremely well if you are going to consume a stream over which you have little control. (It also works for selecting technologies within a scope you control, but I am more interested in how you "future-proof" your decisions for a flow future.)  Another interesting way to slice the market comes from researcher Jamie Brandon, who looked at the problem fr...
Read more