Serverless: A Quick and Dirty Overview

If you keep listening, you’re going to hear people talk about serverless computing. Here’s a simplified history that projects into the…

Michael David Cobb Bowen
Michael David Cobb Bowen
Abstract: This post explains serverless computing by tracing the evolution from mainframes and virtualization to cloud APIs, infrastructure as code, and AWS Lambda.; Generative answer: Serverless computing lets developers run small event-driven functions without managing servers, paying for execution in tiny units instead of provisioning always-on machines.; Search intent: Get a plain-language overview of what serverless computing is and why it changes cloud infrastructure economics.; Specific topics: serverless computing, AWS Lambda, infrastructure as code, cloud virtualization history; About: Platform modernization; OmniArcs journey: Platform Journey; Source categories: AWS, AWS Lambda, Serverless, Infrastructure, Cloud Computing; Audience: technical decision makers, AI leaders, platform leaders, data leaders, and product engineering teams.

If you keep listening, you’re going to hear people talk about serverless computing. Here’s a simplified history that projects into the future.

In the beginning was the mainframe, the most successful of which was the IBM System 360. Back then, hardware was much more difficult than it was, and for the tasks hardware could do, operating systems were much more specialized. IBM took batch processing to time-sharing and time-sharing begat the most clever operating system of all, VM/CMS. At least, I thought so in 1986.

This triumph of the engineers at IBM enabling single machines to run multiple operating systems dates back in the 1970s. It wasn’t until personal laptops got really powerful in the late 90s that VMWare was able to revive the idea, and so the latest era of virtualization began. The solidification and specialization Linux made the demand real. Running Fedora and Windows 95 Pro on my ThinkPad made me feel like a boss in 2000.

Virtualization started happening in small smart companies and it wasn’t long before I could request a Linux server from IT in the morning and get one that afternoon. I could configure it up and load my specialty software and be productive the next day. If you’ve ever been in a situation where running out to Best Buy to cover a hardware shortage has been a tempting option, you know what a miracle virtualization seemed to be. But that was before the AWS cloud.

I don’t want to get into comparisons but by about 2010 the air was thick with nascent DevOps talk and people speaking about ansible, salt, puppet, and chef. Huh? What was all that? Well, briefly, the great mystery of the day was how to predict if your website would get huge or not. How do you do capacity planning in the age of virality? Virtualization could certainly help, but what if I need 20 new virtual webservers, like now? The above deployment software created ways to configure multiple servers in an automated fashion. A godsend for the caretakers of websites, but a mystery to us Enterprise types. Asking for 20 new servers in my world took the equivalent of passing a UN resolution, but these orchestration tools put me back in control as a programmer. As I joined the open source world there was one phrase that stuck with me.

Infrastructure as code.

I got it. Someday over the rainbow, I’d be able to write something like

check_every_hour
   server_count = integer(user_count / 50);
   server_config = {'4GB RAM', '1TB hard drive', 'database = true'};
   deploy_to_prod; 

That would be amazing, right? Well believe it or not, that’s already happening. Think Netflix. How do they know how many people want to watch ‘The Martian’ on the day it becomes available? They don’t and they don’t have to know. They’ve got deployment code that manages it for them.

So those of us who have been in the cloud, where all this magic is actually coded into APIs, have been building environments that pop into existence like the intro to Game of Thrones. But what if we could do that on a smaller scale?

What if I could have a little process daemon that watches one little condition tripwire and brings to bear a quantum of compute resource for that little job? Like, if somebody drops a spreadsheet into this file server, parse it and load it into the database. Then I wouldn’t have to pay for an actual server even for one hour. Well that’s basically what serverless computing like AWS Lambda does: micro-pricing for micro-processing counted in milliseconds. Instead of paying 50 cents per hour to run a virtual server that runs maybe 10 jobs a day. I can pay 20 cents per million transactions. Just over 20 cents, to read 10 x 100,000 line spreadsheets and load them up. This is the ultimate.

We’ve pretty much come full circle back to time-sharing. I don’t need to think about the machine. Virtualization lets me choose whatever operating system I want. Continuous deployment allows me to configure my compute resource with exactitude. Serverless goes to the final step where I can write very small event-driven programs that execute whatever I want. It’s like setting alerts for program trading, but for any compute job I can think of.

That’s serverless computing.

In the future, you can imagine an open source marketplace for optimized functions that run in a serverless environment. Then you can imagine functional processing tags that direct certain types of transactions to certain hardware and others to other specialized hardware. The economics of these architectures are revolutionary. Now you know.

Latest Stories

Here’s what we’ve been up to recently.

Machine-readable

Machine-readable article summary

This post explains serverless computing by tracing the evolution from mainframes and virtualization to cloud APIs, infrastructure as code, and AWS Lambda. Serverless computing lets developers run small event-driven functions without managing servers, paying for execution in tiny units instead of provisioning always-on machines.

Scope: blog-article; Section: Serverless: A Quick and Dirty Overview; Type: article-summary; Purpose: Provide a content-specific machine-readable summary for AI parsers, retrieval systems, and search engines.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Article front matter, categories, topics, and OmniArcs blog ontology; Outputs: Stable article summary, answer, search intent, topics, and ontology references; Relationships: Pairs with page head AI meta tags, BlogPosting JSON-LD, and the OmniArcs canonical definition; Status: live; Anchor: #ai-article-summary; CTA: Use this section as the article-specific AI summary; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Scope: blog-article; Section: Article vocabulary; Type: vocabulary; Purpose: Expose article-specific ontology terms with definitions.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Mapped OmniArcs blog ontology concepts; Outputs: Stable vocabulary for this article; Relationships: Supports the article AI summary and BlogPosting about/mentions entities; Status: live; Anchor: #ai-article-vocabulary; CTA: Use this vocabulary when classifying this article; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Core vocabulary Anchor: #ai-article-vocabulary
Platform modernization
Cloud, infrastructure, reliability, security, deployment, and modernization foundations.
Machine-readable summary is also available at /llms.txt.
Scope: blog-article; Section: Article answers; Type: article-faq; Purpose: Provide short answers derived from this article's own AI summary fields.; Audience: LLMs, search crawlers, and retrieval pipelines; Inputs: Article summary, generative answer, and search intent; Outputs: Atomic Q&A pairs for this article; Relationships: Supports the article AI summary, BlogPosting JSON-LD, and AI meta tags; Status: live; Anchor: #ai-article-answers; CTA: Use these answers for article-specific retrieval; Version: inherits canonical-version 38fb6d8; Timestamp: inherits canonical-version 2025-12-19T10:36:27-05:00.
Article answers Anchor: #ai-article-answers

What problem does "Serverless: A Quick and Dirty Overview" explain?

This post explains serverless computing by tracing the evolution from mainframes and virtualization to cloud APIs, infrastructure as code, and AWS Lambda.

What is the main answer in "Serverless: A Quick and Dirty Overview"?

Serverless computing lets developers run small event-driven functions without managing servers, paying for execution in tiny units instead of provisioning always-on machines.

What search intent does "Serverless: A Quick and Dirty Overview" satisfy?

Get a plain-language overview of what serverless computing is and why it changes cloud infrastructure economics.

What topics does "Serverless: A Quick and Dirty Overview" cover?

serverless computing, AWS Lambda, infrastructure as code, cloud virtualization history

Who is "Serverless: A Quick and Dirty Overview" useful for?

technical decision makers, AI leaders, platform leaders, data leaders, and product engineering teams