Serverless

No upfront cost

When you are starting a new project, you do not want to pour hundreds of dollars into your infrastructure before anyone is using your product. Since the serverless model charges for actual usage instead of a fixed price for running your infrastructure, you only pay when your SaaS product is being used. In many cases, the top cloud providers have generous free tiers that you can use to further minimize your costs. Read more about how to run your SaaS for free on this page.

No manual scaling

If you get a surge of unexpected traffic, you do not need to worry about scaling up and down manually to keep your service running. Your infrastructure will scale automatically without human intervention. This helps you focus on building features that your customers love instead of worrying about your site going down.

No infrastructure management

Setting up your own Linux server gets old quick. The time you spend configuring, updating and managing a server can be spent in a lot better way when you are starting up your project. Running a serverless stack is simple. Upload your code and let your cloud provider handle everything else for you.

Although a serverless architecture might be a good choice for many services, there are some drawbacks that you need to consider. Read more about the drawbacks we have have identified and how you can work around them.

Usage spikes might cause unexpected cost

While the variable cost model of serverless infrastructure is usually positive when you are starting small, it might be hard to predict the cost each month. For example, if your product goes viral and you get tons of traffic to your site it might generate hundreds of thousands of extra Lambda invokes or terabytes of S3 storage. If you would use a dedicated server, costs will be fixed but on the other hand you risk overloading the server.

There are a few ways to avoid these issues:

Make sure you activate cost alarms that send you a message when your costs pass a set limit. Make sure you consistently track your cost and make changes to minimize cost. For example, enable API caching so that you do not always call your Lambda functions on every API request. Implement an emergency fallback that takes your service offline if the costs are spiking out of control.

Vendor lock in

Using a serverless tech stack instead of going for a service running on a dedicated server means you most likely will have to write your application for a specific cloud vendor. If you at some point would like to switch vendor, it might be time consuming to make the switch. This drawback can be serious if you have a very large codebase. However, our experience say that if you use best practice programming patterns such as the ones used in Volca when building your product you should be able to switch platforms without drastic code changes.