How AWS EventBridge API Destinations Are A Flow Innovation


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 destination in EventBridge and some rules to drive the right events to that destination.

Prefer to have customer purchases be automatically tracked in your Salesforce CRM system? Once again, API destinations to the rescue.

By the way, many common SaaS environments already have supported integrations for EventBridge, so you may have to do even less work for those.

As I make clear in Flow Architectures: The Future of Streaming and Event-Driven Integration, flow without interaction is just moving data around the network. It doesn't generate any real value. However, by turning APIs into simple, "codeless" ways to interact with your event streams, AWS is opening the door to a huge ecosystem of functionality and services. AWS has basically coopted the entire HTTP API ecosystem into its event-driven applications story. It's a brilliant move.

I expect this is not lost on the other major cloud providers, nor on the rest of the EDA vendor market. I therefore also expect to see much more simplification of API consumption in event-streaming services in the years to come.

Of course, once all of these services directly consume event streams through standard interfaces and protocols, we won't need any of this. But for now, this is a great move by AWS.

Comments

Post a Comment

Popular posts from this blog

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