Serverless or running code without the need for a server seems like a utopia.

Let’s try to get this clear. First, the concept is contradictory in itself. After all, how do you want to perform without at least a server being involved? So there are indeed servers at the basis of this service. The bottom line is that functionality is made available at an abstract level for the benefit of the developers. As a result, they no longer have to worry about infrastructural and operational issues. This allows them to fully focus on writing code.

Many of the current functionalities such as logging in, even single sign-on functionality or logging in with a social media account is available for use in a project. If such a building block is used in production systems, maintenance becomes important. Maintenance means nothing more or less than keeping track of dependencies in this (open) source. This includes fixed bugs, software errors and improvements through advancing insights.

The code produced in a new project is therefore ready for sharing, and is reused through libraries. The “own” code is therefore small, limited and easy to read and maintain. A pitfall is to use outdated open source blocks, or to use more dependencies in the project without added value. If your own code remains limited, these building blocks can be divided into separate services or programs. The logic of this is not new, problems are thus divided into sub-problems. Separate solutions for each sub-problem are combined into an end result. This has resulted in a concept to allow blocks of code to be executed separately instead of all the code in a large program. Rather ten functions that solve ten sub-problems than a large program that solves everything. That is exactly the basis of functions or services as they are used now. A serverless function is nothing more than a piece of code, with the aim of a partial solution. Example is to confirm a newly logged in user. If this user enters his data, these are processed in a function, which then calls other functions, such as create user, send e-mail for confirmation and prepare an environment for the user. Every other function is therefore also a separate piece of code, which can be called independently and where the functions do not know about each other.

Why is this important?

First, the speed and flexibility of development. Any partial solution can be easily replaced without complicated testing or accepting large chunks of program code. Each function can be used separately, if speed or performance has to be adjusted this can be done immediately, again without dependencies on other functions. Furthermore, the code can be run on any environment, regardless of geography or supplier. For example, a serverless application can run on multiple cloud providers at the same time!

All of these benefits come with a number of drawbacks, such as high complexity and a life cycle per function that must be tracked. This increased complexity is now being offered at very competitive pricing, often the functions are only charged for when used. On the other hand, this means that a single start-up sequence of source code is experienced as a slow response.

Conclusion, serverless is scalable, flexible and can be deployed at an increased speed. The costs of development, speed of delivery and simple software maintenance can accelerate this new way of software systems in the cloud. Keep in mind that this does mean that the one-time start-up of the program code that is required, is experienced as a slow ‘server’ response. It reacts slowly at an initial start.

More on Minimum & Viable on a seperate posting!