4 ms·

> They force you to not share memory on a single system, So instead people use a single SQL database between 20 microservices. > give you scale and failure i

> They force you to not share memory on a single system, So instead people use a single SQL database between 20 microservices. > give you scale and failure isolation, Only if you configure and test them properly, and they actually tend to increase failure and make it harder to isolate its origin (hello distributed tracing) > force you to handle the fact that a called subroutine might fail because it's across a network They don't force that at all. It's good when people do handle that, but often they don't. > I would argue that if you're manually scaling things then you're doing it wrong And I would argue that if people are given a default choice of doing the wrong thing, they will do that wrong thing, until someone forces them not to. Microservices allow people to make hundreds of bad decisions because nobody else can tell if they're making bad decisions unless they audit all of the code. Usually the only people auditing code are the people writing it, and usually they have no special incentive to make the best decisions, they just need to ship a feature.

daotoad 6y ago
If your teams are defaulting to doing the wrong thing in every case, you are having a crisis of leadership. The problem might lie in your technical leadership (e.g. making bad design decisions and failing to learn from experience) or from product leadership (e.g. demanding impossibly short turnaround on work, leading to reliance on solutions that are purely short term focused).
- peterwwillis 6y ago
  Well, I'd answer that with two things 1) good leadership is probably rare, and 2) doing the wrong thing isn't always wrong. In my experience, the best leadership comes from people who don't hyper-focus on one thing, but are constantly thinking about many different things, mostly centered around the customer experience (because that's the whole point of this thing: to make/sell/run a product, not to have perfect software craftsmanship). I find those people rare and usually not working at lower levels of a product. In a sense, doing the wrong thing is perfectly fine if you don't need to be doing the right thing to provide a great customer experience. Of course maintainability, availability, recoverability, extensibility, etc are all necessary considerations, but even within these you can often do the wrong thing and still be fine. I have seen some truly ugly stuff in production yet the customers seemed happy. (though there were probably some chronically sleepless engineers keeping it alive, which sucks and shouldn't happen) I don't like microservices because of how poorly they're usually implemented by default. But at the same time, even poorly implemented microservices give some great benefits (more rapid/agile work, reusability, separation of concerns, BU independence), even if you're struggling against some harmful aspects.

daotoad 6y ago

If your teams are defaulting to doing the wrong thing in every case, you are having a crisis of leadership. The problem might lie in your technical leadership (e.g. making bad design decisions and failing to learn from experience) or from product leadership (e.g. demanding impossibly short turnaround on work, leading to reliance on solutions that are purely short term focused).

peterwwillis 6y ago
Well, I'd answer that with two things 1) good leadership is probably rare, and 2) doing the wrong thing isn't always wrong. In my experience, the best leadership comes from people who don't hyper-focus on one thing, but are constantly thinking about many different things, mostly centered around the customer experience (because that's the whole point of this thing: to make/sell/run a product, not to have perfect software craftsmanship). I find those people rare and usually not working at lower levels of a product. In a sense, doing the wrong thing is perfectly fine if you don't need to be doing the right thing to provide a great customer experience. Of course maintainability, availability, recoverability, extensibility, etc are all necessary considerations, but even within these you can often do the wrong thing and still be fine. I have seen some truly ugly stuff in production yet the customers seemed happy. (though there were probably some chronically sleepless engineers keeping it alive, which sucks and shouldn't happen) I don't like microservices because of how poorly they're usually implemented by default. But at the same time, even poorly implemented microservices give some great benefits (more rapid/agile work, reusability, separation of concerns, BU independence), even if you're struggling against some harmful aspects.