3 ms·
No one had to invent the monolith or define how far it should go; it was the default. Microservices came about because companies kept falling into the same tra
by lostcolony 5y ago
No one had to invent the monolith or define how far it should go; it was the default.
Microservices came about because companies kept falling into the same trap - that because the code base was shared, and because organizational pressures mean features > tech debt, always, there was always pressure to write spaghetti code rather than to refactor and properly encapsulate. That doesn't mean it couldn't be done, it just meant it was always a matter of time before the business needs meant spaghetti.
Microservices, on the other hand, promises enforced separation, which sounds like a good idea once you've been bitten by the pressures of the former. You -can't- fall into spaghetti. What it fails to account for, of course, is the increased operational overhead of deploying all those services and keeping them playing nicely with each other. That's not to say there aren't some actual benefits to them, too (language agnostic, faults can sometimes be isolated), but the purported benefits tend to be exaggerated, especially compared to "a monolith if we just had proper business controls to prevent engineers from feeling like they had to write kluges to deliver features in time".
- Lhiw 5y ago> organizational pressures mean features > tech debt, always I wish. Our organisation focuses on building libraries and frameworks. Literally every solution is a new library. Products take months to ship because you have to either make a new version of a library because the old version wasnt really expecting to work with your needs, or you need to refactor your existing libraries to work with new needs, that takes months of refactoring all the usage points. It's nuts. I tried to build a completely new thing recently, got told to build a library. My thing is pretty specific, doesn't need a library, and will just be single use. It will consume lots of libraries. Would have taken about a week to ship. Instead, here we are week 4 still figuring out how to make this pile of shit work. Sometimes I wish people would just build abstractions on top of what we have. Not everything needs to be a library, sometimes, your new product code is all you need to solve a problem.
- spc476 5y agoThe individual code bases of a microservice might not involve spaghetti code, but the interconnections certain can. I'm looking at a diagram of the service I work on, with seven components (written in three languages), five databases, 25 internal connections, two external interfaces, and three connections to outside databases, all cross-wired (via 6 connections) with a similar setup geographically elsewhere in case we need to cut over. And that's the simplified diagram, not showing the number of individual instances of each component running. There is clear separation of concerns among all the components, but it's the interconnections between them that take a while to pick up on.
- lostcolony 5y agoFair; I should have been more explicit - your code can't fall into spaghetti (since the services are so small). Of course, you're just moving that complexity into the infrastructure, where, yeah, you still have the same complexity and the same pressures.