Home Architectuur De duivel uit het doosje

De duivel uit het doosje

289

In dit blog wil ik verder gaan met het duivelse dilemma dat we kennen in de ICT, namelijk de uitdagingen in capaciteitsmanagement die door alle complexiteit steeds groter wordt. Want er is misschien een integrale ketenvisie over hoe informatie stroomt, maar de trechter zelf is vaak niet transparant. En dus worden we nog steeds verrast met problematiek van de flessenhals waar een kleine verandering er al voor kan zorgen dat de service als dikke stront door een dunne trechter gaat. Dit omdat de logische waarheid in de architectuurmodellen nog weleens afwijkt van de fysieke realiteit.

In de praktijk kom ik dan ook vele voorbeelden tegen waar tegen beter weten in geprobeerd wordt om uit de breedte te halen wat er in de lengte niet in zit. Zoals een prachtige webfarm waar alle servers afhankelijk zijn van één database. En deze database hangt dan aan de opslag met een ‘rietje’, omdat een verkeerd storageprotocol gekozen is, of omdat er vooraf niet gekeken is wat er precies nodig is aan prestatie, de leessnelheid en schrijven. Opslagcapaciteit in gigabytes kost namelijk niks, maar de prestatie ervan blijft nog steeds duur.

Bij de duivel te biecht gaan

Zonder netwerk geen service, zonder opslag geen data en in dat opzicht is het vreemd dat deze twee onderdelen van de architectuur vaak niet goed gedimensioneerd worden. Een euvel dat niet alleen aan de leveranciers te wijten valt, maar ook het gevolg is van de ‘penny wise and pound foolish’ methodiek waarbij invulling van capaciteitsmanagement aan de leverancier overgelaten wordt. Maar dat is geen nieuws, omdat uit eerder onderzoek van Netforecast al bleek dat er naar de verkeerde indicatoren gekeken wordt als het om applicatieperformance gaat. Er wordt namelijk vertrouwd op de hulpmiddelen van leveranciers welke vooral reactief zijn en zich teveel beperken tot één oplossing. Betreffende capaciteitsmanagement is er dus nog weleens sprake van een catch-22 situatie waar leveranciers graag gebruik van maken.

Nu kiezen inkoopafdelingen de systemen vaak op bedienbaarheid, de ‘eye candy’ van een gebruikersinterface in plaats van beheer(s)baarheid. En dus kan real-time de prestatie bewaakt worden van één doos, maar is het niet mogelijk om er trends aangaande de keten uit te halen. En uitbreidingen geven dan maar even verlichting, omdat het oplossen van de ene bottleneck altijd weer leidt tot een nieuwe. Dat doet me weleens denken aan de problemen die er vroeger waren in logistiek management. Met name de Theory of Constraints van Eliyahu Goldratt die aangeeft dat investeren in zaken die niet een bottleneck wegnemen gewoon een verspilling zijn.

De slimste truc van de duivel

Iedereen heeft het over afstemmen van resources maar in gevirtualiseerde omgevingen steekt niemand hier echt tijd in. Misschien komt dat wel door de opdeling die er vaak gemaakt is in het beheer, de verdeel- en heerstechniek, waardoor menige architectuur uit vele puntoplossingen bestaat. Als gevolg hiervan ziet de storagebeheerder alleen een berg data en niet de waarde hiervan voor de organisatie. Want niet alleen ontbreekt het inzicht in de capaciteit maar ook in de fysieke afhankelijkheden. En dat komt nog weleens pijnlijk naar voren bij het uitvoeren van performancetesten met (kritische) productieverstoringen tot gevolg. Maar ook de databases zelf zijn lang niet altijd efficiënt, net als veel applicaties. Opslag en netwerk zijn tegenwoordig een gegeven waar niemand lang meer over nadenkt. Totdat er onvoldoende bandbreedte is en dingen niet alleen trager gaan maar ook onstabiel beginnen te worden.

Op dat moment wordt de capaciteit op één punt even uitgebreid waarna het spelletje weer opnieuw begint omdat we opslag en netwerk consuMEREN met de verdergaande digitalisering. Want een toenemende hoeveelheid data betekent ook uitdagingen in back-up. En dus kunnen de vijf stappen van Eliyahu Goldratt gelinkt worden aan de problemen die ontstaan. Misschien dat het tijd wordt om wat minder met een technologie focus naar de IT te kijken en meer vanuit de service te gaan denken? Zie ook deze link.

Ewout Dekkinga  Infrastructure Architect  |  S&T  |  ESS RTI bij Unisys 

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in