Cloud, Edge and Internet of Things Technologies

Introduction and Context

Cloud computing, edge computing and the Internet of Things (IoT) are complementary technologies rather than isolated trends. Cloud platforms provide elastic computing, storage, networking and managed software services. Edge computing moves selected processing and storage closer to data sources and users. IoT connects physical objects—such as sensors, vehicles, machines and appliances—to digital systems so that they can be monitored, analysed and controlled.

Together, these technologies support applications such as predictive maintenance, smart manufacturing, connected healthcare, intelligent transport, precision agriculture and smart buildings. Their value depends not simply on adopting a platform, but on designing an architecture that satisfies latency, availability, security, data-governance, cost and operational requirements.

Learning Objectives

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

1. Compare cloud service and deployment models.
2. Select suitable cloud resources for scalable applications.
3. Explain virtualization, containers, orchestration and serverless computing.
4. Design a basic cloud–edge–IoT architecture.
5. Evaluate IoT communication protocols, platforms and data pipelines.
6. Identify security, privacy, governance and operational risks.
7. Apply architectural reasoning to a contemporary business scenario.

1. Cloud Computing Foundations

Cloud computing is a model for providing shared, configurable computing resources over a network with rapid provisioning and measured usage. The principal characteristics commonly associated with cloud computing are:

• On-demand self-service: users can provision resources without manual intervention from the provider.
• Broad network access: services are available through standard networks and devices.
• Resource pooling: provider resources serve multiple customers using logical isolation.
• Rapid elasticity: capacity can expand or contract as demand changes.
• Measured service: usage is monitored for billing, capacity planning and governance.

Cloud computing changes the economic and operational model of IT. An organisation can replace some capital expenditure on data-centre equipment with operational expenditure for consumed services. However, cloud is not automatically cheaper. Poorly governed storage, excessive data transfer, over-provisioned virtual machines and unmanaged software licences can create substantial costs.

1.1 Cloud service models

The division of responsibility is often called the shared responsibility model. A provider may secure the physical infrastructure, while the customer remains responsible for identity management, data classification, secure configuration and application security. The exact boundary differs by service and provider; it must be verified rather than assumed.

1.2 Deployment models

• Public cloud: infrastructure is operated by a provider and shared among customers through logical isolation. It offers broad elasticity and a large service catalogue.
• Private cloud: cloud technologies are dedicated to one organisation. It may offer greater control or compliance alignment but usually requires more operational expertise.
• Hybrid cloud: combines private and public environments, often with integration between them. It can support gradual migration or the placement of sensitive workloads in a controlled environment.
• Community cloud: infrastructure is shared by organisations with common requirements, such as public-sector or research institutions.
• Multi-cloud: an organisation uses services from two or more cloud providers. This may reduce dependency on one provider, but increases integration, skills and governance complexity.

Deployment choice should follow requirements rather than fashion. Relevant factors include data sovereignty, latency, resilience, skills, integration, workload variability, regulatory obligations and total cost of ownership.

2. Designing Scalable Cloud Solutions

Scalability is the ability of a system to handle increased workload by adding resources or improving resource efficiency. Vertical scaling increases the capacity of an existing resource, such as adding memory to a server. Horizontal scaling adds instances, such as additional application servers. Horizontal scaling is often preferred for highly available web systems, although it requires stateless design or reliable session management.

2.1 A reference architecture

A common cloud application separates presentation, application logic, data and operations:

Figure: A layered cloud application architecture with ingress, application, data, event and operations components.

Important design principles include:

• Loose coupling: services communicate through stable interfaces and asynchronous messaging where appropriate.
• Stateless application instances: user state is stored in a shared database or cache rather than one server.
• Autoscaling: instances are added or removed according to demand, subject to safe limits.
• Resilience: failure of one instance, zone or dependency should not unnecessarily cause total failure.
• Observability: logs, metrics, traces and business indicators support diagnosis and decision-making.
• Infrastructure as Code: infrastructure is defined in version-controlled declarations, making environments reproducible.
• Security by design: identity, encryption, network segmentation and secure defaults are included from the beginning.

2.2 Capacity and cost reasoning

A simple average throughput estimate is:

where λ is average arrival rate in requests per second, R is the number of requests, and T is the observation period in seconds. This estimate is useful for initial sizing but does not describe bursts, latency or resource demand. Production capacity planning should examine percentiles, peak rates, concurrency, payload size and service limits.

