What is serverless computing: Infrastructure freedom for devs

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.

This is a fast-moving space. Vendors are jockeying for position, trying to carve out a market in the shadow of the giant public cloud providers. Tread carefully. Every application portability promise should be viewed with skepticism.

Azure Stack. If your goal is to run on-premises like the public cloud, then Azure Stack looks to be the best bet. It holds great promise as a cloud-equivalent serverless option, though that does beg the qquestion of why not just use the cloud.

IBM OpenWhisk. OpenWhisk is IBM’s FaaS that can be either hosted or on-premises. It has an API gateway, native Swift and Node.js support, plus Docker image support. It is likely to see more adoption this year as it is one of the better-supported products.

Iron.io. Iron.io was the first serverless provider, but now has to make its way in a world of big cloud providers. It offers two options: IronFunctions and Project Kratos.

Project Kratos is an embrace strategy: It enables enterprises to run AWS Lambda functionality in any cloud provider, as well as on-premises, eliminating vendor lockin.

IronFunctions is the extend strategy: It is an open source serverless/FaaS platform based on Docker that you can run anywhere: on public, private, and hybrid clouds, even on your own laptop.

Fission.io. Fission.io is an interesting new approach to serverless that uses Kubernetes for its cloud infrastructure. Kubernetes takes care of cluster management, scheduling, and networking. There’s a line of thought that Kubernetes, because it has a vibrant and productive developer community, will emerge the winner as the open source cloud infrastructure. Building a serverless product on Kubernetes makes for an interesting alternate on-premises stack.

OpenStack. OpenStack currently doesn’t have native support for FaaS, but there’s something in the works called Project Picasso. It has two main components: Picasso API and IronFunctions. Picasso uses the back-end container engine provided by IronFunctions.

Roll your own. Serverless is not rocket science. You can build your own serverless platform on top of your current infrastructure and get all the benefits without having to migrate to a new stack. This is a good option if you don’t want to treat your datacenter like it’s a cloud.

Serverless computing case study: Coca-Cola

How does serverless work in the real world? Here’s a video, Coca-Cola: Running Serverless Applications with Enterprise Requirements, in which Michael Connor, director of technical strategy at Coca-Cola North America, explains how Coca-Cola uses AWS Lambda to process transactions from its vending machines.

Some findings:

• Serverless is nearly three times cheaper than IaaS. But at about 80 million transactions per month, IaaS becomes more attractive.
• Coca-Cola now mandates serverless solutions or requires a justification for why you won’t use serverless.
• Serverless doesn’t solve all your problems, but it does solve problems that aren’t contributing to the bottom line.
• Serverless does not lay waste to head count. It removes muck work. Patching servers doesn’t help sell refreshments.

Coca-Cola measured where it spent time when using IaaS vs. serverless:

Only 39 percent of time was spent delivering business projects when using IaaS. After moving to serverless, Coca-Cola spent 68 percent of its time on business projects, with room for improvement.

After moving to AWS, there was an initial rush of spinning up servers in minutes when it used to take weeks. That rush wears off as you realize the cost of maintaining servers over their lifetime. Serverless reduces this pain, says Coca-Cola’s Connor.

Coca-Cola also wants developers developing, not performing devops duties. Moving to serverless drastically reduced the amount of ops needed, and the type of ops still in play is more in line with a developer’s skill set.

The vending machine example in question involves the following:

• When you buy something at a vending machine you swipe your card.
• The transaction goes from the vending machine to a Payment Gateway.
• The Payment Gateway submits a REST API call into Amazon API Gateway.
• The API Gateway calls a Lambda function.
• The function handles all the business logic: transactions, credits, debits, and so on.
• Notifications are sent back to users via an Apple/Android Push Notification service. They in turn submit that back to Apple Pay/Android Pay, so you can see a debit in the wallet on your device.
• Then there are “buy 10 get one free” and other promotions on top of all this.

With Lambda, all this happens in under a second, and Amazon charges 1/1,000th of a penny. Plus, Coca-Cola is getting charged only if a customer executes a transaction. Otherwise, Coca-Cola pays nothing. For Lambda, getting about 30 million calls a month, the cost was $4,490 per year.

Using an AWS IaaS approach, the cost for a T2 Medium Server is about $56 per month. The fully burdened cost is nearly five times that: $250 = $56 (server) + $150 (management: patching, on call, accounting) + $30 (security: antivirus) + $14 (automation: Puppet, Chef, Ansible). With six T2 Medium Servers the cost was $12,864 per year, making the Lambda solution 65 percent cheaper than the IaaS solution.

Of course, there is a break-even point. If you are running a huge number of transactions it becomes cheaper to run your own machines. For this example, at about 80 million hits per month, moving to IaaS started to look attractive to Coca-Cola.

One other detail to note from this case study is how serverless handles long-tail life cycles. Let’s say you push out your first ten vending machines. With IaaS, you pay $13,000 for that cluster. What about the end of life? When you have those last ten machines that haven’t quite sunsetted yet, you are still paying $13,000 per year for IaaS. Serverless, however, ramps up and down elegantly. When you get to less than a million hits per month, there’s a 99 percent cost savings.

The cost of going serverless is compelling unless you’re running huge volumes. How many services are you running at a lower volume rate?

Related serverless computing articles

• Serverless: AWS vs. Google Cloud vs. Microsoft Azure
• How to use Microsoft’s Azure Functions
• How to use AWS Lambda for serverless computing
• Review: AWS Lambda redefines “on demand”
• Microsoft Azure Functions locks in on serverless computing
• Build ’em now! 5 uses for serverless frameworks