Lesson 3: Cloud Models, Services, and Characteristics

"The cloud" sounds like a place.

It is more useful to think of it as a responsibility model built on somebody else's infrastructure.

Somebody still owns the hardware. Somebody still patches operating systems. Somebody still manages identities. Somebody still pays for storage and network transfer. Somebody still decides what happens when a service fails.

Cloud computing changes which somebody owns each layer.

Separate deployment model from service model

These are different questions.

Deployment model: who is the cloud environment intended to serve, and how is the infrastructure shared?

Service model: which technical layers does the provider operate for the customer?

Do not mix them.

A public cloud can provide IaaS, PaaS, and SaaS. A private cloud can also expose different service layers.

Deployment models describe how the environment is shared

Public cloud

A provider operates infrastructure offered to many customers through cloud services.

The customer does not own the provider's physical data-center hardware.

They still own responsibilities inside the service they configure.

Private cloud

Cloud infrastructure is dedicated to one organization, whether hosted internally or by another provider.

Private does not automatically mean secure.

It describes the deployment relationship, not the quality of every control.

Hybrid cloud

An organization combines private and public cloud resources as part of one operating design.

A workload may stay in private infrastructure while another service uses public-provider capacity.

The difficult part becomes the boundary between them:

• identity;
• networking;
• data movement;
• monitoring;
• policy;
• cost.

Community cloud

Infrastructure is shared by organizations with common mission, policy, regulatory, or operational requirements.

The shared requirement is what makes the model useful.

Responsibility model

Responsibility moves; it does not disappear

As the provider manages more of the stack, the customer still owns data, access choices, and appropriate configuration.

1. 01
   On-prem

   Customer operates facility, hardware, virtualization, OS, runtime, application, and data.

2. 02
   IaaS

   Provider operates facility and hardware; customer usually owns guest OS upward.

3. 03
   PaaS

   Provider also operates OS and runtime; customer owns application, data, and access design.

4. 04
   SaaS

   Provider operates the application stack; customer still governs identities, data use, configuration, and recovery expectations.

Service models move the responsibility line

Use a simplified stack:

physical hardware
virtualization
operating system
runtime / platform
application
data
identity / configuration

Different service models move the provider/customer boundary.

IaaS: infrastructure is provided, but the guest is still your problem

Infrastructure as a Service commonly provides virtual compute, storage, networking, and infrastructure controls.

The customer usually retains substantial responsibility for:

• guest operating system;
• patching inside the guest scope;
• application installation;
• application configuration;
• identities and permissions;
• data.

If your IaaS VM is reachable but the application configuration is wrong, the cloud provider may be delivering its part perfectly.

PaaS: the provider owns more of the runtime

Platform as a Service provides a managed application platform or runtime.

The customer focuses more on:

• application code;
• data;
• application configuration;
• identities and access;
• service-specific settings.

The provider manages more of the underlying OS and runtime infrastructure.

That reduces administration.

It does not remove application responsibility.

SaaS: the provider delivers the finished application

Software as a Service gives users an application directly.

Customers still make important decisions about:

• user accounts;
• permissions;
• data sharing;
• retention;
• configuration;
• backup or export options where supported;
• acceptable use.

"The provider runs it" does not mean "we have no responsibilities."

Shared and dedicated resources describe another boundary

Cloud infrastructure may use pooled resources across customers, or a service may provide dedicated capacity for a customer or workload.

Shared does not automatically mean unsafe.

Dedicated does not automatically mean secure.

The useful questions are:

• what is physically or logically shared;
• what isolation controls separate tenants;
• what performance guarantees exist;
• what the workload actually requires.

Multitenancy means multiple tenants share a platform with logical separation

A multitenant platform serves multiple customers or organizations while keeping their identities, configuration, and data separated according to the service design.

Do not translate "shared platform" into "everyone can see everyone else's files."

If isolation fails, that is a security incident. It is not the normal definition of multitenancy.

Metered utilization turns architecture into an operational cost

Cloud services can meter usage such as:

• compute time;
• storage capacity;
• requests;
• database operations;
• network transfer.

Network transfer deserves special attention because providers may treat ingress and egress differently.

• Ingress is data entering the service or provider boundary.
• Egress is data leaving it.

A technically correct application can still be badly designed if it unexpectedly generates large metered egress.

Example:

application behavior: functioning as configured
monthly outbound transfer: 2 TB above expected baseline
service availability: normal
billing impact: severe

Nothing is "down."

The architecture has a cost problem.

Elasticity means capacity can change with demand

Elasticity allows cloud resources to scale up or down as demand changes.

That does not mean:

• infinite capacity;
• instant scaling under every condition;
• zero configuration;
• zero cost.

Scaling depends on limits, triggers, quotas, architecture, and provider behavior.

If a service fails during a traffic spike, the question is not simply "does cloud scale?"

Ask whether this design had enough allowed capacity and a working scaling path.

Availability is a design property, not a magic cloud guarantee

Cloud systems can use:

• redundant infrastructure;
• multiple availability zones or regions;
• load balancing;
• replicated services;
• automated failover.

Those patterns can improve availability.

They can also cost more and introduce new dependencies.

Nothing about the word cloud guarantees the service will never fail.

Provider outages happen. Customer configuration failures happen too.

Responsibility mapping tells you who can actually correct the failed layer.

File synchronization keeps copies aligned; it does not automatically preserve history

Cloud file synchronization can keep data aligned across endpoints or locations.

Now delete a synchronized file.

If the deletion propagates everywhere, synchronization worked perfectly.

Recovery still failed if no version history or independent backup exists.

Same principle as RAID and VM snapshots:

synchronization, redundancy, snapshots, and backup solve different failure problems.

Worked case: SaaS application is unavailable

Evidence:

local endpoint: healthy
local network: healthy
DNS: working
provider status: reports SaaS outage

What is the technician's job?

Not to reset every laptop.

Verify scope, document impact, communicate, use approved contingency steps, and follow the provider-side recovery status.

The failure exists outside the customer's direct repair boundary.

Worked case: IaaS VM is reachable, application is broken

Evidence:

provider VM state: running
network endpoint: reachable
guest OS: running
web application configuration: invalid

The provider is delivering the infrastructure layer.

The customer-owned application layer is failing.

"Cloud problem" is too broad.

Worked case: synchronized folder is current everywhere, but the wrong file version is everywhere

Evidence:

sync status: healthy
file version: unwanted change propagated to all clients
independent version recovery: not provided in scenario

Do not disable networking and call synchronization broken.

The sync mechanism did exactly what it was supposed to do.

The missing requirement is recovery from an unwanted synchronized state.

Build the responsibility map

For each supplied scenario, record:

deployment model
service model
shared or dedicated resource assumption
customer-owned layers
provider-owned layers
availability concern
elasticity concern
metering / ingress / egress concern
multitenancy concern
sync / backup concern

Use only the rows that matter to the actual scenario.

Before you move on

When someone says "it is in the cloud," ask:

1. What deployment model are we using?
2. What service model are we using?
3. Who owns the failed layer?

Those questions remove a surprising amount of confusion.

Next we use them to design workloads before choosing any specific platform.