What is cloud computing?

Four or five capabilities do most of the work:

• Virtualisation - hypervisors and containers dividing machines into independently usable parts.
• Self-service and APIs - capacity requested by software rather than by ticket.
• Pooling - many users drawing on shared resources, which is what makes elasticity possible.
• Metering - consumption measured, so it can be billed, forecast and attributed.
• Physical infrastructure - datacenters, power, cooling and networks, on which everything above depends.

The last item is the one the vocabulary hides. Every abstraction in the list terminates on machines in a building, and the quality of a cloud service still depends on that equipment and on the people who maintain it. Claims about a cloud should therefore be traceable to an operator with racks, not to a diagram.

Independence deserves the same scrutiny. Moving away from a provider means re-implementing whatever depended on its particular APIs, its identity model or its managed services, and that cost is paid once per integration. Portability is far easier to arrange at the start of a project than to recover at the end of one, which is why the details of export and interface support belong in an evaluation rather than in a later migration plan.

Resources from a cloud are usually described at one of three levels, each moving a different share of the work to the provider: infrastructure, where you receive machines; platforms, where you receive a deployment target; and services such as storage consumed directly. Which layer a workload belongs on is decided by how much of the machinery the team wants to own.

The same capacity can also be deployed in different patterns - public, private or hybrid - and run on open source software by the operator. Those patterns are covered in the hub's other definitions; this page is about the category itself, not about any one arrangement of it.

The choice matters at the point of purchase because it fixes what you remain accountable for afterwards. A team renting machines inherits patching, configuration and capacity planning; a team on a platform inherits deployment policy and quota; a team using software inherits almost none of it and gives up control of the release cycle in exchange. None of those answers is a verdict on the others - each is a decision about how much of the stack someone is willing to run.

Elasticity is the headline and rarely the deciding factor. Transfer policies and storage rates often move the total cost more than the hourly compute rate does; data gravity means the second workload is harder to move than the first was; and proprietary managed services deepen an integration with every team that adopts them.

Responsibility also follows the layer you rent. Everything above the rented boundary stays with the tenant - configuration, access control, data handling - so a cloud does not remove operations, it changes what operations are about. Teams that plan for that distinction get more out of the model than teams expecting the machinery to disappear.

Cloud computing does not have to be bought from a single vendor with a single account. On VirtEngine, capacity from independent operators is published in one place where it can be compared on stated attributes: what hardware is offered, where it sits, what it costs, and what the provider is able to serve.

Orders are backed by escrow, matches become leases binding tenant, provider and funds, and the resulting usage is reported as signed records that settle after a dispute window under governance-set parameters rather than a private platform margin. Both sides verify identity before any of that begins. The full sequence is described in how the marketplace works.