Technology Inventory: Interpretation of Cloud Native Architecture Trends in 2022

Author: Xin Xiaoliang

Interview guests: Zhijian, Yanlin

Since the development of software architecture, it has experienced the evolution process from monolithic architecture, vertical architecture, SOA architecture to the current cloud-native technologies such as microservices and service grids. The development of cloud-native technologies is unstoppable. The old-fashioned "cloud native" will It will still be a hot topic in the future. And with the acceleration of digital transformation, the use of cloud by enterprises will reach a new level, and cloud-native architecture and cloud-native applications will continue to iteratively evolve.

So with the blessing of cloud native and other technologies, what are the trends worth paying attention to in the field of architecture in 2022? How does cloud native support the future of architecture? This article is reproduced from InfoQ Architecture Headlines. Li Yanlin (Yan Lin), head of Alibaba Cloud MSE, and Li Yun (Zhi Jian), senior technical expert of Alibaba Cloud, are guests on the InfoQ video account to share the latest trends in the field of cloud native architecture. For full video playback, click to read the original text.

software architecture evolution

InfoQ: The software architecture has gone through from the monolithic architecture to the SOA architecture to the later architecture represented by the microservice cloud native. What are the key nodes in the middle?

Zhijian: Speaking of cloud native today, I think we still need to review the history to understand what it is all about.

• In 2000, there was no concept of virtualization, and everyone saw physical machines;
• VMware was born in 2001, but at this time it was still a virtual machine;
• After that, in 2006, Amazon launched the IaaS (Infrastructure as a Service) platform AWS. At this time, the idea was to turn CAPEX (capital investment cost) into OPEX (operating cost). That is, I don't need to buy a lot of machines, but go to the cloud to buy them after they are used;
• In 2009, Heroku proposed PaaS. At this time, it was no longer delivered by virtual machines, but became Buildpacks. It also began to have the concept of containerization and a set of rules for 12-factor applications;
• In 2010, OpenStack appeared. In fact, it does IaaS through open source methods. The purpose is to compete with AWS. The building block it builds is still a VM;
• In 2013, the emergence of Docker brought a big change, and at this time delivery became a container.

Today's Cloud Native was first proposed by Pivotal, and later defined by the CNCF (Cloud Native Computing Foundation) established in 2015.

In fact, we can clearly see some changes in the whole process. From mainframes, servers to VMs, Buildpacks, and then to containers, the isolated units are getting smaller and smaller, from heavy and large to later through the microservice software architecture. It becomes very small. The most important purpose of this is to do decoupling. You may have a lot of ideas about Cloud Native, but I think the key point is what is the core of Cloud Native. From my own understanding, I think all software has a wise saying, we call it divide and conquer, or it can be called solution Coupling, or high cohesion and low coupling. Through continuous decoupling into microservices, the entire interaction is made more agile. Instead of being coupled together like the previous single application, it is difficult to coordinate and deliver.

Another important element of Cloud Native is no lock-in, that is, to avoid technical lock-in. Starting from CNCF's definition of standards, CNCF will not directly say that something is a standard, they will consider this thing as a key component, and express that this component is widely adopted and recognized by our CNCF. In this way, more people will use it, and I know that this software will have long-term maintenance. Naturally, it will be standardized, and the benefit of this standardization is no lock-in. I think it can be done from different dimensions. understand it.

From the vendor's point of view, you can flexibly choose different cloud providers; the other is for engineers, if you are doing business development on the platform of company A, it is very likely that you will not be able to do it after leaving company A. The advantage of no lock-in is that it will not lock employees into a technology company. As long as you master Cloud Native technology, your position can be circulated in the talent market.

Yanlin : Just now Zhijian talked about it from the perspective of the entire software industry. Let me briefly explain my understanding from the perspective of the industry.

The current cloud native technology, including the form of software architecture, is closely related to Internet 1.0, 2.0, and 3.0. The earliest Internet 1.0 era were all static pages. At this time, the content carried by most websites was relatively simple, and a single application could basically be solved by adding CDN; as the Internet entered 2.0, various portal websites and web applications emerged, and some Interactions, more interactions, and more rendering have higher overall technical requirements. Monolithic applications can no longer meet increasingly complex business needs. Software has become more complex, scenarios have become more complex, and the degree of digitalization of human collaboration has become more and more complex. The higher the age, the era of SOA and microservices has entered; after that, a relatively big change has taken place in the entire industry, that is, the mobile Internet. The arrival of the third era has put forward higher requirements for real-time performance, including " Active acquisition, passive push”. The amount of information obtained and the amount of real-time rendering is larger, and the entire IT system is also growing explosively at this stage, and the requirements for digital systems are higher.

