I have been hearing a lot about AWS Step function and I am kind of convinced that AWS step function can replace Camunda . Can someone point me to the difference between AWS step function and what Camunda does ? I know BPMN contains lot more feature than Step function but my general feeling is that AWS is continuously improving Step function and it might very soon be there . Any good pointer will be helpful ?
Hi Bhupendra.
AWS Step Functions and Camunda are indeed competition for some use cases.
I am currently comparing language features, but doesn’t have anything to publish yet. But in general BPMN is much more powerful at the moment - and you are missing a lot like timers (step functions is reduced for waiting with timeout), compensation or scoping (subprocesses). Of course step functions can eventually implement these concepts, but keep in mind that this also means: reinventing them. What I personally like about BPMN is that it is an ISO standard, so a lot of important players in the industry agreed on it and it is well discussed - so you can be sure important concepts are tackled and got right. I know that standards overall don’t have the best reputation at the moment, but I am convinced that they are very useful given a wide adoption like BPMN. A lot of people know it, so it is basically about proprietary vs. standard flow languages.
Another important aspect is visualization. With Camunda you get BPMN models, which are considerably known around the globe by various stakeholders. You can model your flows graphically, but you are not forced to do it by the way, you can also define your flow in Java DSL or YAML. In this case you still have a BPMN visualization (auto-layout). BPMN models enable a BizDevOps mindset as these models can be read by business people as well as developers as well as in operations. This is not so much the case with Step Function visualizations.
Talking about operations: Have a look at Camunda Cockpit and compare this to the AWS tooling, which I think speaks for itself.
Technically a big difference is that Step Functions are cloud only. You simply cannot run them locally or on premise. This might be OK for some, but limits the general applicability. And if you are doing cloud things, Step Functions support AWS stuff better than other (understandable). With Camunda you can also orchestrate e.g. Lambdas, but in the same way as other services (e.g. Azure Functions). It needs some custom glue code (nothing out-of-the-box yet), but is very flexible.
So personally I think it depends on your use case very much - and both tools can be a good fit. Not hard to guess my preferred default 
Let me know if you have feedback or concrete questions!
Cheers
Bernd
PS: Might be also interesting for you to have a look at http://zeebe.io/ - architectural wise it is even closer to Step Functions than Camunda BPM - but if you do not have the requirements for a huge load or to run without RDMS Camunda BPM is the better choice at the moment because of its maturity.
4 Likes
Thanks for that amazing feedback . Every point you mention is what I feel as well being a Camunda/BPMN developer for last few months . My specific question was do we have a comparison of feature set that makes Camunda more attractive than AWS step function along with some nice use cases that can be done in Camunda easily but cannot be done in Step function or not as easy to do in Step function ?
Just to give you a little more feedback we are moving towards AWS as a company and my team has been heavily invested in building Camunda workflow but after attending few AWS session , it seems like we can do most of the stuff with AWS step function as well without worrying about deployment or other stuff that comes with Camunda (Just FYI as this session are attended by my boss as well there has been question about why Camunda?) . I want to be proven wrong regarding step function as I love camunda and I hope someone can do that for me with some nice concrete examples (as I am not an expert in Camunda)
1 Like
I plan to make a more serious comparison later this month (hopefully) or early next year. For the moment I can give you a very prominent example: Compensation, which is about business transactions or also often referred to the Saga Pattern. Think of this simple payment example:
Assume that both services are not transactional, e.g. because they are Lambdas or REST. If the credit card fails you have to roll back the business transactions and compensate any money you deducted from the customer credit. BPMN can do this out-of-the-box, step function not at all (as far as I know). so you would have to model compensation logic “manually”, which might be easy in this case, but we often see much more complicated flows with more complicated compensations, where you have to duplicate basically all happy path flow logic into various compensation moments.
And as an additional remark: To make a fair comparison you would need to compare Step Functions against a Camunda cloud service - which is not yet there. But we will eventually have this. I cannot yet commit on any timeline, but don’t expect it too far away 
As soon as this is there, the comparison makes much more sense and is easier to do. I see the argument of easier operations. Not that it is hard to operate Camunda on AWS, a lot of customers are doing it, but it needs low level ECS or Kubernetes instead of just having the engine as a service.
Personally I still believe that the operational features in Cockpit (EE version) alone make a decision pretty easy for serious use cases. But of course that’s my personal opinionated view.
Hope that helps bit?
Cheers
Bernd
4 Likes
Doesn’t AWS Step functions provide “Catch” which can be used for such “recovery” or “compensation” steps?
Step Functions does indeed have a “catch” and this allows to catch errors and define an action what to do next. This can be used to implement compensation logic. However, the compensation logic cannot be distinguished from happy path logic any more, it is much more cumbersome to design complex logic and it is much harder to write and read. From my perspective this matters a lot - I wrote about this in https://blog.bernd-ruecker.com/bizdevops-the-true-value-proposition-of-workflow-engines-f342509ba8bb.
2 Likes
@BerndRuecker , We are evaluating using AWS Step functions v/s Camunda.
Can you provide me some kind of performance comparison for the same. I am looking for scale parameters like
- Maximum number of parallel execution of workflows
- Maximum number of state transitions per second
- Maximum size of data that can be passed across tasks etc.
(of course with the assumption of some hardware and for a single node)
Thanks in advance
Can you send me a private mail (bernd.ruecker@camunda.com)? I would have some counter questions and it probably needs some more info to give you better ideas.
2 Likes
Haven’t received anything yet - can you please try to send it again and ping me here (to make sure it did not go into SPAM)? Thanks.
Hi,
I am into integrations: SAP, “on premesis” (=SAP PO). So sad that your conversation did not come to an end.
Is there a Camunda-aaS by now?
Is there a Bernd-RĂĽcker-posting on AWS/step vs. BPMN available by now?
Background: In a recent engagement of mine, my client kicked SAP CPI and workflows off his strategic SW architecture road map - in favor of AWS and step functions.
Developers were a little bit puzzled:
“How can you prefer a low on semantics state engine (= AWS/ step) to a powerful formal semantics based BPMN engine (= SAP CPI / Workflow)?”
My guess:
Due to SAP price tag
- SAP PO performance on BPMN was discouraging
- SAP CPI / workflows not yet visible enough
(Very hard to get your hands dirty on SAP Cloud Platform).
I would enjoy BaaS (=BPMN as a Service) like Microsoft flow or IFTTT.
Hoping this thread receives a revival
@drueffler you can do the equiv of step functions or whatever tooling with external tasks. The external task is configured to tell the external task worker to execute the task and return the result.
You can execute your tasks in any language you like.
Hi Dieter.
Great to see you here in our forum! There is no official “AWS State Language” vs “BPMN” or “AWS Step Functions” vs. “Camunda” post available, and I still believe I am probably the wrong person to write it 
But what I can share is that we have users even migrating from Step Functions to Camunda, validating my hypothesis around the limitation of the language.
Ah, and yes, in the meanwhile there is a managed workflow service available, namely Camunda Cloud, see https://blog.bernd-ruecker.com/camunda-cloud-the-why-the-what-and-the-how-8198f0a8c33b.
I could only guess reasons for that decision - but again happy to discuss in a direct conversation if you like.
Hope that helps!
Best
Bernd
Took me a while to find a source for "SAGA pattern: " Saga (Entwurfsmuster) – Wikipedia
What does the acronym SAGA stands for? Simple API for Grid Applications?
For the SAGA pattern there is a direct comparision BPMN vs. AWS STEP available - pretty similar:
Source: https://zeebe.io/blog/2018/08/bpmn-microservices-orchestration-part-2-graphical-models/
I always wondered how to align BPMN-Diagram with logic. I do not enjoy the idea to have logic embedded with BPMN. But I like BPMN refering to logic. For me BPMN and AWS Lambda or microservices in general are a good fit.
…and I do not enjoy the idea of generating BPMN from a pile of development artefacts as SAP PO does it and fails a lot.
@Camunda: Do you offer workshops on applying Camunda Clouds managed BPMN?
1 Like
Term “Saga” is neither abbrevation nor acronym, the word itself meaningful. For example, you can say both sides of coin or positive & negatives. In workflow, its used for managing distributed transactions in terms of completing the transactions successfully, and if failure rollback all the transactions (compensation)
The term “saga” was first used in a 1987 research paper by Hector Garcia-Molina and Kenneth Salem.
Distributed Saga Guarantee
Distributed saga guarantees one of the following two outcomes:
- Either all Requests in the Saga are succesfully completed , or
- A subset of Requests and their Compensating Requests are executed.
Distributed Saga Implementation Approaches
There are a couple of different ways to implement a Saga transaction, but the two most popular are:
- Event-driven choreography (Axon server/Apache Kafka/Messaging systems) : When there is no central coordination, each service produces and listen to other service’s events and decides if an action should be taken or not.
- Command/Orchestration (Workflow systems): When a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic.
1 Like
For Saga: Exactly I talked about this in Bernd Ruecker
I currently looking into Orchestrating Lambdas in more detail with some customers and plan to write a more detailed how-to soon.
Definitely - we went through that hell a couple of times in the past - might I say BPEL?
We do offer a range of workshops, but nothing dedicated to the cloud. But actually the engine within Camunda Cloud is http://zeebe.io/ - so what you learn for Zeebe will be valid for Camunda Cloud. That’s said: we don’t have a classroom training for Zeebe yet but working on the material, so it is not impossible to do something customized onsite.
1 Like