Introduction to Serverless Technologies

Serverless technologies and applications are all the rage, and no wonder! They allow developers and IT teams to focus on business needs and in addition, they promise cost reductions over traditional architectures and with implicit support from the public cloud provider. But is it all an advantage?

Read ahead or start by watching this introductory video on serverless technologies.

What is Serverless

The best way to really understand serverless is to read the following tweet from Kelsey Hightower, a Google Cloud Engineer.

As mentioned above and as Kelsey reminds us, the strength of serverless lies in its focus on “what we care about”, i.e. our application, service, product or business case.

Traditionally, the serverless concept relates to certain computing services offered by cloud providers where all we have to worry about is uploading the code to their platform. From that moment on, service management falls to the provider and allows our organisation to dedicate its efforts to improving that application, service or product.

Recently the concept has evolved, and some public managed cloud services (not necessarily related to computing) have also become part of the serverless world; for example, certain managed database services, developer tools, data analytics services and others.

If we focus at the moment on serverless computing services such as AWS Lambda or Google Cloud Functions, we can consider them from two points of view.

Operational Model

One essential that any serverless service must comply with is that it does not require server management by the user/client. The user is abstracted from the layer that hosts and runs their application and is limited only to deploying their code.

Another fundamental characteristic of these services is the so-called pay-per-use. These services scale the instances or servers hosting the application to zero when it is not being used. That way, no cost is generated unless it is used.

They also provide us with a completely managed security layer at access level.

Programming Model

The use of these serverless technologies is geared towards a service-based approach, to services that are a priori independent and that carry out specific and perfectly defined tasks.

In addition, these services tend to be event-driven. Examples include an HTTP call, a recurrent custom event or the upload of a file to a binary repository that triggers the start of our application (if not already started) and will execute the task implemented in that service.

SERVICE LEVELS AND SHARED RESPONSIBILITY

Although lately we have seen the emergence of different levels of services such as FaaS (Function as a service) or CaaS (Container as a service) complementing and detailing traditional services, we will focus on the three most important levels.

Infrastructure level (IaaS) is the lowest level offered by the public cloud provider. We “rent” virtual machine instances with allocated resources that exist in a certain customisable environment. From there, it is our responsibility to update, secure and have procedures and/or methodologies of action for everything that is not concerned with the hardware itself and the lowest levels of storage and network. 

At Platform level (PaaS) we only upload our code to a controlled environment or use a managed service, and we should not worry about anything other than having security procedures at application and deployment level. Serverless would be at this level.

At the Software (SaaS) level we acquire a complete solution and at this level our responsibility lies only in the use of the service, content or access policies.

This concept is perhaps the most important when it comes to proposing alternative solutions to a given problem. The responsibility acquired according to the level we are using can vary enormously and, of course, being unaware of this does not exempt us from such responsibility.

From the moment we start the design phase through to the implementation of an application in a productive environment, it is likely that requirements will change. However, one factor that we must be very clear about from the beginning is the scope.

If this is not made clear from the beginning of the project, it may be tempting to assume that an approach or solution at Infrastructure level (IaaS) may be “more or less” as expensive as serverless architecture since we are using public cloud services of similar configuration, after all. If not analysed carefully, the possible success of our application could become the team’s worst nightmare.

Serverless solutions guarantee that we can demand the cloud provider takes on high responsibility. Thus if we use IaaS architectures, this will have an impact, not only on possible difficulties for our solutions, but also on the operations teams that would be necessary. 

But Serverless is not the answer to everything and, in any case, there may always be business requirements that make us discard these solutions from the outset.

Pros and Cons

The strength of serverless technologies is the time and cost savings for our team or company. In general, a serverless approach lets us save on costs since resources will shut down when not in use and therefore we will not pay for that downtime.

Secondly, not having to spend a lot of time implementing architecture means our solution will be ready sooner, so time to market will tend to be shorter.

Although there is an improvement in costs and times, we must be aware that the so-called “pay per use” should not be considered a good practice in itself.

Scaling to zero is a “trade-off” or commitment where we will be penalised in some aspect in exchange for a benefit elsewhere. In this case, having our applications turned off when not in use is not a good thing. In fact, there are a multitude of use cases where this can be a nightmare for equipment and for the end user.

It should be remembered that, on many occasions, such services are accompanied by working environments or “frameworks” that must be used and that can be difficult to port to other providers.  Therefore we will always assume an implicit risk when using certain serverless technologies.

No Ops fears

Without a doubt, the main message to convey here is about opportunity and not being afraid to make use of these technologies. The huge portfolio of services and technologies at our disposal (from worldwide databases to voice recognition services) that will be covered by SLAs is incredible and saves us the cost of expensive operational equipment for certain applications.

We must insist on being critical thinkers when it comes to these kinds of “universal solutions”. Serverless services will be useful to us, and we should pay them special attention and take them into consideration when devising any of our solutions.

—–

Serverless technologies are not only the future but already the present for many IT teams around the world who always take these technologies into account when building products and services.

If you want to know more about Serverless, keep reading as we will continue to keep you informed and analyse the world’s day to day trends in our blog.

Imagen: Pexels | Djordje Petrovic