There’s a glut of FaaS providers on the market right now. Cloud providers, database vendors, notification services, your plumber (probably): everyone’s doing it. And they’re constantly telling you how great it is.
Needless to say, it’s getting increasingly difficult to untangle this writhing pile of hype beasts. How do you choose between them? On what dimensions should you assess them?
Note: I’m going to try really hard not to talk about specific providers here even though we all know the main players are: AWS Lambda, Azure Functions, Google Cloud Functions and IBM Cloud Functions.
Event Sources (Triggers), Inputs & Outputs
HTTP triggered functions are the bare minimum.
In the ideal FaaS provider, the FaaS offering is maximally integrated with the provider’s other (non FaaS) offerings. It sits, spider-like at the center of a web whose tendrils attach to the providers identity, messaging, storage, analytics and monitoring services (and more). Even better if the FaaS provider allows integration with external alternatives to these offerings.
Maximally Integrated
What does “maximally integrated” mean? It means that if an application developer wishes, items like those on the list below are not only possible but trivial.
- The provider’s identity service can handle authentication and authorization for the FaaS offering.
- Messages in any of the provider’s messaging services can trigger functions (event sources) and functions can reliably send messages to those same messaging services (outputs)
- The FaaS service can retrieve and deliver related data from storage services as function input at invocation time e.g. when a function is triggered with an id (via HTTP, queue message or other source), make the document or database row with that id available to the function as input.
- Events in structured (e.g. relational db row changes) and unstructured (e.g. file and blob changes, no-SQL document changes) storage can trigger functions (event sources). Functions can reliably return changes that need to be made in those same storage services i.e. (output).
- Without much configuration or code, the provider’s monitoring service can monitor the FaaS offering including cross function triggers, messages and dependencies.
- The provider’s analytics service can delegate work to functions or can call them as a step during processing.
- The provider’s DevOps service can build for and deploy to the FaaS service
This dimension is crucially important because we don’t pick FaaS providers in isolation. The fast time to market and low overhead benefits of FaaS are only realizable when these integrations exist.
Overall Serverless Capability
I’ve written about what it really means to be serverless. Given those defining characteristics, I present to you this hot take prediction:
In five years, most cloud services on most cloud providers will offer a serverless tier.
Messaging services, databases, analytics services, monitoring, identity; all serverless. And not just “managed” either, but fully serverless per the definition in the linked post above.
Why is this important? Because serverless compute is only the beginning. It doesn’t make sense to only scale compute down to zero (to get those sweet savings) when you have to keep your high capacity messaging service , database, monitoring and analytics services running all the time.
The further along your FaaS provider is along this journey: making adjacent services (that should integrate with the FaaS service anyway) also serverless, the better it is for you. You can realize the cost benefits of serverless across most if not all components of your architecture.
Pricing Model
Free executions are table stakes.
This dimension is fairly overrated by many. The truth is most FaaS providers have similar pricing models ((per execution cost + per duration cost) – free executions). In most cases, you’ll save so much on costs compared to non-serverless compute that small differences in cost between the providers shouldn’t faze you.
If you’re past the comparison to non-serverless stage, and need to take advantage of cost savings between providers, the first step is to understand the nature of your workload. Is it made up of tens or hundreds of millions of very short executions? Or fewer, longer executions? Understanding your workload helps you pick which component of the pricing formula to bias for (e.g. execution count vs time)/
Performance
There’s a lot of great content out there about the performance of the different FaaS providers (check out Mikhail’s series on serverless performance). You should have a general idea (from blogs, benchmarks and tests you run yourself) of the basics of FaaS performance, stuff like:
- Cold start times
- Scaling profile (linear? bursty?)
- Execution time limits (5 minutes? 15 minutes?)
- Compute resources available to a single instance (CPU & Memory)
Some other overlooked questions to ask about FaaS performance are:
- What are the overall limits on the number of instances? You should know this because FaaS scale out is finite.
- What are the performance knobs available (per trigger type) and can I control them at the individual function level?
- What is the concurrency model for each trigger?
Language Support & Tooling
You’ll of course want to make sure the provider supports the language(s) you’re interested in and any quirks that language brings to FaaS (e.g. how does being single-threaded affect throughput). Some other important questions to ask:
- Can you write and debug and test the functions locally?
- Is it possible to emulate some (if not all) your functions dependencies locally?
- Does your devops infrastructure build and deploy the functions?
- What is the unit of deployment or grouping (if any)? Can functions share code? or communicate with each other?
X Factor
In many ways, FaaS providers aren’t that different. At any one time though, some providers will offer unique FaaS capabilities that the others don’t have yet. These x-factors can be a huge weight on the scales when choosing a provider. Some examples are:
- Extensions to core FaaS that enables stateful FaaS. This is incredibly important for many scenarios and typically has not been possible with FaaS.
- Pricing models that enable flexibility e.g. unlimited execution time or reduced cold start. Note that this is usually in exchange for moving leftwards on the serverless spectrum (i.e. less serverless).
Summary
It’s not easy to evaluate the FaaS providers. The constant jostling for FaaS dollars means the trend is always towards feature parity. But as we’ve seen there are obvious and non obvious dimensions to assess them on.
So go on. Pick one.