The document discusses the challenges of managing the performance of revenue-critical applications deployed in hybrid cloud, virtual, and physical environments. It introduces AppDynamics as a solution that provides wide and deep visibility into distributed applications. AppDynamics dynamically scales applications in the cloud and other environments, is easy to deploy and use, and provides value quickly. The document also announces the free AppDynamics Lite product.
3. What’s required for Revenue-Critical Apps? Cloud Pre-Production Tools (build, test, deploy, configure) Cloud Production Tools Cloud Platform
4. Production Challenges with Revenue-Critical Apps Production Challenges Dynamic Provisioning Service Level Assurance Inexperience with Hybrid environments Distributed applications Capacity management Trust in Automation Agile = Constant Change Visibility into SOA Apps Horizontal scaling Real-time monitoring
Objective of Slide Thank you and introductions. Time check. Script Thank you for your time today. I look forward to an interactive discussion today on your application performance needs and the chance to present the AppDynamics solution to you. I had this meeting booked from x – y am/pm. Are you still available until then?
Objective of Slide Explain the types of problems we can diagnose. Orient the audience to the 5 components of our solution. Begin to position our binary differentiators. Script This is our “marketecture slide”. On the right, you’ll see the types of events that we can specifically capture and diagnose. We’ve spent a large effort in our 2.0 release in expanding the types of events we can capture –everything from memory leaks, to stalls, to thread contention. Do you see anything in this list that relates to a problem you may have had in the last 12 months? Do you mind telling us a little about it? There are 5 main components of our solution that we’ll walk through in the demo. App Mapping, Policy Engine, Transaction Flow Monitoring, Deep Diagnostics and Cloud Orchestration. As we walk through the demo, we’ll explain which capability fits into each bucket. When comparing our solution to others on the market, it may become apparent that we have solutions in the areas of App Mapping, Transaction Flow Monitoring and Cloud Orchestration where other vendors don’t yet have capabilities.
Objective of Slide Explain the types of problems we can diagnose. Orient the audience to the 5 components of our solution. Begin to position our binary differentiators. Script This is our “marketecture slide”. On the right, you’ll see the types of events that we can specifically capture and diagnose. We’ve spent a large effort in our 2.0 release in expanding the types of events we can capture –everything from memory leaks, to stalls, to thread contention. Do you see anything in this list that relates to a problem you may have had in the last 12 months? Do you mind telling us a little about it? There are 5 main components of our solution that we’ll walk through in the demo. App Mapping, Policy Engine, Transaction Flow Monitoring, Deep Diagnostics and Cloud Orchestration. As we walk through the demo, we’ll explain which capability fits into each bucket. When comparing our solution to others on the market, it may become apparent that we have solutions in the areas of App Mapping, Transaction Flow Monitoring and Cloud Orchestration where other vendors don’t yet have capabilities.
Objective of Slide Build credibility around the customers we already have. Leverage their stories to get the prospect to begin to open up. (Begin discovery) Begin to seed APM 2.0 requirements. Script We’ve been fortunate to have been chosen by some great companies. I’d like to share a couple of their stories with you. Netflix – key points: Netflix.com is a revenue-critical, highly distributed java app. Agile development process with new code introduced every two weeks. Load is constantly increasing as their business grows. All of these factors makes performance monitoring and troubleshooting harder. After an extensive eval over 2 years of Wily, Dynatrace, IBM ITCAM, Precise, Tidal, New Relic and AppDynamics – they chose AppDynamics. If you asked Rob Fagen he’d say it’s because 1) less than 1% overhead in production, 2) built for distributed environments with transaction flow monitoring, 3) deep code level diagnostics with the ability to “find the smoking gun”, 4) works in cloud environments. Many of the competitors didn’t pass their overhead test. EA/Bioware. This is a cool story. They have built a new massive multi-player online Star Wars game. Millions of users can login at the same time and any delay can send these gamers to other sites. They used our solution both in alpha/beta stage to give development feedback on performance and also in production to assure the availability and performance. Gaming companies make a good deal of money as gamers buy extra light sabers and gadgets to enhance their online experience…so it is critical that both the game and the revenue-critical apps operate at light-speed. They selected AppDynamics because of the immediate visibility into performance problems with minimal overhead. Our main user was once the architect of the BMC Patrol product so he was a very informed evaluator. Priceline.com. This is a very complicated distributed application. To serve up the hotel, airline, rental car quotes – priceline.com needs to simultaneously send requests to 50+ partners, collect the responses and present the best deals to their users in a reasonable time frame. If you as the user favor United Airlines or Four Season Hotels…and that response doesn’t come back…you are most likely going to move to a competing website. Our ability to give visibility into multi-threaded application requests and provide immediate feedback was critical to priceline. They told us that no other APM solution could deliver on this functionality. With 120 JVMs, this is a fairly large environment. Do any of these challenges or requirements resonate with you? [Pause] At the appropriate point, we’d be happy to setup a reference call with these customers.
Objective of Slide Recap the discussion with our diffentiators. Script [Note: You don’t need to read each one, speak to the ones that you think are a best fit for the requirements/needs they may have stated during the meeting] D=Distributed apps E=Easy T=Transaction-centric A=Auto-discovers app map W=Wide AND Deep O=Low Overhead B=Baselines S=Scale dynamically DETAWOBS BOATDEWS Boastwed wedboast
