The Tower Under Every Click

How physics becomes chips, chips become clouds, and clouds become the software people simply open and use.

The machine that disappears

Tap the little triangle beside a song. Music begins.

The gesture is almost absurdly small. Your finger moves a few millimetres; a voice arrives from a slab of glass. You do not choose a storage device, locate a server, reserve bandwidth, or tell a processor how to reconstruct the sound. You ask for a song and the machinery disappears.

But it has not gone anywhere.

Somewhere, software recognizes the song and your right to hear it. A network finds a route. Machines retrieve and send the audio. Those machines live in guarded buildings that consume electricity and throw off heat. Inside them, processors move billions of electrical signals through patterns designed by other engineers. Those patterns were printed onto silicon using some of the most complicated machines humans have built—machines that can create extreme-ultraviolet light by firing lasers at droplets of tin until they become plasma.

What connects your fingertip to an exploding tin droplet inside a semiconductor fab?

Not one company. Not one machine. A tower of agreements.

Each floor says to the floor above: you may think in a simpler language now; I will handle the mess underneath. The music player thinks in songs, not packets. The network thinks in packets, not playlists. The server thinks in instructions, not user moods. The chip fab thinks in patterns, materials, and tolerances—not songs at all.

what you experience
        ↓
the song simply plays
        ↓
software, identity, catalog, delivery
        ↓
networks, platforms, cloud services
        ↓
data centers and servers
        ↓
processors, memory, storage, switches
        ↓
chip design, fabrication, packaging, test
        ↓
materials, equipment, electricity, cooling, fiber
        ↓
physical reality

Modern technology is a disappearing act. It advances not only by making new things possible, but by making yesterday’s difficult things stop demanding attention.

The useful sentence from the original study note is:

Everyone is a customer of someone underneath them.

A software company consumes a platform. A platform consumes cloud or operates infrastructure. A cloud provider consumes land, energy, fiber, hardware, construction, and semiconductor supply. A chip designer consumes specialized software, reusable design blocks, foundry capacity, packaging, and test. Near the bottom, “customer” turns back into physical constraint: nobody buys the laws of nature, but everyone obeys them.

This essay is about how the disappearing act works—what each floor hides, what it gives us in return, and why the hidden tower sometimes comes roaring back into view.

How does a machine disappear?

An abstraction is a bargain between two layers.

The lower layer says:

Use this smaller vocabulary. If you follow the contract, I will handle the machinery underneath.

A file system lets software talk about files and directories rather than magnetic sectors or flash cells. An operating system lets a program ask for memory without choosing physical RAM chips. A virtual machine looks like a computer even when many virtual machines share one server. A platform lets a developer say “build this repository” instead of describing every build host, process supervisor, certificate, routing rule, and deployment step.

A useful abstraction has four parts:

PROMISE
what the layer says it will provide

INTERFACE
the small vocabulary the consumer uses

IMPLEMENTATION
the hidden machinery that keeps the promise

OPERATOR
the person or company responsible when it does not

This last part is why a service is more than an abstraction. An instruction set is an abstraction between software and processors. A cloud VM is that kind of abstraction plus an operator, a billing relationship, an availability promise, a control plane, and support obligations.

In 1968, Edsger Dijkstra described a layered operating system in which each successful layer made some physical detail disappear from the reasoning of the layers above it. After processor allocation was abstracted, higher layers no longer cared which physical processor ran a process. After storage was abstracted, higher layers used logical segments rather than physical pages. The point was not merely tidiness. The smaller vocabulary made the system possible to reason about and test. The original paper is still remarkably readable.

The same move appears in modern hardware. The RISC-V specification describes the instruction set as a software-visible interface to many possible implementations. A processor can be simple or deeply out-of-order, physical or emulated, and software can still target the same architectural contract.

That is the trick: hold the interface steady while changing the machinery behind it.

Why one tower is not enough

The original note draws one line from physics to the consumer. That line is useful, but it quietly merges three different maps.

Keeping them separate makes the landscape much easier to reason about.

The execution stack

This answers: what must exist for the code to run?

physical effects and materials
→ transistors and circuits
→ processor architecture and chip
→ board and server
→ firmware and operating system
→ virtual machine or container
→ language/runtime/framework
→ application

The execution stack is technical. It describes how an instruction in source code eventually becomes physical state change in a machine.

The responsibility ladder

This answers: which party operates which parts?

on-premises
→ Infrastructure as a Service
→ Platform / Containers / Functions / Managed Data
→ Software as a Service

