107  Cloud Service Models for IoT

In 60 Seconds

Three cloud service models define responsibility boundaries: IaaS (you manage OS + apps), PaaS (you manage just your app), SaaS (you manage just your data). Use serverless (Lambda) for bursty IoT workloads under 3M events/month; switch to containers for sustained throughput above 10M events/month or sub-50ms latency needs. Start monolithic for MVP (ships 3-6 months faster), refactor to microservices only when hitting team coordination or scaling limits.

107.1 Learning Objectives

By the end of this chapter, you will be able to:

• Distinguish Service Models: Compare IaaS, PaaS, and SaaS and their IoT applications
• Select Appropriate Models: Choose the right service model based on team capabilities and requirements
• Explain Shared Responsibility: Describe what you manage vs. what the provider manages in each model
• Evaluate Trade-offs: Assess serverless vs. container-based and monolithic vs. microservices architectures

For Beginners: Cloud Service Models for IoT

This chapter covers foundational concepts for designing IoT systems at scale. Think of IoT system design like city planning – you need to consider where devices go, how they communicate, where data is stored, and how everything stays secure. Reference architectures and design principles help you create systems that work reliably and can grow over time.

107.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Cloud Computing Fundamentals: Understanding of NIST cloud model and essential characteristics
• Networking Basics: Knowledge of network protocols for cloud connectivity

107.3 The Three Service Models (Overview)

Think of cloud service models like pizza:

Service Model	Pizza Analogy	What You Manage
IaaS (Infrastructure)	Make at home (buy ingredients, oven)	You manage: OS, apps, data
PaaS (Platform)	Take-and-bake (pre-made, your oven)	You manage: Just your app
SaaS (Software)	Delivery (ready to eat)	You manage: Just your data

IoT Examples:

• IaaS: Rent virtual servers (EC2) to run your own IoT platform
• PaaS: Use AWS IoT Core - they handle servers, you handle device code
• SaaS: Use a ready-made dashboard (Ubidots) - just connect your sensors

Figure 107.1: Cloud service models - IaaS, PaaS, and SaaS showing abstraction layers and provider responsibilities

Figure 107.2: Different cloud service models showing infrastructure components managed by provider vs customer

107.4 Pitfall: Choosing IaaS When PaaS Would Suffice

Common Pitfall: Over-Engineering with IaaS

The Mistake: Teams default to IaaS (renting VMs and managing everything) for their IoT platform because it feels more “professional” or gives more control, when a managed PaaS offering would be faster, cheaper, and more reliable.

Why It Happens: Engineers enjoy building infrastructure and underestimate the ongoing maintenance burden. Management assumes “owning” servers means better security. The true cost of patching, scaling, and monitoring custom infrastructure is not calculated upfront.

The Fix: Start with PaaS (AWS IoT Core, Azure IoT Hub) unless you have a specific technical requirement that PaaS cannot meet. Common legitimate IaaS reasons include: custom protocols not supported by PaaS, regulatory requirements for data residency on specific hardware, or extreme cost optimization at massive scale (more than 1 million devices). For prototypes and production up to 100,000 devices, PaaS typically saves 50-70% in total cost of ownership.

107.5 Software as a Service (SaaS)

Definition: Complete applications delivered over the internet, managed entirely by the provider.

Characteristics:

• No software installation required
• Accessed via web browser or thin client
• Automatic updates and patches
• Multi-tenant architecture
• Subscription-based pricing

IoT-Specific SaaS Examples:

• ThingSpeak: IoT analytics platform
• Losant: IoT application enablement
• Particle: IoT device management
• Ubidots: IoT dashboards and alerts

Figure 107.3: SaaS IoT platform architecture.

Figure 107.4: SaaS business advantages - reduced costs, automatic updates, accessibility, and scalability

107.6 Serverless vs. Container-Based IoT Backend

Tradeoff: Serverless (Lambda/Functions) vs Container-Based

Option A: Serverless Functions - Event-driven compute that scales automatically to zero. Pay only for execution time. No infrastructure management.

Option B: Container-Based (ECS/Kubernetes) - Long-running containers with predictable capacity. Better for sustained workloads but requires capacity planning.

Decision Factors:

