The term serverless grew in popularity as Amazon first launched AWS Lambda in 2014. Since then it has grown in both usage and reference, as more and more retailers enter the market with their own solutions. What does the concept really mean, and how does it affect how organizations deploy their applications? Is serverless about a paradigm shift or is it more likely an evolution of infrastructure as a service (IaaS) and platform as a service (PaaS)?
What is “serverless”?
With name serverless, you refer to a special type of architecture in which all application logic runs in an environment without visible processes, operating systems, servers or virtual machines. It’s also worth mentioning that such environments actually do run operating systems and utilize physical servers or virtual machines. The difference is that the responsibility for provisioning and maintaining the infrastructure lies with the service provider. It means that the developers can focus on what they do best – writing code.
This means that when you run serverless, a third party is responsible for everything from processes to server operating systems.It means that the developers doesn’t have to handle dedicated servers or virtual machines. At the same time, the service provider is free to determine their internal infrastructure and how to best meet the client’s needs. The result is that the provider rarely needs to run a permanent workload for a specific customer, but instead spends time efficiently on certain requests from the customers.
Serverless with BaaS and FaaS
Two different variants you often come in contact with regarding servless is Backend as a service (BaaS) and Function as a service (FaaS).
Most modern applications require a web connected backend. BaaS allows you to no longer have to develop your own, a task which often proves difficult to scale. As a result, we see an increased number of third part services implementing functionality and provides logic. This in turn leads to an increase of applications missing app specific server logic will increase – they instead use these third part service providers.
Reducing the need for server-side technology together with backend storage and various other features for smooth integration make BaaS an interesting choice. Some other advantages includes:
- Time savings: Many features such as user management, data storage, queries and search end up saving you a lot of time.
- Time-to-market reduced: Since you won’t need to develop any backend at all, you end up writing a lot less code, shortening your time to market.
- Saves hires: Using BaaS is almost like you hire a bunch of awesome backend developers, without spending any time on recruiting or training. You can save both time and money this way.
However, running serverless with BaaS is not perfect for every application and will come with a few disadvantages as well. Here are some:
- Less control over the backend of your app: If you want or need to have full control over every single asapect of the backend your app runs on, BaaS is probably not for you.
- Less control over hosted code: You give up a bit of control over the BaaS hosted code.
A few examples of BaaS platforms are Kumolos, Kinvey, Parse and of course, Azure.
FaaS refers to the idea of deploying an individual function, action or any other piece of business logic. The function then processes the individual requests before it ends.
When an application still needs specific server logic developers can turn to this modern alternative of a serverless architecture. With this approach, the developers focuses on implementing short-lived functions that communicate both with each other and externally. Everything else is handled by the provider. This includes the creation of enough function instances to meet the client needs, terminating no longer needed instances, keep watch of and maintain logs, etc.
Some benefits of running serverless this way includes:
- High volume transactions: You can easily isolate and scale them.
- Highly dynamic workload: You just pay for the server’s functions the time you actually use them. This means that you won’t need to pay for a server around the clock, saving you a lot of money.
- Scheduled tasks: FaaS are a perfect way to run certain tasks in a scheduled way.
Some good examples of FaaS implementations are Auth0 Webtask, AWS Lambda, Google Cloud Functions and Azure Functions.
PaaS compared to serverless
The biggest difference between Platform as a service (PaaS) and serverless is that traditional PaaS providers such as Heroku and OpenShift often lack the opportunity for automatic scaling. Instead, users need to specify the amount of resources needed. This means that in order to scale up, the user needs to change that specification to suit their new needs.
Another difference is that most PaaS are designed for constantly running applications. If the application goes down, any incoming requests won’t be processed. With FaaS the function starts as requests come and are processed. Ideally, the function shouldn’t demand any resources if there are no requests. According to this line of thinking, traditional PaaS implementations are not strictly serverless.
To summarize, cloud computing and serverless are interesting concepts that can bring a lot to the table. But every business has different needs and it might not actually be advantageous to run serverless for all your applications. You should consider both the pros and cons:
- Shorter time to market and faster releases
- Lower costs for both operatinos and development
- Cheaper scaling
- Decreases the complexity of your application
- Inefficient for constantly running applications
- You will be bound to your provider. It’s often hard to make changes in the platform or switch providers without making application changes as well.
- In order to use their resources optimally, the provider could run multiple customers software on the same physical server.
How does your architecture look? Have you started using serverless, or do you think it’s better to use on-prem? Let us know in the comments!