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 volatil