• Choose Serverless when: IoT messages arrive in unpredictable bursts, cold start latency of 100-500ms is acceptable, individual function execution completes in under 15 minutes, or team lacks container orchestration expertise.

• Choose Containers when: Sustained high throughput exceeds 100 requests/second continuously, cold start latency must be under 50ms, stateful processing requires persistent connections, or workloads run longer than 15 minutes.

• Cost crossover point: At 1-3M requests/month with average 200ms execution, costs are roughly equivalent. Below this, serverless wins. Above 10M requests/month, containers are 40-60% cheaper.

Minimum Viable Understanding: Event-Driven Architecture

Core Concept: Event-driven architecture processes IoT data as discrete events (sensor reading, state change, threshold breach) that trigger downstream actions, rather than continuously polling.

Why It Matters: IoT systems generate data unpredictably - a motion sensor may fire 100 times per minute during activity then remain silent for hours. Event-driven patterns handle this naturally, scaling to zero during quiet periods.

Key Takeaway: Use serverless functions for event-driven IoT when messages arrive in bursts, cold start latency under 500ms is acceptable, and monthly volume is under 3M events. Switch to containers for sustained throughput or sub-50ms latency.

For Kids: Meet the Sensor Squad - Event Edition

Event-driven architecture is like having friends who only speak up when something important happens!

107.6.1 The Sensor Squad Adventure: The Quiet Heroes

Once upon a time in Smart Home Town, the Sensor Squad had a big problem. Thermo the temperature sensor, Lumi the light sensor, Speedy the motion detector, and Droplet the humidity sensor were ALL talking at the same time, every single second!

“The temperature is 72 degrees!” shouted Thermo. “The light is bright!” yelled Lumi. “Nobody is moving!” announced Speedy.

They did this EVERY. SINGLE. SECOND. The Smart Home Computer was SO tired!

That’s when wise old Gatekeeper Gloria had an idea. “What if you only speak up when something IMPORTANT happens?”

Now Thermo stays quiet until the temperature changes by more than 2 degrees. Speedy waits until someone actually walks by. The Computer could rest most of the time, then spring into action exactly when needed!

107.6.2 Key Words for Kids

Word	What It Means
Event	Something important that happens, like a door opening
Trigger	What makes something start, like motion triggering a light
Idle	Resting quietly when nothing important is happening

107.7 Platform as a Service (PaaS)

Definition: Development and deployment platform for building cloud applications without managing underlying infrastructure.

Characteristics:

• Operating system and middleware provided
• Development tools and frameworks
• Automated scaling and load balancing
• Integrated CI/CD pipelines
• Database and storage services

IoT PaaS Examples:

• AWS IoT Core: End-to-end IoT platform
• Microsoft Azure IoT Hub: PaaS for IoT solutions
• IBM Watson IoT Platform: AI-enabled IoT
• AWS IoT Greengrass: Edge computing platform

Figure 107.5: PaaS IoT development workflow.

107.8 Monolithic vs. Microservices IoT Backend

Tradeoff: Monolithic vs Microservices Architecture

Option A (Monolithic): Single deployable unit containing device management, data ingestion, analytics, and alerting. Simpler deployment, easier debugging, lower operational overhead.

Option B (Microservices): Independent services for each function, communicating via API gateway and message queues. Independent scaling, technology flexibility, fault isolation.

Decision Factors:

• Choose Monolithic when: Team size is under 10 developers, device count is under 50,000, release frequency is monthly or less, or time-to-market is critical (monolith ships 3-6 months faster).

• Choose Microservices when: Multiple teams (3+) need independent deployment cycles, different services have vastly different scaling needs, or system must handle 100,000+ devices with varying load patterns.

• Migration path: Start monolithic for MVP (3-6 months faster). Refactor to microservices when you hit team coordination bottlenecks or scaling limits.

Microservices Architecture for IoT

Figure 107.6: Microservices architecture enabling modular scalable IoT platform design

For Kids: Meet the Sensor Squad - Microservices Edition

Microservices is like having a team where each friend has ONE special job they do really well!

107.8.1 The Sensor Squad Adventure: The Super Specialist Team

At first, Thermo the temperature sensor tried to do EVERYTHING - measure temperature, send alerts, save data, AND make reports. Poor Thermo was exhausted!

