Cloud Service and Deployment Models Questions

Direct answer

For a microservices-based Software as a Service (SaaS) Minimum Viable Product (MVP), the smallest version of a product built to test whether it's worth building further, serverless is usually the strongest starting point of the three models, specifically because an early MVP's traffic is low and unpredictable, and serverless is the only one of the three that lets infrastructure cost track that near-zero, uncertain usage instead of a provisioned baseline.

Comparing the three models

Recommendation for the microservices MVP

Serverless functions per microservice endpoint, for two reasons specific to an MVP. First, cost tracks actual, likely very low, usage instead of paying for provisioned capacity nobody's using yet. Second, the natural unit of a microservice, a small, independently deployable piece of functionality, maps cleanly onto a function's natural unit, one thing, triggered by one event or request, so the architecture and the billing and scaling model reinforce each other instead of fighting.

Worked example

Contrast the three models for one specific microservice in the MVP: send a welcome email on signup. On IaaS, that's a small, always-on virtual machine, patched and paid for around the clock to occasionally handle a handful of signups a day, wasteful at MVP scale. On PaaS, it's a small, always-on managed instance, better than IaaS operationally but still billed close to continuously even when signups are rare. On serverless, it's a function triggered directly by the signup event, running for perhaps a few hundred milliseconds, costing essentially nothing when there are no signups. That is the correct cost shape for a product that might get five signups a day during early testing and needs to be able to jump to five hundred without a re-architecture.

Trade-offs and pitfalls

The honest caveat on this recommendation is that "serverless-first for an MVP" stops being obviously correct once the product finds traction and specific services develop steady, high, predictable traffic, since a steadily busy function can end up costing more per unit of work than an equivalent always-on PaaS or IaaS instance. The practical move once that happens is to migrate the specific hot service, not the whole system, to a more provisioned model, while keeping genuinely spiky or rare services on serverless. A separate pitfall is assuming "microservices" implies "serverless" as a package deal; microservices is really about how you decompose the system, and it works fine with any of the three service models per service, so the service-model choice should still be made per microservice based on its own traffic shape, not inherited automatically from the architecture style.

Direct answer

For a customer-facing application at 100,000 daily active users, with the team wanting minimal OS management but real control over scaling rules and custom middleware, I would choose a managed application platform (PaaS), specifically a container-based one such as AWS App Runner, Azure App Service, or Google Cloud Run, sitting in front of a managed database. Container-based PaaS gives up direct OS control, matching the team's stated preference, while still letting them ship whatever middleware (authentication, rate limiting, logging) they need baked into the container image, and it exposes autoscaling as configuration rather than code.

Why this, and not the alternatives

Raw IaaS would over-deliver control the team explicitly said it does not want, at the cost of OS patching and instance-fleet management they would have to staff for no real benefit at this scale. Pure serverless functions could technically work, but the team's requirement for custom middleware, which today typically runs as a layer wrapping the whole request path, would need real re-architecture into a function-per-endpoint shape, adding engineering cost for a workload that is not described as bursty. A container-based PaaS product avoids both problems: it takes the container image unchanged, including the middleware, and the platform still owns the OS and scaling.

A quick sanity check on scale: 100,000 daily active users translating to a handful of requests per user per session is on the order of a few hundred thousand requests a day, which is not an exotic scale. It argues for favoring operability over squeezing out a raw performance ceiling.

flowchart LR
  U["User traffic"] --> LB["Load balancer / content delivery network"]
  LB --> APP["PaaS app tier: autoscaling containers with custom middleware"]
  APP --> CACHE["Managed cache for session and rate-limit state"]
  APP --> DB["Managed database"]

A content delivery network (CDN) in front of the load balancer caches static assets close to users and takes load off the app tier; the app tier autoscales on request volume or queue depth, using the platform's built-in policy rather than custom scaling scripts; and the managed database removes OS and patch ownership from that tier too, consistent with the team's stated preference.

Balancing control, overhead and scalability

Scaling rules: container PaaS platforms expose autoscaling policy (CPU or request-based) as configuration you tune, not infrastructure you build. Custom middleware: bringing your own container image means you keep full control over the middleware stack, unlike a "just push source code" PaaS product that would constrain you to its supported frameworks. Minimal OS management: the team never patches a kernel or manages an OS image, since the platform owns that layer entirely.

A past project with a measurable outcome

