Enough things are wrong win the first paragraphs of this article that I can't be bothered to skim it.
But the attitude that "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" is a naive attitude.
But the attitude that "X that fails at 9/10 companies isn't the problem, we just need to change millions of engineers" is a naive attitude.
There are no silver bullets that can solve this. Only well-designed systems accommodate for the flexibility of human error and hubris can do that.
And even in those 9/10 companies, the failure doesn't even prove that the engineers are the ones unable to create meaningful service boundaries, within a monolith or distributed to multiple services. All of those engineers have bosses and, I don't know what others are seeing, but I feel like I've seen Software Development Manager increasingly become Manager of Software Developers.
I suggest that those same management structures which failed to enable their engineers to create meaningful service boundaries in their monolith, which led to the desire for a cure-all solution, also failed to manage (or protect) their developers such that those developers _could_ turn the existing system architecture into one based on microservices.
Technical leadership has just become increasingly abysmal. Developers are tasked to fulfill user stories but those are often written in a way that completely ignores the technical work required to fulfill such a story. That creates a painful disconnect between expectations and reality, even in 90% CRUD, monolith web apps. Even in a monolith with proper separation of concerns, its easy to imagine one service being the "user" of another service for the purpose of more granular and clear tasks but, "that's not how user stories work." :(
It's even worse than naïve, it's a literal fallacy, a "No true Scotsman" with technology.
System resilience is important at scale, and resilience includes being resilient to the failures in the human component of development; if a system depends that every one developing it to be a master of the underlying foundation then you'll require lots of very specialised, competent people who mastered the technique. That is very costly, if microservices depend on high mastery then we should budget the cost of the talented people required to run it.
My experiences with how to successfully deploy microservices include much the opposite: giving tooling to incompetent people to avoid the worst footguns, training them in best practices over time while designing an architecture that is somewhat resilient to their inevitable failures, one that is easy to be fixed when they've learned how to best use it.
> I understand it’s a harsh title and at times a harsh essay. Such is life. All opinions are my own.
Some takeaways you might have missed:
* Use the right tool for the job - one-tool shops are bound to fail
* (Similar to above) There is a tendency to find _a_ solution rather than the _optimal_ solution
* The engineering halo effect is real and prominent
Then the author goes on to provide some possible solutions:
* Using the SOLID framework for building
* Use services
* KISS
* Developer experience is very important
* Protect your time and your work
* Governance is required to enforce certain principals.
I don't agree with all of these, but they are certainly worth considering.
I did find that lots of people who disliked it, mainly just got put off by the overall tone and the provocative statements from the get go. I basically blame my writing skills (and maybe personality haha). This essay lacks structure and it's more of a stream of thought (sometimes jumping all over the place and going off topic).
I'll just have to live and learn :)
If you're going to make claims that micro-services are failing at 9/10 companies you really should have a source.