Voorkom migratie vanuit de cloud

Wat een onsmakelijk, FUD-gebaseerd nepnieuws. Jammer dat zoiets gepubliceerd wordt.

@Peter
- Het is geen nieuws maar een blog
- Je snapt de sarcasme van het eerste deel?
- Artikel van Gitlab gelezen? Dat is niet nep. Wel nieuws.

Jammer dat je zo reageert.
Een beetje gezonde FUD mag je best hebben voordat je de Cloud in gaat gezien de genoemde feiten :-)

@Peter Als je denkt dat dit FUD is dan heb je waarschijnlijk nog nooit de maandelijkse AWS rekening gezien van een sterk groeiende startup of gehoord met welke (technische) problemen zij te maken hebben in een Public Cloud. Er zijn meerdere scenario's waar een Public Cloud niet meer voldoet, bijvoorbeeld om financiële, performance (Gitlab), governance of andere redenen. En dus dus zijn er ook organisaties die de Public Cloud om die redenen (deels) de rug toekeren. Als je dit 'onsmakelijk', 'FUD' en 'nep' noemt dan heb je er helaas weinig van begrepen.

Ik zie een hoop gemekker over Cloud-oplossingen bij de grote namen (AWS, Azure, Google) om vervolgens een stuk tekst te zien over hoeveel beter de Cloud is als je deze bij een kleine speler (Tuxis) onderbrengt. Een beetje de Pot die de Ketel verwijt. En dan argumenten over een onduidelijke factuur en "het gaat toch stuk" zijn weinig overtuigend.
Ik heb voor meerdere opdrachtgevers gewerkt als Software Developer en ook vaak gezien hoe het een en ander mis kan gaan. Zo was er een bedrijf dat gebruik maakte van een server bij een provider die ze dus zelf gekocht hadden. De provider ging failliet en de Curator claimde gewoon de server op en wat volgde was een vrij lange procedure gedurende welke het bedrijf gewoon niet bij hun eigen data kon komen. Nou ja, ze konden hun eigen server bij de curator terugkopen, wat ze dus niet wilden. Dus hoe kan een bedrijf als Tuxis zijn klanten tegen dit soort situaties beschermen?
Maar goed, hoe groot is het risico dat een provider failliet gaat? Bij AWS, Azure en Google is dat eigenlijk niet voor te stellen. Maar providers als VIP, TransIP en Tuxis, om er maar een paar te noemen, zijn een stuk kwetsbaarder en daarmee een goede reden om op te passen bij investeringen in oplossingen bij deze providers. Je wilt immers na een faillissement van de provider gewoon door kunnen gaan als bedrijf.
De opmerking dat data in de Cloud niet goed beschikbaar kan zijn is ook flauw. Een opdrachtgever van mij zat een halve dag zonder Internet, wat betekende dat ook de website compleet plat lag. Waarom? Omdat een graafmachine buiten het pand door de glaskabel was gaan graven. Foutje...
En dan heb ik het nog niet over de vele malen dat opdrachtgevers in de problemen raakten doordat hackers toegang hadden verkregen tot hun hardware. De ene keer was het een Turkse hacker die een site helemaal wiste en verving met een propaganda-pagina. Een andere keer was er een extra beetje code toegevoegd die probeerde iedere bezoeker te besmetten. Een derde keer werden nieuwe pagina's toegevoegd waar bezoekers op konden inloggen met hun bankgegevens en was de server dus opeens onderdeel geworden van een fraude-onderzoek. En zo heb ik nog wel veel vaker meegemaakt hoe de eigen servers gewoon onbereikbaar konden worden doordat het beheer ervan niet goed geregeld was.
En ja, met het terugzetten van backups was het meestal weer snel opgelost, zodra het was opgemerkt en een beheerder met de server aan de slag kon. Erg lastig als het op zaterdagavond gebeurt...
Eigen hardware is dan wel economisch gezien voordeliger maar je moet dan wel het personeel hebben om deze hardware goed te beheren. En daar gaat je voordeel weer mee verloren.
Wat verder? Storage-oplossingen als Ceph? Wat is de relatie tussen Ceph en AWS/Azure/Google eigenlijk? Ceph is immers gewoon een apart stuk software dat je op je eigen cluster kunt neerzetten. hoe is dit gerelateerd aan de Cloud-oplossingen van b.v. Microsoft die hier niet eens gebruik van maken? Ceph installeer je juist op je eigen hardware en dus is dit een prima argument om niet je eigen hardware te gebruiken...
En dan de grens aan de geleverde performance. Nu heb ik met diverse cloud-oplossingen gewerkt en vooral Azure is vrij handig hierin. Er is immers een complete API waarmee je het systeem automatisch kunt aanpassen als je meer of minder bandbreedte nodig hebt. En de prijs die je moet betalen is redelijk eenvoudig te bepalen door goed in te schatten hoeveel je nodig denkt te hebben. Iets wat je sowieso moet doen.
Maar goed, een dergelijk systeem wordt ook door TransIP aangeboden. Je eigen VPS systeem met een operating system naar keuze en waarbij je via een API de server automatisch kunt bijschalen, zowel omhoog als omlaag, voor relatief weinig geld per maand.
En ja, als ontwikkelaar heb ik geleerd dat de beste optie altijd komt uit het combineren van de juiste technieken voor ieder probleem dat je moet oplossen. Simpel gezegd kun je een website aanmaken voor Azure en Azure dus gebruiken om grote hoeveelheden bezoekers te verwerken. Een VPS bij een provider als TransIP kan dan ingericht worden met enkele web services die vanuit Azure aangeroepen kunnen worden voor de meer complexe zaken. En een server binnen het eigen kantoor kan vervolgens als fileserver dienen en zo grote mediabestanden aanleveren voor de website en daarnaast met enige regelmaat de gegevens backuppen van zowel Azure als de VPS, zodat deze daarna op tape veilig in een kluis kunnen.
Door meerdere providers tesamen te combineren worden de risico's een stuk kleiner in het geval een provider uitvalt.
Het artikel klinkt een beetje als reclame voor Tuxis. Op zich prima, maar een beetje misleidend omdat het een beetje klinkt als "Wij van WC-Eend adviseren WC-Eend!". Natuurlijk zegt Tuxis dat de services van Tuxis beter zijn dan de rest. Dat doen alle verkopers immers. Maar waar ik dan benieuwd naar ben is hoe Tuxis garandeert dat klanten nog steeds bij hun eigen data en servers kunnen komen indien het bedrijf onverwachts failliet gaat. Want die kans bestaat natuurlijk altijd. Zelfs een grote speler als Yahoo komt wel eens in zwaar water en een bedrijf als V&D leek ook niet failliet te kunnen gaan. Tot het gebeurde.
Dus een klant heeft bij Tuxis een hoeveelheid hardware besteld met bijbehorende diensten en de boel is geheel ingericht naar eigen wens. Vervolgens komt de curator langs en die trekt de stekker eruit en verkoopt de hardware aan de hoogst biedende. Dan ben je als klant zwaar de dupe. En ja, je kunt een schadeclaim indienen wat erop neerkomt dat je je achteraan de rij bij de curator kunt aanmelden. En maar hopen dat er nog iets over blijft. Je kunt natuurlijk ook de hardware opeisen maar dan moet je wel kunnen aantonen dat je de eigenaar bent van die hardware.
Dus als ik Tuxis vergelijk met Microsoft Azure, Amazon AWS of zelfs Google Apps, welke zekerheid is er dan dat het bedrijf in staat is om over 5 jaar nog steeds dezelfde diensten te kunnen bieden? En ja, die grote spelers kunnen hetzelfde probleem hebben maar de kans daarop is een stuk kleiner en daarnaast is bij hen de kans groter dat investeerders dan gewoon gaan investeren en bepaalde diensten gewoon overnemen om deze voort te kunnen zetten. Maar hoe zit dat met de veel kleinere providers in Nederland?

