Cloud Service, Deployment and Reference Models

Introduction

Cloud computing is not a single technology or purchasing model. It is an approach to delivering computing capabilities—such as processing, storage, networking, databases, application platforms, and software—through shared, programmable, and usually metered infrastructure. The most important architectural decisions concern what the provider delivers, where the service operates, who controls each layer, and how responsibilities are divided between provider and customer.

The service models Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), and Function as a Service (FaaS) represent increasing levels of provider abstraction. Deployment models—including public, private, hybrid, multicloud, and sovereign cloud—describe the ownership, location, governance, and operational arrangement of cloud resources. These models are not mutually exclusive in all cases. For example, an organisation may use SaaS applications in a public cloud, operate a private PaaS, and deploy selected workloads across two public providers in a multicloud strategy.

A sound cloud architecture requires more than selecting a provider. It requires explicit allocation of security, availability, compliance, data-management, and operational responsibilities. This chapter develops a framework for making such decisions and applies it to a realistic enterprise case.

Learning Objectives

After completing this chapter, a student should be able to:

1. Explain and compare IaaS, PaaS, SaaS, and FaaS.

2. Distinguish public, private, hybrid, multicloud, and sovereign cloud deployments.

3. Use reference architectures to identify cloud layers and dependencies.

4. Apply the shared-responsibility model to security and operations.

5. Evaluate service and deployment models using technical, economic, governance, and strategic criteria.

6. Design an appropriate cloud approach for a regulated or distributed organisation.

7. Identify limitations, portability risks, ethical concerns, and emerging developments in cloud computing.

1. A Layered View of Cloud Computing

A cloud environment can be understood as a stack. At the lower levels are physical facilities, power, cooling, servers, storage devices, and network equipment. Above them are virtualisation and resource-management services. Higher layers provide operating systems, runtime environments, databases, application services, and complete end-user applications.

A simplified reference stack is:

• Facilities and hardware: Data centres, servers, storage, network devices, power, and cooling.
• Virtualisation and orchestration: Hypervisors, containers, schedulers, software-defined networking, and resource pools.
• Infrastructure services: Virtual machines, block and object storage, virtual networks, firewalls, and load balancers.
• Platform services: Managed databases, message queues, application runtimes, identity services, analytics platforms, and developer tools.
• Application services: Business applications delivered through web or mobile interfaces.
• Data and governance: Information, classifications, retention rules, access policies, audit records, and regulatory controls. These span all layers rather than sitting only at the top.

This layering is an analytical model, not a universal product taxonomy. A managed database, for example, is a platform service from the customer’s viewpoint, although it internally uses infrastructure and software managed by the provider. Similarly, containers may be operated directly on IaaS or consumed through a managed container platform.

The value of a layered model is that it makes control boundaries visible. Moving upward in the stack generally reduces the customer’s operational burden, but also reduces direct control over configuration, runtime behaviour, and sometimes portability.

2. Cloud Service Models

2.1 Infrastructure as a Service

IaaS provides configurable virtualised computing resources. Typical capabilities include virtual machines, virtual networks, storage volumes, load balancers, snapshots, and security groups. The customer normally selects machine sizes, operating systems, network topology, and storage characteristics.

In IaaS, the provider is responsible for the physical data centre, hardware, foundational networking, and hypervisor or equivalent virtualisation layer. The customer is generally responsible for the guest operating system, installed software, identity configuration, data, and many network and security settings.

Strengths include substantial control, support for legacy applications, flexibility in operating-system choice, and relatively straightforward migration from traditional data centres. Limitations include patching responsibilities, configuration complexity, the need for skilled administrators, and the risk of reproducing inefficient on-premises practices in a rented environment.

IaaS is suitable when an organisation needs specialised operating-system configurations, has applications that cannot use a managed runtime, or requires detailed control over network and compute resources.

2.2 Platform as a Service

PaaS supplies an application-development and execution environment. The provider manages much of the operating system, runtime, scaling infrastructure, patching, and platform availability. The customer supplies application code, configuration, data, and access policies.

Examples of PaaS capabilities include managed relational databases, application hosting platforms, integration services, development pipelines, and managed container platforms. PaaS enables teams to concentrate on business logic rather than server administration.

