The Full Arc of Modern Compute
The demand for centralized compute has grown steadily since the birth of the internet. We’ve seen a shift from bare-metal, in-house servers to massive data centers hosting thousands of compute nodes of various sizes. We have seen different compute pardigms from physical servers, virtual machines, containers, and functions-as-a-service. And some of them achieved widespread success, while others failed to live up to the hype.
In this blog, I’ll walk through the evolution of compute systems and why some models became dominant while others fell short.
Centralized Compute (Client server)
The earliest form of centralized compute emerged during the client-server era, where organizations deployed large, in-house physical servers to handle client requests over the internet. In this model, companies were responsible for everything — from managing networking and hardware failures to maintaining the operating system and application code.
The challenges of centralized compute
- Scaling challenge: Scaling on demand and scaling across regions required heavy upfront investment.
- Portability Challenge : Apps tied to specific hardware and OS.
- Distribution challenge: Hard to deploy consistently across machines.
Scaling challenge:
As demand for compute increased, organizations needed ways to scale their servers to meet user traffic and workload spikes. There are two primary strategies for scaling: vertical scaling and horizontal scaling.
Vertical scaling: involves upgrading the resources of a single server — adding more RAM, CPU cores, or faster disks. We quickly hit the upper limits of what a single machine can support.
- These upgrades often require downtime and introduce a single point of failure
- High-end hardware becomes increasingly expensive for diminishing gains.
Horizontal scaling: means adding more servers to handle the load and distributing traffic across them via load balancers. Now your application is running in multiple places — every code or config change needs to be synchronized across all instances. Hardware differences make it harder to maintain consistent environments.
Second Level Virtualization:
In 2006, AWS introduced a new computing model in which other companies could rent the servers instead of installing and maintaining it on their own. Quickly, this model became popular and was adopted by many companies. The two primary serviced offered under this model are EC2 and AWS S3.
Virtualization
Virtualization is the technology that makes modern cloud computing possible. Hypervisors are the software that runs multiple operating systems (VMs) on a single physical machine. Each VM has its own operating system and can run independently. There are two types of hypervisors:
Type 1: (bare metal) In this type of virtualization, Hypervisor is installed directly on the physical machine and run VMs on top of it. Eg. KVM, Hyper-v.
Type 2: (Host os based) Here. Hypervisor is installed on top of an operating system(like windows) and runs virutal machines on top. Eg. Virtualbox
The challenges
Scalablity ChallengePortability Challenge- Distribution Challenge: Still a challenge.
Isolation Challenge: This one is solved by the cloud provider, But very interesting to know about. Now that multiple VMs can run on the same physical machine, the cloud platform has to isolate each VM to provide that guarantee to the client. Each VM doesn’t get dedicated hardware — that would be harder to manage. Especially when it comes to networking. A NIC is required for each VM to communicate with the outside world. To solve this, they use vNICs (Virtual Network Interface Cards), which are connected to virtual switches, and those switches are in turn connected to the host’s physical NIC — thus establishing a connection to the outside world.
Containerization
Virtualization solved many of the scalability and portability challenges of the previous model. But you can still hear “It works on my machine” from time to time. All you wanted was to package your code and be able to run it anywhere else.
Here comes containerization. With the help of containerization tools like Docker, you can create and run containers on any machine that has Docker installed. Both containers and VMs run your code in a sandboxed environment — but they do it in different ways. See how?
The main difference between containers and VMs is that containers emulate the operating system, whereas VMs emulate the hardware itself. The Docker Engine — the core piece — is responsible for translating the syscalls made by the container into the host OS. It’s also responsible for managing container isolation with the help of namespaces.
Edge functions
what is edge ?
The edge refers to globally distributed servers located close to users. Instead of routing traffic to centralized cloud regions, edge networks like Cloudflare, with presence in 330+ cities across 125 countries (including mainland China), handle requests as close to the user as possible — reducing latency and improving performance.
Edge functions architecture
Edge functions bring compute to the edge. They’re similar to serverless functions but instead of running in centralized cloud regions, they execute at edge locations, closer to the user. This minimizes round-trip time and is ideal for latency-sensitive workloads like:
Edge functions (eg., Cloudflare Workers, Vercel Edge, Deno Deploy ) are similar to serverless functions from a developer’s perspective, but for computing platforms, they represent a new paradigm. Edge functions use v8 Isolates to run JavaScript code in a sandboxed environment.
V8 Isolates are tiny JavaScript/TypeScript execution contexts that are both lightweight and fast. When you deploy an edge function, your code is compiled into a V8 Isolate along with its heap and global context. A single worker runtime process is responsible for running multiple isolates.
Think of a V8 isolate as a browser tab, and the Workers runtime as the browser itself. When a user request comes in, the Workers runtime either reuses an existing isolate or spins up a new one, runs it inside the worker process, and returns the response.
This model has several advantages on paper. It’s extremely fast, primarily because there’s no virtualization overhead. Creating and destroying isolates — the scalable units of work — is extremely efficient. Tiny means cheaper to create and operate. A single worker process can handle thousands of v8 isolates. In contrast, traditional serverless functions often rely on microVMs like Firecracker. When a request comes in, the platform must spin up a lightweight virtual machine with a stripped-down OS to run your code in isolation. This adds latency, especially when concurrency is high.
But is everything perfect with edge functions? Not quite.
- Edge functions come with fundamental limitations that restrict their use cases:
- They implement only a minimal subset of the standard JavaScript APIs.
- No direct TCP or UDP connections are allowed.
- There’s a hard cap on CPU time, enforced by the Workers runtime.
- No direct access to the filesystem is permitted.
References
https://blog.cloudflare.com/cloud-computing-without-containers/