Renting the Wizard’s Tower: Understanding Cloud Infrastructure

Owning every stone is not the same as controlling the kingdom.

In the previous chapter of The Kingdom in the Clouds, Kubernetes provided a way to coordinate workloads across multiple machines. Pods could be replaced, deployments could maintain the desired state, and services could provide changing workloads with stable ways to communicate. That solved an important orchestration problem, but it left a deeper question unanswered: where do those machines come from, who maintains them, and how much responsibility should belong to the team running the application? Every container eventually consumes real processor time, memory, storage, and network capacity somewhere. Cloud infrastructure begins with the recognition that those resources have not disappeared simply because engineers no longer stand beside the hardware providing them.

Traditional infrastructure made ownership easy to see. Organizations purchased servers, provisioned storage, connected networks, installed operating systems, replaced failed components, and planned capacity before existing equipment reached its limits. That model offered substantial control, but the same control brought responsibility for hardware, power, cooling, security, patching, networking, storage growth, and recovery. Owning the castle meant deciding how every room was built, but it also meant repairing every roof when winter arrived.

Cloud computing changes that arrangement by separating ownership from useful control. Instead of purchasing all the physical infrastructure required to run software, organizations consume resources provided by others and interact with them through services, APIs, and configuration. The processors, disks, networks, and data centers remain physical, but application teams no longer need to own or operate all of them directly. Engineers can request capacity, change it as workloads evolve, and release it when it no longer provides value. The architectural shift is broader than moving servers into someone else’s data center, because infrastructure itself becomes something teams can provision through software.

The Tower Still Has Stones

It is tempting to describe the cloud as a place, since phrases such as “moving to the cloud” make the transition sound geographical. Applications still execute on computers inside physical facilities that require power, networking, cooling, maintenance, and security. The meaningful difference is the operating model surrounding those resources. Cloud providers own and operate enormous pools of infrastructure, while customers consume portions of that capacity through standardized services rather than constructing the physical foundation themselves.

That model changes assumptions that shaped traditional infrastructure. Servers no longer necessarily begin with purchase orders and weeks of procurement; environments can often be created through configuration and removed when their work is finished, and capacity can expand without engineers installing hardware. This programmability also changes how individual machines should be treated. Physical servers naturally became long-lived assets worth preserving, while cloud resources can often be replaced from a known configuration when they become unhealthy. The shift is not simply from physical machines to virtual ones, but from infrastructure that must be preserved to infrastructure that can increasingly be recreated.

Renting Compute Instead of Buying Servers

Compute is the most familiar place to begin because virtual machines still resemble the servers engineers already understand. A cloud provider allows a team to request processor capacity, memory, storage, an operating system, and network connectivity without purchasing the underlying physical host. Processes still consume memory, software still listens on ports, and operating systems still need configuration. What changes is how the machine is acquired and how much of the machinery beneath it belongs to someone else.

Consider a team that needs additional capacity for an API. In a traditional environment, that request might involve budgeting, purchasing, shipping, rack space, networking, operating system installation, and security preparation. In a cloud environment, the same conceptual resource can be described programmatically:

resource "example_instance" "api" {
  image         = "ubuntu"
  instance_type = "4cpu-16gb"
  region        = "west"

  tags = {
    service = "orders-api"
  }
}

The configuration language is less important than what it represents. Infrastructure has become sufficiently describable that its creation can be automated, reviewed, repeated, and versioned alongside other engineering decisions. A server can now be the reproducible result of configuration rather than an individually maintained artifact. Fast provisioning does not remove the need for governance, however, because every instance still has a cost, security boundaries, network relationships, software, logs, and ownership. The cloud reduces the friction of obtaining infrastructure more effectively than it reduces the need to manage it well.

The Kingdom’s Storehouses

Storage undergoes a similar transformation. Applications need durable state for databases, uploaded files, backups, logs, artifacts, and many other forms of information. Traditional systems often tied those needs to physical disks or storage appliances whose capacity and redundancy had to be planned in advance. Cloud platforms instead expose multiple storage abstractions, shifting the engineering task from selecting hardware to choosing the storage model that best matches the data.

Block storage behaves much like a disk attached to a machine, shared file storage allows multiple systems to work with familiar directories and files, and object storage organizes data as independently addressable objects suited to assets, backups, documents, and media. All three can hold bytes, but they differ in access patterns, consistency, performance, durability, scaling behavior, and cost. Providers make these capabilities easy to request, but ease of creation does not make them interchangeable. The engineer’s responsibility shifts upward from assembling machinery to understanding the guarantees and trade-offs of the abstraction being consumed.

Moving the Castle Is Not the Same as Changing the Kingdom

