4 ms·

>Yes, microservices and containers are a way for developers to feel important and grant cover to an unabashed manifestation of Conway's Law. Microservices are

>Yes, microservices and containers are a way for developers to feel important and grant cover to an unabashed manifestation of Conway's Law. Microservices are a more sensible idea in big companies because they can be used (provided you have a sane architect) to create fairly easy to use abstractions that code in any language can use. Where communication and coordination costs are very high but there's lots of resources and programmers (of varying flavors) available it makes sense. Within individual teams and particularly in small companies, where communication and coordination costs are very low and there are not a lot of people or resources available, "microservicing" everything is a brain dead idea. Introducing a network endpoint does not necessarily decouple things any better than a function interface would and it imposes complications and costs that a function interface doesn't.

cookiecaper 9y ago
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.

cookiecaper 9y ago

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.