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

The author said

Before starting this article, I want to reach a few consensus with developers.

The first consensus is that software engineering is not a silver bullet, nor is Serverless a silver bullet. It is not a universal formula for solving all problems.

The second consensus is that Serverless can solve problems in the operation and maintenance domain. It is a technology that solves problems in specific fields, and is not infinitely extensible, 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. However, in essence, its overall complexity is conserved. It actually leaves complex matters to system development engineers and software development engineers, allowing users to have a smooth experience. In the same way, Serverless has handed over the trouble of deploying or maintaining 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 experience such a development curve: from ignorance at the beginning, to the fantasy of new knowledge, to the trough of disappointment, slowly climbing. We learn any new thing through such a curve 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 feeling that new technologies emerge endlessly and I am tired of learning. When Serverless was first launched, it was the same. Everyone was full of unlimited imagination about this technology. After reaching a peak in imagination, they gradually realized the gap between imagination and reality, and experienced firsthand that when used in products, they would fall into the technical trough, and then slowly climb the slope.

Serverless is just right

This article will introduce Serverless to you in three parts:

The first part is "Complex for Cloud Developers"

The second part is "Simplifying for Developers"

In the third section, I will introduce some of the best scenarios for myself and my team when using Serverless.

1. Complex for cloud developers

(1) Serverless architecture

Serverless is an aggregator whose entire development history stands on the shoulders of giants. Nowadays, many cloud service providers run a function, and the underlying architecture is this. First, there will be a CaaS layer at the bottom of the serverless operation. It is a serverless container service, and most application services will run above this layer. A better open source solution for container scheduling is K8s, which is used to schedule containers. The underlying laaS is a virtual machine, and the underlying is a physical machine.

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

(2) Cloud developers: immutable infrastructure

CNCF poses a vendor-unlock crisis for cloud developers. When all cloud services are built as immutable infrastructure, the complexity sinks to the K8s layer, and the architecture becomes universal. Because the entire framework of CNCF's architecture is migrated based on configuration files, it can be deployed on Alibaba Cloud, Tencent Cloud, Amazon's cloud, or even its own private cloud.

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

In a broad sense, Serverless refers to the serverless operation and maintenance system of the entire cloud service provider. For example, traditionally providing a MySQL or Redis service requires developers to realize that it is running on the server and need to provide an IP address. However, after Serverless (Baas), developers no longer need to care about where the service is running, just declare that I need a DB, and the application can automatically link and consume the DB.

In a narrow sense, Serverless not only refers to Severless Computing, but also refers to a FaaS application that is composed of a trigger (which can also be merged into BaaS)+FaaS+BaaS architecture. Currently, the core competitiveness of cloud developers in this layer of Serverless FaaS is to continuously introduce new BaaS capabilities, and BaaS is mainly used in conjunction with FaaS.

The immutable infrastructure of cloud service providers mentioned above is shown in the figure below. Developers deploy applications at the top layer without paying any attention to the underlying infrastructure. Currently, the Baas SDK provided by cloud service providers is actually included in your FaaS runtime. Developers only need to use it as a function interface to directly call it, without caring about where the database is deployed, whether to maintain long links, and so on.

2. Simplify for developers

This figure 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; In fact, by 2021, Serverless has entered a gentle climb period, and everyone has a clear understanding of the issues that Serverless can solve in the operation and maintenance domain, as well as the boundary restrictions and so on.

Why hasn't anything particularly new been introduced in recent years? The reason is that there is no particularly new concept emerging in the Serverless layer, and everyone is more engaged in FaaS application infrastructure construction. Whether the existing various Web application scenarios can be serverless, such as the recently supported database BaaS, and websocket supporting FaaS. In addition, many Web application scenarios are slowly achieved through your efforts to make them close to the ideal Serverless.

2021 Gartner Technology Adoption Recommendation Map

The position of the frame in the figure is Serverless, and the green color indicates that it is mature. It can be seen that today's Serverless is a relatively mature technology that supports most Web application scenarios, so developers can rest assured and boldly try Serverless.

(1) Serverless in the field of operation and maintenance

