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.
Jeroen,
Probeer je nu gewoon aan te geven dan je geen processen kunt automatiseren door vooral veel met buzzwords te gooien ?
Dat wisten wij allemaal al.
Verder leuk verhaal… zo herkenbaar.
Leuke anekdote, maar een software defined omgeving draait uiteindelijk ook ergens op hardware, en daar heb je toch weer last van veertjes.
Het grote verschil is dat het dan niet meer jou probleem is maar dat van je cloud- of andere leverancier.
Ik vraag me echter af of het veertje zich daar iets van aan zal trekken?
Als het zo belangrijk is voor de klant, waarom staat er dan geen failover in een ander datacenter?
Nog los van wel / niet software defined.
Moraal van dit verhaal lijkt me meer, dat de it-afdeling verantwoordelijk wordt gesteld voor business beslissingen. Ben je als it-afdeling onvolwassen als je accepteert dat de klant bepaalt wat er in haar change window gebeurt, ondanks jouw professionele advies ? Moeten we nou wel of niet lean, agile en veerkrachtig zijn ?
Een 24-uurs organisatie die niet zonder kan en geen direct inzetbare redundante oplossing parallel heeft draaien?
Dan besparen ze onterecht op redundantie of hebben ze er gewoon het geld niet voor. Dat laatste komt ook nog wel eens voor en dat kan je niemand kwalijk nemen.
@Benno, wegens spraakverwarring, ze hadden gekozen voor fallover 😉
@ Jeroen,
Je haalt zeer valide punten aan. Waar voor dank.
Het SDDC concept draait gewoon nog op hardware. En als dat fundament niet goed is dan zal je dat zeker merken. Echter wordt hardware wel steeds meer commodity en kan je sneller van merk wisselen en zal migratieproblematiek op het gebied van hardware een stuk verminderen.
Echter ligt er op de softwarelaag van het SDDC nog wel een uitdaging. Want hier wordt in zekere mate een vendor-lockin gecreeerd. Mogelijke standaardisatie kan hier in de toekomst mogelijk een uitkomst bieden. Maar zo ver zijn we nog niet.
Ook deel ik je mening dat je er met alleen softwarekennis niet gaat komen. Specifieke kennis van de onderliggende (hardware)lagen zal voorlopig en misschien nog wel atijd nodig zijn.
Het voordeel van software defined is wel dat het perfect inspeelt op de cloud. Iets wat soft is plaats je makkelijker in de cloud dan iets wat hard is. Dat valt namelijk snel van de wolken af of het is uitermate lastig ( lees vaak onmogelijk ) om in die wolk te tillen.
@Ruud Het is niet alleen inspelen op, er had geen cloud geweest zijn zonder software defined en virtualisatie denk ik. Je kan het niet los van elkaar zien. Altijd leuk verhalen van storingen en problemen maar eens met PaVaKe, die veertjes blijf je houden. Zelf meegemaakt dat ik wat weggemaakt had met een handig commando (rm -f du -sh *!), geen backup kon terugvinden om na een paar weken eindelijk bij de man terecht te komen die even een tape moest aandrukken.
Louis,
Ik sluit me volledig bij je aan. Goede toevoeging. Het is een logisch gevolg de cloud is nu eenmaal software driven.
Dank je voor je toevoeging.
Nu alles software wordt is statistisch gezien dus de kans groter dat hier ook meer problemen uit voort komen, problemen in de microcode los je niet op met SDDC maar verschuif je naar API’s die minder makkelijk te vervangen zijn dan een FRU door de één-op-duizend relaties als gevolg van delen. Leuk dat auteur stelt dat beheer volwassener moet worden maar er lijkt me dus eerder, net als met het veertje, sprake van een gereedschapsprobleem.