James Birnie


Software Delivery (A) 2018
Software Delivery (A)
Friday 11:30 - 12:15

Session type: Lecture
Session level: Intermediate

Microservices are Not Worth the Trouble!!??

Session video

Session download

Download the session document here

There is a minimum level of complexity inherit in every system before we write a line of code. By using microservices we cannot reduce this minimum complexity, we can only move it around.

Are we happy to accept that we might achieve reduced complexity in components for increased complexity in orchestration?

Do we understand that complexity in orchestration can be harder to reason with?

I’ve worked on two massive projects with ThoughtWorks that “did the full microservices thing”. There are many benefits trumpeted by the microservices bandwagon but how many of those benefits did we actually deliver and at what cost? Yes we can deploy different parts of the system independently and yes we can, in theory, scale separate parts of the system independently. But do we as a group, in tandem with our clients, have the maturity to really leverage these benefits? How many builds and pipelines are we managing now? We may have achieved bounded contexts and decoupled the parts of our system but how easy is it to reason with the flow of application now that the logic is distributed? I have also worked on a project where the client asked us “deploy it as a microservice” within their main application. Our main goal was to achieve a separately deployable unit to allow us to iterate quickly and deliver value quickly. We did this but without making it a “true” microservice. Taking an outcomes based approach rather than starting with an architectural philosophy can help us to achieve the outcomes we want without incurring the potentially huge costs of a complex distributed architecture. I’ll contrast the experiences of these three projects to explain how we can do this.


I started working in software delivery in the late 1990s when TDD was something you studied but never did and a pipeline was something for carrying oil. In 2005 I joined a startup and started to feel I could really make a difference.

After nearly 10 years, several total rewrites and an Agile transformation I moved on to a career in consultancy with ThoughtWorks. Two and a half years on I’m still learning my trade and being constantly surprised and sometimes delighted.


  • Given that Raymond Van Barneveld, Michael Van Gerwen and Robin Van Persie all got their requisite 3 letter abbrevia… https://t.co/yur4jzRH6U

Speaker Profile