Nowadays, microservice architecture is becoming pervasive architecture style. Established and battle tested by start-ups like Netflix, Uber, Sound Cloud and larger established enterprises like Amazon and eBay it is now on a way to establish itself as de-facto standard architecture of complex IT systems. According to Sam Newman’s book, Building Microservices, principles to implement a microservices are as follows:
- Modelled Around Business Domain
- Culture of Automation
- Hide Implementation Details
- Highly Observable
- Isolate Failure
- Consumer First
- Deploy Independently
- Decentralise All The Things
Novel idea is to implement and deploy micro service independently from other services. Service should be modelled around business domain and hide its implementation behind API. It should have designed service API with consumer first principle. In case of service implementation change interacting services shouldn’t need to be changed. Using a lot of automation and DevOps practices consumer shouldn’t be even aware that new service is deployed.
All is well when we have one service in isolation. It can be easily tested, developed by small (one pizza) team. But to fulfil business needs services must interact within short and sometimes long conversations. For example, we can have some business flow that includes steps of scanning documents, uploading scan images to Document Management System and notifying responsible parties. It is obviously conversation that spans longer period of time. As a workflow it can be described simply as three consecutive steps with time in between (figure below).
Figure 1 Documents scanning workflow
In microservices world, how to solve this problem? One solution is to use choreography principles and design services to talk to each other. In our example this would mean that service that ships documents for scanning notifies uploading services that there will be some documents to scan. When documents are uploaded to DMS by uploading service it uses notification service to notify business parties. Implementation like this is not ideal because there are dependencies between services which then bring operational and development complexities. Also, business flow is hidden in the services implementation and it can be hardly documented and governed.
Figure 2 Service workflow conversation – saga
Conversation as shown by the workflow sample is something called saga. Saga, in short, is some business story. Saga has properties to handle workflow state and also includes of compensation flow if needed.
How to implement sagas in microservices? One way is to decouple micro services by sending events and principles like event sourcing. In this architecture, each microservice publishes event when something business relevant happens. Events are collected and stored (via eg. event sourcing). Events could be also used as a basis to create commands. Commands will “command” other services to perform some action. In this concept, figure below, we can connect the events with commands by implementing Sagas. There are frameworks that makes this simpler such as Axon framework. From architectural standpoint this is better than interconnected choreographed services but has some weaknesses:
- workflow (or saga) is hidden in code
- it is hard to implement complex saga (with timeouts, escalations etc.)
- state of the saga is not easily available (coding needed)
- sagas and events are tightly coupled, that is removing some event from occurring breaks saga
Figure 3 Microservices and events
What is the alternative? It is obvious by just looking at the workflow diagram. Some may recognize that workflow diagram is using BPMN notation elements. So why not use an BPM engine to implement saga patterns? Yes, BPM engines can be for some projects an overhead but for large enterprises where service and process governance is vital they can be very beneficiary. All of the drawbacks of coded sagas are alleviated by using visual form of sagas in form of BPMN flows.
Let’s try to implement the same workflow using BPMN engine. As seen in figure below, workflow is implemented using workflow engine such as IBM Business Process Manager. Each step is visualized in the flow and engine gives us runtime visibility of the process state. IBM BPM has a capability to raise event when something happens in the flow, such as starting of the flow, activity start or end. This is backed by the Dynamic Event Framework (DEF). Events are stored in the queue to be processed. Another tool, appropriate for the job, IBM Integration Bus acts as Event Processor. If wanted, here all of the event sourcing principles can be implemented. But in this case all we will do is recognize the event and create a command. Command will in first notify BPM engine that task is about to be performed. Secondly, appropriate microservice is called. Call can be synchronous or asynchronous. When microservice finishes, BPM engine is notified that activity is finished and workflow progresses to next item. In this architecture there is no direct service call from the BPM engine to the services. Integration Bus invokes services and has retry and fault tolerance capabilities. Also we need to ensure that this integration layer is really thin. Ideally we would want to implement flow as generic as possible and not to implement any business logic here. Business logic should be implemented as part of the each microservice following the microservice principles layed out previously.
Figure 4 IBM BPM as microservices workflow engine
Given today’s possibility of distributing IBM Integration Bus, Event Processor can be deployed alongside each of the microservice as a sidecar. Service implementation team could be also responsible to develop event processor to connect to the workflow engine.
Figure 5 Microservice deployment with IIB sidecar
To summarize, BPM engine (such as IBM Business Process Manager) could be used as workflow engine in microservice architecture. There are clear benefits of closing the gap between business and IT by doing so. Storing business logic in microservice makes workflow very light and manageable. Also, using integration product such as IBM Integration Bus removes the need for this technicality to be part of service implementation. Let us know if you would like this concept in more details. Miroslav Rešetar is also available at @MiroslavResetar.
