We would love to support the standard, says XML inventor Tim Bray, but why not adopt ours?
Ten launch partners for AWS EventBridge
Amazon Web Services has come online with an update to its CloudWatch Events service, EventBridge, which has integration with integrated third-party SaaS applications .
EventBridge is not really a new service, but an improvement on an existing one. CloudWatch Events has been in existence since the beginning of 2016 and was designed to allow you to respond to changes in AWS resources, such as Simple Storage Service (S3).
You can connect it so that every time a file is added in S3, activate a works in AWS Lambda that does something with the file, for example. You can also trigger events on a schedule. Since the launch, CloudWatch Events now supports more services.
The Bezos combination launched the service with a superset of the functionality that was in CloudWatch Events. The important new feature is third-party support, so any provider can request Amazon to obtain events from its service published in EventBridge. The provider must register with the AWS Partner Network (APN), then apply to become an Integration Partner for EventBridge SaaS. The process requires "less than five days of development," according to the Amazon Frequently Asked Questions.
Once connected, any AWS client can subscribe to third-party service events. There are 10 companies that have committed to 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 the newest in EventBridge is the ability to create a custom event bus. Each custom event bus supports 100 rules, where each rule is an action triggered by an event. Custom event buses can have different permissions assigned.
The creation of an ecosystem around EventBridge is a strategic move of AWS, which reinforces the appeal of AWS to the customers of those third parties. services for parties that have been integrated, and those clients are more likely to build custom event handlers on the AWS platform.
AWS evangelist Jeff Barr noted that:
We are paying even more attention to the AWS event model in general, and it has many interesting developments on the drawing board. With this release, CloudWatch Events has effectively earned a promotion to a higher level service, and I will have much more to say about that in the future.
There are a couple of additional points to highlight. One is that the initial list of third-party companies that support the service is scarce. This is expected at launch, but it is also possible that larger providers may be wary of working on this with AWS.
There is also an emerging standard for the declaration and delivery of events in different services and platforms, managed by Cloud Native Computing Foundation (CNCF), and called CloudEvents. Microsoft supports CloudEvents in Azure Event Grid, its equivalent to the AWS service. It would be useful for all major cloud providers to support CloudEvents to reduce the burden of supporting multiple event services and allow developers to create standard libraries.
Last month, Tim Bray, co-author of the original XML specification, who now works on AWS in messaging. I expected AWS to be compatible with CloudEvents, saying on GitHub:
It has been proposed internally that "Let's support CloudEvents" and this seems like a good idea. There are no promises, but my opinion is that if we could find a plausible way to do it, there is a high probability that we will.
There is a "yes" in that statement, and Bray noticed a couple of difficulties. With "a large number of AWS clients" making use of the existing CloudWatch service, "there is no reasonable possibility that we change the names of the fields". He also said that:
CloudEvents is not finished, but we want to send production software in 2019. In theory, the working group could do a redesign of the attributes at any time. Can any organization plausibly claim to "support CloudEvents" at this stage of the story? It is not obvious to me how.
Addressed some solutions, including the suggestion that CloudEvents adopts the de facto standard of AWS:
If you want to try to make an AWS offer that you can not refuse, consider changing the names of the fields to match ours . We could add support for additional CloudEvents fields and our extras could be extensions.
There is some hope that AWS will do the right thing and work with the people of CloudEvents towards a common standard, but can not hold their breath. ®
Balance consumerization and corporate control.