Guide on Serverless Architecture, Patterns & Use Cases

In the last few years, we have been hearing more and more about serverless technologies. This approach is increasingly used in software solutions of world-class companies that spend huge resources to analyze which approach they should use for their decisions. Serverless helps these companies save a lot of money and handle huge workloads as their product can be used by thousands of people at the same time.

Someone says that serverless is almost an ideal technology, someone is skeptical about it and advocates a traditional architecture. But in fact - each task needs its own approach and this statement also applies to serverless. So in what situations what should we use? In this article, we will try to figure out what serverless is, as well as analyze in which situations it should be used, and in which it should not.

What is serverless?

Serverless is an approach of architecture building with a level of abstraction where you don't have to think much about how you'll deploy your application to the server. Serverless is also known as “event-driven architecture”. To use this approach you will have to use the serverless service of some cloud provider. Such service, which allows you to build the event-driven architecture is called Function as a Service (FaaS) platform.

The minimal unit of serverless architecture is a function. Usually, function - is an artifact, built in any programming language FaaS platform support, with FaaS API included and uploaded to the FaaS platform. A function is a small but self-sufficient piece of logic that is called, performs its task, and then turns off and does not waste resources.

Companies, using serverless in production

Currently, serverless is a fairly well developed and popular solution. This is why many enterprise-scale companies are using it at the moment. Obviously, such companies spend huge resources on the analysis of possible solutions and make only carefully considered decisions. Here is a few examples of such companies:

Why serverless?

If you choose an approach for your project – you can't just say "I need serverless". You need to analyze the problem first. Otherwise, you may run into problems when it will be too late to change such basic things.

For example, you need to process the data batches, produced by some device. You don’t know when and how much data it will produce. But what if there is no data from the device, for example, for a whole day? You hardly want the server to work in this case and waste resources just like that. Or suddenly 500 files appeared in a few minutes? Can the server cope with such a load?

In the described case, serverless is suitable for us, because we do not need a binding to the host and the load is not constant. And this is exactly what serverless is good for. You won't have to pay for running servers when you don't need them. And if a large load suddenly appears, FaaS can launch a large number of replicas of your function at one moment.

The function replicas can execute the logic for each file in parallel. This approach allows you to quickly cope with a large load, since the processing of all files will take place simultaneously and independently of each other.

Of course, you can run such a solution on a server, but in that case you will pay more money for that and it will be much more difficult to make your solution handle a heavy load. It will also take a lot of time and effort from developers who could do something more useful.

So using a serverless architecture – is a best practice for the described case.

Serverless patterns

Server architectures have evolved over time. Gradually, for many stages of building the project architecture, ready-made solutions appeared that allow you to automate their configuration. And if 20 years ago you needed to purchase server hardware, connect it, take care of cooling, install an operating system, set up a runtime environment, now a cloud provider can take on all these tasks.

Today there are two common approaches: IaaC (Infrastructure as a Code) and FaaS (Function as a Service). Both of these approaches have different levels of abstraction. Let's figure it out.

What do we need in the IaaC case? Let's say the application is deployed on a cloud provider instance. In this case, we need to install an operating system on this instance. Then set up the runtime environment, configure CI/CD services, take care of security and so on. In the case of serverless, we can abstract from this as well – we don’t need to configure an instance, operation system and CI/CD anymore. The FaaS provider does it for us.

All we need to do is to break the task into small logical processes, describe them as functions in the language we need and upload the target on the FaaS platform of your cloud provider.

How does it work?

When some event invokes our function, the FaaS platform starts the container (do not confuse it with Docker container) with the function. The container starts the runtime environment, our logic is executed, some data is returned, but the container does not disappear immediately after that. It exists some time after the execution (for different cloud providers, this time is different) and waits for other requests. If other requests come after that, they can be processed in the same container without the need to start the runtime (JVM, etc.).

What happens when the FaaS platform receives one more request but the container is already processing the preceding one? In that case faas starts another container which will execute the logic concurrently to the previous one. Thus, in the serverless approach, excellent horizontal scalability is achieved.

