Elements of Cloud Native Business Automation
Red Hat sponsored this post.
With cloud native becoming the de-facto standard for building and deploying modern applications, and with the proliferation of microservices style application architectures, agile DevOps processes and continuous delivery workflows, there has been an emerging need for highly scaled cloud native business automation platforms.
While traditional workflow platforms provide the ability to run, manage and optimize long-running business processes that cut across various business functions, their potential to orchestrate cloud native applications and microservices are limited by their ability to run and orchestrate applications on a container platform like Kubernetes or OpenShift.
With that in mind, the biggest question that arises is: what constitutes a cloud native business automation/workflow platform and how is it different from the traditional process automation platforms? Here’s my take on the characteristics of a cloud native business automation engine.
State Management and Persistence
Traditional workflow automation platforms rely heavily on relational databases to persist the state of the process instances, while cloud native business automation platforms tend to rely on in-memory data grids for state management. Using an in-memory data grid (with a suitable backing store) often reduces the latency that typically gets introduced into state management/business automation engines, while persisting the process instances state in relational databases.
Event Sourcing
A cloud native business automation platform would typically provide first-class citizen support for events, through event sourcing. Event sourcing in this context refers to the ability to natively emit the process and its constituents’ life-cycle events during the course of execution of the workflow so that other applications (including microservices) could subscribe and react to those events as per the business needs.
Also, the platform needs to be able to spew out the set of business events defined in the process models, so that the orchestration of the microservices and business applications gets more reactive in nature — thereby making the process automation more nimble and loosely coupled.
Domain-Specific Context
The ability to provide native business domain and workflow specific APIs, rather than a set of generic APIs, is a key differentiating factor for a cloud native business automation platform. Most often, the workflow engines provide a set of the APIs that often result in leaking of the workflow engine’s abstractions (like engine specific data models, interface definitions, etc.) into the applications that integrate with the workflow engines. Providing domain and workflow specific APIs will make the interactions with the workflow more aligned with the microservices and cloud native style.
Run Natively on Container Platforms
Leveraging the core capabilities of container platforms — more specifically scalability, elasticity, services discovery, fault tolerance, seamless roll-outs, security, traceability, observability and monitoring — is one of the biggest advantages of a cloud native workflow engine over a traditional one. Cloud native business automation platforms generally provide the ability to natively containerize each of the workflow applications (micro process flows) individually and run on any of the container platforms (potentially using Operators) — much like any other microservice, thereby providing hybrid cloud support.
Serverless
Orchestrating straight through the processing of workflows (short-lived processes) that integrate several applications — including managing their states and retries, along with failure handling — can be extremely challenging. With native support for serverless computing (primarily through Knative components), cloud native business automation platforms are able to offload and decouple the error handling, retrying, and failure handling logic (from the orchestration logic) to a service mesh. This makes it an infrastructure concern, rather than a workflow concern.
Minimal Footprint
Amazingly fast boot time and incredibly low memory footprint are the needs of the hour for applications running on container platforms. Such is the case with cloud native business automation platforms. These platforms typically offer near-instant scale-up and high-density memory utilization in container orchestration platforms like Kubernetes.
Conclusion
Currently, there are not many business automation engines that fit very much into the cloud native business automation space — AWS Step Functions and Lambda, Zeebe and Kogito come to mind. While each of these business automation platforms provides many of the aforementioned capabilities, Kogito — a Red Hat sponsored project that originates from some of the well known Open Source projects (Quarkus, Drools, jBPM, OptaPlanner and a few others) — seems to be the emerging platform for building cloud native workflows.
Feature image via Pixabay.