|
Having built many, large, scalable systems, I would like to make a finer point: I agree that microservices are not better than monoliths. I also claim that monoliths are not better than microservices. When implementing any architecture, the are a lot of confounding issues going to in the choices, including things like: what are the skills of the team, what are the SLA expectations, what hardware resources are available, what are the comfort levels for alternatives, what is the comfort level of retooling, what are the process audit requirements, what are the maintenance costs, what is the black-bus factor, so on and so forth. Architecture is about addressing needs, not building software in the "hey, this is the current fad, so let's do it." Although, for some companies, that is actually a design feature. "Hey, react.js developers, come here!" I've seen microservices that fail to scale because the entire thing was written with synchronous/single-queue calls. The biggest reason for writing a microservice is the guarantee I can prove that nothing has changed. If your authorization/authentication API is separate and proved out, I can deploy my application without concern for backdoors getting (accidentally or intentionally) into the code. I always remember: "No code is easier to verify for correctness than no code." I always cringe when I hear "kill X before it kills you" or "x is considered harmful." What will kill any project is failing to understand and appreciate the implications for the design decisions. |