Orchestrating MicroServices

During this 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 . 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.

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 this kind of applications and how we can use Zeebe, a workflow engine, to tackle some of these challenges.

Slides & Video

[slideshare id=238988609&doc=orchestratingmicroserviceswithzeebe-201027114016]

https://www.youtube.com/watch?v=ZM9dfvXAncQ&feature=youtu.be

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. The new version where the following model is used can be found here. 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 to mcruzdev1 for helping me to make the application better, more real and more complete. If you are interested in running this example in your own cluster visit: http://github.com/salaboy/from-monolith-to-k8s and get in touch 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.