Many organizations begin their cloud journey by recreating infrastructure they already know. Physical servers become virtual machines, familiar network boundaries are reconstructed, applications are installed much as they were before, and existing operational processes follow them into the new environment. This lift-and-shift approach can be sensible when systems cannot be redesigned during migration, legacy assumptions are expensive to change, or business deadlines make relocation more urgent than modernization. Trouble begins when a migration strategy becomes the permanent definition of cloud architecture.

Ten manually maintained servers do not become a fundamentally different system merely because they now run as rented virtual machines. An organization may avoid physical hardware management and gain faster provisioning while retaining configuration drift, fragile machines, manual deployments, static capacity, and old operational dependencies. The location changed while much of the architecture remained untouched. The deeper opportunity appears when engineers stop asking only where infrastructure should run and begin asking which responsibilities should remain theirs at all.

That question leads to Infrastructure as a Service, Platform as a Service, Software as a Service, and the growing landscape of managed cloud services. Each moves the responsibility boundary between provider and customer. Some preserve substantial control while delegating physical infrastructure, while others transfer responsibility for runtimes, platforms, databases, or complete capabilities. The useful architectural question is not which acronym sounds most modern, but which parts of the system are valuable for us to control, and which parts are merely expensive for us to own.

The Price of Control

Infrastructure as a Service sits closest to the traditional server model because the engineering team still controls much of the environment above the provider’s physical hardware. The provider usually owns the data center, physical servers, storage hardware, core networking, power, cooling, and virtualization layer. The customer still chooses operating systems, configures network access, installs software, manages credentials, and operates the applications running on those machines. That arrangement preserves flexibility while removing the burden of owning the physical equipment underneath it.

The remaining responsibility is significant. Every layer an organization chooses to control becomes another layer it must secure, monitor, update, troubleshoot, and recover. A virtual machine can run almost anything, which is precisely why the team may become responsible for nearly everything needed to keep it useful. Specialized networking, unusual operating system requirements, specific hardware, or custom middleware can justify that level of control. Using lower-level infrastructure only because it feels familiar is a weaker reason.

Own the layers that differentiate your system, and be suspicious of the layers you operate only because you always have.

The Prepared Workshop

Platform as a Service moves the responsibility boundary upward. Instead of receiving a mostly empty machine, the team receives a platform designed to run applications according to a supported model. The provider may manage the operating system, runtime, patching, process supervision, deployment mechanics, health monitoring, and portions of scaling and networking. Developers focus more directly on application code and configuration, while the platform handles much of the underlying machinery.

A platform deployment might require only a compact description of the application:

application:
  runtime: node
  version: 22
  replicas: 3

environment:
  NODE_ENV: production

The syntax is not the lesson. What matters is that the team has stopped describing individual machines and started describing the environment the application requires. The platform decides how some of those requirements become part of the running infrastructure. That abstraction can remove substantial operational work when the application fits the platform’s model.

The tradeoff is constraint. Managed platforms often limit operating system access, supported runtimes, networking behavior, deployment patterns, or storage choices. Those limits are not inherently weaknesses because they often enable automation and standardization. The architectural question is whether the platform’s constraints support the application’s needs or continually work against them. A useful abstraction should reduce complexity rather than merely hide it in an inconvenient place.

Buying the Capability

Software as a Service moves the boundary farther upward. Instead of renting infrastructure or a development platform, the organization consumes a completed capability operated by another company. Email, source control, issue tracking, collaboration tools, identity systems, monitoring platforms, and many other services can be delivered this way. The customer still configures the service and governs its use, but the underlying application architecture and infrastructure largely belong to the provider.

This can be uncomfortable for engineering cultures that value building things themselves. Engineers can create internal authentication systems, artifact repositories, monitoring stacks, and other tools, but capability alone does not make ownership worthwhile. Every internal platform becomes a product that requires upgrades, security work, documentation, monitoring, backups, support, and long-term ownership. When a reliable external service solves a problem that does not differentiate the business, purchasing that capability may create more value than maintaining another internal system.

SaaS introduces different risks rather than eliminating them. The organization becomes dependent on vendor pricing, availability, data policies, product direction, and integration boundaries. A provider can change an API, remove a feature, increase prices, or suffer an outage. The tradeoff is therefore not between dependence and independence. It is between different forms of responsibility.

The Ladder Is Really a Boundary

IaaS, PaaS, and SaaS are often shown as three boxes in a diagram, but the more useful mental model is a moving boundary of responsibility between provider and customer. Moving toward higher-level services generally means the provider assumes responsibility for more of the stack while the customer controls fewer underlying layers. Moving toward lower-level services provides greater flexibility while returning more operational work to the engineering organization. Neither direction represents technical maturity by itself.

