Contents and search
Introduction to Cloud Computing

Chapter 1 · Part I · Orientation and foundations

Cloud Computing: A Concrete System Map

You should know that a browser sends requests to a web server and that a relational database stores rows. Basic familiarity with source code, files, and a command-line shell is enough. No cloud account is required. Readers arriving through

Approximately 2,913 words · 13 minute read

Prerequisites

You should know that a browser sends requests to a web server and that a relational database stores rows. Basic familiarity with source code, files, and a command-line shell is enough. No cloud account is required. Readers arriving through a direct link can complete the observations with browser developer tools and curl.

Learning outcomes

After this lesson, you will be able to:

  • follow one web request from a browser to application code, a PostgreSQL database, and object storage;
  • identify which cloud objects exist in a region, in an availability zone, or at a provider-wide scope;
  • separate the request path from the management path;
  • name the evidence that confirms a claimed deployment; and
  • explain why two availability zones, a compliance label, or a provider product name does not by itself guarantee a desired outcome.

Opening concrete narrative: one purchase, many machines

At 10:03 on registration morning, Maya opens CampusCart, a small university bookstore application, from a laptop in a residence hall. CampusCart serves about 5,000 users per day. The application normally completes 80 web requests each second and can receive 400 requests each second during registration peaks. Maya selects a laboratory manual and presses Buy. A spinner remains visible for two seconds, so the campus developer on duty needs to locate the delay.

CampusCart has a browser interface, an application programming interface (API), a PostgreSQL database, and an object store that holds book-cover images. The browser does not contact PostgreSQL directly. The Domain Name System (DNS) resolves a public name, a traffic distributor selects an API instance, and the API reads inventory rows from PostgreSQL. A separate object request retrieves the cover image. Each program runs somewhere physical even when the provider console displays only icons.

Across town, CivicPermit accepts government permit applications that contain personally identifiable information (PII). CivicPermit must preserve audit evidence and remain available after the loss of one of its two configured availability zones. An operator cannot establish either property by pointing to a diagram. The operator needs deployment configuration, access logs, database replication status, restore results, and a controlled failover exercise.

Both investigations begin with the same question: which concrete object handled the action, and which artifact can prove the answer?

Observable evidence

A browser's Network panel produces one row for each observed browser request. The row usually contains the target name, method, status, transferred bytes, and timing phases. The browser clock supplies the client-side timestamps. A 200 status establishes that a Hypertext Transfer Protocol (HTTP) server reported success; the status does not establish that the intended database row was committed.

The API program produces an application log when its logging code executes. A useful CampusCart entry contains a generated request identifier, route, response status, elapsed milliseconds, and selected API instance. The load balancer can produce another access-log entry with a listener address, chosen target, and target response time. PostgreSQL can produce a statement log or an audit event, subject to its configuration. The object store produces object-access evidence only when access logging or an audit facility is enabled. Missing logs can therefore mean either “no action occurred” or “the responsible producer was not configured to record the action.”

The cloud management interface produces configuration objects and audit events. A deployment listing can establish that two virtual machines were requested in two zones. A provider audit event can identify which authenticated principal changed a firewall rule. Neither artifact proves that a browser request reached both zones or that application data replicated correctly.

The following map names the main CampusCart objects and the artifacts that expose them:

Student laptop
  browser Network row
        |
        | DNS lookup and encrypted HTTP request
        v
Public name and traffic distributor
  DNS answer, certificate, load-balancer access log
        |
        +-----------------------+
        |                       |
        v                       v
API instance in zone A     API instance in zone B
  application log            application log
        |                       |
        +-----------+-----------+
                    |
          PostgreSQL connection
                    v
      managed PostgreSQL deployment
      query evidence, transaction rows,
      replication and backup status

Browser ------------------> object store
                            object metadata and access event

Engineer -----------------> provider management API
                            configuration and audit event

The arrows above represent distinct communications, not a guarantee of one physical route. A provider can change an internal route without changing the public API.

Mechanism: the request path and the management path

Maya's purchase begins when browser code resolves the CampusCart name through the Domain Name System (DNS). The browser then establishes protected communication with the returned endpoint and sends a Hypertext Transfer Protocol (HTTP) request. A load balancer accepts the connection and forwards the request to a healthy API instance. The API validates Maya's input, asks PostgreSQL to change inventory and order rows in a transaction, and returns a response. The cover image can follow a separate path through an object-storage endpoint or a cache.

Cloud practitioners call that movement the data plane: the provider mechanisms that carry or operate on workload data. The term includes more than network packets. A database read and an object retrieval are data-plane operations because both act on CampusCart's workload data.

Earlier, an engineer used a console, command-line client, or deployment tool to ask the provider to create networks, compute instances, database capacity, and access rules. Provider control software authenticated the engineer, checked policy and quota, selected capacity, and stored the requested configuration. Practitioners call those management operations the control plane. A control-plane success response means that the provider accepted or completed a requested configuration change according to the named API. The response does not prove that CampusCart now works end to end.

