Serverless: An introduction and new challenges for monitoring
Among other terms under the umbrella concept of cloud computing, we can find the Serverless technology which we have witnessed its growing popularity in the last three years.
In principle, the cloud computing concept covers three levels of service:
- IaaS (Infrastructure as a Service), which allows access to a virtualized computing infrastructure including elements such as virtual servers, load balancers, network connections, etc.
- PaaS (Platform as a Service), which allows access to an environment for the development and implementation of cloud-enabled services and applications.
- SaaS (Software as a Service), which allows access to applications in the cloud, without having to make any software installations.
The “Serverless” part is understood at first as the possibility for software developers to access a cloud service that allows them to create applications without having to configure and manage the servers in which those applications will run.
Expressed in this way, Serverless refers to the services called BaaS (Backend as a Service) in which processes like authentication, access to database or messaging are supplied through physical or virtual servers located in the cloud.
However, there are some differences between BaaS and Serverless
With BaaS, we actually have a server in the cloud that listens to http request or API calls, executes several actions and provides the contracted service.
Serverless implements the event-oriented programming paradigm according to which the program flow is determined by the appearance of a particular event like a mouse click or the message from another program.
Serverless providers define the supported programming languages and developers write a program’s code considering a single entry point and the execution of a single function.
When the program generally called by the generic name of “function” is called, the following happens:
- The execution environment is created,
- The function is executed and
- When the function ends the environment disappear.
Scaling is linear; if the function is called n number of times, the execution environment, in principle, will be created and eliminated the same number of times.
Users do not pay for a resident program that listens (like in BaaS) but for the number of executions and consumption of resources (memory x total execution time).
In order to be profitable, functions must be small, well oriented to one purpose and efficient. That’s why we regularly find functions related with microservices.
In specialized literature, we can find the definition of FaaS (Function as a Service) to describe this kind of service. This concept could be useful to establish a difference with PaaS.
Finally, we can define Serverless as an architecture where we have a cloud-based execution environment that is created to call a function and it’s eliminated when the execution ends.
Nowadays there are several providers of this kind of services; we can mention Amazon with AWS Lambda, Microsoft with Azure Functions, Google with Google Cloud Functions and IBM with OpenWhisk.
For those readers interested in going deeper on Serverless architecture, we recommend this article by Martin Fowler, where the concept is explained in a more detailed way.
Now, the real impact of the Severless architecture is to be defined. However, even if we find complete applications developed under this approach or if everything stays in the development of microservices that can be called as utilities, Serverless represents a paradigm worthy of analysis from the monitoring point of view.
Serverless is a new chapter in a novel that began when we asked ourselves: how will we monitor our platforms and applications if we hire a cloud service?
In 2016, in this same blog an article titled Cloud Monitoring: What you need to know? was published, where we had an introduction to the topic and the main challenges it brings along.
We should especially take into account the warnings from this article about delegating monitoring in cloud service providers and the limitations in monitoring tools they supply.
Keeping this in mind, let’s see what additional challenges Serverless represents. The fundamental questions are these:
- How to monitor an application if our backend server does not exist?
- How to monitor a platform if we have servers so ephemeral that they only exist when a function is called?
Since the server does not exist, we do not have the option to use an agent to collect data.
So, we can use the monitoring tools supplied by the provider, for example AWS CloudWatch, where we can find metrics associated with our lambda functions.
Metrics like number of calls, errors and execution time bring us a general vision about our functions but they could be insufficient to monitor a complex application or a single function with several external connections to APIs or databases.
We need a way to collect and access log information generated by our functions in order to determine important metrics like latency, resources usage, failures, etc. and then we need to be able to correlate this metrics with the general observability of our app.
One option could be introducing into the function’s code the calls to another function in order to recollect the necessary data. Let’s say, for example, that into the code of function A we call another function B designed to collect data log. Then we can use a log tool to interpret and present the information in a coherent way. In this article you can find a good example of this option.
For this option, two elements are worrying: the scalability/cost (what happens if our function is called thousands of time in a short period and we have to pay for the original function and for the log function?). The other point is the contextualization (can we really correlate app – event – function – throughput, for example?).
A second option would be based on the fact that, for example, all log information in lambda functions go to AWS CloudWatch, so in this option we need a tool to interact with CloudWatch and help us watch logs, failures, exceptions, usage of resources etc. A good example of those tools is Dashbird.
The question is: can those tools make the same service with another provider?
Finally, we have to say, beyond the two options previously mentioned; monitoring serverless functions opens serious questions about the observability of our applications and platforms.
The ideal solution could to be extend the use of our regular monitoring tool to any kind of cloud computing we decide to hire in order to maintain a unified monitoring procedure.
All the experience that we can obtain with those monitoring tools and the deep knowledge of our platform and applications surely can make the difference. We invite our readers to know more about Pandora FMS’ unified monitoring by following this link.