3 ms·
I think more startups need to consider building monoliths first. Micro-service architecture definitely has the advantage at scale, but the advantage of monolit
by jacurtis 4y ago
I think more startups need to consider building monoliths first.
Micro-service architecture definitely has the advantage at scale, but the advantage of monoliths is the speed that you can build and improve them. Microservices require much more planning and architecture discussions compared to monoliths.
Microservices also can have incredible performance improvements over monoliths (being able to scale or tailor each micro service to its' specific needs as opposed to "on size fits all" of monoliths). So yes they can be right-sized in your cloud easier and have tailored performance, but it comes at the complexity of the deployment and management of the system. By comparison monoliths can sometimes be managed without a dedicated SRE/DevOps/CloudEngineering team.
Monoliths tend to be cheaper to deploy (up to a certain point).
Startups should consider building on monoliths more often. For proof of concept and MVP tools, monoliths are the way to go. Solo developers also are much better served with monoliths compared to micro services. But I will say, eventually if you scale big enough it will eventually make sense to leave monoliths behind and move towards micro services. Yes there are exceptions (someone will write, "but XYZ company is worth 9 gajillion dollars and runs on a monolith), but generally speaking I consider starting with a monolith and moving to micro services after you hit market acceptance for your product.
- mirekrusin 4y agoThey are better at scale (hundreds of developers or machines needed to run the system). They are better at avoiding downtime during deployments because everything is built around supporting it - but at huge cost. Offline migrations - which may be taking just seconds/minutes - are so much easier to do. We're talking about order of magnitude difference in complexity of adding new features. In typescript world, monorepo with shared packages where some are dockerized services (all under same monorepo wide version) is more than enough for most projects. Microservice crowd will call it monolith (because services can't be deployed independently, they likely share SQL database etc), but it's a set of services. You can run it from docker/swarm/k8s - scalability is not really a problem here until you're HUGE (hundreds of developers or hundreds of machines to deploy to). Refactoring, adding new features, dropping stuff etc. - is all easy, usually type checker will guide you to all places that need changing. Single set of migrations. Straight forward e2e. Fast local development where you can spin the whole thing etc. Why people like to complicate their lives when they have this?
- bvrmn 4y ago> Microservices also can have incredible performance improvements over monoliths At this point it's like "Mongo is Web scale" meme. It's so false on so many levels without a proper context. Not surprising inexperienced devs starting use microservices for "pet shops", because "microservises are fast" and failing miserably.