Onlangs ben ik zijdelings betrokken geweest bij een prio-1 situatie, een storing. Een systeem ligt plat en dit heeft gevolgen voor een belangrijke afdeling. Deze afdeling kan niet meer werken en is onmisbaar in een 24-uurs organisatie.
De hardware had een fiks probleem en na wat speurwerk blijken het de netwerkmodules in een blade chassis te zijn die de storing veroorzaken. Na het uitpluizen van de logs wordt er een besluit genomen: hardware vervanging. Het proces is simpel, binnen enkele uren wordt er nieuwe hardware gebracht: klik vergrendeling los, veertjes trekken de verankering in, hardware er uit, hardware er in, klik vergrendeling vast, en klaar is de monteur.
Helaas voor ons bleek Murphy dit weekend ook dienst te hebben. Nog een keer proberen: de vergrendeling los, los, losser. Potver@#$%!!! De verankering werkt iets te goed, er is geen beweging in te krijgen. Om één of andere reden lukt het niet om een field replaceable unit in het veld te vervangen. Het lijkt er op dat de metalen veertjes niet mee werken. De vijf minuten worden er dertig, dertig minuten worden er een uur, een uur wordt twee uur… De tijd verstrijkt. Ongelofelijk dat een onderdeel van waarschijnlijk nog geen cent zoveel weerstand kan veroorzaken. Maar, de aanhouder wint en uiteindelijk lukt het de modules te vervangen.
Was het maar software defined
Ondertussen gaat er in de gedachten van de collega’s al het nodige rond. Oh, waren we maar jaren verder, software defined alles. Heerlijk. Voltooid verleden tijd voor complexe hardware en veertjes van een cent of wat. Gewoon common of the shelf (#cots) spullen. Gestapeld en niet te complex. Geen uren meer spenderen aan het vervangen van één complex en duur elementje, maar het hele bouwblok in één keer rip-en replace.
Software defined maakt het mogelijk. Eenvoudige hardware bouwblokken en complexiteit in één vluchtige laag. Niet vluchtig als in snel weg, maar vluchtig als in eenvoudig te veranderen. Waren we maar zo ver geweest dit afgelopen weekend. Dromen, dromen…
Terug naar vandaag
Langzaam komen wij weer uit die dromerige wereld terug. De hardware blijkt het probleem helemaal niet. Ja, los van dat veertje dan. Na nog verder graven blijkt het probleem in de firmware te zitten. Aaah, software. Dat is eenvoudig op te lossen. En dat klopt. De hele keten even aanpassen. Drie man tegelijk bezig. Servers, chassis, administrator boards en nic’s. Als of het niks is…
En dan komen we nog harder terug in de realiteit. Deze firmware problemen waren toch eerder aangegeven aan de klant? Proactief gemeld? Eerder gesignaleerd maar niets mee gedaan? Ja, niets mee gedaan. Nou ja, iedere zes weken een change window aangevraagd maar niet gekregen van de klant. Dat is niet te geloven. Dus een afdeling die niet mag stilstaan staat stil omdat er niets gedaan is. Het change proces was bevroren door andere belangen. Een proactief proces dat zo vast zit als dat metalen veertje.
Moraal van dit verhaal: Software defined vraagt meer van de it-afdeling dan alleen software kennis. Stappen maken in volwassenheid, adoptie van een beheerproces en meeveren, maar ook terugveren als de organisatie een tegenbeweging maak.
Hmm, ik kom ook nog even mijn plasje doen.
PaVaKe: Toch tijd om je kennis even op te poetsen. Een cloud leverancier heeft geen last van veertjes. Als een stuk hardware stuk is laat je het gewoon zitten. Dat is micro management. Als 30% van je container stuk is, of ouder dan drie jaar, dan rijdt voer je een procedure uit die alles wat draait in een container (soort super server rack) verplaatst naar andere “fault domains” en is dat klaar is wordt de container ontkoppeld en vervangen met een zojuist in elkaar geschroefde container. Wie nu nog met zweet op zijn voorhoofd een datacenter in gaat om een stuk hardware te vervangen gebruikt zeer zeker geen cloud computing.
Louis: Nee dus. F*ck de veertjes. Ik heb al jaren geen hardware meer gezien anders dan een laptop / desktop / tablet / smartphone welke ook gewoon direct vervangbaar zijn. Laatst liet ik mijn Chromebook uit mijn handen vliegen, dat overleefde hij niet. Even naar de winkel een nieuwe halen, klaar, opgelost.
Heb ik dan nooit problemen? Ook zeker wel. Laatst ben ik een dag verloren door het feit dat IE 9 standaard comcompatibiliteitsmodus aan zet voor intranet sites. Noem het een software matig veertje, dus eens, soms draait software je ook gewoon een loer.
Maar doorgaand op de leuke anekdote (die ander over Scheren as a Service ben ik ook niet vergeten), zie je dat er meer aan de hand was dan geneuzel over de hardware. Blijkbaar zat er ook wat mis in de integratie als de change bevroren was door ander belangen. Dat is voor mij altijd een rode vlag dat er nog veel meer aan de hand is wat niets met hard en software te maken heeft.
Toch lees ik tussen de regels door dat er toch nog weinig met cloud computing gedaan wordt. Gemiste kans 🙂
@Henri
Je toont weer een heerlijke kortzichtheid, zalig zijn de onwetenden want wat je beschrijft is gebaseerd op het ‘fail-in-place’ principe waarbij er voor 30% of meer aan redundancy is aangebracht in het ijzer.
Euh… dat ik hardware kan vervangen is leuk maar wat als ik middleware wil vernieuwen?
Auteur beschrijft een praktijkcase waar problematiek niet zo zeer aan de kant van IT ligt maar bij de business die haar verantwoordelijkheid aangaande configuratie management lijkt te ontlopen. Maar 2% van SOA architecturen houden rekening met veroudering van technische componenten wat dus voor een uitdaging in het Enterprise lifecycle management zorgt.
De volgende sessie met architecten gaat om IAM, gaat een leuke worden als ik kijk naar de wijze waarop veel organisaties nu de sleutel tot de schatkamer bewaren, lees je even goed in aangaande Jasbug (MS 15-011) als we kijken naar de backward compability authenticatie van veel services, een ‘big scale DigiNotar’ uitdaging;-)
Enne… waarop had je eigenlijk de encryptiesleutels opgeslagen?
Ewout, omdat je van diepzinnigheid houdt hier een quote uit The Matrix
Neo: What are you trying to tell me? That I can dodge bullets?
Morpheus: No, Neo. I’m trying to tell you that when you’re ready, you won’t have to.
—-
De middleware waar jij over spreekt zijn de bullets. Als je in de Matrix blijft (en jij de ontwetende bent), dan is die middleware en de technische componenten een probleem.
Als je cloud computing goed gebruikt met software die gemaakt is om te draaien op cloud computing, dan zijn je technische componenten niet interessant en geen onderdeel van je probleem.
je kunt beargumenteren dat we nu eenmaal te maken hebben met systemen die ouder zijn dan dat cloud computing nieuw is, maar dan geef ik terug dat dit dus een probleem is van een business / it die blijkbaar niet kan adapteren en nog vast zit aan werkwijzen en techniek die welliswaar functioneert maar verouderd is, ofwel, legacy.
Ieder bedrijf dat vast zit aan zijn legacy moet vrezen. Want bijna elke business is te kopiëren met efficiëntere varianten. Dus als jij niet kan vernieuwen, komt er wel iemand die het wel kan.
is je organisatie traag? Kan het niet ontsnappen aan een neerwaartse trend? Hoor dan dat Jaws deuntje in je hoofd…. (http://youtu.be/-j1weJ8kpCI?t=1m12s )
@Henri
Dus jij beweert dat de cloud geen ‘knellende veertjes’ kent?
Adapteren is niet innoveren, je zult het wel niet zo bedoelen maar inderdaad is dus elke business in de cloud makkelijk te kopiëren. Ik stelde een vraag over de encryptiesleutels want de schatkamer van een organisatie zit dus meestal niet in de software.
Terugkomend op je quote over kogels ontwijken en dat voorkomen is het handig om te weten dat bepaalde werkwijzen door regelgeving bepaald worden, lees nog even ‘regel-voor-regel’ deze opinie. Tussen vernieuwen en verbeteren zit dan ook dus net zo’n groot verschil als tussen adapteren en innoveren als we kijken naar de ‘knellende veertjes’ van de cloud.
In eerste reactie stelde ik wat over gereedschap, schroeven met een hamer is namelijk geen succes als ik kijk naar de processen, uitgaan van de mogelijkheden van de techniek of de mogelijkheden van een organisatie kan namelijk duur voortschrijdend inzicht voorkomen.
Het ‘knellende veertje’ van de cloud blijft nu eenmaal vertrouwen want als organisatie kun je maar een paar ‘crash & burn’ cases opvangen, betreffende haaien moet je niet vergeten dat als je ermee gaat zwemmen je er één moet zijn omdat je anders wordt opgegeten.
Enne… de cloud biedt mogelijkheden, geen wonderen!
@Henri,
Grote bedrijven hebben grote verantwoordelijkheden en zijn traag.
Die oplossingen die jij verzint zijn geschikt voor midden en kleinbedrijf. Daar is wel overzicht op mensen, middelen, hardware, software, backend, frontend, mid-end :-), relevante wetgeving, leveranciers, klanten.
Leuk matrix citeren:
“Morpheus: Do you believe in fate Neo?
Neo: No.
Morpheus: Why not?
Neo: Because i don’t like the idea that I’m not in control of my life.”
“Morpheus: Unfortunately, no one can be told what the Matrix is. You have to see it for yourself.”
Een groot bedrijf is een uncontrolled matrix, a desert of real. Ga maar eens kijken en pas je Agile Cloud kung fu daar maar eens toe.
Natuurlijk heeft cloud technologie of technologie van bepaalde providers veertjes. Het blijft software en daar gaat ook genoeg mis.
@Felix: Ik weet dat grote (en middelgrote) bedrijven vaak traag zijn. Kijk naar een V&D, die zijn wellicht *te* traag, en wat gebeurd er dan als er andere bedrijven zijn die ook kunnen wat zij kunnen? Juist, dan wordt dat bedrijf overbodig.
Heel simpel, een groot bedrijf zou al voor zijn generieke KA stack al heel veel veertjes weg kunnen nemen.
En ik weet dat veel bedrijven een uncontrolled matrix zijn. Dat is een probleem, vaak *het* probleem van de enterprise, daarom geloof ik in veel gevallen ook niet in grote bedrijven, al hoewel in andere gevallen (bijvoorbeeld Philips die machines voor ziekenhuizen maakt) een kleine bedrijf nauwelijks mogelijk is.
Kortom, sure, we snappen elkaar best wel, maar accepteren dat het niet anders kan, dat doe ik niet.
@ Henri,
Veertjes blijf je in ieder concept of delivery model houden. Het is alleen de vraag wie er verantwoordelijk is voor die veertjes.
In SDx ( Software Defined Anything ) is en blijft het fundament van je oplossing hardware. Ook al bevindt de intelligentie zich veelal op de software laag. Als dat niet goed of stabiel genoeg is verzakt je SDH (Software Define Home ) nog steeds.
De softwarelaag maakt het alleen flexibiler, mobieler,inzichtelijker en gemakkelijker te beheren.
Beste allen,
Mooi om te lezen welk effect een veertje kan hebben. Ook op de reacties.
En ja, ik laat een deel van de historie en context weg om te voorkomen dat ik (wie kent ze nog) telefoonboek dikke blogs ga schrijven. Ja redundantie was een optie, nee niet voor gekozen, andere prioriteiten voor aangevraagde changes laten gaan en verder niet op terug gekomen. Een heleboel o-zit-dat-zo context.
Moraal van de vele buzz-words was en is: dat de organisatie van IT en dus het uitvoeren van ons werk moet mee evalueren met het volwassen worden van onze belangrijkste partner: de interne klant / je collega’s / de opdrachtgever hoe je “hen” ook noemt. Welke technologie we ook gebruiken (zelfbouw, cloudbouw / hybridbouw) we zullen aandacht moeten hebben voor het afstemmen van veranderingen. Een Cloud provider die een gedwongen onderhoud aankondigt is echt niet bereikbaar als dat in de aangekondigde service window staat. En als in de dienstenbeschrijving van je leverancier staat dat de uber virtuele containers draaiend op hardware veilig gemaakt kunnen worden met extra dienstverlening a-la vervangende hardware zal je teleurgesteld raken als blijkt dan ook een veertje in een datacenter uit de bocht vliegt.
Dus goed om te lezen dat iedereen het eigenlijk over het zelfde heeft: de mogelijkheden nemen toe, de keuzes ook en je moet organisatie, procedures, kennis en je zelf blijven ontwikkelen.
En over films gesproken: ben afgelopen weekend naar The Imitation Game geweest over Alen Turing. Indrukwekkend om te zien en naast vele onderwerpen waarover we kunnen schrijven is het toepassen van Analytics (nieuwerwetse Big Data) wel de meest interessante.
En als Alen er niet was geweest was The Matix ook minder relevant..