With the development of the entire cloud computing, in fact, more with the development of the cloud, around 2015, according to what I just said, generalization and standardization are basically gradually formed. After 2015, Various containerizations in the industry, such as Docker, K8s, and Spring Cloud, are all emerging in this era, which is probably the case.

InfoQ: After so many years of changes in the software industry and industry, what stage has the cloud-native architecture developed to now?

to Jane: I think from today's perspective, it can be said that cloud-native architecture has been widely accepted by all walks of life.

Taking Service Mesh as an example, the acceptance of Service Mesh has grown significantly over the past year. The reason why the cloud-native architecture takes Service Mesh as an example is because the overall concept of cloud-native has been widely accepted. For example, K8s under cloud-native architecture is undoubtedly a situation of unifying the rivers and lakes. In contrast, Service Mesh is biased. late. Issues that were once questioned about Service Mesh, such as performance, have been gradually accepted today. Acceptance does not mean that performance issues have been completely solved, but that everyone knows how to make good use of their strengths and circumvent weaknesses.

The question that many companies are considering today is how do I implement the cloud native technology. I think cloud native is a combination of concepts and design patterns. I will not simply say that cloud native has developed to 50% or 60% of the entire process, and I will not look at it with this thinking, but whether we can go to cloud native first, with the evolution of cloud native technology, I will also Can go forward with this rhythm.

I think the good thing is that the whole public has a good awareness and understanding of cloud native technology, and then the overall trend of cloud native is optimistic and flourishing.

Yanlin: me talk about my understanding of this matter. First of all, I will talk about the software technology layered. This year, you can see that Alibaba Cloud and all other clouds are talking about the container Anywhere. In fact, the container has become a An infrastructure that, over the next three to five years, may hold more containers than running on ECS alone.

From the perspective of microservices, because we have been planning for two years recently, you should have seen some key data, such as the average salary of Chinese programmers. The average salary is the labor cost, which is actually much higher than the IT cost. Computing power cost and resource cost. Containers are more about resource scheduling costs and operation and maintenance costs, while microservices are more about R&D costs and collaboration costs. Because if you build too many people on a code, the efficiency is very low. Therefore, the first problem is that manpower and efficiency are becoming more and more important, and with the intensification of competition in the entire industry, you will have an advantage if you run fast, and you will miss this opportunity if you run slowly. The Internet industry is "fast fish eat slow" fish".

Another relatively new thing in the data I am concerned about is the age distribution of the entire programmers. The post-90s generation has become the core force in building a digital economy, and their collaboration mode and work style are no longer the same as those of the older members. They like a more agile and independent collaboration model, and microservices are actually a collaboration model that is more in line with them.

At present, from the perspective of the entire industry, microservices have become a mainstream choice. And we can also see from the other two data: the first is that microservices have an annual growth rate of more than 20% from the perspective of the entire industry, which means that tens of thousands of companies in the entire industry are transforming microservices every year; The second is that in addition to the containerization and microservice transformation of Internet companies, many traditional industries, such as retail, medical care, finance, etc., have begun to undergo digital upgrades one after another, and microservices have a wider application space in the entire society.

From another technical point of view, whether it is a single application, microservices, or future service grids, serverless, etc., all have their own application scenarios. Today, it may be due to the increase in labor costs and the overall rejuvenation requirements for collaboration. Freer and more independent, containers and microservices are becoming more and more important under this general trend.

InfoQ: In the process of chatting just now, we also saw a lot of audiences expressing their approval, and also mentioned some landing cases. Do the two teachers have any relevant landing cases to share?

There are actually a lot of landing cases, so let me just give a few examples that can be talked about to the outside world.

