You probably have already heard the term (or I should say the buzz word): ‘Serverless’ , right?
Nowadays more and more organizations are moving toward Serverless computing. It is the next stage for almost every software company.
Let’s try to understand what Serverless Computing is. We all know what ‘Computing’ is, but what is Serverless?
Serverless is not exactly what it sounds like, which is “without a server”.
As you all know, everything which is executed needs a server to run on. So what does Serverless really mean?
It means without a local server.
Running a Serverless application means running it on a remote server. In other words you don’t have to purchase a server in order to run your application on it. You will just pay someone else to use her server for a time slot. This time slot is when your function is executed. While the server is idle because your function is not being executed, you don’t pay. It is like getting a server on demand.
A Server for Rent Anyone?
The remote server is located on the cloud, and is run by a cloud provider whom we pay according to what we use.
We can choose a server region, when to run our application, how frequently, how much storage and how many CPUs we need. The server that we rent is used not only by us, but by any customer who pays for running their applications. Each cloud provider has its own paying methods and even sales. For example if there is an available server at a specific time slot, you can buy computing time at a discount. There are also public sales on time slots and other funny methods.
Like me and you, Serverless computing has its pluses and its minuses.
What Are the Benefits of Serverless Computing?
- We as developers don’t need to worry about managing machine resources. The cloud provider maintains the server for us.
- We don’t need to handle scaling. This part too is done by the cloud provider. We just focus on building our application.
- ’Pay as you go’ method we (or actually our organization) don’t need to purchase any server. In addition we pay only for the resources we use, for the time we use it.
No running application -> No payment
- Deployment is easy and fast- since we don’t have to manage the servers, and we don’t provide the infrastructure. We don’t need to install anything. just compile our code and the rest is done like a magic.
Any fix or a code change can be done very quickly: just fix the code, compile it on the cloud and the rest is done by itself (or by the cloud provider :) )
- Great UX and happy customers- since we need to focus only on the application and not on handling the infrastructure, we have much more time to improve the look and feel which is what matters to customers. They don’t care about the work we do behind the scenes.
- Better latency- a cloud provider has servers spread all around the world, so if my customer is from Iceland I will pay for a server in Europe rather than a server in the USA.
- From a global point: less energy is wasted for nothing.
These servers are used by many customers at different times, so there are much less empty slots when server runs without any application executed on it.
And Now for the Minuses:
- Debugging is more difficult
There are no tools to debug a Serverless application.
I found myself digging into so many irrelevant log files until I found the specific one that contained the error I was looking for.
You actually need to learn about the log system of your cloud provider in order to debug your end to end application.
- Finance issues
Developers need to think about when to run their application, when to shut it down, and to carefully check the payment method, otherwise they will probably lose money for their organization. As a developer, it was the first time that I had to take financial factors into account. (at work, not at home of course :) )
- Security issues
Uploading your code into a cloud is never as safe as keeping it inside your organization.
Your code depends on many third parties which might contain malicious code, or relies on open source code which might be problematic sometimes.
- Vendor lock in- when we decide to use one vendor, we make adjustments which don’t fit another vendor.
For example although AWS DynamoDB and Azure CosmosDB are both NoSQL databases, they have different indexing and nesting methods, so that you can’t deploy the same application to both.
Which Cloud Providers Are There?
The payment method of Serverless computing is ‘pay as you go’: You use my environment to execute your code for an hour, then you pay me for an hour. You want to execute your code every day but Sundays, you will pay for 6 days a week.
Then at 2008 Google came with ‘Google app engine’. An environment to execute Python applications. I used it back at that time to execute a web application which I wrote.
On 2014 Amazon released AWS lambda. A computed service which runs customer application due to events such as image upload, website click or an output from a connected device.
At 2016 Google, IBM and Microsoft released their cloud platforms. Google Cloud Platform (GCP) is a suite of cloud platforms which runs on the same infrastructure that Google uses for its applications like google engine and YouTube.
Microsoft launched Azure: both public cloud and on-premsis (Azure stack). IBM provides OpenWhisk which is an open source serverless platform.
The most popular cloud providers today are AWS, Azure and GCP.
And Now for a Personal Point of View:
I have experienced developing an application on AWS.
I can sincerely say that writing the lambda function was easy and nice.
Also every fix or a code change was so easy and quick to deliver.
I also used DynamoDB which is a user friendly database. You need to determine a primary key which defines the table. Almost everything else is mutable.
After reading AWS documentation and some forums I also understood how to deploy my application.
Now my application runs in response to website clicks and I am satisfied with it.
However getting there was not so easy since the documentation of AWS is not updated as frequent as AWS GUI.
The biggest news for me was that I as a developer had to read carefully about AWS paying methods and decide according to it when to run my application, which machines to upload (in terms of storage size and number of CPUs versus its prices), and when to shut down my machines so my organization will not spend any extra money.
Here is a link to the story I wrote based on the issues I have faced during developing AWS application:
Use Serverless to create a table in AWS and post new items
In this blog I’m going to explain how to use Serverless framework in order to create a new table in AWS, and write data…
and just to clarify… although both Serverless and containers are running on a remote server, they represent two different approaches.
A container is a standalone executable package of a piece of software that contains all required dependencies to run it. Containers isolate software from its environment so you can move a container from one environment to another without changing anything. However it takes much more time and work to set up a container and also to manage it.
While Serverless allow you to concentrate on developing your application by out-sourcing scaling and infrastructure handling into cloud providers, By using Containers developers keep more control of the application.
Serverless allow you writing functionality without the need of a complex architecture or even classes. You can write the functions you need in the cloud provider environment. (for example lambda in AWS)
When Should You Use Each Approach?
For complex, long running applications where you have all resources and you want a high level control of your application it is better to use Containers. Or in a case you want to migrate into the cloud a legacy software, you can divide it into containers of micro-services and then orchestrate it by using tools such as ‘Kubernetes’.
For applications that don’t need to run all the time, but need to be triggered by different events, you should use Serverless. Also if you need to deliver fast Serverless is your answer.
Netflix used Serverless to encode media files, to backup files and to monitor the environment. It works great for them, so why wouldn’t it for you?