3 Cloud Service Models for IoT

3.1 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. Picture a small team that gathers readings, stores them, and shows a heat alert. A cloud offer can run some of that work. The first choice is which duties the team keeps and which duties the provider takes.

List device identity, message shape, data rules, run code, user access, backup, recovery, and support. Mark one owner for each. Then test a normal reading, a bad message, a lost cloud link, a provider fault, and a restore. Record who sees the fault, who acts, what the device does, and how old data is handled.

Giving away more run work can speed delivery, but it may limit control or make a move harder. Keeping more can allow a special design, but it adds patch, scale, and on-call work. The service label alone does not choose the compute shape or safe edge action. Use the Practitioner layer to match duties to workloads and write the review record. Use the Under the Hood layer to inspect run shape, queues, state, recovery, and provider limits. Those routes test whether the duty line is clear in real failure.

3.2 Start With the Workload Duty

A cloud service model is a duty split. A team may own the application logic, the runtime, the operating system, the broker, or only the data contract, and each split changes what the team can fix during an IoT incident.

Start simple: pick one workload, such as alarm routing or firmware distribution, and ask who patches it, scales it, observes it, and recovers it. The right model is the one whose duty split matches that evidence.

3.3 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. 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.

IaaS gives the team more control over infrastructure and runtime choices. PaaS delegates more platform operation while the team still owns device behavior, application logic, data rules, and access policy. 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. PaaS might mean using AWS IoT Core or Azure IoT Hub for device identity, MQTT ingestion, routing rules, and managed queues while the team still owns topic design, payload validation, alert policy, data retention, and application release behavior. SaaS might mean using a finished fleet dashboard or work-order surface, but the team still owns device enrollment quality, role assignment, export rehearsals, integration tests, and the exit path if the workflow no longer fits.

The model is therefore a statement about accountable work. It should say who rotates gateway certificates, who reviews broker topic permissions, who restores historical telemetry, who changes alert thresholds, who answers operator tickets, and who proves that a site can keep alarming during provider or network degradation. Those responsibilities remain visible even when the provider operates more of the stack.

3.4 Match Models to Workloads

Start with the IoT workload, not the cloud label. 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. 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.

Use the same worksheet for every boundary. A managed device registry may reduce certificate-service maintenance, but it does not decide whether a failed revocation blocks command delivery. 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.

3.5 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. The idea is not just "put sensor data in the cloud." It virtualizes the sensor node itself, so one physical sensor or sensor network can appear to many different clients as if each had a dedicated virtual sensor, billed pay-per-use rather than owned outright.

That virtualization splits a role that a plain wireless sensor network keeps in one place. In an ordinary WSN, the same user owns deployment, redeployment, maintenance, and overhead. A sensor-cloud model splits those responsibilities three ways: a sensor owner who owns deployment and physical placement, a Sensor-Cloud Service Provider (SCSP) who takes on redeployment, maintenance, and operating overhead as a managed service, and an end user who only consumes the resulting data. 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.

The workflow behind that split follows the same request-response shape as any managed platform service: a client requests a virtual sensor instance, a virtual sensor manager and controller check the request against a resource pool of compatible physical sensors, allocate and schedule coverage, provision data back to the requester, and release the instance and its resources when the client is done. Treat that as an evidence trail to design for, not as a settled implementation: dynamic caching of sensor data and combined hardware-plus-infrastructure pricing for this model remain active research questions rather than an established practice, so a team adopting a sensing-as-a-service pattern should expect to design its own SCSP-side scheduling and pricing rather than reuse a mature reference implementation.

3.6 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 important detail is whether each runtime shape fits the state, timing, retry, observability, and ownership behavior of the workload.

Before choosing a runtime, make the workload's timing and state visible. Figure 3.1 is the decision route: use it to separate burst reactions, steady processing, persistent coordination, scheduled work, and control that cannot depend on the WAN.

Read Figure 3.1 from the workload shape on the left to a candidate runtime on the right. 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. This preserves the chapter's central distinction: the compute pattern describes how work behaves, while the service model records who operates it.

The review record should tie both choices together. 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. 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.

This is also where teams catch mismatched promises: a serverless retry policy cannot fix a non-idempotent command, and a managed broker cannot prove local alarm behavior during a WAN outage.

A runtime that fits today does not justify splitting it into independent services tomorrow. Use Figure 3.2 to see which operational pressures warrant a new boundary and which review questions must be answered before the split.

Follow Figure 3.2 from one workload through internal modules and separated workers to independent services. 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 later shapes add deployment and coordination obligations, so they are not automatic maturity levels. This extends the running duty-split narrative: change the runtime boundary only when the evidence shows that the new operating responsibilities are justified.

Every service-model choice should leave a record. 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.

Figure 3.3 turns that list of obligations into a handoff artifact. Inspect it before approval so that a service label and a runtime choice cannot hide the layers the team still owns.

Read Figure 3.3 from workload intent and model choice into the two ownership columns: owned layers and delegated layers must form a complete duty split. Then connect the compute pattern to data obligations, operations proof, and portability rather than treating it as an isolated technology selection. Finish at named ownership and signoff, because an unowned change signal cannot trigger a real review. The record closes this section's narrative by linking workload behaviour, service responsibility, and operational evidence in one decision.

3.7 Summary

Cloud service models for IoT are ownership boundaries. IaaS gives more infrastructure control and more operating responsibility. PaaS can reduce platform work while leaving device, data, application, access, and operations decisions with the team. SaaS can accelerate dashboards, alerts, workflow, and fleet-management surfaces when configuration, data quality, integration, role design, export, and exit boundaries are acceptable. The right model is the one supported by workload behavior, operating capacity, security needs, data obligations, recovery evidence, and a clear review record.

3.8 Key Takeaway

3.9 See Also