Cloud computing is not a single technology or purchasing arrangement. It is a set of architectural and operational models for obtaining computing capabilities—such as processing, storage, networking, databases, application platforms, and complete software products—over a network. Choosing an appropriate model affects cost, security, compliance, performance, operational responsibility, portability, and the speed at which an organisation can deliver services.

Two classifications are especially important. Service models describe what the provider delivers and what the customer must manage. Deployment models describe where cloud resources are hosted, who can access them, and how they are governed. IaaS, PaaS, SaaS, and serverless are service-oriented models. Public, private, hybrid, multi-cloud, community, edge, and sovereign cloud are deployment or location-and-governance models. In practice, these categories can be combined: an organisation may run a serverless application on a public cloud, a private cloud, or a sovereign cloud region.

Learning Objectives

1. The Shared-Responsibility Foundation

Cloud adoption does not transfer every responsibility to the provider. Responsibility is divided between the provider and customer. The exact boundary varies by provider and service, but a useful progression is:

Model	Provider commonly manages	Customer commonly manages
IaaS	Facilities, physical hardware, virtualisation	Operating system, patches, applications, data, configuration
PaaS	Infrastructure, operating system, runtime, scaling mechanisms	Application code, data, identities, application configuration
SaaS	Application and nearly all underlying technology	Users, access policies, data use, configuration, governance
Serverless	Infrastructure, runtime, scaling, much operational capacity	Functions, event logic, permissions, data, application design

This table is a generalisation rather than a contract. For example, a managed database may be delivered as a platform service while the customer remains responsible for schemas, identities, retention, and the accuracy of data. Security is therefore a shared responsibility, not a feature that can be delegated without review.

A further distinction is useful. The provider is generally responsible for security of the cloud—such as physical facilities, core hardware, and managed-service infrastructure—whereas the customer is responsible for security in the cloud, including credentials, data classification, network rules, application vulnerabilities, and appropriate configurations. Poor configuration can expose data even when the provider’s infrastructure is secure.

2. Cloud Service Models

2.1 Infrastructure as a Service

Infrastructure as a Service (IaaS) supplies virtual machines, block and object storage, virtual networks, load balancers, and related infrastructure through programmable interfaces or portals. The customer selects operating systems, installs software, and controls much of the network and compute configuration.

IaaS is appropriate when an organisation needs substantial control, must migrate existing applications with limited redesign, or requires specialised operating-system and network settings. It is also useful for development laboratories, disaster-recovery environments, and workloads that cannot yet be refactored.

Its disadvantages include patching obligations, configuration complexity, capacity planning, vulnerability management, and the need for skilled administrators. A virtual machine may be easy to create but difficult to operate securely over its full life cycle.

2.2 Platform as a Service

Platform as a Service (PaaS) provides a managed environment for developing, deploying, and operating applications. The provider typically manages the operating system, language runtime, application server, patching, and some scaling functions. The customer focuses primarily on code, application configuration, identities, and data.

PaaS can accelerate delivery because developers do not need to build an operating-system and runtime platform for every application. It commonly supports web applications, APIs, managed databases, message queues, and integration services.

The principal trade-off is reduced control. Applications may depend on provider-specific APIs, runtime versions, deployment processes, or data services. A team should examine portability, service limits, observability, backup options, and exit procedures before making a PaaS dependency central to its architecture.

2.3 Software as a Service

Software as a Service (SaaS) delivers a complete application, usually through a web interface or API. The provider operates the application, infrastructure, updates, and much of the security administration. Examples include collaboration, customer relationship management, email, accounting, and human-resources applications.

SaaS reduces infrastructure administration and can provide rapid access to mature business capabilities. However, customers still manage user life cycles, roles, data quality, retention, integrations, contractual controls, and appropriate use. They must also investigate data export, service availability, tenant isolation, audit logging, incident notification, and regulatory commitments.

SaaS is not automatically cheaper. Subscription charges, integration work, storage or transaction charges, premium security features, and exit costs should be included in the business case.

2.4 Serverless Computing

Serverless computing is an operational model in which the provider manages servers and automatically allocates execution resources. Customers commonly deploy short-lived functions triggered by events, HTTP requests, queues, schedules, or changes in storage. Serverless does not mean that servers do not exist; it means that customers do not directly provision or administer them.

