Cloud, SDN & Production Architectures · Study deck

Cloud Platforms: Message Paths and Capacity

A cloud service is a remote program that handles part of the work.

Cloud Clara is your guide for this deck.

cloudcomputingplatforms

Cloud Clara, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: An IoT team using that stack still needs the same release record as any other platform: who owns security groups, key pairs, images, networks, storage volumes, quotas, backups, usage records, and incident response.
Explain: A message lifecycle diagram should show more than "device sends data to cloud." It should expose the control points where errors, duplicates, routing mistakes, and visibility gaps occur.
Explain: Routing may send work to a retry queue and ordered history to a stream; storage and application action are later checks, not part of the broker receipt.

Major section

Start With the Decision

A cloud service is a remote program that handles part of the work.

A hop is one step from one service to the next.
Capacity is how much work a step can handle in a given time; delay is the time that step adds.
A sensor message can cross several such hops before it creates value, and each adds cost and failure work too.

Major section

Start With the Message Path

A broker is a service that directs messages from senders to interested receivers.

The panel sets a fire-door alarm beside room temperature and a monthly energy total.
They all approach one platform, but the question marks show that their routes and urgency are still open.
A queue is a waiting line for work.

Major section

Start With the Message Path (continued)

A burst of routine readings must not delay an alarm, and a lost worker must not erase the only copy of work still due.

A stream is an ordered history that can be read again.
An available platform does not prove a correct application.
Old data, wrong identity, weak access rules, or a harmful receiver action can still produce failure.

Major section

Minimum Viable Understanding

A platform decision is a responsibility decision: Decide who operates device identity, ingestion, routing, state, storage, monitoring, and updates.

Brokers, queues, and streams are not interchangeable: Use each for the role it is built to support.
MQTT QoS is not end-to-end reliability by itself: It describes delivery between MQTT clients and brokers; downstream processing still needs idempotency and replay rules.
Capacity records matter more than product labels: Check connections, message rate, payload size, burst shape, retained state, replay window, and operational ownership.

Major section

Platform Responsibility Map

Some teams consume those capabilities as managed services.

The architecture check should focus on the responsibilities, not on brand names.
The overview depth layer shows the responsibility map that connects field-side devices and gateways to identity, ingestion, routing, observability, state, storage, and controlled return paths.
The review record should explain why that operating shape fits the workload.

Major section

Broker, Queue, Or Stream?

IoT systems often use several message technologies at once.

A device-facing broker is not the same as a processing queue, and neither is the same as a replayable event stream.
A queue buffers work for processors and gives failed jobs a retry or dead-letter review path.
A stream retains ordered event history so consumers can replay it and analytics can inspect earlier events.
A cold-storage message can pass through more than one of these roles.

Message brokers, work queues, and event streams serve different roles in an IoT platform.

Major section

Broker, Queue, Or Stream? (continued)

Broker receipt therefore proves a handoff, while queue pressure, stream lag, and later processing need their own records.

Validation record: session behavior, QoS use, topic naming, authentication, authorization, retained messages, and offline handling.
Validation record: visibility timeout, retry policy, ordering need, idempotency key, poison-message handling, and alerting.
Combining them is common: a gateway publishes to a broker, the platform routes accepted events into a stream, and processors read from queues or stream consumers.

Major section

Message Lifecycle

A message lifecycle diagram should show more than "device sends data to cloud." It should expose the control points where errors, duplicates, routing mistakes, and visibility gaps occur.

A lost QoS 1 acknowledgement can cause a retry, so downstream processing needs an idempotent key.
Routing may send work to a retry queue and ordered history to a stream; storage and application action are later checks, not part of the broker receipt.
The return path may carry an approved command with its own identity, acknowledgement, timeout, and rollback owner.

A cold-storage gateway message moves through identity and topic checks, broker acknowledgment, routing rules, retry queues, retained streams, processing, storage, application action, inspection, and an approved command return path.

Major section

Managed or Self-Managed Platforms

The durable question is not "managed or self-hosted?" The question is "which operating responsibilities should this team own?".

Useful when the team needs deep control over broker behavior, site-local operation, custom protocols, isolated environments, or consistent deployment across many private sites.
Useful when local brokers protect site operation while cloud services handle fleet dashboards, long-term analytics, and cross-site coordination.
That proof should not be mistaken for production readiness.

Major section

Managed or Self-Managed Platforms (continued)

OpenStack is a common example of a self-managed IaaS control plane.

The names are not the design goal; the design goal is still the responsibility boundary.
An IoT team using that stack still needs the same release record as any other platform: who owns security groups, key pairs, images, networks, storage volumes, quotas, backups, usage records, and incident response.
For an IoT lab or private deployment, a DevStack installation can prove the workflow at small scale: create a key pair, create a security group, launch an instance, attach networking, and communicate with the instance.

