How should cloud native architecture be designed?

Introduction to Alibaba provides solutions and best practices based on Alibaba Cloud services for a large number of enterprise customers in all walks of life to help enterprises complete digital transformation, and has accumulated a lot of experience and lessons. Alibaba combines the core focus of the company, corporate organization and IT culture, engineering implementation capabilities and other aspects with architecture technology to form Alibaba's unique cloud native architecture design method—ACNA (Alibaba Cloud Native Architecting)

The concept of ACNA

​

Alibaba provides solutions and best practices based on Alibaba Cloud services for a large number of corporate customers in all walks of life to help companies complete digital transformation, and has accumulated a lot of experience and lessons. Alibaba combines the core focus of the company, corporate organization and IT culture, engineering implementation capabilities and other aspects with architecture technology to form Alibaba's unique cloud native architecture design method—ACNA (Alibaba Cloud Native Architecting). This method is described in more detail in the best-selling book "Alibaba Cloud Cloud Native Architecture Practice" recently published by Alibaba Cloud.
​

(1) The role and purpose of ACNA

​

1) Improve the ability of the R&D team to achieve cost, schedule, function and quality goals.
2) Guide the R&D team to control the R&D and operation and maintenance process, optimize the IT organizational structure and create a more efficient software engineering process mechanism.
3) Guide the R&D team to choose improvement strategies in the process of determining the maturity of the cloud native architecture and positioning the key issues of cloud native.
​

(2) Implementation steps of ACNA

​

1) Determine the maturity level of the cloud native architecture that the enterprise is currently in.
2) Understand the factors that play a key role in improving production quality and optimizing the process.
3) Focus the work on a limited number of key goals, so as to effectively optimize the existing R&D process and continue to improve the product.
​

ACNA is a “4+1” architecture design process, where “4” represents the key perspective of architecture design, including the corporate strategic perspective (ACNA-S1), business development perspective (ACNA-S2), and organizational capability perspective (ACNA-S1). S3) and the perspective of cloud native technology architecture (ACNA-S4); "1" means that the architecture of cloud native architecture continues to evolve closed loop (ACNA-S5). The relationship between 4 key perspectives and 1 closed loop (named ACNA-G1) is shown in Figure 1.

Figure 1 ACNA-G1: ACNA architecture design flow diagram

​

In addition to being an architecture design method, ACNA also includes an evaluation system for cloud native architecture, a maturity measurement system, industry application best practices, technology and product systems, architecture principles, implementation guidance, etc. The other chapters of this book will respectively explain in detail the cloud native technology and product system, architecture principles, best practices and other aspects. Here we mainly introduce the maturity measurement system and implementation guidance of the cloud native architecture.
​

ACNA-S1: Corporate Strategy Perspective

​

Any architecture must serve the corporate strategy, and cloud native architecture is no exception! Unlike previous architecture upgrades, the cloud-native architecture upgrade is not only a technology upgrade, but also a reconstruction of the core business production process of an enterprise (that is, building a digital business through software development and operation). The significance of the cloud-native architecture upgrade It is as profound as replacing hand workshops with more automated assembly lines in the industrial age.
​

Enterprises must be clear about the relationship between business strategy and cloud IT strategy, that is, cloud IT strategy is only the necessary technical support for business strategy, or cloud IT strategy itself is also part of business strategy. Generally, high-tech companies will put forward higher demands on cloud computing, for example, through the extensive use of AI technology provided by cloud vendors to provide users with an intelligent user experience, and the use of IoT (Internet of Things) and audio and video technologies to build a wider range of users , Vivid connection.
​

In fact, in today's digital transformation, more and more companies believe that cloud IT strategy should play an important role in the business strategy of technology to empower business innovation. Cloud IT has become "Cloud First" or even "Cloud Only". "It's just that there are some differences in the strategy of adopting public cloud or hybrid cloud. Based on the cloud IT strategy, cloud-native architecture can help companies implement ubiquitous access technologies and build a digital ecosystem. It can also ensure the rapid iteration of digital business from a technical perspective, build a digital infrastructure for user experience management, and continuously optimize IT costs. , Reduce business risks.
​

ACNA-S2: Business development perspective

​

