Cloud Service and Deployment Models Questions

Direct answer

Vendor lock-in is the cost, in effort, time and money, of switching away from a provider once you have adopted its services, and it grows precisely where you have taken on the most provider-specific convenience. Five common vectors are proprietary application programming interfaces (APIs), managed services with no equivalent elsewhere, provider-specific data formats, provider-specific tooling, and identity. A cloud architect can mitigate each of these during evaluation and design, before the dependency is load-bearing, at a fraction of the cost of untangling it later.

The five vectors and their mitigations

APIs. Calling a provider's proprietary API surface directly throughout the application ties every call site to that vendor. Mitigation: introduce a thin abstraction layer, an internal client wrapping the provider's software development kit, so a future swap touches one module instead of every call site. Where a genuinely portable standard already exists, prefer it over a proprietary equivalent even when the proprietary option is marginally more convenient today.

Managed services with no equivalent elsewhere. Adopting a highly specific proprietary service means there is no "just switch providers" path, only "rebuild it." Mitigation: at design time, evaluate whether an open-source or multi-cloud-available alternative meets the need at an acceptable extra operational cost, and treat the proprietary option as a deliberate, documented trade rather than a default.

Data formats. Exporting data only in a provider-specific format, or having no bulk-export path at all, means migration starts with a data-transformation project before anything else can move. Mitigation: build and periodically test a bulk-export path to an open format (CSV, Parquet, or a standard SQL dump) as part of normal operations, not as a one-time migration afterthought, so it stays trustworthy.

Tooling. Building deployment automation entirely around a provider's proprietary infrastructure-as-code or continuous integration and continuous delivery (CI/CD) product makes the pipeline itself a migration cost. Mitigation: prefer a portable infrastructure-as-code tool such as Terraform over a provider-only equivalent for anything you might need to reproduce elsewhere, and keep build and deploy logic in provider-agnostic tooling where practical.

Identity. Wiring every application's authentication and authorization directly to a provider's identity and access management (IAM) system makes identity itself hard to unwind, since every permission and integration would need recreating. Mitigation: front identity with a standard protocol such as OpenID Connect (OIDC) so the provider's identity system sits behind a portable interface, and keep an inventory of every place a provider-specific role or permission is referenced.

Trade-offs and pitfalls

Every mitigation above has a real, upfront cost, and sometimes worse day-one ergonomics, in exchange for optionality you may never use. The practical stance is to spend mitigation effort proportional to how core and how hard to replace a dependency is, not apply every mitigation to every service uniformly. A low-stakes utility service can reasonably be adopted with zero abstraction; a system-of-record data store deserves the full treatment. The pitfall is doing the opposite: abstracting the trivial dependency for the sake of tidiness while leaving the genuinely core, hard-to-replace one wired in directly because "it was easier to ship that way."

Direct answer

For a 4-person team with limited operations experience hosting an application around 10,000 daily active users, I would recommend PaaS as the primary model, a managed application platform plus a managed database, reserving IaaS only for any piece that genuinely needs it, and treating SaaS as a source of building blocks to buy, such as authentication or transactional email, rather than as the hosting model for the core app itself.

Comparing the three for a small team

IaaS gives full control and potentially the cheapest per-unit compute, but the team would own OS patching, scaling configuration, and monitoring, which competes directly with the very small number of engineering hours available for the actual product. Wrong default here.

PaaS gives up some control, but a 4-person team gets a production-grade deployment, managed scaling, managed database, automated patching, without hiring or becoming operations specialists. That is exactly the trade a resource-constrained team should make.

SaaS is the right model for well-defined, already-solved problems adjacent to the product, using a SaaS product for email delivery, a SaaS-provided authentication service, or a support-ticketing tool for customer service, rather than for the core application, since the core app is presumably the team's actual differentiated product and isn't something an off-the-shelf SaaS product would be.

The recommendation

