3. Cloud Computing Models and Platforms

Introduction and Context

Cloud computing has changed the way organisations acquire computing power, store data, develop applications, and deliver analytical services. Instead of purchasing and maintaining all infrastructure within a local data centre, an organisation can obtain technology resources over a network as a configurable service. This shift is especially important in big data and cloud analytics, where workloads may vary greatly in size, require specialised hardware, and involve large volumes of distributed data.

Cloud computing is not simply the relocation of servers to a provider’s premises. It represents a set of operating models, service responsibilities, architectural techniques, and economic arrangements. A data science team may use infrastructure services to create a distributed processing cluster, a managed platform to train machine-learning models, a software service to visualise data, or serverless functions to execute event-driven transformations. Each choice transfers different responsibilities to the cloud provider and leaves different responsibilities with the customer.

The central managerial and technical question is therefore not whether an organisation should use “the cloud” in general. It is which deployment model, service model, platform architecture, and governance approach best support a particular business and analytical requirement. This chapter develops a framework for making that decision.

Learning Objectives

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

1. Explain the characteristics and strategic implications of cloud computing.

2. Compare public, private, hybrid, and multi-cloud deployment environments.

3. Distinguish IaaS, PaaS, SaaS, and serverless computing according to responsibility and control.

4. Describe the roles of virtual machines, containers, and orchestration platforms.

5. Identify major categories of cloud analytics services.

6. Evaluate cloud choices in relation to cost, performance, security, compliance, portability, and governance.

7. Apply cloud concepts to a realistic big data and analytics scenario.

Cloud Computing as an Operating Model

A widely used definition of cloud computing describes it as on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with limited provider interaction. Five characteristics are especially significant.

On-demand self-service allows authorised users or applications to provision resources without manually negotiating with an infrastructure team. Broad network access makes services available through standard networks and devices. Resource pooling allows a provider to serve many customers from a common physical infrastructure while logically separating their environments. Rapid elasticity permits capacity to expand or contract as demand changes. Measured service enables usage to be monitored, controlled, and commonly billed according to consumption.

These characteristics distinguish cloud computing from traditional outsourcing. A conventional outsourced data centre may still involve fixed capacity, lengthy procurement, and manually configured systems. Cloud services, by contrast, are designed for programmability and automation. Infrastructure can be represented as code, environments can be reproduced, and operational policies can be applied automatically.

Cloud economics also differ from traditional capital expenditure. In an on-premises environment, an organisation generally purchases hardware in advance and depreciates it over time. Cloud computing can convert some of this expenditure into operating expenditure based on usage. This does not guarantee lower cost. Elasticity may reduce waste for variable workloads, but poorly governed consumption, data transfer charges, idle resources, and duplicated services can make cloud environments expensive.

A further characteristic is the shared responsibility model. The provider is responsible for the security and operation of the underlying cloud infrastructure, while the customer remains responsible for elements such as identity management, data classification, application configuration, and access permissions. The exact boundary changes according to the service model. Using a managed database does not remove the customer’s responsibility to configure access controls or protect sensitive information.

Deployment Models: Where and Under Whose Control?

Public Cloud

A public cloud is operated by a third-party provider and offers resources to multiple customers through shared physical infrastructure. Customers usually obtain services through portals, command-line tools, or application programming interfaces. Major providers offer computing, storage, databases, networking, security, artificial intelligence, and analytics services at global scale.

The public cloud is attractive when an organisation needs rapid provisioning, global reach, elastic capacity, or access to advanced managed services. A start-up can experiment without purchasing a data centre, while an established organisation can expand a seasonal analytics workload for a limited period. The principal trade-offs include dependence on provider pricing and architecture, possible regulatory restrictions, network dependence, and the need for strong configuration governance.

Multi-tenancy does not mean that customers’ data is openly mixed. Providers use logical isolation, identity controls, encryption, and network mechanisms to separate environments. Nevertheless, customers must evaluate the provider’s security controls, certifications, service-level commitments, data-location options, and incident-response processes.

Private Cloud