The distinction explains an important failure. Existing CampusCart requests might continue while the management API is unavailable because already-created load balancers and API instances still forward traffic. Conversely, a successful deployment can produce an unusable application when a route or credential is wrong.

Technical terms in context

A cloud resource is a provider-managed object with an identity and lifecycle, such as a virtual machine, network, database deployment, or object bucket. The surrounding noun matters: a PostgreSQL connection is not the same object as a managed PostgreSQL deployment. An API is the defined request and response interface through which one program asks another program to act. A graphical console normally calls provider APIs on the operator's behalf. The National Institute of Standards and Technology (NIST) definition supplies a durable test for whether the surrounding operating arrangement qualifies as cloud computing.

A region is a provider-defined geographic area used to place cloud objects. An availability zone is a provider-defined failure-isolation location within a region. Provider definitions differ in physical detail. Current Google Cloud documentation describes regions as independent geographic areas containing zones; current Microsoft Azure documentation describes an availability zone as a separated group of datacenters with independent power, cooling, and networking; Amazon Web Services (AWS) documents regions and multiple isolated locations called Availability Zones. The durable design idea is failure separation. Exact zone counts, supported products, and physical arrangements remain version-sensitive.

Provider product names are coordinates, not concepts. Structured Query Language (SQL) names the query language in the Cloud SQL product brand; the managed deployment includes much more than a language parser. The table maps common concepts to names visible in official documentation as checked on July 20, 2026:

| Needed object | AWS | Google Cloud | Microsoft Azure | |---|---|---|---| | virtual machine | Amazon Elastic Compute Cloud (Amazon EC2) instance | Compute Engine virtual machine (VM) instance | Azure Virtual Machine | | isolated virtual network | Amazon Virtual Private Cloud (Amazon VPC) | Virtual Private Cloud network | Azure Virtual Network | | object storage | Amazon Simple Storage Service (Amazon S3) bucket | Cloud Storage bucket | Blob Storage container in a storage account | | managed PostgreSQL | Amazon Relational Database Service (Amazon RDS) for PostgreSQL | Cloud SQL for PostgreSQL | Azure Database for PostgreSQL |

Product features and availability change more quickly than the request path described above. Google Cloud is the current official product-family name; Google Cloud Platform (GCP) remains common shorthand but should not be treated as a separate provider.

Working model: requests in flight

CampusCart's request completion rate is the number of completed API responses divided by the observation interval, measured in requests per second. Let lambda denote that completion rate. Let W denote the mean time in seconds from API arrival to API response. Under a stable observation interval, where arrivals and completions are balanced and no large queue is growing, the approximate mean number L of requests inside the API is:

L = lambda × W

The units explain the relationship:

requests/second × seconds = requests

At the ordinary 80 completed requests per second and a mean API time of 0.200 seconds, CampusCart has approximately 80 × 0.200 = 16 requests in progress. At 400 completed requests per second with the same mean time, the estimate becomes 80 requests in progress.

The working model assumes a stable interval, uses means, and treats the API boundary as the start and end of the measurement. The estimate does not predict a percentile, database connections, browser concurrency, or required server count. A queue that grows during overload violates the stability assumption. Slow database calls can also make W rise with load, so multiplying peak arrivals by an old timing value can understate peak concurrency.

The calculation gives an immediate evidence check. If an operator claims 400 completed requests per second, 200 milliseconds mean time, and only five API requests in progress, at least one measurement boundary or clock differs.

Empirical test: expose the public part of the path

Use a public test name rather than a production government endpoint. Run the following commands twice and preserve the output. The target Uniform Resource Locator (URL) is intentionally non-production:

dig +noall +answer example.com
curl -sS -o /dev/null \
  -w 'code=%{http_code} peer=%{remote_ip} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

The Internet Assigned Numbers Authority maintains example.com for documentation. dig displays DNS resource records produced by the resolver's answer. curl produces client-side cumulative timings from its own monotonic timing source where supported. Keep the network, target URL, and command constant; vary only whether the lookup is likely cached by comparing the first and second run.

The expected second lookup can be faster, but a shared resolver cache can make the first run fast as well. A different result does not reject DNS caching by itself. Repeatedly slower connection or first-byte phases could instead reflect routing, server work, radio conditions, or measurement noise. The test rejects the simple claim that “all delay is in application code” when a large part of total occurs before first_byte processing could plausibly finish. Chapter 3 will separate the cumulative fields correctly.

Worked investigation: did two zones serve CivicPermit?

Question

Did CivicPermit continue to accept permit submissions when one availability zone became unavailable?

Conditions

The staging deployment has one API instance in zone A and one in zone B, one zonal traffic distributor, and a PostgreSQL primary in zone A. A test client submits one uniquely numbered synthetic permit each second for five minutes. Synthetic names contain no PII. Operators block the zone-A API health endpoint after minute two; they do not alter the database.

