Service, Deployment and Responsibility Models

Introduction

Cloud computing is not a single technology or purchasing arrangement. It is a collection of service models, deployment arrangements, and governance relationships through which computing capabilities are delivered over a network. A sound cloud decision therefore requires more than asking whether an organization should “move to the cloud.” It requires analysis of what is being consumed, where it is hosted, who operates each component, which obligations apply, and how performance and risk will be managed.

The principal service models are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), Function as a Service (FaaS), and managed services. Deployment models include public, private, hybrid, community, and multi-cloud environments. These models are related but not interchangeable: a private cloud may provide IaaS, while a public cloud may provide SaaS; a multi-cloud strategy may combine SaaS from one provider with IaaS from another.

This chapter develops a framework for comparing these choices and applies the shared-responsibility model to security, compliance, operations, and service-level agreements (SLAs). The emphasis is on practical judgment: selecting an arrangement that fits business requirements, technical capability, risk tolerance, and long-term strategy.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain and compare IaaS, PaaS, SaaS, FaaS, and managed services.
2. Distinguish public, private, hybrid, community, and multi-cloud deployments.
3. Map operational and security responsibilities between a provider and a customer.
4. Interpret important SLA terms and identify weaknesses in an SLA.
5. Select an appropriate service and deployment model for a realistic organizational situation.
6. Evaluate trade-offs involving control, cost, portability, compliance, resilience, and operational effort.

1. Two Dimensions of Cloud Choice

Cloud decisions are best understood through two dimensions.

The first is the service abstraction level. At a low abstraction level, the customer controls many technical details but must perform more administration. At a high abstraction level, the provider manages more of the technology, while the customer gives up some control and depends more heavily on the provider’s interfaces and policies.

The second is the deployment scope. A workload may run on shared provider infrastructure, dedicated organizational infrastructure, a combination of environments, or several providers. Deployment scope affects governance, isolation, connectivity, portability, and resilience.

These dimensions should not be confused. IaaS, PaaS, and SaaS describe the nature of the consumed capability. Public, private, hybrid, and multi-cloud describe how and where that capability is organized.

2. Service Models

2.1 Infrastructure as a Service

Infrastructure as a Service (IaaS) supplies fundamental computing resources such as virtual machines, block and object storage, networks, firewalls, load balancers, and sometimes bare-metal servers. The provider operates the physical facilities and virtualization or hardware layer. The customer generally controls the operating system, installed software, data, virtual networks, and many security configurations.

IaaS resembles renting a configurable data-center foundation. It is appropriate when an organization needs substantial control, must run software with unusual operating-system requirements, or is migrating existing applications with limited redesign.

Typical customer responsibilities include:

• operating-system installation, patching, and hardening;
• application deployment and configuration;
• identity and access management;
• data classification, protection, backup, and retention;
• network security rules and host-level monitoring;
• recovery procedures and application availability.

IaaS provides flexibility, but it can reproduce the administrative burden of a traditional data center. A virtual machine that is unused, over-sized, poorly patched, or exposed to the internet can generate both cost and risk.

2.2 Platform as a Service

Platform as a Service (PaaS) provides a managed application platform, commonly including the operating system, runtime, middleware, deployment tools, databases, messaging services, and scaling mechanisms. Developers concentrate on application code and data rather than server maintenance.

PaaS can accelerate development because teams use standard deployment patterns and provider-managed automation. It is particularly useful for web applications, APIs, data-processing services, and applications designed around managed databases and queues.

The major trade-off is reduced control. A PaaS product may constrain operating-system access, supported programming languages, network patterns, or database features. Applications can become dependent on proprietary APIs, creating vendor lock-in and making later migration expensive.

The customer remains responsible for secure code, application identities, data, authorization logic, configuration, and appropriate use of the platform. The provider normally manages the underlying servers, operating system, runtime components, and platform availability, subject to the service contract.

2.3 Software as a Service

Software as a Service (SaaS) delivers a complete application through a browser, mobile application, or API. Examples include email, collaboration, customer relationship management, enterprise resource planning, and human resources systems.

SaaS minimizes infrastructure administration. The provider usually manages the application, platform, operating system, and physical infrastructure. The customer still controls users, roles, business configuration, data quality, retention settings, integrations, and organizational processes.