But how can we manage our functions? If in our usual serverful approach all microservices work constantly, communicate with each other with requests, and so on, then how to set up interaction with functions in a serverless architecture? There are two main approaches to building the serverless architecture: orchestration and choreography.

Both of these approaches allow you to make interaction between services more abstract. The cloud provider gives you something like an “architecture constructor” in which you can combine functions, databases, file storages etc. into a single system and link them using events.

A few words about providers

There are many cloud providers (vendors) that offer serverless services. Each provider has its own features, prices, rules, and so on. We’ve gathered the most interesting vendors for serverless that you can find below.

AWS vs Azure vs Google Market Share

Comparison

Here is a quick comparison of the described services. In this table, you can see the difference between prices of different FaaS platforms, supported programming languages, and other interesting things.

Programming languages

Serverless functions can be written with various programming languages. Each language has its own application launch features, which is very important in the serverless approach. Some languages can start applications almost immediately, and some languages need to prepare a runtime environment, initialize something, and so on.

Here is the graphic of the most popular languages for serverless.

Top languages used in Lambda functions

Python and Node.js are the two most popular lambda languages

As you can see, Python and NodeJs are two most popular programming languages ​​among companies that use the serverless approach. Python and Node can execute functions without any cold starts which makes the execution of functions very fast and efficient.

3rd and 4th place – Java and GO. Java applications take a huge amount of time to start, but it’s able to execute very complex tasks.

Depending on the features of different programming languages, the scope of these languages ​​in the serverless approach may be different.

Java could be used in a serverless approach if you need some kind of complex logic, which Java can handle better than other programming languages. Java has a huge amount of different libraries that can help you with such tasks. In my own opinion, it is worth using Java in the case when, for the sake of the advantages of executing code in this language, you can put up with cold starts. For example:

Python and NodeJs are more suitable for situations where each part that needs to be processed is simpler, but in general there are more of these parts. These languages ​​do not have a cold start and for handling a large number of small tasks, they will be much more efficient than Java.

• You already have some Java solution and want to make it serverless.
• Your specialists know Java well and will be able to write your solution faster and better on it.
• There are more suitable libraries in Java that can help you.
• You don’t care for a few seconds of cold start, because the Java application processes the information you need faster and you win more on it.

Again, if your specialists know one of these languages ​​better, this can be an argument in favor of this language.

Frameworks

By themselves, serverless functions are incredibly simple and convenient for developers. But no matter how great FaaS platforms are, there is always room for improvement. Therefore, there are a huge number of different frameworks from third-party developers that make deployment and management of functions even more convenient.

Here is a few examples of the most popular of them:

Strengths, weaknesses, threats and opportunities of serverless

Serverless: Benefits, strengths, and opportunities

• Price. You can pay only for the resources your application uses. If there were no events that launched your application, you don’t need to pay anything.
• Instant horizontal scaling. The logic will run as many times as the events will trigger it.
• No need to develop a complex architecture, test it, fix bugs, and so on. The provider gives you a ready-made, reliable infrastructure in which you can easily deploy your solution.
• Event driven. Serverless functions are not working in the background, when they are not needed. Also the event-driven model gives an ability to start the logic as soon as, for example, some file appears in storage. No need to make an additional logic, which will check for the new files.
• Security patches. The vendor regularly releases security patches for its platform. Therefore, you do not have to update your application every time when information about a vulnerability in a particular technology appears on the Internet.
• Just like in the case of security, the vendor regularly improves the platform, adds some new features and increases the stability.
• Cloud providers have instructions and documentation that can help you with usage of the FaaS platform. Also popular vendors have a large community, so you can find many discussions with information about your problem.
• Vendors have their own professional expertise with various scenarios of their platform usage. So you can just use that expertise and follow the best practices.

Serverless: Drawbacks, weaknesses, and threats

