Top Related Projects
Specifications for OpenTelemetry
The AsyncAPI specification allows you to create machine-readable definitions of your asynchronous APIs.
Quick Overview
CloudEvents is a specification for describing event data in a common way. It provides a standardized format for event-driven architectures, making it easier to produce, consume, route, and store events across different services and platforms. The CloudEvents spec aims to simplify event declaration and delivery across services, platforms, and beyond.
Pros
- Promotes interoperability between event-driven systems
- Simplifies event handling across different cloud providers and services
- Provides a vendor-neutral specification for event data
- Supports multiple serialization formats (JSON, Avro, Protobuf)
Cons
- Adoption may require changes to existing event systems
- Some developers may find the specification too verbose for simple use cases
- Limited tooling support compared to proprietary event formats
- Learning curve for teams new to the CloudEvents concept
Code Examples
As CloudEvents is a specification rather than a code library, there are no direct code examples. However, here are some examples of how a CloudEvent might be represented in JSON format:
{
"specversion": "1.0",
"type": "com.example.someevent",
"source": "/mycontext",
"id": "A234-1234-1234",
"time": "2018-04-05T17:31:00Z",
"datacontenttype": "application/json",
"data": {
"message": "Hello, CloudEvents!"
}
}
This example shows a basic CloudEvent with required and some optional attributes.
Getting Started
To get started with CloudEvents:
- Familiarize yourself with the CloudEvents specification.
- Choose a programming language and look for CloudEvents SDKs or libraries that support the spec.
- Implement CloudEvents in your event producers and consumers.
- Use CloudEvents-compatible event brokers or messaging systems to transport your events.
For more detailed information and implementation guidelines, refer to the CloudEvents website and the GitHub repository.
Competitor Comparisons
Specifications for OpenTelemetry
Pros of OpenTelemetry Specification
- More comprehensive, covering metrics, traces, and logs
- Broader industry adoption and support
- Extensive language-specific implementations
Cons of OpenTelemetry Specification
- More complex and potentially overwhelming for beginners
- Requires more setup and configuration
Code Comparison
CloudEvents example:
{
"specversion": "1.0",
"type": "com.example.someevent",
"source": "/mycontext",
"id": "A234-1234-1234"
}
OpenTelemetry example:
from opentelemetry import trace
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("my_span") as span:
span.set_attribute("attribute1", "value1")
Summary
CloudEvents focuses on standardizing event data for cloud-native systems, while OpenTelemetry provides a more comprehensive observability framework. CloudEvents is simpler and easier to adopt for event-driven architectures, whereas OpenTelemetry offers a fuller suite of observability tools but with increased complexity. The choice between them depends on specific project needs and the desired level of observability granularity.
The AsyncAPI specification allows you to create machine-readable definitions of your asynchronous APIs.
Pros of AsyncAPI spec
- Focuses on asynchronous APIs and event-driven architectures
- Provides more detailed schema definitions for message payloads
- Supports multiple protocols (e.g., AMQP, MQTT, Kafka) out of the box
Cons of AsyncAPI spec
- Less widely adopted compared to CloudEvents
- More complex specification, potentially steeper learning curve
- Limited to describing APIs, while CloudEvents is more generic for event data
Code comparison
AsyncAPI spec example:
asyncapi: 2.0.0
info:
title: Streetlights API
channels:
light/measured:
publish:
message:
payload:
type: object
properties:
id:
type: integer
lumens:
type: integer
CloudEvents spec example:
{
"specversion" : "1.0",
"type" : "com.example.someevent",
"source" : "/mycontext",
"id" : "A234-1234-1234",
"time" : "2018-04-05T17:31:00Z",
"data" : {
"message" : "Hello World!"
}
}
Both specifications aim to standardize event-driven architectures, but AsyncAPI focuses on describing APIs, while CloudEvents provides a more general event format. AsyncAPI offers more detailed schema definitions, while CloudEvents emphasizes simplicity and broad applicability across different systems and protocols.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
CloudEvents
Events are everywhere. However, event producers tend to describe events differently.
The lack of a common way of describing events means developers must constantly re-learn how to consume events. This also limits the potential for libraries, tooling and infrastructure to aide the delivery of event data across environments, like SDKs, event routers or tracing systems. The portability and productivity we can achieve from event data is hindered overall.
CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems.
CloudEvents has received a large amount of industry interest, ranging from major cloud providers to popular SaaS companies. CloudEvents is hosted by the Cloud Native Computing Foundation (CNCF) and was approved as a Cloud Native sandbox level project on May 15, 2018, an incubator project on Oct 24, 2019 and a graduated project on Jan 25, 2024 (announcement).
CloudEvents Documents
Latest Release | Working Draft | |
---|---|---|
Core Specification: | ||
CloudEvents | v1.0.2 | WIP |
Optional Specifications: | ||
AMQP Protocol Binding | v1.0.2 | WIP |
AVRO Event Format | v1.0.2 | WIP |
AVRO Compact Event Format | WIP | |
HTTP Protocol Binding | v1.0.2 | WIP |
JSON Event Format | v1.0.2 | WIP |
Kafka Protocol Binding | v1.0.2 | WIP |
MQTT Protocol Binding | v1.0.2 | WIP |
NATS Protocol Binding | v1.0.2 | WIP |
WebSockets Protocol Binding | - | WIP |
Protobuf Event Format | v1.0.2 | WIP |
XML Event Format | - | WIP |
Web hook | v1.0.2 | WIP |
Additional Documentation: | ||
CloudEvents Primer | v1.0.2 | WIP |
CloudEvents Adapters | - | Not versioned |
CloudEvents SDK Requirements | - | Not versioned |
Documented Extensions | - | Not versioned |
Proprietary Specifications | - | Not versioned |
Other Specifications
Latest Release | Working Draft | |
---|---|---|
CE SQL | v1.0.0 | WIP |
Subscriptions | - | WIP |
The Registry and Pagination specifications can now be found in the xRegistry/spec repo.
Additional release related information: Historical releases and changelogs
If you are new to CloudEvents, it is recommended that you start by reading the Primer for an overview of the specification's goals and design decisions, and then move on to the core specification.
Since not all event producers generate CloudEvents by default, there is documentation describing the recommended process for adapting some popular events into CloudEvents, see CloudEvents Adapters.
SDKs
In addition to the documentation mentioned above, there are also a set of language specific SDKs being developed:
The SDK requirements document provides information on how the SDKs are managed and what is expected of each one. The SDK feature support table is a good resource to see which features, event formats and bindings are supported by each SDK.
For more information about how the SDKs operate, please see the following documents:
Community and Docs
Learn more about the people and organizations who are creating a dynamic cloud native ecosystem by making our systems interoperable with CloudEvents.
- Our Governance documentation.
- Contributing guidance.
- Roadmap
- Adopters - See "Integrations".
- Contributors: people and organizations who helped us get started or are actively working on the CloudEvents specification.
- Presentations, notes and other misc shared docs
- Demos & open source -- if you have something to share about your use of CloudEvents, please submit a PR!
- Code of Conduct
Security Concerns
If there is a security concern with one of the CloudEvents specifications, or with one of the project's SDKs, please send an email to cncf-cloudevents-security@lists.cncf.io.
A security assessment was performed by Trail of Bits in October 2022. The report can be found here or on the Trail of Bits website.
Communications
The main mailing list for e-mail communications:
- Send emails to: cncf-cloudevents
- To subscribe see: https://lists.cncf.io/g/cncf-cloudevents
- Archives are at: https://lists.cncf.io/g/cncf-cloudevents/topics
And a #cloudevents Slack channel under CNCF's Slack workspace.
For SDK related comments and questions:
- Email to: cncf-cloudevents-sdk
- To subscribe see: https://lists.cncf.io/g/cncf-cloudevents-sdk
- Archives are at: https://lists.cncf.io/g/cncf-cloudevents-sdk/topics
- Slack: #cloudeventssdk on CNCF's Slack workspace
For SDK specific communications, please see the main README in each SDK's github repo - see the list of SDKs.
Meeting Time
See the CNCF public events calendar. This specification is being developed by the CNCF Serverless Working Group. This working group meets every Thursday at 9AM PT (USA Pacific) (World Time Zone Converter):
Please see the meeting minutes doc for the latest information on how to join the calls.
Recording from our calls are available here, and older ones are here.
Periodically, the group may have in-person meetings that coincide with a major conference. Please see the meeting minutes doc for any future plans.
Top Related Projects
Specifications for OpenTelemetry
The AsyncAPI specification allows you to create machine-readable definitions of your asynchronous APIs.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot