Cloud Service Models

Cloud Service Models Explained

In this chapter, we introduce the definition of service models according to NIST. The concept of a service model is central to planning a cloud adoption process. In 2011, NIST classified three service models for cloud resource management:

• Software as a Service (SaaS)
• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)

Software as a Service (SaaS)

The consumer can use the provider's applications running on a cloud infrastructure.

These applications are accessible from various client devices through a thin client interface, such as a web browser (eg, web-based email) or an application program interface (API).

The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, storage, or even individual application functionalities, except for limited user-specific application settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure applications created or acquired using programming languages, libraries, services, and tools supported by the provider.

The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, or storage, but has control over the deployed applications and, possibly, configuration settings for the application hosting environment.

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to provision processing, storage, networking, and other fundamental computing resources where the consumer can deploy and run arbitrary software, which can include operating systems and applications.

The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications and, possibly, limited control of selected networking components (eg, host firewalls).

Service Model Insights

Service models implicitly introduce a responsibility matrix dictated by contractual agreements specific to each model.

A comparative analysis of service models and the ISO/OSI stack helps clarify the impact of the service model on the cloud adoption journey.

• IaaS:The cloud provider typically ensures service availability up to layer 4 of the ISO/OSI stack (Transport layer).
• PaaS:The guaranteed level varies between layer 4 and layer 5, sometimes extending to layer 6.
• SaaS:Services are typically maintained at layer 6, and in specific cases where no user interaction occurs through a web or mobile application, it can reach layer 7.

The division of responsibility between the cloud provider and the consumer plays a crucial role in defining the service model.

Another key aspect to consider isscalability expectationsin the cloud. Opting for an IaaS model does not necessarily take full advantage of the cloud's scalability capabilities. In fact, scalability responsibility falls on the hosted content within the IaaS service, which may result in classical scalability limitations, potentially leading to higher operational costs rather than reduced expenses.

While it is relatively easy to classify cloud resources managed through IaaS models, this becomes more complex with PaaS and SaaS models.

Many complex cloud resources are delivered viahybrid service models, such asPaaS/IaaS or PaaS/SaaS.

For example:

• Recognizable SaaS solutions includeSalesforce CRM, Microsoft 365, and Google Workspace, all of which offer complex suites of SaaS-based solutions.

Below, we provide a deeper insight into each service model.

IaaS

Classic IaaS services includesbasic network resources (firewalls, VPNs, etc.).

Virtual machines (VMs) not managed by the cloud provider also fall under IaaS. This is one of the most comparable cloud services to traditional IT system management, making it one of the most considered options in lightweight cloud adoption strategies.

The cloud provider guarantees hardware operation, including both physical and logical security.

Thesecurity responsibilityis typically covered up tolayer 4of the ISO/OSI stack.

The consumer is responsible for configuring and managing the operating system and any additional application software installed on the VM.

TOhybrid casebetween IaaS and PaaS is aVM with a managed operating system. Here, the provider manages OS updates and security patches autonomously but does not enforce version changes until official support ends. However, the provider does not assume responsibility for third-party applications installed by the consumer.

IaaS/PaaS and PaaS

PaaS is the first service model that trulydefines cloud computing, though finding purely PaaS-classifiable resources can be challenging.

Many cloud resources usehybrid service models(IaaS/PaaS), includingKubernetes and Red Hat OpenShift.

Some databases are offered as PaaS services, where the consumer only defines:

• DDL (Data Definition Language): Schema structures, stored procedures, functions, and user permissions.
• DML (Data Manipulation Language): CRUD (Create, Read, Update, Delete) operations.

NotablePaaS database servicesincludesAzure Database and AWS Aurora.

Otherspure PaaS servicesincludesAzure Functions and AWS Lambda.

In aPaaS as wellmodel, the consumer relinquishes control over the cloud resource's state, which is contractually managed by the provider. The responsibility matrix is ​​clear: the consumer is only responsible for the functional and application layer.

SaaS

SaaS is one of the most widely adopted cloud service models in the public cloud.

Consider the earlyfree webmail providers, available for more than two decades.

