From the perspective of operation and maintenance, is serverless really a silver bullet?

Author | Pu Songyang (Qin Yue)

the author says

Before starting this article, I would like to reach a few consensuses with the developers.

The first consensus is that there is no silver bullet in software engineering, and serverless is not a silver bullet. It is not a panacea to solve all problems.

The second consensus is that Serverless can solve problems in the operation and maintenance domain. It is a technology to solve problems in a specific domain, and it is not infinitely extended and has nothing to do with low-code.

The third consensus is the law of conservation of complexity - Tesler's law. A typical example is Apple, whose products are easy to use. But in essence, its overall complexity is conserved. It actually leaves complicated things to system development engineers and software development engineers, so that users can experience it smoothly. The same is true for Serverless, which transfers the trouble of deploying or operating applications and websites to cloud service providers, but the overall complexity remains unchanged.

The fourth consensus is the Dunning-Kruger Effect. In the process of cognitive learning, everyone will have such a development curve: from ignorance at the beginning, to the illusion of new knowledge, To the trough of disappointment, climb slowly. When we learn anything new, we go through such a curvilinear process. Gartner uses the Dunning-Kruger curve to explain the development cycle of new technologies.

personal cognitive curve

Gartern Technology Development Curve

As a development engineer, I often have this physical feeling, and it is very tiring to learn new technologies one after another. The same is true when Serverless was first launched. Everyone has unlimited imaginations about this technology. When the imagination reaches a peak, they will gradually realize the gap between imagination and reality, and experience the technology when it is used in products. The trough, and then the slow climb.

Serverless is the time

This article will introduce Serverless to you through three parts:

The first part is "Complications for Cloud Developers"

The second part is "Simplified for developers"

In the third part, I'll cover some of the best scenarios for myself and our team using Serverless.

Complexity for cloud developers

1) Serverless Architecture

Serverless is a master, and its entire development history is standing on the shoulders of giants. Now many cloud service providers run a function, and the underlying structure is like this. First, there will be a CaaS layer at the bottom of the serverless operation. It is a serverless container service. Most of the application services will run on this layer. The best open source solution for container scheduling is K8s. K8s is used to schedule containers. The bottom layer of IaaS is the virtual machine. is a physical machine.

There are many ways to implement CaaS, and the bottom layer of serverless applications must be supported by CaaS services. In addition to Docker, vm can also be CaaS; for example, Node.js vm can also do CaaS, webassembly can also do CaaS, and so on. In addition, when designing the overall architecture, a Component layer is needed to solve the problems of east-west traffic and north-south traffic, such as service mesh and ingress solutions. Generally speaking, the architecture design behind Serverless is basically the same.

2) Cloud Developers: Immutable Infrastructure

The entire CNCF framework is migrated according to configuration files, and can be deployed on Alibaba Cloud, Tencent Cloud, Amazon's cloud, or even a private cloud built by itself. When all cloud services are built as immutable infrastructure, the complexity sinks to the K8s layer, and the architecture becomes generic.

In addition, for cloud service providers, the traditional advantages they have accumulated before (the operation and maintenance advantages of the virtual machine laas layer and the platform-level advantages of the PaaS layer) will gradually be lost. Therefore, if it is a vendor-unlock cloud service provider, there will be a fierce price war to see who can provide better and cheaper services.

Serverless in a broad sense is the serverlessization of the entire cloud service provider's operation and maintenance system. For example, if a MySQL or Redis is traditionally provided, the developer must realize that this is running on the server, and an ip needs to be provided, but after serverless (BaaS), the developer does not need to care about whether the service is running in the end. Where, only need to declare that a DB is needed, and the application can automatically link and consume the DB.

Serverless in the narrow sense is not only Severless Computing, but also a FaaS application, which is composed of a trigger (which can also be classified as BaaS) + FaaS + BaaS architecture. Now the core competitiveness of cloud developers at this layer of Serverless FaaS is to continuously introduce new BaaS (Backend as a Service) capabilities, and BaaS is mainly used in conjunction with FaaS.

The immutable infrastructure of the cloud service provider mentioned above is shown in the figure below. Developers deploy applications at the top layer and do not need to care about the underlying infrastructure. Now the BaaS SDK provided by the cloud service provider has actually been included in your FaaS runtime. Developers only need to use it as a function interface to call directly, without worrying about where the database is deployed, whether to maintain long links, etc. .

Simplified for developers

This picture shows the development status of emerging technologies launched by Gartner in 2017. At that time, Gartner felt that Serverless was still a relatively new concept, and everyone's understanding of it was still in the climbing stage; but in fact, today, Serverless has entered a period of gentle climbing. Now, everyone has a clear understanding of the problems that Serverless can solve in the operation and maintenance domain, and what boundary restrictions are there.

Why hasn't anything special been launched in recent years? The reason is that there is no particularly new concept in the Serverless layer, and everyone is mostly doing FaaS application infrastructure construction. Whether the various existing web application scenarios can be serverless, such as those that have been supported recently, database BaaS, websocket supports FaaS, and many other web application scenarios are slowly implemented through your efforts to make it It can be close to the ideal Serverless.

Gartner Technology Adoption Recommendations Chart for 2021

The position of the frame in the picture is Serverless, and the green color represents maturity. It can be seen that the current Serverless technology is already a relatively mature technology and supports most Web application scenarios, so developers can try it out with confidence. Serverless.

