No support for CloudEvents standard as AWS does its own thing with EventBridge

We'd love to support the standard, says XML inventor Tim Bray - but why not adopt ours instead?

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:

We are paying even more attention to the overall AWS event model, and have a lot of interesting goodies on the drawing board. With this launch, CloudWatch Events has effectively earned a promotion to a top-level service, and I’ll have a lot more to say about that in the future.

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:

It has been internally proposed that we "Support CloudEvents" and this seems to me like a good idea. No promises, but my opinion is that if we could find a plausible way to do it, there is a high likelihood that we would.

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:

CloudEvents isn't finished, but we want to ship production software in 2019. In theory, the working group could do a wholesale redesign of the attributes at any time. Can any organization plausibly claim to "Support CloudEvents" at this stage in history? It's not obvious to me how.

He addressed some workarounds, including the suggestion that CloudEvents in effect adopts the AWS de-facto standard:

If you wanted to try making AWS an offer it couldn't refuse, consider changing the field names to match ours. We could add support for the extra CloudEvents fields and our extras could be extensions.

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. ®

Biting the hand that feeds IT © 1998–2020