Back to Blog

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:

  • 1
    Figma – is a multi-million company that is developing one of the best solutions for professional designers. Serverless approach allows Figma to work quickly, efficiently, and also makes it possible for several designers to work on the same project at the same time.
  • 2
    Coca-cola is also using serverless in its services. One simple example is coca-cola vending machines. The logic is simple. The client buys the drink, the vending machine calls the payment gateway, if payment is successful – it makes the REST request to the AWS API Gateway, which triggers the Lambda function with business logic that processes the history, sends the push notification back to the client and so on.
  • 3
    Netflix is actively using serverless in its product. Publishers upload many files, which need to be processed. Many files are updating, for each file Netflix creates the backup. For all this complex batch processing, serverless is great, which is what Netflix uses.
  • 4
    Codepen is a popular product, designed for web developers, where developers can share their code. Because of serverless codepen servers up to 200000 requests per hour without any problems.

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

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?

how it works

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

aws vs azure

  • 1
    AWS Lambda
    Amazon Web Services (AWS) is the most known cloud provider with an excellent reputation. Lambda launched in 2015 and was one of the first FaaS platforms. It has been actively developed since then and now it is used by approximately 62% of users. Amazon has a large base of cloud services and the lambda is implemented in such a way that it is most convenient to use with these services.
  • 2
    Azure Functions
    Microsoft Azure - another huge cloud provider with a lot of services, that provides a FaaS platform. Introduced in 2016 after Lambda, which allowed it to become the second FaaS platform on the market. Currently, about 20% of users use Azure Functions.
  • 3
    GCP Functions
    Another interesting cloud platform was developed by Google in 2018. It was introduced later than its main competitors, but uses newer technologies and supports later versions of programming languages for writing functions. Google accounts for 12% of all serverless users.
  • 4
    Alibaba Cloud Function Compute
    One more popular solution is released in 2019. It provides an ability to use a shared file system in different functions, which might help you in case you are going to port some legacy code to a serverless platform.
  • 5
    Knative is a very interesting serverless solution for those, who need more customization than regular FaaS platforms could provide. The user himself decides how to deploy this platform, which can both solve many problems of the serverless architecture and add complexity. This approach requires more expertise than conventional serverless solutions.
  • 6
    Cloudflare workers
    Cloudflare workers is a FaaS solution the main feature of which is the minimum delay. Cloudflare has 200+ servers around the world and runs your functions (they call it “workers”) on the closest server to the end user. This platform supports only the languages that haven't cold starts and has the lowest price on the market. Cloudflare - it is a good decision for non-complex tasks, but it has a lot of limits. Full list of limitations you can find here here.
  • 7
    IBM Cloud Functions
    Ibm Cloud Functions (also known as IBM OpenWhisk) - is another popular FaaS solution. IBM also has a big amount of services, so it will be comfortable to use the functions inside the IBM’s ecosystem. That platform supports running functions in docker containers, so the function can be created in any programming language. IBM also provides an Swift SDK, which could be useful for Apple developers.


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.

faas platforms

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

how it works

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.


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:

  • 1
    Serverless Framework
    Languages: Depends on the selected provider.
    Providers: AWS, Azure, Tencent, Google, Knative, Alibaba cloud, Cloudflare Workers, Fn, Kubeless, Openwhisk, Spotinst.
    Serverless Framework is the most popular command line tool which can improve your experience with serverless. It can easily deploy, update, rollback, invoke your functions, create events, show logs, monitor metrics and much more.
  • 2
    Languages: Python.
    Providers: AWS.
    Zappa is a Python framework for AWS that also allows you to manage your functions with a command line interface.
  • 3
    Languages: Full support: NodeJs, Python, Ruby. Sandbox may be not supported: Go, .NET, Java.
    Providers: AWS.
    Architect is a powerful framework that makes it easier to build web applications on AWS. It Supports not only Serverless management, you can also deploy an IaC with it.
  • 4
    Lambda Framework
    Languages: Java.
    Providers: AWS.
    Lambda framework is an open source solution for Java that makes it easier to deploy serverless applications to AWS Lambda. It supports JAX-RS annotations, which make creating REST applications easier.
  • 5
    Spring Cloud Function
    Languages: Java.
    Providers: AWS, Azure, OpenWhisk.
    Open Source framework for Java with multiple cloud adapters. With this framework you don't have to worry about features of writing functions for a specific provider.
  • 6
    Languages: GO.
    Providers: AWS.
    Sparta is an open-source framework for building, deploying and testing GO applications on AWS Lambda. It supports integration with different AWS services which you can connect to your function.

Strengths, weaknesses, threats and opportunities of serverless

Strengths and weaknesses 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

  • 1
    Functions should be encapsulated.
    Each function should be as a “black box”. No one should have to think about how the function works. You just call it and get the expected result.
  • 2
    Decoupling logic into small pieces and making functions for them.
    The function must be used for tasks of the same type. For example, in an IaC application you have two endpoints: “getCar” and “getAllCars”. These endpoints perform similar but different tasks and usually they are part of the same microservice. In a serverless approach, you should make two separate functions: one for getting a single car and another for getting all the cars.
  • Decoupling logic into small pieces
  • 3
    Functions can be reused.
    It's a good idea to use a single function several times in different cases.
  • 4
    Reduce cold starts.
    In some programming languages starting an application may take some time. The faster the function will run, the more effective it will be and the less you will need to pay. For example, if you are using Java - try to avoid creating the functions with Spring Framework. It’s a very powerful framework for server based applications that are constantly running, but such applications take big amounts of time to initialize which is bad for serverless applications.
  • 5
    Use caching.
    If your application often receives similar or identical requests - you can speed up its processing and reduce the cost by using the cache.
  • 6
    Optimize function’s memory size.
    The memory allocated to the function, as well as the time of its operation, affects the final cost of its execution. So, it will be a good idea to analyze how much memory your application actually needs and configure function preferences accordingly.
  • 7
    Use serverless scalability to build synchronous architecture.
    As you can see in the picture above, using synchronous architecture can greatly speed up the task.
  • Use serverless scalability

    Use serverless scalability

Serverless “anti-patterns”

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

  • 1
    Calling functions from another function.
    The functions should be stateless. So if the function calls another function and waits for the result of its execution – it is a very gross mistake that negates the advantages of the serverless approach.
  • 2
    Writing too much logic to a single function.
    Another mistake is making the function something like a monolith. Function should be light and not contain too much logic. Otherwise, every time your logic is triggered, your architecture will run a heavy, cumbersome application.
  • Decoupling logic into small pieces


    Decoupling logic into small pieces

  • 3
    Using synchronous architecture.
    Try to avoid using the synchronous architecture, working with data queues. Parallel executing of data processing logic is much faster than to process each piece of data in turn.

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)

Event-driven data-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.

Chat bots

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.


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.

IaC is right for you

Feel the benefits of Kaa Cloud on yourself

Related Stories

Improving IoT Integration: KaaIoT & TEKTELIC Partnership

KaaIoT & TEKTELIC partner to simplify IoT development with pre-integrated hardware & software solutions....

KaaIoT & Supermicro Collaborate to Provide AI-Powered IoT Solutions for the Edge

KaaIoT and Supermicro offer a combined solution for AI-powered IoT applications at the network's edge...

Machine Condition Monitoring: A Detailed Guide & Case Study

Uncover the potential benefits of machine condition monitoring in reducing downtime and increasing overall productivity...

Understanding IoT Device Management: Comprehensive Guide

Unlock insights into challenges, best practices & solutions for seamless IoT device management with our in-depth guide.