In the process of providing cloud services and consulting for enterprises, Alibaba found that the main demands of digital business for technical architecture are to ensure business continuity, rapid business launch, business cost control, and technology to enable business innovation. Business continuity requirements mainly mean that digital services must be able to provide continuous services to users, and cannot be unavailable due to software and hardware failures or bugs, but also to prevent accidents such as hacker attacks, unavailability of data centers, and natural disasters. In addition, when the business scale grows rapidly, the purchase and deployment of software and hardware resources must be timely so that the enterprise can better expand new users.
​

The market is changing rapidly. Compared with traditional business, digital business has more flexible characteristics, which requires enterprises to have faster "business-to-market" capabilities, including rapid construction of new business and rapid update of existing business. Cloud-native architecture can deeply understand the demands of enterprises for these capabilities, and deal with them in varying degrees at multiple levels such as products, tools, and processes. It should be noted that these demands also bring new requirements to the organizational structure, which may require a complete restructuring of the application (such as microservices).
​

Cloud computing must release cost dividends for enterprises and help enterprises transform from the original CaPex model to the OpEx model, which means that they do not need to purchase a large amount of software and hardware resources in advance, but pay as much as they need. At the same time, the massive adoption of cloud-native architecture will also reduce the development of enterprises. And operation and maintenance costs. Data shows that through container platform technology, operation and maintenance costs can be reduced by 30%.
​

Under the traditional model, if you want to use high-tech empowerment business, you will go through a lengthy process of selection, POC, piloting and promotion. If you choose to use cloud services provided by cloud vendors and third parties, you can apply more quickly New technology for innovation. Because these cloud services have faster connection speeds and lower trial and error costs, and have the advantages of a unified platform and unified technology dependence on the integration of different technologies.
​

ACNA-S3: Organizational Capability Perspective

​

The cloud-native architecture upgrade is a complete upgrade of the entire IT architecture of the enterprise. When each organization upgrades the cloud-native architecture, it must be tailored to the enterprise's own situation. Among them, organizational capabilities and technology stacks are equally important. The architecture upgrades involved in the cloud native architecture have had a huge impact on development, testing, and operation and maintenance personnel in the enterprise. The upgrade and implementation of the technical architecture requires the active participation and cooperation of relevant organizations in the enterprise. Especially in the process of the continuous evolution of the architecture, organizations like the "Architecture Governance Committee" are required to be responsible for the planning and implementation of cloud native, and constantly check and evaluate whether there are deviations between the architecture design and implementation.
​

In addition, the design of cloud native architecture also needs to consider changes in organizational structure. As mentioned earlier, a very important cloud-native architecture principle is servicing (including microservices, small services, etc.). A typical principle in this field is Conway’s law, which requires that the technical architecture and communication architecture of the enterprise must be consistent, otherwise it will lead to The malformed service-oriented structure has even led to the increase in organizational communication costs and the increase in "wrangling" phenomena.
​

Another very important issue that enterprises need to consider is how well they accept changes, or in other words, their ability to quickly adjust their organizational structure and maintain business stability. The cloud-native architecture upgrade requires a large number of enterprise IT personnel to also upgrade the technical system and redesign the job functions, which will inevitably lead to the technical leaders and lower-level employees who were in a stable and comfortable zone must break and rebuild, so the risk of organizational change Have to think carefully.
​

ACNA-S4: A Perspective of Cloud Native Technology Architecture

​

From the perspective of technical architecture, ACNA believes that the architectural dimension includes seven important areas, which are described in detail as follows.
​

(1) Servicing capability
Use microservices or small services to build a business, separate modules with different business iteration cycles in a large business, and integrate and orchestrate modules with standardized APIs. Services are integrated in an event-driven manner to reduce interdependence; The measurement construction continuously improves the service SLA (Service Level Agreement, service level agreement) capability.
​

(2) Elasticity
Utilize the characteristics of cloud resources to automatically expand or contract the scale of the system according to business peaks and resource load conditions, and businesses no longer need to perform capacity evaluation and pay-as-you-go.
​

(3) The degree of
In business, you should try to use cloud services instead of owning third-party services, especially the model of maintaining open source software yourself; the design of applications should be transformed into a stateless model as much as possible, and the stateful parts should be stored in the cloud service. The serverless technology system is further adopted to reconstruct the application runtime, so that the underlying operation and maintenance of the software gradually "disappears".
​

(4)
IT facilities need to be continuously managed. Any software and hardware errors in IT facilities must have the ability to quickly repair them to avoid affecting the business. This requires the system to have comprehensive observability, and the content involves traditional logging methods and monitoring. , APM, link tracking, quality of service (Quality of Service, QoS) measurement and many other aspects.
​

