From Physical Servers to Kubernetes: The Complete Evolution of Application Networking (Explained with real example – TravelCity)

By SND

July 14, 2026 9 Min Read

If you’ve ever tried to jump straight into Docker or Kubernetes without understanding why they exist, you’ve probably felt lost. Terms like Pods, Services, Ingress Controllers, and Load Balancers start to feel like buzzwords instead of solutions to real problems.

The truth is, Kubernetes wasn’t invented in a vacuum. It’s the result of decades of engineers solving one problem after another — scalability, reliability, isolation, and efficiency. To really understand modern infrastructure, you have to understand the journey that led to it.

In this article, we’ll walk through that journey using a simple, relatable example: a travel booking application called Travelity. We’ll follow Travelity from a single physical server all the way to a fully orchestrated Kubernetes cluster, picking up the key networking and infrastructure concepts along the way.

1. The Beginning: A Single Physical Server

Every application has to start somewhere, and for Travelity, that start is humble: one physical server sitting in a data center, running the entire application.

A user opens their browser, types in Travelity’s address, and expects to see flight and hotel listings. But how does that request actually find its way to the server?

This is where IP addresses come in. Every device connected to the internet — including Travelity’s server — has a unique numerical identifier called an IP address. In theory, a user could type that IP address directly into their browser and reach the server. But nobody wants to remember a string of numbers to book a flight.

DNS and Domain Names

This is why DNS (Domain Name System) exists. DNS acts like the internet’s phone book. Instead of memorizing an IP address, users type a human-friendly domain name like travelity.com. Behind the scenes, DNS translates that domain name into the actual IP address of the server hosting Travelity.

The basic request flow looks like this:

Client → DNS → Server

The user types travelity.com into their browser.
The browser asks a DNS server, “What’s the IP address for this domain?”
DNS responds with the server’s IP address.
The browser connects directly to that IP address and loads the application.

This works beautifully — until Travelity becomes popular.

2. The Traffic Spike Problem

Imagine it’s the holiday season, and thousands of users suddenly flood Travelity looking for flight deals. The single physical server, which was perfectly fine handling a few hundred requests, now has to process thousands simultaneously.

CPU usage spikes. Memory fills up. Response times slow to a crawl. Eventually, the server crashes, and Travelity goes offline at the worst possible time — when demand is highest.

This is one of the fundamental problems in application architecture: a single server has a hard ceiling on how much traffic it can handle. No matter how powerful that one machine is, there’s always a limit.

3. Load Balancers to the Rescue

The first real solution to this problem is scaling horizontally — adding more servers instead of relying on one. But if you have multiple servers, how does incoming traffic know which one to go to?

This is the job of a Load Balancer. A tool like an F5 load balancer sits in front of your servers and distributes incoming traffic across them based on availability, health, and load.

The updated flow now looks like:

Client → DNS → Load Balancer → Server 1 / Server 2 / Server 3

Instead of DNS pointing directly to a single server, it points to the load balancer. The load balancer then decides which backend server should handle each incoming request. If one server goes down, the load balancer simply stops sending traffic to it and routes requests to the healthy ones instead.

This solves the traffic spike problem to a degree — Travelity can now handle more concurrent users by simply adding more physical servers behind the load balancer.

But this approach has its own limitations.

4. Scaling with Physical Servers: The Hidden Costs

Buying and provisioning new physical servers every time you need more capacity is slow, expensive, and inefficient. A few of the core issues:

Cost: Physical servers are expensive, and you often have to buy for peak capacity even though you won’t need it most of the time.
Time: Procuring, installing, and configuring a new physical server can take days or weeks.
Underutilization: Most of the time, servers sit mostly idle, wasting resources you already paid for.
Maintenance: Physical hardware needs cooling, power, security, and regular upkeep.

Travelity’s team needs a way to get the benefits of “more servers” without the overhead of buying actual machines every time. This is where virtualization enters the picture.

5. Virtual Machines (VMs) and the Hypervisor

A Virtual Machine (VM) is a software-based emulation of a physical computer. Instead of buying five new physical servers, you can take one powerful physical server and split it into multiple virtual machines, each behaving like an independent server with its own operating system, CPU allocation, memory, and storage.

How Does This Work? The Hypervisor

The technology that makes this possible is called a Hypervisor. Think of a hypervisor as a building manager who takes one large building (the physical server) and divides it into separate, independent apartments (virtual machines). Each apartment has its own walls, its own utilities, and its own lock — the tenants (applications) inside have no idea other apartments even exist.

The hypervisor manages how the physical server’s actual resources — CPU, RAM, storage, and network — are allocated and isolated across all the VMs running on top of it.

VM Networking Architecture

Each VM gets its own virtual network interface, and typically its own IP address, even though multiple VMs are running on the same physical hardware. The hypervisor handles routing traffic between the outside world and each individual VM, just as if they were separate physical machines.

For Travelity, this is huge. Now, instead of purchasing new physical hardware every time they need to scale, they can spin up new VMs on existing hardware in minutes, each capable of running an instance of the application behind the load balancer.

6. Enter Containers: Lighter, Faster, More Efficient

Virtual machines solved a lot of problems, but they still carry some baggage. Each VM includes a full copy of an operating system, which means it consumes a significant chunk of memory and storage, and takes time (often minutes) to boot up.

This is where containers come in.

Containers vs Virtual Machines