SaaS does not eliminate security responsibility. Common customer failures include granting excessive permissions, neglecting multifactor authentication, failing to review audit logs, and assuming that provider backups automatically satisfy organizational recovery requirements. A SaaS contract should also address data export, deletion, subprocessors, legal jurisdiction, incident notification, and service continuity.

2.4 Function as a Service

Function as a Service (FaaS) executes small units of code in response to events such as HTTP requests, file uploads, messages, or scheduled triggers. The provider provisions and scales the execution environment, often charging according to invocations, execution duration, memory allocation, or related consumption measures.

FaaS is associated with serverless computing, although serverless does not mean that servers do not exist. It means that customers do not directly manage the servers supporting the code. FaaS is valuable for event processing, lightweight APIs, automation, data transformation, and irregular workloads.

Advantages include automatic scaling, rapid deployment, and payment closely related to use. Limitations include execution-time limits, startup latency, distributed debugging difficulties, event-delivery complexity, and dependence on provider-specific services. FaaS applications must also control recursive triggers, duplicate events, and inadequate authorization.

A well-designed event-driven function is often idempotent, meaning that processing the same event more than once produces the same intended result. Idempotency is important because distributed systems may retry messages or function invocations.

2.5 Managed Services

A managed service is a technology capability operated substantially by a provider on behalf of the customer. Managed databases, managed Kubernetes clusters, managed security monitoring, managed backups, and managed network services are examples. Managed services may be delivered within IaaS, PaaS, or other arrangements; the term emphasizes operational administration rather than a single standardized abstraction level.

Managed services can provide specialist expertise, continuous monitoring, patching, and operational efficiency. They can also create dependency on provider processes and require careful definition of what “managed” includes. For example, a managed database provider may patch database software but not design the customer’s schema, verify application queries, or guarantee recovery from logically corrupted data.

2.6 Comparison of Service Models

The boundaries are not absolute. A provider may expose settings that transfer some responsibility to the customer, and a contract may add operational services beyond the standard product. Responsibility must therefore be confirmed through technical documentation, configuration, and contract terms rather than inferred from a product label.

3. Deployment Models

3.1 Public Cloud

A public cloud is operated by a provider and made available to multiple customers through shared physical infrastructure and logical isolation. Customers usually obtain rapid provisioning, broad geographic reach, elastic capacity, and a large portfolio of services.

Public cloud is attractive for start-ups, development environments, variable workloads, and organizations that do not wish to own data centers. Its risks include misconfiguration, unexpected consumption costs, concentration of workloads with one provider, regulatory constraints, and dependency on provider connectivity.

Multi-tenancy does not necessarily mean that customers share the same virtual machine or data space without controls. Providers use isolation mechanisms, identity systems, encryption, network segmentation, and hardware or software controls. Nevertheless, customers must evaluate the provider’s assurance reports, architecture, incident history, and contractual commitments.

3.2 Private Cloud

A private cloud is dedicated to one organization. It may be hosted in the organization’s own facilities or by a third party. Private cloud can support specialized compliance requirements, predictable control boundaries, and integration with existing systems.

However, private cloud is not simply a traditional data center renamed. A credible private-cloud environment normally includes self-service provisioning, resource pooling, automation, measured usage, and elastic management where appropriate. Private cloud often provides more control but may have higher capital and staffing costs and a smaller service portfolio than a large public provider.

3.3 Hybrid Cloud

A hybrid cloud combines distinct private and public environments with integration that allows data or workloads to move or interoperate. A common design keeps sensitive records in a private environment while using public cloud capacity for analytics, front-end services, backup, or seasonal demand.

Hybrid cloud is valuable when an organization has legacy systems, data-residency constraints, or variable capacity requirements. It is difficult to operate because it requires compatible identity, networking, monitoring, security policies, data formats, and recovery procedures across environments. A hybrid design should not be claimed merely because an organization owns a data center and also uses a public SaaS application; meaningful integration and workload interaction are normally expected.

3.4 Community Cloud

A community cloud is designed for use by organizations sharing common requirements, such as public-sector agencies, universities, healthcare institutions, or financial organizations. Governance, security controls, and compliance arrangements are tailored to the community.