A team migrating an internal tool off self-managed virtual machines moved its app tier to a container-based PaaS platform specifically to get out of OS patch management, which had been consuming a real, recurring slice of on-call time. Framed as a short story: the team was losing meaningful after-hours time to OS-level patch cycles across a small fleet; the goal was to cut that load without giving up the custom authentication middleware already built into the app; the action was repackaging that middleware into the container image unchanged and switching to the platform's built-in autoscaling instead of custom scripts; the illustrative result was eliminating the OS-patching workstream entirely, with the team reporting roughly a third fewer after-hours pages in the months that followed, since OS-version drift across the fleet stopped being something that needed attention.

Trade-offs and pitfalls

Container PaaS is not unlimited freedom: you are still bound by whatever networking model and container runtime the platform allows, so a workload needing raw kernel modules or unusual hardware access would need to fall back to IaaS. A common pitfall is applying one model uniformly across the whole application when part of it, such as a nightly batch job, fits a scheduled compute pattern better run alongside the main system rather than inside it.

Direct answer

All three service models sit on one spectrum: how much of the technology stack the provider manages for you, versus how much you still manage yourself. Infrastructure as a Service (IaaS) hands you raw compute, storage and networking and you own everything from the OS up. Platform as a Service (PaaS) additionally takes over the OS, runtime and middleware (the software layer that sits between the OS and your application, such as message queues, application servers, or authentication/session handling), so you just deploy code. Software as a Service (SaaS) is a finished application: you own only your data and how you configure and use it.

The three models, one at a time

IaaS. The provider manages the physical data center, the network hardware, and the virtualization layer (the hypervisor that carves one physical server into many virtual machines). You manage the OS, runtime, middleware, application code, and data. Example: Amazon Web Services (AWS) Elastic Compute Cloud (EC2), which rents you a virtual machine and stops there. IaaS is the right default when a workload needs a specific kernel version, custom drivers, or full control of the network stack, for example lifting an existing application that depends on a particular OS build.

PaaS. The provider additionally owns the OS, runtime and middleware. You push application code (or a container image) and the platform patches, scales and load-balances it for you. Example: Google App Engine on Google Cloud Platform (GCP). PaaS fits a small team that wants to ship a web application without hiring dedicated operations staff.

SaaS. The provider owns everything, including the application itself. You own only your data and its configuration: which users exist, what they can see, how records are structured. Example: Salesforce. SaaS is the right choice for a standard business capability, such as a customer relationship management (CRM) system, where building your own would create no advantage.

Data never fully moves to the provider's column. You always decide who is allowed to see it and whether it is used correctly, even when the provider secures every layer beneath it.

Worked example: classifying five real services

• AWS EC2 = IaaS. It hands you a virtual machine. You choose and patch the OS, install a runtime, and own everything above the hypervisor.
• GCP App Engine = PaaS. You deploy application code; the platform owns the OS, the language runtime, and automatic scaling. You never log into a server.
• Azure SQL Database = PaaS, not IaaS, even though "it's a database" makes it sound like infrastructure. Microsoft manages the OS and the database engine's patching and high availability; you manage schema, queries and data. Contrast this with running SQL Server on an Azure virtual machine, which would be IaaS, because you would own the OS and the engine installation yourself.
• Salesforce = SaaS. A finished CRM application. You configure objects, fields and workflows and own your customer records, but Salesforce owns the application code, runtime and infrastructure underneath.
• Google Workspace = SaaS. Gmail, Docs and Drive are ready-to-use applications. Your real responsibility is your data and access configuration: who is in your organization and what they can share externally.

The same ladder shows up on an ML (machine learning) team's bill. A GPU-backed virtual machine running a custom training loop is IaaS: you install the framework, the drivers, and manage the OS yourself. A managed training job that takes your training script and returns a model artifact sits in the PaaS band: the provider owns the cluster orchestration and worker scaling (coordinating many machines to run the job together, and adding or removing machines as the workload changes), you own the training code, data and the resulting model. A managed model-serving endpoint is the same band: you supply the model, the platform owns the runtime and autoscaling of the inference containers (the running, ready-to-answer copies of your packaged model that handle prediction requests).

Trade-offs and pitfalls

The most common misclassification is calling a managed database IaaS "because it holds data like a database server would." The test is not what the service does, it's which layers you still touch: if you never patch an OS or install the database engine, it is PaaS regardless of the product name. A second pitfall is assuming SaaS means zero responsibility; you are always responsible for who has access and how it is configured, and a breach caused by an over-permissioned admin account is still your incident even though the vendor wrote no bad code. Finally, don't treat the three models as a single company-wide choice: most real organizations run all three at once (EC2 for a legacy system, App Engine for a new service, Workspace for email), and the interesting decision is made per workload, not once.

