Last updated on
Before an organisation selects specific cloud services, two fundamental decisions must be made: which deployment model meets requirements for sovereignty, compliance, and operations? And at which service level should cloud capacity primarily be consumed? These decisions are not technical details — they define the structural framework for all downstream architecture, governance, and procurement decisions.
Leaving these decisions to the operational team risks a fragmented IT landscape with inconsistent security levels, incompatible platforms, and difficult-to-manage costs. The decision on deployment and service models is therefore a leadership responsibility.
The organisation uses differentiated deployment models to equally meet requirements for security, compliance, and flexibility. Each model has a clear application profile.
Public Cloud
Public cloud is the primary deployment model for applications without elevated sovereignty requirements. STACKIT as a European provider offers scalable, cost-efficient infrastructure with extensive managed services. Public cloud enables maximum agility with standardised security controls.
Suitable for: development and test environments, SaaS workloads, new digital products, applications with dynamic load profiles.
Hybrid Cloud
The hybrid cloud model combines cloud infrastructure with existing on-premises resources. It is the right approach for organisations that must account for regulatory requirements, existing investments, or data residency obligations, while simultaneously building cloud-native capabilities.
Suitable for: regulated workloads with specific data residency requirements, legacy systems in migration phases, critical business processes with on-premises dependencies.
The strategic rule is: public cloud is the standard. Hybrid is used specifically where demonstrable requirements force a deviation — not as a default escape for concerns that can be resolved through good governance.
Deployment models don’t only define where data resides — they determine who bears responsibility. In a public cloud model, the provider assumes the physical infrastructure, while the organisation remains responsible for configuration, data protection, and application security. In the hybrid model, the responsibility zone expands: the organisation operates parts of the infrastructure itself and must maintain corresponding capacity and processes.
This differentiation has direct implications for workforce planning, security architecture, and compliance evidence. An organisation that chooses a hybrid model without understanding the operational consequences doesn’t create security — it creates complexity without coverage.
Cloud services are consumed at different abstraction levels. Each level defines where the responsibility boundary between provider and organisation lies — and therefore what capabilities and governance controls are required internally.
Infrastructure as a Service (IaaS)
IaaS provides fundamental compute capacity, storage, and networking. The organisation provisions and operates virtual machines, network components, and storage resources itself. Maximum configuration latitude comes with maximum operational responsibility: OS patching, hardening, availability, and monitoring are entirely the organisation’s responsibility.
Use: infrastructure workloads with specific configuration requirements, lift-and-shift migrations, workloads without suitable managed service equivalents.
Platform as a Service (PaaS)
PaaS abstracts the infrastructure layer. Databases, container platforms, message queues, and similar services are provided as managed platforms. The organisation focuses on application logic; operating systems, patching, and platform availability are handled by the provider. PaaS significantly reduces operational effort and is the preferred model for new application development.
Use: new applications, microservice architectures, database operations, application platforms.
Software as a Service (SaaS)
SaaS delivers complete applications as a service. The organisation configures and uses the application — but operates no infrastructure or platform. SaaS governance requires specific measures around data residency, integration security, and provider dependency.
Use: office software, CRM/ERP systems, collaboration platforms, specialised business software.
The strategic guideline is: higher abstraction levels are preferred when they meet business and technical requirements. That means: SaaS before PaaS before IaaS — not for convenience, but because higher abstraction reduces operational effort, promotes standardisation, and redirects the organisation from infrastructure maintenance to value creation.
Deviations from this guideline must be justified: what requirement forces a lower abstraction level? This obligation to justify is not bureaucratic obstruction — it is the mechanism that prevents habit or lack of knowledge about available managed services from undermining the cloud strategy.
Defining the deployment and service models lies with the Cloud Centre of Excellence (CCoE) in close coordination with IT architecture and executive leadership. Deviations from the strategically defined models require an exception decision with documented justification.
This decision structure protects the coherence of the IT landscape and prevents the uncontrolled emergence of shadow IT or incompatible cloud infrastructure in individual business units.