The Beginning of a Platform
Why every architecture eventually reaches the point where it must rethink the network.
Perhaps the greatest challenge in modern platform architecture is no longer operating applications reliably. Today, we have extraordinarily powerful tools for that. Kubernetes orchestrates containers with a level of routine that would have seemed unthinkable only a few years ago. Infrastructure as Code makes even complex environments reproducible. GitOps reduces operational intervention to declarative changes in a repository, while observability platforms can evaluate billions of metrics, logs, and traces almost in real time. Compared with what platforms could do ten or fifteen years ago, it would be easy to conclude that infrastructure is largely a solved problem today. Perhaps that is even true. At least for one part of the platform.
Throughout this article series, we have tried to focus on an area that receives surprisingly little attention in many architecture diagrams, even though it is what makes every public application reachable in the first place. We discussed how modern applications no longer begin in the data center. We followed the path of a request and saw that the internet knows neither applications nor Kubernetes clusters, only networks and reachability. We saw why Anycast is not an additional feature but emerges directly from the architecture of BGP, why high availability begins much earlier than a failover between two data centers, and why compute platforms and edge platforms work closely together while carrying completely different responsibilities. Perhaps all of this can be reduced to a single observation. The entry layer of modern applications has evolved into a platform of its own. Not because an especially large number of products run there. But because decisions are made there that no other system in the architecture can sensibly take over.
Interestingly, that realization often leads to another question. If edge is now a platform, where does it actually end? The answer is surprisingly difficult. It does not end at a load balancer or a web application firewall. It does not end with TLS termination either. None of those components has an independent reason to exist. They simply fulfill different tasks within the same processing chain. Perhaps the following diagram describes modern platform architecture more accurately than many traditional representations.
Internet
│
▼
+-----------------------+
| Edge Platform |
|-----------------------|
| DNS |
| Routing |
| Anycast |
| TLS |
| Layer 4 |
| Layer 7 |
| WAF |
| Health Checks |
| Traffic Engineering |
+-----------┬-----------+
│
▼
+-----------------------+
| Compute Platform |
|-----------------------|
| Kubernetes |
| Container Runtime |
| Services |
| Deployments |
| Storage |
| Business Logic |
+-----------------------+
At first, it may not be obvious what has changed compared with traditional architecture diagrams. It is not the components. Almost all of them existed before. What has changed is their relationship to one another. The edge is no longer infrastructure in front of the platform. It is itself part of the platform.
That observation was ultimately the starting point for everything we have built over the past years. Not because we wanted to develop another load balancer. Not because we believed DNS needed to be reinvented. And not because existing tools perform their jobs poorly. Quite the opposite. Almost all of the technologies discussed in this series have been among the most stable and reliable building blocks of the internet for decades. The real question was why modern platforms still often operate them as independent products even though, from the perspective of a request, they have long formed a common processing layer. That question ultimately led to our own edge platform. Not as a collection of individual network services. But as an architectural layer between the public internet and our compute cloud. A layer that treats routing, Anycast, TLS, Layer 4 and Layer 7 load balancing, health checks, DNS, and security mechanisms not as a loose chain of specialized components, but as different responsibilities within the same platform.
This article does not mark the end of the series. In many ways, it is where the series really begins. Every topic we have covered over the past weeks deserves a much deeper examination. Why does BGP converge within a few seconds in some situations while other changes take significantly longer? What impact do different peering strategies actually have on platform latency? Why do Layer 4 and Layer 7 load balancing differ architecturally far more than their names suggest? How does an edge platform assess the health of a backend when distributed systems can never exist in a completely consistent state? And what role do Kubernetes components such as Cloud Controller Manager, ExternalDNS, or cert-manager play when the edge itself becomes part of the platform? These are exactly the questions we want to explore in future articles. Not from the perspective of a product. But from the perspective of architecture. Not with marketing terms. But with routing tables, packet captures, sequence diagrams, RFCs, configuration examples, and the decisions that actually sit behind a modern platform.
Perhaps the most important insight from this entire series is therefore not that edge platforms are becoming more important. It is that we should begin drawing our architecture diagrams from a different starting point. Not where applications are executed. But where they first begin to exist for a user. At the moment a domain is resolved. At the moment the internet selects a path. At the moment a platform decides whether a connection should be accepted, protected, and accompanied all the way to the actual application. Perhaps modern infrastructure begins exactly there. And perhaps the next generation of modern cloud platforms begins there as well. For us, that was exactly the starting point. The ayedo Edge Cloud is therefore not the end of a development. It is the beginning of a platform.