Toen ik twintig jaar geleden kwam kijken in de it-branche was het gewoon dat het “datacenter” van een middelgroot bedrijf in de bezemkast stond. Een simpel servertje via netwerk van tv-kabel verbonden met wat werkplekken. De enorme vlucht die ict genomen heeft is wel bekend. Door de virtualisatie slag en de bladevorm van servers krimpt de stapel hardware. Het gaat terug naar een omvang die te overzien is.
Als we daar ook de cloudambities bij optellen komt het neer op een sterke afslanking van de benodigde ruimte. Het gemiddelde datacenter van de nabije toekomst past in een eenvoudig blade enclosure en wat diskruimte. Bij de stelling op onze website: ‘over vijftien jaar hebben de meeste bedrijven geen eigen datacenter meer’, geeft 60 procent aan het met de stelling eens te zijn. Bijn atwee derde geeft dus aan dat het datacenter niet meer van hun zelf is, inpandig of ergens extern. Opmerkingen die worden meegegeven is dat het te overzien is als er niet meer zelf geïnvesteerd wordt in eigen ict-middelen.
De cloud ontwikkeling is bekend en al veel beschreven. De ontwikkeling naar ict als dienstverlening is al veel langer aanwezig. Dat het samenkomt met het afbouwen van eigen datacenters is een gevolg. Lege eigen datacenters of met nog een klein beetje rest hardware is wat overblijft. Dit restje past weer in de ouderwetse bezemkast. Een mooie lege balzaal is wat er overblijft.
Maar alles gaat gepaard met een leercurve. Eén belangrijk leerpunt wil ik delen: als je besluit om de it-voorziening bij een dienstverlener te plaatsen organiseer dan als eerste hoe je daar weer kunt vertrekken. Waarom dit leerpunt: wij zijn nu betrokken bij een verhuizing van datacenters tussen twee concurrerende dienstverleners. Omdat beide partijen concurrenten zijn komen ze niet bij elkaar over de vloer. Logische koppelingen zijn niet mogelijk en fysiek verhuizen is de enige optie. Met als klap op de vuurpijl: zodra de verhuizing begint; stopt de dienstverlening van de partij waar men vertrekt. Terugvallen op kennis en kunde van de oude eigenaar is niet mogelijk. De andere partij krijgt maar één kans om het goed over te nemen. Ik zal u niet vermoeien met alle details maar dit is de enige overgebleven optie.
De kosten die hiermee zijn gemoeid zijn fors. De business case blijft voorlopig positief, als er over een langere periode gerekend wordt. Het is een enorme operatie waarbij veel hobbels genomen moeten worden.
Het is dus belangrijk dat voor je met externe partijen gaat samenwerken (en daar de vele vruchten van gaat plukken) je goed moet weten hoe de it-voorziening weer kan worden teruggenomen of kan worden doorgegeven aan een andere partij. De gulden manier waarop is niet op voorhand te geven. Dit is uiteraard van veel (technische) factoren en soorten dienstverlening afhankelijk. Waar het mij om gaat is dat de exit strategie bij aanvang duidelijk is. Op korte termijn hebben wij al verschillende soorten virtuele/fysieke verhuisvragen gekregen tussen dienstverleners. Ieder met hun eigen bijzondere vertrekpunt en oorzaak. Allen gaan met veel kosten en moeite gepaard.
Dus voordat het restje it de bezemkast in kan en er plannen gemaakt worden wat te doen met het lege datacenter (Suggesties: de ideale wijnkelder, incompany danssalon of meditatie ruimte voor alle byod/hnw aanhangers) hou in gedachte dat deze wellicht toch weer eens gebruikt kan gaan worden…
Dag Jeroen, Leuk artikel, leest lekker weg en kan me in de inhoud vinden.
Wel denk ik dan dat het bruggetje naar cloud computing snel gemaakt is. Als het datacenter dan ook nog iets als OpenStack gebruikt of soortgelijk iets, dan is een exit strategie snel te maken.
Dus met je eens, en ik geloof dat er in de nabije toekomst steeds beter die extra stap gemaakt kan worden door de hardware als commodity te zien en als het cloud os dan ook nog commodity wordt, lijkt me een verhuizing al veel sneller te regelen? Of mis ik iets?
Jeroen,
Het verplaatsen van je ict-diensten en middelen naar een cloudprovider of outsourcepartner vereist een deskundigheid. Veel organisaties onderschatten dit punt. Een onderwerp in dit kader is de “Exit Strategie en (re)transitieplan”!
Dit is een hoofdstuk die zeer goed en duidelijk in je SLA opgenomen moet zijn. Veel opdrachtgevers vragen hun leverancier om deze (Exit strategie) op te stellen. Dat kan maar wees bewust dat je als klant dit document namens jezelf en je nieuwe partner moet lezen en niet degene die dat opgesteld heeft (je oude leverancier)
Hou er rekening mee dat je ruimte in de voorgestelde aanpak moet creëren! Dat komt doordat dit voorstel en aanpak door je oude leverancier geschreven is terwijl de nieuwe leverancier anders de zaak wil aanvliegen.
Wanneer je voor een veilige transitie en migratie kiest dan praat je meer over gefaseerde overgang. In deze vorm zijn er diensten die naar nieuwe provider verhuisd zijn terwijl de afhankelijkheden nog bij de oude leverancier liggen (later worden verhuisd) In dit geval de down time van een bron waar het verhuisde dienst van afhankelijk is, kan ook effect hebben op de werking en up-time van de dienst bij nieuwe leverancier. Hoe gaan jullie(oude leverancier, nieuwe leverancier en de klant) samen dit oplossen?
Er zijn nog meer aspecten en onderwerpen die aan dit stuk van SLA (Exit strategie en transitieplan) verbonden zijn. Daarom raad ik de klanten aan om iemand die hiermee ervaring heeft bij deze zaak te betrekken.
Trouwens, als de oude leverancier slim is dan zou hij niet kinderachtig met het verlies van zijn klant omgaan. Door samenwerken om de klant goed te laten verhuizen behoudt deze leverancier goede contacten met deze klant en kan hem altijd als referentie opgeven!
En………wat betreft de oude en lege datacenter, tja verander er niet veel aan misschien heb je hem over 3-5 jaar nodig voor een insourcing-traject!
Interessant stuk en een goede toevoeging van Reza.
Zelf hebben we onlangs een aantal grote partijen gehuisvest en dat is inderdaad in fases gegaan. Een van de partij heeft onlangs nog alle betrokken medewerkers naar ons datacenter laten komen om hen te laten zien waar ze op dat moment stonden in het project en wat er nog moest gebeuren. Tegelijkertijd kregen ze een goede feeling met een stukje IT dat ze nog niet allemaal kenden.
Omdat het zo’n grote operatie is, is het verstandig om een uitgebreid projectplan/team op te stellen. In overleg hebben wij een team opgesteld met afgevaardigden van de klant, onze backofficeafdeling die verantwoordelijk is voor oplevering, onze technische afdeling en de salesafdeling. Zo konden alle belangen meegenomen worden en kan er snel tussen afdelingen geschakeld worden.
Verder ben ik het geheel met Reza eens dat, als je onverhoopt afscheid van elkaar moet nemen, je dit beter in goed overleg en positief mogelijk zou moeten doen. Wie weet wat je later nog voor elkaar kan betekenen.
Dag Jeroen
leuk verhaal, maar wat zou er na de cloud komen:? alles op 1 chip weer lokaal over 8 jaar? Nu is de achterliggende IT-techniek nog complex, volumineus en energie-slurpend. Er is nog maar een beperkte mate van integratie en daardoor is er weer inwikkelde software nodig die nu dan cloud heet om het eenvoudig naar buiten te bieden.
Wanneer dat geïntegreerd is, is het interessant om te zien of de cloud op de wijze zoals die er nu is en efficient kan worden ingezet nog bestaat over 10 jaar en waarschijnlijk al veel eerder….
Jeroen,
“Nieuwe bezems vegen schoon, maar oude bezems kennen alle hoeken en gaten.”
Hoewel ik idee heb dat met virtualisatie en Cloud Computing vooral geprobeerd wordt om problemen onder het kleed te vegen. Maar ik ga in herhaling vallen als ik weer begin over lifecycles, OS agnostic applicaties en beheerSbaarheid om nog een paar punten toe te voegen.
Maar ja, zolang alleen naar functionele oplevering gesprint wordt zullen we onveranderlijk dezelfde fouten blijven maken. Zelfde lijken in de bezemkast met alleen andere techniek omdat het inzicht ontbreekt. Want dat komt meestal pas achteraf, het voortschrijdende inzicht waarna we inderdaad nog weleens op eerdere keuzen terugkomen.
Leuk artikkel
Eigenlijk te idioot voor woorden wat er gebeurd.
En net zo idioot om daar afspraken over te moeten gaan maken.
Daarmee zeggen die hosting partijen eigenlijk dat hun concullega’s (zeg maar de mede-mens) niet te vertrouwen zijn – op voorhand al! Zonder dat er ook maar iets gebeurd is!
Wat een wereld…
🙂
En als aanvulling:
Hoe ging dat spreekwoord ook alweer – dat van de waard en zijn gasten en zo… 🙂
De wet van Moore heeft inderdaad grote invloed op de omvang van datacenters die zoals wordt aangegeven terug kunnen naar het formaat van een bezemkast.
Bij de hedendaagse plannen voor datacenters mis je de toepassing van de wet van Moore. Niet alleen neemt de concentratie toe, zowel in processor als in opslag capaciteit, ook de hoeveelheid opgenomen vermogen wordt geconcentreerd.
Bij overgang van eigen datacenter naar externe datacenters lijkt het logisch dat je dit projectmatig doet. Wat je nog wel ziet is dat mensen fysiek gaan verhuizen, dus met servers slepen die vaak naast veel warmte verstoken weinig capaciteit kunnen leveren. Zorg dus dat je altijd logisch gaat verhuizen over een verbinding en niet fysiek. Als je dat goed doet kan je ook weer makkelijk naar een ander datacenter verplaatsen. Ik noem het verplaatsen omdat verhuizen fysiek is.
Allen,
Dank voor de leuke reacties. Reza, mooie constatering dat de exit strategie moet richten op de nieuwe partijen en niet de achterblijvers.
Veel reacties geven aan hoe het kan en zou moeten zijn. Wij merken dat de techniek niet zozeer de beperkende factor is maar de belangen en de wil. Ik denk dat Will dat ook duidelijk verwoord.
En Maarten, als reactie op jouw voorspellende gave: alles op één chip en weer lokaal? Alles komt in golven. Polkadots waren deze zomer ook weer mode.
Jeroen