1. Paul Pantazis, Manager IT/OPS

2.  17 years of IT experience  Started as a DEV but saw the light ( Then DEVOPS ruined the whole thing for me)  Pure ops [ well define pure ] last 10 years  Different industry verticals same problems [ DoD, DoE, Entertainment Industry ]  Can be reached via e-mail: apostolos.pantazis@gmail.com apostolos.pantazis@gmail.com  Currently employed as a IT Manager in the Entertainment Industry sector – specifically production services & software – employer to remain anonymous as to keep the attorneys out of this …

3.  Well, its slow they said..  The idea of slow also changed depending on the individual you spoke to ( perception vs. reality)  Dev  to ops ( some mumbling about the effect of a hypervisor on “nice Java apps”..)  OPS  Dev what a mess as you can imagine..  Either way customers usually pay the price  We had to do something…

4.  Java,.NET some C  Jboss, Mule ESB, MQ, Citrix  Multiple Relational backend technologies: SQL Server, DB2 etc.  Java Swing, Spring, EJB’s, Adobe Air  Linux, windows  Multi-tiered/”distributed” apps (multiple intersystem integrations )

5.  Ability to triage and pinpoint bottlenecks (High Level )  Ability to “dig-deep” really identify Root Cause and facilitate remediation's from there – Also do it fast.  Stop finger pointing and actually solve problems  Incorporate groups in the problem solving process typically not able to contribute (more information on the escalations)

6.  Track and Troubleshoot specific Transactions end to end  Alerting ( not the usual OPS “stuff” )  Generate response time, load, % normal, slow, stall  Error reports for monthly products ops review meetings  Dig into the database  Daily transaction analysis to gage general health of the app, especially after major releases or when users complain of slow system performance

7.  Started a RFP to look at Market leaders in the space  Needed something that was easy to setup and install  Needed immediate “fix”  Needed a vendor who will strategically partner with us  Needed a tool that did not have a basic level steep learning curve  Needed a platform that was intuitive to both DEV/OPS and Business folks alike (in other words views of the data can be abstracted and represent at the various levels of understanding)

8. We Bought the product! ( if you are interested we looked at a number of other APM tools but seriously nothing really compared or came close )

9.  E-mail chain around 200 messages deep  Kids crying in the background (not really but I think you get it)  You typically end up with something like this

13. Because we are working on solving the problem not pointing fingers …

14. Lets Look at some pretty pictures

15. WTF!!!

26. ““Measure twice; cut once” is a phrase carpenters say to prevent mistakes. The same is true with our App_D experience. By measuring the performance of our applications in development, make adjustments and then continue to do so in production, we used App_D to directly impact customer satisfaction in a positive way. App_D is our tool we use to measure performance, analyze the results and in a closed-loop manner take immediate action to continuously keep performance high. Ensuring applications remain available and fast is a great way to keep customers happy.”

27.  Monitoring endpoints that are shared between applications  Application using multiple Databases on the same instance ( particularly with SQL server )  You will need to spend sometime setting up and configuring the tool to your exact needs – even though you will get useful and intuitive data of the gate

28. Questions?? > /dev/null