Cloud Models and Compute
Last updated 12 Oct 2026
At a glance
Where a BSS/OSS capability runs (on-premise, private cloud, public cloud or SaaS) is an architecture decision, not the last slide in the deck. This section gives the vocabulary for it: deployment models, the IaaS/PaaS/SaaS responsibility line, and the compute ladder from virtual machines to serverless.
The picture
How it works
Four places a workload can run
An operator can run a workload on-premise on its own hardware, on a private cloud it operates, on a public cloud provider’s infrastructure, or consume it as SaaS from a vendor. Moving along that line trades control for elasticity. Most estates end up with all four at once, because different workloads have different constraints.
Who manages what: IaaS, PaaS, SaaS
The service models describe the same stack of layers, from facility and hardware up to application and data. Only the responsibility line moves. With IaaS the provider runs hardware and virtualisation and you run everything above. With PaaS the provider also runs the runtime and middleware. With SaaS the provider runs the application. Whatever the model, the operator still owns the data, the configuration and the risk.
SaaS moves the data, not the accountability. CRM as SaaS puts customer data in the vendor’s region under the vendor’s operations, while GDPR accountability, retention and deletion remain the operator’s (see Security 17.3). The contract becomes part of the architecture.
Regions, availability zones, landing zones
A region is a geographic location with several physically separate availability zones; a workload spread across zones survives the loss of one data centre. 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.
The compute ladder
Each rung hides one more layer from the team running the workload. The point is fit, not progress: a legacy vendor package on a virtual machine is a correct answer.
| 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 |
What decides the placement
- Data: residency, sovereignty and the sensitivity of what the workload holds.
- Latency and reach: how close it must be to inventory, activation and the network management plane.
- Regulation: lawful intercept, retention and sector rules that bind specific systems.
- Vendor support: whether the vendor certifies the package on the target platform.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Workload placement decision | Architecture decision record (enterprise architecture) | — | Programme governance | Made per workload, not per programme |
| Landing zone and account structure | Infrastructure-as-code repository (Git) | Cloud provider console | Cloud provider control plane | Console changes outside the repository are drift |
| Running cloud resources (actual) | Cloud provider control plane | — | CMDB / ITSM | The provider holds what actually exists; the CMDB copies it |
| SaaS application and its hosting | SaaS vendor | — | Operator contract and vendor register | Responsibility moves to the vendor; accountability does not |
| Customer data held in SaaS | The SaaS application, under the operator’s data-controller accountability | — | Data protection register | Residency, retention and deletion stay the operator’s obligation |
| On-premise hardware and facilities | Operator CMDB / asset register | — | Finance fixed-asset register | — |
In practice
Most operators are hybrid, but rarely by design. Channels, catalog, COM and analytics often reach public cloud or SaaS first because they are commercial and portable. SOM and inventory more often stay on private infrastructure, close to the network, and anything that touches the management plane or lawful intercept tends to stay on-premise.
The common failure is a cloud slogan applied at programme level: every new system goes to public cloud regardless of its data or latency, and the exceptions are discovered one integration at a time. The estate ends up hybrid by accident, carrying the cost of both models and the resilience of neither.
Older vendor packages are often certified only on specific virtual machine images. Containerising them without the vendor’s support usually voids that support, so "lift and shift to VMs" is frequently the honest first step rather than a lack of ambition.
The trade-off
What it solves
Deciding placement per workload, by its data, latency and regulation, puts each capability where its constraints are met, and makes the hybrid estate a deliberate design rather than an accident.
What it does not solve
- It does not transfer accountability: data protection, retention and deletion remain the operator’s under any service model.
- It does not make legacy packages cloud-native; the vendor’s certification decides that.
What it adds
- Several hosting models to operate at once, each with its own identity, network and monitoring.
- Contracts and vendor regions become architecture inputs that must be tracked like any other dependency.
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 carries 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.
Takeaways
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.
- Autoscaling works for stateless components; the database still needs a capacity plan.
Check yourself
A programme proposes moving CRM to SaaS and says data protection is now the vendor’s problem. What is wrong with that?Show answerHide
SaaS moves where the data is held and who operates it, not the accountability. Residency, retention and deletion remain the operator’s, so the contract and the vendor’s region become part of the architecture.
Why might the order workflow be a poor fit for serverless even if the API in front of it is a good one?Show answerHide
Serverless suits short, bursty, stateless functions. An order workflow is long-running and stateful, so it belongs on a platform that keeps state and runs continuously.