Serverless is one of the popular directions in IT and continues to grow. Cloud providers are ready to provide all the necessary infrastructure and maintain it, and the user pays only for the execution time of a function—idle time is not billed.
Serverless architecture is a way of building applications in which the developer writes the application logic, while the cloud provider is responsible for launching that logic, monitoring, scaling, maintaining the execution environment, and managing load planning. This is not always an external provider; such infrastructure can also be implemented inside a company using its own computing resources.
The simplification of working with infrastructure traces back to the appearance of the first IaaS (Infrastructure as a Service), where the provider simply offered virtual infrastructure for rent, and then extended to widespread BaaS (Backend as a Service), where a developer’s microservice or a database is simply several containers running in the provider’s environment, and in the case of a database, with preconfigured replication.
Another product is FaaS (Function as a Service), where the execution unit is a single function. In part, this resembles a microservices approach. Your function should not rely on state between calls (it must be stateless), because each call is launched by the provider as a separate instance in a container. There are also some limitations imposed by the cloud platform: not all programming languages can be used to write function code (although the list is usually wide), and there are limits on execution time and memory usage. The exact limits differ by platform and may depend on your pricing plan. Many providers offer trial periods from three months to a year with limits on the number of requests.
The foundation of Serverless is FaaS and the provider’s ecosystem of products. Typically, there are Databases, Authorization Services, API Gateways, Message Brokers (such as Kafka), all provided as services (BaaS) that your function can integrate with.
Each provider may offer a unique set of services, but applications built on FaaS generally have similar architectures. As an example of integration between provider products, you can consider a TODO application (the example is taken from the AWS website).
The application logic is packaged in lambda functions, which interact with the DynamoDB database, provided by AWS as a separate service. In front of the functions is the API Gateway, which handles incoming requests and routes them appropriately. The architecture also includes the Amplify Console for managing the web interface of the application and the Amazon Cognito authentication service.
The main positive aspects of Serverless typically include:
Helps handle peak loads and rapid product growth. The provider will automatically scale the function, and when demand decreases, resource consumption will shrink.
You pay only for the execution time of the function. For example, on AWS, the price includes the cost of function invocations and the amount of memory (GB/s) allocated during execution. Even with 24/7 availability (with some nuances), you do not pay for periods of inactivity.
CI/CD, integration with other services, monitoring, log management, and maintaining the execution environment—the provider handles all of this, allowing for faster product deployment.
Compared to BaaS infrastructure or full server control (VPS), deploying an application into cloud functions has its downsides:
Cloud functions have memory and execution time limits, as well as restrictions on data sizes sent or received. Here are examples of such limits in AWS.
The provider will not keep a container with your function running at all times. If the function has been idle for some time, its next invocation will require time to start up. Startup time depends on the programming language, code size, and the provider’s internal processes, and can reach up to 10 seconds. Here’s a small article with examples on the topic, and a GitHub repo with code and research results.
Although FaaS-based systems and service ecosystems resemble microservice architecture and functional programming, they have their own best practices beyond monitoring, logging, request tracing, and mocking service responses.
If your application requires consistently fast responses, cold starts can be a major issue. The solution is to constantly “warm up” the function, for example, by periodically sending requests that create some load so the provider keeps the function active. The load itself does not matter; what matters is triggering the function. If necessary, the provider will scale by starting additional instances on the fly. Some providers offer built-in mechanisms for this (e.g., AWS), allowing you to keep a certain number of instances always running.
A pattern that allows you to bypass memory, data size, and execution time limits by splitting a large task into smaller chunks. Downloading and processing data in chunks, sending emails in small batches—cloud functions will execute tasks in parallel across different function instances. The trade-off is more complex application code and paying for more function invocations.
Cloud FaaS functions can be triggered not only via API Gateway or direct invocation. A trigger can be an event from any integrated service, such as a message from Kafka. Event-driven code organization works extremely well for FaaS.
Unlike a fixed-price service (e.g., renting a VPS for a year), Serverless costs are composed of several different services, each with its own billing model. Continuous monitoring of costs and resource utilization, along with load planning, is key to reducing infrastructure expenses. Some providers have special offerings, such as AWS Lambda Reserved Concurrency, which allows reserving Lambda instances and keeping them active on a cheaper pricing tier.
An open-source tool for simplifying the development, deployment, and management of serverless applications. It allows developers to focus on writing code without worrying about infrastructure and provider configuration. It supports AWS, Azure, Google Cloud, IBM Cloud, Oracle Cloud. It enables local function testing, integrates with CI/CD systems like Jenkins or Travis, has a large plugin ecosystem, and allows developers to create their own plugins.
A HashiCorp tool representing the "infrastructure as code" approach. It allows defining infrastructure using configuration files in HCL (HashiCorp Configuration Language), which describe the desired infrastructure state rather than the steps to achieve it. Like Serverless Framework, Terraform supports many major cloud providers and allows defining modules, i.e., reusable sets of configuration files for creating and managing infrastructure components.
The Serverless Application Model is an open framework created by AWS for developing, testing, and deploying serverless applications on AWS. SAM provides a simplified way to build serverless apps based on CloudFormation, AWS’s main tool for infrastructure as code.
Unlike the previous tools that focus on cloud providers, Kubeless is a serverless framework for Kubernetes. It allows creating and managing serverless functions directly inside your Kubernetes cluster. It works with standard Kubernetes objects like Deployments, Services, Ingress, etc. It provides scaling and fault tolerance for functions, has a CLI, and integrates with the Kubernetes ecosystem.
An open-source serverless framework. It allows creating functions in many programming languages, including Python, Node.js, Go, Ruby, Java, and others. It supports scaling and ensures fault tolerance. OpenFaaS integrates with Kubernetes and Docker Swarm.
Today, Serverless applications cover a wide range of tasks, from notification and mailing services to analytics platforms, data stream processing, webhooks, game servers, file and multimedia processing, IoT applications, adapters for external services, monitoring and logging systems, business process automation, content rendering servers, customer support chatbots, and testing or deployment servers. Many examples exist within the Serverless Framework ecosystem.
Major IT companies are migrating some processes to Serverless. For example:
Using Serverless is not only a way to reduce infrastructure costs, but also a tool for increasing development efficiency and flexibility. Serverless allows for rapid development and deployment of new functions and applications, as well as scaling them based on business needs.
Additionally, Serverless technologies support creating more reliable and fault-tolerant applications because cloud providers ensure high availability and automatic scaling. This helps companies avoid downtime or service failures that could harm their reputation and customer experience.
Serverless architecture represents a significant step in the evolution of cloud computing, allowing companies to focus on application development without worrying about managing infrastructure. This approach brings flexibility, scalability, and efficiency to development processes while reducing maintenance and operational costs.
In the future, we can expect development in several areas:
Serverless technologies are poised to continue reshaping the landscape of cloud computing, enabling companies to focus on building applications rather than managing infrastructure. With more integrations, new tools, and broader adoption, Serverless will increasingly become a key element in the modern developer’s toolkit.