The responsibility ladder is contractual and operational. It tells you what the provider runs and what the customer must still run, configure, secure, and understand.

The supplier and customer chain

This answers: who depends commercially on whom?

equipment, materials, energy
→ semiconductor and hardware companies
→ data-center and cloud providers
→ platform providers
→ software companies
→ organizations and end users

This map is economic. It explains markets, margins, bottlenecks, bargaining power, and vertical integration.

The three maps often line up, but they are not interchangeable. SaaS does not have to be built on PaaS, and PaaS does not have to run on a third-party IaaS provider. A SaaS company might own servers. A platform might rent machines from AWS, operate colocation hardware, or use several clouds. A hyperscaler might design its own processors while still buying fabrication from foundries and equipment ecosystems below it.

NIST’s cloud reference architecture makes this explicit: SaaS-on-PaaS-on-IaaS is possible, but not required. The boxes describe kinds of service and responsibility, not a mandatory recipe.

How far down does one tap go?

Now we can descend without mixing the maps.

At the top: the thing a person wanted

At the top is the thing a person actually wanted.

They wanted to send a message, edit a document, check a balance, play a song, read an essay, or ask an AI system a question. They did not want to allocate memory, rotate TLS certificates, patch kernels, replace failed disks, or negotiate a power contract.

This is why SaaS feels like the end of the chain. The customer is buying the outcome rather than the machinery for building another technical product.

But “end” does not mean “no responsibility.” The user or customer organization still decides who gets an account, which data may enter the system, how the software fits into a business process, what configuration is safe, and what happens when the output is wrong.

The visible product is where lower-layer capabilities finally turn into human meaning.

One floor down: somebody made deployment boring

Below an application is often a platform.

On a modern web platform, publishing can feel like this:

edit a file
→ build
→ push Git commit
→ a new page appears at its domain

The simplicity is real. It is also manufactured.

Vercel’s build documentation describes an isolated environment that checks out code, applies framework conventions, installs dependencies, runs the build, and produces deployment output. Its routing and function primitives then turn those artifacts into reachable paths and executable services. Git integration connects branch pushes to preview or production deployments. The developer works in the vocabulary of repository, framework, route, function, domain, and deployment—not host, rack, switch, certificate process, or physical machine.

That is PaaS-like value in concrete form: a platform takes a recurring bundle of infrastructure and operations decisions, makes sensible choices, and exposes the smaller set of decisions application developers actually want.

The platform is not “fake infrastructure.” It is a product made out of infrastructure.

Where does the cloud actually begin?

A data center is not automatically a cloud.

A room full of servers becomes cloud-like when software turns its resources into a pooled, elastic, measurable service that customers can provision through defined interfaces. NIST’s canonical cloud definition names five characteristics:

1. on-demand self-service;
2. broad network access;
3. resource pooling;
4. rapid elasticity;
5. measured service.

The important transformation is not merely “the computer is elsewhere.” It is:

physical capacity
→ pooled and controlled by software
→ requested through an API
→ allocated on demand
→ metered and billed

NIST’s provider model shows three broad floors inside a cloud provider:

SERVICE LAYER
IaaS / PaaS / SaaS interfaces

RESOURCE ABSTRACTION AND CONTROL
VMs, virtual storage and networks, allocation, access, metering

PHYSICAL RESOURCES
compute, storage, network, hardware, facilities, power, HVAC

That middle floor—the control plane—is what the phrase “someone else’s computer” misses. Cloud providers built enormous software systems for inventory, placement, isolation, networking, metering, identity, policy, failure handling, and customer control.

They did not just put a web form in front of a server rack.

The cloud becomes a building

A data center is the point where software meets construction, power engineering, thermodynamics, telecom, security, and 24-hour operations.

The building needs utility power and distribution, backup power, cooling, fire detection, physical access control, fiber, racks, network equipment, spare capacity, monitoring, maintenance, and operating procedures. The ISO/IEC 22237 family treats availability, security, and energy efficiency as facility-level design concerns, while its operations guidance includes resilience, capacity planning, risk mitigation, and management over the facility’s lifetime.

Cloud regions then group facilities into geographic and failure boundaries. AWS, for example, documents Regions as separate geographic areas and Availability Zones as independent locations within them. Each Availability Zone contains one or more discrete data centers with redundant power and connectivity. The provider creates the zones; the customer still has to deploy across them if the application must survive a zonal failure. The infrastructure is available, but the architecture remains a choice.

