CloudEvents 0.1 – A common set of metadata to help process events(medium.com)
medium.com
CloudEvents 0.1 – A common set of metadata to help process events
https://medium.com/@austencollins/introducing-cloudevents-a758c62c76bf
25 comments
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.
> 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 :)
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 :)
Great points and good luck!
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).
[1] https://www.dmtf.org/standards/cadf
Context: I work on an internal OpenStack deployment at SAP that uses CADF for auditing.
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.
The references contain an OpenStack audit middleware event
https://github.com/cloudevents/spec/blob/master/about/refere...
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.
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'.
Also, most efforts are team-effort.
Also, most efforts are team-effort.
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.
Thanks for the clarification. That makes more sense with your explanation.
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.
This looks somewhat interesting.
but 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".
but 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".
[deleted]
So is this all an effort to combat amazon's dominance of the market? Because I see every competitor to them on this standard except for them.
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.
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.
+1
I'd personally use this to build some tools for a lot of AWS exclusive use-cases, in addition to multi-cloud stuff.
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.
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.
I certainly couldn't come up with anything else, and it seemed like the best name from the group.
Idea: Distributed peer-to-peer "serverless" computing, where you gain points/money for computing, that can be used to run your own functions.
Sounds like ether or one of the many projects built on it (golem?).
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.