Many people in China translate Serverless into serverless or non service, which is not quite accurate. The opposite of Severless is Serverful, which means that special attention should be paid to servers. The essence of Serverless is to reduce the mental burden and not need to pay much attention to servers. It only needs to focus on deploying functions. As for how it operates, how many containers are there at the bottom, and how many servers are there to support it, Developers don't need to care.

The traditional model of front-end and back-end development is composed of back-end data services, formerly known as SOA, which is service-oriented programming. Nowadays, it is more popular to use domain driven microservices and front-end consumption to assemble data. The traditional method for back-end data interfaces is to provide HTTP APIs, and now the popular BFF (Back For Front) glue layer function orchestration. Providing full data with microservices is currently a popular practice in the industry. The future trend will be fully BaaS oriented, with the ideal state of front and rear end integrated model driven, and there is no need to write interfaces anymore.

Making technological changes with Serverless

Serverless + = ...

The advantage of the current stage of Serverless is its integration with technologies in other fields. Serverless combines with other fields to ignite many technological changes. For example, the combination of traditional microservices and Serverless can be made into BaaS-based microservices. In the past, providing a microservice required developers to care about where the microservice is deployed, but with Serverless, it doesn't matter where the microservice is deployed, just how to call it. LowCode plus Serverless allows the built page to be quickly deployed and launched; The previous interface function layout, such as the traditional BFF, can be serverless in the future, becoming SFF (Serverless for frontend), which is very suitable for front-end and back-end integration solutions.

(2) Transformation of development role: integration of front and rear ends

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

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

3. Best Scenario Practices for Serverless

The most convenient way to determine the recent scenarios used by Serverless is to see which Trigger events are supported by cloud developers.

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 as a Trigger. You can imagine the FaaS function inside a closed package. How do you wake up the package and open it? It's actually waking up through a Trigger.

In addition, at the current stage of Serverless, the importance of developing a language is not that high, and the language is only the tool needed to implement functions. After CNCF was launched, FaaS has become language independent. In fact, FaaS can be code from Node.js, PHP, Python, or other mainstream languages. You can even create a mirror custom language and execution environment by yourself. Therefore, after Serverless, we can borrow the advantages of multiple languages, such as using Python to process AI data, and Node.js to handle highly concurrent network I/O.

(1) SFF data orchestration

The best practice is BFF+Serverless, which is very common within Alibaba Group. Due to the fact that most of the backend scenarios in Alibaba are Java engineers, the front-end team needs to interface with the engineers, and the backend engineers provide HSF microservices, which can be understood as a bunch of RPC interfaces. In the past, we deployed a Node.js application to tune the interface, cleaned and processed the data after obtaining it, and then placed it on the front-end page for rendering. However, after deploying the Node.js application of BFF using Serverless, there is basically no need to consider issues such as following up traffic scaling and cost saving.

(2) GitOps model

GitOps is a very suitable scenario for small businesses, which is equivalent to building a self built pipeline for automatic release and launch. It is no longer necessary to modify a version and test it again, as before. Currently, the entire solution is very mature. Git itself supports a large number of hook functions, so creating such a process is also very easy. What needs attention is to combine the capabilities of cloud developers. For example, Alibaba Cloud's release process is very automated, and it can support online traffic recording and playback after the offline platform is released online.

(3) A small and beautiful technical team

The last point is to create a small and beautiful team. In my understanding, there is a strong constraint to technological architecture: organizational structure determines our technological architecture.

Like the separation of the front end and the back end, it is mostly because the organizational structure defines that the front end has the leadership of the front end, and the back end has the leadership of the back end. Therefore, the front end is developed by the front end, and the back end is developed by the back end, requiring intermediate joint debugging based on API communication. How can we break this gap if we want to create a small and beautiful team?

A more suitable scenario for Serverless is that using the front-end service orchestration SFF will solve the problem of intermediate API communication, and the back-end can provide a full range of services. This change will force the backend to implement microservices, and even the backend R&D will adopt Serverless to implement BaaS, which is a reverse promotion process. If our front-end team has mastered Serverless, there are three advantages: front-end data editing and defecation no longer require back-end engineers; GitOps solves the deployment, operation and maintenance, which can reduce the mental burden on the front-end; Front end students can concentrate on abstracting business models.