Guide

Cloud Computing: Meaning, Models, and a Practical Example

Make cloud computing concrete by mapping a small application to the services it needs and the work its owner must still control.

By the Space Office team · Published November 2, 2026 · Updated November 2, 2026 · 16 min read

Cloud computing is a way to use computing resources and software over a network, with resources provisioned as services rather than managed entirely as local hardware. The service model determines how much the provider operates and how much you control. In Space Office, Tungsten can prepare infrastructure and operating work, Lithium can implement application logic, and Hydrogen coordinates and reviews. A human approves the requirements, access, spending, and release.

Key takeaways

• Define the workload and acceptance criteria before choosing a provider or server.
• Distinguish infrastructure, an application platform, and finished software: each leaves different work with you.
• Map public content, application behavior, and private records separately.
• Cloud hosting does not supply correct business rules, appropriate permissions, or a tested recovery process automatically.
• Compare the complete operating plan, including usage, data transfer, backups, support, and the person responsible for incidents.

For the application packaging layer, the Docker guide distinguishes a source folder, built image, running container, port mapping, and persistent data. Its local static-site exercise complements this guide’s service-model and operating decisions.

Download the cloud computing planning worksheet. The Makers Room workshop, traffic assumptions, capacity figures, and architecture below are fictional teaching examples. This guide does not provision an account, deploy an application, quote a provider price, or report a customer result.

What cloud computing means

NIST’s definition describes on-demand access to a shared pool of configurable computing resources. It identifies characteristics including self-service provisioning, network access, pooled resources, elasticity, and measured service. The practical idea is that a team can request a resource through the provider’s supported interface and use it without buying and installing all the underlying equipment itself.

There is still physical infrastructure behind a cloud service. The difference is how the capability is delivered and operated. Google Cloud’s introduction gives computing, storage, and databases as examples of resources delivered as services. A business may consume a finished application, deploy code to a managed platform, or operate software on rented infrastructure. These choices place different demands on the team.

Consider a workshop business that publishes class details and accepts bookings. A visitor sees a website, but the workload may involve page hosting, application code, stored booking records, sign-in, monitoring, and backups. Calling the whole thing “the cloud” can hide the individual decisions. List the required outcomes first: a visitor can read the schedule, a booking follows the capacity rule, and an authorized staff member can retrieve the correct record.

Service models and deployment models describe different dimensions. SaaS, PaaS, and IaaS describe what is supplied. Public, private, and hybrid cloud describe how environments are made available and combined. A public cloud is not an instruction to make your application’s data public. Access to a booking record still depends on the application, identity, and configuration choices made for that workload.

Using cloud computing also does not require turning every local task into a network service. A small Python calculation can run locally, while a shared booking application may need a hosted environment. An API describes how components interact; it does not identify who operates those components. Keep these concepts separate so the choice follows the work rather than a fashionable label.

Compare IaaS, PaaS, and SaaS by the work you keep

Microsoft’s IaaS overview describes infrastructure resources such as virtualized computing, storage, and networking. With a virtual machine, the customer normally takes on more software and operating-system decisions than with a managed application platform. With finished SaaS, the provider supplies the application experience, while the customer still needs to manage its own use, users, settings, and data responsibilities.

Start with the simplest model that meets the acceptance criteria. If an existing booking product supports the workshop’s capacity rules, export needs, and permissions, using that application may avoid building custom software. If the business needs unusual application behavior, a managed platform may be a suitable next option. A virtual machine offers more operating control and also creates operating work. More control is useful only when someone can own it.

The models can be combined. A custom web application might use a managed database, a separate object store for images, and a SaaS tool for an approved administrative workflow. Treat each connection as a boundary to document. The result can be useful without every part living on the same provider, but each additional service adds configuration, failure behavior, access decisions, and a possible dependency to monitor.

Avoid choosing a category from its headline price alone. A service that appears inexpensive can demand operator time your team does not have. A more managed service can still be a poor fit if it cannot enforce a required business rule or export your records. Write the reasons for accepting each tradeoff in the decision worksheet so a later team member understands the choice.

Map the workload before drawing an architecture

For Makers Room, begin with three components. Public content describes classes and displays a schedule. Application code validates booking requests and applies the capacity rule. A record store preserves accepted bookings and their status. Separating these jobs helps you ask whether a finished product already solves them, whether custom code is required, and which records should ever be accessible to a visitor.

Document the data flow in ordinary language. Which fields leave the browser? Which component checks them? Where is the accepted booking recorded? Who can read or change it? Which logs may contain request details? Use only the fields the workflow needs, and define retention and handling with the responsible owner. A diagram with boxes but no explanation of the records moving between them is incomplete.

Location is another workload decision. Google Cloud’s geography and regions documentation distinguishes regions, zones, and the geographic scope of resources. Check where each chosen service actually stores and processes the relevant data and which locations it supports. A region chosen for one component does not establish the location or failure characteristics of every connected service.

