How serverless computing makes development easier and operations cheaper
Developers spend countless hours solving business problems with code. Then it’s the ops team’s turn to spend countless hours, first figuring out how to get the code that developers write up and running on whatever computers are available, and second making sure those computers operate smoothly. The second part truly is a never-ending task. Why not leave that part to someone else?
A lot of innovation in IT over the past two decades—virtual machines, cloud computing, containers—has been focused on making sure you don’t have to think much about the underlying physical machine that your code runs on. Serverless computing is an increasingly popular paradigm that takes this desire to its logical conclusion: With serverless computing, you don’t have to know anything about the hardware or OS your code runs on, as it’s all taken care of for you by a service provider.
Serverless computing is an execution model for the cloud in which a cloud provider dynamically allocates—and then charges the user for—only the compute resources and storage needed to execute a particular piece of code. Naturally, there are still servers involved, but their provisioning and maintenance are entirely taken care of by the provider. Chris Munns, Amazon’s advocate for serverless, said at a 2017 conference that, from the perspective of the team writing and deploying the code, “there’s no servers to manage or provision at all. This includes nothing that would be bare metal, nothing that’s virtual, nothing that’s a container—anything that involves you managing a host, patching a host, or dealing with anything on an operating system level, is not something you should have to do in the serverless world.”
As developer Mike Roberts explains, the term was once used for so-called back-end-as-a-servicescenarios, where a mobile app would connect to a back-end server hosted entirely in the cloud. But today when people talk about serverless computing, or a serverless architecture, they mean function-as-a-service offerings, in which a customer writes code that onlytackles business logic and uploads it to a provider. That provider takes care of all hardware provisioning, virtual machine and container management, and even tasks like multithreading that often are built into application code.
Serverless functions are event-driven,meaning the code is invoked only when triggered by a request. The provider charges only for compute time used by that execution, rather than a flat monthly fee for maintaining a physical or virtual server. These functions can be connected together to create a processing pipeline, or they can serve as components of a larger application, interacting with other code running in containers or on conventional servers.
From that description, two of the biggest benefits of serverless computing should be clear: developers can focus on the business goals of the code they write, rather than on infrastructural questions; and organizations only pay for the compute resources they actually use in a very granular fashion, rather than buying physical hardware or renting cloud instances that mostly sit idle.
As Bernard Golden points out, that latter point is of particular benefit to event-driven applications. For instance, you might have an application that is idle much of the time but under certain conditions must handle many event requests at once. Or you might have an application that processes data sent from IoT devices with limited or intermittent Internet connectivity. In both cases, the traditional approach would require provisioning a beefy server that could handle peak work capacities—but that server would be underused most of the time. With a serverless architecture, you’d only pay for the server resources you actually use. Serverless computing would also be good for specific kinds of batch processing.
