{"id":78681,"date":"2019-11-21T08:00:51","date_gmt":"2019-11-21T16:00:51","guid":{"rendered":""},"modified":"2025-06-27T04:32:08","modified_gmt":"2025-06-27T11:32:08","slug":"boosting-cloud-interoperability-cloudevents-v1-0-support-azure-event-grid","status":"publish","type":"post","link":"https:\/\/opensource.microsoft.com\/blog\/2019\/11\/21\/boosting-cloud-interoperability-cloudevents-v1-0-support-azure-event-grid\/","title":{"rendered":"Boosting interoperability in the cloud with CloudEvents v1.0 support on Azure Event Grid"},"content":{"rendered":"\n

When Microsoft launched Azure Event Grid<\/a> 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.<\/p>\n\n\n\n

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\u2019t a problem if you exclusively use one cloud provider, but that\u2019s almost never the case \u2013 and even then, if your data is a pain to move, it can present lock-in challenges.<\/p>\n\n\n\n

With Azure Event Grid less than 24 hours old, several major players in the cloud space got together and, in an unlikely collaboration, CloudEvents<\/a> 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.<\/p>\n\n\n\n

Quickly the decision was made that, to produce a valuable open standard event format, an impartial 3rd<\/sup> 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.<\/p>\n\n\n\n

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 \u2013 with Microsoft being one of the primary driving forces and largest contributors.<\/p>\n\n\n\n

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:<\/p>\n\n\n

\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.example.someevent\",\n    \"source\" : \"\/mycontext\",\n    \"id\" : \"C234-1234-1234\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"comexampleextension1\" : \"value\",\n    \"comexampleothervalue\" : 5,\n    \"datacontenttype\" : \"application\/json\",\n    \"data\" : {\n        \"appinfoA\" : \"abc\",\n        \"appinfoB\" : 123,\n        \"appinfoC\" : true\n    }\n}\n<\/pre><\/div>\n\n\n
This specification represents consensus, not only on what the top-level fields should be but also on:<\/p>\n\n\n\n