|
|
|
|
|
by indogooner
2891 days ago
|
|
Visibility of benefits depends on how your engineering organization is structured. Once you have a lot of teams working with monoliths becomes very painful. Having independently deployable unit starts making more sense then. Each service owner has to expose APIs for their users and that forces them to think more about how their service is supposed to be used and what problem is it solving. This also gives autonomy to teams in developing/maintaining their services (tech choice/programming language). Services also help in isolation and QoS. For example if you have different services handling order execution and order listing, the service handling execution has to be highly available and responsive while you can be a bit lax with other one. With services you do need to have a good monitoring system in place. Also having ability to trace a request across services is a great boon. Helps in proper communication across teams. These are of course only some of the reasons I could think but one thing should be clear that going Microservices route involves buy-in from the engineering org and a good enough developer population (I feel ~30+ is good to start) |
|