As we all know that serverless computing is the next big thing in the cloud paradigm.
The term serverless grew in popularity as Amazon first launched AWS Lambda in 2014. Since then it has grown in both usage and reference, as more and more retailers enter the market with their own solutions.
The concept itself is easy enough to understand – you simply run your application without any servers. But what does that really mean? Surely there must be some kind of server running somewhere? The short answer is yes. Let’s dig a little bit deeper into the concept itself, some related terms and what running serverless can mean for you and your organization.
Running Serverless
Running serverless simply means that you and your organization take no responsibility for maintaining the infrastructure around your application. This includes all application logic, processes, the operating system itself as well as the actual servers (or virtual machines). Using such an architectural structure creates a shift in focus. It allows the organization to instead spend time, money and energy on actual development, something much appreciated by most developers.
This means that when you run serverless, a third party is responsible for everything from processes to server operating systems. In short, it means that the developers doesn’t have to handle dedicated servers or virtual machines. At the same time, the service provider is free to determine their internal infrastructure and how to best meet the client’s needs. The result is that the provider rarely needs to run a permanent workload for a specific customer, but instead spends time efficiently on certain requests from the customers.
To summarize, cloud computing and serverless are interesting concepts that can bring a lot to the table. But every business has different needs and it might not actually be advantageous to run serverless for all your applications. You should consider both the pros and cons:
Advantages of Serverless Architecture
Lowering Costs
When your services are not required, you need not to pay. The same applies to hardware – which comes free of cost. This means you only need to pay for what you use. This means you save a lot of money when you go serverless. There is this ‘pay-as-you-go’ model in serverless that can be opted to pay only during the time when you utilize the services if you do not have a bulk requirement – which minuses the idle server time costs.
Hassle Free and Easy to Manage
Security is one of the biggest concerns that we all have. But when it comes to serverless applications, you need not worry about the latest security being implemented as your servers are being monitored and controlled by a third-party services provider. This means you do not have to worry about fixing the bugs or examining for loopholes in your app.
Scalability Improvisation
If you are planning to build an app that should go around and become a hit across the globe, for instance, “Netflix”. But in this case, you would not want to provision infrastructure. However, when you are having serverless architecture run the app, it comes with a highly tremendous capability to fetch traffic volumes with ease. Scaling is dependent on user location and their network strength.
But the service providers will ensure that there are no delays, allowing the apps to perform well, no matter which is your geographic location.
User Experience is What Matters
The infrastructure or the process of development of the app – in fact, nothing matters to your users – all that they care about is the features and functionalities of the app. Since there are no server downtimes or server issues that would lead to a failed performance, there is no point of thinking that there would be discomfort for the users when they use the app from the perspective of user experience.
Server maintenance is no longer a point of concern for the developers, which means they can shift their focus to improving the customer-facing components. Now, you can offer a high-quality and satisfactory user experience with more time available.
Though serverless architecture is capable of providing great user experience, eliminating the struggles of a backend process, it still does not fulfill certain requirements and hence there are a few drawbacks
Disadvantages of Serverless Architecture
Third Party Involvement
The vendor locks you in. Now, it is the vendor who decides what has to be done and the control is not in you, but their hands. You need to go by their rules. As your servers are in the hands of third-party providers, then you do not have control over the run times, updates and even the hardware. This is not beneficial to you – as there would be inconsistencies appearing along with the limitation of resources.
So when you accept the services of a particular vendor, you cannot just walk out one fine morning. It would be highly challenging if, at any point, you wish to move away from a particular vendor to another. And if at all, in any case, you manage to switch over from one service provider to another, a lot of time, effort and resources would be invested into reengineering your app.
Another concern is that the vendor can revise its service terms or pricing policies as and when required, and even cease offering the option.
Inefficient for constantly running applications
It is found that serverless is one of the best options for a short-term process. Even, for real-term processes, such as sending emails, you can opt for the serverless options.
But when the duration of your task increases, there would be functionalities that might need to be executed more often and requiring you to make payments for the time these functionalities run. For instance, if you are uploading a video with long files, it would require a lot of other functions to be called, which would take more time and of course, money.
For instance, you need to complete a file upload in say 10 minutes. But this task extends or goes beyond the expected time, which means you would require to call another function to complete the task. But there is a limit to the number of functions that can run simultaneously – so if you run a number of functions at once, you are doing denial of service on your production apps.
Pay for More Than What You Use
You are paying for what you use. What if you never need to use a function – you would be penalized, which comes over the services charge that you are already paying. This is what a cold-start penalty is, which is imposed on hosted functions – which could be slow for the first time
Hosted functions suffer from a cold-start penalty and can be very slow the first time they are called in a while. But this can be taken care of by limiting your functions – keeping those to small amounts – because cold starts cause to increase the code size and even memory.
Complexities Might be Involved
It is not easing to get a hold of how serverless applications operate. It might take a lot of effort. The integration units that come in serverless are much minuter than those you might find in other architectures. This might need you to take some time to organize the functions such that they work in sync with the data. You might have problems with the versioning and deployment side.
You might get only a small span of time, say five minutes since AWS functions have time restrictions. In case, there is a task that needs large quantities of data that might exceed these run time limits, then you might want to spend a lot of effort into code rewriting for another architecture.
Serverless comes as a new technology for developers. It might seem to be complex when it comes to testing. If it is not taken care of well, it might lead to poor performance.
