We went serverless with our new startup. And you should (probably) too.

#serverless #aws #startup

I have seen cloud tech change a lot in my 10 years of experience. AWS and GCP were not the default choice a few years ago, and I have worked in companies that bought and installed physical servers. What a nightmare! And this is why trying out serverless was the natural next step for me. I think everyone should give it a shot, and I wanted to share my experience!

I have a full time job, which leaves you with very little time to devote to passion projects. In our first side project, CI/CD was never the priority. I spent a lot of time restarting servers manually! But this time at Kaapi, we have worked hard to abstract away a lot of DevOps problems. Being serverless has given us a lot of free time and ability to focus on the business logic of code, and thus, give more time to customer problems. ‍

Why go serverless

Quick start up time - You can set up repeatable scripts to full fledged REST APIs really quickly without worrying about setting up infrastructure required to run your application, you get to focus on the core business logic code which should be the place where a developer spends their time rather than in setting up infrastructure. It simplifies packaging and deployment of your application significantly.
Cost effective - Going serverless has cost benefits across the board. Starting with a generous free tier for development which sometimes could even be good enough to run small scale applications. AWS lambda provides 1 million free requests per month in the free tier. There are no servers running at idle where you are paying for servers that aren’t doing any work for you. No additional hires are required for managing your infrastructure and DevOps work. And lastly, the time that you save is directly related to money saved! All these savings are great especially when you are bootstrapping.
Auto scaling - There is no additional code or changes in your infrastructure required to scale your application when your traffic increases. At best, you’d have to increase the upper limit of scaling with your serverless provider.
Aurora serverless to the rescue - You can always use a traditional relational database or a NoSQL database with a serverless application, but you’d lose the benefits that serverless is giving you in the first place, like the pay-as-you-go model, not having to run a server all the time, the benefits of auto-scaling. AWS Aurora serverless DB was the saviour here to help us keep the benefits the serverless architecture gives us even when using it with a database. I’m a big proponent of going serverless, but I’m not blind to the problems that come with going with a serverless architecture. ‍

When not to go serverless

Local development can get difficult - FaaS providers don’t always have a good way of building and testing applications locally out of the box, that’s where the serverless framework shines and gives you a great local development environment as well.
The cold start problem - It can be argued that serverless at the end of the day isn’t truly “serverless” as a server is spun up somewhere each time you invoke your function. This problem doesn’t really have a good solution, either your use case is okay with a slight delay that comes with a cold start sometimes or we work around and use a language like python over java which has a quicker cold start time along with work-around solutions like this which is a package that helps keeps your functions “warm” and in turn avoiding the cold start.
When you are obsessed with visibility - Serverless can become kind of a black box, you need to be okay with it for your use case. It sometimes becomes hard to monitor and debug. Provider dependency - When you choose to go serverless, you need to choose the serverless provider you’d like to go with like AWS Lambda, Google function etc. Once you commit to a vendor it is a tedious process to change and you are locked in to the pricing your provider is charging. Having said that, to a certain extent that is usually the case when you use cloud server infrastructure from AWS, GCP or Azure.

Keeping all these things in mind, and the fact that we at Kaapi wanted to ship things quickly - this has been a great decision for us until now! We use the serverless framework with AWS Lambda as the provider using python as the language of choice, API Gateway and the Aurora serverless database with a Psql engine for autoscaling. With our front-end being mostly in slack at the time of writing this post, we spent less than half a day setting this up on AWS, we haven’t had to make changes to our development, testing, deployment cycles in over 6 month we have been using this setup.