@Wim,

Ik weet niet of ik wel moet reageren, maar kan het ook niet laten.

Wat te vaak gesuggereerd wordt: Ga naar de public cloud en al je problemen zijn voorbij. Dat wordt weerlegd in de blog met onderbouwing waarom het alternatief (private cloud) wel goed is.
Om dat te doen moet je nadelen opnoemen en voordelen. En dit geval blijken de voordelen, genoemd door leveranciers van de public cloud, ook nog niet allemaal waar te zijn.
Nu ben jij vrij om nadelen van een private cloud op te noemen, maar die vind ik niet terug in je verhaal. En als er al nadelen zijn, maakt dat niet de nadelen van de public cloud ongedaan.

"Omdat een graafmachine buiten het pand door de glaskabel was gaan graven. Foutje..."
Je genoemde foutje is een design fout: loadbalancing, clustering, redundantie zou geholpen hebben. Iets wat je private cloud gewoon biedt.

"En dan heb ik het nog niet over de vele malen dat opdrachtgevers in de problemen raakten doordat hackers toegang hadden verkregen tot hun hardware."
Vroeger, toen de webserver nog direct op hardware draaide? Gehackte software is vaker de oorzaak overigens. Maar beweer je nu dat de hardware van private clouds met bosjes gehacked wordt? Of was er ooit een server gehacked?

