3 ms·

(Almost) Everything is "possible" - but looks pretty inefficient to do this. So are MS relevant/appropriate when you are trying to push stuff through the door a

• williamdclt 6y ago
  Inefficient as in slow? Yes it is (slower than a JOIN, of course), this is explicitely a migration strategy to move from a MS architecture to a monolithic architecture. The alternative is a big-bang migration, which is a much bigger risk. > So are MS relevant/appropriate when you are trying to push stuff through the door [...] That really wasn't my argument, I was highlighting that it's possible to do a progressive migration from MS to monolith, I was not making an argument that one is "better" than the other. To answer this question though: no. A MS architecture will probably give slower responses than the equivalent monolithic architecture (multiple DB lookups, inter-service comms), but that's just one element in the balance (and rarely the most important one, it's rarely important whether you get a response in 100ms or 200ms). I'm not going to go into "why microservices", there's plenty of litterature about it on the internet by people that know much more than me. A decoupled monolith is _harder_ to achieve than decoupled services. Services are decoupled because they have to. It's perfectly normal to go from "ball of mud monolith" -> "decoupled services" -> "decoupled monolith". These transitions do not _need_ to happen either, they're just perfectly okay