Serverless Apps: The Most Important Things You Need to Know

Building serverless apps or setting up a serverless architecture has been a pretty hot topic in recent years.

But seeing if this is the right fit for your application is not that clear.

So in this post, we compressed every information you need to know about serverless applications, collecting the pros and cons to make your architectural decision much easier.

We kinda live and breathe serverless architecture, so if you have any questions, we’re happy to help.

Serverless definition

Honestly, the word “serverless” is quite misleading.

Even though the technology is called serverless, your application isn’t running on thin air.

In case of serverless architecture, you don’t have to worry about setting up and managing the server infrastructure. You don’t have to have your own physical server since your architecture runs in the cloud.

You don’t have to worry about maintenance, scaling and the processes of the server since everything is taken care of by a service provider such as AWS.

When you have a serverless architecture, you only pay for the resources your application/function consumes, and you have infinite scaling on your functions or app.

To achieve the insane scaling, each function of your app runs in a different container. They might be on different machines too!

Their lifecycle is super short. Once a triggering event happens, a container with your function is initialized, your code is executed, and after some time, the container is gone. We cannot use the underlying server to store the application state, file or anything else.

With serverless architecture, you don’t need the traditional always-on server infrastructure. Serverless architectures are event-triggered, working only when there is activity in your app.

There are also powerful frameworks you can use to develop and deploy serverless applications. More on this below.

Is serverless the right architecture for my app?

Is serverless architecture the right choice for your app? Take this short test to figure this out.

Note: This is just a high-level estimate, so don’t take this as architectural advice. Before jumping in to serverless architecture, make sure to consult with serverless experts. We’re here to help.

Serverless advantages

Why should you consider a serverless architecture? Here are some advantages you can expect.

Reduced operational costs (infrastructure and human), spend less time on managing and maintaining the infrastructure
Reduced development costs: serverless backend is commoditized and handled by a 3rd party
You can run code for virtually any type of application or backend service
Scaling is completely automatic depending on the resources required by your application, fully managed by the provider
Cost effective since you only pay for the computing power that you need; perfect if your app has inconsistent or occasional requests
High availability
Running a serverless architecture requires less coding
Packaging and deploying an application is pretty simple, compared to deploying a whole server
Optimize without making infrastructural changes by making your code more efficient; this could significantly decrease the operational cost of your serverless application

· Easy integration with other cloud services

Serverless disadvantages

Besides the upsides, serverless architecture bears some disadvantages too.

Vendor lock-in: It’s much harder to switch vendors and migrate the whole architecture to another service. You probably need to change your code as well to fit in your new cloud provider.
Startup latency: Cold-starting the architecture could cause latency since initializing a container can take up a lot of time (probably seconds).
Time limit: A lambda function can run for up to 3 minutes, so working with big data or other time-consuming operations is just not possible with AWS lambda.
Database connections: Since all our functions run on a different container, you can’t create a singleton of a database service. Every function will have its own connection to your database, and that might cause some troubles on performance.
No access to the server infrastructure: Your infrastructure is managed by the provider but it also binds your hands.
You’re giving up control of your architecture system downtime. Unexpected limits, cost changes, loss of functionality, and forced API upgrades can happen any time.
Multitenancy: Your architecture runs somewhere on a physical server along with many other customers using the same infrastructure.
More difficult integration tests.
More infrastructure code: You need to write more infrastructure code to keep a serverless app running.
Breaking your app into functions is not trivial.
Do you trust a service provider to run your app in the cloud?

Serverless frameworks

There are two main serverless frameworks we use to easily deploy serverless apps.

Serverless framework (yeah, that’s its name): Open-source CLI for building serverless architectures. You can also add a serverless plugin that helps you test your lambda offline.
APEX.run: Apex lets you build, deploy, and manage AWS Lambda functions (works only with AWS)

Click here to learn all the serverless trends you need to know!

Serverless App Case Study

Madbro is a serverless advertising platform where users can pay for gated content by watching targeted video ads.

It also provides an alternative and more efficient business model for online publishers, increasing revenue without distracting the audience with unsolicited advertisements. Since the application has to deal with a volatile load, using serverless backend was a hands-on solution to handle load spikes.

Madbro is a web application that can be integrated with any website, and it’s also compatible with every platform (such as iOS, Android, and Windows).

It applies an online micropayment technology letting users pay by watching videos.

The application has a full serverless backend except for MongoDB built with AWS CloudFront, AWS API Gateway, AWS Cognito, Amazon Simple Storage Service (S3), AWS Lambda, AWS Elastic Transcoder. Backend has built-in error tracking using Sentry and Cloud Watch.

What are these services doing?

CloudFront for distributing and caching s3 stored commercials and admin application
Elastic transcoder for creating different commercial video formats for different platforms
AWS Cognito for admin users, handling different groups with IAM
S3 for storing videos and transcoded videos
AWS Lambda for running the application logic and authorization of API calls
AWS API Gateway for connecting REST calls to AWS lambda handlers

Conclusion

Serverless architecture definitely helps solve some burning architectural issues such as scaling and making your infrastructure cost-effective. Apart from the many great features it offers, there are some disadvantages that need to be carefully considered. You can use our serverless grader to give a rough estimate if your app’s characteristic matches with the serverless requirements. If you’re considering building an app on serverless architecture, you need to know that a bunch of serverless experts are ready to take your project to the next level.