5 Types of Applications That Should Be Serverless Florian Follow Jan 8 · 8 min read

So you want to go Serverless, eh🏋🏼?

At Eightygram we think that too much knowledge is lost when experts discuss things in private. We build a platform for conversations that are public yet protected and hope to create a unique experience on the web. We’re at the very beginning but you can help us by signing up or sharing our mission. Thanks and much love!

Some background and terminology

There has been an evolution in the cloud-computing space with serverless being the next step in server-side application design. So what is the difference between cloud-computing and serverless? In cloud computing, the typical user rents server space and processing power. Since you rent the entire resource, it is available 24/7. The resource itself doesn’t care if you use it or not.

This pattern changes with serverless applications.

The idea behind serverless applications is that the resource itself will only be created when it is used. So you will use resources when a user/client actually interacts with the application.

You — as a developer — have to write special functions and deploy them to a managed service (AWS Lambda, Google Cloud Functions etc.). A typical HTTP-flow will look like this: (1) the user sends a HTTP request, (2) the request will be processed by the infrastructure (3) a container will be created for the relevant function (4) the function executes (5) execution finishes and the resources are freed.

This pattern is called Function-as-a-service (FaaS) and is often used interchangeably with the term serverless.

The approach embodies everything the millennial developer wants: hands-off, freedom, four-hour-workweeks and so on. You get the point … 🚀🚀🚀

In short, serverless promises effortless scaling and reduced costs.

Motivation

Over the last months, I have been reading countless articles about this topic, hundreds of pages filled with confusing information and opinions. I ended up building a prototype. After some testing, I reverted my architecture to a traditional stack.

This was a lot of trouble.

Taking the painful route, I discovered that serverless has its use-cases but you should take the time to research before diving head-first into the delicious flavour-of-the-month architecture 🍬.

Word of caution

Serverless !== AWS Lambda: There are a lot of service-providers for serverless architectures — with AWS Lambda being the most notorious one. This article is heavily derived from my experiences with AWS Lambda. Most, but not all, of my findings can be extrapolated to other providers.

Swimming WITH vs. swimming AGAINST the tide: Yes, you are a developer and with enough hacking you’ll turn your Linux server into a rocket ship 🚀. However, choosing the right tool for the right use-case will feel like swimming with the tide. Doing the opposite will feel … well, like the opposite. Obviously, much is possible with Serverless. This article is for people who want to swim with the tide, not against it. If you want an article about complicated VPC architectures and experimental databases, this article is not for you.

When should you go serverless?

1 Go serverless if your app doesn’t have many users and you don’t plan to scale

Serverless is a great way of running a very small app that does not have many users. The advantage for this use case is the price. Running a reliable, small infrastructure with serverless is dirt cheap.

Here is a pricing example for an app with 1000 users making ~20 request/day (source: serverless-stack.com):

For 6.10$ you can run a small app that has 24/7 availability, close to zero maintenance requirements, data backups etc. Thats something! Don’t buy into the myth that prices will stay this low once you scale — they won’t!

2 Go serverless if your traffic looks like this

Function-as-a-service is on-demand. Everything sits on the server cold and only once the user-request comes in, a container is created and your function gets executed. Ergo: you only pay for when your function gets executed. This makes serverless a great solution if you have lots of periods where users won’t (or barely) use your service. Look for spiky traffic patterns!

This point is especially true when you are using the AWS infrastructure with DynamoDB — your go-to database for Lambda (FaaS).

DynamoDB has a nice new pricing model for exactly these kinds of usage patterns called on-demand. You can end up saving a lot of money since you won’t be paying much when traffic is low.

