There is no doubt about it: The sheer number of different solutions and architectures available in a cloud environment seems to be endless, to the point where cloud complexity must be managed before it can cause a negative impact and affect company operations.
In truth most cloud-related solutions are focused on avoiding excessive complexity, and as a matter of fact, sometimes this is done in such a way that breaks paradigms we have being taking for granted for a long time. One such example is using Serverless approach. To put it simply, imagine being able to publish an application in the cloud without having to worry about servers, or managing resources such as disk space, memory, and CPU usage? And it gets even better! How about being billed exclusively on the resources you have actually used, effectively getting rid of non-productive resources costs? Well, this is a precise description of the Serverless model, yet another way the cloud can make your business run faster, simpler and cost-effective.
So, what is the Serverless model?
Let’s start by stating the obvious: Of course, there are servers and other computing resources in a Serverless based solution, the difference is the fact that they simply do not matter anymore to you, the client of a Cloud Services Provider. But rest assured, there is still a team of experts making sure the usual levels of availability and resilience we got used to expect from a cloud solution are still delivered.
To put it in simpler terms, Serverless computing is an execution model where the cloud provider functions as the server itself, dynamically managing and allocating computing resources as needed. In this approach, the costs are not based on previously acquired units, but on the resources dynamically consumed by your application.
As early as 2006, there were already cloud providers that tried to implement the FaaS (Function as a Service) model, including Google, with its Google App Engine, that allowed a model where the billing was based on application usage, but this solution was limited by a Python framework that did not allow the execution of arbitrary code.
The first major cloud provider to deliver a truly Serverless approach was Amazon, which in 2014 introduced AWS Lambda, where instead of loading the application into a container or virtual machine, customers simply uploaded the code into Lambda and it took care of everything else. The model was, in fact, quite simple: application would remain dormant, until it was activated by the appropriate trigger, then Lambda would start its execution. Once the application completed its task, it was removed from the Lambda service. That simple.
Reinforcing the obvious fact that the Serverless approach still uses servers, it was soon revealed - to no one's surprise - that the driving force behind AWS Lambda was container technology. The real change in this model was the fact that AWS itself was in charge of loading the code in the container and executing it. As expected, with the success of this approach, other major Cloud players followed the trend, so Google, Microsoft, IBM and Oracle have also created Serverless offerings.
Pros and cons
As expected, the Serverless model gained a lot of interest as soon as it was released, as a friend told me: nothing better than living in a post-container world, where my only job is sending my application to a cloud provider, let they make sure everything runs as expected, and be charged only for the resources were effectively consumed.
Serverless computing can bring many benefits, that goes without saying, but just like any other technology, understanding its advantages is only one side of the story. For a proper implementation, a critical look at any disadvantages is also necessary before fully committing to a new model.
- Pay only what you use: There is no room for doubt here, the Serverless model can be way more cost-effective than other cloud approaches. Being billed only for the resources your application effectively consumed is way smarter than being charged on allocated resources that, in some cases, are not even used completely. In the Serverless model, when your application needs to perform a task, the server runs it (and you will be charged accordingly), once the application completes its activities, the server stops (and you stop being charged). It is difficult to imagine a more cost-efficient way of using the cloud.
- Less time worrying about server management: It's quite simple, in a Serverless approach, your IT team will not have to worry about managing the servers in the cloud, as everything is managed by the provider. Using this strategy, aside from the direct cost optimization from intelligent resource consumption, it is also possible to reallocate your IT staff to other much needed activities.
- Elasticity: This is yet another strong point in the Serverless model. Resources can be dynamically allocated, making sure that no problems will occur when, for example, your application is at peak traffic. For example, imagine that you have built an application specifically for major event, such as the live vote counting during the presidential elections. Well, of course you expect a much larger number of visitors on Election Day. Using a Serverless approach, as the number of people accessing your application increases, more resources are allocated, however as soon as the number of users decreases, these resources are removed. Of course, everything is done dynamically and, as expected, you are charged only for the resources effectively consumed.
"In the serverless model, the costs are not based on previously acquired units, but on the resources dynamically consumed by your application"
- Performance: For applications that are used less frequently, the Serverless model may have a bit more latency than running the code in a dedicated environment. This is because an application that is not in use can be completely deactivated, and once it is needed again, it is only natural that it takes a little more time to start.
- Inefficient for longer tasks: In the case of applications that perform tasks with longer duration, the Serverless model may have some limitations. For example, AWS Lambda imposes a maximum execution time per request of 300 seconds (5 minutes), after that time the task is terminated. If your application runs tasks that require a longer time than the cloud provider limits, there are still options such as creating multiple coordinate functions or even using a virtual server for long-running tasks. However, this can be inefficient and cost more than using a dedicated environment.
- Vendor lock-in: A usual concern during a cloud migration is vendor lock-in. Its no different with the Serverless model, after all, it’s the provider that is going to manage every resource. For instance, imagine that you've deployed your app on AWS Lambda and for some reason your company is now migrating to Google Solutions. Well, in addition to making changes to the code of your application, you may also need to take care of other important items, such as access control, database usage and data storage.
- Security and privacy: It’s only natural to assume that the Serverless model is a safer approach. To some extent this is true, after all the cloud provider already takes care of aspects such as patching and vulnerability management.
However, since there is way more components involved than in a traditional architecture, the attack surface is larger. Also, it is important to remember that you cannot install any security solution on the server or even on the network. In this case you need to trust that your cloud provider properly implements security controls.
Another important aspect is privacy considerations, as most Serverless environments run in a public cloud, this implies in shared resources and your data may also be accessible to the cloud provider staff.
Now, it is important to understand that being concerned about security and privacy is quite different from saying that the Serverless model running on a public cloud is not secure. It is! Just understand that for some cases, where there are stricter security and privacy requirements, you might want to consider using Serverless on a private cloud or even on premises (Kubernetes allows you to do just that!).
In general, the Serverless model can be of immense value and is easily adopted, it is just a matter of understanding which applications benefit the most and having a reliable provider.
As many businesses are already adopting this model as their preferred approach, with the creation of standards, and inclusion of more programming languages, Serverless computing will be one of the best ways to gain agility in app development/publication and at the same time implement a cost-effective approach. In truth, this is the power of cloud