For a service charged at a constant hourly rate, estimated monthly cost can be approximated by:

where C is cost, n is the number of resources, p is price per resource-hour, and h is billable hours. The formula assumes a constant number of resources and excludes storage, data transfer, licences, taxes and other services. Actual cloud bills require provider-specific pricing and usage records.

For example, four instances priced at £0.08 per hour and operated for 720 hours cost:

This is an estimate, not a complete total cost of ownership.

3. Virtual Machines, Containers and Orchestration

A virtual machine (VM) emulates a complete computer through a hypervisor. Each VM normally includes a guest operating system, libraries and applications. VMs provide strong isolation and support different operating systems, but their images can be large and startup may be relatively slow.

A container packages an application and its dependencies while sharing the host operating-system kernel. Containers are usually lightweight and portable, but they are not identical to VMs: a kernel vulnerability or insecure privilege configuration can affect isolation. Container images should be minimal, reproducible, versioned and scanned for vulnerabilities.

A container image is normally built from declarative instructions and stored in a registry. At runtime, a container engine creates an isolated process environment. Production systems commonly use an orchestrator to schedule containers across nodes.

3.1 Orchestration responsibilities

An orchestrator typically provides:

• scheduling and placement;
• service discovery and internal networking;
• rolling deployment and rollback;
• replica management and self-healing;
• configuration and secret integration;
• health checks;
• resource limits and quotas.

A deployment should specify requests and limits for CPU and memory. Without limits, a faulty process can exhaust shared resources. Health checks must distinguish liveness—whether a process should be restarted—from readiness—whether it can receive traffic. Poorly designed checks can cause restart loops or route traffic to an unready service.

Containers improve consistency but do not remove the need for monitoring, patching, access control, backup, incident response and capacity planning.

4. Serverless Computing

Serverless computing means that the provider manages server provisioning and much of the runtime operation. In FaaS, a function executes in response to an event, such as an HTTP request, message, file upload or scheduled trigger. The application team generally pays for invocations and execution resources according to the provider’s model.

Serverless is effective for irregular workloads, event transformation, automation and short-lived APIs. Its limitations include cold-start latency, execution-duration limits, provider-specific interfaces, difficult local testing, distributed tracing complexity and possible cost surprises from high invocation rates.

Good serverless design uses small, idempotent functions. An idempotent operation produces the same intended result when safely repeated. This matters because messages may be delivered more than once. Durable state should be stored in a suitable database or object store, not assumed to remain in function memory.

5. Edge Computing

Edge computing places computation, storage or networking services near the point where data is generated or consumed. The edge may be a factory gateway, cellular site, retail branch, vehicle, building controller or local micro-data centre.

The edge is valuable when applications require:

• very low or predictable latency;
• operation during intermittent connectivity;
• reduced backhaul bandwidth;
• local privacy or data residency;
• rapid control decisions;
• local filtering of high-volume sensor data.

Edge does not mean that all processing must leave the cloud. A practical architecture usually distributes functions. Devices perform sensing and immediate control; an edge gateway filters, aggregates and enforces local policy; the cloud performs fleet management, long-term storage, large-scale analytics and model training.

This distribution creates operational challenges. Edge sites may have limited physical security, constrained power, heterogeneous hardware and unreliable networks. Remote patching, device identity, configuration management and offline behaviour must therefore be designed explicitly.

6. Internet of Things Architecture

An IoT system is a socio-technical system consisting of physical assets, sensors and actuators, connectivity, computation, applications, people and governance. A useful layered model is:

1. Things layer: sensors measure conditions; actuators change physical states.
2. Connectivity layer: networks transport data using wired or wireless technologies.
3. Edge or gateway layer: devices are authenticated, protocols may be translated, and data may be filtered.
4. Platform layer: device registry, message ingestion, rules, storage, digital twins and device management are provided.
5. Application layer: dashboards, alerts, workflows, analytics and control interfaces support users.
6. Business and governance layer: processes, ownership, compliance, safety and value measurement are defined.

A sensor reading is not automatically useful information. Meaning depends on metadata such as device identity, location, unit, timestamp, calibration status and quality indicators. Time synchronisation is important when events from several devices are correlated.

6.1 Protocols and connectivity