Good architecture places that boundary according to the system’s requirements, the organization’s expertise, security obligations, cost structure, expected scale, and operational capacity. The same application may reasonably combine several models. A customer-facing service might run on a managed platform while specialized processing uses virtual machines and the engineering team relies on hosted source control. Each component deserves a responsibility boundary that reflects the work it actually needs.

Team capability matters as much as technology. A small engineering group may gain enormous leverage by delegating database operations, deployment platforms, and messaging infrastructure to providers. An organization with specialized infrastructure expertise may reasonably choose lower-level services when greater customization creates enough value. Architecture always exists within constraints, and the ability to operate a system reliably is one of them.

Managed Services and the Work You Choose Not to Do

Modern cloud platforms blur the traditional service categories by offering managed versions of increasingly complex infrastructure. Databases, message brokers, caches, search clusters, Kubernetes control planes, content delivery networks, observability systems, identity services, and analytics engines can all be consumed without having to operate every layer beneath them. These services are attractive because many infrastructure problems are difficult in ways that have little to do with the product an organization is trying to build.

A production database, for example, needs backups, recovery procedures, monitoring, replication, patching, storage management, security, and capacity planning. A managed database can absorb much of that operational burden while leaving the engineering team responsible for schemas, queries, indexes, access patterns, data governance, and application behavior. The machinery becomes less visible, but the need for database engineering remains. Managed services remove categories of maintenance, not the need for technical understanding.

The same principle applies elsewhere. A managed message broker may remove cluster administration while leaving the application responsible for retries, duplicate messages, ordering assumptions, and consumer failures. A managed Kubernetes service may operate the control plane while workload configuration, scaling decisions, security policies, and application reliability remain with the customer. Good abstraction moves responsibility to the layer where it can be handled more effectively rather than pretending that responsibility has disappeared.

Shared Responsibility Is the Real Contract

That division of work becomes explicit through the shared responsibility model. Cloud providers generally protect the physical facilities, hardware, core networking, power, cooling, and infrastructure used to deliver their services. Customer responsibility begins above that foundation and moves according to the service being consumed. With a virtual machine, the customer may still own operating system patches, installed software, firewall rules, credentials, application security, and data protection. With a managed database or SaaS product, more of the technical stack moves to the provider, but important responsibilities remain with the customer.

Those remaining responsibilities commonly include users, permissions, configuration, application behavior, access policies, and data handling. A provider can secure its physical infrastructure, while a customer exposes a storage resource through poor configuration or by granting excessive privileges to an application account. Both can be true at the same time. The provider can fulfill its responsibilities while the customer’s system remains insecure.

Shared responsibility should therefore be understood during design rather than discovered during an incident. Engineers need to know which layers the provider protects, which layers their organization protects, and where configuration choices can move risk across that boundary. The safest assumption is not that a managed service eliminates responsibility. The better assumption is that every abstraction relocates responsibility, and the engineer’s job is to identify where it went.

Cloud Economics Changes the Architecture

Once infrastructure becomes something an organization rents rather than owns, costs begin to behave differently. Traditional infrastructure concentrates much of its expense at the beginning, when servers, storage, and networking are purchased and expected to provide value for years. Cloud services shift more of that expense into ongoing consumption, so architecture directly influences the monthly bill. Compute, storage, network traffic, managed services, availability, and geographic redundancy all carry measurable costs. The cloud makes infrastructure easier to acquire, but it also makes poorly governed infrastructure remarkably easy to keep paying for.

That changes how engineers should compare solutions. A system designed for the largest imaginable workload may waste money during ordinary operation, while one optimized too aggressively for minimum cost may fail when demand rises. Managed services can appear more expensive than equivalent software running on virtual machines, yet still reduce total cost by eliminating patching, backups, recovery, replication, and specialist labor. Engineers should evaluate direct service costs alongside operational work, staffing, reliability requirements, and failure consequences. The cheapest resource is not necessarily the cheapest architecture.

The Convenience Tax

Managed cloud services also create dependency. The more deeply an application relies on provider-specific databases, messaging systems, identity platforms, deployment models, networking features, or proprietary APIs, the harder it may be to move that application. This is commonly described as vendor lock-in, although eliminating dependency altogether is rarely realistic. Every production system depends on languages, frameworks, databases, protocols, vendors, and the expertise of the people maintaining it.

The more useful question is whether the value gained from a dependency is worth the cost of changing it later. A provider-specific service may eliminate months of infrastructure work and give a small team capabilities it could not economically build or operate on its own. Wrapping every service behind elaborate abstractions merely to preserve theoretical portability can create more complexity than the dependency itself. Portability should be treated as a requirement only when the business actually needs it, whether due to regulation, geographic restrictions, negotiating leverage, disaster recovery strategy, or unusually long system lifetimes.

