Shulou(Shulou.com)05/31 Report--

What are the three major problems that traditional APM causes developers to collapse instantly? aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

If you are responsible for creating or managing customer-facing applications for your business, there will be a long list of things to worry about. For example, recently, enterprises have launched a new version of the application, but customers have found serious problems in production, and excessive delays in the application are undermining their user experience. At this point, you remember that it's too late to use APM to solve some of these problems. Your clients have already complained directly to the company and expressed dissatisfaction with social media, and your management team will ask, "how did this happen?"

This nightmare scenario can be experienced by even the best companies in the world. For example, Google found that traffic fell by 20%, while search pages were generated half a second longer. Amazon found that for every 100 millisecond delay, sales fell by 1%. If even these giants could be victims of production application problems, it could happen to anyone.

Relying solely on traditional APM methods may expose enterprises to three key areas of risk:

Unable to identify performance problems as soon as possible

Unable to diagnose root cause of performance problem

Unable to fix performance problems in time

Discover performance problems

One of the biggest problems in managing application performance is whether performance problems can be found as soon as possible, and the answer for most enterprises is no. In fact, 75% of developers report cases where performance problems affect end users in production, and APM solutions are traditionally designed to work only in production.

Traditional APM is not built for the test phase, and although traditional APM usually focuses on production environments, some enterprises try to use them in the early stages of development and testing. They often find that these indicators and reports are invalid at these stages. Production-centric APM will provide statistical analysis of application performance, essentially a summary of thousands of transactions. This may help to point out significant issues that affect performance, but in the absence of any transaction details, it can be a very vague indicator.

Developers and how code changes will affect overall performance are two separate things. There is still a situation in many companies where developers are not directly linked to the performance of the applications they build. Developers build the application and put it into production operations team, when the team finds a problem, they will report back to the development team for repair.

The DevOps campaign urges companies to extricate themselves from this dilemma by creating a large virtual team and transferring some functions and responsibilities from operations to development.

But even in the DevOps environment, we can still see a lot of testing going on, and most APM tools are aimed at operational or performance experts. Because of this, developers do not feel ultimately responsible for delivering code as long as functional requirements are met. This creates a little disagreement between the development and operations teams, and it is still difficult to find performance issues. To span these two teams, developers should have more insight into and influence the performance of the applications they are building. Today, production-centric APM does not give developers such capabilities.

Diagnose the source of performance issu

Once an application problem is found, it becomes tricky to diagnose the root cause of the problem. This is an increasingly difficult task as you move from a development process to a production process. Teams that test late will be forced to diagnose performance problems that are occurring in complex infrastructure and scenarios. In fact, 86% of the root causes are application-level issues that will be reflected in the development environment and consistent with the environment. Therefore, it makes sense to capture these application-level issues as early as possible when it is easier to find the root cause.

Once the application is in production, it is a small part of a large and complex system. It's no longer just the work of the application, it's about all the technologies around the application, from the network infrastructure to the distributed system. A study by Dynatrace found that, on average, a single transaction uses 82 different types of technologies, which makes trying to diagnose the source of performance problems in production like looking for a needle in a haystack.

Because of this complexity, it is difficult to accurately diagnose the root cause of the problem, most of the problems have not been really solved, but simply repaired. To make matters worse, hasty delivery of repairs often leads to other problems, which become more and more serious with each passing day.

As mentioned earlier, traditional APM is high-level enough to tell you that there is a problem and point out the general areas affected. Their purpose is to monitor incredibly complex infrastructure, so general health reports are very useful in operational team production scenarios. However, traditional APM is not important for development teams that want to diagnose the root cause of the problem because they do not provide a detailed root cause analysis. When a problem is detected and a report is created to pass it on to the development team, it may be necessary for performance experts using other toolsets in a phased environment to take actionable data.

In general, application problems can be conditional and difficult to reproduce, and problems may be related to the customer's deployment environment, which complicates problem fixes.

Fix performance issu

This is the most exposed area of traditional APM because the problem is ultimately solved by developers. Production-centric APM is not consistent with developers' daily workflows, so adoption by the development team is a challenge. Developers are already dealing with tight deadlines and product pressures, so the complexity of traditional APM is not worth their time figuring out how to get actionable data.

Most importantly, in the development environment, traditional APM is considered to be absolutely overkill. After all, they are developed for operation and have many features that developers do not need. These APM solutions only point out the general direction of the problem, but do not provide low-level data demos to meet the problem-solving needs of developers. Therefore, enterprises often encounter the following problems when solving traditional APM problems.

No repair validation is available. Setting up and configuring traditional APM on the development machine is a big task with little rewards, as they do not provide features that help isolate, fix, and test problems in the development environment. Traditional APM cannot provide developers with immediate feedback, so they can see how code changes affect the performance of the application they are working on.

In order to verify bug fixes, the development team must wait for deployment to the production phase. If bug exists, the repair test cycle can be very expensive in terms of time and business impact. The long feedback loop between the code owner and the performance of the production problem complicates the fix.

Fixing defective code often involves the developer of the code, and because it usually takes several months for the development code to be released to the development environment, developers do not see the problematic code until they have written the code. At this point, you may not be familiar with the code, while other code may have been built on top of the problematic code, making it part of a large code base. Hundreds of customers may be affected in the time it takes to research, copy, and solve problems.

Tips

The way most companies currently deal with performance management has been broken. When you wait for production to solve application problems, your customers will find them before you do them. When you feed back the problems found in production to the development team to solve, if you start to solve the problem in the development phase or test phase, it will take longer and cost more. Every team, especially one that DevOps focuses on, should carefully study how to improve the speed of finding, diagnosing, and resolving performance problems.

If you don't test early, the customer will become your tester. If you put real users on product code that has not been tested for performance, this is a good choice for losing customers.

Traditional APM is built for operation, essential for production, but not built for developers to test and develop. Instead, developers need to look for APM tools built specifically for development and testing and shift the toolset to a development-centric solution as soon as possible.

The answers to the three major questions about what caused developers to collapse instantly by traditional APM are shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more relevant knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.