"Wat is de relatie tussen Ceph en AWS/Azure/Google eigenlijk?"
Gitlab koos ervoor om Ceph te gebruiken voor hun storage op de apparatuur van de public cloudleverancier. Maar het gaat niet op Ceph. Het gaat erom dat er onbekende, beperkingen waren die niet in de folder stonden bij het aanschaffen van de dienst waarbij ze ook nog eens bar weinig ondersteuning kregen van de leverancier.

"En dan de grens aan de geleverde performance. Nu heb ik met diverse cloud-oplossingen gewerkt en vooral Azure is vrij handig hierin. Er is immers een complete API waarmee je het systeem automatisch kunt aanpassen als je meer of minder bandbreedte nodig hebt. En de prijs die je moet betalen is redelijk eenvoudig te bepalen door goed in te schatten hoeveel je nodig denkt te hebben. Iets wat je sowieso moet doen."
Je hebt het over een te klein gedefinieerde VPS. Het gaat echter over onverwacht afknijpen van ingekochte diensten. Lees het artikel van Gitlab.
Als jij graag een API wil gebruiken voor het definiëren van je VPS-en, dan kan dat gewoon. Ook bij gebruik van een private cloud.

"Vervolgens komt de curator langs en die trekt de stekker eruit en verkoopt de hardware aan de hoogst biedende."
En hier probeer je onterechte angst te zaaien. Er is anno 2016 echt geen enkele curator meer die bij een ISP de stekkers eruit trekt om het om te toveren in oud ijzer. Klanten met een private cloud hebben dat scenario ook allang bedacht en besloten dat de soep niet zo heet is.

"Dus als ik Tuxis vergelijk met Microsoft Azure, Amazon AWS of zelfs Google Apps, welke zekerheid is er dan dat het bedrijf in staat is om over 5 jaar nog steeds dezelfde diensten te kunnen bieden?"
Op dit punt zijn we het eens. Dat is een terechte angst.
Je weet inderdaad niet zeker of de public cloud leveranciers besluiten jouw dienst uit te faseren binnen nu en 5 jaar.
Of de verbinding/iops/burst nog verder wijzigen om te zorgen dat je juist eerder die premium of enig andere aanvullende dienst moet kopen. Uiteraard in het kader van productverbetering.
En misschien wordt je afgesloten van je public cloud omdat het systeem vind dat je nog niet betaald hebt (Geen MENS kon ze helpen, want het systeem...).
Als je zekerheid zoekt is de public cloud zeker niet de plek waar je wezen moet.
Maar een feit is dat jouw eigen cloud in eigendom over 5 jaar gewoon nog bestaat en doet wat jij wil dat hij doet. Het is immers van jou.

Wij horen van klanten en leveranciers dat ze aan het zoeken zijn waarom snelheden naar AWS niet gehaald worden. De reden is dezelfde als waar Gitlab tegenaan liep. Limieten en beperkingen die niet in de folder staan.
Lijkt mij al een hele valide reden om een andere leverancier te kiezen.
En dan blijkt dat een private cloud of cluster een prima oplossing is met heel weinig nadelen omdat de ontwikkeling in het datacenter ook gewoon doorgaat. Dat was de boodschap.

"En ja, als ontwikkelaar heb ik geleerd dat de beste optie altijd komt uit het combineren van de juiste technieken voor ieder probleem dat je moet oplossen."
en
"Door meerdere providers tesamen te combineren worden de risico's een stuk kleiner in het geval een provider uitvalt."