Other systems may reasonably accept stronger provider dependency because delivery speed, reliability, or reduced operational burden matters more. What matters is that the trade is deliberate. Experienced engineers understand what they are gaining, what they are giving up, and what migration would cost if the decision ever needs to be reversed.

Design for the Cloud You Actually Need

The earlier chapters in this series made workloads progressively more portable and easier to replace. Containers reduced environmental differences, Docker Compose showed how services could be described together, and Kubernetes taught us to think in terms of desired state, scheduling, replacement, and orchestration rather than attachment to individual machines. Cloud infrastructure extends those ideas beneath the application, as compute, storage, networking, and managed services can be provisioned programmatically. The result is powerful, but power should not be confused with necessity.

A modest business application may run successfully for years on a few virtual machines and a managed database. Another system may genuinely require containers, autoscaling, queues, caches, multiple regions, distributed storage, and specialized managed services. The quality of the architecture is not measured by the number of cloud products on its diagram. It is measured by whether the infrastructure satisfies the system’s actual requirements without imposing unnecessary complexity.

That restraint matters because cloud platforms make sophisticated infrastructure deceptively easy to create. Engineers can provision globally distributed services, managed Kubernetes clusters, streaming platforms, replicated databases, and elaborate network topologies in an afternoon. Every new service, however, introduces behavior that someone must understand, security boundaries that someone must protect, costs that someone must monitor, and failure modes that someone will eventually encounter. The cloud lowers the barrier to creating infrastructure, so engineering judgment must become the barrier against creating infrastructure without a reason.

A sound cloud design, therefore, begins with the application rather than the provider’s catalog. Determine the system’s actual requirements for availability, durability, performance, security, geographic reach, scalability, recovery, and operational support. Then choose the simplest infrastructure that satisfies those requirements with acceptable trade-offs. A good architect should be able to explain why each significant component exists and what would become worse if it were removed.

What the Guild Should Own

The most important cloud decision is often deciding where the organization’s engineering effort creates unique value. Few companies gain a competitive advantage because their developers are unusually good at patching undifferentiated servers, operating storage arrays, or maintaining internal versions of infrastructure that reliable providers already offer. Those activities may be necessary, but necessity and habit should not be confused.

Engineering teams should retain ownership where control produces meaningful value. The application’s domain model, business rules, security requirements, customer experience, integration strategy, and critical architectural decisions usually deserve direct attention because they express what the organization is actually building. Beneath those layers, every additional responsibility should justify itself. Sometimes that answer will be a virtual machine, while other times it will be a managed database, message broker, platform, or hosted application.

This protects one of the scarcest resources in software engineering: attention. Teams can operate only so many systems well, and every database cluster, deployment platform, authentication service, monitoring pipeline, server fleet, and networking layer consumes cognitive capacity long after its first deployment. Delegating infrastructure responsibly allows engineers to spend that capacity on the problems that distinguish their product while still understanding the guarantees and failure modes of the services they depend on. The lesson is not that engineers should surrender control. It is that control should be purchased deliberately.

Choosing Which Stones Matter

Cloud computing is not the disappearance of infrastructure. It is a different way of deciding who owns it, who operates it, and which parts remain under direct control. IaaS allows teams to retain substantial control while delegating physical infrastructure. PaaS transfers more responsibility for the runtime environment. SaaS allows organizations to consume complete capabilities, while managed services move the same boundary across databases, queues, caches, orchestration systems, identity platforms, and other parts of modern software.

The engineering judgment underneath all of those choices is consistent. Retain responsibility where control creates meaningful value, and delegate responsibility where another layer can perform the work more effectively. Understand the operational, economic, security, and portability consequences of both decisions. Most importantly, never mistake delegated responsibility for eliminated responsibility.

That is the real meaning of renting the wizard’s tower. You may not own the stones beneath your feet, repair the roof, or know which quarry produced the foundation. You still remain responsible for what you build inside, who receives the keys, how valuable assets are protected, and whether the tower is suitable for the work your guild intends to perform. Ownership has changed, but engineering judgment has not.

This week’s theme in The Kingdom in the Clouds is Building Above the Clouds, and cloud infrastructure provides the kingdom with a foundation that no longer needs to be entirely owned to remain under deliberate control. We have moved from portable workloads to orchestration and now to infrastructure that can be consumed as a service. On Wednesday, we continue with The Castle That Appears on Command: Serverless Architecture, where we push that idea further by asking whether some application infrastructure needs to remain provisioned at all.

Sometimes the next tower does not need to stand waiting for us. Sometimes it only needs to appear when the work begins.