Ik zou beter moeten weten dan naar de Hacker News-menigte te kijken voor wijsheid. Onlangs stelde iemand op HN een interessante vraag: 'Ben je ooit overgestapt?'Als HN waren de antwoorden lang niet zo interessant. In feite reageerden relatief weinig mensen op de vraag, en gaven er de voorkeur aan om hun applicaties in privédatacentra te laten draaien. Anderen boden advies dat was afgestemd op kleine winkels en niet op grotere ondernemingen.

Maar ondanks de ruis *was* er een klein signaal in de thread. Als u het meeste uit een bepaalde cloud wilt halen, zult u zich moeten inkopen voor de services ervan, wat de migratie natuurlijk bemoeilijkt. Oh, en als je denkt dat je een betere cloud kunt bouwen dan de hyperscalers, mis je misschien het punt.

== Laat me de credits zien ==

Als bedrijven er eenmaal voor hebben gekozen om op een bepaalde cloud te bouwen, wat zet hen dan aan om over te stappen? Bij het lezen van de HN-antwoorden zijn 'credits'een uitstekende motivator. Het is onduidelijk in hoeverre zo'n honeypot grotere ondernemingen aanspreekt, maar voor een bepaalde demografie kan migratie worden gemotiveerd door voldoende Google Cloud [of Azure of AWS]-credits om een ​​overstap de moeite waard te maken .âÂÂ

Helaas ziet dit simplistische soort kosten-batenanalyse alle verborgen kosten van draaien in de cloud over het hoofd, zoals David Linthicum heeft uiteengezet.

Zoals GitLab blijkbaar heeft ontdekt, kunnen credits migratie aanmoedigen, maar ze betalen er niet noodzakelijkerwijs voor. Zoals beschreven in de HN-opmerking: "Bij GitLab gingen we van AWS naar Azure en vervolgens naar Google Cloud. Waarom in de eerste plaats van AWS afstappen? Geld was een probleem, maar niet omdat AWS inherent duurder was. Het was eerder een probleem met de setup: âÂÂZoals de meeste bedrijven werd er heel weinig aandacht besteed aan de kosten, setup, enz. [bij het starten met AWS]. Het resultaat was dat we eigenlijk geld in brand staken. Er kwam een ​​aanbod voor gratis Azure-tegoeden dat ons ongeveer een jaar aan rekeningen zou besparen ( destijds best veel geld

Klinkt goed, toch? âÂÂOverstappen was nogal pijnlijk en ⦠we waren *erg* snel door de gratis tegoeden heen.â Het bedrijf besloot toen om naar Google Cloud te verhuizen (om onverklaarbare redenen), en ontdekte dat migratie opnieuw een "uitdagend proces"was.
Wat heeft de commentator geleerd van de ervaring? âÂÂTerugkijkend, als ik een bedrijf zou beginnen, zou ik waarschijnlijk bij iets als Hetzner of een andere betaalbare bare metal-aanbieder blijven. Cloudservices zijn geweldig *als* u hun services zo volledig mogelijk gebruikt, maar ik vermoed dat het in 90% van de gevallen gewoon een enorme kostenfactor is zonder dat de voordelen het de moeite waard maken.

Voor mij is dit precies de verkeerde les.

== Begrijp de wolk nog steeds niet ==

Als je de hele thread doorleest, zul je veel zelfverzekerde beweringen vinden dat doe-het-zelf cloud (op Hetzner of andere dedicated serverhosters) de juiste keuze is. (Hier en hier en hier.) Zoals ze zeggen, is de openbare cloud veel trager en duurder dan je eigen server. Behalve dat het dat niet is. . Het idee dat IT-professionals gemakkelijk de cloud kunnen overtreffen, is onjuist en ter zake doende.

Bij cloud ging het nooit echt om geld besparen. Het gaat om het maximaliseren van flexibiliteit en productiviteit. Zoals een HN-commentator opmerkt: 'Ik werk in een heel klein team. We hebben een paar ontwikkelaars die ook als ops fungeren. Niemand van ons is of wil systeembeheerder zijn. In ons geval bespaart Amazon's ECS [Elastic Container Service] enorm veel tijd en geld. Hoe? Door sysadmin-functies te verwijderen die het team voorheen moest invullen. âÂÂJa, de meeste problemen die we eerder hadden, hadden kunnen worden opgelost door een bekwame systeembeheerder, maar dat is precies waar het om gaat. Het inhuren van een goede systeembeheerder is veel duurder voor ons dan een beetje extra te betalen aan Amazon en ze gewoon te vertellen: voer deze containers alsjeblieft uit met deze configuratie.

Hij doet het goed met cloud.

Anderen suggereren dat door over te stappen op serverloze opties, ze de behoefte aan systeembeheerders verder verminderen. Ja, hoe meer u zich verdiept in services die uniek zijn voor een bepaalde cloud, hoe minder gemakkelijk het is om te migreren, ongeacht hoeveel credits een provider u toewerpt. Maar hoe minder verlangen u zou hebben om te migreren, als uw ontwikkelaars aanzienlijk productiever zijn, omdat ze de infrastructuurwielen niet steeds opnieuw uitvinden.
Eén bedrijf probeerde expliciet lock-in aan een bepaalde cloud te vermijden. âÂÂWe hebben ons product vanaf het begin ontwikkeld om te worden geïmplementeerd op 3AWS, Azure, IBM.â Hoezo? Door vast te houden aan de kleinste gemene deler, namelijk FaaS/IaaS ([AWS] Lambda, [Amazon] S3, [Amazon] API [Gateway], Kubernetes Klinkt eenvoudig, toch? was zeker niet gemakkelijk. We negeerden ook tools die ons enorm hadden kunnen helpen [als we bij] een enkele cloud waren gebleven om multicloud te zijn. het? âÂÂSchakelen tussen bepaalde gedeelde functies is mogelijk, maar is zeker niet een paar klikken of een paar Jenkins-banen verwijderd. Wisselen tussen is een fulltime baan. Vinden hoe je dat kleine VM-ding doet dat je deed in AWS , nu in Azure, kost tijd en leren. En schakelen tussen AWS IAM en Azure [Active Directory] toestemming? Tijd, tijd en tijd.âÂÂ

Met andere woorden, multicloud is niet eenvoudig uit te voeren, en migratie ook niet. Betekent dit dat geen van beide het uiteindelijk waard is? Niet noodzakelijk. Zoals Miles Ward, CTO van SADA (een belangrijke Google Cloud-partner), het beschrijft, kunnen er dwingende redenen zijn om naar een andere cloud over te stappen. âÂÂVoor zovelen is het gewoon gebruiksgemak en efficiëntie om dingen voor elkaar te krijgen; voor anderen is het aandacht en partnerschap; voor een derde cohort zijn het absurde kostenvoordelen; en een vierde, het zijn prestaties en betrouwbaarheid. Als zodanig, wanneer klanten hiaten zien in een of meer van die vier gebieden, gaan ze .âÂÂ

Ward heeft waarschijnlijk gelijk: er *kunnen* dwingende redenen zijn om te migreren. Zorg ervoor dat u een volledige analyse maakt van de totale eigendomskosten van de verhuizing, die veel verder moet gaan dan cloud X biedt me $ 50.000 aan credits. Bovendien, voordat u besluit om uw eigen cloud te rollen, is het de moeite waard om rekening te houden met de kosten die gepaard gaan met het beheer van al uw eigen infrastructuur.