This is our first important leak from the abstraction: the application can ignore buildings during normal operation, but geography, latency, regulation, capacity, and failure still reach upward.

The building becomes a machine

A server is not “a CPU in a box.” It is a coordinated system:

processors and accelerators
+ memory
+ storage and controllers
+ network interfaces
+ motherboard and buses
+ power conversion and cooling
+ firmware and management controller
+ operating system and drivers
= a machine capable of hosting useful computation

Even before cloud software touches it, the server hides layers of complexity.

An operating system multiplexes processors, memory, storage, and devices among processes. A hypervisor makes one server look like many computers. Linux KVM, for example, exposes virtual machines, virtual CPUs, and virtual devices through kernel interfaces. A container goes one level differently: it is an isolated process packaged with its required files, normally sharing the host kernel rather than carrying a full guest kernel. Docker’s own explanation notes that clouds often stack both: containers run inside virtual machines.

Kubernetes adds another abstraction. Instead of telling one machine to start one process, you describe a desired workload. Controllers repeatedly compare desired state with actual state and try to close the gap. That reconciliation loop is the hidden machinery behind a declarative promise.

The tower now looks like this:

server
→ virtual machine
→ container process
→ declarative workload
→ managed platform
→ application

Each layer gives the next one a more useful unit to think in.

The machine becomes a global industry

The original note says chips turn physics into computation. Correct. But “chips” is still hiding a remarkable supply chain.

The OECD’s 2025 semiconductor map separates four broad stages:

chip design
→ wafer production
→ front-end fabrication
→ assembly, testing, and packaging

Design needs electronic-design-automation software, reusable IP cores, and process-design kits. Fabrication needs wafers, gases, chemicals, photoresists, deposition, etching, cleaning, lithography, metrology, and inspection. The resulting wafer is not yet a usable product: dies have to be cut, packaged, bonded, and tested.

The business models split too:

• Fabless designers design chips and outsource manufacturing.
• Foundries manufacture designs for customers.
• OSAT companies handle outsourced assembly, test, and packaging.
• IP vendors sell reusable design blocks.
• Integrated device manufacturers own several or all major stages.
• System companies design chips for their own products or services.

TSMC’s pure-play foundry model is a clean example. It focuses on manufacturing customer designs rather than primarily selling a competing chip catalog. In 2025, TSMC reported manufacturing 12,682 products across 305 technologies for 534 customers. One “foundry” is already a vast platform for other chip companies.

ASML sits even lower in the visible chain—not making the chip, but making some of the machines that make advanced chips possible. Its EUV systems create 13.5 nm light by firing lasers at tiny tin droplets in vacuum, producing plasma, then steering the light with multilayer mirrors because EUV is absorbed by most materials. The physics is astonishing, but the business lesson is simple: the semiconductor layer is itself a stack of abstraction providers.

So “AMD is a customer of physics” is a good poetic sentence, but the engineering sentence is:

A fabless chip designer depends on a global system of EDA, IP, process knowledge, foundries, equipment makers, materials suppliers, packaging, testing, logistics, energy, and physical law.

The orange was really an aisle.

And then the service metaphor ends

At the bottom, the service metaphor stops.

Physical law is not a supplier. It does not promise an SLA. It simply constrains what every supplier can build.

Transistors work because semiconductor materials can be engineered so electrical behavior can represent and transform information. Signals take time to propagate. Resistance produces heat. Components fail. Light is absorbed or scattered. Energy must be supplied and waste heat removed.

Technology is not separate from nature. It is a hierarchy of carefully stabilized physical effects.

Now watch the tower disappear

We walked down by asking what the page depends on. Now reverse direction and ask what each layer provides.

Human outcomeread, communicate, decide, create, transact

Software / SaaSfeatures, accounts, workflows, content

Application platformdeployments, functions, databases, routes

Cloud servicesVMs, objects, networks, identities, queues

Resource controlscheduling, virtualization, isolation, metering

Data centeravailable compute, storage, network, resilience

Serverprocess execution, memory, I/O

Chip ecosystemprogrammable processors and accelerators

Physical substratematerials, energy, electromagnetism, heat

The higher layer does not merely add something. It changes the unit of thought.

The chip designer thinks in logical blocks and timing, not individual electrons. The operating-system programmer thinks in pages and processes, not DRAM cells. The cloud engineer thinks in instances and zones, not rack power rails. The application developer thinks in functions and deployments, not hypervisor scheduling. The user thinks in documents and messages, not functions.

This compression is why software can become so complex without every engineer becoming a physicist.

