Debunking Serverless: What People Get Wrong
Debunking Serverless: What People Get Wrong
Raise the curtain on serverless and review some of these myths that still seem to surround the technology.
Join the DZone community and get the full member experience.Join For Free
There's a lot of mystery surrounding this new technology and even for the more tech-savvy of us, there are a few things that we get wrong when talking about Serverless. I'll try to address some of them in the article below and if anybody would like to hit me up with questions (or just hit me) I'm on Twitter way too much already so why not take this opportunity to spend more time on social media?
1. Serverless Will Replace All Monoliths
This is a good one. Serverless is often sold as a "silver bullet" for old architectures, a universal solution for every computer scenario out there, the end of DevOps as we know it. This couldn't be further from the truth. Serverless is not about to bring any sort of apocalypse on everyone and while it brings a lot of benefits to the table, there are still going to be plenty of use cases that call for traditional architectures like monoliths.
Serverless goes best with event-driven programming, and while this is great, not every system out there can work like that. If you have constant workloads, Serverless might not be for you. If you have long-running functions, you might want to look elsewhere as Serverless has some unavoidable limitations that you won't be able to circumvent with ease.
What About All the People that Used to Manage and Provision the Infrastructure?
It's true, you won't need people to handle the provisioning, updates, upgrades, etc., for your system since all of that is handled by your vendor. But you will need people that understand your system and can find the issues when things go sideways or can optimize your stack when need be. Nobody is losing their jobs here! They just need to do a slightly different job and try to understand how serverless architecture works.
2. Serverless is Not Secure
Nope, wrong again! Serverless is basically a number of containers that have a limited life span meaning that the attack has a limited time to "sink its teeth in." Some may argue that since Serverless has many different access points, it increases the vulnerability since the attack vector is large. I completely agree here, but this is more about the way you design your application and what type of permission you provide to your functions.
Using Serverless does not absolve you from writing bad code!
What you need to watch for are the libraries you are using in your projects. They can carry security vulnerabilities that are harder to spot. Then again, this is not a serverless specific issue.
“Serverless security is not inherently better or worse, it’s just different. ” — Guy Podjarny
3. Serverless is Expensive
There's have been countless talks about the real cost of serverless computing and by now it should be obvious that more often than not, serverless is going to be the cheaper option, especially if it's done right. I'm going to link to an article that my colleague, Annika wrote about the amount of money companies save by switching to serverless.
I've mentioned that serverless is cheap if done right. Behind that statement, there is a whole discussion on how to write your serverless architecture and while I'd like to dwell into this subject I'll just link here for you to look at the best practices for serverless development. My buddy Renato wrote this eBook so all credit goes to him.
I've found that when talking about the cost behind serverless, you should always look at the way it's being used. Constant, repeating, long active tasks are going to be expensive to run on Serverless as explained by Tim in an AWS conference last year.
One the same note, companies like Coca-Cola managed to save more than 65% of their cost by switching to Serverless so when it comes down to it, it really all depends on your use case.
4. Serverless is Not for Enterprise
There seems to be a consensus that in enterprise everything needs to be custom-made, self-hosted, self-maintained and made in Java or even worse, PHP. While I do see value in being able to keep tabs on everything that happens with your service and infrastructure, hosting and managing everything yourself comes at a great cost. Big Fortune 500 enterprises have started to migrate towards serverless already because they didn't want to deal with managing everything themselves. Having a partner like Amazon or Microsoft manage your stack is way better than your team of 15 or 20 DevOps people that can only handle so much.
Besides not having to manage the underlying infrastructure themselves, the cost is a huge draw in but even that is probably not as important as what I like to call zero-to-production time, which lets companies that use serverless to create and deploy new features faster than ever before.
Companies like Coca-Cola, Netflix, Airbnb, Bustle, and others have already moved to serverless and more and more are slowly following this trend.
5. Serverless Scales Infinitely
This one is painful for me because I've always seen the scaling aspect of Serverless computing as a huge draw for me and admitting that it does have its limits bugs me for whatever reason. Let me back up first and take AWS Lambda as an example here. Whenever you hit a Lambda function with a request there's a cold start that basically spins a container and then executes the code for that lambda. All the request that happens after that happen quickly since the function is "warm." Now, the beauty behind this design is that you can have by default 1,000 concurrent requests, meaning that as AWS Lambda automatically scales up polling activity until the number of concurrent function executions reaches 1,000. Check out this page for more info on AWS Lambda scaling.
So while there is still a shroud of mystery around Serverless computing, I'm confident in the ability of my fellow colleagues to do their research and understand the true value of Serverless.
If you think I've missed anything, please let me know.
Opinions expressed by DZone contributors are their own.