Then wise old Gateway Greg had an idea. “What if we split up the jobs?”

So they formed the Microservices Team: - Thermo ONLY measures temperature - Alert Annie ONLY sends warnings - Data Dave ONLY saves information - Report Ruby ONLY makes charts

Everyone does ONE thing really well, and if Alert Annie gets sick, the others keep working!

107.8.2 Try This at Home!

Get your family to help with a chore using the microservices way! Instead of one person doing ALL the dishes (wash, dry, put away), split it up: one person ONLY washes, one ONLY dries, one ONLY puts away. Notice how it goes faster?

107.9 Infrastructure as a Service (IaaS)

Definition: Virtualized computing resources over the internet, providing fundamental infrastructure components.

Characteristics:

• Virtual machines, storage, networks
• Full control over OS and applications
• Pay-per-use for compute/storage/bandwidth
• Programmatic resource provisioning
• Geographic distribution options

IoT IaaS Use Cases:

• Custom IoT platform deployment
• High-performance data processing
• Large-scale data lake storage
• Network infrastructure for IoT gateways

Figure 107.7: IaaS infrastructure provisioning.

Tradeoff: IaaS vs PaaS for IoT Platform Deployment

Option A: IaaS (EC2, Azure VMs) - Rent virtual machines and manage OS, runtime, scaling, and security yourself. Full control but high operational burden.

Option B: PaaS (AWS IoT Core, Azure IoT Hub) - Managed platform handles infrastructure while you focus on application code. Less control but faster deployment.

Decision Factors:

• Choose IaaS when: Custom protocols not supported by PaaS are required, regulatory requirements mandate specific OS configurations, or extreme cost optimization at scale (1M+ devices) justifies engineering investment.

• Choose PaaS when: Time-to-market is critical (weeks vs months), team lacks infrastructure expertise, device count is under 100,000, or automatic scaling and security patching are valued over customization.

• Default recommendation: Start with PaaS. Migrate to IaaS only when you hit specific platform limitations.

107.10 Service Model Selection Decision Tree

Figure 107.8: Service model selection decision tree based on team capabilities.

107.11 Shared Responsibility Model

Security Layer	IaaS (You Manage)	PaaS	SaaS
Applications	You	You	Provider
Data	You	You	You
Runtime	You	Provider	Provider
Middleware	You	Provider	Provider
Operating System	You	Provider	Provider
Virtualization	Provider	Provider	Provider
Servers/Storage	Provider	Provider	Provider
Networking	Provider	Provider	Provider

107.12 Worked Example: IoT Backend Cost Comparison Across Service Models

Worked Example: Choosing a Service Model for 10,000 Smart Meters

Scenario: A utility company deploys 10,000 smart electricity meters. Each meter sends a 200-byte reading every 15 minutes (96 readings/day). The backend must store 1 year of data, provide a real-time dashboard, and generate daily billing summaries.

Given:

Parameter	Value
Devices	10,000 smart meters
Message size	200 bytes
Frequency	Every 15 minutes (96 messages/device/day)
Total messages/month	10,000 x 96 x 30 = 28.8 million messages/month
Data volume/month	28.8M x 200 bytes = 5.76 GB/month
Retention	12 months = 69 GB total
Team	4 developers, 1 DevOps engineer

Option A: IaaS (Self-managed on EC2)

Component	Monthly Cost
2x t3.large instances (MQTT broker + app server)	$120
RDS PostgreSQL db.r5.large	$260
S3 storage (69 GB)	$2
Data transfer	$50
DevOps engineer time (20 hrs/month maintenance)	$2,000
Total	~$2,432/month

Option B: PaaS (AWS IoT Core + managed services)

Component	Monthly Cost
AWS IoT Core (28.8M messages x $1/million)	$29
IoT Rules Engine (28.8M evaluations x $0.15/million)	$4
Lambda functions (daily billing: 300K invocations)	$8
DynamoDB (5.76 GB writes + reads)	$45
S3 archive	$2
Total	~$88/month

Option C: SaaS (Ubidots Business)

Component	Monthly Cost
Ubidots Business (10,000 devices)	$499
Custom billing integration (API calls)	$50
Total	~$549/month

Decision:

