Serverless Computing

Introduction to Serverless Computing

The term Serverless Computing is a famously terrible name. There are, of course, physical servers running in a massive Amazon or Google data center.

“Serverless” simply means that the software developer never has to think about the servers.

In traditional cloud computing (like Amazon EC2), a company rents a virtual server. The company’s DevOps engineer must choose the operating system (Linux), install security patches, monitor the CPU usage, and manually configure Auto-Scaling groups to add more servers if traffic spikes. Furthermore, the company pays for that server 24/7/365, even if no users visit the website at 3:00 AM.

Serverless Computing (often synonymous with Function-as-a-Service, or FaaS) eliminates all of this. The developer simply writes a block of code (a Function), uploads it to the cloud, and the Cloud Provider handles 100% of the underlying infrastructure automatically.

How Serverless Works: The Event-Driven Model

The most famous implementation of Serverless is AWS Lambda.

Serverless functions do not run constantly. They are purely Event-Driven. They sit completely dormant on a hard drive, doing nothing and costing zero dollars.

They only wake up when a specific “Event” triggers them:

1. A user uploads an image to an S3 bucket.
2. The S3 bucket fires a trigger.
3. AWS instantly spins up a secure micro-container, loads the developer’s Python code, and executes the image resizing script.
4. The script finishes 200 milliseconds later.
5. AWS instantly destroys the container.

The Pricing Model (Pay-Per-Execution)

Because the container was only alive for 200 milliseconds, the company is only billed for exactly 200 milliseconds of compute time. If nobody uploads an image for the next week, the AWS bill is literally $0.00.

Infinite Auto-Scaling

If a website goes viral and 10,000 users upload an image at the exact same second, AWS handles it seamlessly. It will instantly, simultaneously spin up 10,000 isolated Lambda functions. The developer does not have to configure load balancers or provision clusters. The infrastructure scales from zero to infinity (and back to zero) flawlessly and automatically.

The Drawbacks of Serverless

While Serverless is the holy grail for DevOps and billing, it introduces specific architectural challenges.

1. The “Cold Start” Penalty

When a function is triggered after being dormant for a long time, AWS has to allocate physical hardware, spin up the container, and load the runtime environment (like Node.js or Java) before the code actually executes. This process is called a Cold Start. A Cold Start can take anywhere from 500 milliseconds to several seconds. If a user is clicking a button on a website, a 3-second delay is unacceptable. To fix this, companies must pay to keep functions artificially “warm,” defeating some of the cost-saving benefits.

2. State and Time Limits

Serverless functions are strictly Stateless. Once the function executes and dies, all local memory is wiped. They cannot save variables between executions; all data must be saved to an external database (like DynamoDB). Furthermore, Cloud providers enforce hard time limits. An AWS Lambda function is forcibly terminated if it runs for more than 15 minutes. You cannot use Serverless to run a massive, 3-hour machine learning training job.

Conclusion

Serverless Computing represents the ultimate evolution of cloud abstraction. By shifting the entire burden of server provisioning, security patching, and auto-scaling to the cloud provider, Serverless architectures allow developers to focus 100% of their time on writing business logic, drastically accelerating time-to-market while simultaneously driving cloud compute costs down to the absolute minimum.