Table of Contents
-
1. What is Serverless?
-
2. How does it differ from traditional architecture?
-
3. Advantages and disadvantages of Serverless?
-
4. What are the application scenarios for Serverless?
Back to top
1. What is Serverless?
Serverless literally means “no server” in Chinese, but its true meaning is that developers no longer need to worry excessively about server issues. This does not mean the complete removal of servers; rather, it relies on third-party resources for backend servers, such as using Amazon Web Services (AWS) Lambda for computing services to execute code. The Serverless architecture is divided into two technologies: Backend as a Service (BaaS) and Functions as a Service (FaaS). Serverless is implemented by developers, where the server-side logic runs in stateless computing containers, triggered by events and fully managed by third parties.
What is BaaS?
BaaS translates to “Backend as a Service” in English. Its application architecture consists of numerous third-party cloud servers and APIs, managing the logic and state related to servers by the service provider. For example, in typical single-page applications (SPA) and rich client mobile apps, frontend and backend interactions primarily rely on REST API calls. You only need to call the service provider’s API to complete the corresponding functionality, such as common tasks like authentication, cloud data/file storage, message pushing, and application data analysis.
What is FaaS?
FaaS can be referred to as “Functions as a Service.” Developers can directly deploy service business logic code to run in stateless computing containers provided by third parties. Developers only need to write business code without worrying about servers, and the execution of the code is event-driven. AWS Lambda is currently one of the best implementations of FaaS.
The Serverless application architecture combines BaaS and FaaS, allowing users to focus solely on the business logic code of the application. Functions are written at a granular level and run on the FaaS platform, integrated with BaaS third-party services, ultimately building a complete system without any concern for servers throughout the process.
Back to top
2. How does it differ from traditional architecture?
The traditional architecture model uses a Client/Server (C/S) architecture. In a typical web application, the server receives HTTP requests from the frontend, processes them, and before saving or querying the database, the data may pass through multiple application layers, ultimately returning a response to the backend. This response can be in JSON format or other formats. It then returns the response to the client, as shown in the following image:
In the traditional development model, the development process involves: designers designing pages -> server-side development and frontend development separately -> after server development is complete -> service deployment -> after deployment, frontend and backend integration -> testing -> after testing, going live -> after going live, maintenance. In the traditional development model, developing an application from start to launch requires different roles to perform different tasks, leading to high communication costs. Additionally, during maintenance, considerations such as server load balancing, transactions, clusters, caching, messaging, and data redundancy must be addressed, which presents challenges in the current traditional model. The following diagram illustrates this process:
In a Serverless architecture, the application business logic is formed into multiple independent functional components based on the FaaS architecture. These components provide services externally in the form of APIs. In FaaS, the backend application is broken down into individual functions, and we only need to write the functions and deploy them to the Serverless service. Subsequently, we do not need to worry about any server operations. Thus, the entire process can be completed by a single frontend engineer, significantly reducing communication costs. The following diagram represents the project process:
Frontend engineers can write backend services using Serverless, typically by writing code in AWS Lambda, which supports various languages. The Lambda computing service can execute code in a massively parallel manner in response to events. By using Lambda and various powerful APIs and web services, developers can quickly build loosely coupled, scalable, and efficient architectural systems.
Note: What is Lambda? It is a computing service that executes code written in JavaScript, Node.js, Python, C#, or Java on AWS infrastructure. The source code is packaged and deployed to isolated containers, which have separately allocated memory, disk space, and processors. The combination of code, configuration, and dependencies is referred to as a Lambda function.
Back to top
3. Advantages and disadvantages of Serverless?
Advantages include:
1. Reduces startup costs for startups
When starting a company, developing a web application requires version management servers, continuous integration servers, testing servers, application version management repositories, and other foundational services. When running online, to handle a large number of requests, a good database server is also needed. When our application is aimed at ordinary users, we need:
1.1 Email services for sending reminders, registrations, etc. 1.2 SMS services for registration, login, and other user authorization operations.
For large companies, these foundational infrastructures are readily available. However, for startups, these require some initial costs. But if we use Serverless, we can reduce these costs.
2. Reduces operational costs
For startups, they lack infrastructure, financial resources, and possibly the capability to build infrastructure. Adopting cloud services is the best choice, saving them a significant amount of money. They can focus their energy on products that provide user value without needing to build their own servers, allowing more time to develop business functionalities. The key difference between function computing in Serverless and cloud servers is that cloud servers need to run continuously, incurring monthly or yearly rental fees, while Serverless is billed on demand; functions only run when requests come in, otherwise, there are no costs.
3. Lowers development costs
Serverless provides a series of supporting services. For example, we only need to write the database table name in the configuration file, and the data will be stored in the corresponding database. It also provides a series of function computing templates, allowing us to complete tasks automatically and efficiently with minimal configuration.
4. Enables rapid deployment
For traditional projects, local development requires deployment environments, and we still need to deploy environments for development or testing. However, Serverless has advantages in deployment and can easily achieve online deployment. This is because Serverless has built-in automated deployment features, and all functionalities are provided by the vendor. After writing business code, we only need to run it, and in AWS Lambda, functions are generally ready for invocation within seconds after upload.
5. Higher system security.
Keeping a server running continuously is not easy, and it requires consideration of various types of attacks from hackers. However, with Serverless, we do not need to worry about these issues, as third-party vendors will handle them.
6. Adapts well to microservices architecture and has strong scalability
Serverless is backed by FaaS services like AWS Lambda.
For traditional applications, the way to handle more requests is to deploy more instances. However, this often becomes too late. For FaaS, we do not need to do this; FaaS automatically scales. It can start as many instance copies as needed without lengthy deployment and configuration delays.
Taking Amazon’s AWS Lambda as an example, Lambda allows us not to think about any servers, meaning we do not handle deployment on servers, server capacity, scaling, and fault tolerance, or issues like OS selection, language updates, logs, etc. Your application only needs to interact with multiple third-party APIs or services, and you can also create a serverless API yourself.
Disadvantages include:
1. Not suitable for long-running applications
Serverless only runs when requests come in; when the application is not running, it enters a “sleep mode.” The next time a request arrives, the application will require a startup time, known as a cold start. If our application needs to run continuously and handle a large number of requests, it may not be suitable to use Serverless architecture. In such cases, using cloud servers like EC2 would be a better choice.
EC2 is like buying a car, while Lambda is like renting a car. If we rent a car for a long time, it will definitely be more expensive than buying one, but renting can reduce some maintenance costs.
2. Complete dependency on third-party services
If all services related to the application are placed on third-party services, it may involve security issues. Therefore, we can place non-critical APIs or services on Serverless. Of course, if we have our own service infrastructure, we should use our own facilities. When we use Serverless architecture, we are already bound to the vendor. If we want to migrate services to another cloud service provider, it is not that easy.
3. Lack of debugging and development tools, making problem diagnosis difficult.
4. Not suitable for high-concurrency applications.
Starting a process for each request incurs too much overhead, and sudden traffic spikes can easily lead to timeouts. For example, during the peak of Alibaba’s Double Eleven shopping festival, processing over 80,000 transactions per second means that our system creates and destroys over 80,000 processes every second. This results in significant system overhead, similar to the first point.
Back to top
4. What are the application scenarios for Serverless?
Serverless is suitable for building relatively simple applications, such as uploading an image, encoding or decoding a piece of audio/video, or returning a small amount of data in response to a request.
Serverless architecture has the following characteristics:
1. Achieves fine-grained allocation of computing resources. 2. Does not require pre-allocation of resources. 3. Provides true high scalability and elasticity. 4. Pay-as-you-go usage and billing.
Therefore, the following applications may use Serverless architecture:
1. Management of static websites. 2. Replacing WordPress (Serverless Blog Project). 3. Personal media servers (less!). 4. Internet of Things (IoT) or home automation frameworks or projects (using AWS IoT).
Specific applications include:
Sending notifications:
Services such as PUSH notifications, email notification interfaces, and SMS require infrastructure to set up. Their real-time requirements are relatively low. Even if there is a delay of a few seconds, users can still accept it. In the case of SMS sending, it is generally assumed that users can receive the SMS within 60 seconds. Therefore, a 1-second delay is not a big issue for users. For app message pushing, the requirements are even lower, and users are less concerned about receiving such pushes.
WebHook
When we do not have a server but want a Webhook to trigger a series of operations, we can consider using Serverless. We do not need to continuously pay for a server. With Serverless, we can easily accomplish this and save a lot of costs.
Data statistical analysis
Data statistics require very little computing power, but generating charts can be done periodically.
When receiving data, we do not need to worry about any delays. A delay of 50-200 ms will not affect our system.
Triggers and scheduled tasks
For programs that require web scraping and generation, Serverless may be a good platform.
Although such tasks can also be performed by cloud servers, we only need to start the server periodically. By using self-starting scripts in the server, we can accomplish the necessary tasks. However, after completing a series of tasks, we need to store the data on a remote server. To allow other applications in the system to access this data directly, we may consider using a cloud database. At this point, Serverless applications appear more attractive.
Chatbots
Chatbots are also a very good application scenario.
However, due to domestic conditions (information regulation), this is not an easy task. Therefore, from channels (such as WeChat, etc.), efforts are made to minimize the possibility of this.
However, we can still create a WeChat public account service. When users input a keyword, we can respond accordingly, which is essentially similar to a chatbot.