Evidence collected

The test client produces 300 timestamped result rows. Load-balancer access logs identify the selected API target. API logs identify the zone and synthetic permit number. PostgreSQL rows establish committed submissions. The deployment listing confirms two requested API placements. During the intervention, 296 client rows report 201, while four report 503. After health detection, every successful API log names zone B. PostgreSQL contains 296 unique rows.

Interpretation

The target and API logs establish that zone B accepted work after zone A's API became unhealthy. The four 503 responses show a short interruption during health detection. The PostgreSQL evidence establishes committed synthetic submissions, not merely HTTP responses. The test did not remove the zone-A database, so the exercise did not represent complete zone-A loss.

Intervention or prediction

Before the run, the team predicted that API traffic would move to zone B after a health-check interval and that all database writes would continue because the database remained reachable.

Result

Traffic moved as predicted, but four requests failed before the traffic distributor stopped selecting the unhealthy target. The observed success fraction was 296 / 300 = 98.67% during this deliberately disruptive five-minute interval.

Bounded conclusion

Collected evidence supports only the claim that the staging traffic distributor redirected API requests after the simulated API health failure. Collected evidence does not support the broader claim that CivicPermit survives loss of zone A.

Remaining uncertainty

The exercise left database failover, object storage, identity, DNS, audit-log delivery, and real zone isolation untested. Provider maintenance could also fail differently from the health-endpoint block.

Normal case, failure case, and qualifications

In the normal CampusCart case, DNS returns a reachable endpoint, protected HTTP negotiation succeeds, the traffic distributor selects a healthy API instance, PostgreSQL commits the order, and each evidence producer emits a correlated artifact. A request identifier connects the browser response to load-balancer and API entries without placing customer secrets in logs.

A common edge case appears when two API instances exist but both depend on one zonal database. A zone failure can then leave healthy API programs unable to complete purchases. Two-zone compute placement is necessary for that design goal but not sufficient. Capacity also matters: one remaining zone must have enough healthy compute and database capacity to carry the intended failure load.

Government deployment names require another qualification. AWS GovCloud (US), where “US” means United States, uses isolated regions with different region names, endpoints, and Amazon Resource Name partitions. Azure Government uses separate endpoints and can differ from global Azure in product and feature availability. Google Cloud Assured Workloads applies predefined control packages and monitors specified policy violations. None of those offerings transfers CivicPermit's legal, data-classification, access-control, or application-design responsibility to the provider. Compliance scope must be verified for the exact product, region, configuration, and assessment date.

Common errors

  • “The console icon is the running application.” The icon represents a control-plane object. Request evidence must come from the data path and the workload.
  • “Two zones mean high availability.” Correlated dependencies, insufficient remaining capacity, and missing failover logic can still stop the application.
  • “A 200 response proves the purchase.” The HTTP status reports the server's response semantics. A database row or domain event is needed to establish the intended commit.
  • “The cloud has no physical location.” Provider abstractions hide many hardware details, but processors, disks, cables, buildings, and personnel still exist in governed locations.
  • “Managed means no customer responsibility.” The provider operates a larger part of the stack, while the customer still controls data, identities, allowed access, application behavior, and many configurations.

Knowledge check

Question: A deployment listing shows one CivicPermit API instance in each of two zones. Which claim does the listing directly establish, and which additional evidence would support continued operation after a zone failure?

Answer: The listing directly establishes the requested or current placement reported by the provider control plane. A controlled failover run needs client results, traffic-distributor target logs, API logs, committed database evidence, and database failover status. The additional artifacts connect placement to actual request completion.

Exercises

Check

Draw the CampusCart request path with separate arrows for the API call and cover-image retrieval. Label each endpoint and write one evidence artifact beside every arrow. Submit the annotated diagram and one sentence that distinguishes direct observation from inference.

Practice

Run the dig and curl commands five times at least ten seconds apart. Preserve the raw output in a text file. Calculate the median total time in seconds, name the clock and program that produced each timing, and explain why the DNS answer does not reveal every machine that handled the request.

Challenge

Write a two-zone CivicPermit test plan with one synthetic request per second for ten minutes. Include unique identifiers, controlled conditions, the exact failure action, expected artifacts, a success criterion, a stop condition, and a list of claims the test cannot establish. Submit the plan plus a table schema for the evidence. Do not use real PII.

Authoritative sources and further reading

Required reading

Implementation documentation

All implementation pages above were checked on July 20, 2026. Provider names, region inventories, compliance authorizations, and feature availability are version-sensitive; verify the current page and the exact target environment before making a deployment decision.

Next-chapter transition

The system map shows what exists and which artifacts make a cloud claim testable. The next chapter explains how time-sharing, packet networks, virtual machines, distributed datacenters, and metered interfaces developed into the operating arrangement now called cloud computing.