The principal benefit is productivity. Standardised runtimes, automated deployment, integrated observability, and managed scaling can shorten delivery cycles. The trade-off is reduced low-level control and a greater possibility of provider dependence. Application design may need to conform to the platform’s supported languages, APIs, storage models, and operational assumptions.

PaaS is particularly valuable for new applications, digital services with variable demand, and teams that need rapid delivery without maintaining extensive infrastructure expertise.

2.3 Software as a Service

SaaS delivers a complete application operated by a provider. Users normally configure the service and manage their content, identities, workflows, and authorisations rather than installing or patching the application.

Email, customer relationship management, enterprise resource planning, collaboration, and human-resource systems are common SaaS categories. SaaS can provide rapid deployment, predictable user access, continuous feature updates, and lower internal maintenance requirements.

However, SaaS does not eliminate governance. Customers remain responsible for selecting appropriate configurations, controlling user privileges, classifying and retaining data, managing integrations, and assessing contractual and regulatory obligations. A provider may secure its application infrastructure while a customer accidentally exposes sensitive records through excessive permissions.

SaaS also creates concerns about data export, service continuity, integration dependency, feature changes, and the ability to conduct independent audits. A SaaS agreement should therefore address availability commitments, incident notification, data ownership, deletion, portability, subcontractors, and termination assistance.

2.4 Function as a Service

FaaS is an event-driven execution model in which customers deploy individual functions that run in response to events such as HTTP requests, messages, file uploads, or scheduled triggers. The platform allocates execution resources dynamically and commonly charges according to invocations and execution duration, subject to provider-specific pricing rules.

FaaS can reduce idle capacity, simplify scaling, and support short, independent processing tasks. It is useful for image processing, stream reactions, data validation, scheduled automation, and API back ends. It also encourages modular architectures and rapid experimentation.

Important limitations include startup latency, execution-time limits, statelessness expectations, difficult debugging across distributed events, and possible vendor-specific dependencies. FaaS is not automatically cheaper: high-volume or continuously running workloads may be more economical on containers or virtual machines. Architects must also consider concurrency limits, retry behaviour, duplicate events, idempotency, and observability.

2.5 Comparative Evaluation

The service models can be compared across five dimensions:

| Dimension | IaaS | PaaS | SaaS | FaaS |

|---|---|---|---|---|

| Customer control | High | Moderate | Low | Moderate at code level |

| Customer operations | Servers, OS, applications | Code, data, configuration | Users, data, configuration | Functions, events, data |

| Deployment speed | Moderate | High | Very high for adoption | High for suitable tasks |

| Portability | Generally higher | Variable | Contract and data dependent | Often lower when proprietary |

| Best fit | Specialised or legacy workloads | Managed application development | Standard business capabilities | Event-driven, short tasks |

These are tendencies rather than guarantees. A poorly designed IaaS environment may be less portable than a carefully designed PaaS application, and a SaaS platform may offer excellent data export. Evaluation must therefore examine the actual architecture and contract.

3. Deployment Models

3.1 Public Cloud

A public cloud is operated by a provider for multiple customers. Resources are logically isolated using identity controls, virtual networks, encryption, hypervisors, and other mechanisms, although physical infrastructure is shared. Public cloud offers elastic capacity, extensive geographic reach, managed services, and consumption-based procurement.

Its risks include dependence on provider availability, changing prices and terms, misconfiguration, data-transfer costs, jurisdictional uncertainty, and concentration risk. Public cloud is often appropriate for internet-facing applications, variable workloads, development environments, and services that benefit from global distribution.

3.2 Private Cloud

A private cloud is dedicated to one organisation and may be operated in its own data centre or by a third party. It should provide cloud-like characteristics—such as self-service, automation, resource pooling, and measured usage—not merely traditional virtualisation.

Private cloud can support strict control, specialised hardware, predictable data location, and integration with internal systems. It may be preferred for sensitive workloads or where regulatory and operational requirements make public hosting difficult. Nevertheless, private cloud requires substantial capital, skilled staff, capacity planning, patching, physical security, and lifecycle management. It may not achieve the economies or service breadth of large public providers.

3.3 Hybrid Cloud

