7 Cloud Platforms: Provider Checks and Selection

7.1 Start With the Decision

A provider demo cannot prove fleet behavior under load or outage. Simulations and checks must test the path the product will use.

7.2 Route Overview

This is part 2 of 2. Review Cloud Platforms: Message Paths and Capacity for the preceding evidence.

7.3 Learning Objectives

• Design simulation and provider checks for an IoT workload.
• Record platform selection with capacity and storage evidence.

7.4 Chapter Roadmap

• Simulation and Provider Checks
• Cold-Storage Platform Messaging
• Platform Selection Record
• Common Pitfalls
• Do Not Pick by Feature Lists
• 2. Treating A Broker As A Database
• 3. Ignoring Duplicate Messages
• 4. Hiding Failed Messages
• Platforms Map Message Duties
• Platform Selection Record
• Reliability Across Boundaries
• Summary
• Key Takeaway
• See Also

7.5 Simulation and Provider Checks

Cloud simulators and named provider stacks are useful when they turn assumptions into repeatable evidence. They should not replace the platform record.

Use simulation when a real deployment would be too slow, expensive, or disruptive to test directly. A simulator record should name the workload, topology, virtual machines or services, scheduling policy, network delay, storage behavior, energy or cost model, and the values changed between runs. Tools in this family include CloudSim-style discrete-event simulation for data centers, VMs, brokers, applications, and users; CloudAnalyst-style experiments for geographically distributed users and data centers; and GreenCloud-style experiments for energy and network behavior inside data-center designs. The result is useful only when the run explains what it did not model, such as provider quotas, managed-service behavior, hardware failures, security controls, or operational support.

Named platforms need the same discipline. OpenStack can be a self-managed IaaS control plane when private-cloud control and integration matter, but it brings ownership of compute, networking, images, storage, patching, monitoring, and upgrade risk. Azure, AWS, and similar public clouds can supply managed compute, storage, messaging, analytics, monitoring, machine learning, and IoT services, but the team still owns workload fit, identity policy, data retention, export, cost review, and recovery evidence. For EC2-style virtual machines, record instance family, storage choice, scaling rule, image maintenance, network policy, and the reason the workload needs VM-level control instead of a more managed runtime.

Treat every simulator or provider comparison as a scenario test, not a ranking table. A useful comparison says which design choice changed, which metric moved, which responsibility shifted, and which proof is still required before production.

7.6 Cold-Storage Platform Messaging

A cold-storage operator has gateways at many facilities. Each gateway receives temperature readings, door events, compressor state, local alarm events, and device-health records. The system needs local alarms, central dashboards, maintenance workflows, and replayable records for investigations.

7.7 Platform Selection Record

The platform selection record is the artifact that keeps the chapter from becoming a product comparison.

Reviewers need the diagram Figure 7.1 before accepting platform selection record. The proposition under review is: A platform selection record captures workload intent, message roles, platform responsibilities, capacity records, reliability controls, operations ownership, and portability boundaries. Its visible anchors include Platform decision record and broker, queue, stream, store.

Figure 7.1 becomes useful when Platform decision record is read alongside broker, queue, stream, store. Portability boundary adds the remaining acceptance cue. This supports platform selection record. The visual summarizes: A platform selection record captures workload intent, message roles, platform responsibilities, capacity records, reliability controls, operations ownership, and portability boundaries.

Include:

• Workload intent: what outcome the platform path supports.
• Message roles: telemetry, alert, command, state, audit, replay, or file reference.
• Technology role: broker, queue, stream, state store, time-series store, object store, or application API.
• Reliability controls: QoS, retries, idempotency, deduplication, dead-letter handling, and replay.
• Capacity record: connection count, peak rate, payload size, retention, lag, and load-test result.
• Operations owner: monitoring, scaling, credential rotation, patching, incident response, and check cadence.
• Portability boundary: where service-specific rules, state formats, or deployment assumptions exist.

7.8 Common Pitfalls

7.9 Platforms Map Message Duties

An IoT cloud platform is a set of responsibilities around messages, not a single endpoint. The design must say who proves device identity, who accepts messages, where work is buffered, which events are retained for replay, which state is synchronized, and how commands return toward the field.

Make the platforms map message duties premise visible in the diagram Figure 7.2: Use the platform responsibility map to keep identity, ingestion, routing, storage, observability, state, and return-path duties visible before choosing a managed, self-managed, or hybrid shape. Begin by distinguishing Field side from accept events.

Interrogate Field side first, then find accept events in Figure 7.2. Apply the accept events review question before approved commands and configuration return through a controlled path. Those answers support platforms map message duties; the figure states: Use the platform responsibility map to keep identity, ingestion, routing, storage, observability, state, and return-path duties visible before choosing a managed, self-managed, or hybrid shape.

Read Figure 7.2 as an ordered argument. Start at the input or initiating condition, follow each arrow through the intermediate responsibilities, and finish at the output or evidence record. Notice which boundary, comparison, or transition explains use the platform responsibility map to keep identity, ingestion, routing, storage, observability, state, and return-path duties visible before choosing a managed, self-managed, or hybrid shape. That observation connects this visual to the chapter’s running narrative: use it to justify the next design decision and to record what evidence would confirm it in operation.

Mobile summary: A cloud platform decision is a responsibility decision: prove device identity, accept messages, route work, retain evidence, observe failures, synchronize state, and control commands back to the field.

The broker, queue, and stream answer different parts of that map. A broker handles live publish-subscribe communication, a queue controls processor work, and a stream keeps accepted events available for replay, analytics, and audit.

