Today we can talk of Serverless because, in the last ten years, the concern and control over stack implementation is decreasing, and so it’s possible to focus with more attention on business logic.
Serverless doesn’t mean only Azure Function, Google Cloud Function, or Lambda AWS Function, but also using third party API-based services, known as Backend as a Service, which provide numerous core functionalities to the applications.
If you considered only FaaS in the construction of your serverless architecture, the main actor is, of course, the developer. He is aware that he must write a function which has a single responsibility for an event-driven and stateless architecture, connecting the function with existing APIs, and the execution of the code must not have any delays.
Therefore, he has the responsibility of writing a function that is very efficient. The three main factors that impact a function’s performance are:
- The execution time of business logic in the function;
- The time necessary to get a response from an API call;
- Cold start: the worst-case scenario for a function’s execution time.
The Pay-Per-Use payment model makes serverless interesting, especially when you want to save on the costs. But you try to do some simulation, with one of the price simulators offered by the serverless providers, you will find this result:
As you improve the configuration, price and performance grow at the same rate. This is true until we reach the point of diminishing returns. That means that improving the configuration beyond the point of diminishing returns doesn’t result in an increase in performance, but only an increase in price.
What you must compare are prices between different cloud solution from the same providers. This is because, when it uses FaaS, the code is always portable while architecture isn’t because there are too few standards available today.
Serverless computing may appear to be the most economical at first, but it may require more expensive third-party service, or might autoscales too quickly which may result in greater costs.
Serverless means also less Ops and more Dev, and you don’t fall back to manual steps to deploy serverless components, because without DevOps there is no cost saving.
Faas is just code, so the best way to test it locally is to do unit tests. In most cases you can run integration tests or load tests only when your application is deployed and so, having a good monitoring and diagnostics system is the only way to find and fix issues or improve performance and costs.
In the end Serverless computing makes the cloud much easier to use and it can help with the rapid expansion of existing applications. However, this is not always the best choice when migrating to the cloud, because the re-engineering and refactoring of the application might become too expensive.
There are still many challenges to overcome, like having predictable performance and dependency on remote storage. Today serverless is the right choice for the implementation of asynchronous, concurrent and parallel tasks, or infrequently used tasks. It’s a good option in the construction of an event-driven architecture. But it is important to remember that this is true only if your team has already adopted DevOps practises, thus serverless can help build and develop application more rapidly. Otherwise the adoption of Serverless might not result in an efficient implementation process.