Keep the first design small enough to test. A workshop with a limited schedule does not automatically need multiple regions, a container orchestration platform, or several independent application services. Add complexity to satisfy an actual requirement and document how it will be operated. A clear single-environment proof with understood limits can teach more than a complicated diagram no one has the access or time to maintain.

Work through a class-booking example

Suppose one fictional class has capacity for 12 people and nine seats are already confirmed. Three seats remain. Two visitors each request two seats at almost the same time. If both requests merely read “three available” and each accepts independently, the application could confirm four new seats and reach 13. Cloud infrastructure can run the application, but the hosting category does not correct that business rule.

This example creates concrete implementation questions. What counts as confirmed? Do temporary holds consume capacity, and when do they expire? Can a staff member override capacity? What happens if a visitor presses the button again after a slow response? Answer these questions before selecting features or writing a success message. Otherwise, the team may build a technically responsive interface around an undefined business state.

Give the developer expected results for normal and failure cases. Include a request for more seats than remain, invalid quantities, an interrupted response, two simultaneous requests, and a repeated request. Test the record store and server-side decision as well as the visible form. A browser preview of the remaining count can help a visitor, but it is not the authority that accepts a booking.

Keep deployment effects explicit. A prototype using fictional records can demonstrate behavior without accepting real customers. Before release, the owner must approve the actual data handling, account access, spending, integrations, and rollback plan. Adding payments, confirmation messages, or a waitlist creates additional workflows and failure cases. None of those capabilities is assumed merely because the example uses a hosted application.

Assign access and shared responsibilities

AWS’s shared responsibility model distinguishes provider responsibility for the cloud infrastructure from customer responsibility for what they run and configure, with the split varying by service. For example, a customer operating an EC2 virtual machine is responsible for guest operating-system and application management. Do not assume a provider’s infrastructure controls establish correct customer permissions or a secure application configuration.

Create a responsibility row for each operational task. Name who can change the application, who approves a data-access change, who receives an incident alert, and who can authorize a paid resource. Use the service’s own documentation to verify which underlying tasks it manages. “Managed” should start a specific conversation about scope; it should not end the conversation about ownership.

Use test accounts and fictional records while checking permissions and recovery. Keep application secrets outside public source files and shared screenshots, and follow the selected platform’s supported credential and access mechanisms. This guide is a planning introduction rather than a security audit. The responsible technical owner still needs to review the actual service configuration, application paths, and organizational requirements before production use.

Plan cost, reliability, and exit before launch

Build the cost model from the workload, service configuration, region, and current provider terms. Include recurring service charges, application usage, database and object storage, requests, network transfer, backups, support, and operating time. Record which values are quoted prices and which are assumptions. A free allowance or a small development bill does not establish the cost of a future production workload.

A simple usage example exposes assumptions. If 10,000 page views each transfer an assumed 0.5 MB of billable content, the arithmetic is 5,000 MB, or five decimal GB, before any other traffic. This is an illustrative volume calculation, not a provider bill. Actual transfer depends on asset size, caching, service rules, traffic, and billing units. Price the relevant services using current documentation rather than multiplying this teaching input by an invented universal rate.

Reliability is part of the design and the operating process. The AWS Reliability Pillar frames reliability around foundations, resilient architecture, change management, and proven recovery. For the workshop, define what failure the first version can tolerate, how a failure is detected, who acts, and how the accepted booking records would be recovered. Buying a service is not a completed recovery rehearsal.

Specify a recovery exercise in a disposable or otherwise approved test environment. Start with known fictional bookings, create the intended backup, introduce a controlled test failure, follow the recovery steps, and compare the restored records and application behavior with the expected result. Record what was recovered, what remained missing, and how long the exercise actually took. Those observations apply to that exercise; they are not an uptime guarantee.

Also plan how to leave or change the service. Check export formats, application dependencies, account ownership, and the process for retrieving required records. A backup and a portable export may solve different needs. Rehearse the part that matters to the business rather than assuming an export button reproduces a complete working application elsewhere. Keep the relevant configuration and runbook under the customer’s control.

Use Space Office for a bounded cloud planning packet

A useful first assignment is a service-model decision and operating packet for one workload. The customer provides the business rules, expected traffic and data volumes, available budget, current environment, responsible owners, and constraints. Tungsten can prepare infrastructure, deployment, monitoring, and recovery work. Lithium can implement the application behavior, while Carbon can test the acceptance cases. Hydrogen coordinates and reviews the work against the agreed scope.

Ask for a workload map, a comparison of appropriate service options, a responsibility table, a dated cost model with assumptions, and a test and recovery plan. A human checks the requirements, confirms the evidence, approves access and spending, and makes the release decision. The workflow does not automatically create cloud accounts, grant credentials, authorize purchases, or deploy services. The agent directory and workflow overview explain the current roles and review process.

Cloud computing becomes easier to evaluate when you can name the workload, the service boundary, and the owner of every important decision. Start with what the application must do, choose the simplest suitable model, and test the business rules and operating procedures before release. Expand the design when the evidence requires it, while keeping cost assumptions, data responsibilities, and recovery limits visible.