Cloud, SDN & Production Architectures · Study deck
Cloud Service Models for IoT
A broker is a service that receives messages and passes them to the right users.
Cloud Clara is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Map IaaS, PaaS, and SaaS as responsibility boundaries (device, data, runtime, access, recovery) rather than maturity levels
- Select a service-model boundary for an IoT workload using the decision worksheet (device identity, protocol/message shape, data obligations, operations capacity)
- Separate the service-model choice from the compute-pattern choice (functions, containers, long-running services, local gateway control)
- Write an 11-field service-model review record naming owned layers, delegated layers, compute pattern, and change signal
Major section
Begin With the Duty You Keep
A broker is a service that receives messages and passes them to the right users.
- Firmware is the code that runs on a device.
- A cloud offer can run some of that work.
- The first choice is which duties the team keeps and which duties the provider takes.
Major section
Begin With the Duty You Keep (continued)
Keeping more can allow a special design, but it adds patch, scale, and on-call work.
- Giving away more run work can speed delivery, but it may limit control or make a move harder.
- The service label alone does not choose the compute shape or safe edge action.
- Those routes test whether the duty line is clear in real failure.
Major section
Service Models Move Duties
Cloud service models are responsibility boundaries.
- They describe which layers the IoT team operates directly and which layers a service provider operates under a contract.
- A model is not automatically mature, secure, cheap, or scalable.
- IaaS gives the team more control over infrastructure and runtime choices.
- The model is therefore a statement about accountable work.
Major section
Service Models Move Duties (continued)
It becomes useful only when the team can name the device, data, runtime, access, recovery, and support responsibilities that remain on each side of the boundary.
- SaaS delivers a finished application surface, but the team still owns configuration, onboarding quality, user roles, integration contracts, export tests, and exit planning.
- For a cold-chain monitoring product, IaaS might mean running Mosquitto, PostgreSQL, and dashboard workers on virtual machines that the team patches, backs up, monitors, and restores.
- Those responsibilities remain visible even when the provider operates more of the stack.
Major section
Match Models to Workloads
A telemetry archive, an alarm route, a command channel, a firmware workflow, and an operator dashboard can have different service-model choices inside the same product.
- Managed identity helps only if it fits the device lifecycle and gateway model.
- Enrollment test, revocation test, role map, and support owner.
Major section
Match Models to Workloads (continued)
The selection is strongest when it documents what the workload must do, which team can operate each layer, what the provider is expected to do, and which change signal will reopen the choice.
- Custom brokers may need IaaS or containers; common ingestion can fit PaaS.
- SaaS can accelerate workflow but may narrow export and retention choices.
- A managed device registry may reduce certificate-service maintenance, but it does not decide whether a failed revocation blocks command delivery.
Major section
Match Models to Workloads (continued)
A SaaS dashboard may reduce frontend work, but it does not prove raw export completeness, role separation, or support handoff.
- A self-managed broker may support unusual bridge behavior, but it also creates patch, capacity, backup, and on-call duties that need named owners.
- Common failure: treating "managed" as "no operations." Managed services still require configuration review, quotas, identity policy, monitoring, incident response, data lifecycle checks, and migration planning.
- IaaS increases control and operations burden; PaaS can reduce platform work.
Major section
A Domain-Specific Variant: Sensing-as-a-Service
IaaS, PaaS, and SaaS are generic cloud service models.
- IoT has produced its own domain-specific variant worth recognizing: Sensing-as-a-Service, sometimes called Sensor-Cloud.
- That virtualization splits a role that a plain wireless sensor network keeps in one place.
- That three-way split is the same service-model boundary question this chapter keeps asking, applied to a physical sensor network instead of a compute or storage resource.
Major section
Runtime Shape and Review Records
The service model and the compute pattern are separate decisions.
- A PaaS-oriented architecture can still use containers, functions, managed jobs, stream processors, or local gateway control.
- An IaaS architecture can still delegate some capabilities to managed services.
- The review record should tie both choices together.
- Every service-model choice should leave a record.
Major section
Runtime Shape and Review Records (continued)
The important detail is whether each runtime shape fits the state, timing, retry, observability, and ownership behavior of the workload.
- A short, retry-safe event can reach a function or managed job; a steady stream or protocol bridge points toward a worker or container; persistent state and connections favour a long-running service.
- The bottom path is deliberately different: when an alarm or control deadline must survive loss of cloud connectivity, execution stays at the gateway.
- It should name the workload, service model, runtime shape, state owner, retry rule, identity boundary, telemetry store, recovery path, quota risk, release owner, and change signal.
Major section
Runtime Shape and Review Records (continued)
For example, a "PaaS ingestion" note is not enough for a freezer alert stream.
- The record needs the MQTT topic contract, certificate rotation owner, queue retention, late-message handling, dashboard freshness rule, export rehearsal, and gateway behavior when cloud acknowledgements stop.
- A runtime that fits today does not justify splitting it into independent services tomorrow.
- The later shapes add deployment and coordination obligations, so they are not automatic maturity levels.
Major section
Runtime Shape and Review Records (continued)
At each transition, stop at the review gate: ownership, scaling demand, release cadence, failure isolation, or a data boundary must supply a concrete reason to split.
- The record names the workload, the selected model, owned layers, delegated layers, compute pattern, data obligations, operations proof, portability assumptions, residual risks, owner, and change signal.
- Without that record, the architecture can drift into hidden obligations: unpatched virtual machines, unmonitored queues, unclear exports, brittle adapters, or a SaaS dependency with no exit path.
- Finish at named ownership and signoff, because an unowned change signal cannot trigger a real review.
Major section
Summary
PaaS can reduce platform work while leaving device, data, application, access, and operations decisions with the team.
- Cloud service models for IoT are ownership boundaries.
- IaaS gives more infrastructure control and more operating responsibility.
- SaaS can accelerate dashboards, alerts, workflow, and fleet-management surfaces when configuration, data quality, integration, role design, export, and exit boundaries are acceptable.
Deck summary
Key takeaways
A broker is a service that receives messages and passes them to the right users.
- Keeping more can allow a special design, but it adds patch, scale, and on-call work.
- Cloud service models are responsibility boundaries.
- It becomes useful only when the team can name the device, data, runtime, access, recovery, and support responsibilities that remain on each side of the boundary.
- A telemetry archive, an alarm route, a command channel, a firmware workflow, and an operator dashboard can have different service-model choices inside the same product.
Retrieval practice
Recall check 1 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q1What is the safest way to explain cloud service models in an IoT architecture decision?
Show answer
Answer: A IaaS, PaaS, and SaaS should be treated as responsibility boundaries with explicit proof, not as quality labels.
Retrieval practice
Recall check 2 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q2A small team is building facility monitoring with secure onboarding, telemetry routing, alerts, dashboards, and limited infrastructure operations capacity. Which starting boundary is most defensible?
Show answer
Answer: A A PaaS-oriented start often fits teams that need managed cloud capability but still own device, data, command, and application behavior.
Retrieval practice
Recall check 3 of 3
Cloud Clara says: answer from memory, then check your reasoning.
Q3Which statement best separates service-model choice from compute-pattern choice?
Show answer
Answer: A A sound IoT architecture records both the service-model boundary and the runtime behavior that implements each workload.
Print reference
Answers
Answer key.
- A · IaaS, PaaS, and SaaS should be treated as responsibility boundaries with explicit proof, not as quality labels.
- A · A PaaS-oriented start often fits teams that need managed cloud capability but still own device, data, command, and application behavior.
- A · A sound IoT architecture records both the service-model boundary and the runtime behavior that implements each workload.