It is also why failures can be so confusing: when an abstraction leaks, a lower vocabulary suddenly returns.

Who wakes up at 3 a.m.?

The most intuitive way to separate the service models is not by memorizing boxes. Ask:

Who gets paged at 3 a.m. for this layer?

Something failed	IaaS	PaaS	SaaS
Physical host, facility, hypervisor	Provider	Provider	Provider
Guest operating system	Customer	Provider	Provider
Language/runtime platform	Customer	Mostly provider	Provider
Customer application code	Customer	Customer	Provider’s product team
Data classification and permitted use	Customer	Customer	Customer still owns its use
Users, identities, access, configuration	Customer	Customer	Customer/shared
Business outcome and correctness	Customer	Customer	Customer and provider, by context

The table follows Microsoft’s current shared-responsibility guidance, but the lesson is broader.

IaaS: “Give me a computer-shaped resource”

With IaaS, the provider handles the facility, host hardware, core network, and virtualization. You receive virtual compute, storage, and network primitives. You still choose and operate much of the guest environment and application.

This is high control because the abstraction is relatively low.

PaaS: “Give my application somewhere opinionated to live”

With PaaS, the provider operates more of the runtime and deployment machinery. You bring code and configuration. The platform chooses or constrains more of how that code is built, executed, routed, scaled, and observed.

This is not “less serious” engineering. It is engineering with a different boundary.

SaaS: “Give me the finished capability”

With SaaS, the provider builds and operates the application. The customer configures and uses it.

But responsibility does not become zero. Microsoft’s matrix still leaves the customer responsible for data, identities, users, access, and settings. A company using a payroll SaaS does not outsource the moral or legal decision of who should see payroll.

The missing middle is full of named services

Real catalogs contain many narrower forms:

• Containers as a Service;
• Functions as a Service / serverless;
• Database as a Service;
• Identity as a Service;
• Backend as a Service;
• Model as a Service;
• GPU as a Service;
• observability, messaging, search, and storage services.

These names all express the same move:

Take a capability I would otherwise build or operate and turn it into an interface backed by someone else’s operating work.

The boundaries overlap because products bundle differently. The useful question is not “which acronym wins?” It is:

Which decisions and failures have moved from my team to the provider, and which remain mine?

Why hyperscalers feel like universes

AWS, Azure, and Google Cloud are often introduced as places to rent servers. Their product catalogs reveal a much larger ambition.

Across the three, the recurring categories include:

• general and accelerated compute;
• object, file, block, archive, and backup storage;
• virtual networks, DNS, load balancing, CDN, and edge;
• relational databases, NoSQL, cache, analytics, and warehousing;
• identity, keys, secrets, security, policy, and compliance;
• containers, serverless, integration, queues, and event streams;
• build, deployment, infrastructure automation, logs, metrics, and traces;
• data engineering, search, AI training, models, inference, and agents;
• hybrid, multicloud, migration, end-user, and industry services.

See the current catalogs for AWS, Azure, and Google Cloud.

They overlap because each wants to become the default programmable substrate under a company’s digital work. The strategic prize is not one VM sale. It is being the layer on which databases, applications, analytics, AI, identity, operations, and future platforms are assembled.

The CNCF cloud-native landscape shows what happens inside and around that substrate: provisioning, runtime, orchestration, application definition, delivery, storage, networking, service discovery, gateways, observability, security, and platforms that bundle these pieces. The landscape is enormous because “run an application reliably” is not one problem.

Every provider is also a customer

A SaaS company sells upward and buys downward. So does a platform. So does a cloud provider.

end user
  buys from software company
software company
  buys from platform / cloud / data / identity providers
platform provider
  buys compute, storage, network, colocation or cloud
cloud provider
  buys land, energy, fiber, hardware, construction, chips
chip company
  buys EDA, IP, foundry, equipment ecosystem, materials, packaging

This recursion explains why outages and price changes propagate. A dependency three companies down can become a user-visible incident at the top.

It also explains vertical integration.

Why companies move down the stack

“Everyone is a customer until they build that layer themselves” is a good first model of vertical integration.

AWS began by buying general-purpose processors and building cloud software around them. It now designs Graviton CPUs, Trainium and Inferentia AI accelerators, and Nitro hardware/firmware for virtualization and I/O. Google designs TPUs and the surrounding software stack. Microsoft is deploying its Maia accelerators within Azure.

These companies have not escaped the supply chain. Their chips still require architecture/IP choices, EDA, foundry manufacturing, packaging, equipment, materials, and facilities. But they have moved the design boundary downward.

