3 ms·
I think the hype, groupthink and a propensity to view this as a technical, rather than a largely an economic problem drives people to extremes. I think Martin F
by crdoconnor 9y ago
I think the hype, groupthink and a propensity to view this as a technical, rather than a largely an economic problem drives people to extremes. I think Martin Fowler is largely at fault for that - I think he saw it work really well in his environment, but I think he really didn't understand why.
He was utterly oblivious to the fact that:
* In a different environment with lower coordination costs it is net harmful
* "decoupling" and "microservices" are entirely orthogonal problems and if decoupling is not done while you microservice the shit out of everything your problems are brutally magnified. Tight coupling over network end points is the worst. My time wasted with this problem actually still makes me rage.
Before I worked in a big company I was a MAJOR microservices skeptic because my experience was pretty much just with seeing them grossly misapplied on small teams. Now I am working in a big company I find myself recommending the approach simply because I often see them as a working solution to often extreme people and resource coordination costs that in my previous lives in a small company, simply didn't exist.
I actually kind of shocked myself and had a mini identity crisis when I started doing that. I'm not the microservices guy! I'm the skeptic! Nonetheless, I had that problem and the solution made sense...
In a small company you tend to just have a never ending series of problems, people working at close to peak efficiency and your main problem isn't coordination but just not having enough time, people or resources to solve your problems. The introduction of unnecessary network endpoints everywhere is just going to slow you down and cause problems. If you also have an architect without a deep appreciation of loose coupling that's a recipe for a disastrous rube goldbergesque pile of steaming shit.
In a big company there's often tons of developers all over the place, mostly working very inefficiently and a lot of them will speak different programming languages. Your main problem isn't a lack of resources or time - both are plentiful, it's trying to prevent the rigid and slow moving bureaucracy from preventing you getting anything done and breaking down work into clean chunks so that individuals and teams have enough (but not too much) to work on and the problem gets solved. In that situation a few more network endpoints that are strictly necessary from a technical standpoint is a minor price to pay.
Strictly speaking this isn't 100% a big company / small company thing (my big company environment isn't necessarily like yours) but I'm convinced it's 100% about coordination costs.