The launch of Amazon EventBridge, a somewhat but not entirely new thing, has been well-covered by Jeff Barr; if you want to know what it is, go read Jeff. This piece is to provide a bit of background and context on EventBridge. I didn’t actually make any direct contributions, but was upstream from this work at the definition and early-planning stage.
CloudWatch what? · My first work at AWS was on the project that launched in January 2016 as CloudWatch Events. To us it felt like a small, simple, service — write rules to route notifications of things happening out there in AWS to Lambdas or other useful destinations. It wasn’t a big team or a big task and, when it came time to name it and find it a home, it was hard to believe it deserved top-level service billing.
Coming soon to a laptop near you. Warning: Prepared by engineers without involvement by marketing professionals or lawyers; let’s hope they’re OK.
Since CloudWatch already offered alarming and logging, eventing seemed like a nice third leg of the tripod, so our work launched as a tab on the CloudWatch page, and we thought that was OK.
Customers apparently liked it, and over the years, CloudWatch Events accumulated a mind-boggling number of users and a lot of the things they were doing weren’t really CloudWatch-y at all. Also, the whole Event-Driven Architectures drumbeat kept growing louder and louder out there in the community.
Last year, we got the idea of helping third parties (mostly SaaS vendors) integrate with their customers on AWS, and quickly became convinced that eventing was the right way to do this — while I’m a fan of the Webhook concept, the reality has not been a smooth ride. Once we’d made that call, enhancing the CloudWatch Events APIs to meet partner needs was pretty straightforward once we’d thought through the security dimensions. Except for, this was getting waaaay outside CloudWatch territory.
Which Bridge? · So, we decided that this service deserved top-level billing and went looking for a new name. The best possible answer would be “AWS Events”, right? Wrong. Go look at aws.amazon.com/events and hey, re:Invent, re:Inforce, AWS Summits… you get the picture. Thus EventBridge, which isn’t terrible.
(By the way, all your CloudWatch Events stuff still works and none of the existing API names or semantics have changed.)
The Event Ecosystem · It’s getting pretty big. Inside AWS, Lambda and SNS are event-centric. If you check out our competitors, you’ll notice more services with “Event” in their names every year. The numbers of events flowing through our various accumulated event streams has a lot of digits.
I’m personally pretty convinced that, while you can hook everything together with APIs, there are a whole lot of scenarios where choosing events buys you so much robustness and flexibility that it’s really hard not to. Is it perfect? Of course not: There are lots of places where the API ecosystem is slicker.
If you want to a really good explanation of why event-driven stuff might be in your future, the AWS NYC Summit talk by Mike Deck has what you need. As I write this the day of the summit, it doesn’t seem to be online but I’ll refresh once it gets there; and I bet Mike will reprise at future AWS, uh, events.
There’ll be lots more chapters in this story.
