FaaS (short for function as a service, and often called serverless functions) describes platforms that allow developers to publish their code to the cloud as a set of functions. A FaaS architecture can deploy, execute, and scale these functions up or down as necessary depending on load, and often the developer pays nothing at all when the functions aren't being executed.
FaaS functions are hosted for you on a platform such as AWS Lambda or MongoDB App Services. Because the developer only pays for the time the functions take to execute, this makes them attractive for applications with intermittent workloads, like scheduled tasks, or workloads that depend on some kind of periodic driver.
There are a number of different FaaS providers, each supporting a different set of languages for writing functions, and each with different characteristics and limitations. The primary concern when choosing a platform will usually be the other services available on the host platform, as hosting functions close to the underlying data platform can be important for performance.
Amazon was the first big cloud provider to release a FaaS product. AWS Lambda natively supports functions written in Java, Go, PowerShell, Node.js, C#, Python, and Ruby. They also provide an API that allows you to write your functions in any programming language you prefer.
Because MongoDB Atlas clusters, including serverless instances, can be hosted on AWS, Lambda is a good choice if you're planning to integrate with MongoDB as well as other AWS services. Read more about using AWS Lambda functions with MongoDB.
Google's Cloud Function service support functions written in Node.js, Python, Go, Java, C#, Ruby, and PHP.
MongoDB clusters can be hosted on Google Cloud, so Google Cloud Functions are a good choice if your application will be built with MongoDB Atlas along with other Google Cloud services.
MongoDB Atlas supports Azure, so Azure Functions can integrate well with your MongoDB data.
FaaS platforms package function code into containers or VMs. The host platform will then manage the routing of events to the function containers and will scale them up or down as demand requires.
FaaS is a specialized form of serverless. Serverless is a broader description for platforms that abstract away the hardware they run on. They usually charge on a per-usage basis, and ideally they scale to zero, meaning minimum cost for applications when they are not in active use.
The main advantages of FaaS are:
The primary disadvantages are that most FaaS services have a proprietary API for writing FaaS functions; some applications don't easily decompose into separate functions without a shared state; and existing applications may have to be rearchitected to push state into a shared datastore, like MongoDB.
FaaS architectures are event-based. The events that trigger the running of your function may be an HTTPS request that has been routed to your function, a message passed from a message queue, a scheduled triggering of your function, or even a call from another hosted function.
Because each function may be hosted in a separate VM, or even a different server, in most cases the persistent or shared state of your functions is limited by the hosting FaaS platform. Ideally, functions hosted in a FaaS are totally stateless, which means they can be easily scaled independently by the host platform.
Functions are charged for the amount of time they execute. For this reason, it can be a good idea to optimize to keep the startup time and running time as low as possible. Each platform will have a time limitation after which functions will be forcibly shut down, so for this reason, it's important to ensure that functions at least execute in a reasonable amount of time.
Functions can scale more or less linearly, providing you can store your functions' data in a suitably scalable database (like MongoDB!). In applications where the application builds up significant state in memory, a FaaS solution may not be suitable.
Because MongoDB Atlas can deploy and manage clusters on all the three major cloud platforms (or even across two or more platforms!), choosing a particular cloud provider's function offering comes down more to the other services offered by that cloud platform.
If you're integrating between your cloud provider's function offering and MongoDB, you have two choices. The first is to use the MongoDB driver for your language (such as pymongo for Python functions). The second is to use the new MongoDB Data API platform.
When using the native MongoDB driver, ensure that the driver is cached between function calls. There's a cost to initializing the MongoDB driver, and so if you can share instances between different function calls, that will reduce your functions' run time.
The MongoDB Data API can make different requests over HTTPS, meaning that it takes less time to initialize, and thus feels more native to a FaaS platform. On the other hand, there is more overhead per-call, so if you can use the MongoDB driver efficiently on your platform, you should.
FaaS is good for applications without shared or persistent state that must be stored in RAM. This makes it particularly suitable for applications where shared state is stored in a database, meaning that the functions can spin up and execute in the minimum amount of time, storing all necessary data in the underlying database. Obviously, this means that your database needs to be able to scale alongside the execution of your FaaS functions.
Fundamentally, the key features of functions as a service are:
If these fit your requirements, then FaaS may be a good choice for you.
Generally, yes. FaaS is a platform that is usually provided by your cloud provider. But there's nothing to stop you from hosting your own instance of faasd (a lightweight FaaS server) and hosting your own functions on something as simple as a Raspberry Pi! The primary thing that differentiates FaaS from other architectures is the ability to deploy one or more functions to a system that will handle running them independently.
PaaS (or platform as a service) is commonly used to describe cloud platforms that abstract away the infrastructure that they run on. A good example is Vercel, which allows developers to build next.js applications and deploy them to Vercel's infrastructure without worrying about how that underlying infrastructure works.
In this way, FaaS can be considered a subset of PaaS, where the underlying unit of code is a function, which is a relatively simple unit consisting of inputs, outputs, and persistent services (like databases) that are available for various tasks.
CaaS is short for containers as a service. The primary difference between CaaS and FaaS is that although both are deployed within containers (or lightweight VMs, in the case of AWS Lambda), in the case of CaaS, you have full control over the contents of the container. With a CaaS platform, you would author an entire service (usually following microservice idioms) and then package that up as a container. The host CaaS platform takes care of deploying, maintaining, and scaling these containers as necessary.
With a FaaS platform, the developer doesn't have control over the contents of the container. The developer only has control over the function's code and a list of dependencies required by that code. The rest of the container's contents is managed by the FaaS platform, and provides the necessary processes and supporting code to run and monitor the deployed function.