There was a period when the cloud felt not just inevitable, but virtuous. Infrastructure could be abstracted away from place, capacity could appear when needed, and entire categories of operational work could be handed to organizations better equipped to perform them. Hardware failures, geographic redundancy and capacity planning didn't disappear, but increasingly they became someone else's problem.

For a while, that trade paid enormous dividends, and it still does. Small teams can build systems that would once have required substantial capital and specialized staff. Services can expand geographically without opening data centers. Hardware can fail without anyone from the application team replacing a disk. A company can discover that it suddenly needs ten times the capacity without first discovering that delivery on ten new servers takes six weeks.

That's progress. I have no desire to give it back.

What has become more interesting to me is what happens when the abstraction itself becomes part of the failure.

A service disappears. An account is suspended. A provider changes a price, policy or interface. A network path fails between otherwise healthy systems. An automated enforcement process makes a decision that is later reversed. The provider may behave exactly as its contract specifies, and the eventual resolution may even be correct, while the organization depending on it remains unable to operate in the meantime.

The distinction is temporal.

A correction tomorrow doesn't necessarily preserve continuity today.

That isn't peculiar to cloud computing. We encounter the same problem whenever action and adjudication operate at different speeds. Financial systems can freeze a transaction immediately and investigate it later. Automated moderation can remove something immediately and restore it after review. Security systems can revoke access in milliseconds while determining whether the revocation was justified takes considerably longer.

There are good reasons for this asymmetry. If a system detects what appears to be an active compromise, we probably don't want it to convene a committee before disabling the credential. Sometimes precautionary action has to be faster than complete understanding.

The question is what happens during the interval if the precaution was wrong.

That becomes an architectural concern when the affected service is something an organization can't operate without. An appeal process may eventually restore access, but an appeal process isn't a continuity mechanism. A service credit may compensate for an outage without restoring the transactions that couldn't happen during it. Correctness after the fact preserves something different from availability during the event.

Once I started looking at infrastructure this way, the distinction between owned and rented systems became less important to me than the distinction between dependencies and failure boundaries.

A machine I own can fail.

A service I rent can fail.

My own configuration can lock me out just as effectively as someone else's automated enforcement system. A local network can disappear while a remote service remains perfectly healthy, and a remote provider can become unreachable while everything in the building continues working.

Ownership changes who has authority to respond. Geography changes which failures are likely to happen together. Redundancy changes what can disappear without interrupting service. Contracts change who bears certain costs afterward.

Those are different properties, and collapsing all of them into local versus cloud doesn't tell me enough.

This has changed how I think about the cloud's role in systems I build. I like a locally controlled steady state with outside infrastructure available for things such as geographic separation, backup, additional capacity and services that would be wasteful to reproduce ourselves. For that particular architecture, a useful shorthand is: own the steady state, rent some of the volatility.

I wouldn't make that a universal rule.

A small company may be considerably more resilient running entirely on a mature cloud platform than maintaining hardware nobody on the team knows how to repair. Another organization may have stable workloads, available local infrastructure and enough operational experience that paying indefinitely for elastic capacity it rarely uses makes little sense. A service with highly variable global demand has different requirements from a regional newspaper whose ordinary workload is relatively predictable.

The architecture should follow the failure we're trying to survive.

That means asking more specific questions about every important dependency. If this service disappears, what stops? How long can it remain unavailable before the interruption becomes serious? Can we operate in a reduced mode? Is the data somewhere else? Can another component assume the work? How long would that transition take? Who has the authority to make it happen?

Sometimes the answer will justify redundancy. Sometimes the cost of redundancy will exceed the cost of simply waiting for the service to return.

That's intentional dependency.

It doesn't require pretending we can become independent. Even a server sitting in my own building depends on electricity, replacement hardware, networking equipment, software maintained by people I've never met and supply chains extending far beyond anything I control. Moving something on premises doesn't eliminate abstraction. It changes which abstractions I'm responsible for operating.

Modern infrastructure tools make those choices easier than they once were. Containers can reduce differences between environments. Declarative configuration can make systems easier to reproduce. Common protocols can make data easier to move. Automation can reduce the amount of knowledge that has to remain in one person's head.

None of those guarantees portability.

A containerized application can still depend deeply on a provider's identity system, networking model, storage semantics, managed database or proprietary APIs. Two Kubernetes clusters can look superficially similar while the services surrounding them make migration difficult. A backup stored in another provider may be wonderfully portable until we discover that the recovery procedure depends on credentials or configuration that disappeared with the original environment.

Portability has to be tested the same way redundancy does.

Can we actually move it?

Can we restore it?

Can we operate it there?

How long does that take?

The answers matter more than the architecture diagram.

This is also why I don't think the cloud failed or exceeded some objectively correct domain. We learned more about the trade.

Abstraction makes extraordinary things possible because it lets us stop caring about details that someone else can handle better. Every abstraction also creates a boundary beyond which our own authority becomes limited. Usually that's exactly why we bought it.

The mistake is forgetting the boundary exists.

If an outside service provides something we can comfortably lose for an hour, a day or even a week, dependence on it may be entirely reasonable. If losing it for five minutes threatens the organization, I want to understand that dependency considerably better. Perhaps we need redundancy. Perhaps we need a degraded mode. Perhaps we need another provider. Perhaps the service is reliable enough and the alternatives expensive enough that accepting the risk remains the sensible decision.

The answer doesn't have to be ownership.

It has to be deliberate.

That's where I've landed after spending years thinking about centralized and decentralized infrastructure. Neither arrangement solves dependency because dependency isn't a defect we can engineer out of complicated systems. We can move it, distribute it, duplicate it, insure against it and decide which forms we're willing to accept.

What we shouldn't do is let convenience make those decisions invisibly.

The cloud can be the primary environment. It can be the backup. It can provide geographic reach, burst capacity, managed services or things we have absolutely no interest in operating ourselves. Local infrastructure can carry the steady workload, preserve a degraded mode or simply provide another place from which recovery is possible.

Different systems will draw those boundaries differently.

What matters is knowing what happens when each boundary becomes real.

That's what I mean by intentional dependency. Not independence from larger systems, and not a retreat from abstraction, but knowing which outside promises our continuity depends upon and deciding whether we're comfortable waiting for those promises to be restored when something goes wrong.

Sometimes we will be.

Sometimes later is too late.

The architecture should know the difference before the failure teaches it to us.