Hybrid cloud combines distinct private and public environments with integration and workload portability or coordinated operation. A hybrid design may place confidential data in a private environment while using public cloud for elastic analytics, or retain a core system privately while using public PaaS for customer-facing services.

Hybrid cloud is not simply “using two places.” It requires reliable identity federation, network connectivity, compatible data processes, monitoring, security policy alignment, and clearly defined workload placement. Data gravity, latency, egress charges, and inconsistent controls can make movement expensive or impractical.

3.4 Multicloud

Multicloud uses services from two or more cloud providers. Organisations may adopt it to access specialised capabilities, negotiate commercial terms, satisfy geographic requirements, improve resilience, or avoid excessive dependence on one provider.

Multicloud does not automatically create resilience. If all providers depend on the same identity system, code repository, connectivity carrier, or operational team, a common failure can still affect the entire service. Multicloud also increases complexity in governance, skills, monitoring, security tooling, networking, and cost management. It is most defensible when there is a specific risk or capability requirement rather than an abstract desire to avoid lock-in.

3.5 Sovereign Cloud

Sovereign cloud concerns control over data, infrastructure, operations, legal jurisdiction, and access by foreign entities. Requirements vary by country and sector. A sovereign arrangement may require local data residency, locally incorporated operators, screened personnel, domestic support, government-controlled encryption keys, or restrictions on foreign administrative access.

Sovereignty is multidimensional. Storing data in a country does not necessarily ensure operational sovereignty if a foreign company controls the platform, software updates, support staff, or legal access. Organisations must define which sovereignty properties matter: data location, technical control, legal control, operational control, or continuity under geopolitical disruption.

Sovereign cloud can support public-sector and critical-infrastructure obligations, but it may reduce service choice, increase cost, and complicate interoperability. Claims of sovereignty should be evaluated through contracts, technical evidence, audit rights, and jurisdictional analysis rather than marketing language.

4. Reference Architectures and Responsibility Boundaries

A reference architecture is a generic, reusable description of components, relationships, trust boundaries, and operating principles. It is not a detailed implementation. A cloud reference architecture commonly includes users and devices, identity and access management, edge protection, application services, data services, integration, observability, security operations, and governance.

A typical request path is:

1. A user or system authenticates through an identity provider.

2. A domain name resolves to an edge service or load balancer.

3. Web application protection and network controls inspect the request.

4. Application components invoke platform or infrastructure services.

5. Data services enforce encryption, access control, backup, and retention policies.

6. Logs, metrics, and traces are sent to monitoring and security-analysis systems.

7. Governance services evaluate configuration, cost, compliance, and policy continuously.

Cross-cutting controls include identity, encryption, secrets management, vulnerability management, resilience, logging, incident response, and change control. These controls should be designed from the beginning rather than added after deployment.

A useful architecture document identifies, for every component:

• owner and operator;
• information classification;
• trust boundary;
• authentication and authorisation mechanism;
• availability and recovery objectives;
• dependencies and failure modes;
• monitoring and audit evidence;
• deployment and rollback process; and
• exit or migration approach.

5. The Shared-Responsibility Model

The shared-responsibility model states that cloud security and operational assurance are divided between provider and customer. The provider secures the cloud infrastructure and services it operates. The customer secures what it places in or configures on that cloud. The exact boundary changes with the service model.

For a conventional IaaS virtual machine, the provider normally protects facilities, hardware, hypervisor, and foundational services. The customer normally patches the guest operating system, secures applications, manages identities, configures network rules, protects data, and maintains backups where required.

For PaaS, the provider additionally manages the operating system and runtime platform. The customer remains responsible for code, data, identities, configuration, and appropriate use of the service.

For SaaS, the provider manages the application and most underlying technology. The customer still controls users, roles, data classification, sharing settings, integration credentials, and organisational processes.

For FaaS, the provider manages servers and execution infrastructure, while the customer secures function code, dependencies, event permissions, secrets, data, and business logic. The customer must also design for retries and partial failure.

The model is better represented as a responsibility matrix than as a slogan. Responsibilities may be:

