2 Cloud Computing Fundamentals for IoT

2.1 Start With a Shared Cloud Job

This section: Start With a Shared Cloud Job — Picture a cold-store alarm during an internet outage.

Picture a cold-store alarm during an internet outage. The local unit still has to protect the food. The remote service can wait for the full record. This split is the first cloud choice.

A gateway is a local device or service that joins field devices to a wider network. Telemetry means time-stamped reports about device state and events. Firmware is the software stored on a device. The cloud can hold history, join fleet records, run long jobs, and show many sites at once. It should not own a fast or safe action when a lost link would make that action fail.

Start with one job and ask:

• Must it happen at once?
• Must it work offline?
• How much data must be kept?
• Who needs the shared view?
• What state belongs near the device?
• What state belongs in the cloud?
• How will queued records keep their time?
• What happens when the link returns?
• Who owns a failed upload?
• What proof allows release?

Shared capacity can grow when demand grows. It can also fail, slow down, or cost more than planned. Name those limits before choosing a vendor. Practitioner compares placement, storage, identity, cost, and recovery records. Under the Hood covers service models, shared resources, failure zones, and proof boundaries. That detail extends the outage story; it does not remove the need for local control.

Keep the split easy to retell. Fast safe work stays local. Shared history can move outward. Queued records keep event time. A failed link has an owner.

Imagine a building gateway that sends alarms, routine telemetry, dashboard updates, and firmware evidence to the same cloud account. The first architecture move is to separate what must respond immediately from what can be stored, queued, analyzed, or reviewed later.

Start simple: describe the job the cloud is doing for one device group before naming a provider or service. Once the job is clear, capacity, resilience, placement, and evidence boundaries become easier to judge.

2.2 Shared Cloud Capacity for IoT

This section: Shared Cloud Capacity for IoT — Cloud computing lets an IoT system use shared remote compute, storage, networking, and application services through network APIs.

Cloud computing lets an IoT system use shared remote compute, storage, networking, and application services through network APIs. It is valuable for ingestion, durable storage, fleet analytics, dashboards, device management, and long-running review evidence. It does not remove the need for edge processing: local control, filtering, buffering, and outage behavior still belong near devices when timing, safety, or connectivity require it.

NIST describes cloud computing through five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. For IoT, those characteristics are useful only when they are mapped to real workload boundaries and failure behavior.

Consider a cold-chain fleet with temperature probes, cellular gateways, and a cloud operations portal. The cloud side might use AWS IoT Core, Azure IoT Hub, Google Cloud Pub/Sub, Amazon S3, Cloud Storage, BigQuery, TimescaleDB, or Grafana-style dashboards to accept events, retain history, summarize exceptions, and show fleet status. Those products do not decide the architecture by themselves. The architecture decision is whether each workload benefits from shared capacity, central visibility, managed identity, durable storage, or elastic processing.

The same fleet still needs local behavior. A gateway may keep an MQTT or HTTPS queue while offline, reject malformed sensor records, preserve the last safe alarm threshold, and buffer readings until a mobile link returns. A site controller may keep refrigeration alarms independent from any cloud dashboard. Cloud fundamentals therefore start with a boundary: what is safe to centralize, what must remain local, and what evidence shows the boundary works during normal traffic, burst traffic, and outage recovery. Measured service then turns that boundary into quotas, cost signals, and capacity warnings.

Use Figure 2.1 to test whether a proposed remote service has the behaviours that make cloud capacity useful for an IoT workload.

+

Begin Figure 2.1 with controlled self-service and a standard network path. Shared pools and quick scale let the platform take normal traffic and a storm of links that reconnect. It need not give each fleet one fixed server. The measured-service block adds quotas, cost signs, and warnings as room runs low. Now compare the work line. Data intake, long-term stores, fleet study, views, and device care may sit at the centre. Fast control, filters, queues, and outage rules may stay near the device. Test normal load, bursts, and return from an outage; a remote data-centre label proves none of them.

Use Figure 2.2 to trace the forces behind edge, fog, and cloud work.

+

The branches in Figure 2.2 show several results of shared technical change. Hardware integration and efficient components support work near devices; networks and software platforms make intermediate fog nodes useful; demand also shapes sensor networks and local AI. The diagram does not assign these patterns to one invention. It asks where a workload belongs given latency, resilience, privacy, and bandwidth. Cloud services can provide shared visibility and elastic capacity, while a gateway or device may keep a time-critical or outage-sensitive action close to the site. Use those constraints to place work, then record which boundary and owner make the choice testable.

