How does cloud computing work? From request to running workload

How does cloud computing work? A cloud platform turns physical processors, memory, storage, and networks into resources you can request through software. It checks your identity and the requested configuration, finds available capacity, prepares the environment, and makes it accessible. Your application then runs on real hardware while the platform manages resource status and records usage.

For a developer, student, or technical buyer, following that sequence explains what a cloud provider manages and where your own work begins. Understanding that process helps when an application will not start, capacity is unavailable, or charges continue after a job finishes. This guide follows an infrastructure request from creation to shutdown, then shows how managed services and Compute with Hivenet change the details.

The two layers of cloud computing architecture

The NIST description of cloud infrastructure separates physical hardware from the software abstraction above it. That distinction explains why a simple console action can involve several systems.

Physical computing infrastructure does the work

Physical servers supply CPUs, memory, and sometimes GPUs. Data storage devices hold data, and switches and routers connect machines. Power, cooling, facilities, and hardware maintenance support those resources. Infrastructure may occupy large data centers, colocation facilities, private premises, or smaller distributed sites.

A region or resource type in a console represents a choice within that physical infrastructure. It is not an unlimited supply. Maintenance, existing demand, hardware compatibility, and placement restrictions can make a requested configuration unavailable.

Software makes infrastructure available as a service

In a cloud environment, management software exposes APIs, consoles, templates, identities, policies, and lifecycle controls. Other components allocate resources, create execution environments, configure networks, connect storage, and collect operational information.

Virtual machines are one way to expose computing resources. Containers, bare-metal systems, and managed runtimes are other possibilities. The implementation differs between cloud service providers, and several mechanisms can exist in the same cloud platform.

How does cloud computing work step by step?

Consider a request for an instance that will run an application. The following sequence is a conceptual model: providers may combine, reorder, or perform parts in parallel. Creating a resource is also different from sending an ordinary request to an application that is already running.

1. You describe the resource you need

A console, command-line tool, API client, deployment pipeline, or infrastructure-as-code tool sends a request. For an instance, the configuration might include location, CPU or GPU resources, memory, disk, an operating-system image or container template, and connection settings.

The platform receives a desired configuration. It may acknowledge the request before the environment is ready, so keep its resource identifier and inspect progress rather than assuming that a successful submission means a working application.

2. The platform checks identity and permission

Authentication establishes which person or service is making the request. Authorization checks whether that identity may perform the action on the relevant account, organization, or project.

A valid login does not grant every permission. For example, someone may be allowed to use an existing instance but unable to change billing or delete a shared resource. Credentials for managing infrastructure may also differ from the keys used to connect to the application.

3. The control plane validates the configuration

The management layer checks the request against relevant quotas, policies, supported configurations, account conditions, and service limits. A request can fail because a resource type is unsupported, a quota is exhausted, or the account lacks required credit.

Validation and provisioning are separate operations. Some errors occur before anything is created; others happen partway through setup. After a failed deployment, inspect its state and any resources it created before retrying. Otherwise, retries can leave duplicate resources or unexpected charges.

4. A scheduler finds suitable capacity

A scheduler or allocation service selects capacity that meets the request. CPU, memory, accelerator requirements, location, and placement policies can all matter. A request that fits an account quota can still fail because matching physical capacity is unavailable.

The Kubernetes scheduler provides a concrete example: it filters out unsuitable nodes, scores feasible ones, and selects a placement for a Pod. If no node fits, the Pod remains unscheduled. This illustrates scheduling; it does not mean every cloud provider uses Kubernetes.

5. An execution environment is prepared

For a virtual machine, virtualization software presents virtualized computing resources to a guest operating system. A VM is not necessarily a dedicated physical server. For a conventional container, processes use a shared host kernel with isolation controls; some platforms add further isolation layers.

Bare-metal services expose dedicated physical hardware with a different management boundary. Managed databases, functions, and model endpoints hide more of their execution environment. These choices provide different levels of control, isolation, and maintenance responsibility.

6. Network resources and storage are connected

The environment needs routes to its users, data, and dependencies. Depending on the service, the platform configures addresses, virtual networks, firewall rules, gateways, load balancers, or managed endpoints. Public internet access is a configuration choice, not a requirement for every cloud resource.

Storage may be a disk-like block volume, a shared file system, an object service accessed through an API, or a managed database. The application needs the correct addresses, permissions, credentials, and mount or client configuration. A processor running successfully does not prove that any of these connections work.

7. The environment starts and the application initializes

A VM boots its operating system and applies startup configuration. A container runtime starts the requested image and process. Application initialization may then load configuration, connect to a database, apply migrations, or load model weights into memory.