Serverless is well suited to event processing, APIs with variable traffic, automation, file transformation, notifications, and rapid prototypes. It can reduce idle-capacity management and align charges with invocation or resource use. It may also improve elasticity for irregular workloads.

Important limitations include execution-time limits, startup latency, concurrency limits, distributed debugging, complex state management, and potentially high costs under sustained or unpredictable load. Serverless applications often require managed databases, queues, identity services, and monitoring, so architecture can become distributed even when the code is small.

Serverless is best understood as complementary to IaaS, PaaS, and SaaS rather than a completely separate layer. A serverless function may use a PaaS database and invoke a SaaS service while running on public-cloud infrastructure.

3. Deployment and Location Models

3.1 Public Cloud

A public cloud is operated by a provider for multiple customers. Resources may be logically isolated while physical infrastructure is shared. Public clouds offer broad service catalogues, global regions, elastic capacity, and consumption-based purchasing.

Strengths include rapid provisioning, access to specialist services, geographic reach, and reduced need for capital investment. Concerns include dependence on provider availability, changing prices, configuration risk, data-residency requirements, and possible vendor lock-in. Public cloud security depends heavily on identity management, network design, encryption, logging, and continuous configuration control.

3.2 Private Cloud

A private cloud is dedicated to one organisation. It may be hosted in the organisation’s own data centre or by a third party. Private cloud technology can provide self-service, automation, resource pooling, and measured usage without sharing the environment with unrelated tenants.

Private cloud can support sensitive workloads, specialised hardware, predictable control requirements, or legacy integration. Nevertheless, dedicated infrastructure does not automatically provide cloud characteristics. A manually managed virtualisation cluster with no self-service, automation, or elastic operation may be a data centre rather than a mature private cloud.

Private cloud normally requires greater capital, specialist staff, maintenance, capacity planning, and hardware refresh management than public cloud.

3.3 Hybrid Cloud

Hybrid cloud combines private infrastructure with one or more public-cloud environments through controlled integration. A workload may remain on private infrastructure while using public cloud for burst capacity, analytics, backup, or selected services.

Hybrid designs are useful when data residency, latency, existing investment, or migration constraints prevent complete public-cloud adoption. They are operationally demanding: identity, networking, monitoring, security policies, data movement, and recovery processes must work across boundaries. Hybrid cloud is not merely having both environments; meaningful integration and coordinated management are required.

3.4 Multi-Cloud

Multi-cloud uses services from two or more cloud providers. Organisations may select a provider with the best capability for a particular workload, reduce dependence on one supplier, meet geographic requirements, or use an acquired company’s existing platform.

Multi-cloud can improve negotiation leverage and provide access to specialised services. However, it does not automatically improve resilience. If all providers depend on the same identity system, network carrier, software library, or operational team, a common failure can still affect every environment. Multi-cloud also increases skills requirements, monitoring complexity, governance effort, and data-transfer costs.

A deliberate multi-cloud strategy should define why multiple providers are necessary, which capabilities are portable, how identities are federated, and how applications and data can be recovered.

3.5 Community Cloud

A community cloud is designed for organisations that share a mission, regulatory context, security requirement, or operational concern. Participants may include public-sector bodies, healthcare organisations, research institutions, or financial entities.

The model can support common controls, sector-specific services, and shared investment. Its difficulties include agreeing on governance, funding, service priorities, liability, data ownership, and membership rules. “Community” must be defined institutionally; a group of unrelated tenants using the same public provider is not necessarily a community cloud.

3.6 Edge Cloud

Edge cloud places computing, storage, or selected cloud services close to users, devices, or data sources. The objective is often to reduce latency, lower bandwidth use, support local operation, or process data before transmission to a central region.

Applications include industrial control, connected vehicles, retail analytics, telecommunications, smart campuses, and remote sites. Edge environments are more physically distributed and may have limited power, intermittent connectivity, smaller teams, and greater physical-tampering risk. They require strong remote management, secure boot, local failure handling, synchronisation, and consistent software deployment.

Edge is a location and architectural pattern, not necessarily a different commercial service model. Edge nodes may run virtual machines, containers, PaaS components, or serverless functions.

