3 ms·

I think the problem is partially in the terminology, which drives people to extremes. What we need are "ReasonableServices" (TM), but it's not such a catchy nam

I think the problem is partially in the terminology, which drives people to extremes. What we need are "ReasonableServices" (TM), but it's not such a catchy name. I've seen several attempts at "microservices" that I like to describe, rather, as "puny-services": weak, random little one-offs that get enlisted as a "service" because whoever needed that function didn't feel like seeing if anyone else had already provided it through a different endpoint, etc. So yes, there is a way to do "microservices" right, provided your understanding of "micro" is sufficiently macro and it doesn't just become an excuse for every little self-selecting group of developers to go off in their own world and ignore everyone and everything they'd rather not worry about all day. But in my experience, it almost always does. If you have a team disciplined and experienced enough to do microservices well, you probably have a team that is dubious of the hype and will just start building reasonable software without worrying about how micro-servicey it is.

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.

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.