Infrastructure status and application readiness are different signals. A running instance can contain a stopped process, a failed model load, or an application listening on the wrong port. Check the application's health and a representative request before sending it real traffic.

8. The workload runs and its lifecycle continues

Physical processors execute instructions while memory, storage, and networks support the work. The workload might serve a website, process data, render frames, or perform inference. The platform continues to manage the resource and measure relevant usage.

Later actions, including a resize, restart, replacement, stop, or deletion, return to the management layer. Each action has its own permissions, capacity requirements, and consequences for data and charges.

What is the cloud control plane?

The control plane manages resources. The data or workload plane carries their active work. Creating a database is a management operation; querying its records is a data operation. Microsoft's control-plane explanation makes this distinction explicit.

This separation helps diagnose an incident. A failed resource-creation request does not necessarily mean an existing application has stopped serving traffic. Conversely, a working console does not prove that the application's database or network path is healthy.

These are logical responsibilities, not a promise that each plane occupies separate hardware. In Kubernetes architecture, the control plane manages worker nodes and workloads, while node components execute containers. Physical placement can vary with the deployment.

Resource sharing, isolation, and cloud security

Resource pooling allows a platform to allocate infrastructure across multiple users. Isolation controls separate execution, access, and data. Sharing a host does not mean another customer is authorized to read your files, but isolation quality depends on the technology, configuration, and operation of the service.

A virtual CPU is an assigned computing resource, not a universal promise of an exclusive physical core. Likewise, a GPU service might allocate a whole device, a partition, or another form of shared access. Check the selected resource's specification rather than assuming that every GPU instance exposes an entire card.

Our guide to GPU virtual machines explains that particular environment. Choose the control and capacity your software needs, including memory and driver compatibility, rather than treating the instance label as a complete hardware description.

Compute, networking, and cloud storage have different lifecycles

Block storage behaves like a disk, file storage provides a file-system interface, and object storage exposes objects through service requests. Those interfaces affect how an application accesses data. Their retention and deletion rules are a separate question.

Amazon EC2's storage documentation, for example, distinguishes EBS volumes from temporary instance-store storage. Instance-store data is lost on stop, hibernation, or termination. Persistent storage can have its own deletion settings and charges.

Before a lifecycle change, identify where important data lives, whether it survives the action, and how you would restore it. Replication, a mounted volume, and an available snapshot are not equivalent to a tested recovery process. Use a recoverability test to check the result you depend on.

Networking can change too. Restarting or replacing an instance may affect addresses, endpoint associations, or active connections. Use the service's documented connection details and avoid assuming that an old address will remain valid.

How cloud computing scales

Vertical scaling changes the resources available to one instance or workload. Horizontal scaling changes the number of instances or replicas. Either can be manual or automated; cloud hosting alone does not enable autoscaling.

The Kubernetes autoscaling overview distinguishes these approaches. An automatic policy still needs suitable measurements, limits, and available capacity. A larger allocation may require a restart, and additional replicas need work that can be divided between them.

Scaling helps only if it addresses the limiting component. More application replicas may not help a saturated database, slow storage, or a task that must execute sequentially. Measure request latency, queue length, errors, and resource utilization before choosing a change.

What happens when cloud infrastructure fails?

A disk, host, network path, dependency, or software process can fail. A platform may detect the problem and restart or replace a resource, redirect traffic, or expose an error for an operator to handle. Which actions are automatic depends on the service and configuration.

Replacement capacity does not recreate unsaved work. Applications may need checkpoints, retries, duplicate-request handling, and data recovery. A retry must be designed carefully: repeating a request to charge a customer or submit a job can create a second action if the first succeeded but its response was lost.

Reliability and disaster recovery therefore require more than an instance's existence. Decide which failures the design should tolerate, keep recoverable data outside a single failure point where appropriate, and test restoration. Do not assume that a provider's infrastructure monitoring checks your application's results.

Who manages what in different cloud computing services?

Service models describe how much of the software stack is operated for you. Microsoft's shared-responsibility guidance shows why the division changes between infrastructure, platforms, and finished applications.

• Infrastructure as a service (IaaS): the provider manages physical infrastructure; you usually manage the guest OS, applications, and their configuration.
• Platform as a service (PaaS): the provider operates more of the runtime; you deploy and configure your application.
• Software as a service (SaaS): the provider operates the application; you still manage relevant accounts, access, data, and settings.

Serverless functions and managed endpoints introduce further service-specific boundaries. You may supply code or send API requests without choosing a server, but software dependencies, input handling, permissions, and application behavior still need an owner.

