Catalog
concept#Cloud#Architecture#Governance#Platform

Cloud Service Model

Model classifying cloud services (IaaS, PaaS, SaaS) and their responsibility, operational and integration boundaries.

The cloud service model categorizes delivery types such as IaaS, PaaS, and SaaS and defines responsibility boundaries.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Identity providers / SSO (e.g., SAML, OIDC)API gateway and integration busMonitoring and observability toolchain

Principles & goals

Define clear responsibility boundaries between provider and operatorTreat cost, control and operations as connected decision factorsInclude security and compliance requirements early in model selection
Discovery
Enterprise, Domain

Use cases & scenarios

Compromises

  • Vendor lock-in from unsystematic use of platform APIs
  • Missing SLA boundaries lead to operational risk
  • Unclear security responsibility between provider and consumer
  • Document responsibilities clearly in a RACI model.
  • Establish FinOps metrics to continuously monitor costs.
  • Use standardized integration and auth patterns.

I/O & resources

  • Technical requirements (latency, throughput, SLA)
  • Compliance and security requirements
  • Cost and budget constraints
  • Selected service model with responsibility matrix
  • Architectural principles and migration plan
  • SLA and operational agreements

Description

The cloud service model categorizes delivery types such as IaaS, PaaS, and SaaS and defines responsibility boundaries. It supports decision makers in assessing abstraction levels, control trade-offs, and operational cost allocation. Choice of model affects architecture, compliance posture, billing, and integration with on-premises systems.

✔

  • Faster provisioning through abstracted services
  • Cost transparency and flexible scaling depending on model
  • Teams can focus on core functions rather than infrastructure operations

✖

  • Reduced control over underlying layers at higher abstraction levels
  • Potential dependency on vendor features and APIs
  • Not all legacy systems are suitable for direct SaaS or PaaS migration

  • Total Cost of Ownership (TCO)

    Total costs over lifecycle including operations, licenses and migration.

  • Mean Time to Recovery (MTTR)

    Average time to recover after an outage under the chosen model.

  • Percentage of reused components

    Measure of portability and modularity across providers.

E-commerce uses SaaS for CRM

CRM functions integrated as SaaS to reduce time-to-market; integration realized via API gateways.

Analytics platform on PaaS

Platform services (database, batch runtime) used as PaaS to increase developer focus.

Startup runs infrastructure in IaaS

Jumpstart via IaaS VMs and network infra; later staged migration to PaaS components planned.

1

Capture requirements and define stakeholder criteria.

2

Evaluate service models (IaaS/PaaS/SaaS) against criteria.

3

Run proof-of-concept for the preferred model.

4

Create migration and operations plan, negotiate SLAs.

⚠️ Technical debt & bottlenecks

  • Direct dependency on proprietary platform APIs without abstraction
  • Incomplete documentation of responsibility and operations tasks
  • Legacy components preventing full use of PaaS
Network latency and bandwidthData locality and gravityComplexity of vendor integration
  • Storing critical compliance data in SaaS without contractual guarantees
  • Using PaaS as a cheap IaaS alternative and ignoring platform features
  • Operating IaaS infrastructure manually without automation
  • Underestimating integration effort between cloud and on-prem
  • Lack of observability in mixed service models
  • Overlooked recurring costs from vendor add-on features
Cloud architecture and infrastructure designSecurity and compliance expertiseCost modeling and FinOps basics
Security and compliance requirementsExpected scaling and load profileRequired degree of infrastructure control
  • • Regulatory constraints for data residency
  • • Existing legacy systems and integrations
  • • Budget constraints for operations and migration