Shulou(Shulou.com)05/31 Report--

How to analyze the advantages, significance and application of Serverless? aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Serverless is a hot technology and is considered to be the future direction of cloud computing. Especially in the front-end R & D field, using Node to develop cloud functions can enable front-end engineers to focus more on business logic and change the role of full-stack engineers.

Advantages of Serverless

Technical Leader and architects will pay attention to many indicators when making technology selection, and the biggest contribution of Serverless is R & D delivery speed (Time to Market) and cost (Cost).

In terms of R & D delivery speed, the measure is Time to Market, which is the total time taken from demand output to launch. The advantage of Serverless in this area is reflected in both technical and teamwork perspectives.

One is the technical perspective. I don't entirely agree with the view that Serverless is a very simple technology. Serverless architecture changes the relationship between users and the underlying architecture. Previously, developers need to pay attention to the core business logic, operation and maintenance, and the governance of the underlying architecture. In Serverless architecture, the underlying part is solved by Serverless architecture providers. From the point of view of the whole application system, the difficulty and complexity of the system architecture are not substantially simplified.

We won't go into the underlying implementation details of the Serverless architecture here. Just know one thing: the more things the underlying architecture of Serverless does, the less architecture and operation and maintenance work that needs to be paid attention to at the business level, and because less work is done, the delivery time will be faster.

* * the second is the perspective of teamwork. In Serverless mode, the working model of full-stack development will perform more smoothly. * * We know that front-and back-end separation is indeed a good architectural model: it refines the division of labor, reduces coupling, and improves reuse. But the following problems are the cost of communication between teams, various scheduling times caused by differences in KPI goals, interface confirmation and joint debugging testing. Many technical teams use full-stack development mode to solve these problems. Under Serverless, there is no need to spend too much energy on architecture and technology stack, Runtime and language do not force dependence, but are completely business-oriented, and every front-end engineer can be full-stack.

Another advantage is that Serverless will greatly reduce costs, both in terms of computing resources and manpower.

In terms of the cost of computing resources, it is mainly reflected in the flexible expansion of capacity and payment on demand. In the traditional computing resource budget, in order to resist the peak traffic, the system capacity has Buffer, which is a daily waste.

In Serverless mode, when the business code is online, you don't have to pay a penny. Only when the real request and traffic come, the platform will instantly pull up the corresponding number of function instances according to the number of requests to receive the request and execute the business code, and then need to pay for the resources consumed by the real code execution. * * No Pay for Idle, from an accounting point of view, Serverless changes computing resources from fixed costs to variable costs. * * this payment model has obvious advantages over businesses where traffic fluctuates greatly.

What also needs to be explained is the cost of manpower. Many technical Leader always complain about the lack of manpower, maybe this is not the case, but not enough proportion of people are devoted to the development and iteration of business functions, but to do the necessary supporting work such as architecture and bottom level. I admit that these tasks are indeed very challenging, necessary and important. In the Serverless model, because there is no need to pay attention to the underlying architecture, so reducing the workload and manpower share of this part, there will be more engineers can put on the core business, do more iterations, so as to accelerate the research and development of product functions. Isn't that a higher ROI?

Applicable scenarios for Serverless

Serverless is suitable for scenarios triggered by events. When an event occurs, pull and call the Serverless cloud function, such as file upload, message event in the message queue, timer event, or an event in the IoT device. It can also be used for some file processing, such as image processing, audio and video processing, log analysis and other scenarios.

Of course, these events also include HTTP request events, which is a large applicable scenario of Serverless-HTTP Service, which mainly implements back-end services based on HTTP applications, such as REST API, BFF and SSR services, as well as the implementation of business logic.

I mainly focus on the application of Serverless in HTTP scenarios. This is also the part that is most closely integrated with front-end engineers. Small to provide back-end support for Mini Game and operational activities, to the entire App or site REST API, BFF, or H5 page SSR, are all suitable scenarios for Serverless.

The significance of Serverless to front-end developers

Many advantages of Serverless are discussed in the industry, and there are also many articles about it. I want to focus on front-end developers to say that * * Serverless can help front-end engineers realize their dream of a true full stack. * * some people may question why you proposed a true full stack. Is there any difference between it and the previous one?

Let me first clarify the definition of true full stack: how to judge whether an engineer is a true full stack engineer?

When the company has a lot of product functional requirements, hired a programmer Zhang Quanzhan, if he can turn the requirements into a product from 0 to 1, that is called true full stack. If Zhang Quanzhan completes the front-end function development, back-end development and database development, implements all the required functions and deploys it to the corresponding service, then the question comes: who will restart the service when the service is dead? Who will do the environmental stability? Who will clean up the log when the disk is full? What about the scheduled task? When the product suddenly became popular and the traffic suddenly increased more than ten times overnight (in the ecstasy of the product manager), who was responsible for the expansion? Although these problems are not core business requirements, they must be considered by every online product, otherwise they can only be called functional sets, not products.

The emergence of Serverless architecture "shields" some of the non-core business logic mentioned just now, as well as things related to operation and maintenance. Zhang Quanzhan, a front-end engineer, only needs to pay attention to the core business logic such as foreground function, background function and data, and can make the product independently. For example, the current development of WeChat Mini Programs Cloud is Serverless-style, and developers do not have to pay attention to the underlying architecture at all.

