Living the Golden Rule (of Cloud Architecture) #2: Function-as-a-Service (FaaS)

I previously defined my Golden Rule of Cloud Architecture as “Never pay for unused capacity,” and gave one approach of how to actually do that using horizontal scaling. In this post I’ll look at another possible approach: using Functions-as-a-Service (FaaS) — i.e. AWS Lambda, Google CloudFunctions, Azure Functions, etc.

If your goal is to avoid paying for unused capacity, then serverless technologies are an obvious thing to look at. And they certainly can help — with the emphasis on the “can” implying that they don’t always help. You shouldn’t blindly assume that serverless will always save you money, just as you shouldn’t assume that the Cloud will always save you money (keep reading for an example of how using FaaS demonstrates that caveat).

Functions-as-a-Service give you an opportunity to package your application logic so that it can be run only when needed, and you pay only for what you use — no need to have idle instances sitting around. Sounds good, right? But there are some limitations to be aware of.

With FaaS solutions your logic may be limited to a maximum execution time per invocation, so depending upon the platform you’re using it may not be suitable for long-running tasks. You may also have to choose a maximum amount of memory to allocate in advance, the amount of direct-attached disk you have access to may be limited, and you can’t rely on maintaining state between invocations or sharing state (directly) between multiple instances of the function executing concurrently. These limitations may make FaaS unsuitable for some use cases.

But assuming you can package your application logic into functions, is it guaranteed to avoid unused capacity and save you money? Not necessarily.

One thing to be aware of with FaaS offerings is that you may be billed for execution time in, say, 100ms increments. If your function only runs for 15–20ms on average, for example, you will still be charged for 100ms per invocation. So there is a possibility that you will be paying for some unused capacity. That may be okay if it is still cheaper than a server-based alternative — the Golden Rule does include a caveat saying that it is okay to pay for unused capacity if it is cheaper than the alternatives. But don’t be complacent about being billed for the unused capacity, and be on the lookout for ways to improve utilization. For example, if your function is being triggered by messages from a queue, it may be possible to batch processing of multiple messages into a single function invocation which can improve utilization on average.

Another important thing to be aware of is that you need to be careful about using FaaS for tasks that involve a lot of waiting for I/O to complete. You’re going to be charged for the total time that your function executes, whether it is sitting idle for most of that time or not. So if you’re doing “slow” I/O, such as downloading a file from the Internet, then you may want to think about whether FaaS is the best approach. If you have a large volume of work to do, it may make sense to do I/O-intensive tasks in an inexpensive, long-running instance, and use FaaS just to initiate the I/O and to process the results once they are available. You can use an approach like horizontal scaling to minimize the amount you pay for the servers sitting idle.

No matter how efficiently you use FaaS, if you have a large enough volume of requests there may come a point at which it is more cost effective to deploy a set of instances to handle the work. You still want to follow the Golden Rule and keep those instances busy, scaling horizontally if needed — which is definitely more complex than simply using FaaS. The extra complexity may justify the cost savings though.

So there are definitely some gotchas to be aware of when using FaaS, and it doesn’t work in all cases. But when it does work for you it can be a simple, easy to use, and effective way to both scale effectively and save money. It is definitely an approach worth considering.