A private cloud is a cloud environment dedicated to one organisation. It may be hosted within the organisation’s own facilities or by a specialised provider. Private clouds can provide greater control over infrastructure, network design, data location, and specialised security requirements. They may be appropriate for highly regulated workloads, legacy integration, or organisations that require consistent control over hardware.

However, private cloud does not automatically mean greater security or lower cost. The organisation must finance capacity, maintain hardware and software, operate skilled teams, and implement the automation expected of a cloud environment. Without self-service, resource pooling, monitoring, and rapid provisioning, a private data centre may simply be conventional infrastructure with a new label.

Hybrid Cloud

Hybrid cloud combines private infrastructure with one or more public cloud environments and permits movement or coordinated operation of data and workloads between them. A common pattern is to retain sensitive transactional data in a controlled environment while using public cloud resources for large-scale model training or temporary analytical capacity.

Hybrid architectures are useful when organisations face data-residency constraints, legacy-system dependencies, or a gradual migration strategy. They are also complex. Secure connectivity, consistent identity, data synchronisation, workload placement, monitoring, and operational responsibility must be designed carefully. Moving computation to the cloud while repeatedly transferring large datasets back to local systems may create latency and cost problems.

Multi-Cloud

Multi-cloud means using services from two or more public cloud providers. It may be deliberate, as when an organisation selects a specialised machine-learning service from one provider and a regional infrastructure service from another. It may also emerge through independent departmental purchases.

Multi-cloud can improve negotiating flexibility, resilience, geographic coverage, and access to specialised capabilities. It can also increase complexity in identity management, networking, skills, observability, data movement, and compliance. Portability should therefore be treated as an architectural objective requiring investment, not as an automatic consequence of using multiple providers.

A useful distinction is that hybrid cloud concerns the relationship between different types of environments, whereas multi-cloud concerns the use of multiple cloud providers. An organisation may operate both a hybrid and multi-cloud architecture.

Service Models and the Distribution of Responsibility

Service models describe what the provider supplies and what the customer must manage. They are best understood as a continuum of control rather than four completely isolated categories.

Infrastructure as a Service

Infrastructure as a Service, or IaaS, provides virtualised computing, storage, and networking resources. The customer generally controls the operating system, installed software, applications, and much of the network configuration. The provider manages physical facilities, servers, and foundational virtualisation.

IaaS offers flexibility and is useful for customised applications, migration of existing systems, experimental clusters, and workloads requiring operating-system control. Its disadvantage is operational responsibility. Customers must patch systems, configure firewalls, manage backups, harden virtual machines, and monitor performance. An IaaS-based big data cluster may provide maximum flexibility but also demands substantial engineering expertise.

Platform as a Service

Platform as a Service, or PaaS, supplies a managed environment for developing and running applications. The provider manages the operating system, runtime, scaling mechanisms, and often middleware, while the customer concentrates on application code, configuration, and data.

PaaS can accelerate development because teams do not need to build routine infrastructure. Managed data warehouses, notebook environments, streaming platforms, and machine-learning development platforms often have PaaS characteristics. The trade-off is reduced low-level control and potential dependence on provider-specific interfaces. Application teams should examine export facilities, supported standards, and the cost of leaving the platform.

Software as a Service

Software as a Service, or SaaS, delivers a complete application through a browser or application interface. The provider manages the infrastructure, platform, application updates, and much of the availability architecture. The customer manages users, business configuration, data usage, and access policies.

Examples include collaborative office software, customer relationship systems, enterprise resource planning systems, and hosted business-intelligence applications. SaaS usually offers the fastest route to business capability, but it provides the least technical control. Organisations must assess data ownership, integration options, retention, auditability, vendor continuity, and the ability to extract data in usable formats.

Serverless Computing

Serverless computing abstracts server management almost entirely. Developers deploy functions or services that execute in response to events, requests, schedules, or messages. The provider allocates capacity dynamically and commonly charges according to execution or resource consumption.

