Executive Summary
In the previous lessons, you learned what cloud computing is and how it differs from traditional data centers. You learned that cloud is not simply a different location for servers—it is a different operating model built around automation, APIs, elasticity, managed services, and consumption-based pricing.
The next step is understanding how cloud services are delivered and how workloads are deployed.
Every cloud architecture begins with two decisions:
- What level of responsibility should the organization manage?
- Where should the workload run?
These decisions lead to cloud service models such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Containers as a Service (CaaS), Function as a Service (FaaS), and Software as a Service (SaaS). They also lead to deployment models such as Public Cloud, Private Cloud, Hybrid Cloud, Multi-Cloud, and Sovereign Cloud.
Understanding these models helps engineers and architects choose the right balance between control, operational effort, agility, governance, compliance, and business outcomes.
Why Service and Deployment Models Matter
Imagine two organizations beginning their cloud journey.
The first is a startup launching a new SaaS platform. The engineering team is small, budgets are limited, and speed is critical. Their goal is to release features quickly, automate as much as possible, and avoid managing infrastructure whenever practical.
The second organization is a global financial institution. It must satisfy regulatory requirements, protect sensitive customer data, integrate with legacy systems, and operate across multiple countries and business units. Their priorities include governance, compliance, resilience, and operational consistency.
Both organizations use cloud. Both may even use the same cloud provider. Yet their architectures look completely different.
Why?
Because cloud architecture is rarely defined by the provider itself. It is primarily defined by the service models and deployment models chosen to support business requirements.
Many engineers begin by asking:
- Should I use Kubernetes?
- Should I deploy virtual machines?
- Should I use serverless functions?
- Should I choose AWS or Azure?
Experienced architects ask different questions first:
- How much responsibility should the organization own?
- How much operational complexity can the team support?
- What compliance requirements exist?
- How portable must the workload be?
- Where should the workload run?
- How will operations scale over time?
The answers to those questions typically determine the service model and deployment model long before specific cloud services are selected.
As you progress through this series, you will discover that many architecture decisions are really trade-offs between control, simplicity, portability, governance, cost, and operational maturity.
Learning Objectives
After completing this lesson, you should be able to:
- Explain cloud service models and deployment models.
- Understand how responsibilities are shared between providers and customers.
- Compare IaaS, PaaS, CaaS, FaaS, and SaaS.
- Compare Public, Private, Hybrid, Multi-Cloud, and Sovereign Cloud architectures.
- Evaluate service models from a multi-cloud perspective.
- Understand how AI and Agentic AI are changing cloud consumption.
- Apply enterprise architecture best practices when selecting cloud models.
The Two Decisions Every Cloud Architect Makes
Before discussing individual services, it helps to understand the two decisions that drive every cloud architecture.
Every architecture, whether it runs on AWS, Azure, Google Cloud, OCI, IBM Cloud, or across multiple providers, ultimately answers two questions:
- What am I consuming?
- Where is it running?
The first question determines the service model.
The second determines the deployment model.
Every cloud architecture, regardless of provider, starts with these two fundamental decisions. The figure below provides the mental model that will be used throughout the rest of this lesson.
Every service and architecture pattern discussed throughout this series fits somewhere within this framework.
Once you understand these two decisions, cloud services become much easier to evaluate because they can be viewed through a consistent operating model.
Cloud Service Models Explained
Cloud service models define how operational responsibilities are shared between the cloud provider and the customer.
As services become more managed, operational effort decreases and the provider assumes greater responsibility for running the platform.
This shift influences:
- Staffing requirements
- Security responsibilities
- Governance models
- Operational complexity
- Cost management
- Platform engineering decisions
The easiest way to understand cloud service models is to see how responsibility shifts between your team and the cloud provider.
Rather than memorizing definitions, focus on the responsibility boundary.
With IaaS, you still manage operating systems, patching, application runtimes, and many security controls.
With PaaS, much of that responsibility shifts to the provider, allowing developers to focus primarily on applications.
With SaaS, the provider manages almost everything except user access, governance, and business processes.
The progression is not about eliminating responsibility. It is about deciding which responsibilities create business value and which responsibilities can be delegated to the provider.
Understanding the Responsibility Shift
Many cloud migration challenges occur because organizations misunderstand who is responsible for what.
Moving to cloud does not eliminate responsibility. It redistributes responsibility.
As cloud services become more managed, operational responsibility gradually moves from your organization to the cloud provider. The figure below shows how this responsibility changes across service models.
Infrastructure teams often begin with IaaS because it closely resembles traditional data center operations.
As cloud adoption matures, organizations typically increase their use of managed databases, PaaS platforms, SaaS applications, and serverless services. This reduces operational overhead and allows engineering teams to focus on delivering business capabilities rather than maintaining infrastructure.
However, more abstraction does not automatically mean better architecture.
Highly regulated environments may require greater control.
Performance-sensitive workloads may require custom operating system configurations.
Legacy systems may only be supported on virtual machines.
The goal is not to move every workload toward SaaS. The goal is to choose the right level of abstraction for each workload.
Cloud Deployment Models Explained
Service models determine what you consume. Deployment models determine where those services operate.
The deployment model affects:
- Security boundaries
- Compliance requirements
- Governance controls
- Network connectivity
- Data residency
- Operational complexity
The right deployment model is driven by business requirements rather than technology preferences.
The following comparison summarizes the five deployment models commonly used across modern cloud environments.
| Model | Description | Typical Use Case |
|---|
| Public Cloud | Shared provider infrastructure | Most enterprise workloads |
| Private Cloud | Dedicated infrastructure | Strict control requirements |
| Hybrid Cloud | On-premises + Cloud | Enterprise modernization |
| Multi-Cloud | Multiple cloud providers | Large enterprises |
| Sovereign Cloud | Jurisdiction-controlled cloud | Government and regulated industries |
Public Cloud
Public Cloud is the most common deployment model today.
Infrastructure is owned and operated by cloud providers such as AWS, Azure, Google Cloud, OCI, and IBM Cloud.
Organizations consume resources on demand without managing physical infrastructure.
Typical advantages include:
- Elastic scalability
- Global reach
- Rapid deployment
- Consumption-based pricing
Public Cloud is the default deployment model for most modern applications because it allows organizations to focus on business capabilities rather than infrastructure management.
Private Cloud
Private Cloud provides infrastructure dedicated to a single organization.
Private Cloud environments may run:
- In corporate data centers
- In colocation facilities
- On dedicated cloud infrastructure
Private Cloud is commonly used when organizations require:
- Greater control
- Specific compliance controls
- Specialized hardware
- Legacy application support
Although private cloud offers increased control, it usually requires significantly more operational effort than public cloud environments.
Hybrid Cloud
Many enterprises cannot move everything to cloud immediately.
Legacy systems, regulatory requirements, and operational constraints often require workloads to remain on-premises while new applications are deployed in cloud platforms.
Hybrid Cloud combines both environments.
The figure below illustrates a typical hybrid architecture.
Hybrid cloud remains one of the most common deployment models in large enterprises because it allows gradual modernization rather than large-scale migrations.
Multi-Cloud
Multi-cloud refers to the intentional use of multiple cloud providers.
Examples include:
- AWS + Azure
- Azure + Google Cloud
- AWS + OCI
- AWS + Azure + Google Cloud
Many organizations adopt multi-cloud for reasons such as:
- Regulatory requirements
- Geographic expansion
- Acquisitions
- Resilience strategies
- Access to provider-specific capabilities
A common misconception is that multi-cloud means deploying every workload everywhere.
In reality, most enterprises place workloads where they make the most sense.
For example:
- Microsoft-heavy environments may prefer Azure.
- Analytics workloads may leverage Google Cloud.
- Oracle database platforms may run on OCI.
- Cloud-native applications may run on AWS.
Multi-cloud is not about duplication. It is about optimization.
Sovereign Cloud
Sovereign Cloud focuses on data residency, jurisdictional control, and regulatory compliance.
Organizations operating in sectors such as:
- Government
- Defense
- Healthcare
- Financial Services
may require strict controls over where data is stored, processed, and managed.
Sovereign Cloud environments help satisfy these requirements while still enabling cloud adoption.
As regulations continue to evolve globally, sovereign cloud strategies are becoming increasingly important.
How Enterprises Evolve Toward Multi-Cloud
Most organizations do not begin their cloud journey with a multi-cloud strategy.
Their environments evolve over time as business, regulatory, and technology requirements change.
The figure below illustrates a common cloud evolution path.
This evolution is often driven by:
- Business growth
- Mergers and acquisitions
- Regulatory requirements
- Geographic expansion
- Technology modernization
Understanding this progression helps explain why many large enterprises eventually operate across multiple cloud providers
Multi-Cloud Perspective
Multi-cloud introduces new challenges that do not exist in single-cloud environments.
The same service model can have very different implications when multiple providers are involved.
The comparison below highlights common considerations.
| Service Model | Multi-Cloud Impact |
| IaaS | Easier portability, greater operational effort |
| PaaS | Faster development, increased provider dependency |
| CaaS | Common abstraction layer across providers |
| FaaS | Strongest lock-in risk |
| SaaS | Governance and integration become critical |
As organizations adopt additional cloud providers, architecture decisions become less about services and more about consistency.
Key challenges include:
Identity
Each provider has its own IAM model.
Architects must determine how users, service accounts, and permissions operate consistently across environments.
Networking
Each cloud platform implements networking differently.
Cross-cloud connectivity introduces:
- Routing complexity
- Security considerations
- Latency concerns
- Traffic management requirements
Observability
Operations teams require centralized visibility.
Without a unified observability strategy, troubleshooting becomes significantly more difficult across multiple providers.
Governance
Policies, security controls, tagging standards, compliance requirements, and cost management processes must operate consistently across clouds.
This is one reason platform engineering has become increasingly important in modern enterprises.
Service Models: Engineer vs Architect Perspective
Engineers and architects often evaluate the same service model differently. Engineers focus on implementation and operations, while architects focus on scalability, governance, risk, and long-term sustainability.
| Service Model | Engineer Perspective | Architect Perspective |
|---|---|---|
| IaaS | Maximum flexibility and control | Greater operational responsibility and governance overhead |
| PaaS | Faster development and deployment | Reduced operations with moderate provider dependency |
| CaaS | Consistent container platform | Common abstraction layer for multi-cloud strategies |
| FaaS | Rapid feature delivery | Fast innovation but higher lock-in considerations |
| SaaS | Minimal infrastructure management | Focus shifts to governance, integration, and data ownership |
Deployment Models: Engineer vs Architect Perspective
Deployment models affect how workloads are deployed, managed, secured, and governed across the enterprise.
| Deployment Model | Engineer Perspective | Architect Perspective |
|---|---|---|
| Public Cloud | Fast provisioning and scalability | Business agility and global reach |
| Private Cloud | Greater infrastructure control | Compliance and specialized requirements |
| Hybrid Cloud | Integration flexibility | Gradual modernization strategy |
| Multi-Cloud | More operational complexity | Risk diversification and workload optimization |
| Sovereign Cloud | Additional deployment constraints | Regulatory and jurisdictional compliance |
Multi-Cloud Operations Perspective
As organizations adopt multiple cloud providers, operational consistency becomes more important than individual services.
How Agentic AI is Changing Cloud Consumption
Artificial Intelligence is beginning to influence how cloud platforms are designed, operated, secured, and optimized.
Rather than replacing engineers and architects, AI is helping teams make decisions faster and automate repetitive operational work.
The following examples illustrate where AI and Agentic AI are already creating value.
| AI Capability | Typical Benefit |
|---|---|
| Generate Infrastructure as Code | Faster provisioning |
| Explain architecture patterns | Faster learning and design reviews |
| Analyze cloud costs | Better optimization opportunities |
| Review security configurations | Improved governance validation |
| Execute operational workflows | Faster incident response and remediation |
As AI capabilities mature, architects will spend less time creating resources manually and more time validating designs, policies, governance controls, and business outcomes.
Enterprise Best Practices
Choosing the right service model or deployment model should start with business requirements rather than technology preferences.
The following framework provides a simple way to think about common decisions.
The figure below shows a simplified service model selection guide.
The best solution is rarely the most advanced technology. The best solution is the one that balances business needs, operational maturity, governance requirements, and long-term sustainability.
Common Mistakes and Misconceptions
Many cloud adoption challenges can be traced back to a few common misunderstandings.
| Misconception | Reality |
| Cloud automatically reduces costs | Poor governance can increase costs |
| Multi-cloud means using every provider equally | Most workloads are intentionally placed |
| Security is entirely the provider’s responsibility | Security remains a shared responsibility |
| Kubernetes eliminates lock-in | It reduces some dependencies, not all |
| AI can replace architects | AI assists decisions but does not own accountability |
Understanding these misconceptions early can prevent many costly architecture mistakes.
Architect Notes
Practical Multi-Cloud Checklist Before Deployment
Before deploying workloads, validate both the service model and deployment model decisions.
Service Model
✓ Understand responsibility boundaries
✓ Confirm operational ownership
✓ Validate support requirements
✓ Review portability expectations
Deployment Model
✓ Validate compliance requirements
✓ Review networking architecture
✓ Confirm identity strategy
✓ Establish governance controls
Operations
✓ Implement centralized monitoring
✓ Define cost ownership
✓ Establish security baselines
✓ Automate repeatable processes
AI Readiness
✓ Validate data quality
✓ Establish access controls
✓ Review AI governance requirements
✓ Define approval workflows for automated actions
Key Takeaways
- Service models define responsibility.
- Deployment models define workload placement.
- More managed services reduce operational effort but may increase provider dependency.
- Hybrid Cloud and Multi-Cloud solve different business problems.
- Kubernetes has become a common abstraction layer across cloud providers.
- AI is accelerating cloud operations but does not replace architecture fundamentals.
- Successful cloud adoption starts with choosing the right operating model before selecting services.
What’s Next
Lesson: The Five Major Cloud Providers Compared
Now that you understand service models and deployment models, the next step is understanding how the major cloud providers implement them.
In the next lesson, you will compare:
- AWS
- Microsoft Azure
- Google Cloud
- Oracle Cloud Infrastructure (OCI)
- IBM Cloud
You will learn where each provider excels, how their services compare, and how enterprises evaluate providers when designing modern multi-cloud platforms.
This comparison will provide the foundation for the rest of the Multi-Cloud Learning Series.
