Function as a service (FaaS), also known as “serverless” computing, is an option for deploying applications in the cloud. It’s been around for almost a decade and has been available from the mainstream cloud providers for at least four years. For example, Amazon released AWS Lambdas in late 2014. Microsoft made Azure functions available in early 2016.
But, what exactly is serverless computing? When is it the right choice? When you’re designing an application to use a serverless architecture, what do you need to consider?
Let’s take a look.
What is FaaS?
FaaS simplifies deploying applications to the cloud. With serverless computing, you install a piece of business logic, a “function,” on a cloud platform. The platform executes the function on demand. So you can run backend code without provisioning or maintaining servers. But that’s only part of the story.
The cloud platform makes the function available and manages resource allocation for you. If the system needs to accommodate 100 simultaneous requests, it allocates 100 (or more) copies of your service. If demand drops to two concurrent requests, it destroys the unneeded ones. You pay for the resources your functions use, and only when your functions need them.
“Serverless” computing has servers, but they’re not your problem. The cloud provider manages them for you.
So we’ve already covered three of the main advantages of FaaS: managing servers is no longer your problem, the platform manages horizontal scaling for you, and you only pay for what you use.
By managing the servers for you, FaaS abstracts the server platform away from your application too. You can write your functions in almost any language. You can access other cloud resources like databases and caches. If you conform to the platform’s defined interfaces, your service will work. This freedom doesn’t come for free, though. FaaS places constraints on functions, and it’s not always the best option.
The automatic scaling you get with serverless computing is a significant benefit. It saves you money and protects you from unexpected spikes in usage. As long as you pay your bill, your application will remain available.
Without dynamic scaling, you have to size your system based on the most substantial level of utilization, not its average. This means paying for resources that spend most of their time doing nothing. Even then, the sizing is an estimate based on past usage. What happens when demand exceeds that estimate?
Another option is to roll your own cloud scaling using technology like Docker. This solution still means incurring a great deal of overhead in both cloud resources and personnel. Containers and orchestration provide you with dynamic scaling and excellent recovery capabilities, but you still need servers and skilled DevOps people.
FaaS applications are simple to deploy and update. They are, as the name implies, functions. All you need to do is upload your compiled code and tell the platform how to provision it. You don’t need to enable extra systems or be a cloud expert.
When Is FaaS a Good Fit?
So why isn’t everyone migrating their applications to serverless? FaaS isn’t always the best option, or even possible, for some applications. There are design constraints. But first, let’s look at when it’s a good fit.
The name “Function as a Service” isn’t an accident or affectation. Your code needs to operate like a function. It must be stateless, or you need to externalize state to a database or filesystem.
Fowler has a concise explanation here:
FaaS functions have significant restrictions when it comes to local (machine/instance-bound) state—i.e., data that you store in variables in memory, or data that you write to local disk. You do have such storage available, but you have no guarantee that such state is persisted across multiple invocations, and, more strongly, you should not assume that state from one invocation of a function will be available to another invocation of the same function. FaaS functions are therefore often described as stateless, but it’s more accurate to say that any state of a FaaS function that is required to be persistent needs to be externalized outside of the FaaS function instance.
This restriction makes perfect sense. FaaS provides scaling for you, but without demanding any intimate application knowledge. It can only do this by assuming that it doesn’t have to manage any application state for you.
So if your functions don’t maintain state or solely rely on external resources for it, they’re a good fit for FaaS. RESTful applications are a good example. The functions externalize resource state while clients bear responsibility for maintaining their own.
An event-driven service that needs horizontal scaling can enjoy running as a function. FaaS platforms use the events to create instances of the functions and react based on the volume of requests.
While RESTFul and other event-driven applications are a good fit, work that runs on a schedule is too. Instead of paying for one or more servers that sit dormant most of the time, you can write the job as a function.
When Is FaaS a Bad Fit?
The limitation on application state isn’t the only constraint on serverless computing. There are a few more, and they may prevent your application from running as one or more functions. Or, they might mean you need to rethink your design.
The platform loads functions on demand. They should start up quickly, usually in milliseconds. Then the platform immediately gives them a request. When processing completes, it terminates them. The platform may reuse an instance with a “warm start” to save time, but the function cannot rely on this. This is where the constraint on state comes from. But it also means that an application that performs a lot of initialization will not work well with FaaS.
AWS limits Lambdas to 15 minutes of execution time. Azure limits its Functions to 10 minutes. This is plenty of time for an API call, but it might not be for a scheduled job. Unfortunately, functions have hard limits on execution time.
FaaS might also be a bad fit if you’re concerned about vendor lock-in and can’t figure out how to code around it. If you’re going to have someone else run your code on their platform, you need to write to their API. Depending on how you structure your code, you may be able to avoid lock-in. Or you might not care. But if you do, serverless might not be the right solution.
FaaS Decreases Cost and Increases Efficiency
Cloud vendors bill FaaS based on consumption. You pay for what you use after you use it. You can even control this by setting limits on usage if your application is amenable to that. This is in stark contrast to provisioning servers in advance, based on the anticipated load, where you are always hoping that you pay for more than you need.
Not having to run servers also means less, or no, staff to maintain them. Everything in serverless architecture is managed by the cloud provider, eliminating the need for system administration. Even if you can only offload part of your application to serverless, you can save on staff, or allow them to focus on the critical parts of your mission.
Does FaaS Work For You?
Serverless computing has a lot to offer. It provides an easy path to migrating or building new services in the cloud. Without the overhead of managing servers, and with the increased efficiency of paying for only what you need, you can focus on your business and your application. If you haven’t taken a good look at it yet, there’s no better time than now.
This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)
More action. Less Noise
Get a weekly dose of news from the observability world.Close