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:
- Serverless was first used to describe applications that significantly or fully depend on third-party applications / services ("in the cloud") to manage server-side logic and state. These are typically "rich client" applications (think single page web apps, or mobile apps) that use the vast ecosystem of cloud computing accessible databases (like Parse, Firebase), authentication services (Auth0, AWS Cognito), etc. These types of services have been previously described as ‘(Mobile) Backend as a Service’, and we will be using ‘BaaS’ as a shorthand.
- Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless Containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a Third-party. (Thanks to ThoughtWorks for their definition in their most recent Tech Radar.)
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:
- AWS Lambda
- AWS Serverless Application Repository
- Azure Functions
- Functions as a Service
- Google Cloud Functions
- Persistent Compute Objects
- Web Blog_blogentry_040817_1
- Web Blog_blogentry_131016_1
- [#1] - Serverless Architectures - based on information obtained 2016-10-13
- [#2] - The Comprehensive Guide to Serverless Architecture - based on information obtained 2017-12-15