Serverless vs. Traditional Architecture: What Are the Differences?

Serverless architectures have rapidly emerged as a new technology concept over recent years. Using this architecture, you can create a variety of applications for various industries. If you have a need for computation-light, highly-flexible, stateless applications, then you can familiarize yourself with the basic concepts of serverless architectures and draw inspiration from this document.

In a previous article, we looked at four common applications of serverless with Alibaba Cloud Function Compute. In this article, we will compare and contrast conventional solutions for these four scenarios to a serverless approach with Function Compute.

Serverless Evolution

On the Internet, people often draw parallels with human evolution to explain the evolution of serverless architectures. Each stage in human evolution was accompanied by an increase in productivity. Likewise, the history of IT computing also tells a story of gradual increases in productivity, as shown in the following diagram:

Image for post
Image for post

This development process is marked by several milestones:

Therefore, this is also an evolution of IT architectures driven by a series of technological revolutions. In this process, resources have been broken down, operational efficiency has increased, and software maintenance has been simplified. The evolution of IT architecture has the following characteristics:

Serverless architectures has the following features:

Based on these general features of serverless architectures, let’s now look at several typical cases that you can use as references.

What Are the Typical Applications of Serverless Architecture?

Event Request

When online sellers maintain images of their products, they must dynamically cut the images into different sizes based on the product display location or add different image watermarks. When online sellers maintain images of their products, they must dynamically cut the images into different sizes based on the product display location or add different image watermarks. When sellers upload images to OSS, they can use Function Compute to create custom function computing triggers. Based on computing rules, sellers can generate images of different sizes to meet their online product display needs. This process does not require the construction of additional servers or manual intervention to ensure the aesthetics of the webpage.

In the IoT industry, IoT devices transmit small quantities of data, often at regular intervals. Therefore, there are scenarios involving low frequency requests. For example: An IoT application may only run for 50 ms once a minute. This means that the CPU utilization is 0.1% per hour. In other words, 1,000 identical applications can share the same computing resources. Moreover, in a serverless architecture, you can purchase 100 ms of CPU resources per minute to meet your computing needs. This not only effectively solves efficiency issues, but also reduces usage costs.

During user registration, an email is sent to verify the user’s email address. Likewise, you can create custom events to trigger subsequent registration processes without configuring additional applications or using servers to process subsequent requests.

Events can be triggered at fixed times. For example, you can have your service process transaction data submitted during busy periods at night or when the service is idle. Or, you can run batch data to generate data reports. The serverless method removes the need for additional processing resources, which are less often used.

Traffic Spikes

Mobile Internet applications are often grappling with sudden traffic spikes. For example: A mobile application may usually have a traffic rate of 20 QPS, but every five minutes see an increase to 200 QPS (10 times the normal rate) sustained for 10 seconds. With a traditional architecture, enterprises must scale their hardware capabilities to 200 QPS to deal with these business peaks, even though these peaks account for only 4% of the overall operating time.

With a serverless architecture, you can take advantage of elastic scalability to quickly increase your computing capabilities to meet the current demand. Then, after a business peak, the resources are automatically released to reduce costs.

During a live video activity, as you cannot predict how many viewers may access the livestream, you can scale your transcoding and traffic capabilities using the Function method. This means you no longer have to consider concurrency or traffic capacity scaling issues.

Big Data Processing

Due to security audit issues, you may need to locate access logs with specific keywords in your OSS data accumulated over the past year for multiple regions (one file is created each hour) and simultaneously perform aggregation operations (to compute total values). If you use Alibaba Cloud Function Compute, you can run function computing on your access logs every two hours during peak periods or every four hours during non-peak periods and then store the processing results in RDS. You can use one function to dispatch data to another function so as to run thousands of identical instances.

This way, you can run nearly a thousand compute functions (24 x 365 / 10) in less than a minute. When performing the same computing operation using ECS and computing scripts, it is quite a task just to configure a network solely for these instances (different regions cannot download OSS files over the intranet). In addition, instances may outnumber IP addresses available in the subnet (for example, if your VPC uses a 24-bit subnet mask).

Below we will use Alibaba Cloud’s Function Compute product to discuss the architectures in various use cases and illustrate how you can solve difficulties specific to these cases. Alibaba Cloud Function Compute is a fully-hosted product based on a serverless architecture. You only need to upload your core code to Function Compute to run the code using event sources or SDKs and APIs. Function Compute prepares the runtime environment and dynamically scales the environment based on your request peaks. You are billed for Function Compute based on the time you use it. After requests are processed, billing stops. This reduces costs for applications with significant fluctuations in request volumes.

The following figure shows a developer trial operation procedure for Function Compute:

