This article was first published on Medium. You can take a look at it here.

I’ve had someone tell me before that serverless is great because the code isn’t running on a server. Well obviously the code is not running in thin air, so where is it running in a serverless architecture? What is serverless and why is there so much hype around it? Is the hype even worth it?

The term serverless is misleading because servers still exist, but developers do not need to worry about managing the server. Going serverless means that developers focus on the application at the task level instead of at the server level. Now, they don’t need to worry about managing and operating servers or runtimes in the cloud or on-prem.

Serverless can also be described as Functions as a Service (FaaS). FaaS products execute functions (code) that are run on demand in response to events. The benefit to running code on demand is in the use case where your code does not need to be running full time. When you use a serverless product you only pay for the resources your application consumes, not a pre-purchased unit. In certain scenarios this could save you money. The other benefit to having your code broken down into functions is that scaling and deploying individual functions is much easier. Let’s imagine that one specific function is computationally heavier than another; in a serverless architecture that function can be individually scaled instead of having to scale your entire application.

This sounds a little like microservices, and the concept is similar. The goal of a microservice is to break your large application into small, decoupled, independent systems that connect back together to make your application work (read more here). Functions go one step further and are smaller than microservices, think one microservice can contain multiple functions. The difference comes in use cases. There are some things that are not suitable for functions and vice versa. Ultimately, functions/serverless and microservices both have their place in development but each have their strengths and weaknesses.

So what are the strengths or benefits of serverless? We talked about scalability and cost but is there anything else? As a developer, serverless is nice because you don’t need to provision or maintain any servers. In the situation where you just want to write code that responds to events but don’t need to create an entire application, serverless is awesome. Additionally, some serverless services such as AWS Lambda provide availability and fault tolerance by default, so as a developer you have two less things to worry about. Additionally, serverless can improve application resiliency. Since your code is not hosted on one specific server, you do not have a single point of failure. If the machine your code is running on fails, the serverless provider will switch your code over to a new machine and there shouldn’t be any effect on the user experience. Basically, if developers aren’t worrying about servers, they can spend that time and energy on developing scalable and reliable products.

But someone still needs to worry about the servers because our code isn’t running magically in never never land. Even from an ops perspective there is a potential for saving money. First, you won’t be running and paying for your application 24/7, only on-demand. Additionally, just like with microservices, with serverless infrastructure you can optimize your resources which could also cut down on costs.

Serverless seems great so far, but behind the hype there are some downsides. First is the complexity of designing and maintaining serverless architecture. Breaking your application into microservices introduces complexity. Breaking your microservices down further into functions takes complexity to a whole new level. There is architectural complexity of designing and building a distributed computing architecture. There is the complexity of maintaining such a system and there is also the pain of debugging a distributed system. As of now, there aren’t that many tools to help developers monitor/debug serverless environments but I’m sure there will be soon.

The second downside is performance. In a serverless architecture, you will experience higher latency as your functions respond to the triggers/requirements of the application. When your function is triggered for the first time after a while, a machine has to spin up for your function to be executed. In AWS Lambda, your instance stays up for about 10 minutes after your function’s first execution so it’s available for any subsequent calls. After those ten minutes, you will have to wait again for a new instance to spin-up. If performance is a high priority, I would stick with allocated servers (cloud or on-prem).

The third problem is vendor lock-in. Switching from one vendor to another would probably require you to update/change your code, operational tools, design and architecture. So moving your code from one solution to another would require significant energy. Currently there are several vendors on the market. Here’s a brief overview of the top 4 (in no particular order):

1. AWS Lambda is probably the biggest and most known serverless framework. It started with Node.js but supports Java and Python. AWS Lambda is convenient to use as it is integrated with other AWS services and the Alexa Skills Kit. A developer can use the interactive console and/or command line tools to upload and manage code.
2. Google Cloud Functions is an AWS Lambda competitor that runs on Google’s public cloud infrastructure. This platform supports only Node.js. One main differentiator between Google Cloud Functions and AWS Lambda is that AWS provides more services that can integrate with Lambda. Only a few services such as Google Cloud Storage are integrated with Google Cloud Functions.
3. IBM OpenWhisk is an open source alternative to AWS Lambda and is integrated with IBM Bluemix. OpenWhisk supports Node.js and Swift. Developers can interact with the framework through a CLI and can install OpenWhisk on a local Ubuntu machine. I think the best part of OpenWhisk is that it can be integrated with any 3rd party service that supports Webhooks.
4. Microsoft Azure Functions supports a variety of languages including JavaScript and Python. Microsoft provides an IDE in their portal to help developers prototype and deploy their functions.

I believe that AWS Lambda is the most mature serverless framework. AWS launched Lambda in 2014, Google and Microsoft launched their alternative solutions two years later. AWS Lambda supports advanced features like request chaining and edge processing and integrates into a wide range of AWS products.

In conclusion, is serverless worth all the hype? In certain use cases and situations, serverless can be brilliant. If your application is event-driven or used sporadically and performance is not an issue, it is a good approach for consuming cloud resources while keeping cost low. However, it is not ideal for other situations like when you have a long-running task/service. In these scenarios, serverless could end up costing you more money, negating one of its primary benefits. I think right now serverless is a little young and enterprises are still trying to figure out if it is the right solution for them. I am, however, very excited for the future of serverless computing as I believe it has great potential, especially as more tools to monitor and debug functions evolve.

This is my eighth post in my "What is" tech blog series. I'll be writing more every week here and on my blog!