• Provider responsibility: implemented and operated by the provider.
• Customer responsibility: implemented and operated by the customer.
• Shared or configurable responsibility: dependent on the selected service and configuration.
• Contractual responsibility: defined by service agreements, regulations, and organisational policy.

A provider’s certification does not transfer all responsibility. Compliance reports may demonstrate that certain controls exist, but customers must determine whether those controls address their own risks and whether customer-configured controls are correctly implemented.

6. Decision Framework for Selecting Models

A postgraduate-level evaluation should balance more than technical convenience. The following criteria are useful:

Business fit: Does the model support required features, service levels, growth, and time to market?

Control and customisation: Does the organisation need operating-system, network, hardware, or deployment control?

Security and compliance: What are the data classification, residency, audit, encryption, retention, and access requirements?

Resilience: What are the recovery-time objective and recovery-point objective? Are dependencies geographically and operationally independent?

Economics: Consider subscription or consumption charges, migration, staff, support, network transfer, licensing, backup, and exit costs. A low unit price does not guarantee a low total cost of ownership.

Skills and operating model: Can the organisation monitor, patch, secure, and govern the chosen model? A technically suitable platform may fail if the required skills are unavailable.

Portability and reversibility: Can data and applications be exported in usable formats? Are interfaces documented? Can the organisation operate temporarily without the provider?

Strategic and geopolitical exposure: Could provider concentration, sanctions, legal access, or regional disruption affect continuity?

A practical method is to create a weighted decision matrix. Let each criterion receive a weight whose total is 1, and assign each candidate a score on a consistent scale, such as 1 to 5. The weighted score is the sum of each weight multiplied by its score. This method does not produce an objective truth; it makes assumptions explicit and supports sensitivity analysis. Scores should be supported by evidence and reviewed by security, engineering, finance, legal, and business stakeholders.

7. Illustrative Case: National Health Services Portal

Background

A fictional national health agency operates appointment scheduling, laboratory-result access, and clinician messaging. Its existing data centre is approaching capacity. Demand varies significantly during public-health events, and the agency must comply with strict health-data and residency requirements.

Problem

The agency needs elastic public access and faster development, but it cannot expose identifiable health information to uncontrolled jurisdictions. It also has legacy systems that cannot immediately be redesigned. A single public-cloud strategy may create sovereignty and concentration concerns; a fully private strategy may be costly and unable to handle sudden demand.

Analysis

The portal’s public web tier is relatively stateless and experiences highly variable demand. Appointment and messaging services require strong identity, auditability, and integration with internal systems. Health records require strict classification, encryption, retention, and access controls. The agency also needs tested recovery procedures and evidence for regulators.

Approach and Solution

The agency adopts a controlled hybrid architecture:

• A sovereign or domestically operated private environment stores identifiable clinical data and hosts the core record system.
• A public-cloud edge service provides denial-of-service protection, content delivery, and elastic handling of non-sensitive public information.
• A PaaS integration layer exchanges only the minimum required data through authenticated, encrypted interfaces.
• Selected event processing uses FaaS, but functions receive short-lived credentials and no unnecessary access to clinical databases.
• A central identity service applies multifactor authentication and role-based access.
• Immutable audit logs are retained according to policy, with security monitoring across both environments.
• Infrastructure is defined as code, and deployment pipelines require security testing, peer approval, and rollback capability.
• Contracts specify data location, subcontractors, breach notification, audit evidence, support jurisdiction, deletion, and exit assistance.

The architecture uses data minimisation: the public tier receives tokens and limited appointment information rather than complete clinical records. Connectivity is redundant, and recovery exercises test both technical restoration and manual clinical procedures.

Outcome

The design provides elasticity for public traffic while preserving tighter control over sensitive records. It does not eliminate complexity: the agency must operate identity federation, integration, monitoring, and two governance environments. Its success therefore depends on disciplined operating processes rather than architecture diagrams alone.

Learning Points

1. Deployment models should follow data and risk characteristics, not organisational fashion.

2. Hybrid architecture is useful only when integration and responsibility boundaries are explicit.

3. Data minimisation can reduce both privacy risk and technical coupling.

4. Sovereignty must be assessed across legal, operational, and technical dimensions.

5. Resilience requires tested procedures and independent dependencies, not merely multiple locations.

