The underestimated architecture of modern applications

Modern applications no longer begin in the data center.

There is a curious characteristic of modern software. The more powerful our platforms have become, the simpler their architecture appears at first glance. Today we talk about Kubernetes, GitOps, Infrastructure as Code, or Continuous Deployment as if they were self-evident parts of every application. Within minutes, clusters are created, containers scale automatically, and new versions reach production without users noticing at all. Compared with the infrastructure of past decades, modern software can seem almost elegant. Perhaps even surprisingly simple. But that impression is deceptive. Not because modern systems are more complicated than their predecessors. Rather, because their complexity has shifted to a place we surprisingly rarely talk about.

Consider for a moment how most architecture diagrams begin.

                Application

        +----------------------+
        |    Kubernetes        |
        +----------------------+
                 |
        +----------------------+
        |      Database        |
        +----------------------+
                 |
             Internet ☁

It is a diagram almost everyone recognizes. On the left is the internet. Then comes a load balancer, perhaps an ingress controller, followed by Kubernetes and finally the application itself. Interestingly, we discuss almost exclusively the right-hand side of this diagram. We talk about containers. About databases. About replication. About observability. About deployments. The left-hand side, by contrast, often disappears behind a small cloud labeled Internet. As if nothing between a user and our platform were of any further importance. Perhaps that is one of the biggest misconceptions in modern infrastructure.

The idea that an application begins where the first process starts or the first pod is scheduled comes from a time when applications and infrastructure were almost identical. A web server was an application. An application was a server. There were comparatively few technical layers between a user's browser and the software itself. A router forwarded packets, a web server answered HTTP requests, and a database stored information. Routing, transport, and application formed a unit that could still be explained on a single sheet of paper. Today, that picture feels almost nostalgic. Not because it was wrong. But because it describes a world that barely exists in that form anymore.

Over the past decade and a half, we have invested enormous effort in decoupling applications from their infrastructure. Virtual machines replaced physical servers. Containers made applications portable. Kubernetes detached workloads from individual hosts. Infrastructure as Code replaced manual configurations. GitOps made infrastructure reproducible. Each of these developments pursued the same goal: to reduce complexity within a platform. And they were extraordinarily successful. Yet perhaps that is precisely where a remarkable irony lies. While we continued abstracting applications, an entirely new architectural layer emerged outside those platforms, and its responsibility kept growing. Infrastructure did not become simpler. It moved.

The first contact between a user and a modern application no longer takes place in the data center. It happens at a point that often does not appear in architecture diagrams at all. Before Kubernetes selects a pod. Before a service decides which backend will process a request. Before a single line of application code is executed. There is already an infrastructure whose job is to prepare exactly those decisions. It determines which path a connection takes through the internet. At which location it terminates. Whether it is encrypted. Whether it is legitimate. Whether it is allowed to reach the application at all. At first, this distinction may seem subtle. In reality, however, it changes the way we look at modern platforms entirely.

Suddenly, an application no longer begins where it runs. It begins where a user first interacts with it. That thought may sound almost obvious. And yet we usually treat our systems as though it were not true. We spend weeks planning our Kubernetes architecture. We discuss storage classes, deployment strategies, and service meshes. At the same time, the entire path leading there often disappears behind a single line labeled Internet. Perhaps that is the real problem. The internet is not a cloud. It is not a connection between two boxes in a diagram. And it is certainly not a transparent transport channel through which requests simply flow. It is arguably the largest distributed system ever built. A system that makes routing decisions. That connects networks with one another. That continuously evaluates which paths are reachable and which are not. And that influences every single request long before an application has any opportunity to respond.

Good infrastructure has a remarkable characteristic. It disappears. Nobody cares about DNS as long as a domain resolves reliably. Nobody thinks about routing as long as websites load within milliseconds. Nobody thinks about TLS as long as the little lock icon appears in the browser. And hardly anyone asks which route a request actually took as long as the response returns quickly enough. Good infrastructure does not attract attention. It creates trust. Perhaps that is precisely why it is so difficult for us to think about it. Most of the time, we only notice it when it fails.

Perhaps it is therefore time to start our architecture diagrams at a different point. Not here.

             Internet ☁
                  |
             Kubernetes
                  |
             Application

But here.

Browser
    |
DNS
    |
Routing
    |
Peering
    |
Anycast
    |
TLS
    |
Edge
    |
Load balancing
    |
Kubernetes
    |
Application

Because modern applications no longer begin in the data center. Perhaps they never did.