The model can reduce duplication and support common standards, but it requires agreement about funding, membership, control, data access, and dispute resolution. Community cloud is less common as a commercial category than public cloud, yet the concept remains useful for analyzing shared infrastructure among organizations with aligned missions.

3.5 Multi-Cloud

A multi-cloud strategy uses services from two or more cloud providers. It may be intentional, such as placing analytics with one provider and collaboration with another, or may emerge gradually as departments select different products.

Potential benefits include negotiating leverage, access to specialized capabilities, geographic resilience, and reduced dependence on one provider. Costs include duplicated skills, complex identity and monitoring, inconsistent controls, network egress charges, and difficult application portability. Multi-cloud is not automatically more resilient: if all providers depend on the same identity provider, internet carrier, software library, or staff team, a common dependency can still cause broad failure.

4. The Shared-Responsibility Model

The shared-responsibility model states that cloud security and operations are divided between provider and customer. The provider is responsible for the security and operation of the cloud infrastructure that it controls. The customer is responsible for secure use of the service, including data, identities, configurations, and workloads. The exact boundary varies by service model.

A simplified progression is:

• In IaaS, the customer manages more layers, including the guest operating system.
• In PaaS, the provider manages the operating system and runtime, while the customer manages code, data, and platform configuration.
• In SaaS, the provider manages most of the application stack, while the customer manages users, permissions, data governance, and business configuration.
• In FaaS, the provider manages execution infrastructure, while the customer manages function code, event permissions, dependencies, and data behavior.

Responsibility has at least three meanings:

1. Control responsibility: who can configure or change a component.
2. Operational responsibility: who performs maintenance, monitoring, and recovery actions.
3. Accountability: who must demonstrate compliance or answer for an outcome.

A provider may operate a database, but the customer can remain accountable for lawful processing of personal data. Conversely, a customer may configure a security group, but the provider remains responsible for the physical network and hypervisor.

Responsibility Matrix

This table is a starting point, not a substitute for service-specific documentation. A customer should create a responsibility matrix for every important workload and identify an accountable role for each control.

Identity, Data, and Configuration

Identity is frequently the most important customer-controlled security boundary. Least privilege, multifactor authentication, separation of duties, privileged-access management, and periodic access review should be applied regardless of service model.

Data responsibility includes classification, lawful collection, retention, encryption decisions, key management, deletion, and recovery. Encryption at rest does not automatically protect data from an authorized but malicious application user. Access control and application design remain necessary.

Configuration is another major risk. Publicly exposed storage, unrestricted network rules, weak administrative credentials, and disabled logging are customer-side failures even when the provider’s infrastructure is secure. Infrastructure-as-code, peer review, policy checks, and drift detection can reduce these errors.

5. Service-Level Agreements

An SLA is a formal agreement defining measurable service commitments, responsibilities, remedies, and conditions. It is not simply a statement that a service is “reliable.” A useful SLA identifies the service scope, measurement method, target, exclusions, customer duties, reporting process, and remedy.

Availability and Downtime

Availability is commonly expressed as:

Availability is dimensionless because both time quantities use the same unit. The formula assumes that unavailable time has been defined consistently and that exclusions, maintenance windows, and measurement locations are specified.

For a 30-day month, using 24-hour days:

If a service promises 99.9% availability, the maximum theoretical unavailable time is:

This is not necessarily the customer’s actual experience. The SLA may exclude scheduled maintenance, customer-caused failures, force majeure, or dependencies outside the measured service. A 99.9% monthly target also does not guarantee that outages will be evenly distributed; one 43-minute interruption may be more damaging than several brief interruptions.

Other important SLA measures include:

• Latency: time required to complete an operation, normally with a defined percentile such as p95 or p99.
• Throughput: amount of work completed per unit of time.
• Recovery time objective (RTO): maximum targeted time to restore service after a disruption.
• Recovery point objective (RPO): maximum targeted period of data that may be lost, measured backward from the disruption.
• Support response time: time until a provider acknowledges or begins handling an incident.
• Service credits: contractual compensation when a target is missed.

