En vervolgens - zodra alles er goed uitzag - 'in productie genomen'. Dit betekende: in de praktijk door de gebruikers getest. En daar - 'in het echt' - bleek pas echt hoe de applicatie zich gedroeg en dat was vaak heel anders dan vooraf was aangenomen. In ernstige gevallen ging het werk dan terug naar de tekentafel, waarna een nieuwe cyclus begon.

Testen van applicaties

Die luxe kunnen organisaties zich niet meer veroorloven. De 'business owners' willen betere informatie in ieder stadium van de applicatie ontwikkeling en over het gebruik van applicaties. Onder meer deze druk versnelt de vorming van DevOps-teams, waarin de traditionele scheidingswand tussen de functies is opgeheven. In dit nieuw type teams kloppen ontwikkelaars nog steeds code, maar - anders dan vroeger - zij zijn nu ook verantwoordelijk voor het gedrag van hun applicaties in het wild.

Monitoring van dit gedrag is van enorm belang. Hoe houdt de applicatie zich onder een plotselinge grote toeloop van gebruikers? Wat zijn de responstijden? Hoe is de ontwikkeling daarin? Hoe gaan gebruikers met de applicatie om? Zoals vooraf in een aantal scenario's was vastgelegd? Of compleet anders? Het gaat hier om bedrijfskritische informatie. De performance van applicaties kan immers enorme commerciële impact hebben.

APM toen en nu


Van oudsher was APM (Application Performance Management) het domein van de infrastructurele IT, zeg maar de mannen van de productie. Maar deze 'oude IT' is gedwongen te democratiseren. Niet alleen richting de afzonderlijke DevOps-teams, maar naar alle betrokkenen. Het monitoring boek moet niet alleen open, het moet ook sneller op de plank liggen en bovendien zal de tekst telkens herschreven worden.

Alleen het (reactief) monitoren van applicaties en infrastructuur (denk aan CPU, memory en schijfruimte) is bij lange na niet voldoende. Proactief monitoren van het gedrag van een applicatie, de onderliggende infrastructuur en andere applicaties in de keten is absolute noodzaak.

Daarbij kan ook niet meer worden volstaan met het vooraf definiëren van harde grenzen (zgn. static thresholds) waarop een signaal moet worden afgegeven. Met behulp van analytische tools zal het normale gedrag van een applicatie moeten worden bepaald en moet een alarm afgaan op het moment dat daarvan wordt afgeweken.

Hoe je dit doet in een continue ontwikkel omgeving, en dus ook continue monitoring toepast, kun je volgen via ons blog.