• MQTT is a lightweight publish–subscribe protocol suited to constrained devices and intermittent networks. A broker routes messages between publishers and subscribers. Quality-of-service choices affect delivery behaviour and overhead.
• CoAP is designed for constrained devices and resembles web interaction while using a more compact protocol model.
• HTTP/HTTPS is widely supported and easy to integrate, but can create more overhead for very constrained devices.
• Bluetooth Low Energy supports short-range, low-power communication.
• Wi-Fi offers high throughput but generally consumes more power than low-power technologies.
• LPWAN technologies support long-range, low-power transmission with limited bandwidth.
• Cellular and private industrial networks support broad coverage, mobility and managed quality of service.

Protocol selection should consider payload size, energy budget, range, reliability, latency, mobility, interoperability, spectrum and operating cost.

6.2 IoT data pipeline

A robust pipeline normally includes ingestion, validation, normalization, enrichment, storage, analysis and action. Data may be divided into:

• hot data, used immediately for alerts or control;
• warm data, used for operational dashboards and recent analysis;
• cold data, retained economically for compliance, history or model training.

Filtering at the edge can reduce transmission. For example, a gateway might send a one-minute average during normal operation but transmit all readings when vibration exceeds a threshold. Such rules must preserve evidence needed for safety, auditing and later analysis.

7. Security, Privacy and Governance

IoT and cloud systems enlarge the attack surface because they combine physical devices, networks, applications, identities and third-party services. Security should be treated as a lifecycle activity.

7.1 Core controls

• Give every device a unique, cryptographically protected identity.
• Use mutual authentication where feasible and encrypt data in transit.
• Protect sensitive data at rest and manage keys securely.
• Apply least privilege to users, services and devices.
• Use secure boot, signed firmware and controlled update mechanisms.
• Segment operational technology from general enterprise networks.
• Maintain an asset inventory and software bill of materials where practicable.
• Log security-relevant events and monitor for anomalies.
• Define revocation, replacement and end-of-life procedures.
• Test backups, recovery and incident-response plans.

A password shared by thousands of devices is not an adequate device-identity strategy. Similarly, encryption does not solve insecure authorization: an authenticated device must still be restricted to the actions it is permitted to perform.

7.2 Privacy and ethics

IoT data can reveal behaviour, location, health conditions, work patterns and household activity. Organisations should apply purpose limitation, data minimisation, retention controls and transparency. Individuals should understand what is collected and how it affects decisions. Video, biometric and location systems require especially careful governance.

Automated decisions based on sensor or AI data may be inaccurate because of faulty calibration, biased samples or changing environmental conditions. Human review, confidence thresholds, model monitoring and appeal mechanisms may be required. In safety-critical contexts, an automated system should fail to a safe state rather than merely continue operating silently.

Regulatory responsibilities depend on jurisdiction and sector. Relevant areas may include data-protection law, critical-infrastructure requirements, product safety, radio regulation, accessibility, contractual controls and industry standards. Compliance should be mapped to specific controls and evidence rather than treated as a general statement.

8. Operations and Reliability

Cloud–edge–IoT operations require more than uptime monitoring. Useful observability combines:

• metrics, such as latency, error rate, queue depth, battery level and device connectivity;
• logs, which record events and diagnostic context;
• traces, which follow a transaction across distributed services;
• events, which trigger operational or business workflows.

Service-level indicators (SLIs) measure actual performance, such as successful requests divided by total requests. A service-level objective (SLO) states a target, while an agreement may define contractual consequences. Monitoring should focus on user and business outcomes, not only infrastructure health.

The reliability of a system is constrained by dependencies. If a request requires several independent services sequentially, overall success probability is approximately the product of their success probabilities under the simplifying assumptions of independence and a single attempt. For two services with reliabilities 0.99 and 0.98:

Thus, the sequential path has approximately 97.02% reliability under those assumptions. Real systems may include retries, redundancy and correlated failures, so this calculation is a conceptual model rather than a complete reliability prediction.

9. Applied Case: Illustrative Smart Manufacturing System

Background

A fictional manufacturer operates a production line with motors, pumps and conveyor systems. Unplanned failures stop production, while sending every high-frequency vibration reading to a central cloud would be expensive and would introduce delay.

Problem

The organisation needs early warning of mechanical failure, local safety responses, secure remote maintenance and a historical dataset for predictive models. The line must continue safely during temporary loss of internet connectivity.

Analysis

