Short answer
The cloud lets you obtain computing capacity and technical services when you need them, without owning and operating all the physical infrastructure underneath them.
That can mean renting computing capacity in the form of a virtual server instead of buying physical server hardware. It can also mean using storage, databases, identity systems, message queues or complete applications as services. The provider operates different parts of the underlying technology depending on what you choose; you configure and operate what remains your responsibility.
The important change is therefore not simply where the server stands. It is that infrastructure and technical capabilities can be requested, changed and removed through services and software. This can shorten provisioning time, make capacity easier to vary and transfer some operational work to a provider. It does not automatically improve an application, reduce its costs or remove the need to manage it.
The cloud is not one remote computer
The word cloud can create the impression that applications and data disappear into one large, indistinct system. In practice, cloud providers operate physical data centers containing servers, storage and networks. Software exposes parts of that infrastructure as services that customers can select and configure.
Some of those services look familiar. A cloud virtual machine still has processors, memory, disks, an operating system and network connections. Other services hide more of the machinery. You might store files without managing a file server, run code without maintaining a continuously running server or use a database without installing and patching the database software yourself.
These are different choices, not different names for the same arrangement. Saying that something “runs in the cloud” tells you very little about how it works, who operates each part or what happens when demand changes or a component fails.
You can request resources instead of procuring hardware
In a conventional environment, adding capacity may involve estimating future demand, obtaining approval, ordering equipment, waiting for delivery, installing it and reserving enough capacity for the busiest expected period.
Cloud resources can usually be created through a management interface or software request. A team can create a server, allocate storage or enable a service without waiting for physical equipment to arrive. It can later change or remove those resources in much the same way. Some resources can also be increased, reduced, started or stopped automatically when predefined conditions are met.
This does not eliminate planning. Cloud accounts have limits, suitable capacity may not always be available in every location, and some services require advance commitments or reservations. But the normal unit of change becomes a configured service rather than a piece of equipment that must be purchased and installed.
That difference can be valuable even when an application itself remains largely unchanged. It can also make waste easier: resources that take minutes to create are easily forgotten and may continue to incur charges until somebody removes them.
Capacity can follow demand—but only if the system is built to do so
Cloud platforms make it possible to increase and decrease computing capacity more quickly than most organizations could add and remove their own hardware. Some services can do this automatically in response to demand.
For example, an application might use more processing capacity during working hours and less overnight. A reporting job might need substantial capacity for twenty minutes and none for the rest of the day. A new service could begin small rather than purchasing equipment for a level of use it may not reach.
This ability is often called elasticity. It is a capability, not a property automatically acquired by moving an existing server. An application may keep important state on one machine, require a long startup process or depend on a database that cannot handle the increased load. In that case, adding more application servers may achieve little.
The platform can make capacity available. The application, data and operating arrangements still need to be able to use it.
You choose how much of the technical stack to operate
Cloud services offer different divisions of responsibility.
With a virtual machine, the provider operates the physical building, hardware, network foundation and virtualization platform. You will normally still manage the operating system, patches, installed software, application, identities, configuration and data.
With a managed application platform or database, the provider may also operate the operating system, runtime or database software. You still decide how the service is configured, who can access it, what data it contains and how your application uses it.
With software as a service, the provider operates almost the complete application. Your responsibilities move toward choosing the service, configuring it, managing users and access, governing the data and deciding how the organization depends on it.
Real environments often combine all three. The relevant question is therefore not “Who manages the cloud?” but “For each service we use, what does the provider operate, what do we operate and what remains shared?”
Infrastructure can be described and repeated in software
Because cloud resources are exposed through software interfaces, an environment can be described in configuration and created repeatedly. Networks, access rules, servers and managed services do not always have to be assembled manually through a succession of screens.
This can make changes reviewable and environments more consistent. It can help create a test environment resembling production, rebuild a failed component or reproduce an arrangement in another geographic location.
Services can be placed in different geographic locations
Cloud providers operate infrastructure in multiple parts of the world. Customers can normally choose a provider-defined geographic region in which supported services and data will operate. Within a region, providers may offer separate locations that can be used to reduce dependence on one data center.
This can make it practical to locate a service nearer to its users, satisfy some data-location requirements or prepare a recovery arrangement without constructing another facility. It does not mean every service automatically exists in several locations. Availability, replication and recovery behavior depend on the service and configuration selected.
Geographic choice also introduces questions about latency, cost, legal requirements, data transfer and operational complexity. More locations are not automatically better; they are options to use when the need justifies them.
For a closer look at failure and recovery, see The cloud can fail. What happens to your service and data?
Usage becomes measurable and billable
Cloud services measure consumption: for example, how long computing capacity runs, how much data is stored, how many requests are made or how much data crosses a network boundary. Prices may be based on this consumption, on reserved capacity, on subscriptions or on a combination of them.
This changes a large hardware purchase into a stream of service charges and makes it possible to associate some costs more closely with actual use. It does not guarantee a lower bill. A system that runs continuously, transfers large quantities of data or uses premium managed services may cost more than expected. Discounts may also require longer commitments that reduce some of the apparent flexibility.
The cloud makes resource use visible in new ways, but somebody must still set budgets, understand the charging model, assign costs and remove what is no longer needed.
What the cloud does not do
Moving to the cloud does not by itself:
- decide which applications should move;
- redesign an application so that it can scale;
- make a single server highly available;
- back up and recover every kind of data;
- configure access securely;
- patch every layer of the system;
- make costs predictable or lower;
- satisfy legal or contractual requirements; or
- ensure that the people operating the service know what to do during an incident.
Cloud providers supply infrastructure, services and operating capabilities. They do not know the consequences of downtime for your customers, which records your organization must retain, who should have access or how much change your team can safely operate.
So what is the practical benefit?
The cloud changes the range and speed of choices available to an organization.
You can obtain technical capacity without first owning the hardware. You can vary some of that capacity as demand changes. You can use managed components instead of operating every layer yourself. You can describe environments in software, create temporary environments and prepare fallback arrangements that would be expensive to keep fully running on owned equipment.
Each choice has consequences for cost, control, skills, dependency and responsibility. Sometimes a conventional environment remains the sensible answer. Sometimes the most useful result is a mixture of existing infrastructure, cloud services and software supplied by others.
The cloud is not the objective. It is a set of ways to obtain and operate technology. Its value depends on whether those ways solve a real constraint or create an option the organization can use.
Questions to ask next
Before comparing providers or individual products, it helps to ask:
- What is difficult, slow, expensive or risky in the current environment?
- Which capacity genuinely varies, and which systems run steadily all year?
- Which operational work could a provider perform more effectively?
- Which applications can use additional capacity, and which would need to be redesigned?
- Which responsibilities and skills would remain with us?
- What must stay under our direct control?
- What would happen to costs under normal use, peak use and unexpected growth?
- How dependent would we become on a particular service or provider?
- How would we recover the service and its data?
- What specific improvement would justify making the change?
Those questions turn “Should we use the cloud?” into a discussion about actual services, constraints and outcomes.