The Virtualization Practice

Transcription

1 The Virtualization Practice White Paper: Application Performance Management for the modern Agile and Cloud worlds Bernd Harzog Analyst Performance and Capacity Management The Virtualization Practice July The Virtualization Practice. 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 Python, 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 deployment of rapidly evolving applications onto dynamic and distributed infrastructures 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. VMware 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.

2 Table of Contents I. Introduction Application Performance Management... 1 II. Current Approaches to APM... 1 Monitoring Processes and Services... 2 Synthetic Transactions... 2 HTTP Protocol Analysis... 2 Java and.net Byte Code Instrumentation... 2 III. New Challenges in APM... 3 Proliferation of Applications... 3 Scaled Out (not Up) Deployment Models... 3 Distributed (Cloud) Deployment Models... 3 Proliferation in Tools, Platforms, and Languages... 4 Dynamic Operating Environments... 5 Agile Development... 5 IV. DevOps and AppOpps... 5 Devops and APM Tools... 5 Application Operations (AppOps) and APM Tools... 5 V. Summary... 6 VI. The VMware vfabric APM Solution... 7 VII. About VMware... 8 VIII. About The Virtualization Practice... 8 All other marks are property of their respective owners. ii

3 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. The two most important of these metrics are response time of transactions of interest, and the throughput for combinations of large numbers of transactions and the associated batch and background tasks. 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. All other marks are property of their respective owners. 1

4 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 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. The problem with this approach is that it knew nothing about the actual transactions that users were running in the applications of interest, and therefore provided no data meaningful to users and owners of applications. 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. The problems with synthetic transactions are; 1) You cannot script ever thing that and end user needs to do in an application, 2) You cannot script how users misuse applications, and 3) Once you become an agile shop you will no longer have the time to update your scripts every time you do a release. 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). The problem with this approach is that its visibility is limited to the HTTP layer of the application system, and can therefore not help diagnose problems that lie in the application and database layers of the application system. 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.. All other marks are property of their respective owners. 2

5 III. 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. 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 All other marks are property of their respective owners. 3

6 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. All other marks are property of their respective owners. 4

7 Dynamic Operating Environments Increasingly, modern applications are deployed in virtualized, private cloud or public cloud environments. In the case of virtualized and private cloud environments workloads of various priority and criticality from one enterprise may be sharing the same infrastructure. In the case of public clouds, workloads from many different companies are relatively certain to be sharing the same infrastructure. In both cases the shared and abstracted nature of the infrastructure makes it impossible to infer the performance of applications by looking at infrastructure resource utilization statistics. Therefore when applications run in these environments it is imperative that their performance (response time and throughput) be measured directly by an APM solution that is deployed by and managed by the application owner. Agile Development The unrelenting pressure to deliver more application functionality in less time has given rise to a revolution in the process by which software is developed and updated. Agile Development focuses upon having one small team of developers 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). The combination of Agile Development, scaled out deployment models, distributed deployment models and dynamic/shared execution environments (virtualization) 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. Furthermore these comprehensive views of applications must be automatically and continuously updated by tools as the applications and their supporting environments change. IV. DevOps and AppOpps Devops and APM Tools Many of the above criteria come into play when organizations are using DevOps techniques to manage custom applications deployed in production. The most critical of these criteria are the requirements that APM tools not require manual instrumentation configuration as the applications change (as with agile they change very frequently), and that the APM automatically discover the topology of the application system (as with a dynamic deployment platform and auto-scaling that topology will change frequently and rapidly). Application Operations (AppOps) and APM Tools Data from The Virtualization Practice research shows that less than 5% of the important business applications in production in enterprises worldwide are being managed by an APM solution today. This is because the first generation of developer focused APM solutions are just focused on custom applications and were so difficult and expensive to use that organizations chose to use them only for the most critical and painful of their custom developed applications. And it is also because tools have not until recently existed that made it practical to manage a broad set of application at a reasonable cost and for a reasonable amount of effort. All other marks are property of their respective owners. 5

