Cloud characteristics and deployment models

Why this matters

Lesson 32 answered "who operates what". This lesson answers the other two questions the exam asks about cloud: who can use this resource, which is the deployment model, and what makes something cloud at all, which is the set of essential characteristics.

Both are asked as recognition questions. A scenario describes an arrangement and you name the model, or describes a behaviour and you name the characteristic. Neither is difficult once the definitions are held as distinctions rather than as a list.

The characteristics are also quietly useful in the field, because they explain billing. A bill that varies with use, and an environment that grows when it is busy, are the same property seen from two directions — and a customer surprised by a bill has usually met elasticity without expecting it.

This is the capstone lesson for the virtualisation and cloud domain, and one of the three with no short bench lab: the characteristics are defined by billing and ownership rather than by anything that can be run in twenty minutes.

The lesson

Public, private, hybrid and community deployment, by who can use the resource

Public cloud. Infrastructure owned and operated by a provider, shared among many unrelated customers, reached over the internet.

• No capital cost, immediate provisioning, effectively unlimited scale.
• Shared underlying hardware, which is a compliance conversation in some sectors.
• The default meaning of "the cloud" in ordinary speech.

Private cloud. Cloud characteristics — self-service, pooling, elasticity — delivered to a single organisation. It may be in the organisation's own data centre or hosted by a provider on dedicated hardware.

• Control and isolation; often the answer to a regulatory requirement.
• Capital cost, and the organisation still runs it, so the operational burden does not disappear.
• The key distinction is exclusivity of use, not location. A private cloud hosted by a provider is still private.

Hybrid cloud. Public and private used together, with some integration between them.

• Sensitive workloads stay private, elastic or bursty ones go public.
• "Cloud bursting" is the canonical example: normal load on private capacity, peaks handled by public.
• The cost is complexity — two environments, two sets of controls, and the connection between them.

Community cloud. Shared by several organisations with a common concern — the same regulator, the same sector, the same security requirements.

• Costs shared across a group, with a tenancy boundary narrower than public.
• Less common, and it appears in exam questions precisely because it is the answer people forget.

The identifying question for any scenario: who else can use this? One organisation is private; anyone is public; a defined group is community; some of each is hybrid.

Elasticity, metered usage, shared resources and on-demand self-service

The essential characteristics, and what each looks like in practice:

• On-demand self-service. A customer provisions resources without human interaction from the provider. If somebody has to raise a ticket and a person has to fulfil it, that is hosting rather than cloud.
• Broad network access. Reachable over standard networks from standard devices.
• Resource pooling. The provider's resources serve many customers, assigned and reassigned dynamically. This is the multi-tenancy property, and it is what makes the economics work and what raises the isolation question.
• Rapid elasticity. Capacity grows and shrinks with demand, quickly, and from the customer's point of view appears unlimited.
• Measured service. Usage is metered and billed by what was consumed.

Two distinctions the exam likes:

• Scalability against elasticity. Scalability is the ability to grow to handle more load. Elasticity is growing and shrinking automatically with demand. A system that can be scaled by an administrator is scalable; one that does it by itself in response to load is elastic.
• Scaling up against scaling out. Up is a bigger machine; out is more machines. Out is the cloud-native approach and the one that elasticity assumes.

High availability belongs here too: multiple instances across multiple physical locations so that a failure of one does not take the service down. It is bought rather than given — a single instance in the cloud is still a single instance.

Cloud file synchronisation, and what 'available offline' actually stores

File synchronisation services are the cloud technology a support technician touches most, and they generate a specific family of calls.

How they work: a local folder is mirrored to a provider, changes propagate to every device signed in, and the provider keeps version history for a period.

The behaviours that produce support calls:

• Files on demand. Files appear in the folder as placeholders and download when opened. The folder looks full and the disk is nearly empty — which is the intended behaviour and looks like a fault when a user loses connectivity and finds their documents inaccessible.
• "Available offline" pins a real copy locally. This is the setting a travelling user needs, and it consumes disk. A user who complains about documents being unavailable on a plane needs this setting explained, not a repair.
• Deletion propagates. A file deleted on one device is deleted everywhere, subject to the provider's recycle period. This is synchronisation working, and it is also why synchronisation is not backup — the same distinction as RAID in lesson 21, arriving for the third time in this course.
• Conflicts occur when two devices edit while offline; the service usually keeps both and names one as a conflicted copy.
• Storage full stops synchronisation, and the failure is quiet. Newly created files simply never leave the machine.

The examinable summary: a synchronisation service keeps copies current across devices; a backup keeps copies old so a past state can be recovered. Most users believe they have the second and have the first.

Measured service and why the bill is a monitoring signal

Metered billing means the invoice is a record of what actually ran, which makes it an operational instrument as well as a cost.

What a bill reveals:

• Resources nobody uses. Instances left running after a project, storage holding data nobody reads, addresses reserved and unattached. These are the ordinary waste of any cloud estate.
• Unexpected growth, which is either success or a fault — a runaway process or a misconfigured job can produce an alarming bill within hours.
• Data transfer charges, which surprise people because moving data out of a provider usually costs money and moving it in usually does not.
• Compromise. A sudden spike in compute is a recognised early indicator of stolen credentials being used for mining.

Which is why budgets and spending alerts are a standard first-day control in any cloud account, and why "we did not know until the invoice arrived" is a monitoring failure rather than a billing one.

Choosing a deployment model from a stated requirement rather than a preference

Scenario questions state a constraint, and the constraint decides:

• "Data may not leave our premises" or "a regulator requires dedicated hardware" → private.
• "We need to launch quickly with no capital budget" → public.
• "Steady internal load with large seasonal peaks" → hybrid, with bursting.
• "Several hospitals want to share a compliant platform" → community.
• "We want to keep the customer database in-house and run the website publicly" → hybrid.
• "We are a small business with no server room and no administrator" → public, and probably software as a service.

Two cautions the exam expects a technician to hold. Hybrid is not free: it costs the complexity of two environments plus the link between them, and it is chosen when a requirement forces it rather than as a default. And private cloud is not simply "our servers": without self-service, pooling and elasticity, an organisation running virtual machines in its own data centre has virtualisation rather than a private cloud, and calling it one is the most common misuse of the term in this objective.