Contents and search
Introduction to Cloud Computing

Chapter 2 · Part I · Orientation and foundations

Computing Before the Public Cloud

Read Cloud Computing: A Concrete System Map, or be able to distinguish a browser request path from provider management operations. Basic knowledge of processors, memory, and files is sufficient. Historical machine details are introduced whe

Approximately 3,119 words · 14 minute read

Prerequisites

Read Cloud Computing: A Concrete System Map, or be able to distinguish a browser request path from provider management operations. Basic knowledge of processors, memory, and files is sufficient. Historical machine details are introduced where needed.

Learning outcomes

After this lesson, you will be able to:

  • explain which operational problems batch processing, time-sharing, virtualization, and networked computing addressed;
  • distinguish remote hosting from cloud computing by observable operating characteristics;
  • connect public-cloud APIs and metering to earlier technical and institutional mechanisms;
  • calculate utilization and provisioned server-hours with explicit assumptions; and
  • use primary historical artifacts without treating product launch dates as the invention of a single idea.

Opening concrete narrative: waiting for the computer

In 1966, a university researcher carries a deck of punched cards to a computing center. An operator groups the deck with other submitted jobs. The expensive computer reads jobs, runs each program, and sends printed output back later. A missing comma can cost the researcher an entire submission cycle. The researcher does not directly control the processor while the job runs.

Another researcher sits at a terminal connected to a time-sharing computer. The terminal sends short interactions while a supervisor program switches the processor among users. Each person receives quick enough responses to edit, compile, and run programs interactively. The central processor still executes only a limited amount of work per second; the supervisor changes who can use that capacity and when.

CampusCart faces a related allocation problem decades later. Its application programming interface (API) normally completes 80 requests per second but can receive 400 requests per second during registration. Buying enough servers for the peak leaves processors underused during ordinary weeks. Buying only ordinary capacity creates a queue during the peak. Cloud computing did not remove the allocation problem. Cloud control software made standardized capacity available through network APIs, shortened acquisition time, and attached measurements to billing and policy.

Observable historical evidence

A historical claim needs an artifact produced near the event. A machine manual records commands and operating assumptions. A research paper records the authors' design and reported results. An announcement letter establishes what a vendor offered on a date, not how every customer used the offering. Source code can establish implemented logic, while an operator log can establish a particular run.

R. J. Creasy's 1981 International Business Machines (IBM) paper, *The Origin of the VM/370 Time-Sharing System*, reports that the Compatible Time-Sharing System (CTSS) became operational in 1961 and influenced the IBM Control Program (CP)/Cambridge Monitor System (CMS) design. “VM” identifies the Virtual Machine product family in VM/370. The paper describes operational CP-40 and CMS work in 1966 and the later VM/370 line. IBM's preserved timeline records the official VM/370 announcement on August 2, 1972. Creasy's paper and IBM's timeline support a sequence of named projects. The two historical artifacts do not support the claim that IBM invented every form of virtualization or that present cloud instances are unchanged VM/370 machines.

Public product announcements provide later landmarks. Amazon Web Services (AWS) announced Simple Storage Service (Amazon S3) on March 13, 2006 and an Elastic Compute Cloud (Amazon EC2) beta on August 24, 2006. Google's April 7, 2008 App Engine announcement called the offering a preview and listed quotas. Microsoft announced a Windows Azure technology preview on October 27, 2008. Each announcement exposes the original scope and language. Current product behavior must come from current documentation rather than an old announcement.

Mechanism: four developments that accumulated

Sharing expensive processors

Batch operation kept a processor supplied with queued jobs and reduced manual setup between runs. Time-sharing added rapid scheduling, protected memory, per-user files, and interactive terminals. A scheduler allowed one user's program to execute for a short interval and then gave another program access. Protection mechanisms prevented one ordinary program from freely overwriting another user's memory.

Practitioners use time-sharing for the allocation of computing time among multiple users or programs so that each can make progress. Time-sharing is not cloud computing. A department time-sharing machine can lack on-demand self-service, network access through standard mechanisms, rapid elasticity, provider pooling across customers, or measured consumption as defined by the National Institute of Standards and Technology (NIST).

