Jag borde veta bättre än att titta till Hacker News-publiken för visdom. Nyligen ställde någon på HN en intressant fråga: Har du någonsin bytt? Som HN var svaren inte alls lika intressanta. Faktum är att relativt få personer överhuvudtaget svarade på frågan, de föredrar istället att driva sina applikationer i privata datacenter. Andra erbjöd råd anpassade till små butiker inte större företag.
Men trots bruset *var* det en liten signal i tråden. Om du vill få ut det mesta av ett visst moln, kommer du att behöva köpa in dig i dess tjänster, vilket naturligtvis komplicerar migreringen. Åh, och om du tror att du kan bygga ett bättre moln än hyperscalers, kanske du missar poängen.
== Visa mig krediterna ==
När företag har valt att bygga på ett visst moln, vad får dem att flytta? När man läser igenom HN-svaren är âÂÂkrediter en främsta motivator. Det är oklart hur mycket en sådan honungskruka tilltalar större företag, men för en viss demografi kan migrationen motiveras av tillräckligt med Google Cloud [eller Azure eller AWS]-krediter för att göra en byte värd besväret .âÂÂ
Tyvärr förbiser denna förenklade typ av kostnads-/nyttoanalys alla dolda kostnader för att köra i molnet, som David Linthicum har beskrivit.
Som GitLab uppenbarligen upptäckte kan krediter uppmuntra migrering men de betalar inte nödvändigtvis för det. Som beskrivs i HN-kommentaren, âÂÂPå GitLab gick vi från AWS till Azure och sedan till Google Cloud. Pengar var ett problem, men inte för att AWS till sin natur var dyrare. Snarare var det ett problem med installationen: â Liksom de flesta företag ägnades mycket lite uppmärksamhet åt kostnaderna, installationen etc. [när man började med AWS]. Resultatet var att vi i princip satte eld på pengar. Tillsammans kom ett erbjudande om gratis Azure-krediter som skulle spara oss något i stil med ett år i räkningar ( ganska mycket pengar på den tiden
Låter bra, eller hur? âÂÂAtt flytta över var ganska smärtsamt och ⦠vi brände igenom gratiskrediterna *mycket* snabbt.â Företaget bestämde sig sedan för att flytta till Google Cloud (av oförklarliga skäl), och upptäckte att migrering återigen var en utmanande process.
Vad lärde kommentatorn av erfarenheten? - När jag ser tillbaka, om jag skulle starta ett företag, skulle jag förmodligen hålla mig till något som Hetzner eller en annan prisvärd barmetallleverantör. Molntjänster är fantastiska *om* du använder deras tjänster i största möjliga utsträckning, men jag misstänker att det i 90 % av fallen bara blir en enorm kostnadsfaktor utan att fördelarna gör det värt det.â¢ÂÂ
För mig är detta helt fel läxa.
== Förstår fortfarande inte molnet ==
Om du läser igenom hela tråden kommer du att hitta många självsäkra påståenden om att gör-det-själv-moln (på Hetzner eller andra dedikerade servervärdar) är vägen att gå. (Här och här och här.) Som de säger, det offentliga molnet är långsammare och dyrare än din egen server med stor marginal. Förutom att det inte är det . Denna idé om att IT-proffs lätt kan göra molnet ute i molnet är fel och inte alls.
Cloud har egentligen aldrig handlat om att spara pengar. Det handlar om att maximera flexibilitet och produktivitet. Som en HN-kommentator påpekar, arbetar jag i ett mycket litet team. Vi har några utvecklare som fungerar som ops. Ingen av oss är eller vill vara sysadmins. För vårt fall är Amazons ECS [Elastic Container Service] en enorm tids- och pengarsparare. Hur? Genom att ta bort sysadmin-funktioner var teamet tidigare tvunget att fylla. âÂÂJa, de flesta av problemen vi hade tidigare kunde ha lösts av en kompetent systemadministratör, men det är just poängen att anställa en bra systemadministratör är mycket dyrare för oss än att betala lite extra till Amazon och bara säga till dem - vänligen kör dessa behållare med denna config.
Han gör molnet rätt.
Andra föreslår att genom att flytta till serverlösa alternativ minskar de ytterligare behovet av sysadmins. Ja, ju mer du gräver i tjänster som är unika för ett visst moln, desto mindre lätt är det att migrera oavsett hur många krediter en leverantör kastar på dig. Men, utan tvekan, desto mindre lust skulle du ha att migrera om dina utvecklare är betydligt mer produktiva eftersom de inte uppfinner infrastrukturhjul på nytt hela tiden.
Ett företag försökte uttryckligen undvika inlåsning till något särskilt moln. âÂÂVi utvecklade vår produkt från den första som skulle distribueras på 3AWS, Azure, IBM.â Hur då? Genom att hålla sig till den minsta gemensamma nämnaren som var FaaS/IaaS ([AWS] Lambda, [Amazon] S3, [Amazon] API [Gateway], låter Kubernetes enkelt, eller hur? var verkligen inte lätt. Vi ignorerade också verktyg som kunde ha hjälpt oss mycket [om vi hade stannat kvar med] ett enda moln för att vara multimoln. Var det värt det? â Att flytta mellan givna delade funktioner är möjligt, men det är definitivt inte ett par klick eller ett par Jenkins-jobb bort. Att flytta mellan är ett heltidsjobb. Att hitta hur man gör den där lilla VM-grejen du gjorde i AWS , nu i Azure, kommer att ta tid och lära sig. Och att flytta mellan AWS IAM och Azure [Active Directory]-behörighet? Tid, tid och tid.âÂÂ
Multicloud är med andra ord inte lätt att genomföra, och det är inte migration heller. Betyder det att ingendera i slutändan är värt det? Inte nödvändigtvis. Som Miles Ward, CTO för SADA (en viktig Google Cloud-partner), beskriver det, kan det finnas övertygande skäl att hoppa till ett annat moln. âÂÂFör så många är det bara användarvänlighet och effektivitet att få saker gjorda; för andra är det uppmärksamhet och partnerskap; för en tredje kohort är det absurda kostnadsfördelar; och en fjärde, det är prestanda och tillförlitlighet. Som sådan, när âÂÂkunder ser luckor i ett eller flera av dessa fyra områden ⦠de flyttar .âÂÂ
Ward har förmodligen rätt: Det *kan finnas* övertygande skäl att migrera. Se bara till att göra en fullständig analys av den totala ägandekostnaden för flytten, som måste gå långt utöver âÂÂcloud X erbjuder mig $50 000 i krediter.â Dessutom, innan du bestämmer dig för att rulla ditt eget moln, det är värt att ta med kostnaderna för att hantera all din egen infrastruktur.
