AWS-fakturering är trasig och Kubernetes håller inte, säger irreverent molnekonom Corey Quinn

AWS-fakturering är trasig och Kubernetes håller inte, säger irreverent molnekonom Corey Quinn Duckbill-gruppens frittalande medgrundare Corey Quinn delar sina tankar om molnindustrin, Walmarts paranoia om AWS, varför Docker nästan är tom för pengar och varför Larry Ellison "är inte människor."

Det finns ganska få människor som tittar på molnen, så att säga, som sätter igång brandlarm när de tar sig till Twitter. Corey Quinn, självutformad molnekonom på The Duckbill Group, är kanske den mest synliga. Quinns Twitter-upptäckt drar inga slag. Han är väldigt övertygad om sina åsikter och presenterar dem i oneliners skräddarsydda för Twitteråldern, som komediestylningar av Stephen Lynch eller Mitch Hedberg, men med betydligt mer fördel:

Om du namnger en konferens efter en e-post ämnesrad, antar jag att re: Invent beats fwd: Check This Shit Out, men inte så mycket.

- Corey Quinn på Monktoberfest (@QuinnyPig) 15 september 2019


TechRepublic intervjuade Quinn om de labyrintiska faktureringsmetoderna hos Amazon Web Services, varför transitprissättning på AWS är en tyst budgetdödare och antagandet av populära tekniktrender som Kubernetes och Docker, samt Walmarts noterade misstro mot AWS och Larry Ellisons skryter med Amazons utdragna migration bort från Oracle.

TechRepublic: Vad är det mest konsekvent fel du ser AWS-användare göra?

Quinn: Det mest konsekventa misstaget som alla gör när de använder AWS - detta sträcker sig också till livet - är när människor lär sig något, de slutar hålla sig uppdaterade om den saken. Det finns ett helt ekosystem av människor som vet något om AWS, med säkerhet. Det är helt enkelt inte längre sant, eftersom kapaciteten förändras. Begränsningarna blir avslappnade. Begränsningar slutar gälla. Om du för några år sedan fick reda på att det bara är tio taggar tillåtna per resurs håller du inte nödvändigtvis uppdaterad för att förstå att den gränsen nu är 50.

TechRepublic: Om jag gav dig en trollstav och du hade kraften att döda tre AWS-produkter, vad skulle de vara?

Quinn: Tre produkter som jag skulle vilja se dödade. Det kommer att vinna mig några fiender som du inte skulle tro. Okej, jag ska ge det ett slag. Jag skulle säga Amazon CodeCommit eftersom det är en distraktion, det är deras GitHub-ekvivalent.

Jag skulle döda deras prissättning för dataöverföring två gånger. Jag kunde ta det ett steg längre, för orsakerna till att jag dödar det varje gång är olika. Den första är att det är helt omöjligt för människor att på förhand ta reda på vad det kommer att kosta, det är oöverträffligt. För det andra har det aldrig sett ett prisfall, vi betalar fortfarande 1998-priser för dataöverföring. Det är verkligen molnens akilleshäl.

Det mest konsekventa misstag som alla gör när de använder AWS - detta sträcker sig också till livet - är att när människor lär sig något, slutar de hålla reda på den saken. Corey Quinn

TechRepublic: Det är mycket mer detaljerat än vad jag förväntade mig. Jag trodde att du skulle döda det en gång för ingress och en gång för utrymme.

Quinn: Nej, nej. Om jag dödar antingen ingress eller utträde kommer det bara att försöka igen.

TechRepublic: Så varför tar Amazon fortfarande ut priser för 1998 för dataöverföring?

Quinn: Jag skulle inte vilja tala ut ur tur, men jag tror att eftersom det är så oöverträffligt så ser du inte någon betydande push back. Det är en av de saker som försvinner i räkningen bakgrundsbrus.

Ja, du har kunder som skickar miljontals dollar på dataöverföring, men de spenderar tiotals miljoner dollar på EC2-instanser eller lagring. Du har inte ett stort dataöverföringsproblem för de flesta arbetsbelastningar förrän du har ett mycket större problem med andra tjänster.

Jag misstänker också att det finns mellan ett gäng olika serviceteam. Det känns som det kanske inte finns en uttrycklig enda ägandepunkt, eller "halsen att kväva", beroende på vilket begrepp du föredrar.


Amazon Web Services: En insiders guide (gratis PDF)