Presenting more than one machine

IBM's CP/CMS work separated a control program from user environments. The control program scheduled processors, mapped memory, and presented virtual devices. Each guest environment could behave as though it controlled a machine even while physical capacity was shared. Practitioners call the mediating software a hypervisor and the presented computer a virtual machine (VM). Chapter 4 explains the mechanism in detail.

Virtualization improved isolation, compatibility, and allocation, but virtualization alone also does not create a cloud. A laptop can run three VMs without any remote API, metering, elasticity, or provider organization.

Connecting independently operated computers

Packet networking divided communication into bounded messages that could traverse interconnected links. The early Advanced Research Projects Agency Network (ARPANET) and later Internet protocols allowed programs on separately administered computers to exchange data. Client/server applications and the World Wide Web made remote programs broadly reachable. Domain Name System (DNS) names let administrators change addresses without changing the human-facing name.

Networking made remote access possible. Remote access alone did not standardize capacity acquisition. A hosting company could install one rented physical server after a support ticket and charge a fixed monthly fee. Such hosting was useful, but the customer might wait days for installation and might not receive a programmable mechanism for adding or releasing capacity.

Operating warehouses of computers through software

Large Internet applications required operators to treat many ordinary computers as a coordinated fleet. Automated installation, monitoring, replication, failure detection, load distribution, and distributed storage converted machine failures from rare exceptional events into expected operational inputs. Provider engineering joined that fleet automation with tenant isolation, identity, policy, public APIs, usage measurement, and commercial or institutional rules.

NIST's 2011 definition identifies five essential cloud characteristics: on-demand self-service, broad network access, pooled provider capacity, rapid elasticity, and measured service. The phrase cloud computing therefore names an operating model, not one hardware invention. The “measured service” term in NIST is historical terminology; a clearer local description is that provider mechanisms meter a named quantity such as instance-seconds, stored byte-months, or completed requests over a defined interval.

A causal timeline

| Period or date | Primary artifact | Mechanism made visible | Important limit | |---|---|---|---| | 1961–1964 | CTSS accounts in Creasy's later origin paper | interactive time-sharing and per-user work | one institutional computer was not an elastic public cloud | | 1966 | reported CP-40 and CMS operation | a control program presented protected virtual machines | specialized hardware and local operations remained necessary | | August 2, 1972 | IBM VM/370 announcement preserved by IBM | a supported commercial virtual-machine product | product access and capacity acquisition were not modern web APIs | | 1980s–1990s | Internet standards and web specifications | interoperable communication across organizations | remote servers could still be manually provisioned | | March and August 2006 | Amazon S3 and EC2 announcements | storage and VM capacity requested through web interfaces with usage charges | the initial offerings had far fewer regions, instance types, and durability options than current products | | April and October 2008 | Google App Engine and Windows Azure announcements | provider-managed application platforms entered broader developer use | both announcements described previews, not current production scope | | September 2011 | NIST Special Publication 800-145 | a durable vocabulary for characteristics and service models | the vocabulary classifies deployments; it does not certify quality or security |

Several streams overlap, so the rows must not be read as a single line of invention. Universities, governments, standards organizations, hardware firms, telecommunications operators, and Internet companies contributed different mechanisms under different names.

Technical terms in context: arrangements that are not synonyms

Batch processing names the queued execution arrangement that reduced operator setup between jobs. Time-sharing names rapid allocation of processor time among interactive users or programs. Both arrangements can improve use of an expensive computer, but neither term specifies network self-service or rapid capacity acquisition.

Remote hosting names the operation of a customer's workload on another organization's computers. Utility computing emphasizes measured consumption and charging that resembles an institutional utility. Grid computing usually joins capacity from multiple administrative or technical domains for coordinated work. Historical authors used the labels in overlapping ways, so a practitioner should state the observed acquisition, isolation, network, elasticity, and measurement mechanisms rather than infer them from one label.

Cloud computing names the broader operating arrangement defined by NIST's characteristics. Virtual machines, web APIs, metering, and fleet automation often implement that arrangement, but no one mechanism is sufficient by itself.

Working model: utilization and provisioned time

