No More Servers - FaaS with Firebase Cloud Functions

It’s easier than ever to “spin up” or deploy your own server to support your business. Of course, it’s not exactly your own server, the actual hardware and base configuration is controlled by the Amazons, Googles, Microsofts, and IBMs of the world.

However, you get to put your own software on there without worrying about where the server is located, the utility bills, replacement costs, etc. Now, we can even avoid configuring our servers and scaling our applications with Functions as a Service (FaaS).

What is FaaS?

So let’s break that down and go over a simple scenario of using a FaaS, in this case Google’s Firebase Cloud Functions, which we have been using at Leverege.

An Example - IoT Detection of Flooding

However, I don’t want to run a server all year round to listen for a sensor alert – rain is unpredictable and seasonal. Instead, I decide to use Google’s FaaS, Firebase Cloud Function, which will run only when needed to reduce costs.

So how does it work?

If the water level sensor detects the water is too high, then it can send an “event” to Cloud Functions. So then Cloud Functions receives the event, and starts up my serverless text message function. Notice that the text message function was not already running and was “event-triggered.” Also, Google started up my function and is executing it on their servers, so I don’t have to manage it. While FaaS is called “serverless,” it’s serverless for the consumer, not the FaaS vendor who still has to run servers.

Next, my text message function processes the event and sends Nicole the appropriate text message. After the function execution is completed (the text message was sent), my text message function is terminated.

All of this takes at most a tenth of a second from the time the event was sent from the water level sensor. This process happens every time the water level sensor sends an event, so the text message function is “ephemeral”, or only lasting for a short period of time.

A FaaS application can be thought of as a math function (see below). The input is an event, the output is the result of the function. Like a math function, a FaaS application is essentially “stateless”, it has no knowledge of anything except its inputs and is unable to hold an internal state.

[caption id="attachment_7738" align="aligncenter" width="448"]

Below is a quick bulleted list of pros and cons of FaaS from Mike Roberts’ article. The pros and cons can give you a good idea of what type of applications are best used for FaaS. Afterwards, we'll go over more things that are specific to Google’s Firebase Cloud Functions.

Pros

• Operational costs - You do not need to own or run your own server, you can let the vendor do that for you. There is no need to hire a DevOps person as the vendor also handles scaling!
• Development – FaaS applications can be written in many popular languages and a product engineer with little operational and deployment experience could easily write and deploy FaaS applications.
• Scaling – You only pay for what you need when you need it. This really helps for occasional traffic and/or inconsistent traffic. If you have a lot of traffic all of a sudden, your vendor can “spin up” more instances of your FaaS application. Like the flooding example, if there is occasional traffic, then there is no reason to have a dedicated server. This is a huge win in terms of costs for your business.
• Experimentation – Playing off the development benefit, it’s easy for a developer to write a quick FaaS application and deploy it, allowing for many quick tests on specific computations rather than having to deploy a whole system. It also allows developers to quickly change an application on the fly if there’s a bug.

Cons

• Vendor control – While there are many pros to allowing a vendor to run your functions, there are cons as well. If the vendor has an issue, your application will also have issues, such as long downtimes, API changes, limits on requests, etc.
• Latency – There are two issues here. 1) FaaS applications are not immediately available because they have to be “spun up” by your vendor, and 2) FaaS vendors run multiple instances of various customer applications on the same machine, so there is a possibility of latency due to sharing resources.
• Security – Because your application isn’t on one server anymore, there are security holes when using FaaS functions. Each individual function needs to be secure rather than one server.
• Stateless – FaaS functions last for such a short amount of time, they cannot feasibly store state. So in order to get the state of a user or device, a FaaS needs to query a database or server.

Firebase Cloud Functions

1) Ease of Development and Deployment

Typescript is “used in almost four times as many pull requests as last year” (GitHub). Furthermore, deploying Cloud Functions is very easy, it only takes two terminal commands, firebase use <project name> and firebase deploy --only functions.  

2) Integration with Firebase and Firestore

Firestore is Google’s new document database implementation which is currently in beta. Firestore allows for easier querying than Firebase and scales better. If you want to read about the differences between these two database implementations, check out Cloud FireStore, Firebase's More Scalable Older Brother.

3) Overall Integration with GCP

This Cloud Function could be easily and quickly changed based off of promotions or campaigns your company is running. That type of ease and flexibility is really powerful. Cloud Functions and Google Cloud Platform products are only going to get more integrated with each other, which is really exciting.

FaaS is not for all applications, but it is definitely useful and here to stay. Whenever you are thinking of deploying a whole server, think of whether you could create a FaaS application instead. Personally, Firebase Cloud Functions have worked well for my team and me, so give that a try if you’re looking to use FaaS.