Talk: Microservices are Not Worth the Trouble!!??
Speakers directory
Speaker:
jimbobbirnie
Talk description
Title:
Microservices are Not Worth the Trouble!!??
Short synopsis:
In technology we don't always stop to understand the pros and cons of each big new thing. 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 will explain the key tradeoffs that need to be understood before you jump off the microservices cliff.
Max size: 500 chars
Long synopsis (optional):
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.
Max size: 5000 chars
Tags:
Speaker directory:
Listed in directory
Not listed
Speakers directory