APM Experts
White Paper:
Application Performance Management
– Crossing Platforms, Languages and
Deployment Models
Bernd Harzog
CEO – APM Experts
November 2011
© 2010 APM Experts. All Rights Reserved.
All other marks are property of their respective owners.
Abstract
First generation APM solutions were designed to address the performance of a limited set of applications built with a limited set of tools and deployed around a constrained and largely homogeneous deployment model. For example, these solutions typically only addressed applications built with Java and .NET and deployed on a relatively few large-scale application servers.
A variety of technical and economic trends have rendered the first generation APM approach inadequate in addressing the reality of how applications are built and deployed today. Today’s applications are built using a variety of tools including Java, Ruby, .NET and PHP and are deployed in scaled out open source server farms internal to the enterprise, and across public and private clouds. Additionally, the demands for new application functionality and enhancements to existing functionality have led to development and support methodologies like Agile Development and DevOps that create rapid changes to application systems in production.
The combination of these trends has created a new set of requirements that first generation APM tools are not able to meet and that must be addressed with tools built for today’s realities and directions of
I.
Introduction – Application Performance Management...1
II.
Current Approaches to APM...1
Monitoring Processes and Services ...1
Synthetic Transactions ...2
HTTP Protocol Analysis...2
Java and .NET Byte Code Instrumentation ...2
III.
Flaws in Traditional Approaches to APM...3
Deployment Model Assumptions ...3
Cost to Acquire ...3
Cost to Own and Time to Implement ...3
Breadth of Applicability ...3
Lack of Visibility into the Actual End User’s Experience ...3
Lack of Infrastructure Visibility...4
IV.
New Challenges in APM ...4
Proliferation of Applications ...4
Agile Development, “DevOps” and “AppOps” ...4
Scaled Out (not Up) Deployment Models ...5
Distributed (Cloud) Deployment Models...5
Proliferation in Tools, Platforms, and Languages...6
V.
The New Relic Solution...6
VI.
About New Relic ...7
I.
Introduction – Application Performance Management
There are many aspects of managing the performance of an application system from end-to-end so that proper service levels are provided to the users of these applications. Application Performance Management (APM) focuses upon the application as the key layer in the technology stack responsible for delivering results to end users. APM focuses upon the performance of the application and the resulting business services that are provided to the end users of these applications. Since a major focus of APM is to ensure that the end users of the application or business service are having an acceptable experience, APM focuses upon the most important set of metrics – those that directly measure the quality of service that the users of an application are
experiencing when using that application.
APM is different from, but synergistic with products that focus upon the performance of the infrastructure of applications. Infrastructure performance management solutions are primarily focused upon the availability and resource utilization profile of the hardware and software resources that underlie the applications. These tools are important for identifying structural issues with a network or hardware system and are widely deployed by IT teams with large datacenters and by hosting and infrastructure providers.
Historically, APM solutions have taken an “inside the firewall” approach to determining the boundaries of the application system. Two new trends are causing leading edge APM solutions to expand these boundaries. Deploying applications across private and public clouds means that APM solutions need to be able to work no matter how the application system is distributed. There is also an increasing emphasis upon expanding the notion of “end-to-end” from just looking at the web server to the database, to including the actual experience of the end user in the definition of “end-to-end”.
One of the critical functions provided by APM solutions is to determine the root cause of issues impacting service quality. Modern APM solutions do a great job of finding issues directly in the application code.
However, finding issues in the infrastructure that supports the application often requires cross-correlating data from many disparate products in blamestorming meetings, and still remains a significant challenge in many organizations.
II.
Current Approaches to APM
While APM in one way or another has been applied to computer systems for as long as business critical applications have been running on computers, the APM category of solutions formally came into being as monolithic mainframe and mini-computer applications evolved into client/server and later web-based applications. The distribution of application functionality across many servers and tiers of servers, while beneficial from a cost and scaling point of view, increased the complexity in managing these applications and thus gave rise to the APM discipline.
tell if the application was running or not (process or service was up or down), and whether or not the resource utilization profile of the application was within normal bounds. When resource utilization spiked, it was then inferred that something abnormal was occurring and that an investigation was warranted.
Synthetic Transactions
Once the Internet and the World Wide Web arrived, the emergence of online business to consumer (B2C) and business to business (B2B) ecommerce created a compelling need for organizations to understand the performance (response time and availability) of web-based customer facing applications. The first set of solutions to this problem emerged out of the products that were used to test the performance and reliability of these web-based applications. These testing tools were modified to run synthetic transactions from outside of the company against the web servers that comprised the presentation layer of these application systems. To this day, services still exist whose primary purpose is to ensure that web-based applications are available to constituents in various geographies.
HTTP Protocol Analysis
HTTP protocol analysis solutions are attached to mirror or span ports on the switches that serve the web server tier of these application systems. Since all of the traffic flowing through the switch is forwarded in a read only manner to the mirror port, these appliances could “see” all of the HTTP traffic flowing through all of the web severs attached to that switch.
These products then analyzed the HTTP traffic and provided response time data for granular (or atomic) HTTP request/responses and could also be configured to measure the response time of complex compound
transactions (a complete transaction in the eyes of the end user). The combination of HTTP appliances with byte code instrumentation products addressed a substantial portion of the APM requirements for the applications built in the first decade of the Internet (from 1995 through about 2008).
Java and .NET Byte Code Instrumentation
APM achieved its first level of sophistication as a monitoring tool with the introduction of Java and then later J2EE based application servers. This was an extremely important innovation in the history of application architecture as it split applications into three distinct tiers: web servers, app servers, and databases. These three tier architectures morphed into N-tier architectures with multiple layers of J2EE servers providing different levels of business functionally and later morphed into service-oriented architectures.
The creation of substantial business logic functionality on J2EE and .NET platforms gave rise to the need to manage these complex and distributed applications. First generation byte code instrumentation solutions were brought to market from vendors like Wily Technology (who later led the market for this generation of
solutions). These products were unique in that for the first time it was possible to get visibility into what was occurring inside of the application while the application was running in production. This level of application visibility and manageability made it possible for massive amounts of business critical application functionality to be implemented within the application server, since it was now possible to actually manage these systems effectively in production.
III.
Flaws in Traditional Approaches to APM
Byte code instrumentation solutions combined with HTTP appliances were able to address the APM requirements of first generation Java and .NET, however these solutions were appropriate for applications written to only one set of application architectures (Java and .NET) and around a fairly narrow set of deployment options and use cases. This makes first generation APM solutions problematic in several areas.
Deployment Model Assumptions
The first generation of business critical applications that were written to Java and .NET were typically
extremely complex applications involving many business rules and large amounts of code in one instance of the application. These applications were therefore deployed on relatively few application servers that tended to be very large and very complex pieces of hardware and software. The tools to manage these applications were then built around this assumption – that there would be, in any organization, relatively few Java and .NET application servers per application and that these servers would themselves be scaled up as much as possible in terms of CPU count and memory size.
Cost to Acquire
As Java and .NET became new enterprise software businesses, so too did the tools to manage them. Direct sales forces sold Java application servers at six and seven figure price levels, and the tools to manage these applications were sold to the enterprises on a similar basis and at similar price levels. Therefore this era of application development and management used application platforms and management tools that were very expensive to acquire.
Cost to Own and Time to Implement
The total cost of ownership for this generation of Java and .NET applications was not limited to the software’s licensing and support costs. While APM tools were frequently capable of instrumenting these Java and .NET applications to a very fine-grained level of detail, the choice of what exactly to instrument was a manual process for each transaction in each application. In many cases it took 4 to 6 months of professional services provided by the tool vendor to get the product configured to monitor the exact set of objects and methods in the application that was of interest to the customer. The APM tool’s complexity limited the number of
applications that could benefit from the solution within an organization. Further, the tool’s inflexibility caused organizations to incur significant ongoing costs as each application change or enhancement caused the
instrumentation to be reconfigured as well.
Breadth of Applicability
Byte code instrumentation and HTTP protocol management solutions were able to provide a high degree of application management functionality—but only for a small subset of applications for which the enormous overall cost could be justified. Additionally, these solutions could not address the explosion in tools and languages that occurred in the 2008 – 2010 timeframe. Traditional APM solutions have therefore become limited to a small subset of the total applications in use and currently in development.
leads to a dramatically impaired troubleshooting processes as the application support team first tries to find out if the problem is “inside the firewall”, and then has no tools to further investigate the problem if it is not.
Lack of Infrastructure Visibility
For years, the monitoring of applications and the monitoring of the supporting infrastructure have been separate domains, supported by separate products, and used by separate teams; teams that only talk to each other when forced to do so by a problem being addressed in a blamestorming meeting. The only way to technically integrate these disparate data sets was to apply extremely expensive and complicated statistical correlation technologies to the data from all of the products, a process that was and is too expensive and time consuming for many organizations.
IV.
New Challenges in APM
Existing APM solutions were built around a set of assumptions that are in many cases no longer true today. These solutions assumed that the application was going to get built or bought and then run inside of the firewalls of the enterprise data center. They assumed that applications were going to get built in Java or .Net, which were for a while the dominant development environments used by developers. They assumed that the average application would only get enhanced once or at most twice a year. These assumptions and many others turned out to be no longer valid as a new wave of innovation addressed both how to build applications and how to deploy them.
Proliferation of Applications
The increasing and unlimited demand for new application functionality and an ever-growing backlog of unaddressed application development and enhancement requests in enterprises of all sizes has resulted in the need for increased developer team efficiency. Organizations have responded to this issue in various ways. Many have adopted new tools that allow for applications to be built more quickly, while others (either officially or unofficially) have sanctioned or tolerated “user developed” or “departmental” applications. The bottom line is that when a business area of a company needed some application functionality and they found that they could not get it from the central IT development organization due to backlogs and priorities – they built it themselves in whatever tools happened to match the skill sets on hand. This led to an astounding proliferation of applications within enterprises worldwide with many enterprises reporting that they now have 1500 to 2000 applications that they consider “business critical”.
Agile Development, “DevOps” and “AppOps”
The unrelenting pressure to deliver more application functionality in less time has given rise to other important trends: Agile Development as a development methodology and DevOps as a methodology for managing
applications in production.
Agile Development focuses upon having one developer responsible for each component of an application system, and then having those developers work as a self-coordinating team to deliver new functionality into production on regular and short time intervals (every week, two weeks or at most a month).
DevOps is about eliminating the walls between application development and production application support – essentially creating one team that builds the application and supports it in production.
Application Operations, or AppOps is a variation of DevOps that focuses upon having a dedicated team that is responsible for supporting the application in production, and that coordinates closely with the actual development team.
The combination of Agile Development, DevOps, and AppOps creates a set of requirements that first generation APM tools cannot meet. These tools simply have too much administrative overhead and are too costly to keep up with the pace of change in these new agile environments. Organizations now require a true end-to-end view of their applications, and a top-to-bottom view of their application stack (including the supporting
infrastructure) in order to be able to assure service quality in these rapidly changing environments.
Scaled Out (not Up) Deployment Models
The continued improvements in the price/performance of commodity Intel based servers along with the emergence of lower cost open source alternative application platforms like Linux, JBoss Application Server, and Apache Tomcat means that it is now much less expensive to have large numbers of “smaller” commodity servers than it is to have a small number of high end servers that maximize CPU count and memory size. The economics of commodity hardware and open source application platforms have made it inexpensive to scale server farms out not up. The combination of agile development, modularized software, and scaled out deployment models means that we now have application systems that run on hundreds and in some cases thousands of interconnected servers instead of just a few very large and expensive boxes. This creates another requirement that the first generation of APM tools are not designed to address. They are not designed to support application systems comprised of hundreds or thousands of servers, nor are they priced and sold in a manner that makes their purchase economically feasible for this deployment model.
Distributed (Cloud) Deployment Models
When Amazon launched its public cloud offering (EC2) the first users were developers and organizations who wanted to rapidly prototype and test new applications without having to provision internal resources (either themselves or through their IT departments). Since then, several other public cloud infrastructure and platform providers have come into being (Engine Yard, Google AppEngine, Heroku, CloudFoundry) and many more cloud providers are expected in the near future. This raises another set of issues that first generation APM solutions are completely unequipped to address. The main issue is that first generation APM solutions are designed to assume that the agents that monitor the JVM’s in the application servers are residing on the same LAN subnet as the management system for the APM solution, and that the management system for the APM solution can poll the agents for their data.
These architectural assumptions on the part of first generation APM solutions are invalid for applications where all or a part of the application resides in a public cloud. In the case of an application that resides in a public cloud and the monitoring system resides behind the enterprises firewall it is not possible for the monitoring system to poll the agents in the cloud. To address this use case, the APM solution needs to be redesigned from scratch around the assumption that the agents are autonomous and that they initiate communications over public internet protocols like HTTP and HTTPS through commonly open ports like 80 and 443 to the back end
Many cloud providers offer capabilities that automatically provide computing resources as needed to allow for dynamic scalability during traffic bursts and indeed, this is one of the key benefits of cloud computing— capacity when you need it, automatically. Ensuring the performance of business-critical applications however, remains the responsibility of application owners. The rise of the public cloud has therefore created the need for an APM solution that can work seamlessly in an “out of the box” manner for applications that are
distributed across servers running inside of the enterprise network and servers running in various public clouds. The rise of cloud bursting or the ability to dynamically add instances of an application as workload increases creates the need for an APM solution that can dynamically and automatically recognize and start monitoring new instances of applications as they are instantiated, no matter where they are located.
Proliferation in Tools, Platforms, and Languages
While first generation APM tools did a great job for Java and .NET applications running on a small number of servers deployed inside of an enterprise’s network, that is not the world we live in today.
Today we live in a world of tremendous diversification of platforms, tools and languages. We have gone from having two primary application deployment platforms (Windows and Linux) to having a variety of cloud platforms and infrastructures such as those offerd by Amazon, Microsoft, VMware, Salesforce and others. We have also experienced a tremendous level of innovation and diversification of development tools and
languages. Not long ago it was a world characterized by HTML, Java and the .NET languages (C# and VB.NET). Now, we have these languages plus Ruby on Rails, PHP, AJAX, JavaScript, Groovy, and Python and even PowerShell scripts. It is clear that the pressure to build new application functionality and rapidly enhance existing applications is not going to abate, and will in fact continue to increase over time, driving the continuous evolution of new tools, platforms and languages that keep pace with this need.
Since first generation APM solutions were only designed to address a very limited subset (Java and .NET) of the current and likely future set of tools, platforms and languages, these tools are not equipped to make the jump into deployment environments and development environments of the present or the future. A new method of application performance management is sorely needed—one that is architected for use in virtual or physical environments, supports applications developed in multiple languages, is cost effective, implements rapidly and is easy to use.
V.
The New Relic Solution
New Relic is a next generation APM solution built around the following core principles:
• Support for multiple languages and platforms. New Relic supports applications written with and deployed
to the following tools and platforms; Ruby on Rails, Java, .NET, PHP and Python. Additional tools and platforms will be added on an ongoing basis.
• New Relic provides a true “end-to-end” view of the application system’s performance. New Relic monitors
directly from the end user’s browser and system, through the network between the end user and the application system, and extends all of the way through the web, application and database tiers.
• A true “top-to-bottom” view of the entire application stack and its supporting infrastructure. New Relic
directly in the context of the applications, components and transactions consuming the server resources; allowing for the first time a deterministic view into how infrastructure issues are impacting business transactions - all from within a single tool.
• Real User Monitoring (RUM). New Relic provides detailed views into Browser performance—page load time,
page rendering time, DOM processing, etc—allowing app teams to determine if performance issues are in the front end, versus the middle tier or external services.
• Rich monitoring of application performance (response time) at the individual transaction level with tracing
through the entire stack of application functionality down to individual application components, classes, methods, etc. including the calls into the backend database.
• New Relic is an APM system that is delivered via a Software as a Service (SaaS) model. The backend
management and data storage components of the service are hosted and managed by New Relic,
eliminating the need for customers to purchase or manage any of the infrastructure required to implement and maintain an APM solution.
• Affordable subscription pricing. New Relic is offered via a variety of subscription and usage based pricing plans that make the acquisition and use of New Relic considerably less expensive than first generation APM solutions that were sold using a traditional enterprise software licensing model.
• Easy to use and out of the box functionality. New Relic works when you first install it with no configuration required. The customer establishes an account on the New Relic web site and then points the agents that the customer installs on their servers to their account. Detailed configuration for individual objects and methods is completely unnecessary.
• Distributed deployment architecture. New Relic is built from the ground up to assume that applications run
on servers in distributed geographies and across servers owned by different organizations with different networks. Agents running inside of application servers initiate communications over public Internet friendly protocols to the backend monitoring system hosted by New Relic. No firewall ports need to be opened anywhere on the customer or cloud provider side to make the New Relic service work. The New Relic service has been adopted by tens of thousands of organizations around the world to manage applications deployed in dedicated datacenters, public and private clouds, and in hybrid environments. The solution was architected from the beginning to work seamlessly regardless of deployment environment. It is the first APM tool delivered as a service, which eliminates many of the costs and complexities of traditional APM implementations yet doesn’t compromise functionality. It is the first APM tool to support multiple languages— Ruby, Java, .NET, PHP, and Python and provide a single interface for managing them.
New Relic meets all the requirements of next-generation APM and sets a very high standard for functionality, ease of use and ability to keep pace with today’s rapid deployments.
more than 100,000 production application instances. New Relic also partners with leading platform and hosting vendors including Amazon AWS, Blue Box Group, Brightbox, Engine Yard, Eucalyptus, GigaSpaces, GoGrid, Grid Gain, Heroku, Joyent, Microsoft Windows Azure, Red Hat, RightScale, SpeedyRails, Stax Networks and VMware.
VII.
About APM Experts
Bernd Harzog is the CEO of APM Experts™, a consulting and analysis firm focusing on the virtualization infrastructure and application performance management markets, vendor strategies in these markets, and customer use cases in these markets. Bernd was formerly a Gartner Group® Research Director focusing on the Windows Server® operating system, CEO of RTO Software, and VP of Products at Netuitive®, and has been involved in vendor and IT strategy since 1980.
