• <1 minute

Natural Evolution of Application Performance Management

In this post, I’d like to summarize my take on the changes that happened in the APM market and point out the differences between Systems Center Operations Manager, the old VSO version of Application Insights, and our new offering in Azure.

I often hear many questions about the APM products that Microsoft ships. Including, What happened to SCOM APM? There were some killer features in the Visual Studio Online version of Application Insights – why are they not available in Application Insights in Azure? What are the differences between all those products that seem to address a similar problem? In this post, I’d like to summarize my take on the changes that happened in the APM market and point out the differences between Systems Center Operations Manager (SCOM), the old VSO version of Application Insights, and our new offering in Azure.

Application Performance Management is not a new field. There have been many companies long before Microsoft entered the market. Most notably, Wily Technology defined most of what is now known as APM. Through the mid-2000s, the focus was mainly on application health and availability. Many enterprises run big Java environments and Wily was a perfect fit for helping Ops teams to gain visibility into custom Line-of-Business applications. However, the increased adoption of the agile development techniques in the late 2000s made the IT need a more dev centric approach to eliminate the wasteful interactions between dev and ops when problems occur in production.

Number  of companies have started around that time, most notably NewRelic, AppDynamics, dynatrace and AVIcode. All of them while having different “secret sauce” had one core thing in common: they all had a “magical agent” that Ops can install on a production server to get transaction information, failures, perf metrics and other application telemetry that would help detect and troubleshoot operational problems. Magical agent was an ideal approach at the time with no changes to the code, operation personnel could provide developers with deep failure or performance latency information with runtime data to troubleshoot the issue. This approach was working miracles when the APM focus was still on health that can be relatively easily defined as detecting application failures and degradation in responsiveness.

Fast forward another 5 years and we see huge changes in the industry. Proliferation of cloud, mobile and IoT devices triggered the entire new set of processes around Continuous Delivery, A/B testing etc. that is now called DevOps. Amount and complexity of telemetry required caused the shift from traditional APM into Application Analytics space. The focus is finally shifting from the “how my app is doing” towards “how my customers are doing”. And this shift is not a minor tweak. In traditional APM, measuring performance is relatively standardized. But in the area of user engagement, what you want to know about a typical Amazon customer and her experience is totally different than Angry Bird customer. When you want to know how version A is better than version B it is not about if version A is slower or failing: it’s about what experience the user is having.

This brings an interesting pivotal point to APM. The initial value companies are getting from out-of-the-box “magic” is being quickly eroded by the amount of custom coding required to operationalize and tailor the data to measure application success.

At Application Insights we’ve embraced these new trends and made number of decisions:

  • Application Insights serve cloud, device and on-premises apps: Application Insights can collect telemetry equally well from device apps and cloud apps, as well as services hosted on-premises. By contrast, SCOM focuses predominantly on ASP.NET on-premise apps.
  • Application Insights is SaaS: Our SDKs send all app telemetry into our service in Azure. This is different from SCOM where all telemetry data is stored on-premise.
  • Developers: You  get the most power from Application Insights by using its API to send telemetry that you design to measure the success of each feature or user story. OK, there is also out-of-the-box telemetry that you don’t have to code; and you can even add monitoring at run time if you need to. But these are additional nice features, rather than the core of the service. This is different from both SCOM and VSO AI where most of the data from services application was coming from Microsoft Management Agent that provided “magical” byte-code instrumentation.
  • Application Usage: business success in many cases directly related to the app it runs on. This is more than just the availability number. If nobody came to your 100% reliable service who cares? Application Insights combines various telemetry about health and customer usage data to get comprehensive view on how your app helps your business to succeed. This is the area where Application Insights in Azure is definitely stands out from the VSO version and SCOM. With recent acquisition of HockeyApp that brought advanced iOS and Android telemetry collection capability, support for multi-dimensional metric analysis and correlated searching capabilities it really drives home 360-degree view of application telemetry data.
  • Open Source: we’ve embraced open source world. We published our SDK’s as open source projects and welcome your contributions. It’s up to us all to make them better!

In the next post I will cover the differences between traditional run-time/byte-code instrumentation and the SDK-based approach.