Het lijkt wel of we steeds proberen uit de lengte te halen wat er in de breedte gewoon niet altijd in zit. Zo proberen we applicaties die nimmer ontworpen waren voor virtualisatie en gedeeld resource gebruik toch in het keurslijf van standaardisatie te drukken met bijvoorbeeld Remote Desktop Services. En hiermee maken we van de eerdere correctieve ‘ctrl-alt-del’ gewoonte een preventieve door elke nacht servers te herstarten.
Nu is regelmatig herstarten van een server natuurlijk niet slecht, twintig jaar geleden moest ik dit ook al wekelijks doen voor de mainframe om zodoende de aangebrachte wijzigingen actief te maken. En nu veranderen dingen natuurlijk sneller dan ze vastgelegd worden maar mijn tablet herstart ik desondanks met een veel lagere frequentie, meestal als ik vergeten ben deze op te laden. Het is dus best een rare ‘Best Practice’ om servers te herstarten omdat er onopgeloste problemen met applicaties zijn.
Log-a-ritme
Zolang alleen naar functionele oplevering gekeken wordt en geen rekening gehouden wordt met overdraagbaarheid, efficiëntie en onderhoudbaarheid blijven we dus achter de feiten aanhollen.
Universele oplossingen blijven hierdoor knellen met het maatwerk dat er nodig is, waardoor relatief kleine veranderingen grote impact hebben op de gevoelswaarde van ict. Zo wordt met Agile software ontwikkeling nog onvoldoende gekeken naar aspecten die de mogelijkheden voor Root Cause Analysis in de keten verbeteren. Dat laten Coding Cowboys nog steeds over aan het implementatieniveau waardoor preventief herstarten een begrijpelijke ‘Best Practice’ wordt. En zoeken naar de bottleneck is er ook niet eenvoudiger op geworden met de dynamiek van virtualisatie en load balancing. Het heeft veel gelijkenis met het spel ‘Whack-a-mole’ omdat de nodige informatie in logfiles simpelweg ontbreekt.
Door ontbreken van gegevens over bezetting en belasting worden de verschillende lagen van de infrastructuur zoals netwerk, opslag en servers op basis van vuistregels gedimensioneerd. Maar met de zwaarte die aan de factoren gegeven wordt is hier geen sprake van een lineaire schaal waarmee gewogen wordt. Eerder een logaritmische omdat goedkoper, flexibeler en betrouwbaarder moeilijk tegen elkaar afgezet kunnen worden.
Lengte x breedte
Lagen van de architectuur zoals applicaties, servers, netwerk en opslag vormen samen dan wel een keten maar het beheer hiervan is dikwijls opgedeeld naar techniek. En dus kunnen we wel precies zien welke resources en hoe zwaar deze belast worden binnen de verschillende lagen maar niet door wie. En horizontaal schalen, door de server farm te vergroten zal een bottleneck in andere lagen natuurlijk niet oplossen. Zo wordt de end-to-end response, welke gewoon een optelsom van de prestaties van alle lagen in de infrastructuur is, nog steeds gemeten aan de bovenkant. Reactief dus via gebruikers die klagen over trage applicaties en hangende terminal servers bijvoorbeeld. En hoewel er geen gebrek is aan beheertools is het hierbij net als met de examens waar tachtig procent altijd gaat over dat ene boek dat je niet hebt gelezen. Gelukkig zijn deze steeds vaker multiple choice en wie gokt komt dus al een heel eind.
Virtualisatie gecombineerd met load balancing geeft dus ook meerkeuze oplossingen waarbij we onmogelijkheden direct kunnen doen maar wonderen altijd wat langer blijven duren. Zo kunnen we problemen in applicaties isoleren met Virtuele Desktops (VDI) zodat geheugen lekken niet leiden tot verstoringen. Maar dit lost niet problemen in de andere lagen op en dus krijgen we weer nieuwe uitdagingen zoals ´boot storms´ als er herstart moet worden.
Oud-er(n)-dom
Hoewel hier geschetste problemen natuurlijk niet exclusief zijn voor gecentraliseerde desktop omgevingen zijn deze hier het sterkst herkenbaar. In aangeboden applicatie set zitten namelijk nog weleens erfenissen uit de tijd van Windows 95, oplossingen die ooit gemaakt zijn op basis van dezelfde principes als Agile software ontwikkeling. Gebruikers maakten met Pascal, Visual Basic en andere programmeertalen applicaties voor de eigen afdeling. En natuurlijk werd er niet gedacht aan overdraagbaarheid, rekening gehouden met multiprocessors, 64-bits adressering, gedeeld resource gebruik of alle andere technologische vernieuwingen. Dat deze generatiekloof voor problemen in de race om resources kan zorgen is ook niet nieuw. Het is eerder een telkens terugkerend probleem omdat techniek gewoon sneller veranderd dan de applicaties.
Met desktop virtualisatie kunnen we de levensduur van applicaties verlengen maar dus niet het geheugenbereik verbreden, de interne werking efficiënt verbeteren en keten beter afstemmen. Met het stapelen van oplossingen blijven we proberen uit de lengte halen wat er in de breedte gewoon niet in zit.
In een reis naar verre oosten kwam ik een keer een oude kruidendokter tegen. Hij beweerde dat zijn spul alle ziektes en kwalen kon genezen!
Hetzelfde verschijnsel doet zich op deze site voor! Heb je probleem met je applicaties, is de efficiëntie van je ict afdeling laag, heb je behoefte aan BYO of andere nieuwe technologieën, zijn de kosten van je ict te hoog, loopt je business achter op je concurrenten etc etc, daar hebben we een oplossing voor: “ CLOUD ”
@Ewout: Vandaag wordt nog steeds de legacy van morgen gemaakt, legacy is een cyclus en elke applicatie heeft zijn “herfst”. Virtualisatie is momenteel een belangrijke peiler van cloud computing en ik weet dat je veel kan en weet van virtualisatie en ook van cloud computing.
En je artikel is wel goed, maar door al die woordspelingen en dubbelzinnigheden maakt dat de leesbaarheid slechter.
Cloud computing is geen delivery model, saas, paas en iaas zijn delivery modellen.
Cloud computing is geen oplossing in zichzelf. Je kunt niet vragen; zullen we voor ERP pakket kiezen of voor cloud?
Uiteindelijk draait het om de applicaties en om data.
@PaVaKe: Software op specifieke apparaten vallen in mijn ogen buiten deze discussie. Een apparaat is een onderdeel in een ecosysteem en ontlenen hun waarde uit hun functie. Dat daar legacy op draait is logisch, net als dat de space shuttle zeer oude spullen gebruikte. Hier is cloud ook totaal niet relevant.
@Reza: Touché!
Al zal ieder zelf moeten besluiten wat goed voor hem/haar is.
@Henri,
Stellen dat vandaag de legacy van morgen gemaakt wordt is inderdaad waar, nog een practice waar moeilijk mee te breken valt door commerciele belangen en erg weinig applicaties zijn dus OS agnostisch. Een euvel wat je trouwens ook ziet met Cloud Computing hoewel door webtechnologie de service zelf wel naar meerdere verschillende client devices gebracht kan worden, net als met applicatie streaming maar dat terzijde. En over de definitie van Cloud Computing kunnen we eindeloos discusseren maar vanuit mijn perspectief is het evengoed een delivery model, van computer resource in dit geval welke (vaak) gevirtualiseerd zijn.
Maar daar ging het artikel dan ook niet over, wel over applicaties die min of meer ongewijzigd van delivery model wijzigen en daarmee misschien een parallel hebben met cloud computing. Tenslotte wordt hier ook nog weleens alleen getest op functionaliteit waarbij er geen rekening gehouden wordt met de belasting van resources. En hier wordt ook nog weleens geprobeerd in de breedte te schalen om iets op te lossen wat er in de lengte soms niet in zit, zoals bijvoorbeeld netwerk bandbreedte of non-routable protocollen.
Want zoals jezelf aangeeft gaat het namelijk helemaal niet om systemen of applicaties omdat deze vervangbaar zijn en van eigenaarschap kunnen wisselen maar vooral om de data. En misschien dat ik de volgende keer eens een artikel moet schrijven over zowel het eigenaarschap hiervan als de lifecycle omdat hier de grootste legacy ligt. Zeg maar een deel 2 van: ‘De winst van Cloud Computing’ welke je wel goed leesbaar vond maar waar je het ook niet geheel mee eens was:-)