Cloud Computing: History, Motivation & Terminology
Lecture 1 of Cloud, Web & Mobile (Univ. Duisburg-Essen, Torben Weis). Two blocks: “Historische Einordnung / Motivation des Cloud Computing” and “Begrifflichkeiten”.
1. The centralization cycle
| Era | Architecture | Operation | Effect |
|---|---|---|---|
| Rechenzentren / Mainframes, “Mini” computer | IBM System 360; PDP-11 as a cheap “mini” | Mehrbenutzer-Betrieb, access via Terminals | Zentralisierung of compute power |
| Personal / “Micro” computer | Historic PC | Einbenutzer-Betrieb | Dezentralisierung — enabled by Miniaturisierung |
| Embedded systems / Pervasive Computing | One computer per “Ding” | Embedded | Dezentral — also enabled by Miniaturisierung |
| Cloud | Few huge data centers, thin clients | Multi-tenant | Re-centralization — “Cloud Computing: Zurück zum Anfang?” |
The pattern to remember: the pendulum swings between centralization and decentralization, and each swing is triggered by a technology step (miniaturization) plus an economic driver.
Peer-to-Peer computing (the decentralized counter-model)
- PCs have surplus resources: Rechenkraft, Speicherplatz, Bandbreite.
- Illegal content is easy to delete on a server; shutting down a P2P system is hard (no single point of control).
- Central servers become barely/not necessary → weniger Server, geringere Kosten.
2. What actually caused cloud computing
- Vernetzung und Netzwerkeffekte — data communication becomes faster and cheaper; end customers and providers are online.
- Auswertung riesiger Datenmengen — Google, Facebook & Co., plus scientific data analysis.
- Skalierbarkeit und Effizienz — compute is rented on demand: scaling = simply renting more.
- Out-Sourcing von Rechenzentren — better cost and energy efficiency at a specialized provider.
- Limitierte Endgeräte — web browser, smartphones, Google’s Chromebook: the client is deliberately thin.
3. Network effects (Netzwerkeffekt)
Definition: the benefit rises with the number of users; beyond a critical mass (kritische Masse) it rises faster than linearly.
Two-sided network effect (indirect) — two user groups; growth of one group benefits the other:
- Developers ⇄ users of an operating-system platform.
- Content providers ⇄ customers buying a modem/DSL access: more web servers ⇒ more reasons to get online.
Same-sided network effect (direct) — one user group, superlinear value:
| Law | Growth | Reason | Example |
|---|---|---|---|
| Metcalfesches Gesetz | quadratic, value ∝ n(n−1)/2 | the number of 2-party connections | telephone, fax |
| Reedsches Gesetz | exponential, value ∝ 2ⁿ | the number of subgroups | online games, social networks |
Search engines are the economic punchline: they learn from every click (list shown → user picks an element → that influences future ranking). The network effect comes from centrally collected data — user data is the most valuable asset of Google, Bing & Co. Central data storage is what finally makes large data centers necessary.
Negative network effects
- Congestion (Stau) reduces the efficiency of a network and therefore its value.
- Countermeasures on the Internet:
- Modern DSL/cable modems — avoids congestion at the customer.
- Data centers — avoids congestion at the provider.
- Renting compute — enables fast scalability of applications.
Lock-in
The network effect can produce a lock-in:
- Facebook — competitors may have better software but lack the user base.
- Google search — competitors return worse results because they have fewer users.
- iPhone AppStore — other phones are cheaper but initially lack apps.
- Microsoft Windows/Office.
Network effect + lock-in = business model. (This is the standard exam sentence.)
4. Scalability, outsourcing, and “kaufen versus mieten”
Hockey-stick growth (Twitter example) breaks the buy-and-install model: ordering, delivering, and installing hardware takes too long, and a data center is not trivial to operate — for many companies a notwendiges Übel, aber keine Kernkompetenz. Hence: buy the service from a specialized provider (with Datenschutz as the key caveat).
The skier example (the reusable buy-vs-rent model):
- Ski kaufen: 500 EUR. Ski mieten: 50 EUR/Woche. The vacationer does not know how often they will ski.
- Offline strategy (decide up front): rent if duration < 10 weeks (crossover: 50·w = 500).
- Online strategy (decide as you go): rent 10 times, then buy — at that point rental cost equals the purchase cost.
- Worst-case loss vs the offline optimum: factor ≈ 2. Example: 9 weeks rented (450) then bought (500) = 950, while the offline optimum was 450 → 2.1×.
- Takeaway: renting is not always cheaper in total, but it bounds the possible loss. Startups: buying ties up capital they don’t have (yet); rental keeps the loss bounded and the capacity elastic.
5. Barely-visible forces: WWW, mobile devices, energy
Influence of the WWW
- Browsers are application platforms: HTML + CSS + JavaScript + HTTP.
- Browsers are limiting:
- Local storage exists but is limited, with no durability guarantees.
- Limited compute: JavaScript slower than C/C++/Java, no classic multi-threading, every computation may last only a few seconds — larger computations belong on the server.
- Weak at binary data: image/video processing is server-supported.
- Net effect: the WWW made servers important again.
Influence of mobile devices
- Network-capable (Edge, UMTS, WiFi, LTE), but energy is the limiting factor — progress in battery technology is small.
- Same effect as the WWW: offloading (Auslagerung) to servers.
Energy efficiency
Figures from the Sachstandsbericht des Bundestags 2021:
- 16 TWh electricity, up from 12.4 TWh in 2016; 10 TWh of it for servers/storage/network.
- Efficiency improves: overall efficiency in 2020 21% better than 2017.
- But demand for compute grows faster: servers needed 75% more electricity in 2020 than in 2010; the AI trend has a large influence.
- Share of total German consumption: 2.9%.
6. Terminology: “as a Service”
SaaS Software as a Service → the end user
PaaS Platform as a Service → the developer
IaaS Infrastructure as a Service→ the operator/sysadmin
DaaS Data as a Service
(+ Storage, Desktop, Games as a Service, … "es gibt noch mehr")| Model | What it provides | Examples | Who decides what |
|---|---|---|---|
| SaaS | an application to end users | Google Docs, Salesforce, Exchange hosted by Microsoft | application runs on cloud infrastructure; access via thin client (browser, mobile app); the user has no control over the infrastructure |
| PaaS | cloud infrastructure for developers to install and run applications | Google AppEngine, Heroku | programming language and frameworks must be supported by the provider; developer sets min/max resources; no infrastructure control |
| IaaS | rented machine instances | Amazon EC2, Rackspace | user installs arbitrary software and operating systems; rented limits: Rechenzeit, Bandbreite, Speicherkapazität; no control over switches/hardware |
Mixture of IaaS and PaaS (typical web architecture)
- PaaS layer: handles requests from web clients, scales very well, not suited for long-running computations → delegates long-running requests to the “backend”.
- IaaS layer: rented backend machines where the developer has full control (OS, services, application platform) for long-duration work — data mining, building search indices, application-specific databases.
- Caveat: IaaS does not scale automatically.
7. Deployment models (“wolkige Begriffe”)
- Public Cloud — offered to the general market.
- Private Cloud — dedicated to one organization.
- Hybrid Cloud — a combination of both.
- Community Cloud — a joint venture of several organizations, e.g. science (CERN) or public administration/police. Each user contributes a share (internal or external), costs are shared, fewer unused resources → lower costs.
8. Service Level Agreement (SLA)
A contractual agreement between provider and customer that unambiguously fixes goals, and that must be monitored at runtime (Monitoring).
Contract content:
- Service — e.g. email, storage.
- Ressourcen — storage capacity, accesses per hour, max bandwidth, max response time.
- Verfügbarkeit — e.g. 99.9% = 8.77 h downtime per year.
- Gewährleistung — refund/compensation if availability is worse.
- Support — weekdays only or weekends? Reaktionszeit of support staff.
SMART principle:
| Letter | German | Meaning |
|---|---|---|
| S | Spezifisch | unambiguous description |
| M | Messbar | monitoring must be able to check the SLA |
| A | Assignable | malfunctions must be clearly attributable to a causer |
| R | Realistisch | the SLA must be achievable in practice |
| T | Time-bound | services must be delivered within a time frame |
9. How the bill is computed
IaaS billing — sale of a virtual machine instance per hour:
- (Virtual) CPU time; number of cores per CPU; CPU is specified “vage” in GHz.
- Hauptspeicher in GByte.
- Netzwerk: throughput (GByte/second) and capacity (GByte per hour).
- Persistenter Speicher: GByte total or per instance; replication degree; backup guarantees.
PaaS billing — additional dimensions:
- Number of instances (Always On/Standby).
- Consumed (virtual) CPU time.
- Network with inbound vs outbound distinction.
- Persistent storage: total space, data written per month, replication degree.
- Database transactions performed.
- Emails sent/received; size of the Memcached cache.
Reference calculators: Microsoft Azure, Google AppEngine, Amazon EC2 pricing pages.
Exam hooks
- Classify a scenario into SaaS/PaaS/IaaS: “we only upload a Docker container / manage the OS” ⇒ IaaS; “we push code, the provider runs it, languages restricted” ⇒ PaaS; “we just use the app in a browser” ⇒ SaaS.
- Percent → hours: 99.9% availability ⇒ 0.1% × 8760 h = 8.76 h/year. 99.99% ⇒ ~53 min.
- Metcalfe vs Reed: pairs
n(n−1)/2(quadratic) vs subgroups2ⁿ(exponential). Do not swap them. - Name the network-effect direction: developer/user platform = two-sided; telephone/fax/social network = same-sided.
- Lock-in sentence: network effect + lock-in = business model; give a concrete example.
- Buy-vs-rent crossover arithmetic: rent if
rent_per_period × n < buy_price; state the operational strategy (offline vs online) and the bounded-loss argument. - SMART violations: an SLA that is not measurable (“fast response”) fails M; one that blames “the network” without attribution fails A.
- Why data centers: central data storage from the network effect (search-engine learning) is the causal chain, not “because cloud is modern”.
Sources
master-cs/raw/cloud-web-mobile/01_historie.md(converted from01_historie.pdf, 35 pages — History + Terminology block)- Course: Cloud, Web & Mobile · next: Data Centers and IaaS
- Cross-wiki: system design (scaling, cost curves), distributed systems