Cloud Models and Compute

Public, private, hybrid and multi-cloud; IaaS, PaaS and SaaS; and the ladder from physical servers to Kubernetes and serverless — as architecture, not administration.

Modern BSS/OSS platforms depend on infrastructure that can support scale, resilience, automation and continuous change. The infrastructure decision is an architecture decision; it is not the last slide in the deck.

Four places a workload can run, from most control to most elasticity, and what typically lands at each. Most operators are hybrid — by necessity rather than design.

This module is about architecture, not administration. It will not teach you to run a Kubernetes cluster. It will give you the vocabulary to decide where a BSS/OSS capability should run, why the answer differs from the top of the chain to the bottom, and what each answer costs.

Who manages what: IaaS, PaaS, SaaS

The same nine layers in every column; only the responsibility line moves. Whatever the model, you still own the data, the configuration and the risk.

Regions, availability zones, landing zones

A region is a geographic location with several physically separate availability zones; a workload spread across zones survives a data-centre failure. A landing zone is the pre-built account structure, network, identity and guardrails a workload is deployed into — the cloud equivalent of a wired, secured rack.

SaaS moves the data, not the accountability

CRM as SaaS puts customer data in the vendor’s region under the vendor’s operations. GDPR accountability, retention and deletion remain the operator’s — see Security 15.3. The contract is now part of the architecture.

Compute: the ladder of abstractions

Each rung hides one more layer from the team running the workload. Each fits something in the estate; the point is fit, not progress.

Term	In one line	Why an architect cares
Container	An application and its dependencies packaged as one image	The same image runs in test and production; vendor packages that are not containerised cannot
Kubernetes	The scheduler that runs containers across many machines and keeps them running	It is where cloud-native BSS vendors ship; it is also a platform your team must operate
Serverless	Functions run on demand; you pay per invocation	Cheap for bursty glue; wrong for a long-running order workflow
Autoscaling	Capacity added and removed automatically on load	Only works for stateless components; the database does not autoscale

Architecture decision

Should this BSS/OSS workload run on public cloud, private cloud, or stay on-premise?

Public cloud
Choose when it is stateless or its data has no residency constraint, load varies, and the vendor supports it — channels, catalog, COM, analytics.
Private cloud
Choose when data sovereignty or regulation binds it, it needs low latency to inventory and activation, or existing investment is sunk — SOM, inventory.
On-premise
Choose when it reaches the network management plane, has hardware dependencies, or is a lawful-intercept or retention obligation.

Breaks if the decision is made per programme rather than per workload — the estate ends up hybrid by accident, with the cost of both and the resilience of neither.

Key Takeaways

Where a workload runs is decided by its data, its latency and its regulation — not by the programme’s cloud slogan.
IaaS, PaaS and SaaS move the responsibility line; they do not move the accountability.
The compute ladder is about fit. A legacy vendor package on a VM is a correct answer.