Overview [1][2]#

Serverless is an Event-triggered, ephemeral and stateless cloud-based architecture that dynamically allocates machine resources.

Serverless uses servers; they are just not yours.

Serverless is an Architecture and there’s no one clear view of what ‘Serverless’ is, and that isn't helped by it really coming to mean two different but overlapping areas:

Both of these imply Cloud computing and remember the real definition of Cloud computing is: "Other people's computers"

One way to think of this is Functions as a Service (FaaS)'.

Why Serverless? #

When developing an application, your prime goal is to focus on the problem you are trying to solve. Ultimately, it means that all work you need to do that is not directly linked to your goal needs to be minimized or, better, eliminated.

If there is a surge in the usage of your app, ideally it shouldn’t make any difference to your users. In reality, though, they might expect slowness, a drop in responsiveness and even no service at all if your server crashes. In order to prevent scenarios like this, you need to invest in good infrastructure. Unfortunately, maintaining such a robust infrastructure is time-consuming and expensive.

Some aspects of Serverless for this dilemma:

  • Scales out-of-the-box (Elasticity)
  • Payment based on usage
  • Cloud Service Provider lock-ins vs employee lock-ins - The main problem is that changing personnel is way more difficult than changing a cloud provider. So if you decide to switch technologies or are not satisfied with the current status of your company’s infrastructure, you will likely have a hard time. However, by adopting a serverless strategy, if you ever need to change providers you can expect a less painful experience.
  • Development Team experience - It goes without saying that developers… well, like to develop. If you take from them the responsibility to overlook the infrastructure, they will get more productive by keeping their eyes on the end goal, i.e., creating an awesome app. A stressful working environment can kill devs productivity and actual care for their well being will bring you collateral improvements.

Serverless makes sense when:

  • You need Little control over your server
  • Short computations - Functions as a Service are Event-triggered, which means that they are called when something happens (for example, when a user is created). Serverless providers will set a maximum time limit your function can run to avoid that a single call drains all machine’s memory. If your application performs long and expensive computations, going serverless may be a problem for you.
  • Small throughput - One advantage of Serverless is that you are billed per function request and not by uptime (like traditional Virtual Machine). Serverless May not be well suited for applications with too many requests per second.
  • No data persistence - Serverless is Stateless computing. Do not count on any DataStore. You may be able to read data from an API

More Information#

There might be more information for this subject on one of the following: