The Underestimated Architecture of Modern Applications
Modern applications no longer start in the data center.
There is a peculiar characteristic of modern software.
The more powerful our platforms have become, the simpler their architecture seems at first glance.
Today, we talk about Kubernetes, GitOps, Infrastructure as Code, or Continuous Deployment as if they were self-evident components of every application. Clusters are created within minutes, containers are automatically scaled, and new versions reach production without users even noticing. Compared to the infrastructure of past decades, modern software seems almost elegant.
Perhaps even surprisingly simple.
But this impression is misleading.
Not because modern systems are more complicated than their predecessors.
But because their complexity has shifted to a place we surprisingly rarely discuss.
Let's consider for a moment how most architecture diagrams begin.
Application
+----------------------+
| Kubernetes |
+----------------------+
|
+----------------------+
| Database |
+----------------------+
|
Internet ☁
It's a diagram that probably everyone knows.
On the left is the Internet.
Then follows a load balancer, perhaps an ingress controller, then Kubernetes, and finally the actual application.
Interestingly, we almost exclusively discuss the right part of this diagram.
We talk about containers.
About databases.
About replication.
About observability.
About deployments.
The left part, however, often disappears behind a small cloud labeled Internet.
As if nothing else of significance lies between a user and our platform.
Perhaps this is one of the greatest misunderstandings of modern infrastructure.
The notion that an application begins where the first process is started or the first pod is scheduled comes from a time when applications and infrastructure were almost synonymous.
A web server was an application.
An application was a server.
Between a user's browser and the actual software, there were comparatively few technical layers. 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 sheet of paper.
Today, this picture seems almost nostalgic.
Not because it was wrong.
But because it describes a world that hardly exists in this form anymore.
In the past decade and a half, we have made enormous efforts to decouple 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.
Perhaps therein lies a remarkable irony.
Because while we abstracted applications further and further, a completely new architectural layer emerged outside these platforms, whose responsibility continuously grew.
Infrastructure hasn't become simpler.
It has moved.
The first contact between a user and a modern application no longer takes place in the data center.
It occurs at a point that often doesn't even appear in architecture diagrams.
Even before Kubernetes selects a pod.
Even before a service decides which backend processes a request.
Even before a single line of application code is executed.
There already exists an infrastructure whose sole purpose is to prepare exactly these decisions.
It determines which path a connection takes through the Internet.
Where it ends.
Whether it is encrypted.
Whether it is legitimate.
Whether it is even allowed to reach the actual application.
This distinction may initially seem subtle.
In reality, however, it changes our entire perspective on modern platforms.
Because suddenly an application no longer begins where it is executed.
It begins where a user first interacts with it.
This thought initially seems almost self-evident.
And yet we usually treat our systems as if that were not the case.
We invest weeks in planning our Kubernetes architecture.
We discuss storage classes, deployment strategies, or service meshes.
At the same time, the entire path up to that point 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 certainly not a transparent transport channel through which requests simply flow.
It is probably the largest distributed system ever built.
A system that makes routing decisions.
That connects networks.
That continuously evaluates which paths are reachable and which are not.
And that influences every single request long before an application even has the opportunity to respond.
Good infrastructure has a remarkable characteristic.
It disappears.
No one cares about DNS as long as a domain reliably resolves.
No one thinks about routing as long as web pages load within milliseconds.
No one deals with TLS as long as the small lock symbol appears in the browser.
And hardly anyone wonders which path a request actually took as long as the response comes back quickly enough.
Good infrastructure does not attract attention.
It generates trust.
Perhaps that is why we find it so difficult to think about it.
We usually only see it when it fails.
Perhaps it is 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 start in the data center.
Perhaps they never did.