1) Serverless in the field of operation and maintenance

Many people in China translate Serverless into Serverless or Serverless, which is not very accurate. The opposite of Severless is Serverful. Serverful means that you need to pay special attention to the server. Just focus on deploying the function. As for how it runs, how many containers there are at the bottom layer, and how many servers there are at the bottom layer to support it, developers don't need to care.

The front-end and back-end development models of the traditional model are: the back-end provides data services. It used to be called SOA, which is service-oriented programming. Now, domain-driven microservices are more popular, and the front-end consumes and assembles data. The traditional way of back-end data interface is to provide HTTP API, and now the popular BFF (Backend For Frontend) glue layer function orchestration. It is a popular practice in the industry to provide full data with microservices. Then the future trend will be all BaaS, the ideal state is the front-end and back-end integrated model-driven, no longer need to write the interface.

2) Combining Serverless to make technological changes

Serverless + = ...

The advantage of the current stage of Serverless is the combination of technologies in other fields. Serverless combines with other fields to detonate many technological changes. For example, traditional microservices + serverless can be combined to form BaaS microservices. In the past, to provide a microservice requires developers to care about where the microservice is deployed, but after adding Serverless, you don't need to care about where it is deployed, you only need to care about how to call it. LowCode and Serverless can quickly deploy and launch the built pages; the previous interface function arrangement, such as traditional BFF, can be serverless in the future and become SFF (Serverless for frontend), which is very suitable for front-end and back-end integration solutions.

3) Change of development role: front-end and back-end integration

After the emergence of Serverless, there will be a situation of front-end and back-end integration in the future. Now there are tools for visualizing logic orchestration, such as Uncle Wolf's iMove, which can already do visual orchestration of back-end interfaces, and it becomes very simple for front-end engineers to do a back-end interface orchestration. It can be foreseen that the future responsibilities of front-end engineers can be extended to the back-end.

The original back-end engineers will gradually transform from traditional application deployment to BaaS-based service-level development, and future operation and maintenance engineers will also prefer to migrate to the cloud. This is a series of changes that Serverless brings to the R&D and production chain.

Best Scenario Practices for Serverless

The most convenient way to determine the latest scenario of serverless use is to see which Trigger events are supported by the cloud developer.

So at this stage, various cloud developers are constantly adding new triggers. As shown in the figure, when developers write FaaS, they wrap the HTTP request into a Trigger. The FaaS function can be imagined as a closed package. How to wake up this package and how to open this package? In fact, it is awakened by Trigger.

In addition, at the current stage of Serverless, the importance of the development language is not so high, and the language is only the tool needed to realize the function. After CNCF was launched, FaaS is already language-independent. In fact, it is Node.js, PHP, Python, or other mainstream languages. Code FaaS can be used. You can even build a mirrored custom language and execution environment. . Therefore, after Serverless, we can borrow the advantages of multiple languages, such as using Python to process AI data, Node.js to process high concurrent network I/O and so on.

1) SFF data arrangement

The best practice is BFF + Serverless, which is very common within the Alibaba Group. Since most of the back-end scenarios in Alibaba are Java engineers, the front-end team needs to connect with the engineers, and the back-end engineers provide HSF microservices, which can be understood as a bunch of RPC interfaces. In the past, a Node.js application was deployed to adjust the interface, and after getting the data, the data was cleaned, processed, and rendered on the front-end page. However, after using Serverless to deploy BFF's Node.js applications, there is basically no need to consider follow-up traffic expansion and contraction, cost savings, and other issues.

2) GitOps model

GitOps is a very suitable scenario for small enterprises. It is equivalent to building a set of automatic release and online pipelines. It is no longer necessary to test a version to modify it as before. At present, the whole solution is very mature. Git itself supports a large number of hook functions, so it is very easy to create such a process. What needs to be paid attention to is to combine the capabilities of cloud developers. For example, the release process of Alibaba Cloud is very automated. After the cloud platform is released online, it can support online traffic recording and playback.

3) Small but beautiful technical team

The last point is to build small but beautiful teams. In my perception, there is a strong constraint on technical architecture: the organizational structure will determine our technical architecture.

Just like the separation of front-end and back-end, mostly because of the definition of organizational structure: the front-end has front-end leaders, and the back-end has back-end leaders, so the front-end is developed by the front-end, and the back-end is developed by the back-end, which requires intermediate decoupling based on API communication. So if we want to build a small and beautiful team, how do we break this barrier?

A more suitable scenario for serverless is that the front-end service orchestration SFF will solve the problem of intermediate API communication, and the back-end can provide full services. This kind of change will force the backend to be microserviced, and even the backend R&D will use Serverless to do BaaS, which is a reverse derivation process. If our front-end team masters serverless, there are three advantages: front-end data orchestration no longer needs to find back-end engineers; GitOps solves deployment and operation and maintenance, which can reduce the mental burden of front-end; front-end students can concentrate on abstracting business models.

Instructor Profile:

Pu Songyang, nicknamed Qin Yue. Author of Geek Time "Introduction to Serverless". Serverless and Node.js evangelist, currently responsible for the standardization team of Alibaba front-end committee, low-code team - middle and back-end construction, Node.js application microservice architecture. He has extensive experience in microservices, serverless and mid-stage projects.

Stamp here , can watch the replay Serverless Meetup Shenzhen station!