> the things you described aren't exactly novel programming concepts unique to or invented by microservices. I don't think anyone has ever claimed novelty in m

> the things you described aren't exactly novel programming concepts unique to or invented by microservices. I don't think anyone has ever claimed novelty in microservice architecture. It's very clearly derivative. Shared state is moved. You get some level of isolation simply from the fact that there are two distinct pieces of hardware operating on state. You can then move state to another piece of hardware, and share that state between services (somewhat discouraged), but this is a much more explicit and heavy lift than just calling a function with an implicitly mutable variable, or sharing a memory space, file system, etc. > But can't you just as easily argue they weren't creating a proper "monolith" to begin with? Maybe. You can say this about anything - there's no science to any of this. I could say functional programming leads to better code than oop, but I couldn't really prove it, and certainly you can still do crazy bad garbage coding things with FP languages. But I would argue that the patterns that make up microservice architecture can help you make bad things look bad and good things look good. It's not magic fairy dust that you can just use to make your project "better" by some metric, but no one informed would ever claim so.