Maar je bereikt het tegenovergestelde.
Door meer providers te combineren is er veel vaker iets stuk. En als het afhankelijk is van elkaar, dan is het dus veel vaker helemaal stuk.
Spreiding werkt dus averechts. De enige juiste spreiding is zorgen dat je volledige dienstverlening gescheiden kan draaien. En dat kan dus precies heel eenvoudig met een private cloud. Want die kan veel load aan en ingewikkelde zaken, en files.

"Ga naar de public cloud en al je problemen zijn voorbij."
En dat zal ik zeker niet beweren. Maar met "Ga naar de *private* cloud en al je problemen zijn voorbij." ben ik het ook niet eens. Bij ieder probleem moet je immers op zoek gaan naar de beste oplossing. Soms is dat een private cloud, andere keren een public cloud en misschien een hybride systeem of zelfs een combinatie van systemen. Dat moet je gewoon per probleem en per situatie beoordelen.
Beheer is vaak de grootste uitdaging bij clouddiensten en de public cloud heeft vaak speciale API's tot hun beschikking om snel en automatisch aanpassingen te kunnen uitvoeren. Zo ben ik wel blij met Google Apps, een publieke SAAS oplossing, waar je binnen 5 minuten extra accounts kunt toevoegen of accounts kunt verwijderen. Combineer dat met de migratie-opties die google biedt en je hebt een mooie omgeving om je email mee af te handelen.
Dit in schril contrast met de email oplossing van een van mijn werkgevers in het verleden, waarbij ook een soort cloud-oplossing was gekozen maar iedere aanpassing moest telefonisch worden doorgegeven. En dan ook nog het probleem dat het een dag duurde voor een account was aangemaakt met ook nog eens een spelfout in de naam. En dat is nog niet eens de ergste variant die ik heb meegemaakt met bedrijfs-email-accounts. (Het ergste was een bedrijf waar personeel moest inloggen via een Remote Desktop op een virtuele server om daar Outlook te kunnen openen om zo met een gemeenschappelijke account te kunnen e-mailen...)

"Nu ben jij vrij om nadelen van een private cloud op te noemen, maar die vind ik niet terug in je verhaal."
Eigenlijk zijn de problemen van een private Cloud vergelijkbaar met die van een publieke Cloud. Je hebt een Internetaansluiting nodig om deze te gebruiken en je bent afhankelijk van een externe partij om het geheel te beheren. En het is al helemaal lastig als je als bedrijf niet zelf de juiste ICT-kennis in huis hebt en dus moet luisteren naar de verkooppraatjes van de diverse Cloud-providers. En ja, private of public maakt dan eigenlijk weinig verschil. Het zit hem meer in de provider zelf en de diensten die deze aanbiedt. En hoe eenvoudig deze te gebruiken zijn.
Nu ben ik een ICT-expert en software ontwikkelaar dus Cloud-toepassingen vind ik prettig als ze een goede API tot hun beschikking hebben die ik vanuit mijn eigen code op een veilige manier kan aansturen. Bij public Cloud oplossingen vind je vaak van dergelijke API's en ook nog eens een verzameling code-bibliotheken om deze in mijn eigen toepassingen te kunnen aanroepen. Bij kleinere providers is dat vaak iets meer een uitdaging. Zo heb ik enkele diensten bij TransIP lopen die verder een mooie API aanbieden, maar deze is gebouwd in PHP en eigenlijk alleen bedoeld om vanuit PHP gebruikt te worden. Vertalingen naar .NET of de mogelijkheid om deze vanuit een C++ applicatie aan te roepen hebben ze nog niet. En dat beperkt dan weer hetgeen ik ermee kan doen. Een eigen App bouwen voor mijn Android mobieltje zodat ik mijn data bij TransIP kan blijven controleren is dan een uitdaging. (Niet dat ik daar zelf aan wil beginnen...)

