Avoid The Microservice Fallacy
February 5, 2018
dddbrisbane
microservice
monolith
opinion
Last year I had the pleasure of speaking at the DDD conference here in Brisbane. It was a really good experience and I enjoyed doing the talk a lot. One of the great things about the DDD conference is the engagement of the audience and community and thus the amount of feedback you get as a speaker. A lot of the comments I got were really positive which I obviously appreciate immensely. But I also got quite a lot of good suggestions on things to improve, like;
An engaging talk, but didn’t come away with much of a plan to improve my own software projects - Maybe more concrete examples?
Some of the comments were a bit more challenging both with regards to the topic but also regarding my stance. And I’ll admit that the title of the talk had a bit of click-bait to it, but hey votes are necessary to get the talk accepted. For example, a comment like this;
A whole lot of straw man arguments - More balance. Less click bait
makes me want to elaborate a bit on the message I wanted to get through. First of all, it is important for me to stress that it was not my intention to state that microservices are always a bad thing or a thing to be avoided by all means - In fact, as a developer, I would love to work on a system built around microservices. Nor was it my intention to advocate that a monolith approach is always the best thing. I intended this talk to be a word of caution. A talk to make you think about the cost associated with a microservices architecture and to recognise that some of these costs are often not advertised or just neglected. But most importantly I wanted to highlight that the most important thing to consider when designing software is to solve the actual business problem and to make sure that technology choices are always justified as solving real business problems.
Anyway if you want to see for your self, the talk was recorded thanks to ssw tv and you can watch it here.
Thanks for reading and let me know what you think.