WHAT IS SERVERLESS ARCHITECTURE ?

SERVERLESS ARCHITECTURE MEANS AS A DEVELOPER YOU SHOULD HAVE TO WORRY ABOUT WHAT IS HAPPENING BEHIND THE SEEN!

SERVERLESS DOESNT MEANS NO SERVER!

What is a serverless architecture?

Serverless is a cloud-based code execution model where cloud providers, instead of developers, deal with servers and computing resource management. There are no virtual machines or physical servers: they are deployed automatically in the cloud by vendors.

Cloud providers take care of provisioning, maintaining, and scaling the serverless architecture. What’s more, the serverless architecture allows launching apps as needed: you don’t pay for ‘always-on’ server components to run your app when it’s not being used. Instead, some event triggers app code, and the resources are dynamically allocated for that code. You stop paying as soon as the code is executed.

So, in a nutshell, serverless architecture is a way to build your cloud-based application without managing infrastructure. It eliminates the need for routine tasks like security patches, capacity management, load balancing, scaling, etc. 

Still, serverless does not mean there are no servers at all. The term is somewhat elusive. Servers are simply eliminated from the app development since they are managed by the vendors. 

An application like this usually consists of single-purpose functions where one function means one action execution. A developer creates a module or function that executes a certain action and sends it to the cloud provider. To update it, a developer uploads a new version and initiates the change. At the same time, the developer integrates pre-built backend services with a serverless architecture. 

There is one more thing that can take the infrastructure management burden off developers – containers. While also cloud-based, and allowing breaking and deploying applications into small units, containers are quite different from serverless computing.  

Serverless vs. containers

Unlike traditional servers and virtual machines, serverless computing and containers allow developers to build more flexible and scalable apps. Despite these similarities, serverless and containers have quite a few differences. 

• Physical machines: while serverless architecture is actually running on servers, but the ones provisioned by the vendors, a specific app or function doesn’t have a particular machine assigned. On the other hand, each container exists on one machine, uses its operating capacity, and can be moved to another one if needed.  
• Scalability: with containers, developers have to decide on their number beforehand. In serverless architecture, the backend can be scaled based on demand. 
• Cost-efficiency: containers are constantly running, and you have to pay for space even if no one is using an app. For serverless, the code runs only when called, and developers pay for the used capacity only. 
• Maintenance: while hosted in the cloud, providers don’t maintain and update containers. The thing with serverless is that, from the developer’s perspective, there’s no backend one needs to manage. 
• Deployment: to set up containers, you have to configure system settings, libraries, etc., which takes longer than dealing with a serverless architecture. As soon as the code is uploaded, your serverless app is live. 
• Testing: with serverless apps, it’s hard to replicate a backend environment in the local environment, so testing is challenging. Containers, however, can be tested easily. 

Both serverless computing and containers significantly reduce infrastructure expenses, but serverless more so. While serverless architecture provides more speed to releases and iterations, containers offer more control over the environment. It is also possible to use hybrid architectures. 

Functions as a Service (FaaS)

One more concept we should distinguish from serverless computing is FaaS. We can separate two types of serverless – BaaS (backend-as-a-service) and FaaS (functions-as-a-service), which are overlapping. 

BaaS includes apps that use third-party servers to manage server-side logic (the backend is the service). With FaaS, you upload frontend code to a service like AWS Lambda or Google Cloud Functions, and the provider takes care of backend things like provisioning, managing processes, etc. The server-side logic remains in developers’ hands, but it runs in stateless compute containers. FaaS here is your code as a third-party platform that you pay for only when you use it. 

FaaS can be used without serverless architecture. You can replace part of your app with the FaaS functionality, but it can increase computing costs when the need to scale arises. Instead, serverless computing offers a broader range of functionality than pay-per-use FaaS options since it encompasses a variety of technologies and is considered more cost-efficient.  

Why these 200 tech companies & startups outsource to Ukraine

Download the whitepaper

Types of serverless systems

While serverless computing started as FaaS, it includes all sorts of cloud services now. There are eight common types of serverless systems, distinguished due to their primary purpose. 

Compute

In a serverless compute service like AWS Lambda, developers can run code on-demand or on-schedule. The FaaS platform will provide containerized runtime only. In addition to supporting the most popular runtimes such as Python, Node.js, .NET, and so on, some platforms support custom runtimes as well. 

AWS Lambda allows implementing external API calling, writing data to a database, authenticating a user login, and almost anything else a traditional infrastructure offers.   

Queue buffer

Queuing services hold data when it is moved from one part of an app to another. It decouples services with an asynchronous communication process and controls the volume of data. AWS SQS is a service for queuing. 

Stream processing

This system receives the flow of data packages and analyzes and processes them in real-time. It can be used as a buffer, but stream processing is more useful for analytics: detecting patterns, applying conditions, and reacting according to circumstances. AWS Kinesis can process video and data streams, data firehose, and data analytics. 

Event bus

It allows receiving messages from different sources and delivery to various destinations. The event bus resembles a queue buffer, but it can process multiple topics while a queue works with particular messages only. You can set custom rules for delivering messages to subscribers. AWS EventBridge event bus has numerous third-party integrations, from customer support to security suits. 

Database

The serverless database space range is vast: 

• SQL (Amazon Aurora Serverless) for combinations of transactional and analytical access patterns, with data that presents many-to-many relationships
• Graph (Amazon Cloud Directory) for complex data relationships
• Analytics (Amazon Athena) to provide analytical insights when applied in combination with another database
• NoSQL (Amazon DynamoDB) for large datasets and write-intensive applications.

Blob storage