The key difference is what gets virtualized:

A VM virtualizes the entire hardware stack, including a full guest operating system for each instance.
A container virtualizes only the application layer, sharing the host machine’s operating system kernel while keeping the application and its dependencies isolated.

Because containers don’t need to boot an entire OS, they are:

Lightweight — using far less memory and storage than a VM.
Fast to start — often launching in seconds or even milliseconds.
Portable — a container packages the application code, libraries, and dependencies together, so it runs the same way regardless of where it’s deployed.

For Travelity, this means their engineering team can package the booking service, the payment service, and the search service into individual containers, each with exactly what it needs to run — nothing more, nothing less.

7. Monolith to Microservices

Early on, Travelity was likely built as a monolith — a single, large codebase handling everything: user authentication, flight search, hotel booking, payments, and notifications, all bundled into one application deployed as a single unit.

Monoliths are simple to start with, but as Travelity grows, this approach starts to break down:

A small bug in the payment module can bring down the entire application.
Every deployment requires redeploying the entire application, even for a tiny change.
Different teams working on different features constantly step on each other’s code.
Scaling means scaling the whole application, even if only one part (like search) is under heavy load.

The solution is breaking the monolith into microservices — independent, loosely coupled services that each handle one specific responsibility. Travelity might end up with a Search Service, a Booking Service, a Payment Service, and a Notification Service, each running in its own container, each scalable independently, and each deployable without touching the others.

This is a natural fit for containers: each microservice gets packaged into its own lightweight, portable container.

8. The Problem with Managing Containers Manually

Microservices in containers sound great in theory, but now Travelity has a new challenge: operational complexity.

Instead of one application to manage, there might be dozens or hundreds of containers running across multiple machines. Manually managing this brings serious headaches:

How do you restart a container automatically if it crashes?
How do you scale a specific service up or down based on traffic?
How do containers find and communicate with each other?
How do you roll out updates without downtime?
How do you distribute traffic evenly across many container instances?

Doing all of this by hand, with scripts and manual intervention, doesn’t scale. Travelity’s engineers need an automated system to manage the entire lifecycle of their containers.

9. Why Kubernetes Was Created

Kubernetes (often abbreviated K8s) was built to solve exactly this problem: orchestrating containers at scale. It’s a system that automates the deployment, scaling, networking, and management of containerized applications.

Kubernetes gives Travelity a set of powerful capabilities out of the box:

Automatic Scaling — Kubernetes can automatically increase or decrease the number of running containers based on real-time demand, so Travelity’s Search Service can scale up during a flash sale and scale back down afterward.
Self-Healing — If a container crashes or a node becomes unhealthy, Kubernetes automatically detects it and replaces it, keeping the application running without manual intervention.
Load Balancing — Kubernetes automatically distributes incoming traffic across all healthy instances of a service.
Scheduling — Kubernetes decides which physical or virtual machine (node) should run each container, based on available resources.
Service Discovery — Containers can find and communicate with each other using stable internal names, even as individual container instances are created and destroyed.

10. High-Level Kubernetes Request Flow

Putting it all together, here’s how a request travels through a Kubernetes-powered version of Travelity:

User → F5 Load Balancer → Ingress Controller → Services → Pods → Backend Services → Database

User opens Travelity in their browser and sends a request.
The request hits an external F5 Load Balancer, which distributes traffic into the Kubernetes cluster.
The Ingress Controller receives the traffic and routes it to the correct internal Service based on the URL path or hostname (e.g., /search, /booking, /payments).
A Service acts as a stable network endpoint that routes traffic to the correct group of Pods (a Pod being the smallest deployable unit in Kubernetes, typically wrapping one or more containers).
The Pods run the actual application code — Travelity’s microservices — and process the request.
These services communicate with backend services and ultimately the database to fetch or store data, such as flight availability or booking confirmations.
The response travels back up through the same chain to the user.

This architecture gives Travelity the scalability of horizontal scaling, the isolation of containers, and the automation of Kubernetes — all working together.

The Journey So Far

Let’s recap the evolution:

Stage	Problem Solved	New Limitation
Physical Server	Hosts the application	Can’t handle traffic spikes
Load Balancer	Distributes traffic across servers	Buying servers is slow and expensive
Virtual Machines	Faster provisioning via virtualization	VMs are heavy and slow to boot
Containers	Lightweight, fast, portable app packaging	Manual container management doesn’t scale
Kubernetes	Automates scaling, healing, and networking	New concepts to learn, but solves the core problem

Each layer of this stack exists because of a real, practical problem engineers faced as applications grew. Understanding this progression makes concepts like Pods, Services, and Ingress Controllers feel less like arbitrary jargon and more like logical solutions to problems you now understand firsthand.

What’s Next

This is just the foundation. In upcoming parts of this series, we’ll go deeper into:

Monolith to Microservices Migration
Kubernetes Internal Architecture
Kubernetes Networking Deep Dive
Kubernetes Services Explained
Ingress Controller Explained
Spring Integration Real-World Use Cases
Apache Beam Explained

If you’re preparing for a system design interview, working toward a DevOps or Cloud Engineering role, or just trying to understand how modern applications like Travelity actually run in production, mastering this evolution — from physical servers to Kubernetes — is the essential first step.

Found this useful? Follow along for the rest of the series as we go deeper into Kubernetes architecture, networking, and real-world microservices patterns.