Caller Technology has completed the entire cloud-native technical transformation in the past few years, including containerization and microservices, and has greatly improved R&D efficiency and resource utilization. Now that they have reached the second stage of cloud native, the bigger problem at the moment is service governance, such as graceful online and offline, lossless offline, and at the same time, they also face high availability problems, such as its actual scene, online and offline integration, With higher requirements for online stability, a high-availability system is required, including current limiting, downgrade, fusing, rollback, and full-link grayscale. They have now reached this stage, and they are also at a relatively high level in terms of service governance, representing a case where some traditional enterprises and the Internet intersect.

The other is Skechers. They have also caught up with digital transformation. They know that the digital economy is already an unstoppable trend in China. If they do not join this trend, they may be eliminated. He also contacted us to prepare the entire middle-office system. In almost a few months, he quickly reused Alibaba's middle-office technology architecture to build his entire retail system. Of course, he also encountered some problems in the process. When he was working on a microservice system, his entire system had multi-terminal access to POS, Web, and App, including some traditional architectures, and part of it was a new microservice architecture. In this process, the new cloud native gateway was used to solve the problem. Security issues from the intranet to the extranet, such as certificate management, web protection, security authentication, etc.

In addition, Skechers will also do a big promotion, and the peak value is several times higher than usual. They reused Ali's high availability system, from the entrance to the backend, and created an end-to-end full-link current limiting, downgrading, and fuse mechanism. Guaranteed high availability throughout the transaction process. It was also practiced through the entire full-link stress test system, and the drill was successful one month in advance, supporting the entire Skechers e-commerce system for trading on the day of Double 11.

It takes a few months to build such a system. This is a bonus that the entire cloud native brings to you. I will simply share these two cases.

to Jane : Let me briefly add that the implementation of cloud native architecture today is not a small number, it is already thousands of concepts.

If you often pay attention to the entire industry, you can see that almost all the famous Internet companies are not exploring, but are already deeply used. I don’t think there is any doubt on this point.

InfoQ: What problems will be encountered in this process or in the implementation and application of new technologies, and how should we face them?

to Jane : When we face new technologies, "new" is not the biggest problem.

I just think that every new technology comes along with it that makes us re-examine the technical debt that each business has left over the course of its development. Including the previous implementation of Service Mesh within the Alibaba Group, the most painful thing for me is not whether the technology is new or not, or that you cannot make it, but that you have to spend a lot of energy and time to deal with the historical burden first.

So in the process of landing, one of the biggest pain points I saw was actually the cost of transformation, including moving the previous architecture to cloud native, and possibly splitting services. Because the cloud-native architecture does not simply say that you move it to the container to solve the problem, but that we should take this opportunity to do microservices and microservices, at least in terms of efficiency.

Yanlin: Let me talk about some of my specific feelings in practice. First of all, everyone should have an open attitude towards new technologies. For example, whether it is the transformation of microservices or containers, it not only changes the architecture of the software, but also the architecture of the organization. For example, when we exported Alibaba's software architecture to some traditional enterprises, we found that Alibaba's entire organization is flat, and its microservices are flat and distributed. Therefore, everyone's collaboration efficiency is relatively high, and it is an agile development model. However, many organizations are still in the form of pyramids, and the efficiency of cross-departmental collaboration will be relatively low. Of course, with the change of the software architecture, the organizational structure will also change with the software architecture, which everyone can slowly realize.

Then when you take the first step to solve the mentality problem, you will indeed face some problems one after another, because there is no silver bullet in the software industry, and there is no omnipotent architecture. For example, the microservice architecture is indeed a team of more than 10 people and more than 5 subsystems will have a greater advantage in the overall productivity. In the process of transforming the microservice itself, the more question you ask is how hard is my system to be demolished? I think "one master and one backup" is a more suitable range, and if it is dismantled too finely, it will bring more coordination and operation and maintenance costs. Of course, it does not mean that it will not work if it is finely divided. There are some business scenarios that deviate from the line calculation type. If it is lighter, it can be divided into finer details. This requires experienced experts to do field segmentation.

Specifically speaking about the splitting of microservices, the first problem I encountered at the time was positioning. After microservices, you would find that the logs ran to more than a dozen machines. The cost of viewing all the logs is very high, and the cost of diagnosing problems is very high. Also very large. Now industry link tracking, including APM, and monitoring and alarming are the solutions to the problems in this field.