Serverless is well suited to event-driven ingestion, lightweight transformations, API back ends, scheduled data-quality checks, and workflow triggers. It can reduce idle capacity and operational effort. Limitations include execution-time restrictions, cold-start latency, complex distributed debugging, provider-specific programming models, and unpredictable costs under poorly controlled event volumes. “Serverless” does not mean that servers do not exist; it means that their management is largely hidden from the customer.

Virtualisation, Containers, and Orchestration

Cloud platforms depend on abstraction technologies that separate applications from physical hardware. Virtualisation uses a hypervisor to divide a physical machine into virtual machines. Each virtual machine can run its own operating system and applications. Virtual machines provide strong isolation and support different operating systems on common hardware, but they include operating-system overhead and usually start more slowly than containers.

Containers package an application together with its dependencies while sharing the host operating system kernel. They are generally lighter and faster to start than virtual machines, making them useful for microservices, reproducible analytical environments, and continuous delivery. A container is not a complete security boundary in the same sense as a virtual machine; isolation depends on the container runtime, host configuration, image integrity, and platform controls.

Container images should be built from trusted minimal base images, scanned for vulnerabilities, signed where appropriate, and kept free of embedded secrets. Reproducibility also requires versioned dependencies and controlled build pipelines.

When many containers must be deployed across multiple machines, manual management becomes impractical. Orchestration platforms schedule containers, restart failed workloads, expose services, manage configuration, support scaling, and coordinate rolling updates. Kubernetes is a prominent example, although managed container services and simpler orchestration tools are also widely used.

Orchestration introduces its own complexity. Teams must understand cluster networking, service discovery, resource limits, persistent storage, secrets, observability, upgrades, and access control. It is not automatically superior to simpler deployment methods. For a small data pipeline, a managed service or serverless workflow may be more reliable than operating a Kubernetes cluster.

Cloud Analytics Service Categories

Cloud analytics platforms commonly combine several service categories rather than providing one isolated product.

Object storage stores large volumes of structured, semi-structured, and unstructured data as objects in scalable repositories. It is frequently used as a data lake foundation because it offers high durability and relatively independent storage from computation. Data organisation, metadata, lifecycle policies, encryption, and access control remain important design responsibilities.

Managed relational databases provide structured transactional storage with familiar query and integrity mechanisms. They are suitable for operational applications and moderate analytical workloads, particularly where relational consistency is important.

Cloud data warehouses are optimised for analytical queries over structured and semi-structured data. They commonly separate storage and compute, support parallel processing, and permit independent scaling of workloads. Warehouse design still requires attention to schemas, partitioning, workload management, data quality, and cost controls.

Data lakes and lakehouse platforms store raw and curated data across diverse formats. A lakehouse attempts to combine the flexibility and low-cost storage of a data lake with transaction management, governance, and analytical performance associated with a warehouse. Its effectiveness depends on metadata, table formats, data-quality practices, and disciplined architecture rather than on terminology alone.

Batch processing services execute large transformations periodically. They are useful for historical aggregation, feature creation, reporting, and data preparation. Stream-processing services handle events continuously or with low latency, supporting fraud detection, operational monitoring, recommendations, and real-time dashboards.

Data integration and orchestration services move data between systems, schedule workflows, manage dependencies, and monitor pipeline execution. Business-intelligence services provide dashboards, semantic models, reports, and self-service exploration. Machine-learning platforms support data preparation, experiment tracking, distributed training, model deployment, monitoring, and governance.

A typical analytical architecture may therefore contain operational sources, an ingestion layer, object storage, a processing engine, a warehouse or lakehouse, a machine-learning platform, and a visualisation layer. The architecture should be selected according to latency, data volume, data variety, reliability, skills, regulatory obligations, and total cost—not according to product popularity alone.

A Decision Framework for Cloud Selection

A sound cloud decision begins with workload classification. Questions include: Is the workload transactional, analytical, streaming, or experimental? Is demand stable or highly variable? What latency is required? Which data is sensitive? Must data remain in a particular jurisdiction? Does the team need operating-system control? How difficult would migration be if the provider changed its terms?

The following dimensions support comparison:

