Cloud, SDN & Production Architectures · Study deck
Cloud Computing Fundamentals for IoT
Picture a cold-store alarm during an internet outage.
Cloud Clara is your guide for this deck.
After studying this chapter
Cloud placement starts with the job and its limits
The cloud decision starts with a workload whose shared and local responsibilities are explicit.
- Shared cloud services can support fleet visibility and durable history.Ingestion, storage, analytics, dashboards, identity, and updates are useful when their workload benefits justify the remote network boundary.
- Local control needs to survive the failures that affect remote access.A refrigeration alarm cannot depend on an internet round trip when the site must respond during a link outage.
- Placement needs timing, data, connectivity, and ownership evidence.The building gateway and remote service have different responsibilities for raw records, queues, access, and safe operation.
- A successful dashboard cannot establish the complete resilience claim.Normal traffic, burst load, offline operation, and recovery need observations before the team approves those behaviours.
Major section
The cold-store alarm must work offline
An internet outage must not remove the cold store’s immediate alarm response.
- The local unit must protect the food during internet loss.The alarm decision belongs near the device when a failed link would prevent the required safe response.
- The remote service can wait for the complete incident history.Cloud storage and reporting support later review without becoming the only path to an immediate alarm.
- The gateway is the local connection to the wider network.Its responsibilities can include validation, filtering, protocol translation, short-term buffering, and continuity while the site is disconnected.
- A workload description needs to precede the provider choice.Timing, offline operation, retained data, shared visibility, and failure ownership define the job before a service name is selected.
Major section
Queued history must preserve event time
Queued telemetry remains useful only when its timing and recovery behaviour are preserved.
- Telemetry is a time-stamped record of device state and events.An upload after an outage still needs the original event time so later reporting does not confuse arrival time with occurrence.
- Cloud history can combine records from many sites.Long-running jobs, fleet comparisons, and shared views benefit from remote storage even while immediate site behaviour remains local.
- Firmware is software stored on the device.Firmware evidence can share a cloud account with alarms, routine telemetry, and dashboard updates while retaining a different review purpose.
- A failed upload needs a named operational owner.Queue recovery, retries, and the result after reconnection remain part of the architecture instead of disappearing at the network handoff.
Major section
Shared capacity has operational limits
The operational limits of shared capacity belong in the architecture decision.
- Elastic capacity can grow without removing network or service failures.Shared resources may still slow down, fail, or cost more than planned during the workload’s operating conditions.
- Fast safe work needs a dependable local decision path.A remote dashboard cannot own a time-bound action when link loss would prevent the site from responding.
- Cloud placement needs explicit recovery and cost responsibilities.Storage, identity, access, scaling, retention, and failure records explain who can investigate a remote workload that stops behaving as expected.
- The job description makes the placement boundary easier to review.Alarms, telemetry, dashboard updates, and firmware evidence can have different timing and resilience needs inside the same cloud account.
Major section
The cloud model connects characteristics to services
The cloud model relates service characteristics to runtime and deployment choices; begin with the essential characteristics before following those branches.
- The model’s essential characteristics define a reviewable service capability.On-demand self-service and broad network access need controlled automation, identity, and policy for the IoT workload.
- Pooled resources and rapid elasticity can support changing fleet demand.Isolation must protect data and keys while capacity expands around reconnect storms, firmware waves, or bursts of alarms.
- Measured service gives operations evidence about resource use.Capacity warnings, retention review, cost signals, and accountability connect the shared service to the workload’s operating limits.
- Runtime and deployment choices still need the workload boundary.A remote service model cannot determine which refrigeration alarms, filtering, and outage behaviour must remain at the site.
Major section
A cold-chain fleet still needs local continuity
Fleet visibility and local refrigeration protection are complementary jobs with different failure needs.
- The fleet portal can accept events and summarize exceptions across sites.Shared history, managed identity, durable storage, and elastic processing explain the remote role more clearly than a list of products.
- The gateway can hold an MQTT or HTTPS queue while offline.Buffered readings need to survive until the mobile link returns without making the refrigeration alarm depend on the portal.
- Local validation can reject malformed sensor records before upload.The gateway also needs the last safe alarm threshold so a remote interruption does not silently remove site protection.
- Cloud and site success need observations under different operating conditions.Normal traffic, burst traffic, and outage recovery test whether the chosen boundary works beyond an online demonstration.
Major section
Pooling and elasticity need isolation and measurements
Shared capacity needs usage evidence and protected ownership as demand changes.
- Resource pooling needs isolation between workloads and environments.Shared infrastructure must preserve data, keys, access boundaries, and ownership while it serves multiple IoT jobs.
- Rapid elasticity can absorb changing demand within recorded limits.Reconnect storms, firmware waves, alarms, and seasonal reporting create bursts that need capacity and failure evidence.
- Measured service can expose pressure before operations lose visibility.Usage records support capacity planning, retention review, abuse detection, cost signals, and accountable ownership.
- Scaling capability cannot replace tested outage and recovery behaviour.The fleet still needs queue handling, site continuity, and an observed recovery result when connections disappear and return.
Major section
Controlled access connects the shared service to its users
Network access and resource automation must preserve the workload’s identity and policy boundaries.
- Self-service can make resource changes repeatable through controlled automation.Teams need an authorized way to request and adjust capacity instead of relying on informal setup that hides ownership.
- Broad network access still needs explicit identity and policy.Gateways, applications, and operators use standard network mechanisms without receiving the same access to every data or control function.
- Useful compute can remain distributed across cloud, gateways, and devices.Local filtering, buffering, control, and outage behaviour complement shared history and fleet processing when their constraints differ.
- Placement needs evidence for the specific workload’s constraints.Timing, safety, connectivity, data sensitivity, and operations ownership determine which work can safely move away from the site.
Major section
Every handoff has a responsibility and failure behaviour
The IoT flow connects site records to shared services; follow storage and analytics, then inspect the controlled return path separately.
- The site and edge stage owns sensing, action, and local continuity.Devices feed gateways that validate, translate, filter, and buffer records before those records enter the remote path.
- Cloud ingestion and storage preserve approved shared information.Normalized MQTT events can reach a time-series store for building dashboards and compliance reports once identity and data checks succeed.
- Analytics and dashboards provide a view across the retained evidence.Monthly energy benchmarks, certificate inventories, and model-training datasets can benefit from comparison across buildings.
- The return path needs controlled approval for changes.Configuration or model updates must return through an owned channel with failure behaviour instead of turning the dashboard into unchecked local authority.
Major section
Timing distinguishes a local alarm from fleet analysis
The decision deadline and outage requirement determine which jobs can leave the site.
- A freezer alarm needs local execution when remote travel is too slow.Thermostat commands and fire-damper signals also require a site path when their decision cannot wait for an internet round trip.
- Fleet comparisons can use cloud processing when their timing permits delay.Monthly energy benchmarks, remote certificate inventories, and model-training datasets need a shared view more than immediate local response.
- The timing record must include queues as well as network travel.Remote processing and waiting time are part of the decision budget rather than invisible overhead after the gateway handoff.
- A local fallback needs evidence during actual loss of connectivity.A normal online dashboard cannot establish that a building alarm or ventilation response continues while the remote path is unavailable.
Activity 1 · Match
✎ Place the building workloads
I need each job placed where its timing and connectivity needs can be met.
Match local, cloud, or hybrid to freezer alarm, ventilation fallback, monthly energy benchmark, fleet certificate inventory, and approved summaries with site buffering. Give one timing or outage reason for each choice.
4 minutes · Pen and paper · Answer: Activity 1
Major section
Data and recovery rules travel with the placement
The workload’s data and recovery obligations remain attached after the cloud handoff.
- Central processing needs classified, minimized, protected, and approved data.Raw telemetry can expose personal, operational, safety, or proprietary context before anyone has defined retention or access rules.
- Disconnected sites need explicit buffering, filtering, and local action.The gateway’s normal online behaviour cannot establish what happens during link loss or when its storage fills.
- The remote path needs retry, deduplication, and back-pressure evidence.Reconnect traffic can overload a service unless queue limits and replay behaviour are part of the reviewed recovery contract.
- Cloud and site responsibilities need accountable owners after the handoff.Access, scaling, retention, alerts, and rollback belong beside local procedures and safe-state authority in the placement record.
Major section
Twenty buildings share history while keeping fallback local
The university example combines shared comparison with local fallback and finite buffering.
- The cloud can compare CO2 trends and weekday energy baselines.Facilities dashboards and maintenance audit trails can gain value from information collected across the university’s buildings.
- Each gateway can buffer several hours of local records.The site still needs disk-full behaviour and failed-upload alerts because a finite queue cannot guarantee indefinite outage storage.
- Local ventilation fallback and alarms remain site responsibilities.Filtering, short-term buffering, and building-protocol translation support continuity while fleet reporting uses remote services.
- A hybrid design can send approved summaries while preserving local control.Certificate rotation, topic authorization, raw high-frequency signals, and failed uploads still need visible ownership across that split.
Major section
The review record follows one telemetry event
The review record follows telemetry into storage and acceptance; trace the queue and identity checks toward hourly summaries, metrics, and owner signoff.
- The device fields identify the event and its interpretation.Identity, firmware, timestamp, sequence number, site id, units, quality, and schema version make the measurement reviewable.
- Gateway validation and queuing preserve the record before cloud ingress.An idempotency key and MQTT over TLS publication support a defined path whose duplicate and retry behaviour can be tested.
- Retention separates short-lived raw data from longer-lived summaries.The example asks which raw records are deleted after seven days and which hourly summaries remain for compliance.
- Metrics and owner signoff connect the path to operational acceptance.Logs, queue measurements, access records, runbooks, and rollback procedures provide evidence for the service contract beyond a live chart.
Major section
Service contracts define replay, retention, and return authority
A service contract should make the behaviour during failure observable and owned.
- The ingestion contract needs an accepted event shape and identity.Topic authorization, unexpected-field rejection, queue limits, duplicate handling, and retry expectations determine what happens during reconnect pressure.
- The storage contract needs retention, deletion, and access responsibilities.Raw and summary copies can have different lifetimes, roles, and audit boundaries without leaving ownership implicit.
- The analytics contract needs freshness and approval before results trigger action.Batch or streaming processing and model updates must preserve the evidence used to check a result before operational reliance.
- The return-path contract needs rollout, monitoring, rollback, and local override.Configuration, models, and firmware require an authorized change owner rather than unrestricted control from a successful cloud session.
Activity 2 · Draw it
✎ Sketch the reconnect evidence path
I need the event’s identity and recovery rules to survive every handoff.
Sketch device event, gateway queue, authenticated cloud ingress, raw storage, and hourly summaries. Add duplicate handling, a schema-failure alert, and an approved return path. Mark the owner or rule needed at each boundary.
4 minutes · Pen and paper · Answer: Activity 2
Major section
Shared services complement explicit local responsibilities
Cloud resources are useful when the design preserves the site’s timing and continuity obligations.
- Cloud capabilities can support ingestion, analytics, identity, updates, and fleet operations.Automated, network-accessible, pooled, elastic, and measured services are useful when they match the actual workload.
- Immediate safety and local fallback need explicit site placement.A refrigeration alarm cannot inherit resilience from a scalable dashboard when its required action must survive internet loss.
- Data movement needs sensitivity, retention, and access evidence.Raw-data minimization and approved summaries preserve the information boundary as local records become shared fleet history.
- Resilience needs observations and owners across the entire service chain.Timing, connectivity, queue behaviour, identity, observability, and rollback determine whether the reviewed boundary works during failures.
Deck summary
A cloud claim needs an operating story and evidence
The release claim needs a tested operating boundary that someone can revisit.
- A useful cloud placement starts with shared visibility or another concrete need.Durable evidence, elastic capacity, and fleet coordination must justify the remote boundary for the reviewed device group.
- A safe local path needs to retain authority during internet loss.Immediate alarms, fallback, filtering, and buffering remain near devices when timing and continuity require site execution.
- Acceptance needs more evidence than a working online display.Outages, burst load, over-collection, unsafe return changes, and ownership drift can remain hidden in a normal dashboard demonstration.
- Future review needs an accountable owner and named assumptions.Workload intent, data class, timing class, failure behaviour, and observability explain when a placement decision should be revisited.
Retrieval practice
Recall check 1 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q1Which statement best describes cloud computing as an IoT architecture capability?
Show answer
Answer: A Cloud is useful in IoT when its service characteristics are tied to workload needs and separated from edge responsibilities.
Retrieval practice
Recall check 2 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q2A cold-storage gateway must sound a local alarm when room temperature stays outside the allowed range, even if internet access is down. Cloud dashboards are still needed for fleet reporting. Where should the alarm decision run?
Show answer
Answer: A Cloud and edge work together.
Retrieval practice
Recall check 3 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q3Which evidence best supports accepting an IoT workload for cloud-side processing?
Show answer
Answer: A Under-the-hood cloud evidence connects workload intent, data and timing classes, edge boundaries, resilience, observability, and ownership.
Print reference
Answers
Answer key.
- A · Cloud is useful in IoT when its service characteristics are tied to workload needs and separated from edge responsibilities.
- A · Cloud and edge work together.
- A · Under-the-hood cloud evidence connects workload intent, data and timing classes, edge boundaries, resilience, observability, and ownership.
Print reference
Activity 1 answer
Model answer.
Match: Freezer alarm and ventilation fallback are local because they must continue without internet. Monthly energy benchmarks and fleet certificate inventory fit shared cloud comparison. Approved summaries with site buffering are hybrid because local continuity accompanies remote reporting.
Print reference
Activity 2 answer
Model answer.
Draw it: The event retains identity and timing through validation and the queue. An idempotency key and ingress rules govern replay and duplicates. Schema failures raise an owned alert. Raw and summary storage have retention rules; approved changes return with rollout, rollback, and local override conditions.