-
Roads Through the Sky: Connecting Cloud-Native Services
A distributed kingdom survives only when its distant cities know how to speak. A single castle can rely on hallways. The kitchen knows where the pantry is, guards can walk directly to the armory, and a steward who needs an answer can cross the courtyard and ask for it. Once the kingdom spreads across distant cities, those assumptions disappear. The treasury may live in one region, the guild registry in another, and the market serving the public somewhere else entirely. Each city can function perfectly on its own and still leave the kingdom paralyzed if the roads between them are unreliable or poorly governed. Cloud-native systems inherit the same problem.…
-
The Castle That Appears on Command: Serverless Architecture
Sometimes the finest fortress is the one that exists only when it is needed. A Fortress Without a Permanent Gate: What Serverless Actually Changes For most of software history, deploying an application meant giving it somewhere permanent to live. A server was provisioned, a runtime installed, and a process waited for requests whether anyone arrived or not. Virtual machines changed how servers were acquired, and containers changed how applications were packaged, but the assumption remained: something was running, and engineers were responsible for keeping it alive. Serverless challenges that assumption by asking whether the fortress needs to exist when nobody is visiting. The name is misleading because servers still exist.…
-
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…
-
When the Kingdom Burns: Designing for Failure Before Disaster Strikes
Hope is a poor evacuation plan. There is a quiet confidence that settles over every engineering team after enough successful deployments. Systems remain stable for months. Monitoring dashboards glow green. Customers continue using the software without incident, and the last major outage slowly fades into memory. Over time, it becomes easy to mistake reliability for a permanent characteristic of the software instead of recognizing it as the product of thousands of careful engineering decisions. That confidence is understandable, but it is also one of the greatest risks a software organization can face. Software rarely fails because developers expect it to fail. More often, it fails because teams gradually stop imagining…