Let one CampusCart API server safely complete 100 requests per second under the stated workload. Assume requests divide evenly and that one server can carry the normal 80 requests per second. Four servers can carry the 400-request-per-second registration peak. Ignore redundancy for the moment so the allocation effect remains visible.

Define server utilization for this capacity-planning example as completed request capacity used divided by available request capacity during the same interval. The ordinary utilization of four purchased servers is:

80 requests/second ÷ (4 × 100 requests/second) = 0.20 = 20%

Peak utilization becomes:

400 requests/second ÷ 400 requests/second = 1.00 = 100%

The peak calculation leaves no failure or latency headroom. A practical design would target less than 100%, use measured latency and queue depth, and include redundant capacity.

Now assume CampusCart needs ordinary capacity for 8,752 hours each year and peak capacity for eight registration hours. Four owned servers provide 4 × 8,760 = 35,040 server-hours of annual capacity. A hypothetical perfectly elastic allocation uses one baseline server for 8,760 hours plus three extra servers for eight hours:

8,760 + (3 × 8) = 8,784 server-hours

The ratio 8,784 ÷ 35,040 ≈ 25.1% describes demanded server-hours divided by provisioned server-hours under these assumptions. The calculation does not compare money. Cloud prices can include different processors, storage, network transfer, support, and managed operations. Scaling also takes time, capacity can be unavailable, and a real two-zone design needs more than the minimum request capacity.

The useful prediction is narrower: when short peaks are much larger than the baseline and additional capacity can arrive before the queue becomes harmful, acquiring capacity for shorter intervals can reduce idle provisioned time.

Empirical test: observe time-sharing on a current computer

The following Linux or macOS shell experiment runs two processor-intensive commands at the same time. Use a non-production machine. Preserve the shell transcript and the timing output.

/usr/bin/time -p sh -c 'yes > /dev/null & p1=$!; yes > /dev/null & p2=$!; sleep 5; kill "$p1" "$p2"; wait "$p1" "$p2" 2>/dev/null || true'

Open a second terminal during the five-second interval and observe the two yes programs with top or ps. The shell starts both programs, the operating-system scheduler assigns processor time, and top samples processor accounting. The controlled condition is a five-second wall-clock interval. The varied condition can be one worker versus two workers. On a single available logical processor, two workers should share the available processor time. On a multi-core machine, both can run simultaneously, so record the reported logical processor count.

A result where both workers accumulate processor time supports scheduling and accounting; the result does not reproduce CTSS or a cloud. Thermal throttling, other programs, container quotas, and different top conventions are alternative explanations for unexpected percentages. A run where one worker receives no processor time for the entire interval would reject the simple fairness expectation and require investigation of priority, affinity, suspension, or measurement.

Worked investigation: should CampusCart buy for the peak?

Initial question

Would on-demand API capacity materially reduce CampusCart's idle provisioned time compared with four permanently allocated servers?

Operating conditions

One server safely completes 100 requests per second. CampusCart needs 80 requests per second for 8,752 hours and 400 requests per second for eight announced hours. Additional instances become healthy in three minutes. Registration demand rises from 80 to 400 requests per second over ten minutes. Storage and database capacity are held constant.

Evidence collected

Last year's timestamped load-balancer log summary shows the eight-hour peak and the ten-minute ramp. A repeatable load test establishes the 100-request-per-second safe limit for the tested server image. Deployment events from staging show three minutes from request to health-check success.

Interpretation

The ten-minute demand ramp is longer than the observed three-minute acquisition interval. An operator can therefore request extra instances before demand reaches the one-server limit if an alert or schedule acts early enough. The annual server-hour calculation predicts much less idle compute allocation. The database remains an untested bottleneck.

Proposed intervention or prediction

Keep one baseline instance and schedule three additional instances ten minutes before registration opens. Predict 8,784 allocated server-hours per year under the simplified schedule and no compute queue during the tested peak.

Observed or calculated result

The staging replay reaches 400 completed requests per second with four healthy instances and a 58% processor busy fraction on each instance. The replay's 95th-percentile API time remains 240 milliseconds. The annual allocation calculation remains 8,784 server-hours if staging behavior transfers to production.

