3 ms·
> With microservices, though, you can make changes one service at a time. That's the main property that sets microservices apart from mere SOAs: Microservices
by BjoernKW 8y ago
> With microservices, though, you can make changes one service at a time.
That's the main property that sets microservices apart from mere SOAs: Microservices reduce the risk of change.
With properly architected microservices a single deployment is unlikely to impair an application as a whole whereas with traditional monolithic deployments a single change can severely affect the functionality and operations of an application.
This is also why you probably don't need microservices if you don't need that kind of fine-grained control and risk mitigation.
- bni 8y agoBut often you will end up with a critical service, like for example the service responsible for the order database. Breakage in this one will impact the system as a whole.
- BjoernKW 8y agoThis in turn might point to the services not being cut alongside the right dimensions, that is they might be cut horizontally rather than vertically. Microservices lend themselves to being used in conjunction with domain-driven design. A single microservice should only deal with one domain. If you have a service that covers cross-cutting concerns such as orders that service is not a microservice. In order to improve the design in your case each microservice could access and manipulate order data according to its scope. That way, if one of the services fails only the small part of the order functionality implemented by that service will fail while the remaining order features will remain intact (to some extent; steps in a linear order process that depend on each other of course will still fail without successful outcomes from previous steps).