Comparing Netflix Conductor's Architecture with Flowable's
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPCwWzOaYu8KH-1_PdB4g8s60pCTRzlziO814ETGN3nF04Jjr_Is3Y39b7UG73QT-_kq31G6dvfKgDaHgV412qlXpoI5FKjJVGOASCjWvy77y_gH1OklANsObqhONXqy3Qy7vSe3j1qH6uajFH6pd6ibEwArfrzP1jz94J2LSY8JkkvrzQ99nCiSUil8U/s16000/Flowable%20Service%20Overview.jpg)
EDIT: This blog post took so long that by the time I published I discover that just five days earlier, Netflix announced they " will discontinue maintenance of Conductor OSS on GitHub ". Here's my post anyway.... I have spent several years developing a service (within a big organisation) which uses the workflow engine Flowable to orchestrate the complexity of calling many different services.Whilst the project was a success and we saw the benefits of using a work flow engine, we did encounter a number of rather significant issues with Flowable itself ( I'll explain these on another post later ). This leads me to think that I would use a workflow engine again, but not necessarily Flowable. So what other workflow engines are out there? Netflix conductor is one which I plan on evaluating in this post. First - Some background The service I worked on provided a RESTful API to its clients. On receiving a request it executed a workflow which called many other