TechRepublic: Är det för att programmerare förlitar sig på föråldrade förståelser av AWS, är det detta som resulterar i stora överföringsräkningar?

Quinn: Jag tror det. Du ser också människor distribuera programvara som inte är skriven med zonaffinitet i åtanke: Du följer bästa praxis, distribuerar saker i flera regioner eller tillgänglighetszoner. Kanske saker som Cassandra eller MongoDB vill göra en replikering mellan dem.

De är inte riktigt byggda med ett öga mot "va. Kanske betalar jag per gigabyte för den replikeringsfaktorn" och "Åh, det visar sig att jag bearbetar petabytes i månaden", och det är inte en överdrift, att betyder att jag spenderar tiotusentals dollar.

I liten skala är mycket av vad AWS gör häftigt och är fantastisk. När du skalar ut det finns det vissa böjningspunkter där det inte längre är vettigt att använda tjänster som är snyggt presentförpackade för dig.

Hanterade NAT Gateway tar till exempel en bearbetningsavgift på 0, 045 USD per GB, ovanpå alla överföringar som passerar genom den. Det är inte så mycket förrän du har enorma mängder trafik till Internet eller S3 som passerar genom det, och sedan spenderar du - i vissa fall - miljoner dollar på det. Det försvinner i bakgrundsljudet i EC2-avsnittet i AWS-lagförslaget. Det dyker inte upp i dataöverföring.

TechRepublic: Hur stora är företagen att hitta sina fickor lättare med en miljon dollar per månad i dataöverföringsavgifter?

Quinn: Här är den roliga delen. Det är lätt att tänka på detta som "Det här är bara multinationella företag som har drabbats av detta." Men vi ser relativt småskaliga startups som påverkas av detta. Det som människor tappar synen är att infrastruktur i nästan alla fall kostar mindre än lön. De människor som driver dessa saker är i sig dyrare än själva infrastrukturen, och att förlora det ur sikte leder till löjliga saker.

Vid någon tidpunkt, sluta minska kostnaderna. Du kommer inte att kosta optimera dig till en bättre affärsmodell. Titta till exempel på Lyft. De sa mycket offentligt att de har åtagit sig att spendera minst 100 miljoner dollar per år till AWS under de kommande tre åren och internet exploderade med passform av, "Det är dumt. Du kan spara så mycket pengar genom att driva dina egna datacenter." Säker. Vid den tiden förlorade de också 900 miljoner dollar per år, så att fördubbla sin AWS-räkning eller sänka den till noll, förändrar inte meningsfullt deras tjänstekonomi. Att klippa Amazon-räkningen, förvånansvärt, bör inte nödvändigtvis vara på deras topp 10-lista med artiklar som de fokuserar på, som företag.

Det som människor tappar synen är att infrastruktur i nästan alla fall kostar mindre än lön. Corey Quinn

Varför Kubernetes är bättre för att bygga ett CV än en plattform

TechRepublic: Ur teknisk synvinkel är lösningen på allt bara att lägga till ytterligare ett lager av abstraktion. Som sagt, vad är ditt klagomål mot Kubernetes?

Quinn: Mitt problem med Kubernetes, som det för närvarande är, är två gånger. För det första är det oerhört komplicerat att förstå och inte bara komma igång utan att upprätthålla det. På sex månader, om du kör detta och plötsligt blir saker trasiga - eller värre, ibland långsamma - hur börjar du diagnostisera det? Det finns en fruktansvärd massa av handen vinka och abstraktioner byggda ovanpå den.

För det andra bygger människor hela sin karriär runt Kubernetes. Om några år kommer ingen att bry sig om det alls. Det kommer att ha förenklats och glidit under medvetenhetens yta. Vi har sett detta i teknik gång på gång och igen. Ursprungligen var det webbservrar. Du måste ha en intim kunskap om GCC-kompilatorflaggor, sedan RPM, sedan YUM, och ... nu är det en kryssruta på en S3-hink. Saker blir inte mer komplexa med tiden.

Just nu är bördan för att underhålla Kubernetes ... minst en miljon dollar, antingen i hanterade konsultföretag eller tekniktid. Det är värdefullt, men det är inte ett slutläge. Jag tror att du på ett säkert sätt kan hoppa till det som kommer utanför för mycket besvär från ett ingenjörsperspektiv.

