This blog post is part of a series that explains SERVERLESS. This series will show you in really simple terms what SERVERLESS is, how it works, how to use it and why the IT world is convinced that this is the future of development.
Resources:
- Serverless Framework
- What is Serverless Architecture? What are its criticisms and drawbacks?
- Serverless Computing
- AWS Lambda – Serverless Compute on Amazon Web Services
Content:
What is Serverless
In the most simple terms:
By using serverless, the servers that host/run your application are managed by a provider. Developers can focus just on developing their application and not worry about the configuration/security/scalability of their servers.
Traditional way
To fully understand the awesomeness of serverless, one must first understand the traditional way of software development. The image below simply demonstrates the traditional (and still mostly used) way of doing things.
The process above is really simple – the developer writes some code, the code is put on a server that runs the code 24/7, then the application is visible online. Let’s take it step by step and explain the process displayed above.
First, the developer has to write his code and make it work. That is the step of the process that hasn’t changed massively over time, as developers still need to write efficient and good quality code. We will focus on the next step.
Second, the developer needs to identify all the specs (RAM, CPU, Storage, etc..) that the application requires to run smoothly. Once the requirements have been identified, the developer can ask for a server to be bought/rented, provisioned, patched and tested. This process can take anywhere between 10 minutes to a few days or weeks. If the company has only on-premises servers, this will take longer. If the company uses cloud services, this can actually be done in a matter of minutes, by the developer. In both cases, once the server is ready the code can be deployed (put) onto the server. Once it passes all the tests and everyone is happy, the application can be deployed to production and users can start using this application. The hard part starts now…
Software firefighters
With this type of servers that run 24/7, someone always needs to keep an eye on them. Now, you could have automatic alarms that get triggered in case something horrible happens, but that only covers the disaster scenario. The server still requires maintenance, which means that an employee needs to:
- Ensure that the server runs okay and as expected
- Is secure, meaning that it will resist at least against some basic hacking attacks
- Is scalable, in case your app goes viral and receives millions of request, the server will not ‘explode‘
- That it has enough storage at all times
Overall, is pretty simple to see why this process can get hard at times and takes up a lot of time from a developer that would rather focus on developing his application, than configuring and maintaining servers. That’s where Serverless comes in hand.
Serverless way
Serverless has completely revolutionized the way applications get developed. This is going to be the way work gets done in the future and every developer, especially the new ones, should properly and fully understand this process. Let’s talk about the steps in the picture above:
Firstly, developers need to write their applications in functions. These functions could be written in many programming languages, including: NodeJS, Java, Python, Go and C#.
Secondly, the functions get created and published using tools like Lambda (AWS), Cloud Functions (Google Cloud) or Azure Functions (Microsoft). Once the functions are deployed, the app is available online. Everything seems similar maybe, but there’s a major difference.
You do not need to configure a server. Actually, you don’t even know where your code is running from. The chosen provider deals with all of that process, allowing developers to just write their functions and simply deploying them.
Just because it uses serverless, it doesn’t mean that the code is not running on a server. The code still runs on a server, when a request is made. Basically, every time a request is made, a new server boots up and processes the request, a response is returned and then, if no requests are made for a short period of time, that server gets terminated. This way, you only pay for what you use.
Example:
The price/request is $0.10 and you get only 10 requests in one day, you will end up paying $1 for that day. On the other hand, if you were to have a server running all day, waiting to process those 10 requests, you would pay for the entire time that server was up and running, which would cost way more than $1.
In conclusion, with serverless, developers have to create functions that run on a server when a request is made, those servers are not running all the time. By having the servers managed by cloud providers (AWS, Google, Microsoft), it means that you don’t have to worry about maintenance, security or scalability. The servers scale OUT or down, based on the usage, and the payment method is on a per request basis, rather than paying for the time a resource was running. Compared to the traditional development process, serverless brings many benefits.
Why use Serverless
“If a tree falls in a forest and no one is around to hear it, does it make a sound?”
If a server runs in the cloud and no one is around to use it, does it need to incur any costs?
WinterClouds
It makes your life easier. It’s just that simple. Of course it is also significantly cheaper than running servers, but just the fact that you don’t have to worry about configuring, patching, maintaining and scaling your server everyday, seems like a good enough reason to go for serverless.
It is also becoming one of the industry standards, especially when it comes to building new products. In most cases, it’s hard to argue that a website hosted on a server in your office is more secure and offers more availability than one in the cloud.
Benefits:
- Secure
- Scalable
- Cheaper
- Always available
- Worry Free
- Faster development
- No maintenance needed
Read more about this subject:
Will serverless be the future of enterprise application development?
Serverless: The future of cloud computing?
Server VS Serverless
As already highlighted in this article, Serverless is the winner between the two, depending on your requirements of course. In most cases though, Serverless seems like the easy option for developers to just focus on developing rather than spending precious time configuring, maintaining or fixing.
The pricing model that serverless uses is far more efficient, by reducing infrastructure costs and exposure. While a server provisioned by Lambda is up for 30 seconds, for example, a normal server that you would provision is up 24/7, giving intruders more time to try to attack it.
Conclusion
To conclude, in this article I have quickly and simply explained what Serverless is and how it works. I presented a few pros and cons for each development process and highlighted why you should use Serverless for any future work. Moreover, by being both cost-effective and worry-free, Serverless turns out to be the new industry standard.
How long does it take the app to come online when a request is made though? If it is still running on a server, and in a Cloud, I can’t imagine it taking less than 60 seconds, and even that would be BERY quick for spinning up a server and provisioning code to it in the Cloud….
So is the user just sitting there waiting while the infrastructure is brought online? How is that acceptable?
Hi Evan, that’s a good question. See this article https://medium.com/@nathan.malishev/lambda-cold-starts-language-comparison-%EF%B8%8F-a4f4b5f16a62 for an example of a cold start of a lambda. I also just tested a simple lambda function again that returns a ‘hello world’ message. It took 12.7ms for a cold start, which is not too bad, keeping in mind that it’s a very basic function, more complex functions that need to load dependencies will probably take longer.
Very interesting info. Specially thanks for sharing it in a detailed way. Well done.
Thanks man! Glad you find it useful.