Vibration and temperature sensors generate time-series data. Immediate safety conditions require millisecond- or second-level response, whereas model training can tolerate cloud-scale batch processing. Devices are distributed across a harsh environment and may be physically accessible to attackers. The solution therefore needs local autonomy, secure identity, time synchronisation and controlled updates.

Approach and solution

Sensors communicate with an industrial gateway using a suitable local protocol. The gateway authenticates devices, validates timestamps, removes malformed records and calculates short-window features such as average temperature and vibration thresholds. Critical rules can stop a machine locally according to approved safety logic. Normal summaries are transmitted to a cloud IoT platform through an encrypted connection.

The cloud platform provides a device registry, message ingestion, time-series storage, dashboards and a data lake. A stream-processing service generates maintenance alerts. Historical data is used to train an anomaly-detection model, but model deployment is subject to validation and staged rollout. The gateway retains a local buffer during network failure and forwards records after reconnection. Containers package supporting services, while infrastructure and policies are managed as code.

Access is role-based: operators view line status, maintenance staff receive diagnostic information, and only authorised engineers can deploy gateway updates. Firmware is signed, devices have unique credentials, and all update activity is logged.

Outcome

The architecture reduces unnecessary bandwidth, keeps safety decisions local and provides central visibility. Its success should be evaluated using measurable indicators such as false-alarm rate, mean time to detect, avoided downtime, energy consumption, update success rate and recovery time after connectivity loss.

Learning points

1. Processing location should follow latency, safety and data-governance requirements.
2. Cloud analytics and edge autonomy are complementary.
3. A predictive model is only one component of a dependable operational system.
4. Device lifecycle management is as important as initial deployment.
5. Business outcomes must be measured alongside technical metrics.

10. Contemporary Developments and Best Practice

Current developments include confidential computing, managed edge platforms, private 5G, digital twins, low-power AI inference, event-driven architectures and increasingly automated policy enforcement. Generative AI may assist operators by summarising logs or producing maintenance recommendations, but it should not be granted unreviewed control over safety-critical equipment. AI outputs require provenance, monitoring and human accountability.

A disciplined project should:

1. define business outcomes and safety constraints;
2. classify data and identify legal obligations;
3. map device, edge, cloud and user trust boundaries;
4. select protocols and services using measurable requirements;
5. prototype with realistic network loss and device failure;
6. automate testing, deployment and configuration validation;
7. secure identities, updates, secrets and logs;
8. establish cost budgets and resource policies;
9. monitor technical and business indicators;
10. plan decommissioning before deployment.

Challenges and Limitations

Cloud, edge and IoT architectures involve trade-offs. Cloud concentration can create provider dependency and regional outages. Multi-cloud may improve negotiating position but can increase complexity. Edge deployments are difficult to patch consistently and may be physically compromised. IoT devices often have long lifetimes, weak update support and constrained processors. Interoperability claims may fail when vendors implement standards differently. Sensor data can be incomplete or misleading, and predictive systems can produce false positives that undermine trust. Finally, “real-time” is not a universal guarantee; it must be defined using measurable latency, jitter and availability requirements.

Chapter Summary

Cloud computing provides shared, elastic resources through service models including IaaS, PaaS, SaaS and FaaS. Deployment choices include public, private, hybrid, community and multi-cloud environments. Scalable cloud systems use horizontal scaling, loose coupling, automation, observability, resilience and security-by-design.

Containers package applications efficiently, while orchestration manages scheduling, health, scaling and deployment. Serverless services simplify infrastructure management for suitable event-driven workloads but introduce execution, observability and portability constraints. Edge computing places selected processing near data sources to reduce latency, bandwidth use and dependence on continuous connectivity.

IoT architectures connect things, networks, gateways, platforms and applications within a governed business context. Protocol selection depends on energy, range, payload, reliability and cost. Secure device identity, encrypted communication, least privilege, signed updates, privacy controls and lifecycle management are essential. Effective solutions combine local autonomy with cloud-scale storage and analytics, and evaluate outcomes through operational, financial, safety and user-centred measures.

Key Terms

Cloud computing: Delivery of shared computing resources over a network with rapid provisioning and measured use.

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

PaaS: Managed application platform on which customers deploy code.

SaaS: Complete software application delivered as a service.

FaaS: Event-triggered function execution managed by a cloud provider.

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

Elasticity: Ability to increase or decrease resources as demand changes.

Container: Isolated application process packaged with its dependencies while sharing a host kernel.