3.7 Sovereign Cloud

A sovereign cloud is designed to meet a jurisdiction’s requirements for control over data, operations, personnel, legal authority, and technology supply chains. Sovereignty may concern where data is stored, where it is processed, who can administer the environment, which laws apply, and whether foreign access or provider dependency is acceptable.

Sovereignty is therefore broader than data residency. Storing data in a country does not necessarily ensure that foreign-controlled operators, support personnel, encryption keys, or parent-company legal obligations are excluded. Organisations must examine contractual terms, technical controls, ownership, operational location, support access, audit rights, and exit arrangements.

Sovereign clouds may provide valuable assurance for government, defence, critical infrastructure, and regulated sectors, but they can have a smaller service catalogue, higher costs, and limited geographic flexibility.

4. A Practical Selection Framework

A sound selection process begins with the workload rather than with a fashionable cloud label. The following questions are useful:

A simple qualitative scoring matrix can compare alternatives. For each criterion, assign a weight from 1 to 5 and a suitability score from 1 to 5. The weighted total is calculated as:

Here, S is the total suitability score, wᵢ is the importance weight for criterion i, and rᵢ is the option’s rating for that criterion. Both scales must be defined consistently; a high score should always mean greater suitability. This method supports discussion but does not replace security review, legal analysis, proof-of-concept testing, or total-cost analysis.

where Cₚ is platform or infrastructure cost, Cₒ is operations and personnel cost, Cₙ is network and data-transfer cost, Cₛ is security and compliance cost, Cₘ is migration cost, and Cₑ is expected exit or transition cost. These are monetary values measured over the same period. The estimate should state assumptions about usage, price changes, staffing, and growth.

5. Worked Selection Example

An illustrative regional clinic needs a patient appointment system. It handles personally identifiable information, requires ordinary web performance, has moderate demand, and must comply with national health-data rules. The clinic has few infrastructure specialists but has experienced application developers.

A pure IaaS solution provides control but creates substantial patching and security responsibilities. A general public SaaS appointment product may reduce administration, but only if its data location, audit functions, integration capability, retention controls, and contractual terms satisfy health requirements. A compliant PaaS deployment in an approved region may provide a useful balance: developers retain control of application logic while the provider manages much of the operating platform. A sovereign or community cloud may be preferable if the regulator requires domestic operational control or sector-specific governance.

The recommendation should therefore be conditional rather than automatic: select a certified managed platform or SaaS product only after verifying regulatory scope, access controls, encryption, audit evidence, backup restoration, breach notification, and data export. The decision is driven not simply by technical convenience but by risk, responsibility, and evidence.

6. Case Study: A Manufacturer’s Hybrid and Edge Architecture

Background. An illustrative manufacturing company operates factories with robotic equipment. Production lines need rapid responses even when the wide-area connection is unavailable. Corporate analysts need consolidated data for maintenance forecasting.

Problem. Sending every sensor reading to a distant public-cloud region creates unnecessary bandwidth use and may introduce unacceptable control latency. Keeping all analytics inside each factory makes model management and cross-site comparison difficult.

Analysis. The control loop should remain local because it requires predictable response and continued operation during connectivity failures. Less time-sensitive data can be filtered and aggregated at the factory edge. Corporate analytics benefit from centralised storage and managed machine-learning services. The company also has a policy requiring separation between production-control networks and corporate systems.

Approach. The company deploys an edge platform at each factory for local control support, buffering, and preliminary anomaly detection. A private network segment isolates industrial devices. Selected data is securely transmitted to a public-cloud PaaS environment for fleet-wide analytics. Identity is federated, devices use certificates, software images are signed, and operations teams monitor both edge and central components. The architecture includes store-and-forward behaviour so temporary connectivity loss does not destroy measurements.

Outcome. The design reduces unnecessary data transfer and preserves local operation while allowing central analysis. It also introduces new obligations: edge devices require inventory, patching, physical protection, clock synchronisation, certificate rotation, and tested recovery procedures.

Learning points. Deployment choices should follow latency and failure requirements. Hybrid and edge architectures can solve real constraints, but they increase integration and governance complexity. Resilience must include degraded operation, not only central-cloud redundancy.