(5) Toughness ability
Resilience capabilities include features such as fusing, current limiting, degradation, automatic retry, and back pressure commonly used in servicing, as well as features such as high availability, disaster tolerance, and asynchronization.
​

(6) Automation level
Focus on the agility of the three processes of development, testing, and operation and maintenance. It is recommended to use container technology to automate the software construction process, use OAM to standardize the software delivery process, use IaC (Infrastructure as Code) and GitOps and other automated CI/CD pipelines and Operation and maintenance process.
​

(7) Security capability
Pay attention to the digital security of the business. While using cloud services to reinforce the business operating environment, it also adopts security software life cycle development to make the application comply with security requirements such as ISO27001, PCI/DSS, and level protection. Security capability is a basic dimension and requires attention in architecture evaluation, but it will not participate in scoring.
​

ACNA-S5: Closed-loop architecture continues to evolve

​

The evolution of cloud native architecture is a continuous iterative process. Each iteration has to go through a complete closed loop from corporate strategy and business requirements to architecture design and implementation. The overall relationship (named ACNA-G2) is shown in Figure 2.
​

Figure 2 ACNA-G2: Closed-loop architecture continues to evolve

Let's introduce in detail the key inputs and implementation process of the closed-loop architecture for continuous evolution.

1. Key input
​

1) Enterprise strategy perspective (ACNA-S1): Including digital strategy requirements, technical strategy (especially cloud strategy) requirements, enterprise architecture requirements, etc. It is recommended to quantitatively describe the percentage of innovation efficiency improvement, IT cost reduction value, and risk cost reduction value.
​

2) Business development perspective (ACNA-S2): Including the technical requirements of new services (especially digital services), BI/AI (business intelligence/artificial intelligence) requirements, IoT (Internet of Things) requirements, user experience requirements, etc. It is recommended to quantify Describe the value of business iteration speed improvement, user experience improvement percentage, business development efficiency improvement percentage, etc.
​

2. The key process
​

1) Identify business pain points and structural debt (ACNA-S5-P1): Identify and quantify business pain points (for example, a set of deployments on the cloud, end-to-end observability, etc.); technical debt is based on the specific conditions of each enterprise There are differences, usually including containerization transformation, CI/CD improvement, microservice transformation, old application offline, legacy system integration solution, non-x86 architecture transfer, etc.
​

2) Determine the architecture iteration goals (ACNA-S5-P2): It is recommended that each iteration does not exceed 1 year, and through the OKR (Objective and Key Result) method, the business goals of this iteration are described in the goals. Quantify business value and technical value in key results. Note that when determining the iteration goals, it is necessary to fully identify the stakeholders of the architecture upgrade and their value appeals to avoid situations where the project is very successful but cannot be recognized by the business side.
​

3) Assess architecture risk (ACNA-S5-P3): Risk and value are often a contradiction. Don’t refrain from upgrading the cloud native architecture because of the high risk, and don’t ignore the risk because of the urgent upgrade. It is recommended that the risk and value Get balance. The focus of the P3 stage is to identify risk categories and risk points, which will vary according to the company's industry and the company's own characteristics. Risk categories usually include organizational risk, market risk, technical risk, design and implementation risk, implementation risk, operation and maintenance risk, IT culture risk, financial risk, data risk, compliance risk, etc.
​

4) Select cloud native technology (ACNA-S5-P4): In the P4 phase, the cloud native technology that needs to be used in this iteration needs to be selected from the cloud native technology stack, and the risks and risks that may be caused by the use of this technology must also be selected. Value is the first consideration.
​

5) Develop an iterative plan (ACNA-S5-P5): In the P5 stage, it is necessary to fully consider whether each milestone can be recognized by all participants. It is necessary to avoid the situation of developing behind closed doors and then expecting to produce a high-value product, because Projects like cloud-native architecture upgrades require in-depth cooperation with all participants, and changes to plans and goals are likely to occur during the execution process.
​

6) Architecture review and design review (ACNA-S5-P6): The P6 stage is an important architecture upgrade that changes the entire production line of the enterprise. It requires technical architecture review and important design review, so that important designs can be obtained among the participants. Agree, this is also an important means to reduce the overall risk.
​