Why do that?

• a lower layer has become a large cost;
• generic suppliers are not optimized for the workload;
• control over roadmap or supply is strategically important;
• hardware and software can be co-designed;
• differentiation at the upper layer now depends on the lower layer.

AWS describes Trainium as a full-stack co-design across chip, server, network, SDK, orchestration, and managed service. That is vertical integration in one sentence: optimize across interfaces that were previously company boundaries.

Why not own everything?

• capital intensity;
• need for rare expertise;
• slower organizational coordination;
• ownership of more operational failure;
• loss of supplier competition;
• risk that an internal layer falls behind the market.

The right depth is strategic, not moral. Owning more is neither inherently superior nor inherently foolish.

The price of convenience

Moving upward in abstraction normally buys speed and reduces undifferentiated work.

You can launch sooner. Hire a smaller specialist team. Inherit patching, scaling, failover mechanisms, and security controls. Operate in a vocabulary closer to the product.

But every abstraction makes choices on your behalf.

You may lose low-level control. You may inherit quotas, pricing units, regional limitations, runtime constraints, provider-specific APIs, or a roadmap you do not control. Performance can become harder to explain. Switching providers can require changing assumptions embedded throughout the application.

This is not a defect in abstraction. It is the bargain.

lower abstraction
  more control, more choices, more operating burden

higher abstraction
  fewer choices, faster use, more inherited behavior

The better decision question is:

Which layers create distinctive value for us—and which are merely expensive chores somebody else can perform better?

When the hidden tower comes back

An abstraction lets you ignore details during ordinary operation. It cannot repeal the conditions underneath it.

Joel Spolsky called this the law of leaky abstractions. His examples are old; the principle is not.

A managed database hides storage layout until a query becomes unexpectedly slow. A serverless function hides machines until cold starts, duration limits, or regional capacity affect the user. A cloud object store hides disks until consistency, request rates, permissions, or egress cost matter. A CDN hides distance until content cannot be cached. A platform hides networking until a private database is in the wrong region.

The lower layer tends to return under five conditions:

1. Failure: a dependency is unavailable or only partly available.
2. Performance: latency, throughput, memory, or locality matters.
3. Scale/cost: the provider’s unit economics stop matching yours.
4. Security/compliance: you need to know where data and authority actually flow.
5. Change/exit: you need to move, replace, or debug the provider.

This gives a better learning rule than “always learn everything underneath first.”

Learn the abstraction deeply enough to use it well. Learn the next layer down when performance, failure, security, cost, or change makes that layer relevant.

Abstractions save working attention. They do not eliminate the value of depth.

The Internet is not the cloud

Cloud and Internet are often treated as synonyms. They are different.

The Internet is a network of networks and a layered protocol system. RFC 1122 separates link, Internet, transport, and application layers. IP moves datagrams without promising end-to-end delivery; TCP builds a reliable ordered stream over that weaker service; applications build higher semantics over transport.

DNS turns a distributed naming system into a resolver interface. HTTP gives clients a uniform way to request and manipulate resource representations without knowing how those resources are implemented. HTTP’s current semantics specification explicitly describes this information hiding as a way for clients and servers to evolve independently.

Cloud services are reached over networks and often over Internet protocols. The network is a supporting abstraction stack of its own.

When a browser opens any cloud-hosted application, the cloud has not replaced DNS, TLS, IP, routing, fiber, or the browser. Those layers collaborate.

Where Microsoft Foundry fits

The seed note correctly leaves Microsoft Foundry as a marker for a later lesson. We can now place it precisely.

As of August 2026, Microsoft Foundry is Microsoft’s current unified Azure platform for building, optimizing, and governing generative-AI applications and agents. It brings models, agents, tools, tracing, evaluations, safety, RBAC, networking, and policy into a managed development and governance experience.

Its position is:

physical facilities and hardware
→ Azure resource and control infrastructure
→ Azure compute, network, identity, storage, search, secrets
→ Microsoft Foundry models, agents, evaluation, governance
→ your application or business workflow
→ your user

Foundry is not “inside Office,” and it is not “above Azure” in the corporate sense. It is a higher-level building platform implemented using Azure resources and connected services.

The Foundry architecture documentation is also a useful warning against drawing one magic box. Storage, Key Vault, and AI Search can remain separate Azure resources with their own network, identity, and governance boundaries. The platform provides a more coherent interface; it does not collapse the underlying systems into one object.

This is abstraction in its mature form: a simpler front door into a still-modular building.