8. Challenges, Governance, and Ethical Issues

Cloud concentration can create systemic risk when many organisations depend on a small number of providers. A major outage, supply-chain compromise, or policy change may affect entire sectors. Organisations should assess concentration risk and maintain proportionate contingency plans.

Privacy risks include excessive collection, secondary use, unclear retention, cross-border transfer, and privileged administrative access. Ethical cloud governance requires purpose limitation, transparency, least privilege, accountability, and respect for affected individuals. Automated analytics and AI services require additional scrutiny because data may be used for model training, inferences may be difficult to explain, and errors can affect access to essential services.

Other governance concerns include environmental impact, electronic waste, labour practices in supply chains, accessibility, public-sector procurement fairness, and the use of surveillance capabilities. Carbon-aware scheduling and efficient architectures can reduce environmental impact, but environmental claims should be supported by credible measurement.

Organisations should maintain a cloud governance framework covering identity, data classification, approved services, architecture review, logging, vulnerability management, financial controls, incident response, supplier management, and exit planning. Policies should be enforceable through automated controls where possible.

9. Contemporary Developments and Best Practices

Cloud-native architectures increasingly combine managed Kubernetes, serverless services, event streaming, API gateways, and policy-as-code. Platform engineering teams provide internal platforms that standardise secure deployment while preserving developer productivity. Confidential-computing technologies aim to protect data during processing using hardware-supported trusted execution environments, although their assurance, performance, and operational limitations must be evaluated.

Edge computing places processing closer to users, sensors, or industrial equipment to reduce latency and bandwidth use. It introduces additional physical, patching, and fleet-management challenges. Artificial-intelligence workloads are driving demand for specialised accelerators and managed model services, raising questions about cost, data governance, reproducibility, and model portability.

Best practices include:

• start with business and risk requirements rather than product features;
• classify data before selecting a service;
• use least privilege, multifactor authentication, and short-lived credentials;
• automate infrastructure, policy, testing, and evidence collection;
• design for failure and test restoration regularly;
• monitor cost, performance, security, and reliability together;
• document provider dependencies and maintain usable exit plans;
• use open interfaces and portable data formats where practical;
• review third-party and subcontractor risk;
• assign named owners for every control and dependency.

Chapter Summary

Cloud service models describe the level of abstraction delivered by a provider. IaaS offers substantial control but leaves significant administration to the customer. PaaS reduces infrastructure operations and accelerates development, while introducing platform constraints. SaaS provides complete applications but leaves customers responsible for data, identities, configuration, and governance. FaaS supports event-driven execution and elastic scaling, but requires careful treatment of latency, retries, observability, and portability.

Public, private, hybrid, multicloud, and sovereign cloud describe different ownership, location, governance, and control arrangements. No model is universally superior. Selection should consider business fit, control, security, compliance, resilience, economics, skills, portability, and geopolitical exposure.

Reference architectures make components, dependencies, trust boundaries, and cross-cutting controls visible. The shared-responsibility model clarifies that provider security does not remove customer obligations. Effective cloud governance combines technical controls, contracts, audit evidence, organisational accountability, ethical safeguards, and tested recovery and exit procedures.

Key Terms

Cloud computing: Delivery of computing capabilities through shared, programmable, and usually metered services.

IaaS: Cloud provision of virtualised compute, storage, and networking resources.

PaaS: Managed application-development and runtime platform.

SaaS: Complete software application delivered and operated by a provider.

FaaS: Event-driven execution of individual functions without customer-managed servers.

Public cloud: Provider-operated, multitenant cloud available to multiple customers.

Private cloud: Cloud environment dedicated to one organisation.

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

Multicloud: Use of services from two or more cloud providers.

Sovereign cloud: Cloud arrangement designed to satisfy specified legal, operational, and technical sovereignty requirements.

Reference architecture: Reusable conceptual design showing components, relationships, and controls.

Shared responsibility: Allocation of security and operational duties between provider and customer.

Data residency: Physical or legal requirement concerning where data is stored or processed.

Data sovereignty: Control of data according to applicable jurisdiction and authority.

Portability: Ability to move applications, data, or workloads between environments.

Vendor lock-in: Difficulty or cost associated with changing provider or technology.

