Choosing a FaaS (Function as a Service) provider in 2021

Functions as a service, FaaS, is most likely the most interacted with serverless product on the market. Function execution platforms really gained rise as more people got tired of setting up full containerized environments for simple code execution. The costs, overall maintenance, and cascading consequences of failures meant more people were looking for a lean context to execute one-off workers in the cloud.

The industry really rose to notoriety when AWS introduced AWS Lambda, a lambda being an anonymous function, and the service being that promise, as a service - these are anonymized functions that are not bound to a calling context, but respond to discrete events and take discrete inputs. They’re simple to reason about, simple to call, and most of all, they’re drastically more affordable to run, lending themselves really well to “pay for compute time”, not “pay for standby” which containers need to do.

Outlined above, there’s a few specific advantages and a few disadvantages (though decreasing by the day) to opting for a FaaS provider.

Pro: Maintenance

FaaS providers allow you to design, deploy, and execute functions – and only functions. You don’t need to maintain additional infrastructure. Setting up an environment to run a function is akin to running a restaurant to make yourself a cup of coffee from time to time.

Pro: Cost

Functions have obvious execution signatures which lend themselves to detailed billing. The more fine-tuned your billing, the more exact your cost to benefit analysis will be, and more often than not, that leads to cheaper costs on the whole.

Pro: Upgradable

Your functions can be independently updated, optimized, and measured. Scoping domain logic to independent functions allows for working in an iterative manner.

Cons: Higher Latency

While many tools have risen to solve this problem, serverless functions are subject to slow cold-start times and overall more latency than a dedicated execution environment.

Cons: Portability

Many FaaS providers have proprietary route handling logic

Up to a few years ago, the question about choosing a FaaS approach versus maintaining a dedicated execution environment was much more nuanced. Today, the developments of the FaaS ecosystem can handle the vast majority of all cloud execution needs. Choosing a provider, however, has simply adopted the former nuances.

When choosing a FaaS provider, the two most important questions to answer are related to workload and latency.

Workload dependent criteria

While all major FaaS providers are capable of handling simple workloads, not all of them are capable of offering the same breadth of services. Computationally intensive tasks including machine learning or resource intensive tasks like rendering all need robust service providers supporting those needs.

Some features such as ML processing is only even supported by a smaller number of service providers to begin with.

Latency dependent criteria

As the number of FaaS providers has increased, their product differentiation in solving common problems has also increased. One area of differentiation is where the code actually executes, either in centralized regions or at the edge.

Edge computing is a growing trend, set to explore in the coming few years. At the moment, 10% of enterprise data is currently created/stored outside of standard cloud center. By 2025, that is estimated to reach 75%. Edge computing replicates the code that is to be executed to smaller servers closer to the individual customers, which means that the amount of time, network resources, and energy required to execute my code is all reduced dramatically.

This is, of course, a hard problem to solve, thus not all providers are capable of offering these benefits. CDN providers, having solved many of these challenges in different contexts, are some of the first to embrace these patterns.

Other criteria

Some honorable mentions for things to consider when choosing a FaaS provider also include pricing, speed of prototype, and working with what you have. If you are running serverless workloads with hyper cost-sensitive business requirements, you may find yourself naturally limited to a certain set of providers.

If you are working on setting up “quick and dirty” prototypes, you’re not going to have the time to onboard with an account manager, high-tough, FaaS provider – and there’s plenty of those.

Lastly, if you have existing GCP or AWS infrastructure with billing accounts in place and stakeholder approved, it’s typically best practice to keep serverless services within a single chain of command for both credentialed access, unified billing, and observability tooling.

With so many providers popping up, it’s helpful to have a short analysis of where the different ones excel, and how they rank. Beyond the provider’s individual ability to offer support for the widest array of workloads, at the fastest speeds possible, at a reasonable cost, we need to consider developer efficiency, which has knock-on impacts on operational costs, as well.

DX considerations for FaaS providers

Developer experience for FaaS focuses around design, development, and deployment.

Design

Local simulation of a production environment allows you to ensure that your local code you tested will execute with some degree of predictability in a production environment. This is one of the most useful features for designing serverless functions where layers between your code and the hosting provider may introduce instability.

CLI based templating allows developers to quickly scaffold functions with consistency and best practices built in.

Code first configuration also allows for provisioning resources and designing serverless functions with higher degree of predictability and consistency, benefiting from version control and static analysis tooling.

Develop

Language selection is one of the most important factors when choosing a FaaS provider as different languages lend themselves best to different workload types. Being able to have a range of selection allows executing all serverless workloads with the same FaaS provider. Having to adapt operational code to a different language or runtime just because of FaaS requirements is a substantial hit on developer productivity.

Portable code, or generally abstracted code that is able to run equally across more than one vendor is another critical metric. If each vendor is implementing their own networking interfaces, this will also slow down developer productivity. Code designed for one execution environment should be able to be used with multiple providers.

Tangentially related, but when provider specific APIs are offered or required, providing strong typings for those APIs increases productivity even more, allowing developers to reduce context switching from IDE to documentation and back again.

Deploy

Continuous deployment is perhaps the highest development improvement, allowing versioning and roll-backs as an integrated part of the development process.

Where continuous deployment is not available, or even where it is, CLI based deployment and log tailing is another critical piece of developer experience improvement that reduces time to production, deployment errors, and onboarding of new team members.

