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 an example on GitHub for rearchitecting a Java Monolith application. 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 with Resillient4J 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 & Video
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. 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.
The third version of the model included an example of time-related actions, such as notifications or “Cron Jobs” that needs to be triggered at a certain point in time-related to the context of our execution. In other words, time-sensitive actions that are associated with each individual instance of our models.
This last version exemplifies notifications that needs to be sent to the committee only when they haven’t reviewed a new proposal after a certain period of time. This kind of mechanism, allows us to implement reminders and notifications which can help us to delivery a better service to our “customers” in these case our potential speakers.
It is important to remember that, the workflow engine keeps track of all the data about these executions and send this data to ElasticSearch where it is indexed and ready for reporting and analytics. For this specific example, it might be interesting to know the average time that takes to make a decision in a proposal and configure the notifications according to a deviation from that time.
Sum up
There are loads of other interesting details inside the project, and as I mention in the presentation I want to thank mcruzdev1 for helping me to make the application better, more real and more complete. If you are interested in running this in your own cluster visit the example on GitHub and get in touch (via twitter @Salaboy or GitHub) if you want to get your hands dirty and help me and mcruzdev1 to keep improving the app to make a better example for everyone to use.
