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 van dagen 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’ met een verkeerd storage protocol gekozen is of omdat er vooraf
niet gekeken is wat er precies nodig is aan prestatie, de snelheid van het
lezen 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 applicatie performance 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. Maar misschien
komt dat wel door de opdeling die er vaak gemaakt is in het beheer, de verdeel
en heers techniek en menige architectuur bestaat uit puntoplossingen. Als
gevolg hiervan ziet de storagebeheerder alleen berg data maar 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 performance testen met (kritische)
productie verstoringen tot gevolg. Maar ook de databases zelf zijn lang niet
altijd efficiënt, net als veel applicaties. Maar 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 spelletje weer opnieuw begint omdat we opslag en netwerk
consuMEREN met de verdergaande digitalisering. Want een toenemende hoeveelheid
data betekent ook uitdagingen in backup. En dus kunnen de 5 stappen van Eliyahu
Goldratt kunnen 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?
Geen opmerkingen:
Een reactie posten