• Control and flexibility: IaaS and private environments provide more control, while SaaS and serverless reduce operational responsibility.
• Elasticity and performance: Public cloud and managed services often provide rapid scaling, but performance may depend on quotas, workload contention, and data location.
• Cost: Evaluate compute, storage, requests, network transfer, licensing, support, personnel, and idle capacity. A proof of concept should include realistic usage patterns.
• Security and compliance: Examine identity, encryption, logging, isolation, vulnerability management, retention, audit evidence, and incident response.
• Reliability: Consider availability zones, regions, backups, recovery objectives, provider dependencies, and tested restoration procedures.
• Portability: Prefer open formats and interfaces where appropriate, but recognise that portability may reduce access to specialised managed capabilities.
• Operational capability: An advanced architecture is unsuitable if the organisation cannot monitor, secure, and maintain it.

Cloud governance should include account or subscription structure, identity standards, tagging, budgets, policy automation, approved images, logging, data classification, and lifecycle management. FinOps practices bring finance, engineering, and business teams together to understand and control cloud consumption.

Applied Case: A Regional Health Analytics Platform

Background

The following is an illustrative case. A regional healthcare network operates hospitals and clinics that generate laboratory results, admission records, medical images, appointment data, and equipment telemetry. The network wants to build a platform for demand forecasting, readmission analysis, and operational dashboards.

Situation and Problem

The existing environment consists of separate departmental databases and a small local data centre. Storage is approaching capacity, data preparation is slow, and analysts frequently create uncontrolled extracts. Health information is sensitive, and the network must demonstrate appropriate access, retention, and audit controls. Forecasting workloads are periodic and substantially larger before winter planning cycles.

Analysis

A fully public, unrestricted architecture would create unacceptable governance concerns, while retaining every workload locally would delay analytical development and require substantial capital investment. A hybrid design is considered. Identifiable clinical data will remain in a tightly controlled environment or approved regional cloud service, while de-identified datasets may be processed in elastic public-cloud resources. A central catalogue will record data ownership, classification, lineage, and permitted uses.

The team compares IaaS, PaaS, and SaaS options. IaaS would allow maximum customisation but would increase patching and operational responsibilities. A managed data platform is selected for transformation and analytical querying because the team needs scalability without operating a distributed cluster. Serverless functions will validate incoming files and trigger workflows, while a managed machine-learning service will support experiments and model deployment.

Strategy and Solution

Data is ingested through controlled interfaces rather than informal extracts. Raw data is stored in encrypted object storage with separate zones for restricted, de-identified, and curated data. Role-based access and least privilege are enforced through central identity management. Workloads are isolated by account or project, and network paths are restricted. Analysts use governed views rather than unrestricted access to raw records.

A hybrid connection links approved local systems with cloud services. Data-transfer volumes are monitored because repeated movement of medical images could be costly and slow. Automated policies stop development resources outside approved hours, and dashboards report consumption by department. Model outputs are reviewed for clinical validity and are not treated as autonomous medical decisions.

Outcome

The architecture provides elastic capacity for forecasting while retaining stronger control over sensitive data. Development becomes faster because teams use managed services, although the organisation invests in governance, platform skills, monitoring, and data-quality controls. The case demonstrates that cloud adoption is an architectural and organisational decision, not merely a procurement decision.

Learning Points

The appropriate solution may combine deployment and service models. Sensitive data requires classification and controlled processing, not vague assumptions that one environment is inherently safe. Managed services reduce infrastructure work but do not eliminate customer responsibility. Finally, cost, security, interoperability, and professional accountability must be assessed together.

Risks, Limitations, and Common Mistakes

Cloud environments create risks associated with misconfigured storage, excessive privileges, exposed credentials, insecure interfaces, vulnerable images, inadequate logging, and untested recovery procedures. Concentrating workloads with one provider may create systemic dependency. Outages, quota limits, regional failures, and provider changes can affect operations.

Common mistakes include migrating systems without redesigning dependencies; assuming elasticity automatically controls cost; choosing a specialised service without an exit strategy; ignoring network egress charges; creating excessive accounts and inconsistent policies; and treating dashboards as evidence of governance. Another frequent error is selecting Kubernetes because it is fashionable when a managed database, batch service, or serverless workflow would meet the requirement more simply.

