Cloud-Native, IaaS, PaaS and SaaS Explained

Cloud is not a place in the sky. It is the question of how much of the machine you run yourself and how much someone else does.

I work at the intersection of product, GTM and AI as a software entrepreneur. The moment AI agents run inside your product team, this question stops being theory. It decides where your agents work and how fast.

What you take away here:

• What IaaS, PaaS and SaaS actually mean, in one sentence per layer.
• Why the lines between them have long since blurred.
• Why cloud architecture matters when agents run on your side.

My thesis: the three models are three layers of the same stack. You just need to know which one you run yourself.

🧨 Three layers, one stack

The official definition comes from NIST. In daily work, three simple sentences are enough.

IaaS, Infrastructure as a Service. The bottom layer. You rent only the hardware: compute, storage, network, virtualised in a data centre. You install the operating system and everything above it yourself. You rent IT infrastructure and maintenance, nothing else.

PaaS, Platform as a Service. The middle layer. Here it is not the IT administrator who is called upon, but the developer. The provider supplies the environment as a framework and sets the programming languages, interfaces and data storage. You control only your own code and data, not the infrastructure beneath.

SaaS, Software as a Service. The top layer, it builds on the other two. You do not buy the software and you do not install it. You rent it as a service. Usually an internet-capable device and a browser are enough. Cheap hardware on your side, full compute power in the data centre.

An everyday picture helps. IaaS is the bare shell: you rent the walls and fit out everything yourself. PaaS is the equipped workshop: you only bring your own project. SaaS is the finished appliance on subscription: switch it on and use it.

🛠️ Why the lines blur

The clean layer cake is theory. In practice the lines have been blurring for years. Even before Azure offered virtual machines in 2012, it was often no longer clear where IaaS ends and PaaS begins.

Real projects do not ask about the model. They bundle capabilities: an API here, a component there, a service on top. It is not IaaS or PaaS. It is IaaS and PaaS and SaaS, often in the same project. On top of that comes the hybrid approach, which blurs even the line with your own hardware on premises.

At first you still had to explain and justify PaaS. Soon it was only about real development projects. The maturity around hybrid cloud grew year after year. That is where we stand today: not one model, but a mix you assemble on purpose.

On top of that, whole product categories now sit between the layers. Managed databases, container services, serverless functions. All hybrids where the provider takes on more than with raw infrastructure and dictates less than a full platform. The layer model stays useful anyway. It answers the only question that counts: who runs what.

🧭 The decision walk: one company, three answers

Take a B2B software company with 30 people. One product, a small team, no ops department of its own. It makes a good test case for the choice, layer by layer.

Raw infrastructure makes sense when you truly need control. Say your customers contractually dictate where data sits and who has access. Or your product has runtime or hardware requirements standard platforms don't cover. Then you rent machines and run the rest yourself. The price: you need people who can and want to do that. In the 30-person company that quickly means 2 of them doing nothing but infrastructure.

A platform makes sense when your bottleneck is development, not operations. For our company that's the normal case. The team writes code, the platform takes care of servers, scaling and patches underneath. You give up control and get speed back. For a product team without its own ops, that's almost always the right starting point.

Finished software makes sense for everything that doesn't differentiate you. Mail, CRM, the system for your customer data, accounting, the support tool: rent, don't build. The company wins not a single customer because it runs its own ticketing. Every hour there is an hour not spent on the product.

So the decision walk is not a matter of belief. It's one question per system: does this differentiate us? If no, buy as high up the stack as possible. If yes, take as much control as needed and as little self-operation as possible.

For the 30-person company the outcome often looks like this: the product itself on a platform, the database as a managed service, one piece of raw infrastructure for the one customer with special requirements, a dozen rented tools around it. Exactly the mix from the section before. Not a purity rule, but a series of deliberate single decisions.

⚖️ Three trade-offs, in plain words

Behind every layer choice sit the same 3 trade-offs. Know them and you can place any vendor slide within minutes.

Control versus responsibility. Every layer you run yourself obeys you. And it calls you when it fails at night. Control sounds like freedom, what it means is on-call duty. The honest question is not "do we want control" but "do we want the responsibility that comes with it".

Lock-in versus speed. The more finished services you use, the faster you ship. And the deeper you grow into one provider. Switching becomes expensive, not impossible. The mistake is not lock-in itself. The mistake is taking it on unconsciously. Build everything yourself out of fear of lock-in and you pay the price now instead of maybe later.

Fixed cost versus usage cost. Self-operation costs money whether anyone uses your product or not. Usage-based services cost little under little load and grow with your success. For a young product the second is usually better. You only pay a lot once you have customers. In return you need an eye on the bill, because usage costs grow quietly.

The order matters: first decide what differentiates you, then weigh the trade-offs per system. Do it the other way round and you'll debate vendors for weeks and still end up without a line.

🤖 Why this matters in the age of agents

This is exactly where it gets concrete for me. I build AI-native product teams. I call it Get Multiplayer: how people and AI agents work together. A hyperlean team, a few pros plus agents running around the clock. Three instead of thirty.

These agents run somewhere. Whether on IaaS, PaaS or connected as SaaS decides latency, cost and data control. If you have to keep your code, your Jira and your data in the EU, then the layer choice is not a technical question but a compliance question.

For DACH companies this is no footnote. Many B2B customers contractually require data to stay in the EU or in Switzerland. That's the normal case, not the exception. All 3 layers are available with European regions. You just have to check it at selection time instead of repairing it afterwards.

On top of that comes context. An agent is only as good as its foundation. That foundation is the Context Engine: your company's business and code context. Where that context lives and how the agents reach it is a question of cloud architecture. Without clean context it is garbage in, garbage out.

🧑‍💻 What does this mean for a small product team?

Buy everything that doesn't differentiate you as a finished service. Run as little as possible yourself. And decide the layer question before your agents run, not after. Because the architecture determines what your agents can reach and how fast.

This ties back to the point above. Once AI helpers work inside the product, every layer decision counts twice. It determines where your code runs. And it determines whether an agent can reach logs, data and deployments without a human clicking in between.

A small team has an advantage here: little legacy. You can cut the architecture so the context sits in one place and the agents work there. How such a setup comes together in practice is what I show in SaaS product in 90 days and in From Vibe Coding to Agentic Engineering.

The layer question is part of product management, not IT. I collect more on this in the software product management hub.

🎢 Highs, lows, warning

✅ What works: the layers as a mental model. For every service ask: which layer do I run myself, which one does someone else run. That clears up most of the confusion.

❌ What does not work: treating the models as rigid boxes. Reality is mixed, hybrid and blurred. Wait for the clean cake and you plan past practice.

⚠️ Warning: do not let your cloud architecture happen by accident. The moment agents run on your side, it determines speed, cost and where your data sits.

Cloud is not a place in the sky, it is a decision about what you run yourself. In the age of agents that decision gets more important, not less. If you want to put agents in your product team that know your context, take a look at teklens.ai.