In addition, we see a data that 70% of the containers are very easy to implement microservices, why? Because after microservices, the deployment of your application is more detailed and more expensive, and the operation and maintenance cost will increase. A large part of the container solves the operation and maintenance cost through the automatic mode, and realizes the complementary effect. Through the evolution of containers, a deployment cost problem after the split of microservices is solved.

On the whole, what I can gradually feel is that the threshold for the use of the entire container and microservices is much lower than before. Today, through the development of open source and cloud computing, the threshold of these technologies has been lowered, and the rest may be more of decision makers looking for the right time. For example, I know that the business is going to grow explosively and the complexity will increase. I want to evolve the cloud-native architecture and solve the problem, which is probably the case.

Outlook for future architecture trends

InfoQ: Can you briefly talk about the multi-cloud architecture?

to Jane : In our opinion, an important driving force of cloud native is to prevent lock-in, and it is also something that enterprises are more concerned about and want to have standardized.

With multiple clouds, current customers have some challenges in managing multiple clouds. I think this will be a process. From the very beginning, everyone talks about going to cloud native, to multi-cloud and hybrid cloud. These two are undoubtedly the key content of cloud native, and it will make it more and more convenient for developers to use this technology. , it is done from a developer-centric perspective, so there will definitely be related technologies and products coming out in the future, including some now.

In addition, I understand that in the short term people may not think it is so easy to use, but I think this will become more and more easy to use, which must be the focus of various cloud vendors, because the focus of our development depends on how we can solve customer problems. What pain points help the client better develop his business.

Yanlin : Multi-cloud may be called differently by different manufacturers, such as cross-cloud and hybrid cloud. We emphasize distributed cloud more here. What I can feel is that why the industry chooses multi-cloud, everyone has different ideas.

In the overseas situation, there may be some high-availability needs. In China, everyone hopes to have cheaper resources and fights price wars. Overseas is to take advantage of each cloud, such as AI big data Google Cloud is stronger, traditional IDC field AWS is stronger, so that it can be used in combination, online business in AWS, offline in Google, and so on, used together.

I take this example to say that for most manufacturers, there must be a cost to cross the cloud. Some domestic enterprises may wish to choose multiple cloud vendors and negotiate some discounts, but the result is that the complexity of operation and maintenance and management costs after cross-cloud increase. I know that the domestic Internet industry has invested a lot in this area. manpower to wipe out.

InfoQ: We have collected some community questions before, and would like to ask what new forms of software architecture will emerge in the next five years?

to Jane : What exactly is architecture? I think we need to take a look at it first. The architecture I understand is composed of three elements. The core is the concept. The second is the relationship between concepts and concepts. The third element imposed above is constraints.

The emergence of cloud native is actually a practice of architecture. This practice is based on the problems we have seen and faced in the past, re-review and reflection, break and split the previous concepts, and then reshape this The concept finally formed the Best Practices (best practices) mentioned today, including many design patterns such as Sidecar, Operator and so on.

It is unlikely that there will be no new architectural concepts in the next five years, but if it is disruptive, I personally think it is unlikely. If you want to subvert the cloud-native architecture, first of all, the cloud-native technology needs to be applied to a certain extent, and then there is a situation where there are more extreme pursuits. As for changes, it is normal for new concepts to be put forward. The development of the industry is that people constantly shape concepts. This is precisely the phenomenon and a natural state of technological development.

Yanlin : Unless quantum computing speaks out, I think the distributed era will exist for a long time before this era. Then in the long-standing distributed era, we can feel some trends happening.

Because of containers and microservices, business has become stateless. If the flexibility of the entire flexible scheduling is extreme today, serverless is possible in the future. From our technical architecture this year, the middleware client is lightweight, and the business side will be serverless to evolve, because the business is now more and more stateless. With the completion of the underlying infrastructure and the availability of elastic capabilities, there is a possibility of upward evolution, but from our perspective this year, it is easier for some tasks such as off-line computing to be serverless. I believe that with the continuous breakthroughs in basic technologies, including hardware acceleration technologies, many big manufacturers have plans for Serverless. Before, when everyone talked about Serverless, they were talking about application architecture. Now, for example, message storage has corresponding Serverless products, so Serverless It may be a technical idea in the future.

