Why Do We Need Architectural Visualization?
Every time a microservice architecture is changed, it becomes more complex. Frequent architectural changes may lead to huge differences between the actual architecture and the expectations. Because of these changes, it is difficult for architects or system operations and maintenance (O&M) personnel to accurately remember the composition and interaction of all resources and instances.
In addition, some undesirable features may be introduced during the dynamic evolution of system architectures, such as strong dependence, insufficient local capacity, and over-coupling. These factors bring about significant security threats to the system stability. Therefore, whenever we perform system transformation, business expansion, and stability management, we need to sort out the system architecture to present the interaction between each component beforehand. Architectural visualization can help us clearly identify problems that exist in our architecture, and ensure our system is highly available.
An architecture diagram shared by Daniel Woods when he talked about microservices
Architectural visualization brings about advantages in many aspects, including:
- System Boundary Determination
A good architecture diagram should clearly indicate various system components, and the core call relationships between them. The collection of these components determines the processing boundary of the system. The boundary of a system architecture also reflects the boundary of the business domain to some extent.
- Architectural Problem Identification
Based on the high-availability principle, a visual architecture diagram can help us assess possible security risks, for example, the system robustness in disaster tolerance, isolation, and self-healing dimensions. Second, some architectural link visualization tools (such as Yingyan) have greatly helped developers efficiently troubleshoot and locate problems during their actual work.
- System Availability Improvement
With the upstream and downstream dependency graphs of the system architecture diagram, developers can quickly locate the source of the problem according to data dependency in the case of fault, greatly reducing the mean time to repair (MTTR). With the help of the architecture diagram, we can sort out the strong and weak dependencies in the system. We can either downgrade the weak dependencies during service peak times, or perform fault simulation for each component that the system depends on. By doing so, we can evaluate the reliability of the system as a whole in the case of local faults.
Common Architectural Visualization Practices
Many familiar architecture diagrams exist in static PowerPoint slides. While we may still be using these legacy architectural diagrams, they are often outdated after significant architectural changes. Using an outdated architecture diagram may lead to misunderstanding of the online architecture. We need to constantly update the view of the system architecture in our minds to be sensitive to any architectural changes. Big promotions or major system transformations happening each year provides us with opportunities to sort out and re-recognize the system architecture. Then we may use various tools to view the distribution of various system components, and the internal and external dependencies they have. This is the mostly commonly used method to sort out an architecture diagram. We may call it the “manual drafting method”.
People may want to use automation through technology to improve the efficiency of manual work — for example, the commonly used event-tracking-based microservice visualization solutions. These type of solutions are mainly used in the monitoring fields, such as distributed tracking and appliance performance management (APM). An architectural visualization solution for an ARM product in the app dimension is as follows.
We call this visualization method the “event-tracking-based architectural awareness method”. For this type of method, the identification of architecture components relies on core class detection and event tracking.
This solution has some drawbacks:
- Language Dependence
As long as system event tracking is involved, the language-related features cannot be ignored. We have to provide different dependency packages for different languages.
- Difficult Maintenance
Because this method heavily relies on the detection of the core classes, when the component package undergoes a major update, this update needs to be synchronized.
- Difficult Scalability
It is a client-side identification solution. After the client is released, the support for new components can be implemented only after users update the client.
- Limited Scale
Another drawback of client-side identification is that the performance is limited by the algorithm. However, server-based identification can efficiently achieve more accurate recognition results by using more powerful tools such as big data analysis.
There is also an automated architectural awareness visualization method. We call it the “unbounded architectural awareness method”. It is a language-independent architecture identification solution. It uses the basic data of the metadata, monitoring data, and network data of processes and containers on a user server to create the architecture diagram on the server.
Other Options for Architectural Visualization
In order to minimize the cost to visualize users’ architecture, we use a non-intrusive way to visualize the microservice architecture. By collecting the process data and network interaction data, and then establishing the network interaction relationship between the processes, we are able to create the architectural diagram of microservices. Users only need to install our Application High Availability Service Agent (AHAS Agent) to do architectural visualization. For Alibaba Cloud native microservice systems, the AHAS Agent is installed automatically without user logon.
How to Make Architectural Visualization More Effective?
We also believe that the effectiveness of architectural visualization is related to the level of human cognition. The focus of architectural visualization should consider whether the product better supports top-down methods, bottom-up methods, or a combination of both. Developers are more concerned with the app-level architecture, but architects or managers are more concerned with the overall system architecture. Therefore, different architectural visualization perspectives need to be provided for users at different levels.
The ideal architecture diagram needs to support both macro and micro dimensions. Currently, our architectural visualization product is designed with multi-layer perspectives, including the process layer, container layer, and host layer. Later on, we may include more layers, such as the region layer and service layer.
The three-layer architecture of a microservices application deployed on Alibaba Cloud ECS visualized by AHAS Agent is as follows:
- Dealing with Architectural Changes
No system architecture of a technology company is static. Instead, the system architecture evolves continuously with system version iterations. Therefore, an architectural visualization product must also support automatic update of the architectural information over time, as well as backtracking. In our architectural visualization product Architectural Awareness, the default architecture diagram automatically refreshes over time. It also supports backtracking. You can select a historical timestamp to view the architectural information at that time. This can be very useful when you want to identify any problems that may violate the high-availability principle before or after the release of a major update, or when you troubleshoot dependency problems that should not have occurred.
- The Core of Architectural Visualization
The core of software architectural visualization is to find meaningful and effective perspectives of the elements in the software architecture, as well as the relationships between these elements. We believe that a good software architectural visualization product should help users filter out unimportant information and provide them with valuable views. This is particularly important for microservice architectures that have large and complex interaction relationship chain scenarios. The key points are “meaningful” and “effective”. To achieve these two points, we first need to identify what elements and relationships are meaningful and effective. What we do in this field is to “identify”. Basically, we identify each process running on a user server, the program that initiates remote calls, and so on. When we are clear about these elements, we have a reasonable basis to judge whether an element is meaningful to a user and how important it is to the user’s architecture.
- Element Identification in Architectural Visualization
After sorting out a large number of architectural diagrams, we find that most users care about the following three categories of elements: 1. The users’ own app services; 2. External resources that these apps rely on; 3. Information about the server. Typically, external resources that an application depends on are other applications and general middleware (or storage services). Therefore, we divide the processes that need to be identified as application services and common component services (such as Redis and MySQL). Component services are further divided into user-built services and services provided by public cloud. The identification of cloud services is particularly important for cloud native applications.
- Currently, Architectural Awareness supports identification of 20 Alibaba Cloud services and 21 common third-party service components, such as MySQL, Redis, and Tomcat. The library of supported components is still expanding. The goal is to identify all elements of an architecture as far as practically possible.
- The topology for components (Nginx and Redis) and Alibaba Cloud services (MySQL and AHAS) identified by Architectural Awareness
- The topology for the request flow and monitoring information of a node
- The overview of some processes of hosts identified by Architectural Awareness
What Else Can We Do with Architectural Visualization?
Architectural visualization is not an end in itself, but a means of achieving high system availability. Architectural Awareness collects the architectural data and identifies user components (MySQL, Redis, Message Queue, and so on are collectively referred to as “component”). Based on the component and the matching fault library, Architectural Awareness automatically reminds users of the possible faults for each of these components.
- We also provide an assessment service that can be used in conjunction with Architectural Awareness. This combination allows users to easily simulate and practice against each type of faults, in order to improve the robustness of the system. In addition, Architectural Awareness identifies Java applications. If the load of a Java application is high, we have a throttling service (Alibaba open source Sentinel Commercial Edition) that can be used in conjunction with Architectural Awareness to safeguard the continuous availability of the application.
Throttling Configuration by Using Architectural Awareness
The positioning of AHAS is a data analysis-based high availability assurance product that is designed to help cloud native systems achieve high availability. Architectural visualization is a window for efficient O&M and control. We hope to build an application-centric operation and maintenance integrated platform based on the extensive cloud native data system and the visualized and easy-to-operate architecture diagram. In the future, we will strengthen the integration with other cloud services, such as Alibaba CloudMonitor and Alibaba Cloud Container Service, to enrich the dimension of Architectural Awareness. In addition, we will invest more energy in deep data mining and intelligent consumption, to truly make data a core asset of enterprises, and make data effectively ensure business stability.