How Studo an Austrian company is using Scalingo to do FaaS?

Studo's technical team has been using the Platform as a Service Scalingo for several years to host its web projects. In this article, we will see how they combine several features of Scalingo to use Scalingo like a "Function as a Service" also called FaaS.

But let's start by introducing Studo.

Who is Studo?

Studo is an app for European students to manage their studies online in Germany, Austria and more countries. In its initial market Austria it currently has more than 150k monthly active users which is impressive considering there are around 300k students in Austria.

This means that 1 out of 2 Austrian students is using Studo!

As they are expanding in Germany which is 10 times bigger, they are expecting a big rise in activity.

If you are interested in the technologies they use: the backend uses Kotlin and the database is MongoDB.

PaaS, FaaS, what does this mean?

Scalingo is a Platform as a Service, or PaaS for short. A PaaS is a managed environment in the cloud that allows you to deploy and host web projects without having to install or maintain servers, and without the need of any system administration knowledge.

In the background, a PaaS receives the source code sent by developers to package it in containers. By default, these containers are always on: whether it is 2am or 3pm, the containers are present and immediately ready to receive requests from Internet users.

All the web frameworks and languages usually used by developers run on Scalingo's PaaS such as Ruby on Rails, Django, Node.js ou Symfony.

In Function as a Service (FaaS), the application code is divided into several "functions", which are sort of mini-programs that react to events. It is then possible to chain several functions to perform a complex job.

FaaS is a complete paradigm shift in the way web applications are programmed.

Each function is separated from the others by an isolation mechanism. Unlike PaaS, functions only live during their execution time. As soon as the event is processed by the function, it stops. Most platforms offering FaaS require processing within a maximum of a few seconds.

Two types of computer processing

To help us understand how Scalingo can be used to make FaaS it is important to define the 2 main types of processing that a web application can be brought to perform.

Processing web requests

The first and most obvious treatment is that a web application must react to HTTP requests sent by the browsers of Internet users or machines that use API web projects.

Reacting to events

When an event appears, a certain piece of code is executed. This is the case when setting up asynchronous processing: instead of executing a treatment right away, the description of the treatment is stacked in a queue while another process comes and unstacks this queue and executes the treatments according to their description.

Both PaaS and FaaS allow to process web requests as this is the essence of web programming. As you will have understood reacting to events is the privileged field of the FaaS and it is traditionally not the case for the PaaS.

Except at Scalingo! We will see how it works with a concrete case.

Case study: How to use Scalingo to do Function as a Service?

We were able to talk to Zoltan Sasvari recently, the lead backend developer of Studo. He is also responsible for the system administration of the Studo application. We already interviewed him in our blog.

At the same time Zoltan is also working on another application. Between development and scaling up to serve several hundred thousand active users, it's a lot of work.

According to Zoltan this is only possible because Studo is hosted on Scalingo, which makes life easier for developers since they no longer have servers to manage or perform system administration tasks.

To manage recurring tasks, he started with a very simple worker (process separate from the application) that was just a loop running tasks at regular intervals.

But running all these tasks in the same container started to create problems as Studo grew. Some tasks had to be performed simultaneously, others required a lot of memory and took up a lot of resources, and still others were very light and didn't take much time to perform.

These tasks did not go well together and had to be performed in their own containers.

Dividing them into several workers would have cost a lot of money, because Studo would have paid for containers that were still active for each worker.

Since the workers are working in permanent containers, it was not cost-effective to have one worker per task when some tasks only lasted a few hours per month in total.

We could not have done 15+ workers because it would have been very expensive.

That is why he decided to use one-off containers on Scalingo.

What's a one-off container?

As we explained earlier, when you push code on Scalingo, the platform builds a container image and packages the code with all the necessary dependencies to run that code inside the container. This is the so-called BUILD phase.

Then comes the RUN phase where Scalingo will turn on and run the container. Scalingo knows how to start these containers based on the technology detected during the BUILD phase.

The RUN phase starts the project so that it can respond to web requests.

But there is another way to use the container image built during the BUILD phase: the one-off container.

A one-off container is an additional ephemeral container that is started by placing a command on it. Your code must therefore be able to interpret the command you give to it. The command can be interactive or not.

The easiest way to execute a one-off container is to download our CLI and execute the run subcommand. The argument passed after the run keyword is the command you want to see executed.

Here are some examples using Scalingo's CLI.

scalingo -a my-application run ls -l

Executes the command ls -l in a one-off container. The one-off container starts, executes the command, returns the result to the user and shuts down immediately.

scalingo -a my-application run rails console

Runs the Ruby on Rails debugging console. The one-off container starts, executes the command, I/O allows the user to type commands into the console and see the result. Here the container is switched off as soon as the Rails console is exited.

If the easiest way to invoke a one-off container is to use our CLI, there is also an API.

The API of one-off containers to execute functions

Zoltan did this by triggering one-off containers via the Scalingo API when he needed to perform a task via a single worker much smaller than before.

A worker uses the Scalingo API to perform different tasks in one-off containers.

He uses one-off containers to perform tasks such as :

• Data archiving. Each application start from a user is recorded in a database in a collection "appStarts" and its size increases rapidly, but as only recent activity is needed at Studo, older data is archived in case it is needed for debugging. Zoltan uses one-off containers to query the data, format it (to remove all personal data related to the GDPR) and send it to AWS S3.
• Data analysis. This task queries the data from the collection "appStarts", aggregates it and saves the result in InfluxDB to visualize it in Grafana. This allows Studo, for example, to find performance problems.
• Subscription updates. Users pay either on the Apple App Store or the Google Play Store. The application must periodically synchronize the status of the subscriptions by calling the APIs of these app stores.

The execution of tasks is done like a function for a FaaS: when the task is invoked, the platform starts a container with the necessary information to allow the task to run. As soon as the task is completed, the container stops.

Whether the task lasts 15 seconds or 30 minutes, Scalingo only charges the container execution time, to the minute (any minute started is due).

Thanks to one-off containers, Studo retains all the advantages of a PaaS like Scalingo while being able to benefit from the normally exclusive advantages of serverless such as pay-per-use.

It is extremely simple to use one-off containers. It works very, very well!

Conclusion

As we have seen in this article it is possible and easy to use the Scalingo PaaS and its APIs to execute temporary functions in reaction to events.

This allows developers using Scalingo to use the platform as a FaaS.

The interest for them is to be able to continue using the same technologies, tools and mental models as for their usual web projects.