Recovery-time objective: Target time for restoring a service after disruption.

Recovery-point objective: Maximum acceptable period of data loss measured in time.

Infrastructure as code: Machine-readable definition and management of infrastructure configuration.

Least privilege: Granting only the access necessary for an identity or process.

Review Questions

Short Answer Questions

1. What is the principal distinction between IaaS and PaaS?

2. Why does SaaS adoption not eliminate customer security responsibilities?

3. Define hybrid cloud and identify one challenge associated with it.

4. What does the shared-responsibility model allocate?

5. Why is data residency not sufficient to establish complete cloud sovereignty?

Long Answer Questions

1. Compare IaaS, PaaS, SaaS, and FaaS in terms of control, operational responsibility, portability, and suitable workloads.

2. Explain the advantages and limitations of public, private, hybrid, and multicloud deployment models.

3. Describe how a reference architecture can support security, resilience, and governance.

4. Discuss the technical and contractual controls required when adopting a SaaS application for sensitive organisational data.

5. Explain why a multicloud strategy may increase rather than reduce operational risk.

Analytical / Application Questions

1. A financial institution must retain sensitive customer records in its national jurisdiction but requires globally scalable fraud-analysis services. Recommend a deployment and service-model combination, and justify the trust boundaries and data flows.

2. An organisation proposes moving every workload to FaaS to eliminate server management. Critically evaluate this proposal, including workload suitability, cost, observability, latency, portability, and security.

3. Construct a responsibility matrix for a PaaS-hosted web application. Identify at least five provider responsibilities and five customer responsibilities, and explain how an incorrectly configured customer control could cause a security incident.

Multiple Choice Questions with Answers

Question 1

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

A. Software as a Service

B. Function as a Service

C. Platform as a Service

D. Infrastructure as a Service

Correct Answer: D. Infrastructure as a Service

Question 2

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

A. Maintaining the provider’s physical servers

B. Configuring user access and data-sharing permissions

C. Patching the provider’s hypervisor

D. Replacing failed storage hardware

Correct Answer: B. Configuring user access and data-sharing permissions

Question 3

What is the defining characteristic of FaaS?

A. Dedicated physical servers for every customer

B. Event-triggered execution of individual functions

C. Manual installation of operating systems by users

D. Delivery of complete business applications

Correct Answer: B. Event-triggered execution of individual functions

Question 4

Which deployment model combines private and public cloud environments?

A. Hybrid cloud

B. Private cloud

C. Sovereign cloud

D. Community cloud

Correct Answer: A. Hybrid cloud

Question 5

Why does using two cloud providers not automatically guarantee resilience?

A. Cloud providers cannot use encryption

B. Common dependencies may still create a single failure point

C. Multicloud environments cannot use identity services

D. Public clouds cannot host redundant applications

Correct Answer: B. Common dependencies may still create a single failure point

Question 6

Which statement best describes sovereign cloud?

A. A cloud used only for scientific computing

B. A cloud that always uses physical servers owned by customers

C. An arrangement addressing legal, operational, and technical control requirements

D. A cloud with no shared infrastructure

Correct Answer: C. An arrangement addressing legal, operational, and technical control requirements

Question 7

In a conventional IaaS deployment, who usually patches the guest operating system?

A. The customer

B. The internet service provider

C. The hardware manufacturer only

D. The cloud auditor

Correct Answer: A. The customer

Question 8

Which factor is a cross-cutting concern in a cloud reference architecture?

A. Identity and access management

B. Screen resolution of end-user devices only

C. Office furniture allocation

D. Printer cartridge capacity

Correct Answer: A. Identity and access management

Question 9

What is the main purpose of an exit plan?

A. To increase dependence on proprietary interfaces

B. To define how services and data can be transitioned or recovered

C. To eliminate all cloud monitoring

D. To prevent contractual review

Correct Answer: B. To define how services and data can be transitioned or recovered

Question 10

Which practice most directly supports least privilege?

A. Giving all administrators permanent unrestricted access

B. Using short-lived credentials and narrowly scoped permissions

C. Sharing one account across a development team

D. Disabling audit logging

Correct Answer: B. Using short-lived credentials and narrowly scoped permissions