7. Challenges, Governance, and Contemporary Practice

Vendor lock-in and portability

Lock-in can result from proprietary databases, identity services, event formats, network designs, and operational knowledge. Portability is not always the best objective: specialised services may produce substantial business value. The professional question is whether dependency is understood, justified, documented, and supported by an exit plan.

Security and privacy

Least-privilege access, multifactor authentication, encryption, key management, secure configuration baselines, vulnerability management, central logging, and tested incident response are foundational. Privacy requires lawful processing, purpose limitation, minimisation, retention control, and appropriate international-transfer safeguards where applicable.

Reliability and concentration risk

A provider’s published availability does not guarantee application availability. Applications may fail because of incorrect permissions, exhausted quotas, faulty deployments, unavailable dependencies, or regional disruption. Designs should identify single points of failure and test restoration rather than relying only on contractual service-level objectives.

Financial and operational governance

FinOps practices help teams monitor consumption, allocate costs, set budgets, remove idle resources, and choose suitable purchasing commitments. Governance should also cover tagging, ownership, approved regions, service catalogues, architecture review, and automated policy enforcement.

AI-enabled cloud services

Cloud providers increasingly offer managed artificial-intelligence services. These can accelerate development but introduce questions about training-data use, model location, intellectual property, explainability, bias, prompt and output retention, and human oversight. An organisation should not place regulated or confidential data into an AI service until contractual and technical controls are verified. AI may assist monitoring and optimisation, but automated actions require safeguards and review.

Best-practice checklist

Chapter Summary

Service models determine how much technology the provider manages. IaaS offers control with significant operational responsibility; PaaS manages much of the platform and accelerates application delivery; SaaS delivers a complete application; and serverless abstracts infrastructure and supports event-driven execution. Deployment models determine hosting, access, location, and governance. Public cloud provides scale and breadth, private cloud provides dedicated control, hybrid cloud integrates environments, multi-cloud uses multiple providers, community cloud serves a shared sector or mission, edge cloud places processing near users or devices, and sovereign cloud addresses jurisdictional and operational control.

No model is universally superior. Selection should consider data sensitivity, compliance, latency, elasticity, skills, cost, portability, resilience, governance, and exit requirements. Cloud architecture is therefore a business and risk decision as well as a technical decision. Effective practice combines clear responsibility boundaries, disciplined security, tested recovery, cost governance, and evidence-based evaluation.

Key Terms

Cloud computing: On-demand network access to shared configurable computing resources.

Service model: A description of the capabilities supplied by a provider and responsibilities retained by the customer.

Deployment model: A description of where cloud resources operate, who accesses them, and how they are governed.

IaaS: Provision of virtualised infrastructure such as compute, storage, and networking.

PaaS: A managed application platform that reduces responsibility for operating systems and runtimes.

Serverless: An execution model in which the provider manages servers and dynamically allocates resources.

Public cloud: Provider-operated infrastructure shared logically among multiple customers.

Community cloud: Cloud designed for organisations sharing sectoral or mission requirements.

Edge cloud: Cloud processing located close to users, devices, or data sources.

Sovereign cloud: Cloud designed to satisfy jurisdictional requirements for control, location, and operation.

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

Vendor lock-in: Difficulty or cost involved in moving away from a provider or proprietary service.

Data residency: The geographic location in which data is stored or processed.

Total cost of ownership: Combined cost of acquiring, operating, securing, migrating, and exiting a solution.

Review Questions

Short Answer Questions

Long Answer Questions

Analytical / Application Questions

Multiple Choice Questions with Answers

Question 1

Which service model generally leaves the customer responsible for the operating system?

Question 2

Question 3

Correct Answer: B. Customers do not directly provision or administer servers

Question 4

Which deployment model combines private infrastructure with public-cloud services through integration?

Question 5

Question 6

Correct Answer: B. Applications may still share common dependencies or failure points

Question 7

Correct Answer: A. Whether data and operations meet jurisdictional control requirements

Question 8

Question 9

Correct Answer: B. An event-driven image-processing task with irregular demand

Question 10

Correct Answer: C. It commonly requires more capital and specialist operational capability

Chapter 2 Cloud Service and Deployment Models

Cloud Service and Deployment Models

Introduction