Case for Microservices Orchestration Using Workflow Engines

Abstract

Microservices have become the de-facto software architecture for cloud-native applications. A contentious architectural decision in microservices is to compose them using choreography or orchestration. In choreography, every service works independently, whereas, in orchestration, there is a controller that coordinates service interactions. This paper makes a case for orchestration. The promise of microservices is that each microservice can be independently developed, deployed, tested, upgraded, and scaled. This makes them suitable for systems running on cloud infrastructures. However, microservice-based systems become complicated due to the complex interactions of various services, concurrent events, failing components, developers’ lack of global view, and configurations of the environment. This makes maintaining and debugging such systems very challenging. We hypothesize that orchestrated services are easier to debug and to test this we ported the largest publicly available microservices’ benchmark TrainTicket [24], which is implemented using choreography, to a fault-oblivious stateful workflow framework Temporal [19]. We report our experience in porting the code from traditional choreographed microservice architecture to one orchestrated by Temporal and present our initial findings of time to debug the 22 bugs present in the benchmark. Our findings suggest that an effort towards making a transition to orchestrated approach is worthwhile, making the ported code easier to debug.