Cloud service models describe how much of the stack the provider runs and how much you run yourself. The three classic models are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Backend as a Service (BaaS). Function as a Service (FaaS) is now common enough to belong in the same comparison. Each model trades flexibility for convenience differently, and the right choice depends on what your team needs to control versus what it would rather hand off.

This guide walks through each model with current 2026 providers, where each fits, and where the limits of the models are pushing toward a newer approach: infrastructure from code.

A Quick Comparison

Model	What you manage	What the provider manages	Best for
IaaS	OS, runtime, app, data	Hardware, virtualization, networking	Custom infra needs, full control
PaaS	App, data	OS, runtime, scaling, deploy pipeline	Standard web apps, fast iteration
BaaS	Frontend, business logic in client	Backend services (auth, db, storage, push)	Mobile and SPA-first products
FaaS	Function code	Runtime, scaling, invocation	Event handlers, glue code, edge compute
IFC	Application code (infra inferred)	Provisioning, scaling, environments	Backends where code is the source of truth

The rest of this guide expands each row.

Infrastructure as a Service (IaaS)

In an IaaS model, you rent virtualized hardware: compute, storage, networking, sometimes operating systems. Everything above that is your responsibility. You pick the OS, install the runtime, configure the database, deploy the app, and patch the kernel.

IaaS Providers

The three hyperscalers dominate: AWS EC2, Google Compute Engine, Microsoft Azure Virtual Machines. Beyond them, Hetzner, DigitalOcean, Linode (Akamai), Vultr, and OVH are credible alternatives, often at much lower prices for similar specs. For comparisons, see AWS vs Azure vs GCP.

Pros and Cons

Pros

• Maximum flexibility. You can run anything that fits on a Linux box.
• No vendor-imposed runtime constraints.
• Cost-efficient at scale once you optimize.

Cons

• High operational burden. You own patches, security, scaling, monitoring.
• Cost predictability is poor. Pay-as-you-go bills can swing without warning.
• Vendor lock-in is real even at this layer; provider-specific networking, IAM, and storage APIs make migrations painful.

When IaaS Fits

Pick IaaS when you have specific infrastructure requirements that don't fit into any platform's box: bare-metal performance, regulatory isolation, custom kernels, GPUs in a particular configuration, or workloads where the cost of a managed platform's overhead is real money. Most teams who choose IaaS as their default end up reinventing PaaS internally; the question to ask is whether that's the work you want to be doing.

Platform as a Service (PaaS)

PaaS abstracts the operating system and runtime. You bring application code, the platform handles building it, deploying it, scaling it, and exposing it on a URL.

PaaS Providers

The PaaS landscape changed substantially in the last few years.

• Vercel dominates frontend and serverless functions, especially for Next.js.
• Railway, Render, and Fly.io are the modern Heroku-shaped PaaS for full-stack and backend apps. See Heroku alternatives in 2026.
• Heroku itself has been hollowed out by Salesforce ownership and the end of its free tier; it's no longer the default it once was.
• Cloudflare Workers, Vercel Edge, and Deno Deploy are edge-first PaaS platforms.
• The hyperscaler-native options (Google App Engine, AWS Elastic Beanstalk, AWS App Runner, Azure App Service) still exist but feel dated next to the modern set. See App Runner alternatives.

Pros and Cons

Pros

• Fast time to production. Push code, get a URL.
• Sensible defaults for scaling, TLS, logs, and rollbacks.
• Lower ops burden than IaaS.

Cons

• The platform's box is the platform's box. Stepping outside it is hard.
• Pricing scales with traffic in ways that can become expensive at growth stage.
• Vendor lock-in, particularly around the deployment model and platform-specific runtime APIs.
• Limited control over infrastructure boundaries that matter for compliance and data residency.

When PaaS Fits

PaaS is the right default for most web applications until you have a specific reason to need more control. The sweet spot is small to medium teams shipping standard HTTP services. The wrong moment to be on PaaS is when you've outgrown its scale tier, hit a feature limit, or started paying more in platform fees than the savings in ops time justify. See Platform as a Service: An Introduction for a deeper look.

Backend as a Service (BaaS)

BaaS goes further than PaaS by providing not just a runtime but a backend: authentication, database, storage, real-time sync, push notifications, all behind a client SDK. The mobile or web frontend talks to the BaaS directly; there's often no application server in between.

BaaS Providers

• Firebase is the original. Owned by Google, integrates Auth, Firestore/Realtime DB, Cloud Functions, Cloud Storage, and Cloud Messaging.
• Supabase is the open-source-flavored alternative built on Postgres. Auth, database, storage, realtime, edge functions.
• Convex focuses on reactive queries and end-to-end type safety with TypeScript.
• Appwrite and Pocketbase are open-source and self-hostable.
• AWS Amplify is Amazon's BaaS umbrella, integrating Cognito, AppSync, DynamoDB, and S3.
• Nhost combines Hasura's GraphQL with auth and storage.

For deeper coverage, see Backend as a Service: What is it?.

Pros and Cons

Pros

• Extremely fast prototyping. Auth, database, storage in an afternoon.
• Zero backend code for many features.
• Real-time and offline-sync features that would be hard to build from scratch.

Cons

• Vendor lock-in is severe. Migrating off a BaaS is closer to a rewrite than a port. Teams routinely migrate from Supabase to AWS or from Firebase to GCP once they outgrow the model.
• Pricing surprises. Real-time listeners, function invocations, and bandwidth can spike unpredictably.
• Limited control over query performance and database internals.
• Custom business logic still needs somewhere to run, often as cloud functions that grow into a shadow backend.

