Serverless

Serverless is a model of building and running applications in which developers write and deploy code without provisioning, configuring, or maintaining the servers that run it. The name is deliberately figurative: servers absolutely still exist, but the responsibility for managing them shifts to a cloud provider. Developers hand over a piece of code, and the platform decides where to run it, how many copies to spin up when traffic surges, and when to shut everything down when demand drops. Billing usually follows actual usage, measured by the number of requests and the compute time each request consumes, so an idle application costs little or nothing.

In practice, serverless most often takes the form of functions as a service. A developer writes a function that does one discrete thing, such as resizing an uploaded image, processing a payment webhook, or returning data for an API request. The platform holds that function ready and executes it on demand whenever a triggering event arrives, then automatically scales the number of running instances up or down to match the load. This event-driven, on-demand execution is the heart of the model. The tradeoff is that functions are stateless and short-lived, so anything that needs to persist between calls must live in an external database or storage service, and a function that has not run recently may face a brief startup delay known as a cold start.

The term emerged as cloud platforms introduced this style of hosting, with the launch of functions-as-a-service offerings in the mid-2010s bringing it into common use. It was coined partly as a marketing contrast to the older world of renting and babysitting virtual machines, and the "less" suffix simply signals the absence of server management from the developer's point of view.

For a business, serverless matters because it lowers both the operational burden and the cost of running software. There is no fleet of servers to patch, secure, or keep online overnight, and the automatic scaling means a marketing campaign that suddenly drives ten times the normal traffic is absorbed without anyone paging an engineer. Small teams can ship features that would once have required a dedicated operations person, and the pay-per-use pricing keeps early-stage and seasonal projects inexpensive. For a website, serverless is a natural fit for handling form submissions, contact endpoints, scheduled tasks, and integrations with third-party services.

The common mistakes are worth understanding. Serverless is not always cheaper at very high, steady volume, where a continuously running server can cost less than millions of individual function invocations. Cold starts can hurt latency for infrequently used endpoints, and the stateless nature of functions forces a different design mindset than a traditional always-on application. Serverless relates closely to edge functions, which push this idea geographically closer to users, and to microservices, which break an application into small independent pieces that serverless functions can neatly implement. Understood for what it is, serverless is a way to trade infrastructure control for speed of development and elastic, usage-based economics.