Public cloud, private cloud, and hybrid cloud are deployment models rather than this allocation of software work. A multicloud setup uses multiple providers. Neither label tells you whether a particular database is managed or who must patch an operating system.

How measured usage becomes a bill

Cloud platforms measure units defined by each service, such as instance runtime, provisioned storage, requests, or data transfer. A price schedule converts those units into charges, sometimes alongside subscriptions, commitments, or support fees. Measured service does not guarantee a lower total cost.

A running resource can cost money while idle. Stopping one component may leave other billable resources behind. The EC2 lifecycle documentation explicitly separates instance usage from resources such as retained volumes and addresses.

Review the resources created by a deployment as a group: compute, disks, snapshots, networking, logs, and managed services. Confirm the service's charging states, minimum billing increments, retention rules, and cleanup behavior. A budget notification is useful, but it is not necessarily a spending cap.

A GPU workload from request to shutdown

Suppose a developer wants to serve a model on rented GPU capacity. They first check the model license, GPU memory needs, software requirements, expected traffic, and how input data may be handled.

1. Request: choose a suitable resource, location, image, storage plan, and restricted connection settings.
2. Prepare: wait for the instance, connect, load the model, and configure the serving process.
3. Verify: test a request, check permissions, inspect errors, and measure response time and memory use.
4. Operate: monitor behavior and cost, preserve important outputs, and make capacity changes deliberately.
5. Finish: export data, confirm the copy is usable, and apply the documented stop or termination procedure.

The provider supplies infrastructure; the developer still needs a working, protected service. Opening a network port does not configure authentication, and a GPU allocation does not establish that the model fits or meets the required latency.

How Compute with Hivenet applies this lifecycle

Compute with Hivenet offers GPU and vCPU instances through containers or virtual machines. The current Compute quickstart starts with choosing an organization, checking its credit balance, and configuring an available instance, software environment, and connection options.

Review the current resource details and price in the console. Once created, the instance reaches Running after it responds over SSH; the application may still be initializing. Connect using the instance's displayed details and verify the workload separately.

The VM and container comparison matters here: Compute containers do not provide root or sudo access. Choose a VM when your software needs OS-level control. Do not assume that every instance permits the same system changes.

Compute billing uses prepaid organization credits and per-second charging while an instance is Running. Only the organization Owner can add credits. Low credit can interrupt workloads, so monitor the balance and keep independent copies of important data.

An instance and a managed inference endpoint are different services

With an instance, you operate the application or model-serving software within that environment. Hivenet Inference API instead provides managed model endpoints, leaving you to integrate the API, control access, handle inputs, and evaluate outputs.

Its current billing documentation describes fixed running replicas billed per second, rather than per token. Autoscaling is not currently available. Fewer requests therefore do not automatically reduce provisioned capacity or its cost.

Stopping does not preserve an instance indefinitely

Hivenet's start and stop documentation says compute charges stop when an instance leaves Running. Stopping releases capacity and keeps configuration and data temporarily. Restart depends on matching capacity, and an instance left stopped for more than 10 days is automatically terminated.

Termination permanently deletes the instance and its local data. Export and verify important files beforehand. Waiting for capacity does not extend the stopped-instance retention window. These are Hivenet-specific rules, not a universal cloud policy.

Does distributed infrastructure change the process?

Infrastructure can be arranged across multiple sites while exposing familiar controls for instances, networks, storage, and APIs. The physical arrangement can affect placement and failure planning, but users still request resources, run workloads, monitor results, and manage their lifecycle.

Distribution alone does not establish a security, availability, latency, or environmental outcome. Evaluate the actual service boundaries, locations, dependencies, and operating commitments. The same applies when comparing providers with large centralized facilities and those using smaller distributed sites.

Questions about how cloud computing works

Does every application request create a new server?

No. A request often reaches an already-running process or managed service. Some platforms start or scale execution capacity in response to demand, but that behavior depends on the service, configuration, and current capacity.

Does a working internet connection guarantee access?

No. You also need a reachable network path, permitted credentials, correct configuration, and a healthy application. Some cloud services are accessible only through private networks.

Can a running cloud instance still be unusable?

Yes. The infrastructure can be running while its application is starting, has failed, lacks data access, or cannot accept traffic. Check both resource status and application behavior.

Does deleting compute remove every cost and every copy of data?

No universal rule applies. Local data may be destroyed while separate disks, backups, logs, endpoints, or commitments remain. Review the resource relationships and deletion settings before cleanup.