Blob storage, such as AWS S3, is used to store text files, videos, or images. For big data analysis, it is integrated with Lambda and Amazon Athena.

API endpoints

The most common models for API implementation are REST and Graph. REST allows two systems to communicate with the help of HTTP methods. It requires knowing the endpoints, parameters, and filters in advance. For REST architecture, there is an AWS API Gateway. Graph API allows combining filters, selecting which data points to return, aggregating information before retrieval, etc. For Graph, there is the AWS AppSync service. 

Authentication management

A serverless user management system allows apps to authenticate, authorize, and manage users applying high-level security standards. AWS Cognito provides the level of security that can be replicated by an extended app development team only. 

Here’s an example of how different types of serverless systems can be combined in one ecommerce app:

Benefits of serverless architecture

We’ve already mentioned that serverless is much more convenient and offers more functionality than traditional server-based infrastructures. Developers can make releases faster, scale better, and reduce infrastructure expenses. Let’s explore these points in more detail. 

Reduced time to market

Developers can focus on business logic since infrastructure provisioning, management, and scaling are not their tasks anymore. Also, the function code is faster to write as it is designed to do one thing at a time. Updates are quick and easy as well: the new code is uploaded, and changes are initiated through calling API, without deploying the entire application. 

Quick start

Serverless architecture includes BaaS building blocks for common functionalities – the types of serverless systems mentioned in the previous paragraph. So, you have ready-made solutions for databases, file storage, API, etc., which help you integrate your app with backend services and instantly reach system stability.   

Automatic scalability

Serverless architectures can scale both up and down according to the demand for the specific functions. The providers ensure horizontal autoscaling, so any unexpected traffic spikes are accounted for, and won’t put your system down.  

Pay-as-you-go model

We’ve already mentioned this benefit: developers pay only for the number of resources they use. There’s also an offering from AWS Lambda for a free usage tier that includes 1M requests per month and 400,000 GB-seconds of compute time.

Reduced TCO (total cost of ownership)

This pricing model boils down to reduced operational costs, as you pay for the executed code only (which is milliseconds), and it means around 30% monthly savings on memory usage. 

With all these advantages, there are still some limitations to a serverless architecture. 

Serverless challenges and solutions

Despite the fast adoption of serverless, people still often choose server-centric infrastructures. The main concerns around serverless app development are function timeouts, minimal time-lag, costly cloud migration, privacy, and vendor lock-in. They fall under the following groups. 

Performance

Running on Lambda, serverless apps may have several performance issues:

• Running a function inside VPC can result in a significant cold time start, depending on the language. You can minimize the impact on users by analyzing cold start times frequency, duration, and count with a service like Dashbird.
• The distance of the function from the user influences the response time. Via Lambda@Edge, you can deploy a function to the Amazon CloudFront and automatically host the function in multiple locations.  
• Request path can affect latency: some requests require actions from several microservices and multiple databases, e.g., several Lambda functions, API Gateway, databases, external services. It makes sense to think about the architecture patterns beforehand. 
• Runtime configurations: Lambda has a predefined set of configurations and memory sizes to choose from. And while lower memory and CPU settings are cheaper, it can influence the execution of some tasks, so define how much CPU you need to allocate to a specific function. 

Monitoring and DevOps

Since serverless infrastructures span across multiple services and functions, issue detection and debugging becomes a real challenge. There are solutions for gathering logs and metrics, but there’s still a lot of data to analyze. Specific third-party tools like Dashbird, Thundra, etc. can help you out here: you can automate visualization, set alerts, and get some insights into the root of the problem and release pipelines. 

Security

Serverless architectures are allocated on public cloud environments and have significantly more surface area than traditional apps. Therefore, watch out for functions with overly generous IAM policies, outdated libraries, and unauthorized requests. 

Other issues

Migrating to the cloud and migrating from one cloud to another is quite a challenge since serverless is specific to every provider. While there are tools like the Serverless Framework, managing multi-cloud workloads requires significant effort. On the other hand, cloud providers offer rich and varied services, so the need to switch a provider may never arise. 

One more issue is that your expenses will grow with the number of levels you need to manage. Containers may turn out less expensive when you need to host multiple layers of complex logic, or something that runs 24/7, with consistent workloads. In this case, having everything in one container will make sense. 

Speaking of cost, let’s have a closer look at how serverless cloud services are billed. 

The economics of serverless computing

Pay-per-use is a standard model for all cloud providers. But there’s more to that. Let’s take AWS Lambda and Azure Functions, for example: the cost per function invocation is 20 cents for one million invocations. Sounds cheap, right? However, this is not the main element of the total cost. 

Since the invocation of functions requires significant computing resources, FaaS providers also charge for the combination of allocated memory and function execution time. For AWS Lambda, it’s $0.00001667 for every GB-second used. The amount of memory is configurable, therefore the price of function execution depends on configuration. 

Even considering the additional expenses, the use of Lambda is still very cheap: one million invocations with the average time of 500 ms and 128 MB allocated memory will cost you around $1.25. If run continuously, this function will cost you nearly $6 per month. Furthermore, in an attempt to attract more users, AWS Lambda and Azure Functions offer generous free tiers to a function using 128 MB of memory running 24/7 for a month. 

Still, serverless architecture is not always a money saver. Certain workloads require considerable computing resources, and functions should be validated against the FaaS environment limitations. 

Also, we recommend comparing the price of serverless functions from different providers here. Historically, Amazon was the first cloud provider to offer a FaaS platform, AWS Lambda. Other providers you can consider are Google, with Cloud Functions, and Microsoft, with Azure Functions, as well as open-source alternatives such as Apache OpenWhisk, Spring Cloud Functions, and Fn Project.