Why you could use Serverless for your startup

One of the most common hurdles, that I see for makers to start building a tech tool/product/startup, or whatever you want to call it, is the cost of starting up. I never really liked the idea of having a server running 24/7 when it is not doing anything. At that moment you are basically paying for IF something would happen and that is just throwing away money. (I know there are free services on AWS and other PaaS solutions but it is still running 24/7 for a prototype, sounds a bit silly to me). Throwing out money. Giphy Let’s be real here, your app is not going to be an overnight success you don’t have to worry about usage spikes and even if it happens, Serverless will scale with it. The free tier is also pretty generous on the PaaS services(AWS, Azure, Google Cloud,…). As you can see (below) AWS Lambda gives you one million requests per month and 400,000 GB-seconds of computing time (or up to 3.2 million seconds of computing time) per month. The function that I wrote to handle stripe transactions takes between 1,100 and 1,400ms to complete. At that rate, I can handle more than 100,000 calls a month which is way more than I would need to make a prototype. Here are some resources for comparing and calculating prices. for comparing between the different PaaS solutions and for comparing an EC2 instance vs Serverless. http://serverlesscalc.com https://servers.lol/ The AWS Lamba Pricing What is this Serverless sorcery? With Serverless you don’t deploy one backend on your server but you will deploy every function from your backend separately from the rest. You could look at it as a microservice backend but then without the communication between the services. It is technically possible for Serverless functions to call each other but this not best practise. For serverless you will always try to do . One function does one thing. This is not only from a design philosophy perspective but also from a financial aspect because calling different functions will elongate the execution time for the function, which is bad. You only have a finite amount of computing time in your free tier so faster = better in this case. Now we have these functions deployed somewhere on amazon’ server farm. But what now? How do we interact with them? Well there are two options: separation of concerns A REST call Triggered by events The REST call is just the same as always. For example you want to create a user. With a normal server you would make a POST call to the /users endpoint. For Serverless functions it is exactly the same. You define the endpoint for a specific function when you deploy this function. The REST call will trigger the function behind the endpoint and when this function is done, your REST call returns and the instance will close again. Your PaaS solution will calculate the difference between the start time and end time for this execution and you will then get billed for this time that is expressed in ms. For the events it’s pretty straight forward. You can bind events to the functions. For example you have a function that compresses images. You can set this function to be triggered every time an image is uploaded to an S3 bucket. The same procedure that I mentioned before will then start . The function will execute, the instance closes and you only get billed for the execution time. When do I use Serverless? There are two simple checks I do before deciding to work with a Serverless backend. First I ask myself: “Do I need a backend?”, and I mean do you really need a backend to validate your idea? If you don’t need a backend then DON’T use a backend! Those nice-to-have features with a backend can still be added later. You are just creating overhead that you don’t need for the moment. The next question I ask myself is: “How complex will my backend be?”, this is a more difficult question to answer because there is no simple yes/no answer or a clear guide on when something is too complex. You kind of have to decide for yourself what you think will be too complex. Let’s say we have an app with a backend to handle the following features: user authentication, interaction with a database to provide a service and a payment function to pay for this service. Alright, let’s look at what we need here. To save some data and to provide login and registration we only need basic CRUD (Create, Read, Update, Delete) operations on for example a DynamoDB, if you host on AWS Lambda. The payment can be handled by one function if you use Stripe. As you can see this backend is basically about five functions long, not that many. I would say this is definitely possible with Serverless without having to worry about expenses. Now you could say there has to be a third question, something like “How many visitors will your backend have to handle?”. Although that is definitely an important question to ask, I will leave it out here because we are talking about prototypes that are realistically not going to get that much traffic in the beginning. Even if you would get spikes, Serverless will just scale with it. A short decision tree for Serverless How do I get started? You might now be thinking: “Alright that’s cool and all but how do I get started with this?”. I will be writing a small tutorial in the next article on how you write a nodejs serverless backend on AWS Lamda. Make sure to follow me on and to get notified when I post the sequel to this post. medium twitter If you liked this article feel free to follow me on to get notified when I post another article and follow me on to stay up to date on what I am doing/building. medium twitter