Platform selection route checks workload intent, connection and message shape, technology roles, state retention, stress evidence, ownership and portability before choosing managed, self-managed or hybrid operation.

Major section

QoS And Reliability

MQTT QoS is useful, but it is not the whole reliability design.

Fit: frequent telemetry where occasional loss is acceptable and newer readings supersede older readings.
Extra controls: sequence numbers or sampling-quality indicators when loss should be visible.
Fit: alerts, state changes, and commands where delivery matters and duplicates can be handled.

MQTT QoS 0, 1, and 2 compared by their actual publish-acknowledgment handshake: QoS 0 is one-way with no acknowledgment, QoS 1 is a publish plus PUBACK round trip with a possible duplicate on resend, and QoS 2 is the four-step PUBLISH, PUBREC, PUBREL, PUBCOMP exchange.

Major section

QoS And Reliability (continued)

Fit: narrow cases where duplicate delivery at the broker boundary is more harmful than added latency and complexity.

QoS 0 sends once without an acknowledgement, so loss can be silent.
QoS 1 adds PUBACK, but a lost acknowledgement can trigger a resend and a duplicate for a subscriber.
QoS 2 uses PUBLISH, PUBREC, PUBREL, and PUBCOMP to settle the message id with more overhead.
That protocol choice does not prove storage, application action, or return commands downstream.

Deck summary

Key takeaways

A cloud service is a remote program that handles part of the work.

A broker is a service that directs messages from senders to interested receivers.
A burst of routine readings must not delay an alarm, and a lost worker must not erase the only copy of work still due.
A platform decision is a responsibility decision: Decide who operates device identity, ingestion, routing, state, storage, monitoring, and updates.
Some teams consume those capabilities as managed services.

Retrieval practice

Recall check 1 of 5

Cloud Clara says: answer from memory, then check your reasoning.

Q1A platform accepts telemetry but loses events during downstream outages. Which responsibility should the team examine?

ABuffering and recovery under bursts or outages

BDevice enrollment as the complete outage solution

CDashboard color as evidence of retained events

DCommand delivery as a replacement for ingestion

Show answer

Answer: A The responsibility map assigns buffering to retry storms and downstream interruptions.

Retrieval practice

Recall check 2 of 5

Cloud Clara says: answer from memory, then check your reasoning.

Q2An analytics team needs ordered event history for replay. Which role best matches that requirement?

AA device broker routing live commands without a retained ordered log.

BA processing work queue distributing tasks among current workers.

CA device identity service issuing credentials for event producers.

DAn event stream retaining ordered records for later replay.

Show answer

Answer: D The section distinguishes replayable ordered history from live routing and queued work.

Retrieval practice

Recall check 3 of 5

Cloud Clara says: answer from memory, then check your reasoning.

Q3A platform diagram stops at broker acknowledgment, yet an alert must reach staff and a command may return. Which trace closes the lifecycle?

ATrace identity, routing, retry, processing, storage, staff action, and return command.

BTreat broker ACK as staff action because acknowledgement means the alert reached its human responder.

CSkip identity and topics merely because the gateway connected once.

DDraw only a return arrow without proving the command reached the device.

Show answer

Answer: A Broker receipt is one handoff; the later result and return path need proof.

Retrieval practice

Recall check 4 of 5

Cloud Clara says: answer from memory, then check your reasoning.

Q4A state-change command may be retried after a lost broker acknowledgment. Which MQTT delivery choice and controls fit?

AUse QoS 1, idempotent ID, saved state and receiver confirmation.

BUse QoS 0 and treat no error as proof of physical actuator execution.

CUse QoS 2 alone without application-level command confirmation.

DUse QoS 1 but run every retry as a new actuator state change.

Show answer

Answer: A At-least-once delivery can repeat, so downstream action must be safe and confirmed.

Retrieval practice

Recall check 5 of 5

Cloud Clara says: answer from memory, then check your reasoning.

Q5A platform team wants a capacity record that will survive a reconnect storm and vendor change. What should it measure?

ACount connections, rates, payload, retained state, limits, lag, and catch-up.

BSize from peak broker brochure rate alone, omitting reconnect and retained load.

CMeasure quiet-day average traffic because that daily rate predicts the queue's behavior during reconnects.

DMeasure only monthly bill without message or consumer capacity.

Show answer

Answer: A These are workload and recovery facts the team can retest.

Print reference

Answers

Answer key.

A · The responsibility map assigns buffering to retry storms and downstream interruptions.
D · The section distinguishes replayable ordered history from live routing and queued work.
A · Broker receipt is one handoff; the later result and return path need proof.
A · At-least-once delivery can repeat, so downstream action must be safe and confirmed.
A · These are workload and recovery facts the team can retest.