By Wu Peng, Alibaba Technical Expert
Over the past two years, the discussion about the serverless concept has become increasingly popular in the developer community, with the number of articles shared on this topic growing exponentially. A case in point is the prominent cloud-native computing event, KubeCon + CloudNativeCon. It hosted 20 themes related to the serverless architecture in 2018, and the number surged to 35 in 2019.
Cloud-based infrastructure solutions for serverless computing become more diverse than ever, for example, from the earliest AWS Lambda to Azure Functions, Google Functions, and Google CloudRun, as well as Alibaba Cloud's Serverless Kubernetes, Serverless App Engine, and Function Compute.
New concepts and products do not appear out of thin air but are conceived to address current problems. As practitioners gain a clearer and deeper understanding of a problem domain, the coping measures will iterate step by step, and solutions more pertinent to the nature of the problem will present themselves with time. If we do not work towards a solution from the perspective of the problem domain, we may end up gridlocked between two extremes: "a solution for all" and "a solution ahead of its time, and therefore beyond comprehension".
Figure 1
This figure shows a common project iteration model designed to meet customer needs. In this model, the project team fulfills customer needs through passive iterations while gradually and deeply understanding customer needs. In addition, the project team proactively iterates its work and works with customers to adopt better solutions or solve problems from the root. Each demand feedback will deepen the understanding of customer needs and facilitate the provision of services that better meet customer needs. Each bug feedback will deepen the understanding of the solutions and facilitate the provision of more stable services.
Once the model is activated, the daily focus shifts to how to accelerate iterations.
To achieve this, we need to identify the constraints and work on targeted solutions. The following figure shows a development model from the development perspective.
Figure 2
Although different development languages and architectures will be used in practical applications, there are common problems at each stage, as shown in figure 3.
Figure 3
In addition to solving the preceding common problems, we need to provide standardized solutions, reduce the learning and application costs for developers, and shorten the time to market.
After we analyze the time spent on different phases through the project lifecycle, we find that:
To accelerate iteration, we need to address the areas that require more time and effort, as shown in Figure 4.
Figure 4
From left to right, we can reduce the deployment and O&M costs by delegating O&M tasks at different levels. Then, we can proceed to work on the costs arising from the "general logic" level. The two strategies, when adopted together, maintain a sharper focus on business through iterations. It is a process of evolution from cloud hosting to cloud-native, which fully enjoys the technology dividend brought by cloud-native.
Due to the high coupling between the software design and deployment architectures and the environment, the technologies adopted in the iterative process of inventory applications need to be adjusted accordingly to accommodate new concepts, services, and products. Thus, the development and deployment methods need to be reconstructed. However, the development and deployment of new applications come with the cost of learning and practicing new philosophies.
Therefore, this process cannot be completed overnight. We need to prioritize the business pain points and select matching services and products. In addition, we need to carry out technical pre-research in advance, based on the future plan, and choose suitable services and products at different stages.
Wikipedia provides us with a relatively comprehensive definition of serverless computing. "Serverless computing is a cloud computing execution model in which the cloud provider runs the server and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application rather than based on pre-purchased units of capacity".
The computing model brings several benefits to users. Serverless computing simplifies the process of deploying code into production. Scaling, capacity planning, and maintenance operations may be hidden from the developer or operator. Serverless code is used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications are written to be purely serverless and use no provisioned servers at all.
The nature of a concept is an abstraction of a problem domain and a summary of its characteristics. Understanding a concept through its characteristics focuses on its value rather than the text description.
From the perspective of users, serverless computing has the following characteristics:
In companies of a certain scale where the development and O&M roles are strictly differentiated, this form of computing is nothing new, but rather an ongoing practice. The current technology trend is to take advantage of the scale and technological benefits of cloud computing, reduce the technology costs of businesses through cloud migration, and subsequently utilize the benefits of embracing cloud technologies to drive business growth. Therefore, the industry's discussion about serverless focuses on the serverless capabilities of cloud services and products.
Martin Fowler in his article expounds the serverless development model from the perspective of architecture. The essence of the article boils down to three components:
Serverless development adopts an event-driven model and conducts architectural design by producing and responding to a variety of events, such as HTTP or HTTPS requests, time, and messages. Such a model is centered on the process of producing and handling events, which drive the entire service process. So the focus is the whole process. The deeper we understand the businesses, the more the event types and businesses will match each other, and the more technologies and businesses are mutually reinforcing.
The event-driven model makes resident services change from mandatory to optional, thereby better responding to changes in business request volumes, such as auto scaling. In addition, the services are not resident. This helps reduce the required resource and maintenance costs and accelerate project iteration.
The following two diagrams from this article give us an intuitive understanding of the model.
Figure 5
Figure 5 shows a common development model. The Click Processor service is a resident service that responds to all click requests from users. In a production environment, multiple instances are deployed usually. Considering that "resident" is a key feature, one of the daily O&M focuses is to ensure resident services' stability.
Figure 6
Figure 6 shows an event-driven development model. It focuses on event generations and responses and does not require response services to be resident.
A major difference between the concepts of serverless and Platform as a Service (PaaS) or Container as a Service (CaaS) is whether auto scaling is the core feature of the concepts when they first came into existence.
With the event-driven development model, auto scaling requires greater transparency for developers in serverless scenarios, so that developers can better cope with the uncertainties of business requests after the developed system goes into production.
In terms of development, either images or programming language packages (such as war/jar in Java) are delivered, and the platform handles runtime tasks. We can go one step further and adopt the FaaS philosophy to provide business logic functions based on the platform or standardized FaaS solutions. The platform is responsible for runtime issues, such as request entry, request invocation, and auto scaling.
Regardless of the delivery method, BaaS can be used on the cloud. It enables part of the logic to be implemented through the cloud platform or third-party OpenAPIs, such as rights management and middleware management. During the development process, developers focus more on businesses.
For the serverless service model, the primary consideration is how cloud vendors support serverless computing. Different services and products mainly differ in their understanding and fulfillment of serverless features.
In terms of zero O&M, the most fundamental aspects are eliminating server O&M costs and allowing developers to apply for resources on demand. Regarding routine O&M operations, such as capacity management, auto scaling, traffic management, logging, monitoring, and alerting, different services and products adopt suitable methods based on their own positioning and target customers.
In terms of billing, for one thing, cloud vendors determine the charging dimensions based on their own positioning, such as pay by resource usage or pay by the number of requests; for another, they determine the granularity of charging based on current technical capabilities.
From the preceding analysis, note that different serverless service models of cloud vendors are not static. The models are continuously iterated with product positioning, target customer characteristics, and technical capabilities.
Serverless service models are designed to satisfy actual needs. As figure 4 showed, cloud vendors' serverless service models are classified into the following types:
The following diagram compares the platforms and their functions.
Figure 7
At present, cloud vendors provide serverless products with different dimensions. The following provides a brief summary.
Figure 8
Among the solutions that provide container group services, AWS Fargate and Azure ACI have a lot of influence in overseas markets. A container group as a whole is similar to a pod in Kubernetes. Users directly create container groups by calling OpenAPIs, without having to purchase and configure servers before deploying services and delegate resource-related capacity management and maintenance. Users may use the resource instance platform as a large-capacity resource pool, apply fine-grained resource applications at the container group level, and manage application-level capacity in coordination with auto scaling.
Generally, in a production environment, users do not directly use such resource management services. Instead, they use application orchestration services to make such services transparent and focus on application orchestration.
Kubernetes is a de facto standard for container scheduling. Solutions like AWS EKS and Alibaba Cloud's Serverless Kubernetes host Kubernetes master components and provide services at the Kubernetes node layer based on resource management services, such as Virtual Kubelet and AWS Fargate, or Virtual Kubelet and Alibaba Cloud ECI.
For users who want to directly use Kubernetes capabilities and maintain Kubernetes at a low cost without maintaining resource pools, this solution effectively meets their needs.
Solutions such as Google GAE, Google CloudRun, and Alibaba Cloud Serverless App Engine service O&M tasks such as release management (packaging, canary release, phased release, rollback, version control, etc), logging, monitoring, alerting, traffic management, and auto scaling. This allows users to focus on business needs and achieve low-cost O&M.
This platform is a good fit for users who want to transform and use existing applications at low costs and minimize O&M work. However, there is no standardized solution for O&M at the application management plane in the industry. Each project tends to have its own unique requirements. Therefore, to adopt such a serverless product, it is necessary for users to strengthen communication, continuously provide feedback for the platform, and in turn, bring the serverless platform into alignment to their own business through joint efforts.
In addition to application management capabilities, solutions such as AWS Lambda, Azure Functions, Google Functions, Alibaba Cloud Function Compute, and Tencent Cloud Functions make the common logic transparent during the development process, so that users fully concentrate on the implementation of business logic. This process can be compared to the process of writing unit test cases during software development. The input and output are universal, and the only difference lies in the processing logic. This type of serverless product is the most discussed form in the industry, representing the industry's abstraction of the ideal development process. It may further accelerate the iterative process and reduce the time to market. This type of serverless product can be more closely integrated with other products on the cloud platform and uses cloud platform services in the form of BaaS to implement common logic, such as storage and cache. It has certain implicit requirements for the richness of cloud platform products.
If a process is less dependent on external processes or focuses on computing, such as frontend and multimedia processing, the use of such serverless products has relatively low learning and usage costs, and is easy to get started. As services and components become more abstract, this serverless solution is applied in an increasing number of business scenarios, and O&M will be more transparent. Meanwhile, users directly enjoy the industry's best practices during their development processes. The stability, performance, throughput, and other aspects of services can be maximized based on the platform's capabilities.
To conclude, while selecting serverless products, users need to first determine the current business technology stages, pain points, and the demand for cloud solutions. Next, users must map the products offered by different vendors to their requirements and select the services and cloud products that suit their current phases.
The mapping process should determine whether the positioning of a cloud product meets the business needs in the long term from various perspectives, such as:
It is also necessary to determine whether cloud products can develop with businesses. Especially among the technology requirements of businesses, you need to determine which limitations are caused by the positioning of cloud products and which limitations are caused by the current technology implementation of cloud products.
If the positioning of cloud products creates limitations, it is necessary to select cloud products that can better meet the business requirements. If the limitations are imposed by current technology implementation, then technologies and cloud products have the opportunity to grow together. It is recommended that users provide feedback to cloud products in time so that cloud products can better meet business needs.
Additionally, we should pay attention to the richness of cloud vendors' service types at the business level. The richer the cloud vendors' own service types and the larger the scale, the greater the scale effect. This, in turn, brings more technical benefits and cost advantages to the businesses.
Fortunately, cloud products usually come with an abundance of documents and user groups. Users must directly exchange ideas with product managers and developers, promptly provide feedback and requirements, and seek joint development in the spirit of collaboration.
Serverless is essentially a problem domain. It abstracts problems from the development process that are not critical to the businesses but affect business iteration and provides solutions accordingly. This concept did not appear out of the blue but has been used in some way in our daily work. Going with the tide of cloud computing, cloud-based serverless services and products are more systematic and competitive. Relying on the scale effect and diversified product lines, they address business domains and continuously provide services that better meet business needs.
The serverless concept not only flourishes on the centralized cloud but also gradually develops at the edge. It allows services to operate more extensively, better meets the customer needs of businesses and achieves lower latency and greater stability.
This article begins with the daily processes of project management and development, helps readers understand the serverless concept from the perspective of daily practices, and helps them select serverless services and products that suit their current stages. In addition, as the author is in charge of underlying development for Alibaba Cloud's Serverless App Engine, he conveys the concept of collaborative construction between cloud products and users from the perspective of cloud product vendors, so as to deliver and create value through collaboration.
Conversation with the First Chinese TOC about How Dragonfly Became a CNCF Incubation Project
508 posts | 48 followers
FollowAlibaba Clouder - June 22, 2020
Alibaba Clouder - August 25, 2020
Rupal_Click2Cloud - August 8, 2022
Alibaba Clouder - January 20, 2021
Alibaba Cloud Native - February 5, 2021
Alibaba Cloud MaxCompute - October 18, 2021
508 posts | 48 followers
Follow
IDaaS
Make identity management a painless experience and eliminate Identity Silos
Learn More
Elastic Desktop Service
A convenient and secure cloud-based Desktop-as-a-Service (DaaS) solution
Learn More
Blockchain as a Service
BaaS provides an enterprise-level platform service based on leading blockchain technologies, which helps you build a trusted cloud infrastructure.
Learn More
Message Queue for Apache Kafka
A fully-managed Apache Kafka service to help you quickly build data pipelines for your big data analytics.
Learn MoreMore Posts by Alibaba Cloud Native Community
