It’s been about 9 months now since I first heard of the term “Serverless”. I can clearly remember feeling a sense of awe at the fact one day I’ll be able to create web apps without the need to have and manage a server, which for a front-end developer, like myself, would be a dream come true.
What is Serverless?
Well, that dream has not come true quite yet! Using Serverless computing doesn’t mean you won’t have a server in the technical sense, it just means that you won’t have to manage it yourself. You use services like AWS Lambda, Microsoft Azure or Google Cloud Functions to leverage their flexible, easy to scale, cost-effective cloud infrastructure by creating microservices that start or stop functions. The goal here is to reduce maintenance costs while allowing the developer to focus on the business logic, rather than being stuck constantly thinking about the infrastructure, security, and upgrades. Since the service providers have a similar offer, for the purpose of this article, I’ll stick to only talking about AWS Lambda and promise to come back around to talk about the other options at a later time.
The concept, simple as it is, fascinated me from the getgo. Working with large-scale enterprise projects has taught me that infrastructure and scalability will always be a problem. With Serverless, you can circumvent this issue as all the server logic, problems and responsibility are covered by the service providers.
So where’s the magic?
You can’t talk about how awesome Serverless is if you don’t know what FaaS means (an acronym for Functions as a Service). FaaS is basically a small piece of code (think small reusable function) that returns a value after it runs its course. It’s that simple. With AWS Lambda, which is Amazon’s FaaS service, your code will be split into Lambda functions that run on several environments:
Node.js — v6.10, v8.10 (recommended)
Java — Java 8
Python — Python 2.7
.NET Core — .NET Core 1.0.1 (C#)
To get your code in a Lambda function, you upload a zip or use AWS Lambda Management Console. The name of the function has to be unique, otherwise you’ll get an error. You can read more about deploying and creating functions here.
“Run code without thinking about servers. Pay for only the compute time you consume”. — AWS Lambda
To better understand the magic of Serverless, allow me to paint you a picture.
Let’s say you have 10 people in your tech startup that drink coffee each morning. Everyone likes their coffee with a lot of milk. To make sure that you always have milk, you bought a cow that sits comfortably in the office kitchen and is ready to supply enough milk to the entire office.
Suddenly, Mark Cuban invests $ 16M in the company and you hire 100 more people (and before you ask, yes, everyone who was hired drinks their coffee with milk. It was a hiring prerequisite). Because you have more people in the office, you’ll need to get more cows to deliver milk. That’s basically the traditional way of running your services. You purchase a server and have a certain set of resources at your disposal. If you end up needing more, you have to get the server provider involved, make sure your app was built to scale, upgrade hardware, etc. With Serverless, this problem goes away. Your milk gets delivered exactly when you need it, without having a bunch of cows taking your precious office space via a platform that scales when needed. You only pay what resource you end up using. Many services like AWS Lambda offer around 1 million requests for free.
Betsy and her friends hanging out — circa 2018
The benefits
One of the many advantages of going serverless is the drastic cost reduction, since you pay for what you used. For AWS Lambda, the monthly compute price is $0.00001667 per GB-s and the free tier provides 400,000 GB-s. The monthly request price is $0.20 per 1 million requests and the free tier provides 1M requests per month.
Just by switching from traditional hosting to serverless computing, we’ve seen companies that managed to cut server costs from $ 10,000 down to $ 370 per month (read more), which is amazing no matter how you look at it.
$370 down from $ 10,000 per month is a huge deal!
In my opinion, the next big benefit of going serverless is the go-to-market time. Since you don’t dwell on the infrastructure issues, releases are easy to push and you are left with plenty of time to focus on the actual app rather than on the black sorcery that’s happening underneath the covers.
For big enterprise applications that require a lot of prep work, like backward compatibility testing or merging all the new components with the old API, going serverless could be a better solution, since the code is split into small reusable functions that are easier to manage and work with (not to mention the cut in cost).
Another very important thing to note about serverless is the ability to scale gracefully when the time comes. It’s something that usually is hard to achieve and if you manage to pull it off, it usually costs an arm and a leg.
“AWS Lambda will dynamically scale capacity in response to increased traffic. To handle any burst in traffic, Lambda will immediately increase your concurrently executing functions by a predetermined amount, dependent on which region it’s executed.”
— AWS Lambda
So why isn’t everyone going serverless?
Like everything else in this world, it has its… inconveniences. Cloud computing and Serverless as a technology have been around for years, but it’s only now that we’ve been able to get it for a cost-effective price. Most providers that offer serverless services have yet to reach a maturity where you, as a consumer, get all the tools needed to launch your app. Take for example AWS Lambda, in my opinion, one of the better options out there. It severely lacks in the monitoring and error reporting department; something that developers rely on. Thankfully, there are options like Dashbird.io to get around this ‘deficiency ‘.
What about limitations?
Each service provider has a set of “hard limitations” that you’ll have to respect to in order to have a good time.
Let’s get back to AWS Lambda. You have certain limits but I’d advise you look past the word “limitations”, and think of them as guidelines. The environment is limited to 512 MB of disk space, memory can vary from 128 to 1536 MB and the execution timeout for a request is 5 minutes. If you are so inclined, you can read all the limits of AWS Lambda here.
Conclusion — my two cents
As a technology that’s available to the masses, serverless is still in its infancy and will take a while before it starts to spread like wildfire, but believe me: It. Will.
Mainly for two reasons: cost and speed at which you develop and deploy the application. Granted, traditional servers won’t go anywhere, but I full heartedly believe that in the next couple of years, we will see a shift towards serverless and FaaS. I look forward to seeing how the technology will evolve and how developers and entrepreneurs will rally behind it, finding new ways to implement and develop applications.
Serverless - Hacker Noon_Read writing about Serverless in Hacker Noon. how hackers start their afternoons._hackernoon.com