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.<p>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.<p>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.<p>It shows that standards can be both extremely useful and frustratingly bound to fashions.
> 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.<p>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.<p>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.<p>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".<p>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 :)
This looks similar to CADF [1], which is used by OpenStack, but it looks less structured.<p>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).<p>[1] <a href="https://www.dmtf.org/standards/cadf" rel="nofollow">https://www.dmtf.org/standards/cadf</a><p>Context: I work on an internal OpenStack deployment at SAP that uses CADF for auditing.
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'.<p>Also, most efforts are team-effort.
This looks somewhat interesting.<p>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".
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.
Idea: Distributed peer-to-peer "serverless" computing, where you gain points/money for computing, that can be used to run your own functions.