Keep the first review at message-family level. Room temperature telemetry, compressor-fault alarms, gateway health reports, firmware rollout status, and setpoint commands should not be forced through one generic "cloud messaging" answer. Each family has a different identity check, delivery consequence, retention need, and owner.

For overview review, ask three questions. Which component proves the sender is allowed to publish? Which component absorbs work when downstream processors are slow? Which component keeps accepted events long enough to replay or audit them? If those answers point to different components, the platform design should say so explicitly.

That trace should also name what is not proven. A broker acknowledgement does not prove dashboard freshness. A queue retry does not prove long-term history. A stream replay window does not prove that a command reached a gateway. The overview record should keep those boundaries visible before the team chooses managed, self-managed, or hybrid platform pieces.

A useful minimum record therefore has four columns: message family, platform role, evidence produced, and owner. For example, telemetry may name the broker topic and accepted-event store, alarms may name the queue and escalation owner, replay analytics may name the stream and retention window, and commands may name the return path plus acknowledgement rule. This keeps the overview small while still proving the architecture is more than a product label.

During the first pass, avoid mixing operational promises into one vague availability target. A platform can be available for telemetry while alarm processors are overloaded, replay consumers are behind, or command acknowledgements are delayed. The overview should therefore name the user-visible consequence for each message family: stale dashboard, missed escalation, incomplete audit, unsafe command state, or delayed maintenance action.

7.10 Platform Selection Record

Write one record per major message family. The record should not merely say "use managed IoT" or "self-host MQTT." It should tie workload behavior to the component role, validation evidence, operations owner, and retest trigger.

Use the record to separate normal traffic from stress cases. A platform that handles average telemetry may still fail during a power recovery when every gateway reconnects, resends buffered samples, refreshes credentials, and asks for pending commands. The record should include reconnect-storm behavior, rejected-message inspection, queue catch-up time, and the owner who decides whether to shed, defer, replay, or escalate work.

Also record the portability boundary. Topic naming, rule engines, device shadows, retained state, stream partition keys, and dead-letter formats can become service-specific. That is acceptable when the team names the dependency, tests the export or migration path that matters, and knows which release or compliance event would force a review.

For a cold-storage deployment, a useful record might say: alarm events use QoS 1 into the broker, include an idempotency key, enter a queue with dead-letter alerting, and write accepted alarm state to an audit stream. Temperature summaries use a replay stream with schema version and consumer-lag alert. Commands use a command id, authorization check, gateway acknowledgement, timeout, and rollback owner. Those details make the platform choice testable.

7.11 Reliability Across Boundaries

MQTT QoS can confirm delivery between MQTT endpoints, but it does not prove downstream processing, storage, replay, dashboard state, or command execution. Each boundary needs its own failure rule, duplicate rule, and inspection path.

At the broker boundary, the key questions are session identity, topic authorization, retained-message behavior, duplicate publishes, and whether the acknowledgement means "accepted by broker" or "processed by the application." At the queue boundary, the questions change to visibility timeout, retry count, idempotency, poison-message handling, and when a failed message becomes an incident. At the stream boundary, the questions are partitioning, ordering scope, retention, schema evolution, lag, and replay authority.

Under load, these boundaries interact. A reconnect storm can create duplicate QoS 1 deliveries, queue backlogs, stream lag, dashboard staleness, and delayed commands at the same time. The release record should therefore connect sequence numbers or idempotency keys to the processor, not only to the broker. It should connect dead-letter records to operator action, not only to a storage bucket. It should connect replay windows to the investigation questions the team actually needs to answer.

Command return paths need the same treatment. A command record should include command id, requested state, target group, authorization decision, delivery attempt, gateway acknowledgement, application completion proof, timeout rule, and rollback owner. Without those fields, a platform can show that a command was published while still leaving operators unsure whether the field system accepted or safely applied it.

This is why "exactly once" claims need careful wording. A protocol or service may narrow duplicate behavior for one exchange, but the IoT outcome still depends on application handlers, storage writes, retries, human workflow, and gateway state. The deeper platform proof is a chain of small contracts, each with its own evidence and owner.

For replay and audit, the boundary is not only technical; it is also interpretive. A stream partition key decides which events keep order together. A schema version decides which consumers can safely replay old records. A retention rule decides whether an incident can still be investigated. A lag alert decides when analytics are stale enough to stop trusting a dashboard. Those choices should be recorded beside the broker and queue settings because they change what the platform can prove after an outage or model defect.

Security boundaries also change the reliability claim. Mutual TLS or token validation proves a session identity, not that the device is healthy, calibrated, or authorized for every topic. Topic authorization proves publish permission, not that a payload schema is valid. Schema validation proves shape, not physical truth. The platform record should keep these proofs separate so incident review can locate the failing boundary quickly.

The same separation helps cost and capacity review. Broker connection limits, queue depth, stream retention, storage writes, and alert fan-out scale on different drivers. If the team records the driver at each boundary, it can retest the right part when gateway count, sampling rate, retention policy, or command frequency changes.

7.12 Summary

Cloud platforms and message queues should be selected by workload responsibility, not by brittle named-service comparisons. A durable IoT messaging architecture separates live device communication, work buffering, retained event history, state synchronization, storage integration, and controlled return paths. The quality gate is a validation record: capacity assumptions, QoS and retry behavior, replay tests, dead-letter handling, observability, operations ownership, and portability boundaries.

7.13 Key Takeaway

Cloud platforms should be compared by message responsibilities, reliability boundaries, operations ownership, replay needs, and team operating capability.

7.14 See Also

7.15 Continue Your Route

This final part closes the route from Simulation and Provider Checks through See Also. Return to Cloud Platforms: Message Paths and Capacity or continue from the cloud-sdn-production module index.