Orchestration: Automated scheduling, networking, scaling and lifecycle management of containers.

Serverless: Computing model in which the provider manages most server provisioning and operation.

Edge computing: Processing and storage located near data sources or users.

Internet of Things: Networked physical objects that sense, communicate and/or act.

Gateway: Intermediate device that connects local devices to other networks or platforms.

MQTT: Lightweight publish–subscribe messaging protocol commonly used in IoT.

Digital twin: Digital representation of a physical asset or process, linked to relevant data.

Observability: Ability to understand system state through metrics, logs, traces and events.

Infrastructure as Code: Declarative, version-controlled management of infrastructure.

Least privilege: Granting only the access required for an identity to perform its task.

Data minimisation: Collecting and retaining no more personal data than necessary.

Review Questions

Short Answer Questions

1. Distinguish IaaS, PaaS and SaaS.
2. What is the difference between vertical and horizontal scaling?
3. Why are readiness and liveness checks different?
4. State two reasons for processing IoT data at the edge.
5. What is the purpose of a device registry?

Long Answer Questions

1. Compare public, private, hybrid and multi-cloud deployment models, including their advantages and limitations.
2. Explain how containers and orchestration support reliable application deployment.
3. Describe an end-to-end IoT data pipeline from sensor to business application.
4. Discuss security and privacy controls for a cloud–edge–IoT system.
5. Explain how observability and resilience should be designed into a distributed application.

Analytical / Application Questions

1. A healthcare organisation needs local operation during network outages and central analysis of long-term records. Propose a cloud–edge architecture and justify where each major function should execute.
2. An IoT deployment produces large volumes of data but has a limited communications budget. Design an edge filtering and storage policy, identifying risks of losing data.
3. A company is considering multi-cloud deployment to avoid vendor lock-in. Analyse the technical, financial, security and governance trade-offs and recommend decision criteria.

Multiple Choice Questions with Answers

Question 1

Which cloud service model generally requires the customer to manage the operating system?

A. Infrastructure as a Service

B. Software as a Service

C. Function as a Service

D. Managed database as a complete application

Correct Answer: A. Infrastructure as a Service

Question 2

Which design most directly supports horizontal scalability?

A. Keeping all user sessions only in one server's memory

B. Adding interchangeable application instances behind a load balancer

C. Increasing the size of one fixed server only

D. Disabling health checks

Correct Answer: B. Adding interchangeable application instances behind a load balancer

Question 3

What is a primary advantage of edge computing?

A. It guarantees unlimited storage at every device

B. It removes the need for device security

C. It can reduce latency and bandwidth use near the data source

D. It requires all processing to occur in the public cloud

Correct Answer: C. It can reduce latency and bandwidth use near the data source

Question 4

Which protocol uses a lightweight publish–subscribe model commonly suited to IoT?

A. FTP

B. MQTT

C. SMTP

D. SSH

Correct Answer: B. MQTT

Question 5

What is the main purpose of a container orchestrator?

A. To replace all application source code

B. To schedule, scale and manage container workloads

C. To physically manufacture sensors

D. To eliminate the need for identity management

Correct Answer: B. To schedule, scale and manage container workloads

Question 6

A cloud function is invoked by an uploaded file and transforms that file. Which characteristic is most important for safe retries?

A. Idempotence

B. Large local disk capacity

C. A shared administrator password

D. Permanent in-memory state

Correct Answer: A. Idempotence

Question 7

Four resources each cost £0.08 per hour and run for 720 hours. What is the estimated compute cost?

A. £23.04

B. £230.40

C. £288.00

D. £2,304.00

Correct Answer: B. £230.40

Question 8

Which control best protects the integrity of device firmware updates?

A. Unsigned firmware from an anonymous source

B. A shared password for every device

C. Signed firmware verified before installation

D. Disabling update logs

Correct Answer: C. Signed firmware verified before installation

Question 9

In the shared responsibility model, which activity normally remains a customer responsibility?

A. Maintaining the provider's physical building

B. Manufacturing the provider's servers

C. Configuring customer identities and access permissions

D. Repairing the provider's power system

Correct Answer: C. Configuring customer identities and access permissions

Question 10

For two sequential services with independent reliabilities of 0.99 and 0.98, what is the approximate combined reliability?

A. 0.0198

B. 0.9702

C. 0.9850

D. 1.9700

Correct Answer: B. 0.9702