Image for post
Image for post

Below we will explain several serverless use cases in detail to increase your understanding of the serverless architecture.

Scenario 1: Event-Triggered Computing

Image for post
Image for post


Users upload various file types (including images, videos, and text files) to OSS from a mobile phone, web application, or PC. Then, the OSS PutObject event triggers Function Compute to process the uploaded files.

Typical Scenarios

After a user uploads video files to OSS, Function Compute is triggered to obtain and transmit the object metadata to the core algorithm library. Based on the algorithm, the core algorithm library pushes the relevant video files to the CDN origin site, hot-loading the specified video. In another scenario, after video files are uploaded to OSS, Function Compute is triggered to synchronize multiple transcoding rates and store the processed video files in OSS. This provides a lightweight data processing solution.

In multimedia processing scenarios, massive volumes of files are often uploaded to OSS and then must be processed (for example, watermarking, transcoding, fetching file attribute data). In such a scenario, you must solve the following technical difficulties:

Function Compute provides a solution that can easily address these technical difficulties:

Conventional Approach to Event Triggering:

Function Compute Approach:

Scenario 2: Elastic Resizing (Live Video with Multiple Connected Microphones Scenarios)

Image for post
Image for post


The broadcasting room client collects audio and video streams from host and audience members with connected microphones and sends them to Function Compute for multiplexing. Function Compute sends the collected data to the multiplexing service for synthesis and pushes the synthesized video stream to CDN. Viewers pull the livestream in real time to view the multiplexed and synthesized video live.

In some live video scenarios, multiple audience members interact using connected microphones, so the host is simultaneously connected to multiple microphones. The host can connect multiple audience members or friends to the screen and synthesize the picture into a single scenario, which is then provided to the livestream viewers. In this scenario, you must be aware of the following technical difficulties:

Serverless architecture provides the perfect solution for these difficulties.

As a real-time audio and video forwarding cluster for the host and connected microphones, Function Compute automatically resizes multiple execution environments used to process real-time data streams based on the concurrent volume. After a business peak, the function appropriately reduces the resource volume. Code management capabilities are deployed on the cloud, allowing you to modify and maintain code iterations at any time. You no longer have to manage multiple software runtime environments.

Conventional approach to live video streaming:

Function Compute approach:

Scenario 3: IoT Data Processing

Image for post
Image for post

The architecture is divided into two parts:

Smart device status processing also generates several key technical difficulties. You must design an efficient non-polling technical framework to process the status data from a large number of devices to the IoT platform. Then, you need a way to efficiently and transparently transmit the processed data to other products, such as writing to a database or pushing data to mobile terminals.

Conventional approach to IoT device status:

Function Compute approach:

By comparing these two methods, we can see that the Function Compute solution is more universal and greatly reduces the maintenance workload.

Scenario 4: Shared Dispatch System Details

Customers can use a dispatch platform to choose from the services provided by various sellers, such as ordering food or buying products. The dispatch platform then notifies the nearest delivery staff to pick up the relevant product from the nearest seller and deliver the product to the customer. A simple process is shown in the following figure:

Image for post
Image for post

Process details:

In this dispatch scenario, you must solve several technical difficulties:

After you choose an Alibaba Cloud product solution, Function Compute works with other products to effectively solve these problems. The solution’s architecture is shown in the following figure:

Image for post
Image for post

Process details:


Here, the route logs are stored in Log Service to facilitate subsequent reporting and analysis. In the delivery process, delivery staff’s profile pictures and street views are stored in OSS. Function Compute can be used to pull delivery staff locations from third-party map information, such as AutoNavi Maps.

In this solution, Function Compute can provide dynamic resizing capabilities, while API Gateway performs authentication and ensures secure access. Function Compute can communicate with multiple products to seamlessly use other resources and content. All processed data is stored in Table Store databases, and all logs are directly loaded to Log Service for subsequent data reporting.

Conventional approach to shared dispatch systems:

Function Compute approach:


Through the preceding scenarios, we can reach the following conclusion: In event-triggered scenarios, scenarios with business traffic fluctuations, and iterative scenarios that require rapid connection to multiple other products, Function Compute provides an optimal solution to address cost, efficiency, and connectivity considerations.

Image for post
Image for post

Although Function Compute applies in many scenarios, it is not a one-size-fit-all solution. For example, if your business does not experience significant request fluctuations during the day, Function Computing does not save much.

As emerging technology, serverless frameworks have yet to support more development tools with the general edition still in the pipeline. In addition, Function Compute’s execution environment does not record states, so serverless frameworks are not well suited to tightly coupled applications. Due to the limited amount of resources available for allocation, it is no easy job to split up and launch certain large applications.


Written by

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store