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?

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.

Les conférences Tech du web2day avec ENI

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?

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.

Les conférences Tech du web2day avec ENI