SaaS encompassessocial media services and widely used B2C sales platforms, some of which are expanding into enterprise solutions (eg, WhatsApp for Business).

Theboundary between SaaS and PaaSis sometimes ambiguous, and even cloud providers themselves may struggle to classify services technically, often relying on marketing terminology instead.

Examples of Paid SaaS Services

Azure:

• Microsoft 365:A well-known SaaS application that allows users to access cloud-based productivity tools such as email, calendars, and document management.
• Microsoft Dynamics.
• Microsoft Business Central.
• Microsoft Teams.
• Microsoft Chat GPT:One of the most widespread AI-driven prompt services powered by OpenAI.
• Microsoft Copilot:A productivity acceleration service leveraging OpenAI technology.

AWS:

• AWS Elastic Beanstalk:A plug-and-play platform supporting multiple programming languages ​​and environments.

Google Cloud Platform (GCP):

• Google Mail:One of the most widely used free and paid email services.
• Google Workspace:A suite of productivity tools used worldwide.
• Google Gemini:Emerging as an AI-integrated service within Google's productivity offerings, with promising integration intoBigQuery.
• BigQuery:Google'sserverless, multi-cloud data warehouse, offered as a SaaS solution. It integratesmachine learning algorithmsto provide real-time insights into business processes.

This classification helps organizations understand which service models best fit their operational and strategic needs when adopting cloud computing.

Ambiguity in Service Model Interpretation

In personal-use solutions, many cloud services function as wellSaaS, offering a fully managed experience with minimal user-specific customization.

However, in enterprise environments, these services evolve intohybrid models, providing organizations with extensive customization and control over service configurations.

While activating a solution likeMicrosoft 365 or Google Workspacemay be simple, its enterprise-level deployment introduces significant complexity. Advanced setup demandsstrong networking and security expertiseto ensure full-service functionality while maintaining corporate compliance.

Additionally, enterprise versions often offerAPI-based integrations, allowing deep customization and automation. As a result, responsibility for service management shifts from solely the provider to ashared responsibility model, where both the provider and the consumer play key roles in governance and maintenance.

Extending Cloud Service Models

---

In the initial chapters of this section, we introduced fundamental concepts regarding cloud service and distribution models.

IaaS, PaaS, and SaaS—delivered via public cloud providers—are the primary service models offered by major cloud vendors.

However,hybrid cloudandcloud-nativesolutions areevolving, creating new service opportunities.

For example, as a software provider, I may have shifted from installing my product on customers' local machines to offering it as a web service, with only lightweight local applications mimicking the traditional desktop experience.

In parallel, we have defined the key roles in the cloud supply chain and the cloud consumption chain, introducing the responsibility matrix (RACI) as a simplified representation of service responsibility management.

The cloud is continuously evolving, introducing increasingly complex cloud resources designed to address specific consumer needs—sometimes creating new demands through marketing strategies.

For example, instead of offering my software as aweb service, I might distribute it as acloud marketplace product:

• The customer downloads my product, which is automatically deployed in their cloud environment.
• The software runs within their cloud but sends me usage analytics on how the customer interacts with my service.

Alternatively, I might offer a dedicated cloud ecosystem for each client, running on my own cloud infrastructure.

As these hybrid models emerge, cloud providers are launching more specialized solutions to prevent customer migration based on cost optimization alone.

At the center of this strategy isdate.

If I offer a unique service that no competitor provides—even at an acceptable price—my customers will find it very difficult to switch to another provider.

To reinforce customer retention, public cloud providers are introducing hybrid PaaS/SaaS services that are native to their specific cloud platform and not easily replicable on other clouds.

Impact on IT Operations and Organizational Restructuring

We have already seen how cloud consumption structures introduce specialized roles, leading to a reorganization of IT operations.

Figures30attempts to illustrate how the cloud service market is adapting to this growing complexity.

In Figure the term “hyperscaler” is used to represent a primary public cloud provider.

Hyperscalers collaborate with telecommunications providers, ensuring the first level of service—data transport, which corresponds to the lower layers of the ISO/OSI model.

