Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Zo vast als een veertje

 

Computable Expert

ing. Jeroen MJ van Yperen Hagedoorn
Business Development Manager, Proact Netherlands B.V. . Expert van Computable voor het topic Infrastructuur.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5226977). © Jaarbeurs IT Media.

7


Lees meer over


 

Reacties

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.

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..

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×