Alibaba has accumulated a wealth of experience and lessons by providing Alibaba Cloud based solutions and best practices to help enterprises complete their digital transformation for a large number of enterprise customers across a wide range of industries. Alibaba combines the core focus of the enterprise, enterprise organization and IT culture, engineering implementation ability and other aspects with architecture technology, forming Alibaba’s unique Cloud Native architecture design method — ACNA (Alibaba Cloud Native Architect).
The concept of ACNA
Alibaba has provided Alibaba Cloud based solutions and best practices to a wide range of enterprise customers to help them complete the digital transformation, and has accumulated a lot of experience and lessons. Alibaba combines the core focus of the enterprise, enterprise organization and IT culture, engineering implementation ability and other aspects with architecture technology, forming Alibaba’s unique Cloud Native architecture design method — ACNA (Alibaba Cloud Native Architect). This set of methods in the official Ali cloud recently published the best seller “Ali cloud cloud native architecture practice” has a more detailed introduction.
(1) Role and purpose of ACNA
1) Improve the capability of the R&D team to achieve the objectives of cost, schedule, function and quality. 2) Guide the R&D team to control the process of R&D, operation and maintenance, optimize the IT organizational structure and create a more efficient software engineering process mechanism. 3) Guide the R&D team to select improvement strategies in the process of determining the maturity of the cloud native architecture and locating key issues in the cloud primitive biology.
(2) Implementation steps of ACNA
1) Determine the maturity level of the enterprise’s current cloud native architecture. 2) Understand the factors that will play a key role in improving production quality and optimizing the process. 3) Focus on a limited number of key objectives, so as to effectively optimize the existing research and development process, and then continuously improve the product.
ACNA is a “4+1” architecture design process, where “4” represents the key perspectives of architecture design, including enterprise strategy perspective (ACNA-S1), business development perspective (ACNA-S2), organizational capability perspective (ACNA-S3) and cloud native technology architecture perspective (ACNA-S4). “1” represents an Architecture Continuous Evolution Closed Loop for Cloud Native Architecture (ACNA-S5). The relationship between the four key perspectives and one closed loop (named ACNA-G1) is shown in Figure 1.
Figure 1 ACNA-G1: Schematic diagram of ACNA architecture design process relationship
In addition to being an architecture design methodology, ACNA also includes an evaluation system for cloud native architectures, a maturity measurement system, industry application best practices, technology and product systems, architecture principles, implementation guidance, etc. Other chapters of the book will elaborate on cloud native technology and product systems, architectural principles, best practices, etc. Here, the maturity measurement system and implementation guidance of cloud native architecture are mainly introduced.
ACNA-S1: Corporate strategic perspective
Any architecture must serve the enterprise strategy, and the cloud native architecture is no exception! Upgrade is different with previous architecture, upgrading of cloud native architecture is not only the upgrading of technology, but also to the enterprise’s core business processes (i.e., through building digital business of software development and operations), a refactoring, upgrade the significance of cloud native architecture, as the industrial age with more automated assembly line to replace manual mill as profound.
The enterprise must understand the relationship between the business strategy and the cloud IT strategy, that is, the cloud IT strategy is only a necessary technical support to the business strategy, or the cloud IT strategy itself is part of the business strategy. Generally, high-tech companies will put higher demands on cloud computing, such as providing intelligent user experience through extensive use of AI technology provided by cloud vendors, as well as using IoT (Internet of Things) and audio and video technology to build wider and more vivid connections for users.
In fact, in today’s digital transformation, more and more enterprises believe that Cloud IT strategy should play an important role in the enterprise business strategy of technology enabling business innovation. Cloud IT has become “Cloud First”, or even “Cloud Only”. There are just some differences in the strategy of going all-public versus hybrid. Based on cloud IT strategy, cloud native architecture can help enterprises realize ubiquitous access technology, build digital ecosystem, ensure rapid iteration of digital business from a technical perspective, build digital infrastructure oriented to user experience management, continuously optimize IT costs and 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, fast launch of business, business cost control, and technology enabling business innovation. The business continuity appeal mainly refers to that the digital business must be able to continuously provide services for users, not to make the business unusable due to hardware and software faults or bugs, and to prevent the occurrence of accidents such as hacker attacks, data center unavailability and natural disasters. In addition, when the scale of the business is growing rapidly, the purchase and deployment of hardware and software resources must be timely, so that the enterprise can better reach new users.
The market changes 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 enterprise’s demands for these capabilities and deal with them at different levels such as products, tools and processes. It is important to note that these demands also impose new requirements on the organizational structure, which may require a complete refactoring of the application (such as micro-serviceability).
Cloud computing must unlock a cost dividend for companies, helping them move from the Capex model to the Opec model, where they pay as much as they use instead of buying a lot of hardware and software upfront. At the same time, the adoption of a large number of cloud native architecture will also reduce the development and operation costs of enterprises. Data show that the container platform technology can reduce the cost of operation and maintenance by 30%.
Under the traditional model, if you want to use high-tech enabling services, you will go through a lengthy process of selection, POC, pilot and promotion. However, if you choose to use cloud services provided by cloud vendors and third parties, you can apply new technologies more quickly for innovation. Because these cloud services have faster connection speeds and lower trial and error costs, they also have the advantage of a unified platform and a unified technology dependency on the integration of different technologies.
ACNA-S3: Organizational Competence Perspective
The upgrade of cloud native architecture is a thorough upgrade of the entire IT architecture of an enterprise. When upgrading cloud native architecture, each organization must adapt itself according to the situation of the enterprise. Among them, organizational capability and technology stack are equally important. The upgrade of cloud native architecture involves a huge impact on the development, testing, operation and maintenance personnel in the enterprise. The upgrade and implementation of the technical architecture requires the active participation and cooperation of the relevant organizations in the enterprise. In particular, as the architecture continues to evolve, an organization like the Architecture Governance Board is needed to plan and land the cloud native, and to constantly review and evaluate the deviations between architecture design and implementation.
In addition, the design of cloud native architecture also needs to consider organizational changes. Mentioned a very important cloud native architectural principles of service is (including micro, small services, etc.), the field is a typical principles of conway’s law, for enterprise’s technical architecture and communication architecture must be consistent, otherwise it will lead to deformity of architecture of service, and even lead to organizational communication costs and increased “evasive” phenomenon.
Another important thing to consider is how receptive the organization is to change, or to its ability to make rapid organizational changes and maintain business stability. The upgrade of cloud native architecture requires a large number of enterprise IT personnel to also upgrade the technical system and redesign the post functions, which is bound to cause the technical leaders and low-level employees who were originally in the stable and comfortable zone to have to break and stand again, so the risk of organizational change has to be carefully considered.
ACNA-S4: Cloud native technology architecture perspective
From the perspective of technology architecture, ACNA believes that the architecture dimension contains seven important areas, which are specified below.
(1) Servicalization capability
Build business with micro service or small service, separate modules with different business iteration cycles in large business, and integrate and arrange modules with standardized API, etc. An event-driven integration between services reduces interdependence; Continuously improve Service SLA (Service Level Agreement) capabilities through measurable construction.
(2) Elastic capacity
Leveraging the nature of cloud resources to automatically scale up or down the system based on peak business and resource load eliminates the need for capacity assessment and pay-as-you-go business.
(3) Serverless degree
In business, we should try our best to use cloud services instead of holding third-party services, especially the mode of maintaining open source software by ourselves. The design of the application should be as much stateless as possible, with the stateful parts stored in the cloud service. Serverless technology system is further used to restructure the application runtime, so that the underlying operation and maintenance of the software gradually “disappear”.
(4) Observability
The IT facility needs to be continuously governed. The hardware and software errors in any IT facility should be able to be quickly repaired to avoid affecting the business. This requires the system to have comprehensive observability, which involves the traditional logging mode, monitoring, APM, link tracking, Quality of Service, etc. QoS) measurement and other aspects.
(5) Toughness
In addition to such characteristics as fusing, current limiting, downgrading, automatic retry and back pressure commonly used in serverization, toughness capability also includes such characteristics as high availability, disaster tolerance and asynchronization.
(6) Automation level
Focusing on the agility of the three processes of development, test and operation, we recommend using container technology to automate the software construction process, using OAM to standardize the software delivery process, and using IAC (InfrastructureAs Code). Infrastructure is code) and automated CI/CD pipeline and operations processes such as GITOPS.
(7) Safety capability
Pay attention to the digital security of the business, while using cloud services to strengthen the business operation environment, adopt the security software life cycle development, so that the application meets the security requirements of ISO27001, PCI/DSS, level protection and so on. Security capability is a fundamental dimension that requires attention in architectural metrics, but it will not be scored.
ACNA-S5: Architecture Continuous Evolution Closed Loop
The evolution of cloud native architecture is a process of constant iteration, and each iteration will experience a complete closed-loop from enterprise strategy and business appeal to architecture design and implementation. The overall relationship (named ACNA-G2) is shown in Figure 2.
Figure 2 ACNA-G2: Architecture Continuous Evolution Closed Loop
The key inputs and implementation processes for the continuous evolution closed-loop are described in detail below.
1. Key inputs
1) Enterprise strategic perspective (ACNA-S1) : including digital strategy appeal, technology strategy (especially cloud strategy) appeal, enterprise architecture appeal, etc. It is suggested to quantify the percentage of innovation efficiency improvement, IT cost reduction value, risk cost reduction value, etc.
2) business development perspective (ACNA – S2) : including the technology of pursuit of new business (especially digital business), BI (business intelligence/AI)/AI appeal, IoT (Internet of things) appeal, user experience, etc., and suggested that quantitative describe business iteration speed rise, the user experience improve percentage, percentage of business development efficiency, etc.
2. Key processes
1) Identify business pain points and architectural liabilities (ACNA-S5-P1) : Identify and quantify business pain points (e.g., cloud-on-cloud next-set deployment, end-to-end observability, etc.); Technical liabilities vary from enterprise to enterprise and typically include containerization, CI/CD improvements, microservice modifications, legacy application rollouts, legacy system integration solutions, non-x86 architecture transitions, and so on.
2) Determining the architectural iteration goals (ACNA-S5-P2) : It is recommended that each iteration should not exceed 1 year. The business objectives of the iteration should be described in the goals and the business value and technical value should be quantified in the key results by means of OKR (ObjectiveandKey Result). Note that when determining the iteration goals, the stakeholders and their value demands for the architecture upgrade should be fully identified to avoid the situation that the project is successful but not recognized by the business side.
3) Assessment of architectural risks (ACNA-S5-P3) : risk and value are often contradictory. Don’t avoid upgrading the cloud native architecture because of the high risk, nor ignore the risk because of the urgent upgrade. It is suggested to strike a balance between risk and value. The focus of stage P3 is to identify risk categories and risk points, which will vary according to the industry the enterprise is in and the characteristics of the enterprise itself. 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 the cloud native technology (ACNA-S5-P4) : In the P4 stage, the cloud native technology to be adopted in this iteration shall be selected from the cloud native technology stack, and the possible risks and values caused by the adoption of this technology shall be given priority consideration.
5) Formulate iteration plan (ACNA-S5-P5) : P5 stage need fully consider each milestone to be able to get all the participants, be sure to avoid closed development first and then expect to output a high value product, because like cloud native architecture upgrade project, need to cooperate with the depth of the participants, and likely to change in the process of execution plans and goals.
6) Architecture review and design review (ACNA-S5-P6) : As an important architecture upgrade to change the entire production line of an enterprise, the P6 stage requires technical framework review and important design review to make important designs recognized among all participants, which is also an important means to reduce the overall risk.
7) Architecture risk control (ACNA-S5-P7) : After the risk points are determined in Phase P3, monitoring methods and warning thresholds for these risks should be set immediately, and changes of these thresholds should be continuously monitored in the process of architecture upgrading to achieve real-time risk assessment and early warning. On the whole, in the whole implementation process, enterprises need to establish a risk control loop of “identification, monitoring, evaluation, early warning and improvement”.
8) Iteration acceptance and review (ACNA-S5-P8) : In order to make the next iteration of cloud native architecture upgrade successful, even if this iteration has been successfully accepted, the team needs to review the gains and losses of this iteration objectively and deeply, especially in soft skills such as organizational ability, project and product management ability.
Cloud native architecture maturity model
The Cloud Native Architecture Maturity Model is an evaluation model that can help organizations identify the gaps between their current software architectures and mature cloud native architectures so that they can make targeted improvements during subsequent iterations of architecture optimization. ACNA defines a Maturity Model for cloud native architectures from major architectural dimensions, referring to the definition of the CMM. It is important to note that ACNA’s Cloud Native Architecture Maturity Assessment Model does not help enterprises assess from a common technical architecture, application architecture, or information architecture dimension, so it does not help implementors comb through the architecture’s core stakeholders and architecture delivery contracts. 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 rather from the specific software technology architecture of a modern cloud-based application. Although the scope of such assessment is relatively small, it is more professional and more operable.
In addition, the ACNA Cloud Native Architecture Maturity Model is not evaluated against an enterprise or an architecture implementer, but rather against the architecture adopted by a particular piece of software. Therefore, for an enterprise, some software may be rated as zero (initial) and some as intermediate (development), depending on the architecture of each piece of software.
Six assessment dimensions
The ACNA cloud native architecture design consists of six key architectural dimensions (Service + Elasticity + Serverless + Observability + Resilience + Automation, SESORA). Here we start by defining the maturity levels for the key dimensions, as shown in Figure 3 (named ACNA-T1).
Figure 3 ACNA-T1: Cloud native architecture maturity model: key metric dimension
Combining the four different maturity stages of the cloud native architecture, we define a maturity model for the entire architecture, as shown in Figure 4.
Figure 4 Cloud native architecture maturity model
Evaluation model implementation guidance and worksheet
The entire workflow of the evaluation model implementation guidance (named ACNA-T2) is shown in Table 5.
Table 5 ACNA-T2: Workflow of Cloud Native Architecture Evaluation Model Implementation Guidance
In order to unify the output of the ACNA evaluation model, a unified Cloud Native Architecture Evaluation Form (named ACNA-T3) was presented to enable users to have a consistent understanding of the results, as shown in Table 6.
Table 6 ACNA-T3: Cloud Native Architecture Evaluation Form
Evaluation of Servitization Capability
The evaluation of the servitization capability (named ACNA-T4-1) is shown in Table 7.
Table 7 ACNA-T4-1: Servicalization Capability Assessment Form
Assessment of resilience
The assessment of elastic capacity (named ACNA-T4-2) is shown in Table 8.
Figure 8 ACNA-T4-2: Elastic Capacity Assessment Form
Evaluation of the degree of serverless
An estimate of the degree of Serverless (named ACNA-T4-3) is shown in Table 9.
Table 9 ACNA-T4-3: Serverless degree evaluation table
Evaluation of observability
An evaluation of the observability (named ACNA-T4-4) is shown in Table 10.
Table 10 ACNA-T4-4: Observability Assessment Table
An assessment of resilience
The toughness capability assessment (named ACNA-T4-5) is shown in Table 11.
Table 11 ACNA-T4-5: Toughness Capacity Assessment Form
Evaluation of automation capabilities
An assessment of the automation capabilities (named ACNA-T4-6) is shown in Table 12.
Table 12 ACNA-T4-6: Automation Capability Assessment Form
This article is the original content of Aliyun, shall not be reproduced without permission.