New Relic 2011 WHITEPAPER

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
the future. New Relic is uniquely suited to address these new needs in a cost effective manner that
provides instant time to value for the users of the APM solution.

The Next Generation of Applications Performance Management

Table of Contents

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

VII. About APM Experts......................................................................................................8

© 2010 APM Experts, All Rights Reserved.
All other marks are property of their respective owners. ii


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.

Monitoring Processes and Services
The first generation of APM solutions actually knew very little about the applications themselves. These
solutions were based upon agents running on server operating systems like Unix and Windows Server that
collected metrics about the processes that comprised the applications of interest. These products were able to

All other marks are property of their respective owners. 1


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.

Lack of Visibility into the Actual End User’s Experience
For many organizations, the notification of a problem still occurs with the end user calling up the help desk and
saying “it is slow”. First generation APM solutions typically have no visibility into what happens to end user
experience after a transaction leaves the web server that comprises the edge of the application system. This



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
management system. In fact, just using this kind of communications architecture alone may not suffice as many
enterprises do not allow traffic to enter their networks in a manner that would allow for the agent in a public
cloud to talk to an on-premise monitoring system.



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
presents server resource utilization metrics, including CPU, memory, storage, and network utilization,



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.

VI. About New Relic
New Relic, Inc. is the leading software-as-a-service provider of application performance management solutions
that enable developers and operations teams to quickly and cost effectively monitor, troubleshoot, and tune
application performance in real time. More than 5,000 organizations use New Relic to monitor and optimize



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.


New Relic 2011 WHITEPAPER

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie New Relic 2011 WHITEPAPER

Ähnlich wie New Relic 2011 WHITEPAPER (20)

Mehr von New Relic

Mehr von New Relic (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

New Relic 2011 WHITEPAPER