Phill Barber's Blog

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

 I was fortunate to attend a great talk by Sam Newman on the above subject, here is a brief summary of the content and my thoughts. First off, I should say that I went in to the talk regarding myself as "experienced" on the subject of microservices.  I anticipated learning about the more complex "data decomposition" aspects rather than the basics.  However I have to admit that even the fundamental points on microservice were still a benefit for me to hear.  This is likely due to Sam being such a good teacher.  I found myself somewhat re-learning topics which I hadn't anticipated. Microservices and Backwards Compatability Sam described microservices as an architecture style which allow you to partition your functionality into separate services which are independently deployable .  The data that each service stores is hidden within the microservice boundary.  They allow you to scale your organisation since you can have teams working on separate systems in paralle