[#item_title]

Last Tuesday, I gave a presentation about “Orchestrating Microservices with Zeebe” for a London Meetup. In this blog post you can find the slides and video for the presentation – but first, a few words about the content of the presentation.

I’ve focused more on the orchestration side of the example that you can find here: http://github.com/salaboy/from-monolith-to-k8s^[1]. Instead of spending time discussing the frameworks used for the example, I’ve highlighted the importance of exposing the business logic and flow of our applications to other relevant stakeholders. You can always follow the links to download and run the example in your own Kubernertes Clusters.

The first half of the presentation was focused on the example scenario and some tools that I’ve used to build the Cloud Native version of the application. This intro covered the use of Spring Cloud Gateway^[2] with Resillient4J^[3] to provide a single entry point for all our services from outside the cluster.

After showing some of these projects in action and describing why you might want to look at them for your own projects, I spent some time describing the common pain points and challenges of building these kinds of applications and how we can use Zeebe, a workflow engine, to tackle some of these challenges.

Slides^[4]

https://www.youtube.com/watch?v=ZM9dfvXAncQ^[5]

During the demo, I focus 3 versions of the workflow model that built on top of each other.

First, we replace the code inside the Call for Proposals (C4P) service with a workflow model and we delegate the execution of this model to the workflow engine. You can find the code that was used before adding the workflow engine interaction here^[6]. The new version where the following model is used can be found here^[7]. The main difference in code is that now the Call for Proposal service doesn’t know or care which service is called next, that decision is now delegated to the following model (Version 1).

The second version of the model adds on top of the first one, by changing the model, hence changing the sequence of interactions, demonstrating how useful is to have the core business logic expressed as a model that can be shared with non-technical teams.

The new model covers the scenario where we need to send a confirmation link to our potential speakers to confirm their participation, before publishing the proposal to the Agenda.

Now that we have two versions of our workflow model, you can clearly explain how your Cloud Native applications are working today and how they were working yesterday, as these models can serve as live documentation about how your compony/organization is currently operating.