Project: CloudEvents (App Definition and Development / Streaming & Messaging)
File: 2018-11-14-KubeCon-Intro-DeepDive.pdf

Introduction: 
CNCF Serverless WG & 
CloudEvents 
Doug Davis - dug@us.ibm.com 
Cathy Zhang - Cathy.H.Zhang@huawei.com Agenda 
●Serverless WG Overview 
●CloudEvents Overview 
●SDKs 
●Status of CloudEvents 
●Serverless Workflow Introduction 
●Demo - time permitting 
●Q&A Serverless WG Overview 
●Technical Oversight Committee initiated 
○Whitepaper 
■Overview of technology 
■State of ecosystem 
■Recommendations for possible CNCF next steps 
○Landscape 
●CloudEvents - Minimal common attributes / shape of events 
○Sandbox project 
●Function workflow - orchestration of Functions CloudEvents Overview 
●Consistent metadata & format 
●Core specification - minimal properties 
●Transport bindings - how to serialize in JSON, HTTP, MQTT, ... 
{
  "specversion" : "0.1", 
  "type" : "myevent", 
  "source" : "uri:example-com:mydevice", 
  "id" : "A234-1234-1234", 
  "time" : "2018-04-05T17:31:00Z",     
  "contenttype" : "text/plain", 
  "data" : "Hello" 
}It’s not about data. 
It’s about metadata! CloudEvents Use Cases 
●Normalize events, web-hooks, across environments - interop!! 
●Facilitate integrations across platforms 
●Leave the event business logic processing to the application 
●First step towards portability of functions CloudEvents Deliverables 
●CloudEvents Specification  – define the metadata 
●Serialization Rules Specifications 
○JSON  event format 
○AMQP  event format 
●Transport Bindings Specifications 
○HTTP  – binary and structured 
○MQTT 
○AMQP 
○NATS 
○Web-hooks 
●Primer Cloud Events SDK 
●SDK CloudEvent Sub-group 
○(De)Serializer for CloudEvents on various transports - at least http 
○Provide consistency across SDK / languages 
●Development underway (WIP) 
○Go
○Java 
○Javascript 
○CSharp 
○Python Status of CloudEvents 
●Current version: v0.1 - April 2018 
○v0.2 very soon! 
●What’s left for CloudEvents v1.0? 
○Finalize the core Event Attributes 
○Finalize the set of protocol and serialization mappings 
○Documentation, developer and/or user guide. 
○Interop demos & verification through implementations and testing 
●What will come after CloudEvents 1.0? 
○Develop SDK and supporting tools for CloudEvents 
○Stabilization and adoption (organize more CloudEvents Interop Demos) Workflow Introduction WorkFlow Introduction 
WorkFlow Introduction 
WorkFlow Introduction 
WorkFlow Introduction 
Demo - Time Permitting CloudEvents Demo 
https://youtu.be/TZPPjAv12k 
Cloud Events Demo 
https://twitter.com/CloudEventsDemo/lists/demo Thank You! 
●Serverless WG : https://github.com/cncf/wg-serverless 
○Workflow: https://github.com/cncf/wg-serverless/tree/master/workflow/spec 
●CloudEvents : https://cloudevents.io/ 
○Org : https://github.com/cloudevents 
○Spec repo : https://github.com/cloudevents/spec 
○SDKs : https://github.com/cloudevents/sdk- ...
●Deep-Dive Session: Thursday November 15 - 15:05-15:40 - 3M 3 
○Cathy: Serverless Workflow: Key to Wide Serverless Adoption 
■Thursday November 15, 2018 12:15 - 12:50 
●Questions? Deep Dive: 
CNCF Serverless WG & 
CloudEvents 
Clemens Vasters - clemensv@microsoft.com 
Cathy Zhang - Cathy.H.Zhang@huawei.com Agenda 
●CloudEvents Deep Dive 
●Workflow Overview 
●Q&A Eventing vs Messaging 
•Events and messages are both mailing envelopes for data, decorated 
by metadata – but they are different. 
•Events carry facts. They report things that have happened. 
•State transitions, observed conditions, objects having been created, … 
•Messages carry intents. The sender expects something to happen. 
•Command execution, job handling, workflow progress, … 
•Events are published as an information option for interested 
subscribers. The audience size may be zero or many. 
•Messages are sent to handlers. There may be delivery and handling 
status feedback, replies, conversations, or complex control flows like 
Workflows and Sagas. The audience size may be one or many. CloudEvents - Base Specification 
•CloudEvents is a lightweight common convention for events. 
•It’s intentionally  not a messaging model to keep complexity low. 
•No reply-path indicators, no message-to-message correlation, no target 
address indicators, no command verbs/methods. 
•Metadata for handling of events by generic middleware and/or 
dispatchers 
•What kind of event is it? eventtype 
•When was it sent? eventtime 
•What context was it sent out of? source 
•What is this event’s unique identifier? eventid 
•What’s the shape of the carried event data? contenttype , schemaurl 
•Event data may be text-based (esp. JSON) or binary CloudEvents - Event Formats 
•Event formats bind the abstract 
CloudEvents information model to 
specific wire encodings. 
•All implementation must support JSON. 
JSON is the default encoding for where 
metadata text must be rendered, e.g. 
HTTP header values 
•AMQP type system encoding defined for 
metadata mapping to AMQP properties 
and annotations 
•Further compact binary event format 
candidates might be CBOR, or Protobuf. JSON Representation {
  "specversion" : "0.1", 
  "type" : "myevent", 
  "source" : "uri:example-com:mydevice", 
  "id" : "A234-1234-1234", 
  "time" : "2018-04-05T17:31:00Z",     
  "type" : "text/plain", 
  "data" : "Hello" 
}HTTP Transport Binding 
•Transport bindings bind the CloudEvent event metadata and data to 
the transport frame of an existing application or transfer protocol. 
•HTTP Transport Binding: 
•Binds a CloudEvent event to the HTTP message. Works for both requests 
and replies. Does not constrain usage of methods or status codes; can be 
used for all cases where HTTP carries entity bodies. 
•Structured mode: Complete event including metadata rendered carried in 
entity body. Upside: Easier to handle/forward 
•Binary mode: Only event data carried in entity body, metadata mapped to 
headers. Upside: More compact HTTP Structured Binding Mode 
HTTP/1.1 POST /myresource 
…
content-type: application/cloudevents+json 
{
  "specversion" : "0.1", 
  "type" : "myevent", 
  "source" : "uri:example-com:mydevice", 
  "id" : "A234-1234-1234", 
  "time" : "2018-04-05T17:31:00Z",     
  "contenttype" : "text/plain", 
  "data" : "Hello" 
}
Complete event including metadata rendered carried in entity body. Upside: 
Easier to handle/forward HTTP Binary Binding Mode 
HTTP/1.1 POST /myresource 
ce-specversion: 0.1 
ce-type: myevent 
ce-source: uri:example-com:mydevice 
ce-id: A234-1234-1234 
ce-time: 2018-04-05T17:31:00Z      
content-type: text/plain 
Hello
Only event data carried in entity body, metadata mapped to headers. Upside: 
More compact Other Transport Bindings 
•AMQP: ISO/IEC messaging protocol used for a variety of message 
brokers and event buses; defined in OASIS 
•Binds event to the AMQP message 
•Binary and structured modes 
•MQTT: ISO/IEC lightweight pub/sub protocol for device telemetry 
propagation; defines in OASIS 
•Binds event to MQTT PUBLISH frame. 
•Binary and Structured for MQTT v5 
•Structured mode only for MQTT v3.1.1 (lacks custom frame headers) 
•NATS: Text-based lightweight pub/sub protocol 
•Binds event to the NATS message. 
•Structured mode only (lacks custom frame headers) Workflow Deep Dive Workflow Overview (Use Case) 
Workflow Overview (Key Primitives) 
Workflow Overview (Use Case) 
Workflow Overview 
Thank You! 
●Serverless WG : https://github.com/cncf/wg-serverless 
○Workflow: https://github.com/cncf/wg-serverless/tree/master/workflow/spec 
●CloudEvents : https://cloudevents.io/ 
○Org : https://github.com/cloudevents 
○Spec repo : https://github.com/cloudevents/spec 
○SDKs : https://github.com/cloudevents/sdk- ...
●Questions?