Data quality is also a cloud concern. A highly scalable pipeline can process incorrect, duplicated, biased, or poorly documented data at greater speed. Analytics teams must therefore include validation, lineage, metadata, reproducibility, and monitoring in the platform design.

Ethical, Regulatory, and Professional Considerations

Cloud analytics may involve personal, financial, health, employment, or behavioural data. Organisations should collect and use data for legitimate purposes, minimise unnecessary retention, restrict access, and provide appropriate accountability. Data residency and cross-border transfer requirements may affect provider and region selection. Contracts should address breach notification, subcontractors, deletion, audit rights, service continuity, and data portability.

Machine-learning services introduce additional concerns. Training data may reproduce historical discrimination, and automated outputs may be difficult to explain. Human review, impact assessment, model documentation, performance monitoring, and an appeals process are important in high-consequence applications. Professional responsibility remains with the organisation and its practitioners even when a cloud provider supplies the technical service.

Current Developments and Best Practices

Cloud platforms increasingly support confidential computing, policy-as-code, managed vector and machine-learning services, real-time analytics, lakehouse architectures, and cross-cloud management. Generative AI services are being integrated into development, search, data preparation, and business applications, but they introduce risks involving data leakage, inaccurate outputs, copyright, and uncontrolled consumption.

Useful practices include designing for failure, automating infrastructure and policy, using infrastructure as code, applying least privilege, encrypting data in transit and at rest, maintaining independent backups, testing recovery, and monitoring both technical and financial performance. Teams should prefer managed services when they reduce undifferentiated work, but retain architectural understanding and an exit strategy. Pilot projects should measure latency, reliability, security, data-transfer volume, operational effort, and total cost before large-scale adoption.

Chapter Summary

Cloud computing provides programmable, elastic access to shared technology resources and changes how organisations acquire and operate analytical capability. Public, private, hybrid, and multi-cloud environments differ in control, scalability, complexity, and governance requirements. IaaS provides infrastructure control; PaaS manages much of the application platform; SaaS delivers complete applications; and serverless abstracts server management for event-driven execution.

Virtual machines provide isolated operating environments, containers package applications efficiently, and orchestration platforms coordinate large container deployments. Cloud analytics architectures typically combine object storage, databases, warehouses or lakehouses, batch and stream processing, integration, visualisation, and machine-learning services. Selection should consider workload characteristics, cost, security, compliance, reliability, portability, and organisational capability. Effective cloud adoption requires shared-responsibility awareness, governance, automation, ethical data use, and continuous evaluation.

Key Terms

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

Public cloud: Provider-operated cloud infrastructure shared by multiple customers through logical isolation.

Private cloud: Cloud environment dedicated to one organisation.

Hybrid cloud: Coordinated use of private infrastructure and public cloud services.

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

IaaS: Service model providing virtualised computing, storage, and networking resources.

PaaS: Managed application-development and runtime environment.

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

Serverless computing: Event-driven execution in which server management is largely abstracted from the customer.

Virtual machine: Software-defined computer running its own operating system on virtualised hardware.

Container: Lightweight package containing an application and its dependencies.

Orchestration: Automated deployment, scheduling, scaling, and management of containers or services.

Object storage: Scalable storage of data as discrete objects with associated metadata.

Data warehouse: Analytical data platform optimised for structured querying and reporting.

Data lake: Repository that stores large volumes of data in diverse formats.

Lakehouse: Architecture combining data-lake flexibility with warehouse-style management and analytics.

Elasticity: Ability to increase or reduce resources in response to demand.

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

FinOps: Collaborative practice for managing and optimising cloud expenditure.

Infrastructure as code: Automated definition and management of infrastructure through version-controlled files.

Review Questions

Short Answer Questions

1. What are the five commonly identified characteristics of cloud computing?

2. Distinguish hybrid cloud from multi-cloud.

3. What responsibilities generally remain with an IaaS customer?

4. Why are containers usually more lightweight than virtual machines?

5. What is the purpose of a cloud data warehouse?

