Microservices Considered Harmful (2019)
> However, your codebase has now to deal with network and multiple processes.<p>Here's the thing I see repeatedly called out as a negative, but it's a positive!<p>Processes and networks are amazing abstractions. They force you to not share memory on a single system, they encourage you to focus on how you communicate, they give you scale and failure isolation, for force you to handle the fact that a called subroutine might fail because it's across a network.<p>> f your codebase has failed to achieve modularity with tools such as functions and packages, it will not magically succeed by adding network layers and binary boundaries inside it<p>Functions allow shared state, they don't isolate errors. Processes over networks do. That's a massive difference.<p>If you read up on the fundamental papers regarding software reliability this is something that's brought up ad nauseum.<p>> (this might be the reason why the video game industry is still safe from this whole microservice trend).<p>Performance is more complex than this. For a video game system latency might be the dominating criteria. For a data processing service it might be throughput, or the ability to scale up and down. For many, microservices have the performance characteristics that they need, because many tasks are not latency sensitive, or the latency sensitive part can be handled separately.<p>>  would argue that by having to anticipate the traffic for each microservice specifically, we will face more problem because one part of the app can't compensate for another one.<p>I would argue that if you're manually scaling things then you're doing it wrong. Your whole system should grow and shrink has needed.