Criterion	IaaS	PaaS	SaaS
Monthly cost	$2,432	$88	$549
Time to deploy	3-4 months	4-6 weeks	1-2 weeks
Customization	Full	High	Limited
Operational burden	High	Low	None
Scalability to 100K	Manual	Automatic	Plan upgrade

Result: PaaS wins on cost ($88/month vs $2,432 for IaaS) and deployment speed (6 weeks vs 4 months). SaaS is faster to deploy but 6x more expensive than PaaS and limits billing customization. IaaS is only justified if the utility requires custom protocol support or strict data residency on specific hardware.

Key Insight: At 28.8 million messages/month, PaaS is 96% cheaper than IaaS because the DevOps labor cost dominates the IaaS bill. The PaaS cost advantage narrows above 500 million messages/month where per-message pricing exceeds infrastructure costs.

Putting Numbers to It

Breaking point analysis: When does PaaS cost overtake IaaS as message volume scales?

\[ \text{PaaS monthly cost} = \text{base services} + (n \times \$1/\text{M messages}) \]

\[ \text{IaaS monthly cost} = \text{infrastructure} + \text{DevOps labor} \]

At 28.8M messages: PaaS = $88, IaaS = $2,432. Solving for breakeven where PaaS = IaaS:

\[ \$29 + (n \times \$1) = \$432 \text{ (IaaS without labor)} \]

\[ n \approx 400\text{M messages/month} \text{ (breakeven)} \]

Above 500M messages/month, infrastructure economies of scale favor IaaS. Below 100M, PaaS wins decisively.

107.12.1 Interactive: Service Model Cost Comparison

viewof sm_devices = Inputs.range([100, 500000], {value: 10000, step: 100, label: "Number of IoT Devices"})

viewof sm_msg_day = Inputs.range([1, 288], {value: 96, step: 1, label: "Messages per Device per Day"})

sm_msg_month = sm_devices * sm_msg_day * 30
sm_paas_cost = (sm_msg_month / 1e6) * 1.00 + (sm_devices * 43200 / 1e6) * 0.08 + 60
sm_iaas_cost = 240 + 2000  // 2x t3.large + DevOps labor
sm_saas_cost = Math.max(50, sm_devices * 0.05)

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
  <p><strong>Monthly Messages:</strong> ${(sm_msg_month / 1e6).toFixed(1)}M</p>
  <p><strong>IaaS Estimated Cost:</strong> $${sm_iaas_cost.toLocaleString()}/month <em>(compute + DevOps labor)</em></p>
  <p><strong>PaaS Estimated Cost:</strong> $${sm_paas_cost.toFixed(2)}/month <em>(AWS IoT Core + managed services)</em></p>
  <p><strong>SaaS Estimated Cost:</strong> $${sm_saas_cost.toFixed(2)}/month <em>(per-device subscription)</em></p>
  <p style="font-size:0.85em; color:#555;"><strong>Recommendation:</strong> ${sm_msg_month > 500e6 ? "Consider IaaS at this message volume" : sm_devices < 5000 ? "SaaS or PaaS both viable at small scale" : "PaaS offers best cost/flexibility balance"}</p>