On the other hand, if your traffic is uniformly distributed and high you should be prepared to open up your wallet… and I mean big time (see: https://gist.github.com/jordansissel/1797961). This is partially true for all major cloud providers but especially valid for AWS DynamoDB.

And you won’t be migrating to a cheaper solution soon because you’ll be pretty locked into the proprietary eco-system of your cloud provider.

3 Go serverless if your app has very predictable data access patterns

Do you know exactly what your app will end up doing when designing your database? Have you mapped out every way users access their data? Are you certain these patterns won’t change in the future? Good news, serverless might be for you. With serverless you are quite likely to end up using a NoSQL database such as DynamoDB or Google BigTable. While these databases offer flexibility when it comes to the data they can store, they are certainly not flexible when it comes to the ways you can access your stored data.

So if your app can rely on a simple key-value-store database and that’s all it’ll need for the rest of its life — good for you.

If you are building e. g. a social application where new use-cases may arise in the future — going serverless will feel like swimming against the tide.

4 Go serverless if you want to scale infinitely and are able to handle the cost

If you are running a mega-application that needs scaling beyond the usual standard and you have the financial backbone to pay for the incurring costs, serverless can be a great option.

If you’re a company of the mentioned size, the decision is likely to be between a DevOps team or a completely managed service. And quite frankly, both options are expensive, so it’s quite possible the the math will work out. Anyway, if you are a company of that size, you should probably not rely on advice on Medium in the first place: So, go and call your enterprise-sales-rep of choice ☎️.

But be aware that running mega-/high-reliability/super-performant apps on serverless will come with its own pitfalls. These pitfalls will require overhead and management of their own. Testing, building development environments, the need for custom tooling, cold starts (bad performance on some requests), hot shards etc. will require you to put some considerable work into your serverless architecture still (see: https://segment.com/blog/the-million-dollar-eng-problem/). If you are unlucky, you might end up with the same DevOps team and a AWS bill that will squeeze your lemon 🍋.

5 Go serverless if you aren’t handling enormous files nor Websockets

With functions-as-a-service (FaaS) there is usually a maximum amount of time that you can run a single function. Until 2018 this has been 5 min. for AWS Lambda — now it’s 15 min.

If you need to upload big files e. g. 4k movies to a S3 bucket, 15 min. may not be enough and you have to get really creative with a serverless architecture to do this. Generally, you will be using lambda for something it was not designed for. Ergo: You’ll find yourself swimming against the tide.

The stand on Websockets with serverless is a little more complicated. While you can do it, and you will find some resources showing you how it can be done, I’d argue that you’re better off with a traditional backend (if you’ll find yourself seeking more info about the topic drop a comment).

More things to consider

There won’t be much tooling ready for you

Serverless is pretty immature. The Serverless Framework is a pretty popular approach these days and has been around for some years.

But the Framework is pretty slim. If you are used to the comfort of modern MVC frameworks, you’ll find yourself building a lot of stuff from scratch. You are, in many ways, re-inventing the wheel … haven’t we been taught not to do that?

Debugging your application will also be quite cumbersome. You’ll most certainly find yourself putting a lot of console.log() in your code. After that you’ll get to scrape logs from cloudwatch (in case of AWS).

It’s not all bad: The integration with AWS IAM, Cognito and Cloudformation works quite well

If you aren’t familiar with the services of your cloud provider, there is a lot to learn before you can use serverless productively. In the case of AWS you have to get a good grip around API-Gateway, Cloudformation (Infrastructure as code), IAM etc.

Once you’ll have a good grip around these topics, the integration works quite well. But be vary: You’re now fully locked into the ecosystem of your cloud provider — with all the benefits and pitfalls.

You have to take the time to dive deep into NoSql data modelling

For many people serverless is a great reason to dip their toes into NoSql since Amazon and Google offer great integrations for NoSql and FaaS. Coming from the world of SQL and normalised data schemas, this isn’t an easy task! And since your data access patters (the way you query your data) are pretty inflexible once put into production, you should take the time to investigate how to model you data correctly. This will take time but can be a great learning experience.

Conclusion 🎉🎉🎉🎉

Serverless is exiting and fun. Currently, I see the pricing as a prohibiting factor. Serverless sure isn’t a silver bullet but for the right use-case it might just give you that nice, cushy feeling of swimming with the tide.

Stay happy and keep hacking 🤖!

I’m trying to build a twitter audience. If it works, i’ll publish more helpful coding tricks. Follow me https://twitter.com/FlorianMartens9 😜