Hoe vaak heb je het adagium 'IT moet zichzelf schikken naar de wensen van de business' al gehoord? Het is een van die clichés die erg logisch klinkt, maar in de praktijk lastiger is uit te voeren dan je vooraf zou denken. Wij geven je wat inzicht in de manier waarop IT van waarde kan zijn voor missiekritische applicaties door gebruik te maken van een nieuwe generatie application performance management (APM) technologie.
In de afgelopen vijf jaar is er een radicale verandering ontstaan in de manier waarop zakelijke applicaties worden gebouwd. De applicaties van vandaag de dag zijn fundamenteel anders opgebouwd door service-orientated architecture (SOA), open-source, agile ontwikkeling en nieuwe ontwikkelplatforms. Ook is IT verhuisd van het fysieke datacenter naar virtuele servers en cloud-omgevingen. Gebouwd voor piekbelasting wordt vervangen door capaciteit on-demand, troubleshooting gecentreerd rond developing maakt plaats voor troubleshooting gericht op operations.
In een niet zo ver verleden functioneerden zakelijke applicaties nog monolitisch. Alle code werd uitgevoerd op een grote applicatieserver en alle data bevond zich in een enkele database. Als er iets misging, kwam je al snel uit bij ‘the usual suspects’. Vandaag de dag is dat wel anders, nu veel applicaties afhankelijk zijn van internet. Een zakelijke transactie wordt in veel meer stappen (hops) voltooid dan vroeger. Dat betekent voor de diagnose van een probleem dat je de transactie moet kunnen volgen terwijl het verschillende systemen op verschillende apparaten passeert.
Om de prestaties van je zakelijke transacties te kunnen meten, moet je weten waar wat plaatsvindt en wat de impact van de transactie op de afzonderlijke component is. Dit gaat verder dan controleren of hardware nog functioneert; het gaat over het volgen van transacties op meerdere locaties, begrijpen hoe lang data ergens verblijft en nagaan of de prestaties van applicaties overeenkomen met historische gegevens.
Het inspecteren van pakketjes op het netwerk is niet voldoende om bovengenoemde vragen te beantwoorden. Netwerktools bieden geen ondersteuning voor de volledige details op transactieniveau. Dit komt doordat ze niet kijken in de code van een applicatie. Anders gezegd: ze zijn niet ‘application aware’. Omdat je niet kunt managen wat je niet kunt zien, moet je anno 2010 heel andere tools gebruiken om een samengestelde applicatie te kunnen monitoren.
Een tool die je daarvoor kunt gebruiken is AppDynamics. Deze next-generation APM-oplossing laat zakelijke transacties van begin tot eind volgen, zowel over fysieke, virtuele als cloud-infrastructuur. AppDynamics biedt live visualisatie van de transactieflow, waardoor je precies kunt zien hoe prestaties per tier zijn. Via groene/oranje/rode indicatoren kun je snel zien waar het probleem zich bevindt. Een rode indicator spoort aan tot actie. Het probleem kan zich dan zowel in de sfeer van operations (bijv. uitval van hardware) als applicaties (bijv. slecht geschreven code) bevinden. AppDynamics dicht het gat tussen IT-operations en de ontwikkelaar.
Buiten de juiste tool bestaat er ook nog zoiets als APM 2.0. Dit zijn de best practices rond performance management in de complexe omgevingen die we vandaag de dag tegenkomen. Ik noem ze hieronder.
APM 2.0 tools moeten worden gebouwd voor samengestelde applicaties. Een APM 2.0 oplossing zou een visueel overzicht moeten tonen om applicatietopologie voor IT-operations inzichtelijk te maken. Een techniek als ‘application mapping’ toont alle applicatietiers en back-end services, ook al wordt door toepassing van agile development nieuwe code toegevoegd. (Dit verschilt met oude applicaties. Tegenwoordig worden applicaties vaker geüpdate. In plaats van jaarlijks soms zelfs wekelijks.)
Een APM 2.0-tool zou moeten draaien rond het proces van de zakelijke transactie. De tool moet meten wat er voor de business toe doet, namelijk de transactie. Niet langer is het meten van infrastructuur en de gezondheid van afzonderlijke componenten van de applicatie voldoende om kwaliteit van service te garanderen.
Een andere best practice is een tool gebruiken die je voorziet van uitgebreide diagnostiek. Een APM 2.0-oplossing moet diagnostiek bieden op detailniveau. Zulke tools moeten je in staat stellen om problemen te herleiden naar de bron en mogen niet meer dan twee procent overhead met zich meebrengen.
Maak policies voor de tools die je gebruikt. Bijvoorbeeld, maak een policy van het feit dat je het afrekenen van een bestelling niet langer dan twee seconden wilt laten duren. Om vals alarm te voorkomen, moet je APM 2.0-oplossing weten wanneer een overschrijding wordt veroorzaakt door slechte performance of dat het gaat om een incident dat voor de algemene transactietijd geen gevolgen heeft. De tool moet leren van historische patronen en deze vergelijken met de huidige performance.
Een APM2.0-oplossing zou zowel cloud-deployed applicaties moeten kunnen monitoren en ingezet moeten worden om elestic computing mogelijk te maken. Het beste is om ‘cloud orchestration’ toe te passen. Hiermee kan jouw bedrijf op een intelligente manier opschalen en naar beneden schalen wanneer nodig.
Conclusie: applicaties en omgevingen worden steeds complexer. Een goede APM 2.0-tool helpt zowel IT-operations als developers vooruit om IT te schikken naar de wensen vanuit de business.
Linda Musthaler is analist bij Essential Solutions Corporation