7) Architecture risk control (ACNA-S5-P7): After the risk points are determined in the P3 stage, it is necessary to immediately set the monitoring methods and early warning thresholds for these risks, and continuously monitor the changes of these thresholds during the process of architecture upgrade , To achieve real-time risk assessment and early warning. On the whole, during the entire implementation process, companies need to establish a closed-loop risk control of "identification-monitoring-evaluation-early warning-improvement".
​

8) Iterative acceptance and review (ACNA-S5-P8): In order for the next iteration of the cloud native architecture upgrade to be successful, even if this iteration has been successfully accepted, the team needs to objectively and thoroughly review the gains and losses of this iteration Review, especially in soft skills such as organizational capabilities, project and product management capabilities.
​

Cloud native architecture maturity model

​

The cloud native architecture maturity model is an evaluation model that can help companies find the gap between the current software architecture and the mature cloud native architecture, so as to make targeted improvements in subsequent architecture optimization iterations. ACNA refers to the definition of CMM (Capability Maturity Model) and defines the maturity model of cloud native architecture from the main architectural dimensions. We need to note that ACNA’s cloud-native architecture maturity assessment model will not help companies assess from the dimensions of general technical architecture, application architecture, or information architecture, so it does not help implementers sort out the core stakeholders of the architecture and architecture delivery. contract. At the same time, the evaluation model itself does not evaluate the skills of the core team members and the organization's process, culture, and pipeline construction, but evaluates the specific software technology architecture based on cloud-based modern applications. Although the scope of such assessment is relatively small, it is more professional and more maneuverable.
​

In addition, the assessment object of the ACNA cloud native architecture maturity model is not the enterprise or architecture implementers, but the architecture adopted by a specific software. Therefore, for an enterprise, the evaluation result of some software may be zero (initial level), and the evaluation result of some software is intermediate (development level), which depends entirely on the architecture of each software.

6 evaluation dimensions
​

The ACNA cloud native architecture design includes a total of 6 key architecture dimensions (Service + Elasticity + Serverless + Observability + Resilience + Automation, abbreviated as SESORA). Here we first define the maturity level of the key dimensions, as shown in Figure 3 (named ACNA-T1).
​

Figure 3 ACNA-T1: Cloud native architecture maturity model: key indicator dimensions

Combining the four different maturity stages of the cloud native architecture, we defined the maturity model of the entire architecture, as shown in Figure 4.
​

Figure 4 Cloud native architecture maturity model

Implementation guidance and worksheets for the evaluation model

​

The entire workflow of the evaluation model implementation guidance (named ACNA-T2) is shown in Table 5.
​

Table 5 ACNA-T2: Workflow for implementation guidance of cloud native architecture evaluation model

​

In order to unify the output of the ACNA evaluation model, we have given a unified "Cloud Native Architecture Evaluation Form" (named ACNA-T3) to allow users to have a consistent understanding of the results, as shown in Table 6.

Table 6 ACNA-T3: Cloud Native Architecture Evaluation Table

Serviceability assessment

The evaluation of servicing capability (named ACNA-T4-1) is shown in Table 7.
​

Table 7 ACNA-T4-1: Servicing Capability Evaluation Table

Assessment of resilience

​

The assessment of resilience (named ACNA-T4-2) is shown in Table 8.
​

Figure 8 ACNA-T4-2: Resilience Assessment Form

Evaluation of the degree of

​

The evaluation of the degree of serverless (named ACNA-T4-3) is shown in Table 9.
​

Table 9 ACNA-T4-3: Serverless Degree Evaluation Table

Evaluation

​

The evaluation of observability (named ACNA-T4-4) is shown in Table 10.
​
Table 10 ACNA-T4-4: Observability Evaluation Table

Resilience assessment

​

The assessment of resilience (named ACNA-T4-5) is shown in Table 11.
​

Table 11 ACNA-T4-5: Resilience Ability Evaluation Table

automation capability

​

The assessment of automation capability (named ACNA-T4-6) is shown in Table 12.
​

Table 12 ACNA-T4-6: Automation Ability Evaluation Table
​
​

More information

"Alibaba Cloud Cloud Native Architecture Practice" is officially produced by Alibaba Cloud, recommended by Zhang Jianfeng, President of Alibaba Cloud Intelligence, and Cheng Li, CTO of Alibaba; from design principles, patterns/anti-patterns, technical options, design methods, industry cases and other dimensions Comprehensively summarize the methodology and practical experience of Alibaba Cloud's cloud native architecture.

Copyright Statement: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users, and the copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.