Direct answer

Service-model choice does not change whether you can meet an EU data-residency requirement; it changes how much of the compliance burden is technical, something you configure and verify yourself, versus contractual, something you have to get in writing and trust. That split tracks the shared-responsibility boundary that governs every service model: IaaS gives you the most levers to pull yourself, SaaS gives you the fewest and pushes the burden toward contract terms.

Controls by model

Worked example

A company running an EU customer database on IaaS provisions its own virtual machines and database engine in an EU region and configures backup jobs to write only to EU storage, verifiable by inspecting their own infrastructure. On PaaS, they pick a managed database's EU region, but must additionally check the vendor's documentation for whether that service's automated backups, diagnostic logs, or support-access tooling are also EU-scoped, since providers have historically kept some metadata in a home region by default. On SaaS, for example a customer-support ticketing product, residency depends entirely on whether the vendor sells an EU-residency tier; if it does not, the technical option may not exist at all, and the choice becomes either avoiding that vendor for EU personal data or accepting a contractual transfer mechanism with legal sign-off.

Trade-offs and pitfalls

The biggest pitfall is assuming "I picked the EU region in the console" fully discharges the requirement above IaaS: managed-service metadata, provider support access, and third-party sub-processors can each independently violate residency even when the primary data store is correctly pinned. On SaaS specifically, pin down what the underlying regulation actually requires, for example the EU's General Data Protection Regulation (GDPR) if that is the driver, since "data must remain in the EU" and "a transfer of personal data outside the EU needs a valid transfer mechanism" are two different, commonly conflated obligations. Treating a residency requirement as absolute when the real rule permits a properly documented transfer mechanism can lead you to reject an otherwise workable vendor for no real compliance benefit.

Direct answer

Serverless functions, also called Function as a Service (FaaS: AWS Lambda, Azure Functions, Google Cloud Run functions, the platform formerly known as Cloud Functions), are best understood as a further point along the PaaS spectrum rather than a wholesale new category or a step toward SaaS. The provider takes over everything PaaS already took over (OS, runtime, middleware) plus two things classic PaaS still leaves you: capacity planning and idle cost. What makes serverless feel distinct is a difference of granularity and billing, not a different responsibility layer.

Why not SaaS, and why "further along PaaS"

SaaS gives you a finished application. Serverless gives you a place to run your application code, so it fails the core SaaS test immediately: does the provider own the application logic? No, you still write the function.

PaaS gives you a managed runtime you deploy a service into and typically leave running continuously; you still think in terms of "how many instances" and pay for a provisioned server whether or not it's handling a request. Serverless removes the instance concept from your mental model entirely: the platform decides how many copies of your function to run, scales all the way to zero when idle, and bills per invocation and execution duration rather than per hour of a running server. That is a difference in degree along the same "who manages what" ladder PaaS is already on, not a new category.

The three responsibilities the question names

• Runtime: entirely the provider's. It picks the execution environment, patches the language runtime, and you only choose a supported version and keep your code compatible with it.
• Scaling: entirely the provider's, and automatic. It scales per invocation, including to zero, and the levers you get are reserved concurrency (a cap that both guarantees and limits how many copies of your function can run at once, useful for protecting a downstream dependency like a database connection pool, at no extra charge) and, on some platforms, provisioned concurrency (an additional-cost option that keeps a guaranteed number of copies pre-initialized and ready, so a request doesn't have to wait for a fresh one to start) to reduce cold starts.
• Application code: yours, same as PaaS. You still own business logic, dependencies, and any bugs in your function.

Worked example

Contrast two workloads. An internal admin dashboard that gets hit sporadically all day is a natural PaaS fit: a provisioned instance sits warm between requests, and you pay for that idle time regardless of traffic. An event-driven job that resizes an uploaded image whenever one lands in storage is a natural serverless fit: the function runs for, say, a few hundred milliseconds per image and you pay only for that time, at the cost of a cold-start penalty the first time an idle function wakes up to handle a request.

Trade-offs and pitfalls

Serverless trades away two things PaaS still gives you. First, statelessness: nothing reliably persists in memory between invocations, so any state the workload needs has to live in an external database or cache. Second, a hard maximum execution duration, which makes serverless a poor fit for long-running or streaming work. The common pitfall is treating "serverless" as free of operational burden entirely; in practice you trade server-patching burden for observability burden, since tracing a request across many short-lived, independently scaling function instances is genuinely harder to reason about than reading one long-lived process's logs.