This text was taken from the book and a Udemy course The DevOps Toolkit: Catalog, Patterns, And Blueprints
Help us choose the next subject for the course by filling in a survey at https://www.devopsparadox.com/survey
Personally, I do not think that managed Functions as a Service are a good idea. Functions are too small for my taste. The execution model in which each request is served by a fresh instance is deeply flawed. The pricing is too high for my budget.
All that being said, I can see use cases where managed FaaS is a perfect fit, but only if that would be the only flavor of serverless deployments. But it’s not, even though many are putting the equation between FaaS and serverless computing.
Functions as a Service became very popular with the introduction of AWS Lambda. That is not to say that Lambda is the first implementation of serverless computing (it is not), but that Lambda is what brought the actual implementation of some of the principles to the masses. Lambda is to serverless what Docker is to containers. Both brought the implementation of existing concepts to mainstream.
As a result of the popularization of Lambda, people associate serverless with functions. That is wrong. It is a misunderstanding of what serverless is. FaaS is only one flavor of serverless. It is one possible path we can take towards the same goal. But there are others. There are other ways to do serverless deployments, and we will explore them soon.
More often than not, FaaS is not the right solution for the vast majority of workloads. Writing only functions is limiting. Having limits to how long a process can run, which language it is written in, how many requests it can handle, and so on and so forth, is too constraining for my taste. I understand the need to restrict choices. That’s the best and the easiest way to simplify things and provide a service everyone can use. But it is deeply flawed.
Serverless computing, on the other hand, has much more to offer. Companies and communities are experimenting with different ways we can fulfill on the promise of making deployment and management of our applications easier. A few years from now, I am confident that we will look at managed FaaS like Lambda, Azure Functions, and Google Cloud Functions, as pioneers. They will be services that made serverless computing popular, but also that were failed experiments. Almost all initial attempts at something new turn out to be failures. Mesos is an excellent example of a scheduler that was a pioneer, but failed and was replaced with Kubernetes.
Similarly, I believe that the same future is waiting for us with managed FaaS. It will be replaced with a better flavor of serverless computing. As a matter of fact, we already have better implementations of serverless computing, and we will explore them soon.
Use FaaS if you have a good use case for it. But limit your usage of it only to "special" cases. Do not go crazy and convert everything into functions. If you are eager to use serverless deployments, give me a bit more time to introduce you to other options before deciding which is the right one for you, if any.
All in all, I do believe that the future is in Serverless computing. However, Functions as a Service (FaaS) is not it. FaaS is not going to be the most commonly used nor the best serverless flavor. We are at the begining. Other solutions will prevail. While we might not yet know what those other solutions are, there are a few common properties that will likely become a norm across most serverless computing solutions.