Serverless is an opportunity for the front-end engineer community. Give a front-end engineer the opportunity to independently take charge of certain product development, the opportunity to complete some products from demand to launch from 0 to 1, and an opportunity to return to the role of Internet R & D engineer. I hope all front-end engineers will have the opportunity to become Serverless engineers and have the opportunity to independently develop the whole product.

Preparation for adoption of Serverless

Generally speaking, adopting Serverless does not require a lot of learning and preparation process for engineers.

Serverless itself subtracts from the existing architecture, subtracting the management and configuration of those servers. Of course, when landing, there is still some preparatory work to be done:

First of all, it is a clear goal. After learning about Serverless, developers should think about what problems to solve with Serverless for their own business and development architecture. What kind of promotion do you want to achieve? No technology is used for use, but to solve specific problems for specific scenarios. This is the first thing to understand.

After defining the goal, there is some design work on the architecture in Serverless mode. Like the traditional development model, the workload of system design is determined by the complexity of the business. For complex business logic, you need to know how many cloud functions there are before development. The input and output definition of each cloud function and which BaaS back-end services are used need to be designed and planned in advance.

In particular, these designs are not fundamentally different from non-Serverless, and Serverless cloud functions are not mysterious. To put it simply, what it provides is a language Runtime. Code that is executed in a non-Serverless architecture is still executed in the Serverless architecture. If the business is based on application frameworks such as Express or koa, you can use these frameworks directly under the Serverless cloud function.

Finally, there are some preparations for implementation. Take Tencent Cloud function as an example. As long as you have written code, spend less than half a day reading some basic documents and tutorials, or follow Demo, you can start writing code immediately. There is almost no threshold or difference. The emphasis on knocking on the blackboard is that don't forget the engineering and CI/CD considerations, especially the integration with existing R & D processes. This piece has some small workload, after all, it is an upgrade of the development mode, but the CLI and SDK based on cloud functions are easy to implement.

The relationship between Serverless and Cloud function

The Serverless architecture consists of two parts, FaaS (Functions as a Service) and BasS (Backend as a Sevice). FaaS refers to the cloud function, which is a new way to organize and provide computing power, so that users no longer need to care about the management and configuration of the server, but only focus on the writing of the core business logic business code. BaaS refers to some service-oriented back-end functions, including database / object storage, account authentication, message queuing, social media integration and AI capabilities. These services and interfaces use the corresponding SDK or API to connect and invoke at the FaaS layer.

The combination of FaaS+BaaS constitutes the Serverless serverless architecture, which eliminates all operation and maintenance operations, so that enterprises and developers can focus more on the development of core business, achieve rapid launch and iteration, and grasp the pace of business development.

Thus it can be seen that cloud function is the computing power part of Severless architecture and the basic computing resource to implement Severless architecture. In the business system under Severless architecture, the required BaaS back-end services may be different due to different business functions and requirements scenarios, but the business logic needs to be implemented through cloud functions.

Specific case

Just now I also mentioned that Serverless itself has many application scenarios, and the answer to this question is different in different Serverless scenarios.

If the business requirements are based on application frameworks like Express and koa, then there is basically no difference in design. Serverless cloud functions can well support these application frameworks, but they are deployed in different ways.

If the requirement scenario does not need any application framework, directly use the original code, when designing under the Serverless architecture, we need to consider the function as the granularity and regard the function as the minimum functional unit in the business.

There is another scenario where there is a big difference between using Serverless and not using it-- enterprise cloud.

Now many enterprise applications are doing applications on the cloud, the cloud is actually a very technical threshold. There may be only a few hundred lines of code to be uploaded to the cloud, but traditionally the cloud is not as simple as uploading and deploying hundreds of lines of code (it is estimated that many engineers will be crazy when they see the thick books of Kubernetes). This process requires professional, experienced engineers and takes a lot of work to migrate business systems to the cloud.

The experience under Serverless is very different. Because of the serverless architecture, you don't need to pay attention to the configuration and governance of virtual machines or containers. Basically, you only need to upload code to the cloud.

The Future Evolution of Serverless

From the perspective of past history, there are still some general laws in the evolution of technology.

First of all, I predict that the ecology of Serverless will tend to be prosperous. A technology is very advantageous, and the stronger the relevant community contribution and surrounding support, the more people will use it; the more people use it, the more popular the technology will be, similar to the efficient market theory in economics. Recently, Serverless has developed rapidly. By the time you read this article, our Serverless DB product has already been released, that is, developers do not even need to pay attention to the existence of the database. There will be more and more Serverless users, at the same time, there will be more contributors to the ecology, and the whole ecology will be more prosperous.

The second direction is the standardization of Serverless. When the ecology is booming, the need for standardization becomes very strong. Each cloud at home and abroad has its own Serverless solution, which hides the underlying basic settings from developers. However, the interfaces and implementations of different families are still different. Just imagine, how does it feel for developers to migrate to another cloud vendor when they internationalize the code implemented in Serverless on the domestic cloud, only to find that there is no smooth migration at all? How do the two technical teams within the company reuse functions and code under the architecture of Serverless? How can an application be built with a unified standard or framework? Serverless development needs some standards, or a framework to adapt to different implementations and interfaces between cloud vendors, which is likely to be the next development direction of Serverless.

This is the answer to the question on how to analyze the advantages, significance and application of Serverless. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.