[SCdF]

I want to second this.

Reading high scalability and watching talks about how Netflix, Google, Spotify and friends deal with their massive loads can be entertaining, but for the vast vast majority of us it is only that: entertainment.

Google's solution is almost certainly not right for you. Netflix's solution is almost certainly not right for you.

I've never had the distinction to work on a project that large, but I imagine that even if you are this scale their solutions are still not useful, because at that scale and complexity everyone's needs are different.

[kqr]

I don't agree fully. My understanding of the Google level scale is that you are forced to deal in good abstractions. You need to pick the right interface, nothing can ever be responsible for more than one thing, and you need to make things extremely composable. With a foundation like that, you get the ability to model your system using even simpler substitute components, making it possible to reason about behaviour in conditions which are difficult – if not impossible – to actually test.

If the ideas sound familiar, that's because they're basically just good software design. Except if you don't design things well from the start, you have to either kill it off or spend years fixing it.

I think a lot of this could be the exactly right mindset for many of us. Sure, there's something to be said for an MVP, but with some experience in designing composable abstractions, you can create an MVP that scales up to real workloads in half the time of your competitors, who basically have to rebuild their thing from scratch.

[itamarst]

You need to _operate_ your software. The way a company with 10,000 software engineers operates their software is very different than how a company with 5 software engineers does it.

Microservices are the prime example of thing you should never do at small scale. They're a solution to an organizational problem of organizing large teams. Typically each team has a single microservice... and then 5-person companies will go all microservices and support 20 services with one team, and then get confused why it's not going well.