28 ms·
I tend to start with a monolithic service. Sooner or later you get a feel for which bits are becoming at least API stable and could run independently. That's w
by cs02rm0 10y ago
I tend to start with a monolithic service.
Sooner or later you get a feel for which bits are becoming at least API stable and could run independently. That's when I split them out.
Do it too soon and you end up choosing the wrong boundaries and tying yourself up in knots, do it too late and your monolith can become a mess that's difficult to detach the pieces of.
- brwr 10y agoTrue. There's another thread in here somewhere talking about premature generalization. I think that's what you're getting at with "Do it too soon and you end up choosing the wrong boundaries".
- api 10y agoI tend to try to write monolithic services in such a way that they could be broken up into microservices if that were ever desired. I don't go too far with this, just avoid things like shared static state and other anti-patterns.
- brwr 10y agoYou mean you follow good software development practices? Heresy!
- hosh 10y agoAnother option is to start with an umbrella app (Erlang/Elixir/OTP). It can run like a monolithic or ... nano-services (I suppose) within the same monolith. When it is time to split them out, it is easier. It does assume that you either start with devs familiar with OTP or you have generalist devs that can pick things up quickly.