When BaaS Fits

BaaS is the right call for mobile and SPA-first products at the prototype-to-early-traction stage, especially solo developers and small teams who don't want to operate a backend at all. It becomes the wrong call once business logic gets serious or pricing starts surprising you. The migration paths exist, but the cheaper move is to use BaaS knowing you'll outgrow it, and to plan the exit before you need it.

Function as a Service (FaaS)

FaaS lets you deploy individual functions that run in response to events: an HTTP request, a queue message, a scheduled trigger. The provider handles the runtime, scales each function independently, and bills per invocation.

FaaS Providers

• AWS Lambda is the dominant option, integrated deeply with the AWS ecosystem.
• Google Cloud Functions and Azure Functions are the hyperscaler equivalents.
• Cloudflare Workers runs at the edge with very low cold starts.
• Vercel Functions and Netlify Functions are PaaS-bundled FaaS.
• Deno Deploy runs TypeScript functions globally.

Pros and Cons

Pros

• True scale-to-zero. You pay only for invocations.
• Per-function deploy granularity.
• Excellent for event-driven workloads and glue code.

Cons

• Cold starts. Even with optimizations, latency-sensitive endpoints can feel laggy on first hit.
• Operational fragmentation. A real backend often ends up as 50 functions whose dependencies and shared state are hard to reason about.
• Local development is harder than a traditional service. Most teams reach for an emulator or wrapper.
• Cost cliffs. At high invocation volume, FaaS becomes more expensive than running a small fleet of containers.

When FaaS Fits

FaaS is the right primitive for genuinely event-driven workloads: async tasks, scheduled jobs, webhooks, edge transformations. It's the wrong primitive when you're using it to assemble a coherent backend that needs shared state, transactions, or service-to-service calls. At that point you're using FaaS to imitate a service, and the imitation is more expensive and harder to operate than the real thing. See serverless functions for a deeper take.

How to Choose

A practical decision flow:

• Frontend or mobile app, no real backend yet? Start with BaaS. Ship the product. Plan the exit before you outgrow it.
• Standard web service, small team, want to ship? PaaS. Pick a modern one (Railway, Render, Fly.io, Vercel) over a legacy one.
• Workload that's genuinely event-driven or runs at the edge? FaaS for those specific functions, often combined with another model for the always-on parts.
• Specific infrastructure or compliance requirements? IaaS, with the caveat that you're now operating it.
• Backend with multiple services and growing complexity? Read the next section.

The Next Layer: Infrastructure from Code

The four models above all share an assumption: infrastructure is configured separately from the application that runs on it. PaaS hides some of the configuration, BaaS hides more, but the underlying split is the same. Your code lives in one place; the description of what it needs (database, queue, secret, schedule) lives somewhere else, in a dashboard, a YAML file, or a Terraform module.

In 2026, that split is increasingly the bottleneck. AI tools generate application code quickly, but they can't reliably reason about infrastructure that isn't expressed in the same context. Multi-environment deployments require coordinating two codebases. Local development has to imitate cloud services rather than run them.

Infrastructure from Code (IFC) is the response: declare what your application needs (database, Pub/Sub topic, secret, cron job) directly in the application's source code, and let tooling provision the right cloud services from those declarations.

Encore is the open-source IFC framework for TypeScript and Go, with over 11,000 GitHub stars and production users including Groupon.

import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";

// Provisions managed Postgres (RDS on AWS, Cloud SQL on GCP, Docker locally).
const db = new SQLDatabase("users", { migrations: "./migrations" });

// Provisions Pub/Sub (SNS+SQS on AWS, Pub/Sub on GCP, NSQ locally).
export const userSignedUp = new Topic<{ id: number }>("user-signed-up", {
  deliveryGuarantee: "at-least-once",
});

export const create = api(
  { method: "POST", path: "/users", expose: true },
  async (req: { email: string }) => {
    const row = await db.queryRow`INSERT INTO users (email) VALUES (${req.email}) RETURNING id`;
    await userSignedUp.publish({ id: row.id });
    return row;
  },
);

The same code runs locally, in preview environments, and in production. Encore Cloud provisions the underlying AWS or GCP services in your own cloud account; there are no runtime dependencies on Encore in production. The framework is open-source and includes an encore eject path for teams that want to leave.

This is not a replacement for IaaS or PaaS in the strict sense. It's a different primitive that sits at the application layer, and most teams using it run on AWS or GCP underneath. What it replaces is the configuration sprawl that grows around any non-trivial backend.

Conclusion

The classic IaaS / PaaS / BaaS / FaaS taxonomy is still useful for thinking about who runs what. In practice, most teams in 2026 use a combination: a PaaS or IFC framework for the main backend, BaaS for some specific feature, FaaS for event handlers, and occasional IaaS escape hatches for things that don't fit anywhere else.

The trend worth tracking is the one toward unified application + infrastructure descriptions. Whether you call it IFC, declarative infra, or something else, the direction is the same: less context-switching between code and config, fewer separately-managed deployment artifacts, and a tighter loop from change to running production.

Related Resources

• Platform as a Service: An Introduction
• Backend as a Service: What is it?
• Serverless functions explained
• Heroku alternatives in 2026
• How to deploy to AWS in 2026
• Encore vs Terraform, CDK, Pulumi, and SST