RTO and RPO are not the same. An RTO of four hours concerns restoration time; an RPO of fifteen minutes concerns the age of the latest recoverable data. Neither measure alone guarantees business continuity.

Evaluating an SLA

A professional SLA review should ask:

1. What exact service and geographic regions are covered?
2. How is availability measured, and from whose measurement points?
3. What exclusions apply?
4. Are dependencies such as identity, networks, or customer configuration included?
5. What notice is required for incidents and planned changes?
6. Are remedies automatic, meaningful, and proportionate to business impact?
7. How are data export, termination, deletion, and transition handled?
8. Are audit rights, compliance evidence, and subprocessors addressed?

Service credits may be financially small compared with the cost of an outage. Organizations should therefore combine contractual remedies with architectural resilience, tested backups, monitoring, and business continuity planning.

6. Selecting Models: A Decision Framework

A sound selection process begins with workload requirements rather than provider popularity. Important criteria include:

• required control over operating systems and networks;
• internal skills and available operations staff;
• workload variability and scaling needs;
• data sensitivity and legal location requirements;
• performance, latency, and integration constraints;
• portability and exit requirements;
• resilience and recovery objectives;
• total cost, including migration and egress costs;
• provider maturity, support, and assurance evidence.

An organization with a stable legacy application and strong systems-administration skills may select IaaS. A development team seeking rapid delivery may prefer PaaS. A small organization needing standardized collaboration may choose SaaS. An event-driven image-processing workload may fit FaaS. A regulated institution may use a hybrid design, but only if it can operate the required connectivity and governance.

Cost and Capacity Considerations

Cloud cost is influenced by consumption, commitments, data transfer, storage, support, licensing, monitoring, and staff time. A simple monthly estimate can be represented as:

This is a planning identity rather than a universal provider billing formula. Each term must be defined for the organization’s accounting period and measured in the applicable currency. Apparent savings from shutting down servers may be offset by migration, redesign, training, compliance, and integration costs.

7. Applied Case: Northstar University Research Platform

This is an illustrative case.

Background

Northstar University supports a research platform used by faculty and students. The platform stores ordinary research documents, confidential participant information, and large scientific datasets. Demand rises sharply during grant deadlines. The university has a small infrastructure team, an existing private virtualization cluster, and a requirement to maintain audit evidence for research-data handling.

Problem

The existing platform runs entirely on university-managed servers. Provisioning takes weeks, the cluster is underused during ordinary periods, and the team lacks sufficient capacity for short-lived data-processing experiments. Moving everything to a public SaaS product would provide little control over specialized analysis tools and data workflows.

Analysis

The workloads are not identical. Collaboration and document editing are relatively standardized and can be obtained as SaaS. The research portal requires custom code and should use PaaS to reduce operating-system maintenance. Burst analytics can use FaaS or managed batch processing. Highly sensitive participant data requires stricter access control, logging, and approved storage locations. Existing laboratory systems must remain connected to the private environment.

A hybrid architecture is therefore appropriate, with carefully governed integration rather than indiscriminate workload movement. A multi-cloud design is not initially justified because the university lacks staff to operate multiple equivalent platforms and has no clear requirement for provider diversity.

Approach and Solution

Northstar adopts the following arrangement:

• SaaS for collaboration, with university-controlled identity federation and multifactor authentication;
• PaaS for the research portal, with code scanning, private network integration, and managed database services;
• private infrastructure for selected sensitive systems and laboratory integration;
• FaaS for event-driven document classification, designed to avoid storing sensitive content in logs;
• managed backup with periodic restoration tests;
• a responsibility matrix assigning data classification, access review, and recovery validation to university roles;
• an SLA requiring incident notification, defined support response times, data export, and evidence of service availability.

Outcome

Provisioning time falls from weeks to hours for approved environments. The university reduces routine server administration and can scale analysis during deadlines. However, it must invest in cloud-financial management, identity governance, network engineering, and staff training. The hybrid arrangement improves flexibility but introduces integration complexity and does not remove the need for data stewardship.

Learning Points

1. Different workloads may require different service models.
2. Hybrid cloud is useful only when integration and governance are designed explicitly.
3. A provider’s technical operation does not transfer institutional accountability for data.
4. Managed services reduce some work but do not eliminate architecture, configuration, or recovery responsibilities.
5. SLA commitments must be connected to business requirements and tested operationally.

