ayedo Edge-Cloud: The Underestimated Architecture of Modern Applications

Modern Applications No Longer Start in the Data Center

There is a persistent thought, although modern software has long disproved it.

When we talk about running an application, we almost automatically think of the data center. Of virtual machines, Kubernetes clusters , databases, containers , or storage systems. Our architecture diagrams often start right there: somewhere within a cloud region, behind a firewall, where compute resources are provisioned and applications are executed.

Even the language we use reveals this thinking. We talk about deploying applications, operating clusters, or scaling platforms. For us, the actual infrastructure begins the moment the first container is started.

But that’s no longer where it begins.

Perhaps it never began there.

The notion that an application begins with its first process or its first pod comes from a time when software and infrastructure were almost synonymous. Running a web server meant putting a server in the rack, installing an operating system, configuring a web server, and connecting it to the internet. Between a user’s browser and the actual application were comparatively few technical layers. Routing, transport, and application formed a unit that could still be explained with a single architecture diagram.

Today, this picture seems almost naive.

Not because modern applications have fundamentally become more complicated, but because their actual complexity has shifted.

In the past decade and a half, we have made enormous progress in abstracting applications themselves. Virtual machines replaced physical servers. Containers reduced the differences between development and production environments. Kubernetes decoupled applications from individual hosts and made infrastructure increasingly declarative. GitOps, Infrastructure as Code, and automated deployment pipelines finally ensured that even highly complex platforms can be reproducibly built and operated.

However, it would be a mistake to assume this development has made infrastructure simpler.

It has merely moved it to another place.

While the complexity within our platforms was continuously reduced, a completely new architectural layer emerged outside these platforms, which today takes over a significant part of what was once naturally part of a single web server.

A user who calls an application no longer connects directly to a server.

They first reach an infrastructure whose actual task is not to execute applications but to decide if, where, and under what conditions an application can even be reached.

This distinction initially seems subtle.

In fact, it changes our entire view of modern systems.

Because before a single line of application code is executed, before Kubernetes selects the appropriate pod, or a service forwards a request to the correct backend, a multitude of systems have already made decisions that significantly influence the further course of this request.

Which network path is used?

At which location is the connection received?

Where does the TLS connection end?

Is the request legitimate?

Is the target system even reachable?

Should the same user be directed to the same backend again?

Or must the request be discarded at this point?

Remarkably, it is not that these decisions exist.

Remarkably, they do not appear in most architecture diagrams at all.

We draw applications.

We draw databases.

We draw Kubernetes clusters .

With some luck, we might draw a load balancer in front of them.

The actual path that each individual request takes often disappears behind a simple line labeled Internet.

Perhaps therein lies one of the greatest misunderstandings of modern platform architectures.

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.

Between a user and the actual application today lies an independent infrastructure that makes routing decisions, establishes cryptographic connections, enforces security policies, distributes load, detects attacks, monitors the health of backends, and continuously decides which part of a platform is visible and which remains hidden.

The more applications were abstracted, the more significant this layer became.

Paradoxically, we talk about it much less frequently than about [container] orchestration, service meshes, or observability.

Perhaps because it performs its task particularly well.

Good infrastructure has a remarkable property: It disappears.

No one thinks about DNS as long as a domain reliably resolves.

No one deals with routing tables as long as websites load within milliseconds.

No one wonders how a TLS certificate was provided as long as the little lock symbol appears in the browser.

And hardly anyone thinks about the actual path a request took as long as the response comes back quickly enough.

Only when one of these systems fails do we realize they were never mere supporting actors.

They were the stage on which every modern application moves from the very beginning.

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

Not in the data center.

But where every application truly begins.

At the first request from the Internet.

The Journey of a Request

Every modern application begins with a surprisingly unspectacular action.

Someone opens a browser.

Perhaps they are sitting in a home office in Munich. Perhaps they are working in an office in Hamburg or calling an API on the go via a mobile network. For them, it doesn’t matter. They enter a URL, press the Enter key, and expect an application to appear within moments.

This expectation is remarkable.

Because it presupposes that a multitude of independent systems make the same decision in a very short time: This request should reach exactly this application.

So let’s start where every request actually begins.

Not in the data center.

Not in the Kubernetes cluster .

But on a laptop somewhere on the Internet.

The browser initially knows only one name.

https://api.example.de

Nothing more.

No IP address.

No server.

No data center.

Just a name.

For this name to become a connection at all, the browser first needs to find out where to connect. It queries a recursive DNS resolver, which in turn contacts several name servers until an answer is finally found.

From the browser’s perspective, this process is remarkably unspectacular.

It receives an IP address.

That’s all it cares about.

What the browser doesn’t know: This IP address doesn’t exist in just one place.

It is published simultaneously at multiple locations.

For the client, it remains a single address.

Always the same.

Regardless of whether the user is in Flensburg, Frankfurt, or Freiburg.

At this point, one of the most elegant concepts of modern network infrastructure already begins.

Because the browser does not connect to a specific data center.

It merely connects to an address.

The Internet then decides for itself where this connection actually ends.

The first TCP packet now leaves the user’s computer.

It passes through the home router, reaches the Internet Service Provider, and begins a journey through networks belonging to different companies that have nevertheless agreed to forward data packets to each other.

There is no central traffic controller.

No instance monitors all data traffic.

No database knows the optimal path.

Instead, each network only has a small piece of the overall picture and makes its own decisions based on this.

This very property has made the Internet astonishingly robust for decades.

Every network operator knows its direct neighbors.

Everyone decides for themselves which paths are preferred.

From countless local decisions, a global network finally emerges.

At some point, our request reaches a network that knows the same public IP address at multiple locations simultaneously.

Now something remarkable happens.

Not the application decides which location serves the user.

Not DNS.

Not any geo-database.

But the Internet itself.

From a routing perspective, the Point of Presence in Hamburg might be the shortest path.

For another user, the same infrastructure decides on Frankfurt a few milliseconds later.

Both users use the same URL.

Both receive the same IP address.

And yet their connections land in different places.

Without redirect.

Without a new DNS query.

Without any application even being aware of it.

Perhaps that is the true magic of Anycast.

It is not an additional service.

It is a property of the network itself.

When the connection finally reaches a Point of Presence, there is still no talk of HTTP.

First, a TCP connection must be established.

The classic three-way handshake ensures that both communication partners agree on a connection, exchange sequence numbers, and establish a common transmission channel.

Only then does the next layer begin.

Since almost every application communicates encrypted today, the TLS handshake follows immediately.

Certificates are verified.

Cryptographic methods are negotiated.

Keys are generated.

Only after both sides are sure with whom they are communicating does the actual exchange of application data begin.

Interestingly, for many people, this is where the mental model of an HTTPS connection already ends.

The browser speaks HTTPS.

The server responds.

Done.

In fact, the real work only begins now.

Because for the first time, the request is decrypted.

For the first time, a platform can understand what the user actually wants.

Which host was called?

Which URL is requested?

Which HTTP header was transmitted?

Which cookies does the request contain?

Which backend should handle it?

But above all:

Should this request even be forwarded?

Because not every request comes from a browser.

Not every request comes from a legitimate user.

Not every connection pursues a legitimate goal.

A modern edge platform therefore does not merely view an HTTP request as a data stream.

It analyzes it.

It recognizes known attack patterns.

It evaluates headers.

It checks protocol violations.

It compares requests with rules of the Web Application Firewall and decides within milliseconds whether the request should be allowed or blocked.