We recently shared 3 Common Pitfalls in Microservice Integration - and how to avoid them and lots of you wanted more. So this four-part blog series takes us one step back to the things you’ll be considering before migrating to a microservices architecture and applying workflow automation. In this fourth and final post in the series, we’ll discuss why the physical ownership of process models is so important to ongoing success.
You can find the source code on GitHub for the simple order fulfillment application, introduced in the first blog in this series, available as the flowing-retail sample application which we use as an example in this blog.
Ownership of process models
Independent of the physical deployment of a workflow model (where the engine runs) it must be crystal clear who is responsible for a certain model, where it is maintained and how changes are deployed.
In microservice architectures the ownership of a workflow model must be in the team owning the respective domain.
In the flowing-retail example there are two workflow models:
- Order fulfillment: This belongs to the order fulfillment business capability and has its home in the order microservice.
- Payment: This is owned by the payment microservice.
It is really essential that you distribute the ownership of parts of the business process fitting to your domain boundaries. Don’t do a BPM monolith — where e.g. the order fulfillment process handles business logic and other details related to payment — just because you do a workflow model.
The “orchestration process”?
I am often asked: “But where is the orchestration process?” That’s easy – In my understanding of microservices, there is no such thing as an orchestration process. Often, people mean end-to-end business processes, like order fulfillment in the above example. Of course, the end-to-end process is highly visible and important, but it is domain logic like everything else and goes into a microservice boundary in our example the order microservice. In that sense the order microservice containing end-to-end orchestration logic might be very important — but organized the same like other microservices as e.g. payment.
When saying “orchestration process,” some people mean domain logic that only involves the flow — so the respective microservice might not have other logic (no own data, no own programming code, etc.). That’s fine — but it should still be a microservice as even this logic needs clear responsibilities. And often the logic grows over time anyway.
- This topic is complex and there are no easy-to-adopt-in-all-scenario-answers. I hope this blog series gave you some orientation. Let’s quickly recap:
- You need to choose your communication style: Asynchronous, RPC-ish or work distribution using the workflow engine. Depending on that choice the workflow engine can perform different favors for you:
- The ownership of workflow models must be in the domain of the respective microservice. The workflow should clearly concentrate on that domain.
- You can run the workflow engine centralized or decentralized.
- Track or manage —you should strive for a balanced mix of choreography and orchestration.
Interested in learning more?
Watch Monitoring & Orchestrating Your Microservices Landscape using Workflow Automation webinar, led by Bernd Ruecker, our Camunda Co-Founder and Chief technologist. He discussed how workflow automation supports the orchestration of microservices, ensuring seamless execution of business processes even in a case of a failure.
This blog was originally published on Bernd’s blog - check it out if you want to dive even deeper into microservices!