FaaS comparison criteria

Abstracting all our results above, we’ll evaluate some of the more popular FaaS providers with the following criteria.

• Plugins, Integrations, and Libs
• Edge Ready
• Cost
• Local production simulation
• Language selection
• Infrastructure as code (IaC)
• CLI availability
• Continuous deployment

Comparing the Vendors

Below is a non-exhaustive list of FaaS providers. Our list doesn't include options such as Knative, or OpenFaaS which are platforms for running FaaS solutions themselves. The distinction turns grey quickly, but for the purposes of a general overview, we’ll be looking at providers offering a “hosted function” product proper.

Traditional providers

AWS Lamdba

You can’t really begin talking about FaaS providers without talking about Lambda, or really even AWS as a whole. Seen by many as the forerunner of cloud computing at scale, Lambda is the 800 pound gorilla in the room.

Google Cloud functions

GCP will of course have their own cloud computing options. Where raw computing resources may lag behind some alternatives, the knowledge APIs and libraries are the best of the best.

Azure functions

Microsoft is sure to bring their own FaaS solutions to the table, and with one of the most diverse set of supported languages, as well. No matter how you write your business logic, Microsoft's rich ecosystem and pre-existing billing approval with many companies make it a great place to host serverless workloads.

Vercel

Vercel has long been a favorite for rapid deployment in the JavaScript community. Having taken a developer obsessed focus to product offerings and being the makers of the wildly popular NextJS framework, they’ve been the gateway to serverless computing for many.

Gatsby Cloud functions

For those with front-end experience, Gatsby is a familiar name, having extolled the promises and benefits of static sites for years. Born of the static first approach is the need to still have a few processes running server side. Gatsby Cloud functions is a great place to see just how far the frontier of static plus serverless has really gone.

Netlify functions

Another well loved tool by front-end developers, Netlify is an all-inclusive solution for hosting web applications, cloud functions, and more. For those looking for less overhead than the big cloud providers, Netlify is a great option that can still perform as well as the rest of them.

Cloudflare Workers

Cloudflare workers are a newer entrant into the cloud computing ecosystem, but with the extensive experience of Cloudflare in edge networks, they’ve risen quickly in prominence.

Fly.io

Fly.io does a lot more than cloud computing, including multi-cloud, distributed databases. Their cloud computing, however, is why they’re in this list, so the stats are:

Oracle Functions

Rounding out their long standing strong feature set, oracle has surprisingly one of the more open and portable FaaS solutions available, allowing the product to be wholesale picked up and transferred into alternative cloud environments.

IBM Functions

Of course big blue wouldn’t be left out of the cloud revolution. As part of a massive push into the cloud, IBM has kept lock step with all the major cloud developments while maintaining the enterprise features and trust they’ve come to be counted on for by so many of the world’s biggest companies.

Tencent Cloud

Tencent is the juggernaut cloud you either hear everything or nothing about. Dominating the asian market as well as powering many of the popular apps arrayed across your phone, Tencent has a robust offering worth adding to your price comparison analysis.

Alibaba Cloud

Another of the asian giants, Alibaba is more than the everything store of the east, it boasts a growing and competitive cloud offering as well. Alibaba has a multitude of additional developer tools available including integrated IDEs and more.

Redhat Open Shift

Open Shift is a strong contender in cloud computing and robust development environments. Their FaaS support is an early beta preview, but worth keeping an eye on for all the benefits Redhat has to offer.

No-Code / Low-Code providers

These last providers don’t warrant an analysis block in that much of their core product offering is to abstract those implementation details away anyways. But for speed of prototyping, and, in many cases, aptly handling a large number of use cases, the low-code / no-code providers make the list.

TinyFunction

A very new entrant onto the scene, TinyFunction is, without a doubt, the fastest way to get a function executing at an endpoint. And that’s all it does. If you’re looking for a quick prototype method, look no further.

Pipedream

Pipedream is a robust platform that performs well under load. They provide a large number of integrations from Fitbit to finance. While still allowing for breakout code environments, they opt for a configuration over code interface design that allows anyone to drag-and-drop glue code with minimal effort.

Autocode

Autocode allows you to write any type of serverless code and implement with their large standard library of external service providers. With helpful log handling, team account management, and an intuitive online IDE, Autocode is a great solution to bridge the gap from pseudo-code to production.

Where does FaaS fit into the Hasura story? Hasura has two specific features that pair really well with serverless execution: actions and events.

With actions, you can design serverless workloads that execute behind a custom query or mutation field. If you need to perform custom authentication logic, this is a perfect use case for actions.

With events, you can also define serverless workloads that execute in reaction to events that happen in your database. Let’s say a user uploads a PDF to your storage engine, which in turn writes that file reference into your database, an event could begin processing that PDF with OCR for content extraction. Paired with subscriptions, this is a great way to execute long running processes.

A bonus opportunity for cloud execution is for micro GraphQL services that perform limited functionality that can then be added as remote schemas. Performance restrictions will limit the number of cases this should be used in production, but for some problems this can be a good solution!

Serverless execution is here to stay. With the rough 80/20 analysis method, serverless will be a dominant strategy for many companies that want to control costs, embrace low-op approaches to infrastructure, and focus on domain logic, not managing their own servers. Embracing FaaS providers is a great way to begin the serverless journey for incremental adoption and observing the benefits that it provides.