2.3 Workload Placement by Constraints

This section: Workload Placement by Constraints — A practical cloud decision starts by tracing the IoT data flow.

A practical cloud decision starts by tracing the IoT data flow. Devices sense and act. Gateways validate, translate, filter, buffer, and protect local continuity. Cloud services ingest, store, process, and share information. Operations teams review behavior and push approved changes back through controlled channels.

Write the path as a workload map before selecting a service. In a building-monitoring deployment, BACnet or Modbus devices may feed a site gateway, the gateway may publish normalized MQTT events, and the cloud may land them in a time-series store for dashboards and compliance reports. If a thermostat command, fire-damper signal, or freezer alarm cannot wait for an internet round trip, it stays local. If a monthly energy benchmark, remote certificate inventory, or model-training dataset needs fleet-wide comparison, it fits cloud-side processing.

The path in Figure 2.3 moves data from device to cloud and back; check each handoff.

+

Keep Site and edge, Storage, and approved configuration or model updates return through a controlled path separate while reading Figure 2.3. The diagram makes Site and edge a visible workload placement by constraints cue; its Storage relationship advances the claim: A cloud path is reviewable when every handoff has a responsibility, identity, and failure behaviour.

The chapter needs visual evidence for workload placement by constraints. Figure 2.4 provides it: Placement should follow workload evidence, not a generic preference for cloud or edge. Examine Edge or site together with connectivity.

+

Map Edge or site to the current requirement in Figure 2.4. Map connectivity to the next duty and observe, and control return traffic to the later proof. This continues workload placement by constraints: Placement should follow workload evidence, not a generic preference for cloud or edge.

2.4 Cloud Evidence Boundaries

This section: Cloud Evidence Boundaries — Under the hood, an IoT cloud design is a chain of service contracts.

Under the hood, an IoT cloud design is a chain of service contracts. A device event becomes a gateway record, an ingestion decision, a storage item, an analytic result, an operator view, and sometimes a return-path change. Each step needs identity, data classification, failure behavior, observability, and ownership.

A cloud placement is weak if it relies on changing product names, pricing examples, or marketing claims. A stronger choice captures the workload intent, the cloud characteristic being used, the edge boundary, the data class, the timing class, the failure behavior, and the owner who can revisit the assumption when workload or risk changes.

One telemetry record shows why the boundary matters. A sensor measurement may include a device identity, firmware version, timestamp, sequence number, site id, unit, quality flag, and payload schema version. The gateway may validate it, add an idempotency key, write it to a local queue, and publish it through MQTT over TLS. The cloud ingress layer may authenticate the certificate, check topic authorization, reject unexpected fields, place the record on an event bus, and write different copies to short-retention raw storage and longer-retention aggregates.

That chain creates operational questions that cannot be answered by the word cloud alone. What happens when the MQTT broker throttles a reconnect storm? Which messages are safe to replay? Which raw records are deleted after seven days, and which hourly summaries remain for compliance? Which alert is raised when schema validation fails? Which operator can approve a configuration change that travels back through the cloud to the gateway? Durable evidence is the combination of logs, queue metrics, schema versions, access records, runbooks, and rollback paths that show those answers were designed rather than assumed.

Use Figure 2.5 to follow a record from the device to owner review.

+

The record in Figure 2.5 starts with device identity, firmware, time, sequence, and site. A gateway validates the event and gives its local queue a key before cloud ingress checks certificate and topic policy. The storage branch keeps raw data for the stated short retention window and produces an hourly summary for longer review. Logs, metrics, and owner signoff then show how the placement behaves under normal traffic, bursts, and outage recovery. This path is why a cloud choice needs a data class, timing class, failure mode, edge boundary, and named owner. The service name alone cannot answer a replay or retention question.

2.5 Summary

This section: Summary — Cloud computing gives IoT systems shared, automated, network-accessible, elastic, and measured resources.

Cloud computing gives IoT systems shared, automated, network-accessible, elastic, and measured resources. Those properties support ingestion, storage, analytics, dashboards, identity, updates, and fleet operations when the design also records local timing, data, connectivity, and ownership boundaries.

The architecture is strong only when cloud responsibilities are separated from edge responsibilities. Immediate safety, local fallback, raw-data minimization, and outage behavior need explicit placement evidence instead of a generic claim that cloud is scalable.

2.6 Key Takeaway

This section: Key Takeaway

2.7 See Also

This section: See Also