Serverless: advantages and disadvantages Solidify

Serverless: advantages and disadvantages

Published June 08, 2017

The term serverless grew in popularity as Amazon first launched <a href="https://www.google.se/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjZoZW4urjVAhXHbxQKHfbyBioQFggnMAA&url=https%3A%2F%2Faws.amazon.com%2Flambda%2F&usg=AFQjCNHjO6kLR29M6rle7MjKqum-YKJfhA">AWS Lambda</a> in 2014. Since then it has grown in both usage and reference, as more and more retailers enter the market with their own solutions. The concept itself is easy enough to understand – you simply run your application without any servers. But what does that really mean? Surely there must be some kind of server running somewhere? The short answer is yes. Let’s dig a little bit deeper into the concept itself, some related terms and what running serverless can mean for you and your organization. <h2>Do you really run completely serverless?</h2> Running serverless simply means that you and your organization take no responsibility for maintaining the infrastructure around your application. This includes all application logic, processes, the operating system itself as well as the actual servers (or virtual machines). Using such an architectural structure creates a shift in focus. It allows the organization to instead spend time, money and energy on actual development, something much appreciated by most developers. This means that when you run serverless, a third party is responsible for everything from processes to server operating systems. In short, 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. <h2>Serverless with BaaS and FaaS</h2> Two different variants you often come in contact with regarding servless is Backend as a service (BaaS) and Function as a service (FaaS). Here are some more details about them. <h3>BaaS</h3> 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 party 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 include: <ul> <li>Time savings: Many features such as user management, data storage, queries and search end up saving you a lot of time.</li> <li>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. </li> <li>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.</li> </ul> However, running serverless with BaaS is not perfect for every application and will come with a few disadvantages as well. Here are some: <ul> <li>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.</li> <li>Less control over hosted code: You give up a bit of control over the BaaS hosted code. </li> </ul> A few examples of BaaS platforms are Kumolos, Kinvey, Parse and of course, Azure. <h3>FaaS</h3> 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: <ul> <li>High volume transactions: You can easily isolate and scale them.</li> <li>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.</li> <li>Scheduled tasks: FaaS are a perfect way to run certain tasks in a scheduled way. </li> </ul> Some good examples of FaaS implementations are Auth0 Webtask, AWS Lambda, Google Cloud Functions and Azure Functions. <h2>PaaS compared to serverless</h2> 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. <h2>Summary</h2> 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: <h3>Pros:</h3> <ul> <li>Shorter time to market and faster releases</li> <li>Lower costs for both operatinos and development</li> <li>Cheaper scaling</li> <li>Decreases the complexity of your application</li> </ul> <h3>Cons:</h3> <ul> <li>Inefficient for constantly running applications</li> <li>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.</li> <li>In order to use their resources optimally, the provider could run multiple customers software on the same physical server.</li> </ul> There are of course more advantages and disadvantages to running any version of serverless. The ones mentioned above are some we’ve seen many run into, but as every situation is different the challenges and benefits will of course also vary.   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!