8. Challenges, Governance, and Ethics

Vendor Lock-In and Portability

Lock-in can arise from proprietary APIs, data formats, identity integration, operational tooling, and staff expertise. Portability should be assessed realistically: moving virtual machines may be easier than moving a distributed PaaS application with proprietary databases and event services. Use documented interfaces, export procedures, open formats where practical, and periodic exit exercises for critical systems.

Privacy and Regulation

Cloud use does not remove obligations under privacy, records-management, financial, health, or sector-specific regulation. Organizations should know where data is processed, which subprocessors are involved, how access is logged, how legal requests are handled, and how deletion is verified. Data minimization and purpose limitation remain important even when storage is inexpensive.

Concentration and Systemic Risk

Dependence on a small number of providers can create concentration risk. A provider outage, pricing change, cyber incident, or regional disruption may affect many customers simultaneously. Resilience planning should identify common dependencies, not merely count providers.

Artificial Intelligence and Managed Cloud Services

Cloud providers increasingly offer managed machine-learning and generative-AI services. These can accelerate experimentation, but organizations must evaluate training-data use, retention, model outputs, intellectual-property rights, bias, explainability, and prompt or document leakage. The shared-responsibility model still applies: the provider may operate the model platform, while the customer remains responsible for lawful data use, access control, human oversight, and appropriate deployment.

Governance Best Practices

Effective governance commonly includes:

• approved reference architectures and service catalogs;
• identity federation, multifactor authentication, and least privilege;
• tagging and budgets for cost accountability;
• encryption and managed key policies appropriate to data sensitivity;
• centralized logging with protected retention;
• vulnerability and configuration management;
• tested backup, restoration, and incident-response procedures;
• supplier due diligence and contract review;
• documented exit and portability plans;
• periodic review of actual architecture against the responsibility matrix.

Chapter Summary

Cloud service models describe the level of technology managed by a provider. IaaS offers extensive control but requires substantial administration; PaaS reduces infrastructure work while introducing platform constraints; SaaS delivers complete applications but leaves customers responsible for users, data, and configuration; FaaS supports event-driven execution with strong operational abstraction; and managed services provide defined operational assistance that must be examined carefully in contract and practice.

Deployment models describe organizational scope. Public cloud provides broad, shared-provider capabilities; private cloud provides dedicated control; hybrid cloud integrates private and public environments; community cloud serves organizations with shared requirements; and multi-cloud uses multiple providers. None is universally superior. The correct choice depends on workload characteristics, skills, regulation, resilience, cost, and strategic objectives.

The shared-responsibility model prevents the mistaken belief that cloud adoption transfers all risk to a provider. Physical infrastructure is generally provider-managed, while customers retain important responsibilities for identity, data, application security, configuration, and recovery. SLAs make selected commitments measurable, but availability percentages, RTOs, RPOs, latency targets, exclusions, and remedies must be interpreted in business context. Strong cloud practice combines suitable architecture, explicit accountability, governance, testing, and realistic exit planning.

Key Terms

Service model: A defined way of consuming technology capabilities from a provider.

Deployment model: The organizational and infrastructural arrangement in which cloud services operate.

Infrastructure as a Service (IaaS): Provider-delivered computing, storage, and networking resources managed by the customer at higher layers.

Platform as a Service (PaaS): A provider-managed application platform on which customers deploy code and data.

Software as a Service (SaaS): A complete provider-operated application accessed by customers over a network.

Function as a Service (FaaS): Event-triggered execution of customer functions without direct server management.

Managed service: A technology capability for which a provider performs defined operational tasks.

Public cloud: Cloud infrastructure operated by a provider for multiple customers.

Private cloud: Cloud infrastructure dedicated to one organization.

Hybrid cloud: Integrated use of private and public cloud environments.

Community cloud: Cloud environment designed for organizations sharing common requirements.

Multi-cloud: Use of services from two or more cloud providers.

Shared responsibility: Division of security, operational, and compliance duties between provider and customer.

Vendor lock-in: Difficulty or cost associated with moving from one provider or technology to another.

