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?
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.
Design
- 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
- 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?