Startups: The Ecosystem and How They're Funded · Part 4 of 19

Why Cloud Computing Transformed Startups

Testing whether anyone wants your product used to require buying servers and renting rack space first.

Before cloud computing was an option, a startup that needed to serve traffic had to buy it: servers, networking equipment, storage, and often space in a physical data center to put all of it, plus the operations staff to keep it running. That spending happened up front, in large chunks, before a single customer had confirmed the product was worth building. If demand came in lower than expected, the company had already spent the money finding that out.

What replaced the old model was a set of changes that, together, removed most of the reason a startup would ever run its own hardware:

• On-demand infrastructure: compute, storage, and networking are available in minutes, against the weeks or months it took to order, ship, and rack physical hardware.
• Consumption pricing: pay for what gets used, so an idea with three users costs close to nothing to keep running while it's being validated.
• Managed services: a database, a queue, or an identity system that would once have needed a specialist to run is available as an API call, with the operator's own team handling patching, failover, and backups.
• Global infrastructure: a startup can serve a customer on another continent without building anything there itself.
• Elastic scaling: capacity can grow or shrink to match demand automatically, instead of being sized in advance for a guess about peak load.
• Developer tooling: infrastructure can be defined, versioned, and reproduced in code, so a small team can operate systems that would once have needed a much larger one.

Together, these are why startups reach for managed services early rather than running things themselves. Every hour spent operating a database is an hour not spent finding out whether the product is worth having a database for, and at the pre-seed or seed stage, that trade favors buying the capability.

The preference comes down to six things, which return whenever a specific architecture decision is on the table: speed, flexibility, technical leverage, operational burden, cost, and risk. A managed service is usually faster to start with, easier to change later, and lets a small team punch above its headcount, at the cost of less control and a dependency on someone else's system staying reliable. Which side of that trade to take depends on the company's current stage and risk profile.

This site's Core Cloud Architecture series picks up from here, walking through the building blocks this trade-off applies to (compute, storage, databases, networking) one at a time, with AWS, GCP, and Azure examples.