This looks similar to CADF [1], which is used by OpenStack, but it looks less structured.
In CADF, each event has a target (the thing that is changed or being viewed), an initiator (the user performing that action), and possibly an observer and reporters. I'm not sure if CloudEvents wants to be intentionally minimal, or if it just hasn't developed to the same intricacy as CADF (as the 0.1 version number suggests).
I'm a contributor on the project, and have been working to make sure that the use cases fit both requirements.
Can be difficult to maintain both, with naming conventions of the particular entities, but so far it seems to be moving forward, and the working group is collaborative.
Isn't it weird to have references to some AWS services, but not CloudWatch Events itself? To me that would be the service that makes the most sense as a comparison point.
This article has too much self-congratulatory tone that comes off as a bit disingenuous. A single person didn't invent 'serverless' and 'spread it all over the world'.
Good feedback. Didn't intend that. The goal was to give a personal perspective starting from the beginning of the serverless trend, to highlight why the effort is meaningful.
Yeah, seems totally in good faith. I think even a moderate order change makes it much better. Regardless, great work highlighting the work on cloudevents, and giving your personal context.
I don't think we're thinking about AWS at all, at least I'm not, nor have I ever heard them brought up in that context. We see a problem, we have a problem, we're working together for a combined solution that fits our use cases.
We have included AWS examples and considerations for their requirements, if they choose to be involved or not is on them.
Agreed, I think this is more an effort to have a free flow of event and information. It's not that one organization has a monopoly on it, it's that all users suffer small painful taxes at every boundary. Collectively they become rather large and this is a way to address that.
> Vendors (especially nascent ones) have an opportunity in serverless, if they decrease emphasis on trying to copy each other’s services, and instead innovate new serverless services that offer unique, best-in-class, value propositions.
I think this is super important. In the serverless space, we've seen a couple of larger API vendors (Auth0, Twilio, ...) build their own FaaS. This is great for "Hello World" projects, and projects focused only around that single API.
But I believe that for all bigger projects, that work with multiple APIs, you end up in hell. Some functions running on Auth0 webtasks, some on Twilio Functions and some on a cloud-vendor FaaS? Sounds like a maintenance nightmare.
What we tried is to integrate our events with the three big cloud players. It's doable rather quickly as long as it's just "dumping a message into a queue".
I think a spec like CloudEvents can make such integrations easier in the future, and it would allow us to make use of higher level features of the cloud providers, without having to deep-dive into their specific products. I'm petitioning my PO to give me some time to make our API compliant with CloudEvents :)
Harmonization between vendors is good. If all this is is common names for headers and keys to cut down on trivial divergence, this is great.
As for the big picture, one of the unfortunate consequences of HTTP having recently won out as the default protocol for remote interaction is having to reinvent or re-frame all of the prior art that's been in use with other platforms. There's half a dozen other pubsub messaging protocols and their associated framing and envelope specs, but they usually define full semantics around addressing and routing -- and usually run on lower-level transports than over HTTP.
Since this effort doesn't want to prescribe every facet of messaging, it can't directly define a more restrictive profile or overlay of an existing protocol. Instead, it has to start fresh, and invent yet another envelope format. Someday, someone will ask why there isn't a simple way of getting MessageID or MessageTimestamp across a variety of technologies whose purpose is largely the same, yet I don't think anybody will go back and define a one true mapping between the protocols. If some vendor later decides to accept AMQP as well, they'll write some glue code to translate, but if another vendor accepts it too they'll write their own independent mapper. This is one of the ways that incompatibilities proliferate: actors left to their own devices in the absence of unambiguous guidance.
It shows that standards can be both extremely useful and frustratingly bound to fashions.
Certainly true, CADF is a good format for auditing events, but in implementation the several I've used seen, support most of it, and make some subtle changes. That divergence causes it to be a mostly standardized format which might as well be a non-standradized format, involving mappings, etc.
Why did they have to name it cloudevents? What's in it that restricts the use of it to the cloud? Surely you can structure events acc.to this spec without using public cloud.
I would say it's more cloud native than cloud restricted. In the past we used to try to bring things from outside of the cloud into to the cloud, now we're starting to bring things born in the cloud out of the cloud.
Ironically, the spec under the CloudEvents standard is much less restricted to cloud-based objects than its early working version "open events"
We considered a number of cases where the event source is not addressable software. Heck, your local library can emit a feed of cloud events where the event source is an isbn Uri.
Nothing restricts it's usage, it's just that in the naming conversation, with the other names already taken, what domains were available, etc, it was the best option.
I certainly couldn't come up with anything else, and it seemed like the best name from the group.
25 comments
[ 1.9 ms ] story [ 41.5 ms ] threadbut I couldn't help but to point out that while healthy self promotion is good, the author needs to notch down a little on the "I".
In CADF, each event has a target (the thing that is changed or being viewed), an initiator (the user performing that action), and possibly an observer and reporters. I'm not sure if CloudEvents wants to be intentionally minimal, or if it just hasn't developed to the same intricacy as CADF (as the 0.1 version number suggests).
[1] https://www.dmtf.org/standards/cadf
Context: I work on an internal OpenStack deployment at SAP that uses CADF for auditing.
I'm a contributor on the project, and have been working to make sure that the use cases fit both requirements.
Can be difficult to maintain both, with naming conventions of the particular entities, but so far it seems to be moving forward, and the working group is collaborative.
Also, most efforts are team-effort.
We have included AWS examples and considerations for their requirements, if they choose to be involved or not is on them.
I think this is super important. In the serverless space, we've seen a couple of larger API vendors (Auth0, Twilio, ...) build their own FaaS. This is great for "Hello World" projects, and projects focused only around that single API.
But I believe that for all bigger projects, that work with multiple APIs, you end up in hell. Some functions running on Auth0 webtasks, some on Twilio Functions and some on a cloud-vendor FaaS? Sounds like a maintenance nightmare.
What we tried is to integrate our events with the three big cloud players. It's doable rather quickly as long as it's just "dumping a message into a queue".
I think a spec like CloudEvents can make such integrations easier in the future, and it would allow us to make use of higher level features of the cloud providers, without having to deep-dive into their specific products. I'm petitioning my PO to give me some time to make our API compliant with CloudEvents :)
As for the big picture, one of the unfortunate consequences of HTTP having recently won out as the default protocol for remote interaction is having to reinvent or re-frame all of the prior art that's been in use with other platforms. There's half a dozen other pubsub messaging protocols and their associated framing and envelope specs, but they usually define full semantics around addressing and routing -- and usually run on lower-level transports than over HTTP.
Since this effort doesn't want to prescribe every facet of messaging, it can't directly define a more restrictive profile or overlay of an existing protocol. Instead, it has to start fresh, and invent yet another envelope format. Someday, someone will ask why there isn't a simple way of getting MessageID or MessageTimestamp across a variety of technologies whose purpose is largely the same, yet I don't think anybody will go back and define a one true mapping between the protocols. If some vendor later decides to accept AMQP as well, they'll write some glue code to translate, but if another vendor accepts it too they'll write their own independent mapper. This is one of the ways that incompatibilities proliferate: actors left to their own devices in the absence of unambiguous guidance.
It shows that standards can be both extremely useful and frustratingly bound to fashions.
We considered a number of cases where the event source is not addressable software. Heck, your local library can emit a feed of cloud events where the event source is an isbn Uri.
I certainly couldn't come up with anything else, and it seemed like the best name from the group.