In addition, what I can feel is that below the container, it is more concerned with DevOps and solving the operation and maintenance efficiency. The first half of cloud native solves the problem of Ops, which is the problem of operation and maintenance. In the future, it will be more about solving the problem of Dev. Make research and development more efficient and develop faster iterations. Of course, in this process, middleware including microservices may solve more default security, trustworthiness and stability issues.

Architect growth experience sharing

InfoQ: Many programmers will encounter some bottlenecks when switching from ordinary developers to architects. Do the two teachers have any experience in the growth of architects to share with you?

to Jane : In fact, there are many things that can be said in the field of architects. Let me first talk about my thoughts and briefly share a few points. Yanlin can make additions.

First of all, the first point of being an architect is to have the pursuit of technology, to have some accumulation in technology, and the pursuit of software design, which is what we call "the beauty of architecture".

The second point is to know how to switch perspectives and look at things from different perspectives. My biggest feeling as an architect is how to look at what we are doing from the perspective of users, customers or users. When you look at things from the perspective of a user or customer, you will find something completely different.

From the point of view of my own commercialization in the past year, I have a very big feeling. Whether developing and delivering a product to customers, or building an internal module, how to look at it from the perspective of the other party, we will find that a technical term we are familiar with feels natural and simple, but customers or users do not think so.

I personally think that the more important thing is the continuous upgrading of thinking. From focusing on individuals to focusing on larger teams and organizations, it is a process of continuous breakthroughs. To be a good architect, you need to have continuous abstraction ability, you need to be very pragmatic, and you need to have product thinking and business thinking. The higher the cognition goes, the more you will find that technology is only a part, but what I want to emphasize is not to think that technology is not important.

Yanlin : I just said very well, switching perspectives is a hurdle that many people cannot get around when they change from programmers to architects or PDs and leaders. Then I will add a few ideas from my side. I often interview, so I will talk about a few things that I am more concerned about in combination with this.

First of all, in terms of basic technology or software development, I prefer people who are curious. If you are interested in technology, you can continue to deepen the technology. Otherwise, it is easy to float on the surface, and it is difficult to have long-term technical precipitation. Driven by curiosity, can we develop and go further.

The second is to take the initiative to take responsibility at work. I also often tell my teammates, if you can't figure it out, I'll help you do it together. In this process, you can get more resources and help and get faster growth. A lot of growth is to jump to a high area and challenge more difficult things, so that you can continue to exercise yourself and think about problems at a higher level.

The third is the dimension of thinking. I mentioned the user perspective and the technical perspective just now. There is another perspective that is also more important, that is, the overall perspective.

For example, for example, a newly hired employee looks at problems and disassembles them without thinking too much. They can disassemble 10 problems into 5 requirements, and 5 problems have already reached a level, and they can start from these 5 requirements. Find out the unreasonable and avoid it in the middle, which will have the product thinking, and then rebalance the schedule to complete the remaining reasonable demand, so as to exercise the input-output ratio and priority thinking. When you complete a complete product, you will continue to coordinate with the front-end and back-end, operations, etc., and the ability will be gradually exercised in the process of collaboration. In the same way, going further up is the ability to coordinate more surrounding resources and so on.

To sum up briefly, after 2-3 years of employment, the in-depth accumulation of core technologies is very important. Only with depth can we go further; after the technology is solid, the second point is to cultivate product thinking. Product thinking is very important, not just technology. ;After having product thinking, the third thing to do is the collaboration of upstream and downstream people. To be an architect, you need to deal with multiple roles to get things done well; when the collaboration is done, the problem to be solved is leadership and planning for the future. ability, this requirement will be higher.

InfoQ: Very much for the answers of the two teachers. Because of time constraints, today's live broadcast is almost over here. Thank you very much for watching, and thank you Zhijian and Yanlin for their wonderful sharing.

Guest introduction:

Li Yun (flower name: Zhijian), technical director of Alibaba Cloud Service Grid Hybrid Cloud Product. Since 2018, he has led the team in the development and construction of service grid technology in Alibaba Group, and has done many technical sharings on cloud native and service grid at QCon.

Li Yanlin (flower name: Yanlin), Nacos PMC, founder of Alibaba Cloud MSE product, and head of Alibaba Cloud soft load team.

Full content video playback, click here view.