Let's not forget about the increased complexity on governance you get when migrating to microservices, since instead of a single app in a single server you now have multiple apps on multiple servers. Even though server administration is not a big issue nowadays, the regular app monitoring still needs to be done and is multiplied by quite a lot in this scenario.
Also take in account that "easier to track bugs" might not be the case if the process that caused it triggers multiple events in multiple servers, a situation where usual debugging cannot be used, and you actually need a culture of logging everything in order to actually be able to find the error right away (and a particularly good use case for monitoring tools that centralize all the logs in one place).
It's not my intention to stop people from trying a distributed architecture, these advantages are true, but only mentioning the good parts may lead to some huge disappointments...
Agreed with your perspective. Microservices are very attractive on paper but it also comes with a cost. If you have more than 3 services per developers I think you'll start to see some new pains emerging (testing, monitoring, restoring a new stack, managing dependencies, feature flags...).
I would recommend not diving too far too fast, moving a few isolated components out of the monolith (auth or audit logs can be good candidates) will help understand the new practices to adopt.
There are great benefits to embracing Microservices and I'm a huge proponent of it. Just make sure you go at your own pace, it took Netflix years to get to the level of maturity they have.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Let's not forget about the increased complexity on governance you get when migrating to microservices, since instead of a single app in a single server you now have multiple apps on multiple servers. Even though server administration is not a big issue nowadays, the regular app monitoring still needs to be done and is multiplied by quite a lot in this scenario.
Also take in account that "easier to track bugs" might not be the case if the process that caused it triggers multiple events in multiple servers, a situation where usual debugging cannot be used, and you actually need a culture of logging everything in order to actually be able to find the error right away (and a particularly good use case for monitoring tools that centralize all the logs in one place).
It's not my intention to stop people from trying a distributed architecture, these advantages are true, but only mentioning the good parts may lead to some huge disappointments...
Agreed with your perspective. Microservices are very attractive on paper but it also comes with a cost. If you have more than 3 services per developers I think you'll start to see some new pains emerging (testing, monitoring, restoring a new stack, managing dependencies, feature flags...).
I would recommend not diving too far too fast, moving a few isolated components out of the monolith (auth or audit logs can be good candidates) will help understand the new practices to adopt.
There are great benefits to embracing Microservices and I'm a huge proponent of it. Just make sure you go at your own pace, it took Netflix years to get to the level of maturity they have.