Applicaties groeien niet mee met hun omgeving

IT infrastructuren worden gemoderniseerd en de meeste applicaties migreren succesvol mee. Maar sommige applicaties vertragen juist, zij profiteren niet van de vooruitgang. Er worden voorstellen gedaan om de problemen op te lossen in de infrastructuur, maar deze blijven liggen vanwege de investeringen die ermee gemoeid zijn en omdat ze niet passen in de nieuwe architectuur. In vrijwel alle gevallen wordt de patstelling tussen gebruikers en IT organisatie doorbroken met escalaties en eindigt het verhaal met één of meer onvoorziene stelposten op de exploitatiebalans. Dit soort situaties is eenvoudig te voorkomen wanneer uitzonderingen tijdig onderkend worden.

Door Marcel Wigman, performance architect bij Ymor

Applicaties zijn beperkt toekomst-proof

Een applicatie wordt ontwikkeld om optimaal te kunnen presteren op een bepaald soort technische omgeving en voor bepaald gebruik. Maar IT infrastructuren hebben de laatste jaren grote veranderingen ondergaan omwille van flexibiliteit en beheersbaarheid. Virtualisatie, centralisatie van storage, multi-site en cloudoplossingen zijn gemeengoed geworden. Bepaalde veranderingen pakken echter nadelig uit voor de prestaties van sommige applicaties. De methoden en technieken die tijdens de ontwikkeling van de applicatie door de ontwikkelaar gekozen zijn – en dus vastliggen in de applicatie – kunnen tot performance problemen leiden wanneer de software gebruikt wordt in een omgeving waarin andere regels gelden. De ondergrond groeit en evolueert, maar applicaties groeien niet mee. Dit is een belangrijke oorzaak voor het ontstaan en groeien van performance problemen.

Generieke omgevingen zijn een utopie

Infrastructuur architecten en beheerders zijn geneigd te denken in generieke oplossingen waarin alle applicaties draaien. Er wordt een ‘enterprise architectuur’ geformuleerd die voldoet aan gangbare moderne normen. Om ook in de toekomst te blijven voldoen wordt gesteld dat er geen uitzonderingen mogen worden gemaakt op de gekozen standaard. Anderzijds stellen softwareleveranciers vast dat de nieuwe omgeving voldoet aan de eisen die ooit opgesteld zijn, de omgeving wordt tenslotte sneller. Maar niet alle afhankelijkheden die een applicatie heeft met haar omgeving zijn goed vastgelegd. Gevoeligheden van een applicatie en bijbehorende do’s en don’ts zijn zelden goed gedocumenteerd. Vooraf wijst niets er dus op dat er problemen gaan ontstaan, dit blijkt pas na implementatie. Applicaties kunnen meestal niet worden aangepast, er zal dus een uitzondering moeten worden gemaakt op de nieuw gekozen IT architectuur.

Applicatie versus infrastructuur en andersom

Ymor doet regelmatig onderzoek naar de oorzaak van performanceproblemen en komt dit soort situaties geregeld tegen. De oplossing is vaak eenvoudig, maar de aanbevelingen stuiten op principiële bezwaren. Niet de implementatie van de oplossing maar de discussie over principezaken zorgt voor langgerekte trajecten die uiteindelijk, soms na jaren, toch gerealiseerd worden. Dit had eenvoudig voorkomen kunnen worden door al in de ontwerpfase van de nieuwe infrastructuur architectuur ruimte te reserveren voor veilige alternatieve voorzieningen en dit mee te begroten.

Voorbeelden van oorzaken van vertraging

  • Ingewikkelde routering: Applicatiecomponenten die intensief met elkaar communiceren kunnen onevenredig veel hinder ondervinden van toegenomen complexiteit van infrastructuur tussen de applicatiecomponenten in. Niet alleen fysieke afstand tussen de componenten, maar ook complexe routering van verkeersstromen en autorisatie kunnen onverwachte problemen veroorzaken. Deze problemen kunnen eenvoudig worden opgelost door verantwoorde alternatieven toe te staan op de routering van verkeer tussen componenten of het verplaatsen van componenten in de omgeving;
  • CAD/GIS pakketten en VDI: Kaart- en tekenpakketten stellen hoge eisen aan de grafische afhandeling tussen de machine waarop het pakket draait en het beeldscherm van de gebruiker. Wanneer deze pakketten draaien in een gecentraliseerde omgeving zoals Citrix, ontstaan gegarandeerd problemen. Hiervoor zijn goede maar ook kostbare oplossingen verkrijgbaar die beter vooraf begroot kunnen worden;
  • Afschaffen van de C-schijf: Wanneer een applicatie rekent op de hoge beschikbaarheid van een opslagmedium, kan de introductie van gedeelde netwerkshares problemen introduceren. Er zijn gevallen bekend waarin exorbitante investeringen gedaan zijn om vast te kunnen houden aan het ontwerpprincipe. Het had beter geweest om vooraf een verantwoord alternatief te introduceren waarmee de totale architectuur kon blijven voldoen aan de normen.

Kortom: onderken issues tijdig

Een applicatie groeit niet mee met de onderliggende en doorgroeiende IT-omgeving. De architect zal daarom voorzieningen moeten treffen om problemen die voortvloeien uit specifiek applicatiegedrag, te voorkomen. Het is raadzaam om de beheerders van een nieuwe omgeving instructies mee te geven waarmee uitzonderingen netjes kunnen worden ingepast zonder de architectuur geweld aan te doen. Dit betekent wel dat de verwachte besparing voor hardware, schaalbaarheid en veiligheid van een nieuwe omgeving mogelijk minder groot is dan in een ideale situatie. Met een realistische kijk op de toekomst wordt een wildgroei van ad-hoc oplossingen en daarmee samenhangende uitgaven voorkomen.

 

Lees ook:

Sorry, comments are closed for this post.

Meer weten? 

Neem contact met ons op voor een vrijblijvend adviesgesprek: