Software Basics #2 - How Infrastructure Became Invisible

From Bare Metal to SaaS: The Evolution of Infra for Investors and Founders

As mentioned in Series #1, launching a startup meant ordering physical servers, wiring them in a closet, and praying the power wouldn’t cut out. Infrastructure wasn’t abstract — it was metal. You bought it, installed it, managed it.

But in less than two decades, the cost and complexity of infrastructure collapsed — and so did the barriers to entry. What used to take a million dollars and a data center now takes a credit card + GitHub account.

This isn’t just a technical shift,  it’s a transformation in who gets to build what. Infrastructure used to be a barrier. Now it’s leverage. And if you’re investing in or working around tech companies, you need to understand how that leverage works.

Let’s rewind for a second. In the early 2000s, infrastructure meant real estate. If your app got popular, you had to rack more servers. If you misjudged demand, you burned money or crashed.

Then came Amazon Web Services (AWS). It changed everything ,  not by offering something brand new, but by slicing up the old model and selling it in pieces.

Image Credit: blogshub.co.in

Basically:

• Need a place to host files? Use S3 (Simple Storage Service) — a pay-as-you-go file cabinet in the cloud.

• Need a place to run your app’s backend logic? Use EC2 (Elastic Compute Cloud) — rentable virtual machines you can scale up or down as needed.

• Need a database without managing it yourself? Use RDS (Relational Database Service) — a fully managed SQL database with backups, security, and scaling built in.

• Need a custom domain and want to direct users to your app? Use Route 53 — AWS’s DNS service that connects domain names (like yourapp.com) to the actual servers hosting your app.

Together, these services turned infrastructure into Lego blocks: composable + flexible + and massively cheaper than buying hardware. And because AWS (and its competitors like Google Cloud and Azure) take care of the messy stuff — security patches, failover, backups — startups could move faster without hiring a huge ops team.

Why This Shift Mattered: From Scarcity to Overload

So the walls came down. Servers became APIs. Infrastructure turned from a blocker into a launchpad.

But with that freedom came something else: choice overload.

Today, there’s a tool for everything. Hosting, logging, payments, authentication, machine learning, analytics — all available as plug-and-play APIs or micro services. Need file storage? You’ll hear about S3, Cloudflare R2, Google Cloud Storage. Need a database? People will toss around Postgres, DynamoDB, Supabase, Firebase…

If you’re new to this world, it’s easy to feel behind. As if there’s a list of 500 services we should memorize before we’re “technical enough” to follow.

We don’t.

The goal isn’t to memorize acronyms — it’s to see the structure underneath. All of these tools are just variations on a few core questions:

· Where does your code run?

· Where does your data live?

· How does your product talk to the outside world?

· What do you build, and what do you rent?

From IaaS to -> PaaS to -> SaaS: The Climb Up the Abstraction Ladder

Once you understand the cloud, the next leap is realizing just how far abstraction has gone.

Once cloud infrastructure took off, something fascinating happened: developers started outsourcing not just the hardware, but the setup. The boring, messy middle layers — the kind that didn’t differentiate your business but still ate your time.

That’s where the abstraction ladder begins.

🪜 Step 1: Infrastructure-as-a-Service (IaaS) — Early 2000s

This is where cloud really began. Around 2006, AWS launched EC2 — letting developers rent virtual machines on-demand. Suddenly, you didn’t need to buy servers or wire your own data center.

But EC2 gave you a bare-bones machine. You still had to install the OS, configure security, manage dependencies, and monitor uptime. It was still a lot of work — just no longer done in your garage.

🧠 Analogy: IaaS is like renting an empty apartment. You don’t build the walls, but you still have to bring in your own bed, fridge, router, and heating system.Think of IaaS like renting a raw apartment. You get the keys and the empty space, but furnishing it — plumbing, heating, furniture — is on you.

🏗️ Step 2: Platform-as-a-Service (PaaS) — Late 2000s to Early 2010s

Then came the next layer of abstraction.

In 2007, a tool called Heroku launched, letting developers push their code to production with just a few commands. No manual configuration. No server headaches. You write code, Heroku runs it. It was a game-changer — especially for early-stage startups or solo builders.

Heroku automatically:

• Created a server

• Installed the runtime

• Scaled the app up/down based on traffic

• Gave you built-in logs, deployment previews, and rollbacks

It abstracted away the whole DevOps layer. You just focused on your code.

In 2011, Firebase was born. It took PaaS even further. Firebase didn’t just host your app — it gave you a backend in a box. Realtime database? Authentication? File storage? All there, pre-built. Plug-and-play backend. No servers, no ops team, no stress.

It gave:

• Realtime Database (users could see updates instantly)

• Authentication (sign up/log in with Google, Twitter, etc.)

• Storage (upload files/images)

• Hosting (static website files)

• Analytics + Notifications

🧠 Analogy: PaaS is like moving into a fully furnished apartment. The electricity works. The WiFi’s ready. The couch is already there. You just bring your suitcase.

So, PaaS = Abstraction + Speed

• Heroku = Code runner + app host

• Firebase = Full backend in a box

Both let you ship faster, without worrying about infrastructure.

⚙️ Step 3: Software-as-a-Service (SaaS) — 2010s to Today

Once infrastructure and backend logic got abstracted away, the next question became:

Why build it at all if someone else already has?

This is where SaaS started to shape modern startups — not just as tools, but as a philosophy of building.

SaaS: Renting Brains, Not Just Machines

By the mid-2010s, teams weren’t just renting servers or platforms. They were renting complete functionality — prebuilt, battle-tested, and delivered through a browser.

You don’t build your own CRM — you use Salesforce or HubSpot.

You don’t run your own email infrastructure — you use SendGrid or Mailchimp.

You don’t code your own helpdesk — you plug in Zendesk or Intercom.

🧠 Analogy: If PaaS is a fully furnished apartment, SaaS is room service. You don’t even cook — you just order what you need.

This allowed teams to ship faster, stay leaner, and focus on what made their product special — not on reinventing wheels.

Image Credit: jagoanhosting.com

👀 Seeing the Stack Like an Expert

By now, we’ve seen how startups moved from managing metal servers to plugging into abstracted layers — infrastructure, platform, and software delivered as a service.

But what does that shift really mean?

For a generalist, SaaS might seem like the whole story. A clean UI, a monthly fee, a solved problem.

However, SaaS is just the surface.

What they see is a chain of services stacked underneath — and what they think about is tradeoffs.

• Are they deploying on Heroku or Vercel? That’s platform-as-a-service — fast to ship, but less flexible.

• Are they storing files in S3? That’s infrastructure-as-a-service — more control, more complexity.

• Are they building their own backend auth? Or using Firebase, which handles it all out of the box?

This isn’t just trivia. These decisions shape how fast the team can iterate, how expensive scale becomes, and how easy it is to hire engineers down the line.

So when a technical person hears “SaaS,” they’re not just thinking about what it does — they’re thinking about how it’s built.

And if you’re trying to understand a startup’s potential, or evaluate a pitch, or just speak the same language as the builder in the room — this is the x-ray vision you need.

👣 Where to Go From Here

If this feels like a lot — that’s because it is. The modern stack is powerful, flexible, and overwhelming. You don’t need to memorize every tool or acronym. You just need a working map.

That’s the whole point of this series: to help you see the map, not get lost in the terrain.

💬 Let’s Talk

If you have questions, confusion, or ideas you want me to unpack in future pieces — leave a comment or message me on LinkedIn. This whole thing works better when it’s two-way.