Use Cases
-
How Atlassian uses Camunda within their hyperautomation...
Learn why Atlassian turned to process orchestration to hyperautomate their tech stack with Camunda and deliver improved customer and employee experiences.
-
The Secret Behind the IT Transformation of...
Get details on how solutions built with Camunda enabled Covea to organize data more effectively and create an even-stronger user experience.
-
Maximus Modernizing and Maximizing Their Potential
Is less really more? Maximus embraced microservices orchestration to gain reduced software license, implementation and infrastructure costs.
-
Refactoring an Actor Model System from Nact.io to Camunda Cloud
This month marks the 20th anniversary of the Open Source Erlang language and the Erlang virtual machine. Renowned for its reliability, the ability to hot-patch running code, and the Actor model, Erlang has been incredibly influential in software development, particularly in scalable distributed systems. If you look through the Zeebe source code, you’ll see Actor components sprinkled throughout. Zeebe core engineer Deepthi Akkoorath did her PhD thesis in Scalable Consistency in theMulti-core Era and is a huge fan of Erlang. Here is a video of Deepthi describing the architecture of Zeebe, the workflow engine powering Camunda Cloud: https://www.youtube.com/watch?v=JbXKgQQmukE A couple of months ago, I wrote a statistics collector for the Camunda DevRel team. You can see the project in the...
-
Complex multi-repo builds with GitHub Actions and Camunda Cloud
BLUF (Bottom-line Up-front): GitHub Actions are AWESOME and will change your life, but you risk losing yourself in a microservices architecture of repos, or have to go monolith once you get a few dependent projects or cross service provider boundaries – unless you orchestrate. I show you how I did it in this article. Get access to the Camunda Cloud Public Access Beta here. Use the Zeebe GitHub Action to orchestrate multi-repo builds with Zeebe and Camunda Cloud. In this article: Preamble What are GitHub Actions? GitHub Actions: The Good GitHub Actions: The Bad GitHub Actions: The Ugly Custom CI with GitHub Actions and Camunda Cloud Zeebe GitHub Action Modelling the problem / solution Starting a Camunda Cloud workflow from...
-
Incident Alert Exporter
I took a break today from the article I’m working on about “Orchestrating GitHub Actions with Zeebe and Camunda Cloud” (stay tuned, because it is lit) to build an exporter for Zeebe, one that can alert you whenever an incident is raised – for example via Pushover, Pager Duty, or by calling you via the Twilio API. If you just want to see the code, it is on GitHub: Zeebe Incident Alerter. There are a couple of videos of the stream of me coding it at the end of the post if you want to see that. Using tutorials to write Zeebe extensions I followed a couple of tutorials from June last year to accomplish it – Writing a Zeebe...
-
Going to Zero-Scale Zeebe on Camunda Cloud with Cloudflare Workers
I get questions about running Zeebe at “zero-scale”. That means workers that consume no resources when there are no tasks to perform. The Zeebe service on Camunda Cloud includes a generic HTTP-Worker that can be used to achieve this. The HTTP-Worker polls for jobs of type “Camunda-HTTP”, and then invokes a REST endpoint based on the HTTP verb and URL set in the task headers. If you are not on Camunda Cloud you can use zeebe-http-worker, or just write your own. In combination with “serverless” functions, this can be used to achieve a zero-scale architecture. Cloudflare workers are serverless processes that run in response to REST requests at the edge of Cloudflare’s hosting infrastructure. “At the edge” means that a...
-
Operational Monitoring: Zeebe Cloud Canary
Designing a resilient system means planning for, and alerting on various failure states. The Zeebe Cloud Canary npm package adds alerting to your Node.js Zeebe applications. There are a few things that can go wrong in a Zeebe system that you definitely want to surface operationally. Your client applications might exception and halt. The broker might fail – whether due to a hardware failure or some edge-case condition that puts it in an infinite restart loop while recovering (it could be memory constrained, for example, and rescheduled by K8s before it can recover its state on boot up). Both of these cases can be detected by probes. The broker has a readiness probe that can be monitored for this, and...