Bounded conclusion

The historical demand profile and staging replay support scheduled temporary compute allocation for this eight-hour peak. The evidence does not establish a lower bill or successful production behavior.

Remaining uncertainty

Production request mixtures, provider capacity, zone loss, database locks, network limits, object retrieval, scaling failures, and price changes remain outside the test. A flash crowd faster than three minutes can still overload the baseline instance.

Normal case, failure case, and qualifications

The normal on-demand case has a known demand ramp, a tested machine image, sufficient provider quota, available zone capacity, a health check, and an automated release action. Provider metering produces usage records after allocation. CampusCart operators compare those provider records with deployment events and workload measurements.

A limiting case occurs when demand jumps to 400 requests per second in ten seconds while additional instances need three minutes. Requests queue or fail before new capacity becomes healthy. Pre-scaling, spare capacity, admission control, caching, or a different architecture must cover that interval. “Elastic” describes the ability to change allocation; the word does not mean instantaneous or unlimited.

CivicPermit's history can lead to a different allocation decision. The government application carries personally identifiable information, has audit obligations, and requires operation across two availability zones. Procurement time, authorization scope, data residency, evidence retention, and failure capacity can dominate the simple server-hour ratio. Cloud acquisition changes who operates each mechanism; the change does not remove the agency's duty to verify the complete arrangement.

Historical labels also require care. “Utility computing,” “grid computing,” “hosting,” and “application service provider” described overlapping arrangements. NIST's characteristics offer a useful test, but real products can sit near category edges. Private clouds can meet the characteristics without selling capacity to the public. Public provider use can also include dedicated hardware.

Common errors

  • “Cloud computing began on one launch date.” Public launches are important commercial landmarks, while the required mechanisms developed across decades and institutions.
  • “Time-sharing and cloud computing are synonyms.” Time-sharing allocates processor time. Cloud computing adds a broader operational arrangement including network access, self-service, pooling, elasticity, and measurement.
  • “Virtualization created elasticity.” Virtualization makes capacity easier to partition, but control software, images, networking, health detection, quota, and institutional processes create usable elasticity.
  • “Twenty-percent utilization means the owned servers are waste.” Redundancy, latency targets, growth, failure headroom, and fixed-cost constraints can justify idle capacity. The percentage is evidence for a decision, not the decision itself.
  • “Pay per use always costs less.” Unit prices, transfer charges, support, engineering labor, commitments, and demand shape determine total cost.

Knowledge check

Question: A hosting company installs a dedicated server after a customer submits a ticket, charges one fixed monthly fee, and provides network access. Which NIST cloud characteristics are directly visible, and which are missing or unproved?

Answer: Broad network access is visible. The description does not establish on-demand self-service, rapid elasticity, pooled provider capacity, or usage measurement. Dedicated hardware does not disqualify a broader cloud arrangement, but the stated ticket workflow and fixed allocation do not establish the remaining characteristics.

Exercises

Check

Create a five-row evidence table for CTSS, CP-40, VM/370, Amazon EC2 beta, and Google App Engine preview. For each row, preserve a source Uniform Resource Locator (URL), artifact producer, date, directly supported claim, and one unsupported claim. Submit the table.

Practice

Repeat the utilization calculation for a safe server capacity of 125 requests per second, a normal demand of 80 requests per second, and a peak of 400 requests per second lasting 24 hours each year. Choose the minimum integer server count for the peak, state a headroom qualification, and submit all arithmetic with units.

Challenge

Run the scheduler experiment with one, two, and four workers for five seconds each. Preserve raw timing and top or ps samples. Report logical processor count, processor time per worker, wall time, and at least two confounding factors. Write a bounded conclusion that does not call the local computer a cloud.

Authoritative sources and further reading

Required reading

Primary product records

Advanced reference

Historical sources establish behavior and claims at their publication dates. Old quotas, prices, product limits, and product names are not current implementation documentation.

Next-chapter transition

Time-sharing and virtualization explain how operators divide machines. Public cloud use also depends on communication between independently located programs. The next chapter follows a request through DNS, addresses, routes, transport security, traffic distribution, and private cloud networks.