I'm sure now most of you, if not all, have heard about serverless and how trendy & sexy it's. But what bothered me the most was when to use one?
But before answering that, let’s answer the what & why first and by knowing that the answer will reveal itself.
What is Serverless?
So what is serverless? Does it mean that there is no server? Nope, that's not the case. It means that you are not responsible for managing your infrastructure. All you have to do is write some logic to be executed when a certain something happens. Certain something could be an event, for example, a file uploaded or an HTTP call.
Why Serverless?
- Scaling/unpredictable workload.
While the scaling point could be achieved by many solutions already, for example, Kubernetes with KDA could do the same effect, but again most of the cloud providers will provide this functionality out of the box and will be more efficient as you are only paying for the resources you used.
- Cost
Theoretically speaking, cost should be very low as you are only paying for what you use, meaning the function would only work when some sort of event happens, and you are only paying for the time the function took to finish the work.
- Simplicity/Rapid development
You only care about your business logic. Everything else is not your responsibility, no server, no number of replicas, nothing you want to do 1 2 3 just write 1 2 3.
- Security
It's easy to apply a principle such as least privilege where you define the permissions for each function so that there is no such master function (you shouldn't have) that does it all and have permission for everything besides that the cloud provider should provide the latest updated versions of OS that runs your function so you shouldn't worry about that.
The bad side?
What are the limitations?
- Cold Start
The time the cloud provider takes to lunch your function, and it depends on how frequent the function was called sometimes, it takes 1 - 2s.
- Can't store things in memory/files.
When your function gets triggered, it runs on an ephemeral disk which is something that gets deleted after the function completes. The same thing applies to the used memory.
- Execution time
Some cloud providers limit your function running time to a certain number of minutes, so if you want to process something that takes a long time, it’s a big no.
- Vendor lockin
This happens when your implementation & logic rely on the infrastructure of a specific cloud provider. For example, if you are using AWS, you will end up relying on many services & permission related only to AWS, which means if you want to switch to another cloud provider, you will suffer a little.
- Hard to test
While frameworks such as serverless & SAM could allow you to run your function offline, your function won’t run without storage or a database. So you will end up using some resources in the process and maybe cost you a bit compared to the normal way.
When to go serverless?
Now, this is a hard question to answer. For me, it depends on the problem you are trying to resolve, so if you are doing a time-consuming task, most likely using functions won’t be good enough for you the same thing for handling real-time apps.
On the other hand, if you want something rapid to develop and you are short on the money side, this is definitely something to consider.
Top comments (1)
I would definitely argue with this.
In reality it is very hard to hire engineers that are skilled enough to go full serverless from day 1 without significantly lowering their output.
Everyone lists AWS/Azure/GCP whatever in their CV's but then when going deeper you realise they have written 3 lambdas in total over the last decade.
Sure they can copy paste function in whatever language into AWS console but what about debugging? What about testing ? Do they know how to orchestrate end-to-end serverless test ? Do they know how to setup feature env?
Rapid development my a**