Long Answer Questions

1. Compare public, private, hybrid, and multi-cloud environments in terms of control, scalability, cost, and governance.

2. Explain the shared responsibility model across IaaS, PaaS, SaaS, and serverless computing.

3. Discuss how virtualisation, containers, and orchestration contribute to cloud application delivery.

4. Describe the major categories of cloud analytics services and show how they may be combined in an analytical architecture.

5. Explain a systematic framework for selecting a cloud platform for a big data workload.

Analytical / Application Questions

1. An organisation has predictable transactional workloads, highly variable forecasting workloads, and sensitive customer data. Recommend a deployment and service model combination and justify it.

2. A data team has selected a multi-cloud strategy to avoid vendor lock-in but is experiencing duplicated skills, data-transfer costs, and inconsistent identity controls. Analyse the problem and propose governance measures.

3. Design a high-level cloud analytics architecture for streaming equipment telemetry, including ingestion, storage, processing, model deployment, monitoring, security, and cost controls.

22. Multiple Choice Questions with Answers

Question 1

Which characteristic most directly enables cloud resources to expand and contract in response to changing workload demand?

A. Measured service

B. Rapid elasticity

C. Broad network access

D. Resource pooling

Correct Answer: B. Rapid elasticity

Question 2

An organisation retains regulated data in its own controlled environment but uses public-cloud processing for de-identified forecasting data. Which deployment model best describes this arrangement?

A. Private cloud

B. Public cloud

C. Hybrid cloud

D. Single-tenant SaaS

Correct Answer: C. Hybrid cloud

Question 3

Which service model gives the customer the greatest control over the operating system while the provider manages physical servers and virtualisation?

A. SaaS

B. PaaS

C. Serverless

D. IaaS

Correct Answer: D. IaaS

Question 4

A team needs to execute short data-validation tasks whenever files arrive, without managing servers. Which approach is most appropriate?

A. Serverless computing

B. Private virtualisation only

C. Manual physical deployment

D. A dedicated transactional database

Correct Answer: A. Serverless computing

Question 5

What is the principal role of a container orchestration platform?

A. Replacing all data governance controls

B. Scheduling, scaling, and managing containerised workloads

C. Converting every database into a data lake

D. Eliminating the need for application monitoring

Correct Answer: B. Scheduling, scaling, and managing containerised workloads

Question 6

Which statement best distinguishes a container from a virtual machine?

A. A container normally packages an application while sharing the host kernel; a virtual machine includes a separate operating system.

B. A container always provides stronger isolation than a virtual machine.

C. A virtual machine cannot run applications independently.

D. Containers require physical servers dedicated to one application.

Correct Answer: A. A container normally packages an application while sharing the host kernel; a virtual machine includes a separate operating system.

Question 7

A company chooses two public-cloud providers mainly to access specialised services from each. What major risk should it plan for?

A. The impossibility of using identity management

B. Increased complexity in skills, networking, monitoring, and governance

C. The elimination of all provider dependency

D. The automatic reduction of data-transfer costs

Correct Answer: B. Increased complexity in skills, networking, monitoring, and governance

Question 8

Which service is most directly associated with storing diverse raw data at large scale for later processing?

A. Object storage

B. Email SaaS

C. Desktop virtualisation

D. Identity federation alone

Correct Answer: A. Object storage

Question 9

Why might a managed analytics platform be selected instead of IaaS for a data-processing workload?

A. It removes every customer security responsibility.

B. It provides unlimited capacity without cost.

C. It reduces infrastructure administration while retaining focus on data and applications.

D. It guarantees that migration to another provider is effortless.

Correct Answer: C. It reduces infrastructure administration while retaining focus on data and applications.

Question 10

Which practice best addresses the risk of uncontrolled cloud expenditure?

A. Disabling all monitoring to reduce platform overhead

B. Using budgets, tagging, lifecycle policies, and consumption dashboards

C. Selecting the most complex orchestration platform

D. Moving every workload to a private data centre

Correct Answer: B. Using budgets, tagging, lifecycle policies, and consumption dashboards