</div>`

Match: Cloud Service Model Concepts

Order: IoT Backend Architecture Evolution

Key Concepts

• IaaS (Infrastructure as a Service): Cloud delivery of virtualized computing, storage, and networking where the customer manages OS, middleware, and applications — maximum control at maximum management burden (e.g., EC2, Azure VMs)
• PaaS (Platform as a Service): Cloud delivery of a development and deployment platform where the provider manages OS, runtime, and middleware — developers focus on application code only (e.g., AWS Elastic Beanstalk, Azure App Service, Heroku)
• SaaS (Software as a Service): Fully managed applications delivered over the internet where the provider manages everything including the application itself (e.g., Salesforce IoT, AWS IoT Analytics, Splunk)
• FaaS (Function as a Service): Serverless execution model where individual functions are triggered by events (MQTT messages, HTTP requests) and scale to zero when idle, eliminating server management entirely (AWS Lambda, Azure Functions)
• Managed IoT Service: A PaaS/SaaS offering providing device management, message routing, and protocol translation as fully managed services, eliminating the need to operate MQTT brokers, device registries, or connection management infrastructure
• Total Cost of Ownership (TCO): The complete cost of an IT solution including initial capital expenditure, ongoing operational costs, and hidden costs (staff time, support, training), used to compare IaaS vs. on-premises vs. managed services
• Vendor Lock-in: The dependency created when IoT architectures use cloud-provider-specific APIs, data formats, or protocols that make migration to alternative providers technically difficult and expensive

Common Pitfalls

1. Choosing IaaS to “Save Money” on a Small Team

A 3-person startup choosing raw EC2 instances over managed IoT PaaS to avoid “vendor dependency.” Managing OS patching, MQTT broker clustering, load balancing, and monitoring consumes the entire team’s time. Use managed services unless your team exceeds 10 engineers with dedicated infrastructure staff.

2. Building on Deprecated PaaS Runtimes

Deploying IoT middleware on cloud PaaS runtime versions that are scheduled for end-of-life. Google Cloud IoT Core was deprecated with 12 months’ notice, leaving IoT teams scrambling to migrate. Always verify runtime lifecycle and build migration paths into architecture reviews.

3. Ignoring Egress Costs in SaaS Pipelines

Designing an IoT data pipeline that pulls data from one SaaS service and feeds it to another in a different cloud. Data crossing cloud boundaries incurs $0.08–0.12/GB egress fees. At 1 TB/day this costs $44,000/year. Model data flows and egress costs before finalizing service selection.

4. Over-Engineering with FaaS for High-Throughput IoT

Using serverless functions to process every individual MQTT message from 100,000 devices reporting every second. At 100,000 invocations/second, FaaS cold start latency and per-invocation costs become significant. Use stream processing (Kinesis, Kafka) for high-throughput IoT; reserve FaaS for low-volume event-driven logic.

Label the Diagram

💻 Code Challenge

107.13 Summary

This chapter covered cloud service models for IoT:

1. SaaS: Fastest deployment, least control - ideal for dashboards and analytics
2. PaaS: Balance of speed and customization - ideal for custom IoT applications
3. IaaS: Maximum control, most management - ideal for custom infrastructure
4. Serverless vs. Containers: Choose based on traffic patterns and latency requirements
5. Monolithic vs. Microservices: Start simple, evolve when needed

107.14 Knowledge Check

Question 1: Service Model Selection

A startup with 3 developers and no DevOps engineer needs to launch an IoT product for 5,000 devices within 3 months. Which service model should they choose?

A. IaaS – rent VMs and build custom infrastructure B. PaaS – use managed services like AWS IoT Core C. SaaS – use an off-the-shelf IoT platform D. Private cloud – deploy on-premises servers

Answer: B. PaaS provides managed infrastructure (no DevOps needed), pay-per-use pricing, and enough flexibility for custom application logic. IaaS would require too much infrastructure expertise, SaaS may lack customization, and private cloud requires months of setup.

Question 2: Serverless vs. Containers

An IoT system processes vibration data from 500 machines at 100Hz continuously (50,000 readings/second) with a 200ms alert latency requirement. Which compute architecture is best?

A. AWS Lambda functions triggered per reading B. Container-based stream processing (ECS/Kubernetes) C. A single large EC2 instance D. SaaS analytics platform

Answer: B. Containers provide no cold start (meeting the 200ms requirement), cost-effective processing at sustained high throughput, and stateful processing with local caching. Lambda’s cold start (100-500ms) would violate the latency requirement, and at this volume, Lambda costs approximately 7x more than containers.

Question 3: Architecture Evolution

When should an IoT platform team migrate from a monolithic to a microservices architecture?

A. Immediately at project start for best practices B. When team coordination bottlenecks or scaling limits are hit C. After the first customer complaint D. Never – monolithic is always better

Answer: B. Start monolithic for MVP (ships 3-6 months faster). Migrate to microservices when multiple teams (3+) need independent deployment cycles, different services have vastly different scaling needs, or the system must handle 100,000+ devices with varying load patterns.

107.15 Knowledge Check

Quiz: Cloud Service Models for IoT

107.16 What’s Next

Direction	Chapter	Description
Next	Cloud Deployment Models	Public, private, and hybrid cloud models
Next	Cloud Platforms and Message Queues	Compare AWS, Azure, and messaging technologies
Back	Cloud Computing Fundamentals	NIST model and essential characteristics