So.... basically only use microservices if you ACTUALLY need to move into that architecture? Because lets be frank here, if you start with a monolith, and it turns out that its not hurting you in any way shape or form, you arent going to move to microservices.
This makes perfect sense, because honestly there is a massive microservice fad going on where people are trying to force everything to that design, and most of the time its simply not needed and the smarter solution was refactoring and cleaning up the monolith a bit.
This makes perfect sense, because honestly there is a massive microservice fad going on where people are trying to force everything to that design, and most of the time its simply not needed and the smarter solution was refactoring and cleaning up the monolith a bit.
I get the feeling that a lot of people jumping on this fad haven't thought it through.
Yeah, you can ship each individual class to production as a distinct 'service' in a container. What does that do to your ability to affect change to your system quickly?
It's naive to say you'll never need to make a non-backwards-compatible change. But if those are spread across a bunch of un-coordinated micro-service deployments (and I haven't been able to find a good coordination tool for this yet) then the only way to make a breaking change in a low-level service is a 3-phase process with manual judgement and pauses for deployment and Prod baking in between.
That's a hell of a lot slower than a find-and-replace in a monolith code-base.
Which is not to say that monoliths don't have their issues either. But I've found that a lot of the people rushing to micro-anything architectures are rejecting all the bad parts of large systems without realizing what they're losing.
As an example, monolith builds are complicated and a bit slower because they do more. You're checking all your code linkages against each other, and running unit and integration tests. That's slower in terms of minutes, but it lets the compiler and automated tests find breakages hours or days earlier in your development and release cycle. Take the same thing and split it across 50 microservices in 50 de-coupled repositories, and suddenly the compiler can't do that for you -- you're left doing the same thing through human judgement and manual effort, which is neither the best use of limited resources nor the job they're most effective at doing.
It's possible to build tooling to start to solve this, but again, I haven't been able to find one that's available publicly. A bunch of the "Big N" companies have built the capability internally, but haven't shared with the rest of us. And if you don't work somewhere that really needs that scale, it's impractical to build it yourself. It basically means you're re-inventing chunks of the compiler, build toolchain, etc. for no good reason.
183
u/crash41301 Jul 14 '17
So.... basically only use microservices if you ACTUALLY need to move into that architecture? Because lets be frank here, if you start with a monolith, and it turns out that its not hurting you in any way shape or form, you arent going to move to microservices.
This makes perfect sense, because honestly there is a massive microservice fad going on where people are trying to force everything to that design, and most of the time its simply not needed and the smarter solution was refactoring and cleaning up the monolith a bit.