3 ms·
> We are considering moving the micro service hell into a more monolith architecture vs. something new. Why?
by connordoner 4y ago
> We are considering moving the micro service hell into a more monolith architecture vs. something new.
Why?
- naiv 4y agoTo add one new property to an existing entity we need to currently update and deploy 5 services multiplied by review / testing / acceptance / production environments plus the api client and sometimes the messages depending on what kind of field it is. So it takes 3-5 hours instead of 20-30 minutes. This pretty much sums up our current situation: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- Jtsummers 4y agoNot a total defense of microservices, but that's also a problem with just improper modular code (apparent tight coupling between modules/services and many repetitions). Since you're talking about refactoring, which is a stepwise procedure, an early step can be identifying things like these repetitions and consolidating them into a single (or single set) of modules which are referenced by the multiple services. This doesn't fix the deployment problem (needing to redeploy multiple services for a single change), but it can address the code change problem. This also sets you on the path to a monolith if that's what makes sense for your system or organization in the future since your code will become more consolidated with this process over time. But you can avoid committing to a monolith earlier than necessary, you may find multiple services (micro or mega) are appropriate as you start cleaning up the system.