How to read any technology company

When you encounter a company, service, or acronym you do not understand, do not start by memorizing its marketing category. Ask five questions.

1. What does it consume?

Does it consume chips, VMs, container clusters, model APIs, data, payment rails, developer code, or finished user input?

This identifies the layer below it.

2. What does it package?

Does it package computation, deployment, identity, data storage, messaging, model inference, a workflow, or a finished business outcome?

This identifies the abstraction it provides.

3. What is the interface?

Is the customer using instructions, an API, a deployment manifest, a Git push, a dashboard, a prompt, or a finished UI?

This tells you the vocabulary the product wants the customer to think in.

4. What responsibility did it remove—and what remains?

Who patches? Who scales? Who backs up? Who configures access? Who is paged? Who owns the data and the outcome?

This reveals the real service boundary.

5. Where does it leak?

When do cost, latency, failure, geography, security, portability, or provider limits force the customer to understand the machinery underneath?

This reveals how deep you eventually need to learn.

With those five questions, most technology landscapes stop looking like a wall of company names. They become a set of repeated moves:

consume a lower capability
→ stabilize and operate it
→ expose a smaller interface
→ sell or provide it upward

The map, if you want the whole thing

The essay stayed narrative. This section makes the coverage visible.

Physical and semiconductor floor

• Common land, buildings, electrical grid, backup power, cooling/water, fiber;
• Common materials, wafers, specialty gases/chemicals, packaging materials;
• Often hidden EDA, IP cores, PDKs, lithography, deposition, etch, metrology, inspection, OSAT.

Machine and execution floor

• Common transistor, logic, ISA, CPU/GPU/accelerator, memory, storage, network;
• Common server/board/rack, firmware/BMC, operating system, drivers;
• Common hypervisor/VM, container, orchestrator, language/runtime/framework;
• Frontier confidential computing, custom accelerators, optical interconnect, quantum.

Facility and network floor

• Common data center, region/AZ, backbone, carrier, DNS, TLS/certificates, CDN/edge;
• Often hidden capacity planners, facility operators, spares, maintenance, physical security, time synchronization.

Cloud and platform floor

• Common resource pooling, scheduler, metering, identity, policy, control plane, observability;
• Common IaaS, PaaS, CaaS, FaaS/serverless, DBaaS, storage/identity/model services, SaaS;
• Common public, private, community, hybrid, multicloud, edge;
• Often hidden broker, carrier, auditor, procurement, billing, contracts, compliance, exit plan.

Application and human floor

• Common code, data model, API, product UI, business workflow, support;
• Customer-owned identities, configuration, data use, process correctness, human outcome;
• Residual embedded/industrial control, telecom operations, grid engineering, quantum systems, and regional providers require their own deeper maps.

Audit line

The map was checked against the OECD semiconductor value chain; NIST/ISO cloud service and reference architectures; RISC-V execution environments; RFC 1122 Internet layers; the CNCF provisioning/runtime/orchestration/application/observability landscape; and AWS/Azure shared-responsibility models.

The source note already had the correct tower. The anchor diff added the missing joints: EDA and semiconductor equipment; foundry/OSAT business models; firmware, ISA, virtualization, containers, and orchestration; DNS/carriers/CDN; cloud brokers and auditors; control planes and metering; shared responsibility; platform bundles; and the ways abstractions leak.

The remaining residue is deliberate. This is a map of the modern networked-software dependency and abstraction stack, not every technology domain.

The one sentence to keep

If the whole essay collapses in memory, keep this:

Every technology layer takes a complicated capability from below, operates and stabilizes it, exposes a smaller vocabulary above, and leaves the customer with a new boundary of control and responsibility.

That sentence explains chips, operating systems, clouds, platforms, APIs, AI services, and SaaS.

And it explains the tower under every click.

Where this map came from

The report used primary standards, specifications, official architecture material, and original systems writing. Core anchors: OECD semiconductor mapping; NIST SP 800-145; NIST SP 500-292; ISO/IEC 22123; RISC-V ISA; RFC 1122; CNCF landscape guide; Azure and AWS shared responsibility.

Product examples were checked against current official material for TSMC, ASML, Vercel, AWS, Azure, Google Cloud, and Microsoft Foundry as of August 2026. Vendor examples show how the abstraction pattern appears in practice; they are not rankings or endorsements.

The semiconductor and cloud landscapes are much deeper than one essay can descend without becoming several books. This map aims for conceptual completeness at a useful depth, then names the branches that need their own specialist maps.