This article is intended for those who do not know of the existence of Function-as-a-Service, or, at some point heard about it, but, for one reason or another, decided not to use it. Maybe they did not really understand what this new architecture was for, or perhaps because they were afraid due to the lack of certainty around costs.
What is FaaS?
Before defining Function-as-a-Service or FaaS, we need to clear up a few points:
- FaaS is a Back-End technology
- FaaS is different from BaaS (Back-end as a Service). BaaS is a third-party service that we use within our applications, for example Auth0, an authentication service that we utilize in our solutions
- The difference. We need to program FaaS, whereas BaaS is only consumed.
- FaaS is Serverless. It does not have a server (although there is one somewhere, obviously), but we only pay for the invocation, and only when it is used, nothing else.
So, what is FaaS? It is a service provided by some infrastructure providers (AWS, Google Cloud, IBM Cloud, Azure, etc.), in which we upload our functions, and they are executed on demand by an event .
What can these functions do?
Practically anything we need, they have no limitations, and we only pay for their usage.
The charge that shows up on our credit card statements is calculated based on the following: we execute an event and the cloud service “turns on” the infrastructure where our function is, begins to execute our code, uses X amount of RAM for Y amount of time, and then shuts down again. The time from the infrastructure being “turned on” until it shuts down is what is charged.
Why should (or shouldn't) it be used?
It is difficult to define whether or not it is useful, as it really all depends on your application, your needs, how you design said application and how much you are willing to spend. Let’s do a slightly more in-depth analysis.
Needs
If your application receives three users per month it does not require a lot of CPU power or memory, so FaaS could be very cheap, or even free.
This is because most providers offer a free execution layer (AWS Free), which is an allowance to deploy your application without having to pay.
Going back to necessity, if our application is rarely used, and the infrastructure is only turned on when in use, we should not pay for a VM to be turned on all the time.
Now, if your application is a super platform used by thousands of users per day, consumes a lot of resources, and is not well designed (to work with serverless), then your credit card statement might bring with it a few headaches. What’s more, your application might not work in the way you are paying for.
Design
FaaS is oriented towards microservices, so if we have a large monolithic application it will be really difficult to use FaaS services (unless we are interested in doing a migration, which is another topic entirely).
Why can’t I use FaaS for my monolithic application?
- FaaS is serverless, therefore it is stateless- it does not save states. To put it another way, imagine that every time the front-end makes a request to our monolithic application the server is turned on, resolves the request, and then turned off again. So, we don't have an initial configuration, we don't have singletons, we don't have anything at all to store a session on the server in. Everything that we need to keep for a future request must be stored in a database and then retrieved. It would be, therefore, a waste of time and effort, and would really make our monolithic application unusable.
- FaaS has a limited execution time that we configure (AWS lambda is between 5 and 15 minutes), so if our process takes more than this amount of time the infrastructure shuts down, and everything that our process was doing is lost.
- FaaS is limited for processing. The amount of assigned CPU and RAM is limited, not because of financial constraints, but rather once we reach the power limit, we really cannot add any more. Added to this is the fact that there is a specified execution time, so we will be left with slow processes, most of which will not be able to finish.
- FaaS, by design, is not intended for our monolithic applications. In simple terms, in the process of resolving a request FaaS does the following: allocates the infrastructure (assembles the VM), displays the code (and in some cases compiles it), resolves the request, and then shuts down Now imagine such a cumbersome process for our monolithic solution- it would be a really a bad idea.
Costs
Let’s suppose that we really do need FaaS and our solution consists of Microservices that are well-suited, except for a couple of adjustments to this new technology- let’s take a look at the numbers.
We can’t talk about numbers without starting with the following: which is more important for your solution?
- Responding quickly to every query, regardless of the cost
- Responding in a reasonable time, having error controls in the event of failed transactions, and keeping costs manageable?
If you lean towards the second scenario, FaaS is probably not for you. In my experience, maintaining control over FaaS costs is not a simple task for solutions that are used daily by multiple users, mainly because there can be peaks in transactions. The biggest advantage of FaaS is that it scales horizontally for each request, meaning that before X request, we will have had X instances of the serverless function running in parallel, which is to say that, for each instance, you will be charged for the time the transaction lasts and how much RAM it consumes.
It is really very difficult to manage these numbers. For this reason many people are inclined to use a low-cost VM and then increase with demand and as our pockets deepen.
Conclusion
Analyze FaaS as a potential option for many processes that are really necessary (in the next section, I will explain some common use cases where FaaS really excels).
It is really cheap, but you have to know exactly what you are doing and how you are doing it. Take into account what the advantages and disadvantages of using it are.
Finally, FaaS is a great piece of technology, we just have to know when to use it and what to use it for. A very powerful tool is not always the right one in every circumstance. A chainsaw, for example, is great for cutting down trees, but not for slicing a cake.
Common use cases
In this section I want to present two or three examples where FaaS would really stand out and help us solve an otherwise cumbersome problem.
First of all, in my opinion, FaaS can help us to solve processes that are quick or resource-intensive for short periods of time that we need to run very sporadically, for example a batch process. It runs once a day, we need it to solve transactions quickly, and then it will not be used again until the next day.
Database Synchronization
Imagine that we have a piece of software for medical records from hospitals and each hospital (in different regions of a country) has a reduced version of the system. In this scenario we have to synchronize the patients’ medical records in a single, centralized database.
In this case I would use FaaS, to ensure that each hospital receives its updates and in turn each hospital sends it’s new data to the central hospital.
Why would it be better to use FaaS?
If we are not interested in how much data there is, because as it scales horizontally whether we have a single transaction or 1,000, we are sure that FaaS will manage to do the job without data loss, since each transaction is a new instance.
Additionally, if we open a new hospital there will not be any issues when it begins to send its data, since again, scalability will help solve this without having to worry about performance.
Black friday
As another possible example, imagine that we own an appliance store, and we do not usually make more than 10 sales per week, so our traffic is really low.
But if for some reason we go from 10 weekly sales to 100,000 believe me when I say we would need an infrastructure that scales quickly, is unattended (meaning that there is no IT person managing the infrastructure), and solves the problem for us.
Can you think of any other examples of Faas application? Please share any doubts, ideas, and examples.
About the Author
Mauricio Bergallo is a Systems Engineer with extensive knowledge in a variety of programming languages. Great experience and understanding with all aspects of the software development life cycle.
