Serverless computing provides a great opportunity for developers seeking relief from the burden of infrastructure. By abstracting away everything but a block of code, the serverless model makes it faster for developers to iterate and deploy new code, enabling smaller teams with smaller budgets to do things that only big companies could do before. Or, as Mat Ellis, founder of Cloudability, recently said in a CloudCast episode, “Serverless attempts to industrialize developer impact.”
Of course, in the background, servers still exist, humming away. But serverless architectures are stateless. They do their work by executing a bit of logic—a function—and calling out to other services to do whatever else they need. If you’re a developer who primarily builds applications using services via APIs or needs to respond to events, serverless architecture may prove to be the easiest, fastest, and least risky means for getting the job done.
In this article, I break down what serverless architecture really means, offer a detailed comparison of the major public cloud options, and shed light on a real-world serverless project under way at Coca-Cola.
Serverless computing defined: It’s all about the function
Serverless is a cloud computing service model that—like IaaS, PaaS, SaaS, BaaS, and CaaS—depends on ubiquitous, convenient, on-demand access to a dynamic shared pool of configurable network, storage, and compute resources. Serverless, however, takes a different approach to using those resources.
There is no agreed-upon definition of serverless computing, but a manifesto about the concept has emerged. With serverless, functions are the unit of deployment. No machines, VMs, or containers are visible to the programmer.
Among the chief services available for serverless in the cloud are AWS Lambda, Azure Functions, and Google Cloud Functions. In the cloud, “FaaS” (functions as a service) may be a better term. And when I say “function,” I really mean a function. Here’s an AWS Lambda example coded in Node.js:
exports.myHandler = function(event, context, callback) {
console.log(“value1 =" + event.key1);
// do stuff
callback(null, "some success message”);
}That’s it. Upload the function and wire it to a request or event. When your serverless hosting provider (in this case, AWS) detects a request has been made (a REST invocation, for example) or an event has occurred (say, a file is added to an S3 bucket), your function will be called with the passed-in arguments and your return parameters will be passed along as the result. It’s more complicated in practice, of course, because you can add security restrictions, for example, but that’s the essence.
Behind the scenes there are servers, of course, but as a developer, you never need to think about them. All you should know is your function.
Your function can be written in any language supported by your provider. All you need to do is map an incoming request or event into a function call. Each provider has its own set of supported languages, conventions, procedures, costs, capabilities, and restrictions (see the table below). But this is what the Serverless Manifesto means by “bring your own code.”
Your function can be arbitrarily complex, and it can call out to included libraries or external services through an API. To be scalable, a serverless function must only use services that are themselves scalable.
Depending on the provider, code can be written directly in an online editor or be uploaded as a code file, a .zip or .jar file, or a container. This is also a downside of serverless, because the tools for uploading and managing your code through the release cycle are still not very good, though numerous frameworks are stepping in to fill the void.
Of course, the code can’t truly be arbitrarily complex. There are provider-dependent restrictions. Each host has a max code upload size (50MB for AWS Lambda, for example). Each host has a max function execution time (between 1 and 300 seconds for AWS Lambda). Each function is also limited in the amount of memory it has available and the power of the CPU used. Want more memory, a better CPU, or longer execution time? You pay more. Billing is another difference between providers, as you’ll see below.
Serverless computing changes code management
You no longer have to deal with capacity planning, deployment, scaling, installation, patches, and so on. This is often called "no-ops" or "less-ops," but really it’s "different ops." Code still needs to be organized, developed, built, tested, versioned, released, logged, and monitored.
Because all you see is the function, your provider is in charge of activating your functions in response to any requests or events. When a request comes in and a free instance of the function isn’t available, the code must be allocated to a server and started. As a developer you do nothing. It’s on your provider to ensure there is enough capacity to handle the load. Of course, in the instance of a cold-startup scenario, the latency hit is one of the downsides of serverless.
The economics of serverless computing
With serverless, you pay for consumption and are charged only when your service runs. You never pay for idle compute time. The implications of this are vast. You can build out an entire infrastructure without paying a penny. Operational, development, and scaling costs are all reduced.
Contrast this with PaaS and IaaS, where you pay for capacity. A PaaS provider will manage servers for you, but your application has long-running processes that you’re always paying for, even if they sit idle. Capacity can be managed by building a load-sensitive autoscaling system, but you will always be paying for some excess capacity.
How to handle state in serverless computing
Because all you see is a function, there’s no place to store state. When a function is done executing, its compute resources can be garbage-collected and reused. Therefore, state must be stored in some other service like a database or a cache.
To control billing costs, providers place a maximum execution time on a function. Currently this is five minutes for AWS Lambda and Azure Functions. There’s a downside to execution limits. What if, for example, you are upgrading a database? Or your function makes a lot of calls to other services to return a result? Or your function has a lot of input to process? These operations can take a lot longer than five minutes in some instances.
Unless your function is simple, functions need to be coded as stateless, idempotent, event-driven services driven by a state machine that hold data in a persistent store between invocations. This can get complicated. But your normal cloud approaches still work. Divide inputs into batches and put them in a work queue, for example.
To help here, AWS has created a new service called Step Functions that implements a state machine and allows functions to last indefinitely. Really, AWS Lambda should be better rather than requiring a completely different and expensive service be used.
Metrics and logging in serverless computing
Although serverless narrows down the service interface to a single function, sometimes called a nanoservice, complexity is always conserved. With PaaS, the atomic unit of compute is the application. This has pluses and minuses. Because an application is large, it can be slow to start and stop; it can be hard to scale in response to demand; it can be hard to bill at a granular level. But PaaS is also easy to manage, monitor, and debug.
By spreading out code across a potentially large number of functions, serverless can be really hard to debug. The trace for logic flows is spread across a number of different log files, and there’s no connection between the calls. Logging and metrics are required, but it’s not enough. Tools in this area need to get better.
Serverless computing providers compared
So, how to get started? There are multiple options to begin rolling with serverless. The two broad buckets are to use the public cloud and to go with an on-premises solution.
Cloud-based serverless providers
Serverless has become table stakes for any public cloud, so the all major providers are developing their own product. Amazon has AWS Lambda since April 2015. Microsoft has Azure Functions since November 2016. Google has Google Cloud Functions, which is in beta.
In terms of deciding among the three, if you are already on the public cloud, it’s best to use the product from your current provider. A big part of the usefulness of serverless is the richness of the available services and events you can consume. Those choices are best inside your cloud. But if you’re getting started in the cloud and stability is important, then AWS Lambda has been around the longest and is the safest choice thus far.
For AWS Lambda, functions are independent, though in practice they are often managed in groups using a framework like Serverless. You are charged based on the number of requests for your functions and the time your code executes. If you want more CPU, you have to allocate more memory.
With Azure Functions, a function app is composed of one or more individual functions that are managed together by Azure App Service. A function app can use either a Consumption hosting plan or an App Service hosting plan. With a Consumption plan, a function app scales automatically and you pay by memory size and total execution time across all functions as measured in gigabyte-seconds. Using an App Service hosting plan billing is more like EC2.
Because Google Cloud Functions is still in beta, much about how functions operate and are billed remains unknown. We know there are two types of functions: HTTP functions and background functions. HTTP functions are directly invoked via HTTP(S). Background functions are invoked indirectly via a message on a Google Cloud Pub/Sub topic or a change in a Google Cloud Storage bucket.
On-premises serverless providers
Hosting serverless in your own datacenter is not dead simple yet, though it’s getting easier and there are multiple options. Still, you have to be willing to set up and maintain the infrastructure.