A microservice seems to be just another level of abstraction. They follow in line from functions, to classes, modules, packages, and libraries. It's just the next higher level of abstraction, this time separated by network calls.
The positive side of microservies is that they can be scaled and updated independently. The inherit downside is that adding network calls can add race conditions and failure states.
However, the real trouble with microservices starts when they are misused. If service A calls to service B which calls to service C, which in turn modifies the state of service A, you can easily enter a world of pain. This type of behavior can happen with any abstraction (e.g., functions, classes, modules), but unfortunately, it is very easy to do with microservices, and happens all the time.
I do like the idea of separating truly independent services for scaling, but today we still need a better way to enforce or clarify that separation so that these types of dangerous dependencies don't creep up.
Just spit-balling here, but this type of dependency enforcement could happen at the container or container orchestration level. Perhaps Docker or kubernetes could prevent a service from accessing a resource if another upstream service accessed that same service.
If you need two services that talk to each other to also read and write to another service, you aren't really building microservices, you're building a distributed system.
The positive side of microservies is that they can be scaled and updated independently. The inherit downside is that adding network calls can add race conditions and failure states.
However, the real trouble with microservices starts when they are misused. If service A calls to service B which calls to service C, which in turn modifies the state of service A, you can easily enter a world of pain. This type of behavior can happen with any abstraction (e.g., functions, classes, modules), but unfortunately, it is very easy to do with microservices, and happens all the time.
I do like the idea of separating truly independent services for scaling, but today we still need a better way to enforce or clarify that separation so that these types of dangerous dependencies don't creep up.
Just spit-balling here, but this type of dependency enforcement could happen at the container or container orchestration level. Perhaps Docker or kubernetes could prevent a service from accessing a resource if another upstream service accessed that same service.
If you need two services that talk to each other to also read and write to another service, you aren't really building microservices, you're building a distributed system.