Let’s start with the most spot-on comic of Hilbert.
I’ve personally seen various cases as this comic. In real companies. For real production flows. From real people.
This entire discussion about monolith vs microservices feels the same for me. The same as the discussion about cloud vs on-prem, Rust vs Go, red vs blue…
What we read is biased
Every blog, even this one, is biased. Because I have my set of experiences gained over the years, it does not mean I have covered every aspect of IT. Not even speaking over the aspect that comes with company politics, architecture, people in general and the list goes on.
Even when I want to be 100% objective, I’m never going to be objective. I need some knowledge to write something. By having that set of knowledge, I’m biased per default. So many things I do and write might not be useful for someone else, even though I might be “right” or “correct”. I could write that I really love Golang, but if your company has 40 Java developers, why would you pick Go for the next project. Such a decision should be based on way more factors right?
Yet by just saying “I got 40 Java developers, I’m not switching ever” is also quite a wrong thought. Just because you have it, does not mean it is the long-term solution. It is a really fair call to let people be more freely on their programming language. Especially if:
- You have motivated people, willing to change
- It helps your business, future projects
- There is room to learn
- Other languages provide so much more gains on your projects
A really nice blog post is from Discord. They “changed” from Golang to rust. Please have a read here: https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
Personally, it’s cool to read about the tech, but more importantly about their team. They managed to have the freedom and expertise to just switch a programming language because it helped them so much. That’s the hardest thing to do. Not the tech itself.
So, what is your company like?
In most cases, I really wonder what your company is like. If you ever have a discussion about monolith vs microservices, think about how everything else runs in the company.
I would really dislike using microservices if we are rolling out updates with FTP on 100 static servers…by hand. Why would you even have a discussion about something, if got numerous other problems (*cough* challenges)?
But there are so many more things to think about. How is the staff? Do you have quite some experience in house and enough FTE’s? Are people eager for change? Do you actually have a sensible reason to switch things? Other than you read a blog from a tech company that has 100 senior developers? 🙂
The ups and downs
Both “solutions” have their ups and downs. Currently, we see a movement of people moving back from microservices to a somewhat monolith approach. This has nothing to do with microservices being bad or visa-versa.
Some things just work better in a different way. Mistakes are cool if you learn from it.
What bothers me is that we are having discussions about what others are doing. “Company X moves to a monolith approach” – PANIC. Perhaps we have to rethink everything!
How can you pick something?
I strongly believe is it NOT about the tech. Technologies prove themself. It’s about picking the right tool for the right job. Having the proper support for it in any way possible.
For picking between monolith vs microservices, you should listen to the people who are working with it. Having real experiences with it. Yet think about organizational structure and methods.
- Do you have the proper experience in-house
- And the platform (and therefore people too) for it.
- Is it in line with company methods, or is there room for change?
- Are people eager to change and actually helping each other out?
- And if not, is there room to support them?
- Do you have people or teams that can take the lead
- You’ll sometimes need those to get things rolling.
- Does it even make sense for your applications or future projects
- I.e; don’t just do something because it’s cool. lol
And even then, you might fail
You should be open to failure.
It’s new, perhaps bleeding edge. It’s cool to get the experience that it did not work the way you have planned or expected. But be open for it, be able to discuss that freely and make new changes or revert. It would be a unicum that a technology project/switch went flawlessly in one go.
In most cases, it’s really not about the technology or stack. It’s about people, changes and the company. Nearly anything could work, yet you’ll need the proper backing for it. These transformations are insanely hard to pull-off in one go. It requires changes on multiple levels.