Service-level agreement (SLA): Contractual statement of measurable service commitments and remedies.

Availability: The proportion of agreed service time during which a service is usable according to a defined measure.

Recovery time objective (RTO): Target maximum time to restore service after disruption.

Recovery point objective (RPO): Target maximum period of data loss measured backward from disruption.

Idempotency: A property in which repeated processing of the same request or event produces the same intended result.

Least privilege: Giving identities only the access necessary for authorized tasks.

Review Questions

Short Answer Questions

1. What is the principal difference between IaaS and PaaS?
2. Why does SaaS not eliminate customer security responsibilities?
3. Define hybrid cloud and identify one reason to use it.
4. What do RTO and RPO measure?
5. Why is a responsibility matrix useful in cloud governance?

Long Answer Questions

1. Compare IaaS, PaaS, SaaS, FaaS, and managed services in terms of control, operational effort, scalability, and vendor dependence.
2. Explain the advantages and disadvantages of public, private, hybrid, community, and multi-cloud deployments.
3. Discuss how identity, data governance, and configuration management fit within the shared-responsibility model.
4. Explain why an SLA availability percentage may not fully represent business resilience.
5. Develop a cloud-selection framework for a medium-sized organization migrating several different workloads.

Analytical / Application Questions

1. A company has a stable legacy application, a small development team, strict data-location requirements, and highly variable seasonal demand. Recommend service and deployment models, and justify the trade-offs.
2. A provider advertises 99.95% monthly availability for a 30-day month. Calculate the maximum theoretical unavailable time in minutes, then identify at least three SLA conditions that could change the practical interpretation.
3. An organization uses two cloud providers but both depend on one identity provider and one network carrier. Analyze whether this is genuinely resilient multi-cloud and propose improvements.

Multiple Choice Questions with Answers

Question 1

Which service model generally gives the customer control over the guest operating system?

A. IaaS

B. PaaS

C. SaaS

D. FaaS

Correct Answer: A. IaaS

Question 2

Which model is most directly associated with event-triggered execution of small units of code?

A. Private cloud

B. FaaS

C. SaaS

D. Community cloud

Correct Answer: B. FaaS

Question 3

Which deployment model combines integrated private and public environments?

A. Public cloud

B. Private cloud

C. Hybrid cloud

D. Community cloud

Correct Answer: C. Hybrid cloud

Question 4

In a typical SaaS arrangement, which responsibility normally remains with the customer?

A. Operating the provider’s physical servers

B. Replacing failed storage hardware

C. Managing user permissions and organizational data

D. Patching the provider’s hypervisor

Correct Answer: C. Managing user permissions and organizational data

Question 5

What does an RPO primarily describe?

A. The target time to restore a service

B. The maximum targeted period of data loss

C. The provider’s support response time

D. The percentage of monthly service availability

Correct Answer: B. The maximum targeted period of data loss

Question 6

Using a 30-day month, what maximum unavailable time corresponds to 99.95% availability, before exclusions?

A. 21.6 minutes

B. 43.2 minutes

C. 72 minutes

D. 216 minutes

Correct Answer: A. 21.6 minutes

Question 7

Which statement about multi-cloud is correct?

A. It automatically guarantees resilience against all outages

B. It means that every workload must run identically on every provider

C. It uses services from at least two cloud providers

D. It is another name for a private cloud

Correct Answer: C. It uses services from at least two cloud providers

Question 8

Which practice best reduces the risk of excessive cloud permissions?

A. Granting all developers administrator access

B. Applying least privilege and reviewing access regularly

C. Disabling audit logging

D. Using one shared account for operations

Correct Answer: B. Applying least privilege and reviewing access regularly

Question 9

Which is a common limitation of PaaS?

A. It always requires customers to maintain physical servers

B. It may create dependence on provider-specific interfaces

C. It cannot support application code

D. It provides no automated operational capabilities

Correct Answer: B. It may create dependence on provider-specific interfaces

Question 10

Why can service credits be insufficient as a resilience strategy?

A. They always increase availability above the SLA target

B. They may not compensate for the operational and business cost of an outage

C. They eliminate the need for backups

D. They prevent all customer configuration errors

Correct Answer: B. They may not compensate for the operational and business cost of an outage