Skip to content

Commit ba60c2c

Browse files
hsandmannhsandmann
committed
service model
1 parent 7eecd1b commit ba60c2c

3 files changed

Lines changed: 263 additions & 6 deletions

File tree

‎docs/classes/paas/index.md‎

Lines changed: 0 additions & 1 deletion
This file was deleted.

‎docs/classes/service_models/index.md‎

Lines changed: 245 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,245 @@
1+
2+
Cloud service models define **how much of the stack the cloud provider manages** versus how much the customer manages. The more the provider manages, the less control the customer has — and the faster they can move.
3+
4+
The three foundational models defined by NIST[^1] are **IaaS**, **PaaS**, and **SaaS**. Beyond them, several specialised models have emerged — **FaaS**, **CaaS**, **DBaaS**, and others — each carving out a narrower slice of the stack.
5+
6+
---
7+
8+
## The shared responsibility stack
9+
10+
Every cloud service model can be mapped to the same six-layer stack. The dividing line between what the provider manages (green) and what the customer manages (orange) shifts as you move up the model hierarchy:
11+
12+
``` mermaid
13+
graph TD
14+
subgraph On-Premises
15+
direction TB
16+
A1[Hardware] --> A2[Virtualisation]
17+
A2 --> A3[OS]
18+
A3 --> A4[Middleware]
19+
A4 --> A5[Application]
20+
A5 --> A6[Data]
21+
style A1 fill:#ff9999,stroke:#333
22+
style A2 fill:#ff9999,stroke:#333
23+
style A3 fill:#ff9999,stroke:#333
24+
style A4 fill:#ff9999,stroke:#333
25+
style A5 fill:#ff9999,stroke:#333
26+
style A6 fill:#ff9999,stroke:#333
27+
end
28+
subgraph IaaS
29+
direction TB
30+
B1[Hardware] --> B2[Virtualisation]
31+
B2 --> B3[OS]
32+
B3 --> B4[Middleware]
33+
B4 --> B5[Application]
34+
B5 --> B6[Data]
35+
style B1 fill:#a8e6cf,stroke:#333
36+
style B2 fill:#a8e6cf,stroke:#333
37+
style B3 fill:#ffd3b6,stroke:#333
38+
style B4 fill:#ffd3b6,stroke:#333
39+
style B5 fill:#ffd3b6,stroke:#333
40+
style B6 fill:#ffd3b6,stroke:#333
41+
end
42+
subgraph PaaS
43+
direction TB
44+
C1[Hardware] --> C2[Virtualisation]
45+
C2 --> C3[OS]
46+
C3 --> C4[Middleware]
47+
C4 --> C5[Application]
48+
C5 --> C6[Data]
49+
style C1 fill:#a8e6cf,stroke:#333
50+
style C2 fill:#a8e6cf,stroke:#333
51+
style C3 fill:#a8e6cf,stroke:#333
52+
style C4 fill:#a8e6cf,stroke:#333
53+
style C5 fill:#ffd3b6,stroke:#333
54+
style C6 fill:#ffd3b6,stroke:#333
55+
end
56+
subgraph SaaS
57+
direction TB
58+
D1[Hardware] --> D2[Virtualisation]
59+
D2 --> D3[OS]
60+
D3 --> D4[Middleware]
61+
D4 --> D5[Application]
62+
D5 --> D6[Data]
63+
style D1 fill:#a8e6cf,stroke:#333
64+
style D2 fill:#a8e6cf,stroke:#333
65+
style D3 fill:#a8e6cf,stroke:#333
66+
style D4 fill:#a8e6cf,stroke:#333
67+
style D5 fill:#a8e6cf,stroke:#333
68+
style D6 fill:#a8e6cf,stroke:#333
69+
end
70+
```
71+
72+
:material-square:{ style="color:#a8e6cf" } Provider manages    :material-square:{ style="color:#ffd3b6" } Customer manages    :material-square:{ style="color:#ff9999" } Customer manages (on-premises: everything)
73+
74+
---
75+
76+
## IaaS — Infrastructure as a Service
77+
78+
**You rent raw infrastructure.** The provider supplies virtualised compute, storage, and networking. You install the OS, runtime, middleware, and everything above.
79+
80+
| Provider manages | Customer manages |
81+
|---|---|
82+
| Physical datacentre, power, cooling | OS: installation, patching, hardening |
83+
| Hypervisor and host OS | Runtime and middleware |
84+
| Physical network | Application code and data |
85+
| — | Firewall rules, IAM, backups |
86+
87+
**Examples:** AWS EC2, Google Compute Engine, Azure Virtual Machines, DigitalOcean Droplets.
88+
89+
**When to choose IaaS:**
90+
- You need full OS-level control (custom kernel, specific OS version)
91+
- Lift-and-shift of existing on-premises workloads
92+
- High-performance computing with specialised hardware (GPU instances)
93+
- Strict compliance that requires controlling the entire stack
94+
95+
!!! example "Typical IaaS workflow"
96+
1. Provision a VM (e.g., `t3.medium` on EC2)
97+
2. SSH in, install JDK and your application runtime
98+
3. Configure nginx as reverse proxy
99+
4. Set up cron jobs for backups
100+
5. Handle OS patches manually or via automation (Ansible, SSM)
101+
102+
---
103+
104+
## PaaS — Platform as a Service
105+
106+
**You deploy code; the provider runs it.** The provider manages the OS, runtime, middleware, scaling, and networking. You write the application and configure it via environment variables.
107+
108+
| Provider manages | Customer manages |
109+
|---|---|
110+
| Hardware through runtime | Application code |
111+
| OS patching and updates | Configuration (env vars, scaling rules) |
112+
| Load balancing and auto-scaling | Application data |
113+
| Build pipelines and deployments | — |
114+
115+
**Examples:** Heroku, AWS Elastic Beanstalk, Google App Engine, Azure App Service, Railway, Render.
116+
117+
**Architectural implication:** PaaS favours the **12-factor app** pattern — stateless processes, config via environment variables, logs to stdout. Persistent state must live in external managed services (database, object storage).
118+
119+
**When to choose PaaS:**
120+
- Building a new application without infrastructure expertise on the team
121+
- Rapid prototyping and MVPs
122+
- API backends and microservices that don't need OS control
123+
- Teams that want to ship features, not manage servers
124+
125+
!!! example "Typical PaaS workflow"
126+
1. `git push heroku main` (or connect a GitHub repo)
127+
2. Provider detects the runtime (Java, Node, Python) via buildpacks
128+
3. Provider builds, containerises, and deploys automatically
129+
4. Attach a managed Postgres add-on — no database server to maintain
130+
131+
---
132+
133+
## SaaS — Software as a Service
134+
135+
**You use the software; the provider runs everything.** The customer manages only users, permissions, and the data they put in. There is no infrastructure or application to operate.
136+
137+
| Provider manages | Customer manages |
138+
|---|---|
139+
| Hardware through application | User accounts and permissions |
140+
| Security, compliance, updates | Data entered into the system |
141+
| Multi-tenancy and isolation | Integrations (via APIs/webhooks) |
142+
143+
**Examples:** Google Workspace, Salesforce, Slack, Notion, GitHub, Datadog, PagerDuty.
144+
145+
**Multi-tenancy:** A single application instance serves all customers, with data isolated by tenant ID. This enables economies of scale — and is why SaaS has the lowest time-to-value.
146+
147+
**When to choose SaaS:**
148+
- Off-the-shelf software already meets the need (CRM, HR, email, monitoring)
149+
- The team should not be building or operating the tool itself
150+
- Speed of adoption matters more than customisation depth
151+
152+
---
153+
154+
## Beyond the Big Three
155+
156+
The foundational models have spawned specialised variants targeting a narrower part of the stack:
157+
158+
### FaaS — Function as a Service (Serverless)
159+
160+
The extreme end of PaaS. You deploy individual **functions** rather than applications. The provider manages everything — including scaling to zero when idle — billing only for the milliseconds the function runs.
161+
162+
| | |
163+
|---|---|
164+
| **Unit of deployment** | A single function |
165+
| **Scaling** | Automatic, to zero when idle |
166+
| **Billing** | Per invocation + duration (ms) |
167+
| **Constraint** | Cold starts; max execution time (e.g., 15 min on Lambda) |
168+
| **Examples** | AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers |
169+
170+
**Best for:** event-driven workloads, webhooks, scheduled jobs, sporadic or bursty tasks. Not suited for long-running or consistently low-latency applications.
171+
172+
### CaaS — Container as a Service
173+
174+
Between IaaS and PaaS. You provide **Docker images**; the provider manages the container runtime, orchestration, networking, and scaling. You retain full control of the runtime inside the container.
175+
176+
| | |
177+
|---|---|
178+
| **Unit of deployment** | Docker image |
179+
| **What you control** | Everything inside the container |
180+
| **What provider manages** | Scheduling, networking, scaling, node health |
181+
| **Examples** | AWS ECS / Fargate, Google Cloud Run, Azure Container Instances |
182+
183+
**Best for:** microservices teams already using Docker who want managed orchestration without operating Kubernetes themselves.
184+
185+
### DBaaS — Database as a Service
186+
187+
A managed database where the provider handles provisioning, backups, replication, patching, and failover. You connect with a standard client and run queries.
188+
189+
| | |
190+
|---|---|
191+
| **You manage** | Schema design, query tuning, access control |
192+
| **Provider manages** | Replication, backups, OS patching, failover |
193+
| **Examples** | AWS RDS, Amazon Aurora, Google Cloud SQL, Azure Database, PlanetScale, Neon |
194+
195+
### Other specialised models
196+
197+
| Model | Abbreviation | Examples |
198+
|---|---|---|
199+
| Storage as a Service | STaaS | AWS S3, Google Cloud Storage, Backblaze B2 |
200+
| AI / ML as a Service | AIaaS | AWS Bedrock, Google Vertex AI, Azure AI |
201+
| Monitoring as a Service | — | Datadog, New Relic, Grafana Cloud |
202+
| Security as a Service | SECaaS | Cloudflare, AWS Shield, Snyk |
203+
| Communication as a Service | CPaaS | Twilio, SendGrid, AWS SES |
204+
205+
---
206+
207+
## Full comparison
208+
209+
| | On-Premises | IaaS | PaaS | CaaS | FaaS | SaaS |
210+
|---|---|---|---|---|---|---|
211+
| **Control** | Maximum | High | Medium | Medium | Low | Minimal |
212+
| **Customer responsibility** | Everything | OS and above | App and data | Container and data | Code only | Data only |
213+
| **Time to market** | Slow | Slow | Fast | Fast | Very fast | Instant |
214+
| **Scaling** | Manual | Manual / scripted | Automatic | Automatic | Automatic to zero | Automatic |
215+
| **Cost model** | CapEx | Per VM-hour | Per usage | Per container-hour | Per invocation | Per user/seat |
216+
| **Portability** | Full | High | Medium | High (image) | Low (vendor API) | None |
217+
218+
---
219+
220+
## Decision framework
221+
222+
``` mermaid
223+
flowchart TD
224+
start([What do you need?]) --> q1{Need full OS control\nor lift-and-shift?}
225+
q1 -->|Yes| iaas[IaaS\nEC2, GCE, Azure VM]
226+
q1 -->|No| q2{Deploying containers?}
227+
q2 -->|Yes| q3{Want to manage\nKubernetes yourself?}
228+
q3 -->|Yes| k8s[CaaS on Kubernetes\nEKS, GKE, AKS]
229+
q3 -->|No| caas[CaaS managed\nCloud Run, ECS Fargate]
230+
q2 -->|No| q4{Event-driven /\nsporadic workload?}
231+
q4 -->|Yes| faas[FaaS\nLambda, Cloud Functions]
232+
q4 -->|No| q5{Building a\ncustom application?}
233+
q5 -->|Yes| paas[PaaS\nHeroku, App Engine]
234+
q5 -->|No| saas[SaaS\nUse an existing product]
235+
```
236+
237+
---
238+
239+
:fontawesome-brands-youtube:{ .youtube } [IaaS vs PaaS vs SaaS](https://www.youtube.com/watch?v=SBQoyZXrpcY){:target="_blank"} — practical overview of the three foundational models.
240+
241+
242+
[^1]: MELL, P.; GRANCE, T. [The NIST Definition of Cloud Computing](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf){:target="_blank"}. NIST Special Publication 800-145, 2011.
243+
[^2]: [AWS Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/){:target="_blank"}
244+
[^3]: [Azure Shared Responsibility](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility){:target="_blank"}
245+
[^4]: [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/){:target="_blank"}

‎mkdocs.yml‎

Lines changed: 18 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -126,15 +126,28 @@ nav:
126126
- 2026.1: versions/2026.1/index.md
127127

128128
- Classes:
129-
- 1. Distributed Systems: classes/distributed_systems/index.md
130-
- 2. Containerization: classes/containerization/index.md
131-
- 3. Microservices: classes/microservices/index.md
129+
- 1. Distributed Systems:
130+
- Overview: classes/distributed_systems/index.md
131+
- CAP Theorem: classes/distributed_systems/cap/index.md
132+
- Consensus & Algorithms: classes/distributed_systems/consensus/index.md
133+
- 2. Containerization:
134+
- Overview: classes/containerization/index.md
135+
- Docker: classes/containerization/docker/index.md
136+
- Docker Compose: classes/containerization/compose/index.md
137+
- 3. Microservices:
138+
- Overview: classes/microservices/index.md
139+
- Domain-Driven Design: classes/microservices/ddd/index.md
140+
- Architecture & Components: classes/microservices/architecture/index.md
132141
- 4. Architectures:
133142
- Overview: classes/architectures/index.md
134143
- Clean Architecture: classes/architectures/clean/index.md
135144
- Hexagonal Architecture: classes/architectures/hexagonal/index.md
136-
# - 5. API: classes/api/index.md
137-
# - 6. DevOps: classes/devops/index.md
145+
- 5. API:
146+
- Overview: classes/api/index.md
147+
- REST API Design: classes/api/rest/index.md
148+
- OpenAPI & Swagger: classes/api/swagger/index.md
149+
- 6. Service Models: classes/service_models/index.md
150+
# - 7. DevOps: classes/devops/index.md
138151
# - 7. Cloud: classes/cloud/index.md
139152
# - 8. Orchestration: classes/orchestration/index.md
140153
# - 9. Reliability: classes/reliability/index.md

0 commit comments

Comments
 (0)