Det känns också ... precis som du skulle förvänta dig att komma ut från Google. Det är relativt åsikt på ett super nedlåtande sätt. Den har väldigt många rörliga delar. Det är oerhört överdrivet för de flesta arbetsbelastningar som folk lägger på det, men det är "den nya hotnessen" att citera en gammal film, och folk omfamnar den oavsett vad jag säger. Jag brukar vara lite nere på många tekniker som är överhypade. På den andra sidan av myntet har jag vanligtvis rätt.

TechRepublic: Tja, vad, enligt din åsikt, gjorde Docker fel?

Quinn: Mycket. Jag tror att det misstag som de gjorde är att de inte fick vänner. Jag tror att de inte var säker på vad deras affärsmodell skulle bli. Jag tror att de därför var mycket försiktiga med att samarbeta nära med någon. De höll alla på armslängd.

Så att när det visade sig att - som Kubernetes så småningom kommer - plötsligt var det ingen som bryr sig om Docker längre, eftersom containertiden är så långt borta från den intressanta delen av vad det är som de bygger, att det bara spelar ingen roll längre . Det finns ingen historia - jag kanske använder Docker, om du använder Kubernetes är du nästan säkert - men det finns ingen del av den berättelsen där du skickar en check till Docker.

TechRepublic: Hur liknar det med utvecklare av open source-programvara som säger att Amazon tar sitt projekt, erbjuder det i molnet och tjänar pengar på det.

Quinn: Du var tvungen att förvänta dig att det skulle hända. Jag tror att det finns sura druvor. Folk förväntade sig, när de byggde saker med dessa licenser, att alla andra som försökte sälja en produkt skulle bli skit på det. Det visar sig att Amazon inte är det. Människor misstog open source för en affärsmodell, och jag tror att det har efterklang i hela ekosystemet.

Amazon påpekar att de aldrig har klonat ett tjänste- eller open source-projekt som sedan drev dem ur verksamheten. Ta en titt över hela företaget som Mongo, Elastic, RedisLabs, alla klarar sig mycket bra. Om något, hävdar Amazon att detta är en validering av produkten som de har byggt.

Huruvida det är sant eller inte, jag vet inte. Jag brukar inte spendera tillräckligt med tid på navlen i den öppna källvärlden. Det finns många väldigt arga människor med stänk som flyter ut ur munnen när de hänger sammanhängande om giltigheten hos dessa modeller. Inget av dessa företag verkar göra massuppsägningar.

Varför "mer eller mindre allt" är fel med multicloud

TechRepublic: Så vad är fel med multicloud?

Quinn: Som uttryckt, som en bästa praxis, mer eller mindre allt. Det finns några problem med det. Till att börja med tvingar det alla att tillgodose de gemensamma nämnarna som finns mellan molnen, och de är mycket mindre än de flesta tror att de är.

Om du bara använder moln som ett ställe att köra en massa av dina VM: er, fungerar det. Det är irriterande, men det fungerar. Det tar också bort en hel massa erbjudanden på högre nivå. Nu finns det giltiga användningsfall för att göra det. När tillsynsmyndigheterna behöver det, säkert. Det låter vettigt. När dina kunder kräver det finns det tillfällen där du måste böja dig för det oundvikliga.

Men vi ser att människor driver detta som en bästa praxis på greenfield som är att vara artig, nötter. Vem driver det här? Det är en hel massa andra- och tredjedelsoperatörer som vet att om du ska gå all-in på en leverantör, är det inte deras.

Trots att jag fokuserar på AWS: s ekosystem är jag ingen partner. Jag bryr mig inte vilken molnleverantör som ett företag tar. Jag föreslår att de väljer den som fungerar för deras affärsmodell och i många fall, det är väldigt skrytt av att inte AWS, men välja vad det än är och gå in i.

Jag tror att det finns många företag som bankar sina bröst och hävdar "vi gör ingenting med AWS eftersom vi betraktar dem som en konkurrent." Om du går på LinkedIn, använder de många människor vars huvudsakliga fokus är AWS. Så, vem är någon att tro?

TechRepublic: Vad tycker du om Walmarts påstådda paranoia om Amazon och AWS?

Quinn: Jag tror att det är giltigt att inte vilja finansiera dina konkurrenter. Jag tror att det är skitigt att gå till dina leverantörer och dina leverantörer, att vara en mobbing och kräva att de driver sin verksamhet på olika sätt. Jag tror att det talar om enorm osäkerhet. Jag tycker att det lägger mycket av din konkurrensnackdel på mindre företag som mycket väl inte kan ha bandbredd för att närma sig dessa saker, och jag tycker att det är helt ärligt, förkastligt.

