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):
- 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.
- 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.
- 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.
- 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!
Top comments (15)
great read :)
Great post! Thanks. :)
Brilliant read as always Aditi
Biggest advantage is that you don't maintain the server, you just pay for them. :) Also, you can choose which vendor will lock you in it's technology stack. :p
True, serverless is much more than FaaS.
Sure, you can run your functions on the infrastructure of Amazon, Google, Microsoft or IBM, but to me it seems they are just tiny bits of glue code to use with the services that do the real work.
While you can use something like the serverless framework to abstract this FaaS stuff, the other services like S3, RDS, DynamoDB or Cognito aren't abstracted away.
Very nice article. The problem to me is that when something like this emerges, it becomes a silver bullet and everyone wants to use it everytime. I am not sure how a code can be aware of the server but I'll be looking further.
Seem interesting ! I ask myself if it's cheaper than a dedicaced as a Student.. It could be great for my final project !
Do you have any idea of that? Or if it's could be interesting in my case.
Anyway, a good lecture !
I would mention lack of readonly access to real infrastructure when debugging especially (logs) as con, and "don't care for uptime" as pros.
If you're using MS Azure Functions you can run your function on your local machine and debug it in the same way as other .Net projects with Visual Studio for instance.
I'm not sure how it looks like on other platforms.
Is it valid to think in a chatbot API implemented in a serverless fashion?
Interesting take on the whole serverless thing. I'm a little late to the game and I'm only just learning about it all now. Thanks for sharing this, food for thought.
Great article! I'd also add Google Cloud Run to your list of serverless, it's a different approach but in my view still serverless!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.