Amazon Web Services has gone live with an upgrade of its CloudWatch Events service, EventBridge, which has integration with third-party SaaS applications built in.
EventBridge is not really a new service, but rather an enhancement of an existing one. CloudWatch Events has been around since early 2016 and was designed to let you respond to changes in AWS resources such as Simple Storage Service (S3).
You can hook it up so that whenever a file is added in S3, it triggers a function in AWS Lambda that does something with the file, for example. You can also fire off events on a schedule. Since the launch, CloudWatch Events now supports more services.
Bezos' juggernaut launched the service with a superset of the functionality that was in CloudWatch Events. The big new feature is support for third-parties, so that any vendor can apply to Amazon to get events from their service published in EventBridge. The vendor has to sign up to the AWS Partner Network (APN), then apply to become an EventBridge SaaS Integration Partner. The process requires "less than five days of development," according to Amazon's FAQ.
Once hooked up, any AWS customer can subscribe to events from the third-party service. There are 10 businesses who've bought into the service, including Zendesk, Datadog, SugarCRM and Symantec.
You can also create events from your own custom applications. This was possible with CloudWatch Events, but new in EventBridge is the ability to create a custom event bus. Each custom event bus supports up to 100 rules, where each rule is an action triggered by an event. Custom event buses can have different permissions assigned.
Creating a ecosystem around EventBridge is a strategic move by AWS, strengthening the appeal of AWS for customers of those third-party services that have integrated, and making it more likely that those customers will build custom event handlers on the AWS platform.
AWS evangelist Jeff Barr noted that:
There are a couple of further points to note. One is that the initial list of third-party businesses that support the service is thin. This is to be expected at launch, but it is also possible that larger vendors are wary of working on this with AWS.
There is also an emerging standard for event declaration and delivery across different services and platforms, managed by the Cloud Native Computing Foundation (CNCF), and called CloudEvents. Microsoft supports CloudEvents in Azure Event Grid, its equivalent to the AWS service. It would be helpful for all the major cloud providers to support CloudEvents to reduce the burden of supporting multiple event services and to allow developers to create standard libraries.
Last month, Tim Bray - co-author of the original XML specification, who now works at AWS on messaging - gave hope that AWS would support CloudEvents, saying on GitHub:
There is an "if" in that statement, and Bray noted a couple of difficulties. With "a huge number of AWS customers" making use of the existing CloudWatch service, "there is no reasonable prospect of us changing field names." He also said that:
He addressed some workarounds, including the suggestion that CloudEvents in effect adopts the AWS de-facto standard:
There's some hope then that AWS will do the right thing and work with the CloudEvents folk towards a common standard - but do not hold your breath. ®
Still 'work in progress' but that's a huge vote of confidence
The Free Software Foundation really set the bar high there
Browser makers keep coming back to the need to please advertisers
Terms for open-source C++ toolkit tweaked to encourage contribution
Only Insiders need apply for now
Azure Functions 3.0 goes live, Microsoft Search learns some new acronyms, and more
Scheduled for summer 2020