3 ms·

CloudEvents Event Specification

77 points by gtirloni 3y ago

Tknl 3y ago
AWS is noticeably absent in the list of implementations.
- whirlwin 3y ago
  Changing the CW implementation which is so tightly coupled to many other AWS service might be overly tricky for AWS to accomplish over a short period of time. Hope it happens anyway
  - paulddraper 3y ago
    What about EventBridge?
- erikerikson 3y ago
  AWS initially participated but was finalizing the Event Bridge format specification at a time when CloudEvents was not ready to go 1.0. [edit: more simply MS & GCP said were insufficiently flexible for the Gorilla and AWS wasn't willing to delay shipping]
  - Nickste 3y ago
    [I’m a PM on EventBridge] This is correct. Tim Bray, who built CloudWatch Events (which later became Amazon EventBridge) participated in the early CloudEvents spec, but as Erik said, CloudWatch Events launched before CloudEvents spec was finalized. From the EventBridge perspective, we like CloudEvents and I expect that in future we will look to add support for it as an alternative to our existing envelope.
RedShift1 3y ago
Any examples?
- gunnarmorling 3y ago
  Debezium (a platform for change data capture) supports CloudEvents as one format [1] for emitting data change events to Kafka, etc. Judging by interactions with users, there seems to be some interest in this, but it's not huge. [1] https://debezium.io/documentation/reference/stable/integrations/cloudevents.html https://debezium.io/documentation/reference/stable/integrati...
- guywithabike 3y ago
  We used CloudEvents internally at Segment as an evolution of the existing ad hoc format that evolved naturally over time. We were generally happy with its ability to bring some semblance of order, documentation, and guidance to our event format while also being flexible to changes. For example, we layered on the ability for internal services to return 207 Multi-Status responses to batched events and it didn't require major hacks.
  - MuffinFlavored 3y ago
    > We used CloudEvents internally at Segment as an evolution of the existing ad hoc format that evolved naturally over time. Is this just another way of saying "a really big JSON document"?
- erikerikson 3y ago
  Many Azure services, SAP, PayPal, KNative, and far more.
deleted 3y ago
[deleted]
verst 3y ago
In Dapr (Distributed Application Runtime) we use CloudEvents as the language and provider / service agnostic event standard in our PubSub API building block. You can either provide a cloud event envelope yourself, or just provide the data and we will create the envelope. https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview https://docs.dapr.io/developing-applications/building-blocks...
dingi 3y ago
We extensively use CloudEvents at my current company. It does a good job standardizing the event structure. It does pose some challenges in statically typed languages when it comes to deserialization of event data. We use typescript, so no complains in that regard.
- epgui 3y ago
  > It does pose some challenges in statically typed languages when it comes to deserialization of event data Why is this a challenge? I've worked with similar things in the past and never ran into any issues-- isn't this a very well trodden path?
eecc 3y ago
Base64 binary encoding? SMH… Also, why not just define RDF schemas and take it from there?

77 points by gtirloni 3y ago

Tknl 3y ago

AWS is noticeably absent in the list of implementations.

whirlwin 3y ago
Changing the CW implementation which is so tightly coupled to many other AWS service might be overly tricky for AWS to accomplish over a short period of time. Hope it happens anyway
- paulddraper 3y ago
  What about EventBridge?
erikerikson 3y ago
AWS initially participated but was finalizing the Event Bridge format specification at a time when CloudEvents was not ready to go 1.0. [edit: more simply MS & GCP said were insufficiently flexible for the Gorilla and AWS wasn't willing to delay shipping]
- Nickste 3y ago
  [I’m a PM on EventBridge] This is correct. Tim Bray, who built CloudWatch Events (which later became Amazon EventBridge) participated in the early CloudEvents spec, but as Erik said, CloudWatch Events launched before CloudEvents spec was finalized. From the EventBridge perspective, we like CloudEvents and I expect that in future we will look to add support for it as an alternative to our existing envelope.

RedShift1 3y ago

Any examples?

gunnarmorling 3y ago
Debezium (a platform for change data capture) supports CloudEvents as one format [1] for emitting data change events to Kafka, etc. Judging by interactions with users, there seems to be some interest in this, but it's not huge. [1] https://debezium.io/documentation/reference/stable/integrations/cloudevents.html https://debezium.io/documentation/reference/stable/integrati...
guywithabike 3y ago
We used CloudEvents internally at Segment as an evolution of the existing ad hoc format that evolved naturally over time. We were generally happy with its ability to bring some semblance of order, documentation, and guidance to our event format while also being flexible to changes. For example, we layered on the ability for internal services to return 207 Multi-Status responses to batched events and it didn't require major hacks.
- MuffinFlavored 3y ago
  > We used CloudEvents internally at Segment as an evolution of the existing ad hoc format that evolved naturally over time. Is this just another way of saying "a really big JSON document"?
erikerikson 3y ago
Many Azure services, SAP, PayPal, KNative, and far more.

deleted 3y ago

[deleted]

verst 3y ago

In Dapr (Distributed Application Runtime) we use CloudEvents as the language and provider / service agnostic event standard in our PubSub API building block. You can either provide a cloud event envelope yourself, or just provide the data and we will create the envelope. https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview https://docs.dapr.io/developing-applications/building-blocks...

dingi 3y ago

We extensively use CloudEvents at my current company. It does a good job standardizing the event structure. It does pose some challenges in statically typed languages when it comes to deserialization of event data. We use typescript, so no complains in that regard.

epgui 3y ago
> It does pose some challenges in statically typed languages when it comes to deserialization of event data Why is this a challenge? I've worked with similar things in the past and never ran into any issues-- isn't this a very well trodden path?

eecc 3y ago

Base64 binary encoding? SMH… Also, why not just define RDF schemas and take it from there?