"Je genoemde foutje is een design fout: loadbalancing, clustering, redundantie zou geholpen hebben. Iets wat je private cloud gewoon biedt."
Tegen de schade die een graafmachine levert aan de glaskabel valt weinig te beginnen als al je servers zich in hetzelfde pand bevinden want hoeveel redundantie je ook hebt, het is allemaal afgesloten dankzij de kabelbreuk. Maar een extra server op een andere locatie zou een oplossing kunnen bieden indien de servers maar ver genoeg uit elkaar staan. De ene in Maastricht en de ander in Den Helder, bijvoorbeeld. Want ik kan mij ook een stroomstoring herinneren die nog niet zo lang geleden Amsterdam trof die een groot deel van de ICT-bedrijven in Amsterdam plat wist te leggen. En natuurlijk kan een datacenter een mooi noodaggregaat hebben maar dan nog is de vraag of de internetverbinding nog actief blijft want als de provider hun aggregaat uitzet heb je alsnog geen Internet meer.
En juist het Internet is extreem belangrijk bij Cloud-toepassingen.
Als ICT'er heb ik het gelukkig niet vaak meegemaakt dat een grote storing het werk geheel stil legde. Maar het is wel eens voorgekomen en in 1 geval ben ik vervolgens zeer snel naar huis gegaan omdat de stroom het daar wel deed en de server in een ander gebied stond. Vanaf thuis kon ik zo alsnog een probleem met de server herstellen terwijl het kantoorpand tot 20:00 gewoon geen Internet en geen stroom meer had.

"Maar beweer je nu dat de hardware van private clouds met bosjes gehacked wordt?"
Nope, maar het is wel een groot risico. Ik heb geen cijfers over hoe vaak de private cloud wordt gehackt. Ik weet wel dat ik meerdere malen bij opdrachtgevers aan de slag kon om de nodige malware weer uit de Cloud te schoppen en dan voornamelijk bij websites in de Cloud waar hackers gewoon extra code en extra pagina's aan toe wisten te voegen.
Maar goed, hoe snel een Cloud-oplossing wordt gehackt hangt niet van het type Cloud af maar van hoe de gebruikers ermee om gaan. Het gebruik van simpele wachtwoorden en zelfs het noteren en delen van wachtwoorden met derden maakt het vrij eenvoudig om een Cloud-omgeving te hacken.
Maar http://www.dailydot.com/layer8/cloud-computing-security-government-it-survey/?linkId=16980379 van September 2015 is een mooi artikel wat gaat over hoe onveilig Cloud-oplossingen wel niet kunnen zijn. Alle Cloud-oplossingen zijn hierbij kwetsbaar omdat de zwakste schakel (de gebruiker) bepaalt hoe sterk de beveiliging werkelijk is. Dus ja, ik hou mijn Google Apps account in de gaten alsmede mijn DropBox, mijn Azure en zelfs mijn oude Yahoo account. Maar ik let ook goed op de virtuele server die ik bij TransIP heb staan en daarnaast ook op mijn prive-web server in mijn kast thuis. En met alleen mijzelf als gebruiker van deze Cloud-diensten heb ik toch enige zekerheid.
Nou ja, behalve dan die keer dat DropBox werdt gehackt. Ik hoop dat mijn wachtwoord van 20 tekens alsnog veilig genoeg is.

