“if it ain’t broken, don’t fix it” is een van de achterliggende oorzaken van het in gebruik blijven van Legacy applicaties. Maar de omgeving verandert, het netwerk verandert. Wat doen deze veranderingen met de (ervaren) applicatie performance en welke rol speelt security hierin?
Als performance tester ervaar ik dat de aandacht vaak wordt gelegd op de voorkant / gebruikers interface van (web)applicaties. De gebruikersverwachting in reactietijd. Maar vaak is deze vertaling moeilijk te maken, van verwachting naar aantal milliseconde(ms). Performance is daarmee bijna een neurowetenschap geworden, hoe reageert het brein op laadtijden.
De ervaren performance kan beïnvloed worden; “user perceived performance”. Dit is vaak te herkennen als een laadbalk of een ‘spinner’ zoals we die ook wel kennen van YouTube, bij het laden van een video. Het geeft een indicatie dat er daadwerkelijk wat gebeurd. Het maakt gebruikers niet uit, uit hoeveel verzoeken een website is opgebouwd, of wat de browser moet doen om de site op te bouwen of voor welke hardwarecomponenten is gekozen.
Wat wel steeds meer aandacht krijgt van gebruikers is beveiliging. Bij het openen van de website van de bank verwachten we dat dit over een beveiligde (gecertificeerde) verbinding gaat en bijvoorbeeld cross-site-scripting tegen gegaan wordt. Zeker moet er gedacht zijn aan alles in de OWASP top-10. Dit alles, natuurlijk zonder het verlies van gebruiksvriendelijkheid. We willen liever niet een apart apparaatje hebben, vervolgens een sms krijgen en daarna een wachtwoord moeten invoeren wat uit bijna onverenigbare combinaties moet bestaan.
Beveiliging gaat verder dan wat het oog ziet aan goedgekeurde certificaten en invoeren van wachtwoorden. Beveiliging verspreidt zich over meerdere delen van het OSI model. Een firewall kan bijvoorbeeld geïmplementeerd worden op de data link, het netwerk, het transport, de sessie en soms de applicatie laag.
Vaak worden verschillende netwerkcomponenten zonder veel testwerk in productie geplaatst, ten behoeve van beveiliging, ondersteuning of onderhoud. Wat is de impact van deze componenten op de performance van de intern- en extern ontsloten applicaties?
Firewalls, ongeacht als fysieke hardware component of de virtuele variant, bevat ook software.
De implementatie van software binnen ieder landschap dient uitgebreid getest te worden op inpasbaarheid en compatibiliteit. Bij, van origine voornamelijk hardwarecomponenten, is dit vaak minder normaal. Naast dat iedere nieuwe firewall (vaak) nieuwe software (versie) bevat, hebben we ook te maken met nieuwe of gewijzigde instellingen.
Zonder dat een firewall aan ‘packet inspection’ doet is het een infrastructureel component, ofwel een ‘hop’ in het netwerk. Een onderdeel waar al het netwerkverkeer doorheen moet en voegt dan al ~0,5ms toe aan ieder pakketje. In de praktijk gaan firewalls vaak gepaard met beveiligingsregels en bedrijfsregels. Hiervoor is ‘packet inspection’ nodig en zal al het verkeer inhoudelijk geanalyseerd moeten worden, dit heeft een negatieve invloed op de performance.
Binnen veel grotere organisaties worden legacy applicaties nog dagelijks gebruikt. Deze applicaties worden vaak niet meegenomen in de afweging om een infrastructureel component te vervangen. Verouderde protocollen zoals DCOM/COM, die gemaakt zijn voor een LAN en niet voor een WAN, worden erg beïnvloed door een extra firewall / hop. De ‘hop’ is elke component die tussen gebruiker en applicatieserver staat.
Uit mijn ervaring in het testen van infrastructurele componenten blijkt dat ieder component een andere impact heeft. Een netwerk wat altijd correct gefunctioneerd heeft op de huidige componenten kan niet tot slecht functioneren op nieuwe componenten, ook door fouten in software van bijvoorbeeld een firewall.
De combinatie van legacy, beveiliging, stijgende gebruikersverwachtingen en vernieuwingen in de infrastructuur zorgen voor een hoop onzekerheden. Performance is een architectonische beslissing, daar hoort infrastructuur ook bij.
