Microsoft Open Source Blog 
When Microsoft launched Azure Event Grid in August of 2017, our goal was to make it easier to quickly architect and compose event-driven systems. Pretty much at the same time, Serverless Inc. launched their own solution solving many of the same problems, which made us both realize that solving the same problem in different, custom ways had introduced a new problem: interoperability.
Two services each created with the express goal of making it quick and easy to compose other cloud services could not talk to each other without a serverless function or any other compute layer in between in order to translate. This isn’t a problem if you exclusively use one cloud provider, but that’s almost never the case – and even then, if your data is a pain to move, it can present lock-in challenges.
With Azure Event Grid less than 24 hours old, several major players in the cloud space got together and, in an unlikely collaboration, CloudEvents was born with the aim of making interoperability easy in event-driven systems. Plainly, point my event source at my event handler, and it should just work. A few meetings on the topic proved that the idea had value and that getting some of that largest players in the industry to cooperate was going to be an interesting challenge.
Quickly the decision was made that, to produce a valuable open standard event format, an impartial 3rd party was needed in order to ensure the project had equal input not just from the major public cloud providers, but also SaaS companies, industry, startups, OSS projects, and anyone else interested in making it easier for developers to build event-driven solutions anywhere.
CloudEvents was then handed over to the Serverless Working Group of the Cloud Native Compute Foundation. Over the past two years, 200 people representing 70 companies have joined weekly calls to advance the goal of interoperability, and 60+ people have contributed to the open source GitHub repository for CloudEvents – with Microsoft being one of the primary driving forces and largest contributors.
The result of these two years, 70+ companies, and countless hours working on an open source project is the small set of fields that constitute the CloudEvents v1.0 specification:
{
"specversion" : "1.0",
"type" : "com.example.someevent",
"source" : "/mycontext",
"id" : "C234-1234-1234",
"time" : "2018-04-05T17:31:00Z",
"comexampleextension1" : "value",
"comexampleothervalue" : 5,
"datacontenttype" : "application/json",
"data" : {
"appinfoA" : "abc",
"appinfoB" : 123,
"appinfoC" : true
}
}
This specification represents consensus, not only on what the top-level fields should be but also on:
- How extensions should be handled
- How those fields should be represented in JSON and AVRO
- Protocol bindings for HTTP, AMQP, Kafka, MQTT, and NATS
- Specification for WebHook usage
- How batching should be handled
- SDKs in C#, Go, Java, Javascript, and Python for serializing and deserializing
But most importantly, CloudEvents represents consensus on the idea that we need to make it easier for developers to connect disparate systems and software.
Not only has Microsoft helped lead the way in the journey to creating CloudEvents, but has also led the way in adoption. In April of 2018, when CloudEvents v0.1 was announced, Microsoft was the first company to implement it by supporting it in Azure Event Grid and making Azure events available in Cloud Events v0.1.
With the announcement by the CNCF of CloudEvents v1.0, we are incredibly excited to announce that Azure Event Grid supports CloudEvents v1.0 for both ingress and egress of events, and that multiple other Microsoft projects have also adopted CloudEvents – including the recently announced Distributed Application Runtime (Dapr) and Event Grid on IoT Edge projects.
With support for CloudEvents v1.0 in Azure Event Grid, every single Azure event source is capable of producing events in the CloudEvents v1.0 format. And vice versa, Event Grid can accept and route events from any CloudEvents 1.0 compliant event source and push them to Azure Functions, WebHooks, Event Hubs, or any other event handler.
Similarly, with support for CloudEvents v1.0 in Event Grid on IoT Edge, you can also leverage CloudEvents to publish events between containers on the same edge device or between edge devices for disconnected environments, as well as from the edge to the cloud for hybrid solutions.
We’re incredibly excited about the prospect of an open world in which developers can choose the systems and services they want to use without worrying about lock-in or interoperability issues, and hope to see you out there using CloudEvents as well.
If you’re looking for places to get started, check out how to use CloudEvents v1.0 with Azure Event Grid or with Event Grid on IoT Edge, read the CNCF Serverless Working Group primer on CloudEvents v1.0, or jump straight to the specification. If you’re interested in contributing, please check out the GitHub repository, or consider joining the regular calls hosted by the CNCF Serverless Working Group.
Questions or feedback? Let us know in the comments below.