Om du vill tävla, tävla på dina fördelar. Inte av vad som skulle vara konkurrensbegränsande beteende, i en fungerande antitrustregleringsmiljö.

TechRepublic: Vad skulle ditt råd vara för att migrera bort från Oracle?

Quinn: Jag tycker att det är en bra idé. Ta en titt på Amazon, som stimuleras mer än de flesta för att flytta från Oracle, och de säger att det fortfarande är i process. Det kommer fortfarande att ta år, och du har Larry Ellison på scenen att kråka om detta. Jag tycker inte att det låter så bra som Oracle tror att det gör. Dessa freaking människor hatar oss och det är fortfarande nästan omöjligt för dem att migrera från vårt nonsens.

Det ger inte nya potentiella kunder de varma fuzzierna eftersom du vet att varje gång du väljer en databasleverantör kommer det att vara lock-in. Men att säga att några av de mest tekniskt skickliga människorna på planeten, hos Amazon, som är otroligt motiverade att göra detta sätt snabbare än nästan något annat företag på planeten, fortfarande inte har kommit dit? Det säger mycket. Inte mycket av det bra.

Att bli ansiktet av fakturering på Amazon Web Services

Detta är Corey Quinns faktiska huvudskott.

Bild: The Duckbill Group

TechRepublic: Hur avslutade du dig i den här positionen? Hur blev du Corey Quinn?

Quinn: Mitt tidigare jobb körde verksamhet hos en gigantisk kapitalförvaltare. Jag åkte dit genom förvärv och som det visar sig fungerar min personlighet exakt lika bra som du tror att det skulle göra i en stor sammansatt reglerad finansinstitution.

Jag dablade med att konsultera och stänga i flera år och jag tänkte, om jag skulle ... driva ett konsultföretag på det sätt som jag ville, vad skulle jag bry mig om? Jag vill att det ska byggas kring ett dyrt problem som folket skulle vara villiga att försvinna på ett sätt, och eftersom jag under min karriär har hanterat några ganska kränkande samtalsmiljöer, ville jag att det skulle vara ett problem som var strikt arbetstid, så ingen väcker mig och skriker klockan 2.

Till att börja med var jag rädd för att Amazon skulle fixa faktureringssystemet och göra mig ur verksamhet inom sex månader. Nu är jag rädd att de aldrig kommer att göra det.

Mina utsikter, när jag pratar med dem, säger de inte, "Inte intresserad. Nej." De säger: "Inte det här kvartalet. Kan vi prata snart igen?" Detta problem försvinner inte på egen hand. Min marknadsföring är inkommande, jag har inte ett försäljningskontor som ringer för dollar på konsultsidan.

Att bli varumärket för AWS-fakturering är lite svårt. Så jag gjorde det var genom att äntligen omfamna det som alltid fick mig i allvarliga problem med tidigare jobb: min personlighet.

I de flesta företag kan du inte få en representant att gå på scenen och, mer eller mindre, riva Amazon en ny över något beslut de har fattat och inte har fallit ut för det. Vad kommer Amazon att göra när du äger företaget och företaget är byggt runt ditt varumärke? Ta bort min födelsedag? Jag ser inte detta som ett betydligt stort hot mot dem.

TechRepublic: Så du har gjort snark till en supermakt.

Quinn: Jag har det och jag försöker vara rättvis mot dem. Det finns tillfällen jag säger fina saker om Amazon. Det finns tillfällen jag säger skitliga saker om dem, och jag försöker göra det globalt. Jag har också en stående regel, jag gör inte skoj med enskilda människor. Förutom Larry Ellison, som inte är människor. Han kör effektivt på en gallon med spädbarnsblod, eller något. Han har inte vänner eller familj som älskar och bryr sig om honom för att kränkas på hans vägnar - för att han är Larry Ellison - så jag har en speciell dispens. Men för resten, när jag nämner någon med namnet, är det upplyftande och humoristiskt.

Cloud och allt som ett nyhetsbrev för tjänster

Det här är din resurs för det senaste om AWS, Microsoft Azure, Google Cloud Platform, XaaS, molnsäkerhet och mycket mer. Levereras måndagar

Registrera dig idag

© Copyright 2020 | mobilegn.com