Re:Microservices Architecture on Google Cloud
by KronisLV on Monday November 22, 2021 @02:57AM
(#29303945)
> Adding more services introduces more complexity in the deployment architecture as well.
This is true, but having multiple services or even instances that can horizontally scale gives you more leeway as far as resiliency against errors goes. For example, the issues in the monolith at my current day job could have a way lower priority/impact, if they didn't risk bringing down the entire application should the application server/instance fail - instead, if there were N instances, the load could just be handled by the other instances.
Of course, if you actually have the operational capacity to support microservices, that may be a good investment in some particular systems - if a part of the whole system would start to misbehave, its impact could be far more limited, for example, due to resource constraints or rate limits that should be in place. Monitoring could also become somewhat easier and you could figure out where any problem lies, except for the most complex Byzantine failures.
> I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the monolith is muliple times easier mostly depending on the code structure.
However, where monoliths fail in my eyes, is the strong coupling. For example, i currently need to migrate the very same monolith to far newer frameworks and runtimes, which is essentially impossible to ship, because a large number of edge cases and specific functionality all break when this is done.
So instead of being able to ship the parts that'd work (say, the RESTful API and the front end), i'm blocked by the things that don't work (report functionality, PDF functionality, file handling functionality, database migration functionality), so for approx. the past month it has probably looked like i'm not generating much business value, due to struggling with all of this. I wrote more about the problems with this here on HN: https://news.ycombinator.com/item?id=29204841
This is true, but having multiple services or even instances that can horizontally scale gives you more leeway as far as resiliency against errors goes. For example, the issues in the monolith at my current day job could have a way lower priority/impact, if they didn't risk bringing down the entire application should the application server/instance fail - instead, if there were N instances, the load could just be handled by the other instances.
Actually, one of my first blog posts talks about how scalable and modular monoliths might be a way to leverage the best of both worlds: https://blog.kronis.dev/articles/modulith-because-we-need-to...
Of course, if you actually have the operational capacity to support microservices, that may be a good investment in some particular systems - if a part of the whole system would start to misbehave, its impact could be far more limited, for example, due to resource constraints or rate limits that should be in place. Monitoring could also become somewhat easier and you could figure out where any problem lies, except for the most complex Byzantine failures.
> I have personally worked with Rails application monoliths and Node.js microservices and I can tell you that making changes on the monolith is muliple times easier mostly depending on the code structure.
However, where monoliths fail in my eyes, is the strong coupling. For example, i currently need to migrate the very same monolith to far newer frameworks and runtimes, which is essentially impossible to ship, because a large number of edge cases and specific functionality all break when this is done.
So instead of being able to ship the parts that'd work (say, the RESTful API and the front end), i'm blocked by the things that don't work (report functionality, PDF functionality, file handling functionality, database migration functionality), so for approx. the past month it has probably looked like i'm not generating much business value, due to struggling with all of this. I wrote more about the problems with this here on HN: https://news.ycombinator.com/item?id=29204841