Above this, we find:

• The three primary cloud service models (IaaS, PaaS, SaaS).
• Infrastructure as Code (IaC), enabling automated cloud ecosystem lifecycle management.
• DevSecOps operations, which integrate with the Cloud Architecture COE and FinOps COE to mediate service deployment.

What If an Organization Has a Low Cloud Maturity Level?

Some enterprises may be unable to fully implement cloud-native operations, due to:

• Low cloud maturity
• Cultural gaps that cannot be easily addressed within the budget of a single business project

In these cases, cloud services allow organizations to outsource the creation and management of a dedicated cloud ecosystem tailored to a specific business project.

This is known asBusiness Process as a Service (BPaaS).

BPaaS allows businesses to adopt cloud services incrementally, while preparing for future cloud-native transformations.

Holistic Vision

Choosing among IaaS, PaaS, and SaaS is not a purely technical decision; it's an orchestration oftechnology, organization, finance, risk, and portability. The “right” model is the one that best aligns these lenses for a specific business outcome—now and as it evolves.

The big picture

• Value speed vs. control:PaaS/SaaS accelerate delivery by abstracting infrastructure; IaaS maximizes control at the cost of more operational burden.
• Shared responsibility ≠ zero responsibility:As you move from IaaS → PaaS → SaaS,whatyou manage changes, butgovernance and data accountabilityremain yours.
• Data gravity rules:Application code can be portable;datecreates inertia. Plan for data lifecycle, residency, and egress from day one.

Four lenses to decide

1. Architecture & Ops
   • IaaS: bespoke environments, full control over OS/network; demands solidIaC, GitOps, and runbooks.
   • PaaS: managed runtimes/databases, faster releases; design to provide SLOs/limits and use12‑factorpractices.
   • SaaS: consume capabilities (eg, email, CRM, analytics) with minimal ops; integration and identity become first-class work.

2. Organization & Roles
   • Define aRACI: who'sAccountablefor uptime, security, backups, cost?
   • Create aPlatform Team(even small) to offer “golden paths” and guardrails for IaaS/PaaS users.

3. Risk, Compliance & Security
   • Treatidentity (IAM), encryption, logging, and backup/restoreas non‑negotiable baselines across all models.
   • Map data classificationto service choice (eg, regulated data may require private networking, KMS ownership, or specific regions).

4. FinOps & Unit Economics
   • IaaS: variable costs + idle risk → rightsize, schedule, and autoscale.
   • PaaS: managed scaling; watchper‑request/GB‑secondstyle pricing.
   • SaaS: per-seat/per-usage; model over 3–5 years and includesegress/integrationcosts.

When to prefer each model (rule of thumb)

• SaaSfor commodity capabilities (email, docs, ITSM, CRM, analytics UI). Demand: export formats, APIs, clearexit plan.
• PaaSfor differentiated apps where speed matters (functions, containers, managed DBs). Demand: SLOs, scaling policy, quotas.
• IaaSfor specialized workloads (legacy, low‑level tuning, strict isolation). Demand: automation (IaC), hardening, cost guards.

Guardrails that travel with you

• Policy‑as‑code(tagging, budgets, SCPs/OPA),secrets management, immutable builds, observability SLOs, DR patterns(RTO/RPO defined).
• Standardize Honcontainers + IaCeven when using PaaS, to keep future options open.

Reducing vendor lock‑in (pragmatically)

• Favor open interfaces (eg,S3‑compatiblestorage,OpenAPIfor services).
• Decoupledomain logicfrom provider SDKs behind adapters.
• Keep data export pipelines and ownership schemainternal.
• Track shortreversibility doc: what would it take to move in 90 days?

Decision checklist (copy/paste)

• Exit strategy(export formats, data volumes, notice periods)?
• Date class &residency? Encryption & key ownership?
• RequiredSLOs(latency, availability) andRTO/RPO?
• Who isAccountablefor uptime, security, andcost?
• 12‑monthrun ratevs. 36‑monthTCO(incl. egress & staff time)?
• Whatbusiness KPIsdoes this service impact?