SaaS API vendors have settled on programming language- and cloud platform-agnostic technologies like HTTP, REST, OpenAPI and, recently, GraphQL; allowing developers to jump right in and work easily. Event-driven architectures are rising to prominence in cloud-native solutions – however, they are not standardized and the main cloud platforms often have multiple, proprietary products.
The challenges of an event-driven world
Many large organizations run multiple platforms for their content, CRM, commerce and more to cater to different parts of their business. As businesses turn to headless, cloud-native platforms to modernize themselves with reduced bottlenecks and quicker releases, event-driven architecture has quickly become the staple and continues to spread across the industry.
Event-driven architectures can look similar and easy, on paper, to interconnect. The reality is there’s going to be different services, both modern and legacy, that customers want to bring together — that’s when it starts getting complicated, particularly when trying to connect services from outside your cloud provider.
The events from a cloud provider and a SaaS vendor’s API can have different configurations and processes. This makes them straightforward to implement on their own, but challenging to bring together to work as one.
The CloudEvents specification was created to help overcome those issues by being abstract enough to work with any programming language and cloud vendor, while also concrete enough to be useful. CloudEvents enables interoperability between major protocols, with a low learning curve and cloud platform support. Being an open standard is a big advantage of CloudEvents since anyone can contribute to making it better and also adopt it without major licensing hassles. This helps with the goal of propagating it through organizations and making it a ‘standard’ across the industry.
The big names behind CloudEvents
CloudEvents was first introduced in 2018 by the Cloud Native Computing Foundation (CNCF) as an initiative to provide a common way to describe events via an open standard. commercetools is proud to have supported this effort from the start.
The CloudEvents standard was crafted and shaped as a collaborative effort among dozens of contributors, many of which are big names in tech and cloud providers like Amazon, Google and Microsoft. commercetools is among the contributors in that list, represented by Christoph Neijenhuis, Tech Lead in the API design and event-driven integrations at commercetools.
CloudEvents 1.0 release milestone
In late 2019, CloudEvents hit its 1.0 release milestone, bringing significant improvements over previous iterations and marking a more formalized state of the project. With its v1.0 release, CloudEvents will shape a set of standards on how events and API calls are handled.
Even when custom-developed, events typically contain properties in the first place — CloudEvents will ensure naming conventions and the way events are described are the same across the board. The consistency and portability it brings will allow the support of serverless endpoints through the extension of existing services. The upsides brought by CloudEvents are very accessible through easy implementation and low adoption barrier.
As we believe in being at the forefront of the innovation curve, commercetools released support for CloudEvents 1.0 just after its release and will deprecate version 0.1 this month. Specifically, we’re proud that our Subscriptions API, used to trigger background processes in response to an event on our platform, makes extensive use of the CloudEvents format.
As a headless, cloud-native commerce platform, commercetools is able to work with other software and services in your organization’s ecosystem, from CMSes to tax lifecycle automation. The support of an open specification like CloudEvents makes our product even easier to work with and connect with other services you may use.
What’s next for CloudEvents
Now that the milestone release is out, there’s emphasis to increase adoption of CloudEvents. It’s already being used by the various cloud providers and SaaS companies in that list, and more outside of it. For event producers, CloudEvents is a sensible standard to stand behind since:
SaaS vendors benefit when protocols and products are standardized, which CloudEvents does for events.
Adapters to/from CloudEvents have been or will be written for many middleware providers (particularly the ones with larger market share).
CloudEvents is expected to trickle down to the customers of SaaS vendors that support it and become even more widespread.
Given enough SaaS vendors who support it, middleware providers with smaller market share will support CloudEvents for easier adoption of their product.
We’re at a stage where projects moving into the cloud and becoming headless has become mainstream. However, the reality is that the services used by enterprises are still going to be a mix between modern and legacy, which may run within the cloud or outside of it. CloudEvents simplifies the process of bringing different combinations of services together. An increased adoption of the CloudEvents specifications will drive higher levels interoperability between protocols and improve developer productivity across the board.