Serverless

Serverless is the compute model that made deploying APIs radically simpler, and it reshaped how a generation of APIs got built. Serverless — functions-as-a-service, exemplified by AWS Lambda — lets you deploy a unit of code that runs on demand, scales automatically, and bills only for actual execution, without managing any servers. For APIs, this was transformative: combined with an API gateway, serverless functions became one of the most accessible ways to stand up an API. You write the function that handles a request, wire it to a gateway, and you have an API that scales from zero to massive without you provisioning or managing infrastructure. I watched serverless go from a novel idea to a default deployment pattern for a huge swath of APIs, and it represents one of the more genuinely useful shifts in how APIs get deployed — collapsing the infrastructure overhead that used to stand between an idea and a running API.

The AWS Lambda and API Gateway combination is the canonical serverless API stack, and I documented it extensively. When AWS API Gateway launched in 2015 — an event I marked with characteristic enthusiasm — it completed the serverless API picture: API Gateway in front to handle routing, authentication, and rate limiting, Lambda behind it for compute, and a database like DynamoDB or RDS for storage. I wrote walkthroughs of building simple APIs with exactly this stack — DynamoDB, Lambda, and API Gateway, or RDS, Lambda, and API Gateway. The appeal was that this stack let you build a real, scalable API without managing a single server: the gateway handled the API management concerns, Lambda ran your logic on demand, and the whole thing scaled automatically. This became the reference architecture for serverless APIs, and the pattern spread across the industry as the cloud providers all built equivalent offerings.

The technical-debt argument was one of the more interesting cases I made for serverless. I wrote in 2016 that serverless approaches to deploying code will help unwind some of the technical debt we have — because serverless forces a certain discipline. When your compute is decomposed into small, independent, stateless functions, you’re pushed away from the tangled monoliths that accumulate technical debt and toward smaller, more manageable, more independently-deployable units. Serverless, like microservices, is about understanding your dependencies and constraints, as I wrote in 2018 — the discipline of decomposing your system into small pieces makes the dependencies explicit and the constraints clear. This was a real benefit: serverless wasn’t just operationally convenient, it nudged architectures toward the kind of decomposition that’s easier to reason about and change. Though I also flagged the failure mode in 2018 with “monolithic serverless, WTF” — because you can absolutely build a tangled monolith out of serverless functions if you’re not disciplined, defeating the architectural benefit entirely.

The serverless-and-microservices relationship is worth being precise about, because the two are related but distinct. Microservices is an architectural pattern — decomposing a system into small, independently-deployable services. Serverless is a compute and deployment model — running code on demand without managing servers. They fit together naturally: serverless functions are a convenient way to deploy microservices, and both share the philosophy of small, independent, decomposed units. But you can do microservices without serverless (running them on your own infrastructure) and serverless without microservices (deploying a function that isn’t part of a microservices architecture). Understanding the distinction matters for reasoning clearly about your architecture: serverless is about how you run code, microservices is about how you structure your system, and the serverless API stack is one popular way of combining the two.

The blueprints-and-tooling maturation made serverless API deployment increasingly accessible and repeatable. I wrote in 2017 about serverless blueprints for your API and the AWS serverless API portal — reusable patterns and reference implementations that let teams stand up serverless APIs without reinventing the architecture each time. By 2020 I was writing about generating serverless APIs in multiple languages from a Postman collection, and running and organizing Lambdas with Postman collections — the integration of serverless deployment with the broader API tooling ecosystem. The trajectory was serverless API deployment becoming more defined, more repeatable, and more integrated with the rest of the API lifecycle. What started as a novel way to run code became a mature, well-tooled deployment pattern with blueprints, generators, and integration into the API operations toolchain. Serverless moved from frontier to infrastructure.

The honest framing, which I’ve held throughout, is that serverless is a genuinely useful deployment pattern with real benefits and real shadows. The benefits are real: radically reduced infrastructure overhead, automatic scaling, pay-per-execution economics, and a nudge toward cleaner decomposition. These made serverless one of the most accessible ways to deploy APIs, lowering the barrier between an idea and a running, scalable API. But I’ve also pointed at the shadow, consistent with my broader concerns: I wrote in 2017 about reducing developers to a transaction with APIs, microservices, serverless, DevOps, and the blockchain — the recognition that the same decomposition that makes serverless convenient also commoditizes the work, breaking development into small interchangeable units in ways that have labor and power implications. Serverless is a tool, and like every powerful tool it has both a genuinely useful face and a set of consequences worth being honest about. For the practical work of deploying APIs, serverless earned its place as a default pattern — the API gateway plus functions plus managed storage stack became one of the standard ways to build an API, and it remains a genuinely good answer for a huge range of API deployment needs. It collapsed the infrastructure barrier that used to stand between developers and running APIs, and that’s a real and lasting contribution to how the API economy gets built.

Discovery

Learnings

Guidance

Toolbox

Alignment

API Evangelist LLC

Serverless

References

Guidance Details

Explore more

Discover APIs