8 There is a new variant of DevOps which is increasingly being known as Application Operations or AppOpps. AppOpps is all about managing every application in production for end-to-end response time. The need for AppOpps is being driven requirements on the part of application owners to have better visibility into application performance when applications are running in virtualized environments or private clouds. Managing every application in the enterprise for end-to-end response time introduces a set of very unique challenges that traditional developer oriented APM tools cannot meet. Every application includes purchased applications for which the enterprise does not have the source code making a tool that treats the code as the thing to be managed inappropriate. Every application often includes applications developed with tools like C, C++ and VM that predate the modern application runtime environments supported by the modern developer focused APM vendors. For the above reasons, AppOps focused APM tools cannot count on just an agent inside of a Java JVM, or a.net CLR as the collection mechanism for the APM data. Data must be collected either from an agent in the OS or from the TCP/IP network. V. Summary Historically, APM tools have been used for a very small fraction of the important applications in enterprises. It is now imperative that a new generation of tools be developed, brought to market and deployed for the following reasons: 1. New applications are being put into production and then changed at a faster pace than ever before. 2. These new applications are being deployed in scaled out, distributed environments, often spanning multiple internal data centers, and internal/external clouds 3. These applications are being run in dynamic and shared environments either on internal virtualized infrastructure or in public clouds with infrastructure shared among multiple customers. 4. Moving business critical applications to dynamic and shared infrastructures will not work unless the owners of those applications receive assurances regarding the performance and availability of those applications. 5. For the above reasons, all important applications, irrespective of their source (purchased or custom developed), and irrespective of how they were built (old or new tools), will need to be monitored with an APM solution. 6. This will require a new generation of APM solutions that are both specifically designed to be able to monitor a broad range of applications, and that understand the ramifications of applications running in dynamic and shared environments. Current tools that focus just upon Java,.NET, or other modern custom application development frameworks do not meet this need. 7. VMware vfabric APM is uniquely suited to meet this need due to its breadth of application support, and its integration with the rest of the VMware vsphere product line. All other marks are property of their respective owners. 6

9 VI. The VMware vfabric APM Solution VMware vfabric APM is an Application Operations (AppOps) focused APM solution specifically designed to address the modern challenges mentioned directly above. vfabric APM starts with a unique data collection approach that collects application performance data from three different vantage points: An OS agent resides in the Windows or Linux OS. This agent is based upon the widely installed and in use Hyperic Agent. This agent collects application performance data from the perspective of the operating system, and is particularly useful in helping determine when OS and system level resource constraints are impacting application performance A virtual appliance that accesses the vsphere vswitch through a virtual mirror port. This virtual appliance is able to see (on a read only basis) all of the TCP/IP traffic flowing in between guests on a host and in and out of the host upon which it resides. vfabric APM includes layer 7 protocol decoders for the popular web (HTTP), middleware (Java and.net) and database protocols (SQL Server, Oracle, and MySQL). Therefore this component of vfabric APM can construct an end to end topology map and calculate end-to-end response times for all applications running on a vsphere host irrespective of their source (purchased or custom developed) and irrespective of when or how they were built. An agent inside the Java runtime or JVM. This agent provides for deep instrumentation of code and call stack analysis for custom developed applications. This agent is self-configuring and unlike legacy first generation Java solutions does not require instrumentation changes when the application changes making it an ideal choice for Agile shops who are rapidly evolving their applications. The combination of these three data collection approaches is found only in vfabric APM. Therefore vfabric APM is the only APM solution that is appropriate for both Application Operations where every application needs to be automatically supported, and Developer Operations needs where Java developers using Agile techniques are rapidly and frequently changing custom applications in production. vfabric APM is also unique in how it integrates with the rest of the VMware product family. vfabric APM integrates with vfabric AppDirector, allowing monitoring to be configured at the time that the application system template is constructed so that monitoring is automatically and appropriately instantiated when the images that comprise the application system are started. vfabric APM is also integrated with the vsphere platform, allowing for example a component of an application to be automatically rolled back to a previous image if it is determined that a new release of that component is the source of a response time or throughput problem. VFabric APM 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. No firewall ports need to be opened anywhere on the customer or cloud provider side to make the VFabric APM work. All other marks are property of their respective owners. 7

10 VII. About VMware VIII. About The Virtualization Practice The Virtualization Practice is an industry analyst firm focusing upon data center virtualization and cloud computing. Bernd Harzog is TVP s Analyst for Performance and Capacity Management 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 All other marks are property of their respective owners. 8