"Het gaat erom dat er onbekende, beperkingen waren die niet in de folder stonden bij het aanschaffen van de dienst waarbij ze ook nog eens bar weinig ondersteuning kregen van de leverancier."
Maar Ceph zelf is gewoon gratis. Open-Source zelfs! (https://github.com/ceph/ceph) En dat betekent gewoon dat je je eigen leverancier bent en dus zelf je onderhoud moet regelen. Of anders een derde partij moet inhuren om dit voor jou te regelen. Het probleem ligt dan niet bij Ceph maar bij degene die het heeft "verkocht" en geïmplementeerd.
En daar ligt ook een groot probleem. Veel gebruikers van Cloud-oplossingen missen de kennis en ervaring om zelf goede keuzes te maken en zijn daarbij afhankelijk van anderen voor adviezen. Zo had ik ooit een opdrachtgever (en vriend) die een kleine website wilde beginnen en mij om een kort advies vroeg omdat hij een vriend had gevraagd om een site te ontwerpen (voor een kratje bier!) en het duurde zo lang voor het af was. Hij schrok vervolgens wel enorm van toen hij hoorde hoeveel werk een complete website wel niet kan zijn, zeker indien hij hem zelf wilde onderhouden. En ook hoeveel kosten er uiteindelijk bij konden komen te kijken. Plotseling was hij best tevreden met hetgeen hij had gekregen voor het kratje bier en besefte ook dat hij niet veel meer had moeten verwachten.
Tja, veel mensen hebben een bedrijf en willen er iets met Internet erbij hebben want dat is modern. Ze weten alleen vaak niet waar ze aan beginnen en dan krijg je allerlei onverwachte problemen. Zelfs professionele ICT'ers gaan geregeld de fout in, zeker indien men daarbij vasthoudt aan een bepaalde zilveren kogel als oplossing voor al hun problemen. Maar er is gewoon geen zilveren kogel waarmee je alles kunt oplossen!

"Door meer providers te combineren is er veel vaker iets stuk. En als het afhankelijk is van elkaar, dan is het dus veel vaker helemaal stuk."
Maar je zei zelf al dat er altijd wel iets stuk gaat. En of er vaker iets stuk gaat is lang niet altijd zeker maar als er dan iets stuk gaat, dan is dat een kleiner deel van het geheel. De locatie van het probleem is dan ook sneller te vinden en net zoals met andere Cloud-toepassingen kun je via load-balancing en andere trucks gewoon een backup in werking stellen terwijl het betreffende onderdeel wordt gerepareerd.

"Het gaat echter over onverwacht afknijpen van ingekochte diensten."
Gitlab: "With this performance capacity, we became the "noisy neighbors" on the shared machines, using all of the resources."
Hey, dat herken ik. In het verleden had ik in mijn SecondLife virtuele omgeving een script gemaakt die alle conversaties op mijn landje opnam en door stuurde naar mijn server om het daar in een database op te slaan. En omdat het soms best druk bezocht was bleek dit soms heel veel data te zijn die mijn shared server moest verwerken. Zoveel eigenlijk dat mijn provider mij verzocht of ik de hoeveelheid verkeer een beetje kon afremmen.
Maar goed, ook dit soort dingen moet je van tevoren proberen in te schatten. En als je om wat voor reden te maken denkt te hebben met heel veel dataverkeer of heel veel rekenkracht dan moet je sowieso goed nadenken over de hardware die dit alles moet gaan ondersteunen. Maar nogmaals, hier blijkt het eigenlijk te gaan om een gebruiker die slecht geïnformeerd was over de mogelijkheden maar wel enorm hoge verwachtingen heeft. De meeste ICT'ers leren dit net als GitLab door dit soort incidenten en dus is het belangrijk dat je goed weet welke behoeftes je systeem allemaal moet hebben.
Maar goed, GitLab stelt hele hoge eisen aan hun systeem en biedt eigenlijk zelf een SAAS oplossing aan voor vele andere gebruikers. Ze leveren een versiebeheersysteem in combinatie met Agile functionaliteit en zijn daarbij eigenlijk niet de enige. Maar goed, zelf heb ik meer de voorkeur voor Microsoft's Team Foundation Services waarbij ik twee servers in gebruik heb. Eentje op mijn eigen web server thuis in de kast en de ander in de Cloud van Microsoft. Werkt allebei even goed. Maar ik snap dan ook wel hoe het kan dat ze zoveel data te verwerken krijgen. En als je dit als een publieke dienst wilt aanbieden dan is het niet erg handig als je een server moet delen met andere gebruikers.
Opvallend is dan wel weer dat ik een account bij Gitlab aanmaak om hun site eens te testen en dit doe via een Google App account. En dan zie ik bij de profile settings dat het plaatje wat bij mijn account hoort kennelijk niet geladen kan worden. Geen idee waarom maar kennelijk is ook de huidige Cloud-oplossing niet helemaal perfect. (Enkele minuten later is het plaatje er wel...)

"Je weet inderdaad niet zeker of de public cloud leveranciers besluiten jouw dienst uit te faseren binnen nu en 5 jaar."
Klopt, maar als het gebeurt dan zal er bij de publieke cloud, zeker bij grote partijen als Google en Microsoft, een enorm protest komen vanuit de gebruikers. Daarnaast zullen er genoeg ander providers zijn die deze diensten meteen willen overnemen en de nodige migratie-opties zullen aanbieden om over te stappen naar de Private Cloud.
Maar een kleine provider die mogelijk maar een paar duizend klanten heeft zal het stilleggen van de diensten veel minder protest opleveren. Het is immers maar een kleine groep die het slachtoffer wordt.
Daarnaast blijft er het grootste probleem dat bedrijven failliet kunnen gaan. Ja, ook Google en Microsoft kunnen failliet gaan. Als ik kijk naar hoe het gaat met Yahoo zie ik al hoe moeilijk zo'n groot tech-bedrijf het uiteindelijk kan hebben. Maar omdat deze bedrijven juist zo groot zijn zullen er vaak investeerders klaar staan om de boel alsnog overeind te houden, wat de meeste klanten tijd genoeg moet geven om een alternatief te zoeken.

"Er is anno 2016 echt geen enkele curator meer die bij een ISP de stekkers eruit trekt om het om te toveren in oud ijzer."
Nee, maar een curator ziet wel een hoop hardware in het pand staan die waarde heeft in de verkoop en zal deze dan ook gewoon te koop aanbieden, tenzij de klanten kunnen aantonen dat zij toch echt de eigenaar ervan zijn. Een curator mag namelijk enorm veel en als klant is het enige dat je feitelijk kunt doen een schadeclaim indienen en achteraan aansluiten bij de overige schuldeisers. Dit geldt niet alleen voor de hardware maar ook voor de data die door de Curator gewoon doorverkocht kan worden als dat geld oplevert. En anno 2016 kunnen er gewoon nog problemen ontstaan door een al te ijverige curator die de dienstverlening gewoon plat legt to de klant betaalt voor toegang tot hun gegevens.
Op 15 November jl. had IT Room Infra een mooie bijeenkomst waar diverse punten over datacenters en Cloud Computing ter sprake kwamen. Daarbij ook vooral de focus op risico's' die men loopt bij diverse Cloud-oplossingen.
Van die presentaties is http://www.itroominfra.nl/wp-content/uploads/sites/30/2016/07/Compose-2.pdf een mooie omdat die aangeeft wie Cloud-oplossingen het meeste gebruiken, voor welk doel ze gebruikt worden en tegen welke problemen men regelmatig aan loopt.
In 2014 bij een vergelijkbaar even was deze presentatie ook interessant: http://www.itroominfra.nl/wp-content/uploads/sites/30/2014/04/1.VanRietAlliedAdvocaten.pdf Want hierin is meer informatie over wat er gebeurt bij een faillisement en welke problemen hierbij kunnen voorkomen.
Zekerheid heb je als klant eigenlijk nooit en in de 30 jaar dat ik al in de ICT zit heb ik veel veel zien veranderen, veel op zien komen maar ook veel ten onder zien gaan. Wie de meeste zekerheid wil moet kijken naar welke partijen het meest stabiel zijn geweest in de afgelopen jaren en goed blijven controleren of ze in de toekomst stabiel blijven.
Daarnaast kan het nooit kwaad om altijd een exit-strategie bij de hand te hebben en niet te wachten tot het laatste moment om een migratie uit te voeren.

"En ja, private of public maakt dan eigenlijk weinig verschil. Het zit hem meer in de provider zelf en de diensten die deze aanbiedt. En hoe eenvoudig deze te gebruiken zijn."

En over dat zijn we het eens.
Dan kunnen we weer terug naar de infrastuctuur, waar deze blog over gaat. Public cloud infrastructuur die niet doet wat beloofd is en daar kun je niets aan doen anders dan zorgen dat die van jezelf is.

"http://www.itroominfra.nl/wp-content/uploads/sites/30/2014/04/1.VanRietAlliedAdvocaten.pdf"
Gaat echt over data die je op de apparatuur van een ander zet. De door jouw gebruikte public cloud dus.

Nog een voordeel om toch maar eigen spullen te kopen.

Je moet het zo zien, als je huurbaas falliet gaat (lees isp), komt de curator ook niet jouw TV (lees server) ophalen omdat het in het pand (lees rack) zit dat je huurt.

Verder denk ik dat je goed moet lezen.

"Public cloud infrastructuur die niet doet wat beloofd is en daar kun je niets aan doen anders dan zorgen dat die van jezelf is."
Maar dat kan in principe niet omdat dit dan contractbreuk is en je via een rechter gewoon gaat opeisen wat je met de provider hebt afgesproken. Het probleem is eerder: 'Public cloud infrastructuur die niet doet wat JIJ denkt dat beloofd is...'
Dit is een kwestie van jezelf goed laten voorlichten en luisteren naar verhalen en ervaringen van andere partijen. En daarnaast ook goed beseffen wat je precies nodig hebt want als je zelf een SAAS aan het opzetten bent voor tienduizenden gebruikers zoals GitLab dan moet je beseffen dat je behoeftes veel anders zijn dan die van een bedrijf met 500 medewerkers die alleen een administratiesysteem voor intern gebruik nodig heeft. Of gebruikers zoals PostNL die wel heel veel gebruikers hebben maar waarbij iedere gebruiker eigenlijk maar hele kleine data-transacties uitvoert.

"Gaat echt over data die je op de apparatuur van een ander zet. De door jouw gebruikte public cloud dus."
Maar ook als je gewoon je eigen server koopt en deze laat installeren en onderhouden door een extern datacenter. Als het datacenter failliet gaat dan zet de Curator alles op slot en wordt het lastig om je eigen server terug te krijgen en om vervolgens een ander datacenter voor die server te vinden.
En nee, de curator komt niet meteen mijn TV ophalen als de huisbaas failliet gaat, tenzij de huisbaas een compleet gemeubileerde woning verhuurde. Dan kan de curator opmerken dat de TV bij de originele inboedel behoort en dus alsnog deze in beslag nemen. Kom dan maar op met je aankoopbon.
Vergelijkbaar is het als je een bestelling hebt lopen bij een winkel die vervolgens failliet gaat. (Denk aan V&D, bijvoorbeeld.) De curator kan dan gewoon besluiten om niet te leveren en melden dat je je geld terugkrijgt. Ten minste, als er nog geld over is na het afbetalen van alle schuldeisers...
Sowieso wil je zelf direct door terwijl de curator de stekker uit alles haalt, want stroom kost ook geld. Je moet dus een duidelijke exit-strategie hebben met de betreffende provider of ook echt alle hardware in je eigen kantoor plaatsen.
Dat laatste is in principe de beste oplossing maar dan moet je eigenlijk twee kantoren hebben die redelijk ver uiteen liggen zodat b.v. stroomuitval bij de ene provider niet ook de ander neerhaalt. Betekent ook op beide kantoren een systeembeheerder die de hardware in de gaten kan houden en eventueel kan aanpassen. Op zich wel te doen, maar je moet wel een ervaren beheerder in dienst hebben die alles goed weet te beveiligen. Ik zei al dat de gebruiker in het algemeen de zwakste schakel is waardoor het achterneefje van de directeur die wel eens Windows 10 heeft geïnstalleerd is dan geen goede oplossing.
Dus is het handiger om je hardware te laten beheren door een externe provider die alles dan in de gaten kan houden. Ook mooi als je dan de hardware ook goedkoop via die provider kunt inkopen maar dan moet het niet om een virtuele machine gaan maar daadwerkelijk kaal metaal.
Bij virtuele servers heb je vaak pech bij faillissement omdat het dan alleen pure data is, en data is wettelijk niets. Daar kun je eigenlijk geen rechten aan ontlenen. Je moet dan ook echt fysieke hardware bezitten bij de provider. Maar dat is niet waar veel klanten van cloud providers bij stil staan. Die zien het verschil niet tussen virtuele servers en fysieke servers. Ja, het prijskaartje is het verschil... Virtueel is goedkoper.
Een ander en minder bekend risico bij een faillissement is het 'bodemrecht' van de BelastingDienst. En dat is een hele vervelende als je een server laat hosten bij een externe provider omdat de belastingdienst gewoon beslag legt op alles wat ligt op de bodem van het failliete bedrijf. Dus ook jouw servers. (Zie http://wetten.overheid.nl/BWBR0004770/2012-01-01/1#HoofdstukIV_Afdeling1_Artikel22)
En dat betekent dat als mijn verhuurder failliet gaat, ik niet alleen uit het pand moet vertrekken maar de belastingdienst gewoon beslag legt op alles wat in het pand aanwezig is en ik vervolgens moet aantonen dat die TV echt van mij is en niet van de verhuurder. Gelukkig zijn huurders van woningen wel iets beter beschermd zodat dit scenario onwaarschijnlijk is. Maar een datacenter of provider kun je niet volledig vergelijken met een verhuurder van een pand.
Kortom, bij alle cloud providers moet je goed opletten op hoe financieel gezond de provider is. Dat is bij grotere providers eenvoudiger dan bij kleine providers.