> If you need more resources, buy a bigger system and scale up, not out. Only consider scaling out when you have exhausted scaling up.
This happens at all sorts of companies that are not FAANGs, and don't have "insane scale". There's an extremely large spectrum between the web site for Joe's Coffee Bar and Amazon. On commodity hardware, you hit issues with scaling up a monolith long before you reach FAANG level or "insane scale".
I've worked with multiple startups that have hit scaling limits with their monoliths. Inevitably, dealing with that is a huge problem because the monolith was developed with few resources under heavy time pressure. Modularity is lacking, breaking it up is difficult. Individual devs are often inclined to say that's just a skill issue, and that may have some truth to it, but managing those skill issues is a big part of what corporate software development is about.
This can have a huge impact on a company's funding, ability to deliver new features, ability to scale development, and of course ability to scale the user base. Typically, by the time they hit that wall, scaling the monolith horizontally is not a great option, because it wasn't designed to support that.
It's often been observed that microservices are a primarily an organizational tool, and that's true. But organization is critical if you have multiple development teams.
That doesn't necessarily mean every app should consist of hundreds of tiny microservices. But there can be enormous benefits from implementing an app from the start as independent services based on its natural divisions between modules.
Without knowing what the cause of those scaling problems were (CPU, memory, IOPS, etc.), I’ll have to take your word for it. But having worked at several startups, I can say that it’s a common disease that engineers start to optimize for the “we’re going to have a jillion customers” case long before they even have one customer, and that adds a whole bunch of complexity, cost, and schedule to the development, which increases burn and stands between the company and its cash-flow positive date. In fact, if it forces another round of funding, it can wash out the original employees or even kill the company. On the other hand, it’s easy to raise money when you have customers and are near cash flow positive. You can do a HUGE amount with a modern server with 100+ cores, TB of RAM, etc. IOPS are the one thing which hasn’t scaled quite as well. So yea, I’m being a bit hyperbolic in saying you need to be a FANG to consider it, but I think the main point still stands: most applications, if well-written, can be run well on today’s hardware and scaled up if they need it while eliminating most of the complexity associated with scaling out. Yes, there are exceptions to that rule of thumb.
This happens at all sorts of companies that are not FAANGs, and don't have "insane scale". There's an extremely large spectrum between the web site for Joe's Coffee Bar and Amazon. On commodity hardware, you hit issues with scaling up a monolith long before you reach FAANG level or "insane scale".
I've worked with multiple startups that have hit scaling limits with their monoliths. Inevitably, dealing with that is a huge problem because the monolith was developed with few resources under heavy time pressure. Modularity is lacking, breaking it up is difficult. Individual devs are often inclined to say that's just a skill issue, and that may have some truth to it, but managing those skill issues is a big part of what corporate software development is about.
This can have a huge impact on a company's funding, ability to deliver new features, ability to scale development, and of course ability to scale the user base. Typically, by the time they hit that wall, scaling the monolith horizontally is not a great option, because it wasn't designed to support that.
It's often been observed that microservices are a primarily an organizational tool, and that's true. But organization is critical if you have multiple development teams.
That doesn't necessarily mean every app should consist of hundreds of tiny microservices. But there can be enormous benefits from implementing an app from the start as independent services based on its natural divisions between modules.