3 ms·
I can’t believe it’s news that someone said this. I thought everyone understood: you don’t try to do microservices until you have to. Before you get to that poi
by mullingitover 4y ago
I can’t believe it’s news that someone said this. I thought everyone understood: you don’t try to do microservices until you have to. Before you get to that point you make your monolith modular enough that if you ever need microservices you’re prepared to break them out.
- 8organicbits 4y agoA lot of people are focused on microservices as a way to address scaling (of load, team size, etc.) but there's other reasons to choose a microservice. A pretty basic one is when an existing microservice already does what you need and no suitable module or library exists. In that case, there's no "until". Start with a microservice. There's a number of open source projects that are pluggable microservices, for example.
- mattbillenstein 4y agoThis is not well understood at all - and a lot of frameworks don't really lend to simply splitting a piece off. I've seen terrible spaghetti code apps where literally nothing can be refactored because of the model / view, God object dependency stuff all over the place.
- 0x6c6f6c 4y agoThis is really it. You can have everything in a monolith and scalable and modular by following good architectural practices. If the need arises, you could move into SOA, and break out a couple of your larger domain modules. Continue following these same rules though. If the need arises still, you could move into micro services, and break out more / all of your domain modules. Truly understand first whether you actually need this first. But the "let's do micro services this monolith is old junk" trope, abandonwaring the codebase, building out a bunch of services without strong, fundamental domain knowledge, and then complaining when shit is expensive and fragile and broken- it's getting tiring.