A managed application platform for the app tier plus a managed database for storage, with a couple of SaaS building blocks glued in for auth and transactional email rather than built from scratch. This keeps the team's operations surface down to "watch a dashboard and occasionally adjust a scaling policy" instead of "own a fleet."

A hybrid approach, and when it makes sense

A hybrid here would mean keeping the core app on a managed platform while running one specific piece on IaaS, for example a background job that needs a software dependency the managed platform doesn't support, or a steady, cost-sensitive batch workload where a small reserved virtual machine is genuinely cheaper at this scale than the managed equivalent. This makes sense once the team has one clear, isolated piece of the system with a requirement PaaS can't satisfy, or a cost delta large enough to justify the added operational surface for that one piece, not as a blanket decision to control more of the stack.

The analytics variant: a different lock-in calculus

If the workload were analytics or business intelligence (BI) flavored instead of a general customer-facing app, for instance this same 4-person team standing up internal reporting dashboards, the PaaS-first instinct needs an extra check. A fully SaaS BI tool gets a working dashboard fastest, but it usually couples the team's reporting logic and data tightly to that vendor's proprietary query language and connectors, a much larger vendor lock-in exposure than picking a managed application platform for a general web app, where the exit path (redeploy the same container elsewhere) is comparatively cheap. A PaaS-level option, a managed data warehouse queried with standard SQL, costs the team a bit more setup and ongoing responsibility, someone has to model the data and maintain the queries, but keeps the exit path open, since standard SQL and exported data are portable in a way a BI SaaS product's proprietary dashboard definitions typically are not. For a 4-person team specifically, that's worth naming explicitly rather than defaulting to "SaaS is always right for a small team," because the team's limited operations capacity has to be weighed against how expensive it would be for that same small team to unwind a deep SaaS BI dependency two years later if the vendor's pricing or roadmap stops fitting.

Trade-offs and pitfalls

The first pitfall is treating "small team, limited ops" as an automatic vote for SaaS everywhere; SaaS for your core differentiated product usually means you're not actually building a product anymore, just configuring someone else's. The second is over-indexing on cost-per-unit-compute when comparing IaaS to PaaS at this scale: at 10,000 daily active users, the labor cost of even a fraction of one engineer's time spent on operations very likely exceeds the sticker-price premium of PaaS, so the "PaaS costs more per server" argument that matters at large scale mostly doesn't apply yet.

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

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.

Direct answer

For predictability specifically, not lowest absolute spend, the ranking is SaaS ahead of PaaS on committed terms ahead of pure pay-as-you-go IaaS. SaaS's subscription billing turns cost into a near-fixed line item you can plan a year out; IaaS's usage-based billing ties your bill directly to demand and to how well your team manages the infrastructure underneath it.

Billing models compared

Applying it for a CIO who wants predictability

The Chief Information Officer's stated preference argues for two concrete moves. First, default to SaaS for anything that is a standard capability, since a fixed per-seat subscription is close to the most predictable line item in the entire budget. Second, for custom systems that must run on PaaS or IaaS, negotiate reserved or committed-use pricing (a multi-year capacity commitment in exchange for a discount and a flatter bill) rather than staying on raw on-demand pricing; committed-use converts a variable cost into something closer to fixed, at the price of losing the ability to shrink instantly if usage drops. On IaaS specifically, predictability also requires labor investment: a small cloud financial operations (FinOps) practice of budgets, alerts, and regular right-sizing reviews, precisely because the billing model itself will not provide predictability on its own.

Trade-offs and pitfalls

The pitfall is treating "SaaS is most predictable" as "SaaS is cheapest." Per-seat SaaS pricing can become the single largest line item as headcount grows, so predictability and total cost are different axes, and a CIO who says "predictability over lowest spend" is explicitly accepting the possibility of paying more for a flatter bill. Make that trade-off explicit rather than silently optimizing for cost anyway. Also flag that committed-use IaaS pricing only helps predictability if the workload's baseline is genuinely stable; over-committing capacity for a workload that later shrinks converts "unpredictable but scoped to actual use" into "predictable and now overpaying."