• Price. Price can be both an advantage and a disadvantage of serverless. That’s why you should make an analysis before choosing an approach. Serverless chosen for the wrong tasks or used incorrectly can be much more expensive than IaC.
• Cold start. Your application starts running when some event triggers it. Starting an application may take some time. That’s why you should choose the programming language wisely. For example, functions written in Python will run almost instantly. But in Java it is easier to implement logic for complex tasks.
• Hard to troubleshoot. If you have a project that contains many functions and some error happens – you can see only the logs that the vendor gives you. Therefore, you should take care of the tools that will help you detect the problem.
• Vendor lock-in. Using serverless in, for example, AWS Lambda – is much more comfortable when you are using it with other AWS products. Such projects are very easy to connect to DynamoDB, S3, Secrets Manager etc. And the more such services, the more difficult it becomes to switch to another platform. And also, other services have different pricing. You need to keep it in mind if you decide to build a serverless application.
• Throttling. If you have a serverless website and millions of people accessed the site at the same time – the provider just can’t give you so much performance at the same time. For example, AWS can start 1000 replicas of your function in a second. But if you need more than 1000 – other replicas will start with delay.
• Public cloud. FaaS means that the application runs on the provider's server. And some data may not be secure to process on a foreign server.
• You need to onboard the developers and give them some time to learn how to work with serverless.

Best practices

Serverless “anti-patterns”

So now, knowing the strengths and the weakness of serverless, let's find out what we should avoid in that approach.

Best use-cases for serverless

Usual approach with the server may cause some problems. It may be hard to develop the architecture, if you don’t know how much performance you need to process all the requests or data batches.

Speaking of batch processing, with the usual approach, it can be very difficult to build an architecture in which complex, spontaneously appearing data files will be processed in parallel. You need cron jobs to check for the new files, records in the database with its states, a lot of extra storage requests and some difficult logic for parallel data processing. All those problems (and not only) can be solved with the serverless approach.

Now, when you know about the strong and weak sides of serverless, let’s talk about best practices of its usage.

Event-driven data-processing (batch processing)

Imagine next situation: you have some devices, that produces some data. That data needs to be processed as soon as possible. And you don’t know the periodic of it’s producing. With IaC, you need to check if the data appeared by some timer.

Most likely will not notice the new file immediately or it will check for new files very often and spend many resources on that. And who knows how things will be with scaling if suddenly there are too many files in a short period of time?

Serverless can solve all of these problems. You can choose a new file appearing as a trigger of your function – and its replica will start for any new file.

Web Applications

Serverless can also be used for usual web applications. Static context can be stored in some cloud storage, while interactive elements trigger the serverless function by HTTP request. For example, it can be the form that asks for information about the user on the website. Users can ignore that form, and the function will not be triggered. This way, your function is not called - and you save the money.

Mobile and IoT applications

Similar to web applications, mobile applications can have a lot of static context that you hardly need a constantly running server to maintain.

Cron jobs

Another use-case for which serverless is well-suited is a cron job. If you need some logic to be executed by schedule, you can simply implement it with a severless approach. Most cloud providers have support for this feature out of the box. All you need to do is to add the cron job as a trigger for your function and it will start according to your schedule without wasting resources the rest of the time.

Chat bots

You can also use a serverless approach for implementing chat bot’s logic. In this case you can use both approaches: serverless and IaC. For example, you can host your bot on the server with minimal amount of logic and that bot will call serverless functions which will perform more complex logic. You should use a platform webhook service to customize your event’s handling.

Media processing

Serverless architecture is also a good solution for multimedia processing. You can make the functions for video transcoding, images resizing, and so on.

Conclusion

Serverless is not a one-size-fits-all solution. Thoughtless choice of this architecture in favor of others may cause serious troubles both in terms of performance and price. So before making a choice, you need to think carefully about what tasks your solution should perform.

Serverless is right for you if:

You need a decision for complex tasks that may appear spontaneously and intermittently, such as receiving and processing files from some devices, deploying an application for each user who visits the site, and so on.

Your decision has a static context with some optional executable logic. Some part of your logic requires an asynchronous execution with a high horizontal scalability.

You don’t want to think about security, environment and so on.

IaC is right for you if:

You need a long-running application, which constantly executes some kind of logic. You need instant answers from your applications without cold starts.

You are scared of vendor-lock and do not want to depend on any provider.