Traffic-Lights for Microservices

 There was a time when message-oriented service to service software communication invariably followed a command-driven, centralised architecture model. We had languages such as Business Process Execution Language (BPEL) to not only aid with process design for such architectures but which could be executed as workflow engines. Then, in the mid 2000s, I was involved with the design committee called the OASIS Electronic Business Business Process (ebBP) Technical Committee, designing and standardising a language for an alternative kind of architecture model, called choreography. It was decentralised and was therefore arguably more suited to message exchanges between organisations rather than within an organisation. The centralised approach, on the other hand,  became known as orchestration. Another term for it, gaining popularity nowadays, is ‘command-driven’. 

The ebBP processes could collaborate and could be composed together into combinations of processes. The more atomic processes could be standardised and referenced in agreements between parties as they still are today (in frameworks which might not use ebBP but are influenced by the architecture model). Later, a new trend emerged to use the choreography design in message exchanges between services in a microservice software system. Each service could have autonomy and agreement with other services to collaborate on a set of business processes but keeping the independence of each service. 

What complicated things a little was the trend of message queuing and service bus architecture which we call ‘event-driven’ today. Event-driven architecture means that one service does not even need to know what other services are collaborating with it and synchronising their state with it. Arguably this combination of technology architectures is a recipe for chaos. I would caution that this be treated like a road traffic situation, and that orchestrated, command-driven workflow engines be used like traffic lights to bring order to ‘traffic’ trouble-spots. 

Orchestration nowadays does not need to be centralised. It too can use messages, command messages, as distinct from the event messages in a choreography. That is why it is also called ‘command-driven’. Traditionally orchestration used REST endpoints and this is still an important option. Orchestration differs from choreography in how distributed transactions are controlled. It typically uses a coded state machine. If the message transactions are controlled using a saga pattern, this still can be applied to command-driven services or workflow engines, but with a commander pattern state machine running in the saga. 

That is the technical terminology. My non-technical analogy is the use of a traffic light to control the flows of traffic. Each commander service is a ‘traffic light’ service which commands microservices to do things in order in a flow. It controls the flows of ‘traffic’. There are often trouble spots in a choreographed set of intercommunicating microservices and a strategic positioning of a traffic light might be just what is needed to restore order. 

Practicalities? Pinpoint the troublesome events in the microservices choreographies. Pinpoint where failed messages recur frequently. Then identify candidate services which could take a role as a controller/commander service. Implement orchestration of a suitable set of events by identifying command message that would trigger what event handlers do on receiving a published event. Introduce a saga with a state machine to send these command messages. States can include failures. Of course, extra messages will be required to respond with a success or failure message. Cancellation messages might be required too. Persisting the messages also needs consideration, as with event-driven messaging. 

An alternative to using a microservice as an orchestrator/commander is to consider replacing the event choreography with a workflow engine, perhaps a lightweight, even serverless solution. The commands need not be messages but could be requests and responses to and from a REST API. I have never tried this but it seems to be becoming accepted as a solution. I find the traffic light analogy quite compelling.