The Cloud Native Computing Foundation’s (CNCF) CloudEvents specification hit its 1.0 release milestone and moved from CNCF’s “Sandbox” status to a more formal “Incubator" project. CloudEvents targets solving ongoing complexity around using events to trigger functions in increasingly adopted cloud-native environments.

The project was created to provide a common platform for developers to describe serverless events, which are what trigger serverless-based applications. This allows for greater portability of serverless application across different platforms.

More specifically, CloudEvents defines common attributes of an event that can provide interoperability and how those attributes are transported into an application environment using already-established protocols. It also provides a platform to support the building of tools for developing, running, and operating serverless and event-driven architectures.

This should make it easier for developers to integrate event data to build portable tooling. It will allow for greater portability of serverless applications across different platforms, such as Amazon Web Services (AWS) Lambda, Microsoft Azure Functions, and Google Cloud Functions. Those three cloud giants have all contributed to the project, along with the likes of IBM, SAP, Red Hat, and VMware.

The 1.0 release was a major jump from the project's most recent 0.3 status. Doug Davis, senior technical staff member at IBM and co-chair of CNCF's Serverless Working Group and the CloudEvents project, explained the main focus of the jump was on stabilization and testing.

“From a pure technical perspective, v0.3 was pretty stable and so not too much changed as we went through our testing phase,” he noted in an email to SDxCentral. “However, we went back and revisited a key decision point for us – how to deal with extensions – and opted for some changes that reduce the complexity of the system, which should increase adoption, ease implementation, and [interoperability].”

While CloudEvents sprung out of CNCF’s Serverless Working Group early last year, Davis noted that the project is not explicitly tied to serverless platforms. He explained that it can apply to any message that carries an event “regardless of whether it’s for serverless or not,” though he added that it will most likely solve serverless “pain points.”

“Having to manage – from a middleware perspective – the variety of events coming into the systems used to require quite a bit of customized code,” Davis said. “Now with CloudEvents there's a chance to abstract the event processing model by leveraging the standardized metadata that CloudEvents offers. This means that common tooling/middleware can be leveraged and not have to change each time a new event is processed.”

This is an ongoing challenge in the serverless ecosystem that is still somewhat siloed to a specific cloud provider. Some vendors have targeted this challenge through their own applications that operate outside of a neutral-host governance model.

TriggerMesh, for example, earlier this month launched its EveryBridge platform. EveryBridge is a serverless event bus that can connect applications using events, which is the thing that triggers a function to run.

TriggerMesh co-founder Mark Hinkle differentiated EveryBridge from CloudEvents in that their platform is a “generic event management system that can target services running in ‘pure’ Kubernetes, not just Knative.”

Microsoft is a supporter of CloudEvents, but also recently launched a similar eventing effort through its Kubernetes-based event-driven autoscaling (KEDA) platform. That platform, which was developed with Red Hat, allows developers to run those serverless functions within a Kubernetes environment across other clouds and on-premises locations.

The CNCF Technical Oversight Committee voted to move CloudEvent from the organization’s Sandbox to its Incubation layer, which is the middle layer in CNCF’s landscape model. Projects typically start out in the Sandbox, before maturing into Incubation, and then can become Graduated projects if they meet the group’s guidelines. Graduated projects include Kubernetes, Prometheus, and Envoy.

The CloudEvent 1.0 release has already been adopted into the Knative Eventing framework, Red Hat’s EventFlow, and SAP’s Kyma platforms. Microsoft has also said it will support CloudEvents natively in Azure through its Azure Event Grid.

Specific to Knative, CloudEvents provides the infrastructure to abstract event routing and filtering. Knative is not a CNCF project, but it is tied to CNCF’s halo Kubernetes project.

Looking ahead, Davis said that he hopes the project remains focused on dealing with smaller issues impeding adoption “rather than something too large. I think that'll make it easier to come to consensus and to rally the community around it.”