Verdomme, Google, ik wilde niet weer een blog schrijven. Ik heb zo veel te doen. Bloggen kost tijd, energie en creativiteit die ik beter zou kunnen gebruiken: mijn boeken, , mijn spel en zo verder. Maar je hebt me genoeg kwaad gemaakt, dus ik moet dit schrijven.
Laten we dit dus maar aan de orde stellen.
Ik begin met een klein, maar leerzaam verhaal uit de tijd dat ik net bij Google begon te werken. Ik weet dat ik de laatste tijd veel negatiefs over Google heb gezegd, maar het frustreert me wanneer mijn eigen bedrijf regelmatig incompetente zakelijke beslissingen neemt. Toch moet ik zeggen: de interne infrastructuur van Google is echt buitengewoon, je kunt gerust stellen dat er vandaag de dag niets beters is. De oprichters van Google waren veel betere ingenieurs dan ik ooit zal worden, en dit verhaal bevestigt dat slechts.
Eerst wat achtergrondinformatie: Google heeft een technologie voor gegevensopslag genaamd . Dit was een geweldige technische prestatie, een van de eerste (als het niet de eerste was) "oneindig schaalbare" key-value opslag: in feite het begin van NoSQL. Tegenwoordig doet Bigtable het nog steeds goed in een behoorlijk drukke K/V-opslagruimte, maar in die tijd (2005) was het echt geweldig.
Een grappig detail over Bigtable is dat ze interne besturingsobjecten hadden (als onderdeel van de implementatie) genaamd tablet-servers, met grote indexen, en op een gegeven moment werden ze een bottleneck bij het schalen van het systeem. De ingenieurs van Bigtable breken zich het hoofd over hoe ze schaalbaarheid konden implementeren, en plotseling beseften ze dat ze tablet-servers konden vervangen door andere Bigtable-opslagen. Dus Bigtable is een deel van de implementatie van Bigtable. Deze opslagplaatsen zijn op alle niveaus aanwezig.
Een ander interessant detail is dat Bigtable enige tijd populair en alomtegenwoordig binnen Google werd, en elk team zijn eigen opslag had. Op een van de vrijdagse vergaderingen vroeg Larry Page nonchalant: "Waarom hebben we meer dan Ć©Ć©n Bigtable? Waarom kunnen we niet gewoon met Ć©Ć©n toe?" Theoretisch zou Ć©Ć©n opslag voldoende moeten zijn voor alle opslagbehoeften van Google. Natuurlijk schakelden ze nooit volledig over op Ć©Ć©n opslag om praktische redenen van ontwikkeling (bijvoorbeeld de gevolgen van een mogelijke storing), maar de theorie was interessant. ĆĆ©n opslag voor het hele universum (overigens, weet iemand of Amazon dit deed met hun Sable?)
Hoe dan ook, hier is mijn verhaal.
Op dat moment werkte ik iets meer dan twee jaar bij Google, en op een dag ontving ik een e-mail van het engineeringteam van Bigtable met ongeveer deze inhoud:
Beste Steve,
Hallo van het Bigtable-team. We willen u laten weten dat u in datacenter [naam datacenter] een zeer, zeer oud binaire bestand van Bigtable gebruikt. Deze versie wordt niet meer ondersteund, en we willen u helpen overstappen naar de nieuwste versie.
Laat het ons gerust weten als u tijd kunt plannen om samen aan dit probleem te werken.
Met vriendelijke groet,
Het Bigtable-team
Bij Google ontvang je veel e-mail, dus op het eerste gezicht las ik het ongeveer zo:
Beste ontvanger,
Hallo van een of ander team. We willen u laten weten dat bla-bla-bla-bla-bla. Bla-bla-bla-bla-bla-bla, en bla-bla-bla onmiddellijk.
Laat het ons weten als u een deel van uw kostbare tijd kunt plannen voor bla-bla-bla.
Met vriendelijke groet,
Een of ander team
Ik was van plan het onmiddellijk te verwijderen, maar op de rand van mijn bewustzijn voelde ik een onprettig, zeurend gevoel dat dit niet helemaal gelukkig leek op een formele brief, hoewel het duidelijk, dat ze de verkeerde ontvanger hadden, omdat ik Bigtable niet gebruikte.
Maar het was vreemd.
De rest van de dag dacht ik afwisselend aan het werk en aan welk type haaienvlees ik zou moeten proberen in de microkeuken, waarvan er minstens drie dichtbij genoeg waren om met een nauwkeurige worp van een biscuit te raken vanaf mijn plek, maar de gedachte aan de e-mail verliet me niet, met een groeiend gevoel van lichte ongerustheid.
Ze hebben duidelijk mijn naam genoemd. En de brief is naar mijn e-mailadres gestuurd, niet naar dat van iemand anders, en het is geen cc: of bcc:. De toon is heel persoonlijk en duidelijk. Misschien is dit een vergissing?
Uiteindelijk nam mijn nieuwsgierigheid de overhand en ging ik een kijkje nemen bij de Borg-console in de datacenter die ze noemden.
En natuurlijk had ik beheer over een BigTable-opslag. Wat?! Ik keek naar de inhoud en ā wat een verrassing! Het was van de Codelab incubator waar ik mijn eerste week bij Google in juni 2005 zat. Codelab dwong je om Bigtable te starten, zodat je daar enkele waarden in kon schrijven, en blijkbaar had ik die opslag daarna nooit afgesloten. Het werkte nog steeds, hoewel er meer dan twee jaar verstreken waren.
Deze geschiedenis heeft verschillende opmerkelijke aspecten. Ten eerste was het werk van Bigtable zo onbelangrijk in de schaal van Google, dat pas na twee jaar iemand de overbodige opslag opmerkte, en dat alleen maar omdat de binaire versie verouderd was. Ter vergelijking, ik had ooit de mogelijkheid overwogen om te gebruiken voor mijn online spel. In die tijd kostte deze service ongeveer $16.000 per jaar voor lege Bigtable op GCP. Ik zeg niet dat ze je bedriegen, maar naar mijn persoonlijke mening is dat veel geld voor een lege rot database.
Een ander opmerkelijk aspect is dat de opslag nog steeds werkte na twee jaar.. WTF? Datacenters komen en gaan; ze ervaren onderbrekingen, ze ondergaan gepland onderhoud, ze veranderen constant. De hardware wordt vernieuwd, switches worden verplaatst, alles wordt voortdurend verbeterd. Hoe in hemelsnaam hebben ze mijn programma twee jaar lang laten draaien ondanks al deze veranderingen? Dit kan een bescheiden prestatie lijken in 2020, maar in 2005-2007 was het behoorlijk indrukwekkend.
En het meest opmerkelijke aspect is dat een extern ingenieursteam in een andere staat contact met mij opneemt, de eigenaar van een klein, praktisch leeg Bigtable-exemplaar, dat geen verkeer heeft gehad in de afgelopen twee jaar ā en biedt hulp aan om het te vernieuwen.
Ik bedankte hen, verwijderde de opslag en het leven ging verder. Maar dertien jaar later denk ik nog steeds aan deze brief. Omdat ik soms soortgelijke brieven van Google Cloud ontvang. Ze zien er zo uit:
Geachte gebruiker van Google Cloud,
Wij herinneren u eraan dat wij het onderhoud van de service [belangrijke service die u gebruikt] vanaf augustus 2020 beĆ«indigen, waarna u uw instanties niet meer kunt bijwerken. We raden aan over te stappen op de nieuwste versie die momenteel in bĆØta is, waarvoor geen documentatie of migratiepad beschikbaar is en die al verouderd is met onze vriendelijke hulp.
We streven ernaar om deze wijziging zo min mogelijk impact te laten hebben op alle gebruikers van het Google Cloud-platform.
Vrienden voor altijd,
Google Cloud Platform
Maar ik lees zulke brieven vrijwel nooit, omdat ze in werkelijkheid het volgende zeggen:
Beste ontvanger,
Ga naar de hel. Ga weg, ga weg, ga weg. Laat alles wat je doet achter, want het doet er niet toe. Wat telt, is onze tijd. We besteden tijd en geld aan het onderhouden van onze rommel, en we zijn het zat, dus we zullen het niet langer ondersteunen. Dus stop met je verdoemde plannen en begin in onze waardeloze documentatie te graven, smekend om kruimels op forums. En trouwens, onze nieuwe rommel is helemaal anders dan de oude rommel, omdat we dit ontwerp behoorlijk hebben verpest, haha, maar dat is jouw probleem, niet het onze.
We blijven ons inspannen om al je ontwikkelingen binnen een jaar onbruikbaar te maken.
Ga alsjeblieft weg,
Google Cloud Platform
En het is zo dat ik dergelijke brieven ongeveer eens per maand ontvang. Het gebeurt zo vaak en zo constant dat ze onvermijdelijk me hebben afgestoten van GCP naar het kamp van cloudtegenstanders. Ik ben het er niet meer mee eens om afhankelijk te zijn van hun proprietary ontwikkelingen, omdat het voor devops veel gemakkelijker is om een open source-systeem op een kale virtuele machine te ondersteunen dan te proberen de achtervolging aan te gaan met Google en zijn beleid van het beƫindigen van 'verouderde' producten.
Voordat ik terugkeerde naar Google Cloud, omdat ik zelfs maar dichtbij Laten we eens kijken naar het werk van het bedrijf op andere gebieden. Google-ingenieurs zijn trots op hun softwareontwikkelingsdiscipline, maar dat veroorzaakt eigenlijk problemen. Trots is een valkuil voor de onvoorzichtigen; het heeft veel werknemers bij Google doen denken dat hun beslissingen altijd juist zijn en dat juistheid (volgens een vage, onduidelijke definitie) belangrijker is dan zorg voor de klanten.
Ik zal een paar willekeurige voorbeelden uit andere grote projecten buiten Google geven, maar ik hoop dat je dit patroon overal zult zien. Het komt erop neer: achterwaartse compatibiliteit ondersteunt de levensvatbaarheid en relevantie van systemen gedurende tientallen jaren.
Achterwaartse compatibiliteit is een ontwerpprojectdoel voor alle succesvolle systemen die bedoeld zijn voor open gebruik, dat wil zeggen, gerealiseerd met open source en/of op open standaarden. Ik voel dat ik iets te voor de hand liggends zeg, iets wat voor iedereen zelfs ongemakkelijk is, maar dat is niet zo. Dit is een politiek probleem, dus voorbeelden zijn nodig.
Het eerste systeem dat ik kies, het oudste: GNU Emacs, is een soort hybride tussen Kladblok van Windows, het besturingssysteem en het Internationaal Ruimtestation. Het is moeilijk uit te leggen, maar Emacs is in Ć©Ć©n zin een platform, gemaakt in 1976 (ja, bijna een halve eeuw geleden) voor programmeren, om je productiviteit te verhogen, maar het lijkt op een teksteditor.
Ik gebruik Emacs elke godganse dag. Ja, ik gebruik ook IntelliJ elke dag; dit is zelf al een krachtige instrumentele platform geworden. Maar het schrijven van extensies voor IntelliJ is een veel ambitieuzere en complexere taak dan het schrijven van extensies voor Emacs. En belangrijker nog, alles wat voor Emacs geschreven is, blijft eeuwig.
Ik gebruik nog steeds software die ik voor Emacs schreef in 1995. En ik ben ervan overtuigd dat er mensen zijn die modules gebruiken die in de jaren 80 voor Emacs zijn geschreven, zo niet eerder. Af en toe is wat kleine aanpassing nodig, maar dat is echt vrij zeldzaam. Ik weet niets van wat ik ooit voor Emacs heb geschreven (en ik heb veel geschreven), dat de architectuur opnieuw zou moeten worden gebouwd.
Emacs heeft een functie genaamd make-obsolete voor verouderde entiteiten. De terminologie van Emacs voor fundamentele computerconcepten (zoals wat een 'venster' is) verschilt vaak van de industrienormen, omdat Emacs deze termen heel lang geleden heeft geĆÆntroduceerd. Dit is een typisch gevaar voor degenen die hun tijd ver vooruit zijn: al je termen zijn onnauwkeurig. Maar in Emacs bestaat er echt een concept van veroudering, dat in hun jargon wordt genoemd. veroudering.
Maar in de wereld van Emacs lijkt er een andere werkdefinitie te zijn. Een andere fundamentele filosofie, als je het zo wilt noemen.
In de wereld van Emacs (en in veel andere gebieden die we hieronder zullen bespreken) betekent de status van verouderde API's over het algemeen: āJe zou deze benadering eigenlijk niet moeten gebruiken, want hoewel het werkt, heeft het verschillende tekortkomingen die we hier zullen opsommen. Maar uiteindelijk is het jouw keuze.ā
In de wereld van Google betekent de status van een verouderd product: āWe schenden onze verplichtingen jegens jou.ā Dat is echt zo. Dit is in wezen wat het betekent. Het betekent dat ze je zullen dwingen regelmatig een aantal werkzaamheden te verrichten, mogelijk veel werk, als straf voor het feit dat je geloofde in hun : wij hebben de beste software. De snelste! Je volgt alles precies volgens de instructies, start je applicatie of dienst op, en dan ā bam, na een jaar of twee valt het uit.
Het is alsof je een tweedehands auto verkoopt die precies na 1500 km zal stuk gaan.
Dit zijn twee totaal verschillende filosofische definities van 'veroudering'. De definitie van Google ruikt naar . Ik geloof niet dat dit hebben we echt geplande veroudering is in dezelfde zin als bij Apple. Maar Google heeft zeker de intentie om je programma's op een indirecte manier stuk te maken. Ik weet dit omdat ik meer dan 12 jaar als software-engineer daar heb gewerkt. Ze hebben vage interne richtlijnen over in hoeverre ze achterwaartse compatibiliteit moeten waarborgen, maar uiteindelijk is het aan elk afzonderlijk team of dienst. Er zijn geen richtlijnen op bedrijfs- of ingenieursniveau, en de stoutmoedigste aanbeveling als het gaat om verouderingscycli is: 'Probeer klanten 6-12 maanden tijd te geven om te updaten voordat je hun hele systeem kapotmaakt.'
Het probleem is veel ernstiger dan ze denken, en het zal nog vele jaren aanhouden omdat klantgerichte zorg niet in hun DNA zit. Meer hierover hieronder.
Op dit moment ga ik een gedurfde uitspraak doen dat Emacs in hoge mate succesvol is en zelfs in wezen omdat ze zo serieus omgaan met achterwaartse compatibiliteit. Eigenlijk is dit de stelling van ons artikel. Succesvolle, langlevende open systemen danken hun succes aan microgemeenschappen die decennia lang rond uitbreidingen/plugins. Dit is het ecosysteem. Ik heb al eerder nagedacht over de essentie van platforms en hoe belangrijk deze zijn, en dat Google nooit in de hele geschiedenis als bedrijf heeft begrepen wat er komt kijken bij het creƫren van een succesvol open platform, afgezien van Android of Chrome.
Eigenlijk moet ik kort Android noemen, omdat je er vast aan gedacht hebt.
Ten eerste, Android is niet Google. Ze hebben bijna niets met elkaar te maken. Android is een bedrijf dat in juli 2005 door Google is gekocht, dat het recht kreeg relatief autonoom te opereren en in feite in de afgelopen jaren grotendeels met rust gelaten is. Android is een beruchte technische stapel en net zo beruchte organisatie. Zoals een Google-medewerker zei: 'Je kunt niet zomaar binnenkomen in Android.'
In een van mijn eerdere artikelen heb ik al nagedacht over hoe slecht sommige van de vroege ontwerpoplossingen van Android waren. Verdorie, toen ik dat artikel schreef, waren ze bezig met de uitrol van troep genaamd 'instant apps', die nu (verrassing!) , en ik heb medelijden met je als je zo dom was om naar Google te luisteren en je content naar deze instant apps te verplaatsen.
Maar hier is een verschil, een aanzienlijk verschil, dat erin ligt dat de mensen van Android echt begrijpen hoe belangrijk platforms zijn; ze doen er alles aan om de functionaliteit van oude Android-applicaties te behouden. In feite zijn hun inspanningen om de backward compatibility te behouden zo extreem dat zelfs ik, tijdens mijn korte verblijf bij de Android-afdeling enkele jaren geleden, ontdekte dat ik hen probeerde te overtuigen om de ondersteuning voor sommige van de oudste apparaten en API's te laten vallen (ik had ongelijk, zoals bij veel andere dingen in het verleden en het heden. Sorry, jongens van Android! Nu ik in Indonesiƫ ben geweest, begrijp ik waarom ze ons nodig hebben).
De mensen van Android handhaven de backward compatibility tot bijna onvoorstelbare extremen, wat enorme hoeveelheden verouderde technische schulden in hun systemen en toolchains opbouwt. Oh mijn god, je zou sommige gekke dingen moeten zien die ze in hun bouwsysteem moeten doen, en dat alles in het belang van compatibiliteit.
Daarvoor geef ik Android de felbegeerde prijs 'Je bent geen Google'. Ze willen echt niet zoals Google worden, dat geen duurzame platforms kan creƫren, maar Android weet hoe je dat moet doen. weet, en daarom gedraagt Google zich op een zeer verstandige manier door de mensen van Android toe te staan om alles op hun eigen manier te doen.
Echter, instant-applicaties voor Android waren best een dom idee. En weet je waarom? Omdat ze vereisten om je applicatie opnieuw te schrijven en opnieuw te ontwerpen! Alsof mensen zomaar twee miljoen applicaties gaan herschrijven. Ik neem aan dat de instant-applicaties een idee waren van een of andere Googler.
Maar hier is het verschil. Backward compatibility komt met hoge kosten. Android draagt zelf de last van deze kosten, terwijl Google erop staat dat deze last gedragen wordt door jij, de betalende klant.
Je kunt de toewijding van Android aan backward compatibility zien in zijn API's. Wanneer je vier of vijf verschillende subsystemen hebt om letterlijk hetzelfde te doen, is dat een duidelijk teken van toewijding aan backward compatibility. Wat in de wereld van platforms synoniem is met toewijding aan je klanten en je markt.
Het grootste probleem van Google hier is hun trots op hun engineeringhygiĆ«ne. Ze houden er niet van als er veel verschillende manieren zijn om hetzelfde te doen, vooral niet als de oude, minder wenselijke manieren naast de nieuwe, meer eigenaardige manieren staan. Dit verhoogt de leercurve voor nieuwkomers in het systeem, verhoogt de onderhoudslast van verouderde API's, vertraagt de snelheid van nieuwe functies en de grootste zonde ā het ziet er lelijk uit. Google is als de Hertogin van Richmond uit 'Alice in Wonderland' van Tim Burton:
Hertogin van Richmond:
ā Alice, weet je waar ik het meest bang voor ben?
ā Voor de ondergang van de aristocratie?
ā Ik was bang dat ik zou hebben lelijke kleinkinderen.
Om de compromis tussen mooi en praktisch te begrijpen, laten we kijken naar het derde succesvolle platform (na Emacs en Android) en zien hoe het werkt: Java zelf.
In Java zijn er veel verouderde API's. Veroudering is zeer populair onder Java-ontwikkelaars, zelfs populairder dan in de meeste programmeertalen. In Java zelf, de belangrijkste taal en bibliotheken, vindt er voortdurend veroudering van API's plaats.
Neem maar Ć©Ć©n van de duizenden voorbeelden, wordt als verouderd beschouwd. Het is verouderd sinds de release van Java 1.2 in december 1998. Het is 22 jaar geleden dat het verouderd is.
Maar mijn echte code in productie sluit nog steeds threads elke dag. Is dat goed? Absoluut! Ik bedoel, natuurlijk, als ik de code vandaag opnieuw zou schrijven, zou ik het anders implementeren. Maar de code van mijn spel, dat de afgelopen twee decennia honderden duizenden mensen gelukkig heeft gemaakt, is geschreven met een functie voor het sluiten van threads die te lang blijven hangen, en ik heb het nog nooit hoeven veranderen. Ik ken mijn systeem beter dan wie ook, ik heb letterlijk 25 jaar ervaring met het werken met het in productie, en ik kan met zekerheid zeggen: in mijn geval is het sluiten van deze specifieke werkthreads volkomen ongevaarlijk. Het is niet de moeite waard om tijd en moeite te steken in het herschrijven van deze code, en hulde aan Larry Ellison (waarschijnlijk), dat Oracle me niet heeft gedwongen het opnieuw te schrijven.
Waarschijnlijk begrijpt Oracle ook iets van platforms. Wie zal het zeggen.
Bewijzen kun je tegenkomen in alle belangrijke Java API's, die doordrenkt zijn met verouderingsgolven, net als de lijnen van een gletsjer in een canyon. In de Java Swing-bibliotheek zijn er gemakkelijk vijf of zes verschillende toetsenbordnavigatiemanagers (KeyboardFocusManager) te vinden. Het is eigenlijk moeilijk om een Java API te vinden die niet verouderd is. Maar ze functioneren nog steeds! Ik denk dat het Java-team een API pas echt zal verwijderen als de interface een flagrante beveiligingsprobleem veroorzaakt.
Dit is het probleem, jongens: wij, softwareontwikkelaars, zijn allemaal erg druk, en in elk softwaregebied worden we geconfronteerd met concurrerende alternatieven. Op elk moment overwegen programmeurs in taal X taal Y als mogelijke vervanging. Oh, geloof je me niet? Wil je het over Swift hebben? Alsof iedereen migreert naar Swift en niemand het verlaat, toch? Wat weet je weinig. Bedrijven maken zich zorgen over de kosten van dubbele mobiele ontwikkelteams (iOS en Android) en beginnen te begrijpen dat deze cross-platform ontwikkelsystemen met grappige namen, zoals Flutter en React Native, echt werken, en dat je ze kunt gebruiken om de grootte van je mobiele teams te halveren of, aan de andere kant, ze dubbel zo productief te maken. Het draait om echt geld. Ja, er zijn compromissen, maar aan de andere kant: geld.
Stel je hypothetisch voor dat Apple uit domheid een voorbeeld nam aan Guido van Rossum en aankondigde dat Swift 6.0 niet achterwaarts compatibel is met Swift 5.0, veel zoals Python 3 niet compatibel is met Python 2.
Het is waarschijnlijk dat ik dit verhaal tien jaar geleden al vertelde, maar vijftien jaar geleden ging ik naar het OāReilly Foo Camp met Guido, waar ik in een tent zat met Paul Graham en een hoop grote namen. We zaten in de uitputtende hitte te wachten op Larry Page, die met zijn privĆ©helikopter zou komen, terwijl Guido monotoon sprak over "Python 3000", dat hij noemde naar het aantal jaren dat het iedereen zou kosten om te migreren. We vroegen hem steeds weer waarom hij de compatibiliteit schond, en hij antwoordde: āUnicodeā. En we vroegen, als we onze code moesten herschrijven, welke andere voordelen we zouden zien? En hij antwoordde āYoooooooooooooouuuuuuuniiiiiiicoooooooodeā.
Als je Google Cloud Platform SDK ("gcloud") installeert, ontvang je de volgende melding:
Beste ontvanger,
We would like to remind you that support for Python 2 has ended, so you can just forget about it.
... and so on. The circle of life.
But the thing is, every developer has a choice. And if they are forced to rewrite code often enough, they might consider other options. andere They are not your captives, no matter how much you would like that. They are your guests. Python is still a very popular programming language, but, darn it, Python 3(000) has created such a mess within its communities and with its users that the consequences cannot be cleaned up for fifteen years.
How many Python programs have been rewritten in Go (or Ruby, or some other alternative) due to this backward incompatibility? How much new software has been written in something else besides Python, even though it could have been written in Python, if Guido hadn't burned the whole village down? It's hard to say, but Python has clearly suffered. It's a huge mess, and everyone is losing.
So, suppose Apple takes a page out of Guido's book and breaks compatibility. What do you think will happen next? Well, maybe 80ā90% of developers will rewrite their software, if they can. In other words, 10ā20% of the user base will automatically switch to some competing language, like Flutter.
Do this a few times ā and you will lose half of your user base. Just like in sports, current form also matters in the programming world. everythingAnyone who loses half their users in five years will be considered a Big Fat Failure. You need to be on trend in the world of platforms. But this is where dropping support for old versions will eventually ruin you. Because every time you get rid of a portion of developers, you (a) lose them for good because they are angry at you for breaking the contract, and (b) you hand them over to your competitors.
Ironically, I also helped Google become the diva that ignores backward compatibility when I created Grok, a system for analyzing and understanding source code that facilitates automation and tooling based on the code itself ā much like an IDE, but here the cloud service stores materialized views of all billions of lines of Google's source code in a large data repository.
Grok heeft Google krachtige basis gegeven voor geautomatiseerde refactoring door de gehele codebasis (letterlijk in heel Google). Het systeem berekent niet alleen uw opgaande afhankelijkheden (waarvan u afhankelijk bent), maar ook neergaande (die afhankelijk zijn van u), zodat u, wanneer u de API verandert, weet wie u breekt! Dus wanneer veranderingen worden aangebracht, kunt u controleren of elke gebruiker van uw API is bijgewerkt naar de nieuwe versie, en in de praktijk kunt u vaak het proces volledig automatiseren met het hulpmiddel Rosie, dat ze hebben geschreven.
Dit stelt de codebasis van Google in staat om intern bijna bovennatuurlijk 'schoon' te zijn, omdat deze robotachtige dienaren door het huis zwerven en automatisch alles opruimen als ze SomeDespicablyLongFunctionName in SomeDespicablyLongMethodName hebben hernoemd, omdat iemand besloot dat het een lelijke kleinzoon was en dat het moest worden ingeslapen.
En eerlijk gezegd, het werkt best goed voor Googleā¦ intern. Ik bedoel, ja, de Go-gemeenschap in Google lacht vriendelijk om de Java-gemeenschap in Google vanwege hun gewoonte tot voortdurende refactoring. Als je iets N keer opnieuw start, betekent dat niet alleen dat je het N-1 keer hebt verpest, maar na een tijdje wordt het heel duidelijk dat je het waarschijnlijk ook met de N-de poging hebt verpest. Maar over het algemeen blijven ze boven deze drukte en houden ze de code 'schoon'.
De problemen beginnen wanneer ze proberen deze houding op te leggen aan hun cloudklanten en gebruikers van andere API's.
Ik heb je een beetje geĆÆntroduceerd in Emacs, Android en Java; laten we kijken naar het laatste succesvolle en langlevende platform: het web zelf. Kun je je voorstellen hoeveel iteraties HTTP heeft doorgemaakt sinds 1995, toen we knipperende tags <blink> en 'In ontwikkeling' pictogrammen op webpagina's gebruikten.
Maar het werkt nog steeds! En die pagina's werken nog steeds! Ja, jongens, browsers zijn wereldkampioenen in achterwaartse compatibiliteit. Chrome is weer een voorbeeld van een zeldzaam Google-platform waarvan de hoofden goed zijn vastgeschroefd, en zoals je al kunt raden, functioneert Chrome effectief als een geĆÆsoleerd bedrijf, afzonderlijk van de rest van Google.
Ik wil ook onze vrienden onder de besturingssysteemontwikkelaars bedanken: Windows, Linux, NIET APPLE JE BENT APPLE, FreeBSD enzovoorts, voor hun enorme inspanningen op het gebied van achterwaartse compatibiliteit op hun succesvolle platforms (Apple krijgt op zijn best een min-zes, omdat ze constant dingen breken zonder enige goede reden, maar op de een of andere manier weet de gemeenschap dit in elke release op te lossen, en tot nu toe zijn de containers met OS X nog niet volledig verouderdā¦ nog niet).
Maar wacht even, zeggen jullie. Vergelijken we niet appels met peren - autonome softwaresystemen op Ć©Ć©n machine, zoals Emacs/JDK/Android/Chrome, met multi-server systemen en API's, zoals in clouddiensten?
Nou, ik heb hierover gisteren op Twitter geschreven, maar in de stijl van Larry Wall (de maker van de programmeertaal Perl - red.) volgens het principe 'slecht/graag gedaan' heb ik het woord gezocht verouderd op de websites voor ontwikkelaars van Google en Amazon. En hoewel AWS in honderden maal meer diensten aanbiedt dan GCP, vermeldt de ontwikkelaarsdocumentatie van Google ongeveer zeven keer vaker veroudering.
Als iemand van Google dit leest, dan zijn ze vast bereid om diagrammen te trekken in de stijl van Donald Trump, dat ze alles eigenlijk goed doen, en dat ik geen oneerlijke vergelijkingen moet maken, zoals 'het aantal vermeldingen van het woord deprecated in verhouding tot het aantal diensten'.
Maar na zoveel jaren blijft Google Cloud nog steeds dienst nr. 3 (ik heb nog steeds geen artikel geschreven over de mislukte poging om nr. 2 te worden), maar als we de insiders mogen geloven, zijn er enkele zorgen dat ze binnenkort naar nr. 4 kunnen zakken.
Ik heb geen sterke argumenten om mijn stelling te 'bewijzen'. Alles wat ik heb, zijn kleurrijke voorbeelden die ik heb verzameld in 30 jaar als ontwikkelaar. Ik heb al gewezen op de diep filosofische aard van dit probleem; op de een of andere manier is het gepolitiseerd in ontwikkelaarsgemeenschappen. Sommigen zijn van mening dat platformontwikkelaars verantwoordelijk moeten zijn voor compatibiliteit, terwijl anderen vinden dat het de zorg is gebruikers (van de ontwikkelaars zelf). EĆ©n van de twee. En is dat niet echt een politiek vraagstuk, als we beslissen wie de kosten voor gemeenschappelijke problemen moet dragen?
Dus is dit politiek. En er zullen zeker verontwaardigde reacties komen op mijn optreden.
Zoals gebruiker Als gebruiker van het Google-cloudplatform en ook als AWS-gebruiker gedurende twee jaar (terwijl ik bij Grab werkte), kan ik zeggen dat er een enorm verschil is tussen de filosofieƫn van Amazon en Google als het gaat om prioriteiten. Ik ben geen actieve ontwikkelaar op AWS, dus ik weet niet goed hoe vaak ze oude API's verwijderen. Maar ik heb het vermoeden dat dit niet zo vaak voorkomt als bij Google. En ik geloof oprecht dat deze constante bron van geschillen en frustraties in GCP een van de grootste factoren is die de ontwikkeling van het platform belemmeren.
Ik weet dat ik geen specifieke voorbeelden heb genoemd van GCP-systemen waarvan de ondersteuning is stopgezet. Ik kan zeggen dat alles wat ik heb gebruikt, van netwerken (van de oudste tot VPC) tot opslag (Cloud SQL v1-v2), Firebase (nu Firestore met een totaal andere API), App Engine (laten we daar maar niet mee beginnen), cloud endpoints van Cloud Endpoint, en totā¦ ik weet het nietĀ ā absoluut alles dreef me ertoe om de code maximaal om de 2-3 jaar opnieuw te schrijven, en ze hebben de migratie nooit voor je geautomatiseerd, en vaak Alsof dat zo hoort.
En elke keer als ik naar AWS kijk, vraag ik mezelf af waarom ik nog steeds op GCP blijf. Ze lijken duidelijk geen klanten nodig te hebben. Ze hebben kopers. Begrijp het verschil? Laat me het uitleggen.
Google Cloud heeft een , waar mensen hun software-oplossingen aanbieden, en om het effect van een leeg restaurant te vermijden, moesten ze het vullen met enkele aanbiedingen, daarom hebben ze een contract gesloten met het bedrijf Bitnami om een hoop oplossingen te creƫren die met een 'klik op de knop' kunnen worden ingezet, of ik moet zelf 'oplossingen' schrijven, omdat deze niets oplossen. Ze bestaan gewoon als vinkjes, als marketingvullers, en Google heeft zich nooit bekommerd of een van de tools daadwerkelijk werkt. Ik ken productmanagers die aan het stuur zaten, en ik kan je verzekeren dat deze mensen er niet om geven.
Laten we bijvoorbeeld een oplossing met zogenaamd 'klik op de knop'-implementatie nemen. Ik ben doodmoe van de fratsen van Google Cloud SQL, dus begon ik te overwegen om mijn eigen Percona-cluster op te zetten. En deze keer leek Google goed werk te leveren, ze waren van plan me wat tijd en moeite te besparen met Ć©Ć©n druk op de knop!
Nou goed, laten we gaan. We klikken op de link en drukken op deze knop. We kiezen 'Ja' om akkoord te gaan met alle standaardinstellingen en een cluster in ons Google-cloudproject uit te rollen. Haha, het werkt niet. Geen van deze rommel werkt. De tool is nooit getest en begon vanaf het eerste moment te verrotten, en het zal me niet verbazen als meer dan de helft van de 'oplossingen' voor Ć©Ć©n-klik uitrol (nu begrijpen we waarom de aanhalingstekens) niet werkt. over het algemeen werkt niet. Dit is absoluut duister, waar je beter niet naar binnen kunt gaan.
Maar Google roept je gewoon op om het te gebruiken. Ze willen dat je het koopt. Voor hen is het een transactie. Ze willen niet dat je iets ondersteunen. Dit is niet in het DNA van Google. Ja, ingenieurs steunen elkaar, wat blijkt uit mijn verhaal met Bigtable. Maar in producten en diensten voor gewone mensen zijn ze altijd meedogenloos in , die niet voldoet aan de winstgevendheidseisen, zelfs niet als deze miljoenen gebruikers heeft.
En dit vormt een echt probleem voor GCP, omdat dit DNA ten grondslag ligt aan alle cloudaanbiedingen. Ze zijn niet gericht op het ondersteunen van iets; het is algemeen bekend dat ze weigeren om (als een beheerde service) enige derde partijsoftware te hosten totdat, totdat AWS hetzelfde doet en er een succesvol bedrijf omheen bouwt, en wanneer klanten letterlijk hetzelfde eisen. Maar je moet wel moeite doen om Google iets te laten ondersteunen.
Dit gebrek aan ondersteuningscultuur, gecombineerd met het principe 'laten we iets breken om het mooier te maken', vervreemdt ontwikkelaars.
En dat is niet goed als je een duurzame platform wilt bouwen.
Google, word wakker, verdomme. Het is nu 2020. Je verliest nog steeds. Het is tijd om goed in de spiegel te kijken en te antwoorden of je werkelijk in het cloudbedrijf wilt blijven.
Als je wilt blijven, dan moet je stoppen met alles te breken. Mensen, jullie zijn rijk. Wij, ontwikkelaars, dat zijn we niet. Dus als het gaat om wie de last van compatibiliteit draagt, moeten jullie die verantwoordelijkheid nemen. Niet wij.
Want er zijn nog minstens drie echt goede clouds. Ze trekken je aan.
En nu ga ik verder met het repareren van al mijn kapotte systemen. Oh.
Tot de volgende keer!
P. S. Update na aanleiding van het lezen van enkele discussies over dit artikel (de discussies zijn geweldig, trouwens). De ondersteuning voor Firebase is niet stopgezet en er zijn geen plannen waarvan ik weet dat deze bestaan. Toch hebben ze een vervelende streamingfout die ervoor zorgt dat de Java-client stopt in App Engine. Een van hun ingenieurs heeft me geholpen met dit probleem, toen ik bij Google werkte, maar ze hebben de bug nooit echt opgelost, dus ik heb een klote-oplossing, elke dag de GAE-toepassing opnieuw opstarten. En zo is het al vier jaar! Nu hebben ze Firestore. Het zal veel werk kosten om daarop te migreren, omdat het een volledig ander systeem is, en de Firebase-fout zal nooit worden opgelost. Wat kunnen we concluderen? Je kunt hulp krijgen, als je voor een bedrijf werkt. Waarschijnlijk ben ik de enige die Firebase op GAE gebruikt, omdat ik minder dan 100 sleutels opsla in een 100% native toepassing, en het stopt er om de paar dagen mee door een bekende bug. Wat kun je erover zeggen, behalve dat je het op eigen risico moet gebruiken. Ik ga over op Redis.
Ik heb ook gezien dat sommige meer ervaren AWS-gebruikers zeiden dat AWS doorgaans nooit stopt met de ondersteuning van welke service dan ook, en SimpleDB is een uitstekend voorbeeld. Mijn vermoedens dat AWS geen dergelijke ziekte van stopzetting van ondersteuning heeft zoals Google lijken gerechtvaardigd.
Bovendien heb ik opgemerkt dat het team van Google App Engine 20 dagen geleden de hosting van een kritische Go-bibliotheek heeft verbroken door de GAE-toepassing te sluiten van een van de belangrijkste ontwikkelaars van Go. Echt heel dom.
Tot slot heb ik gehoord dat de Google-medewerkers dit probleem al bespreken en in het algemeen met mij eens zijn (ik houd van jullie, jongens!). Maar het lijkt erop dat ze het probleem als onoplosbaar beschouwen, omdat er in de cultuur van Google nooit een goede stimulansstructuur is geweest. Ik denk dat het goed zou zijn om wat tijd vrij te maken om de absoluut fantastische ervaring te bespreken met de ingenieurs van AWS, toen ik bij het bedrijf Grab werkte. Hopelijk in de toekomst!
Ja, in 2005 hadden ze inderdaad verschillende soorten haaienvlees op het gigantische buffet in gebouw 43, en het vlees van de mako-haai was mijn favoriet. Maar tegen 2006 hadden Larry en Sergey al het ongezonde snackvoer verwijderd. Dus tijdens het verhaal over Bigtable in 2007 waren er werkelijk geen haaien meer en heb ik je valselijk bedrogen.
Toen ik vier jaar geleden naar de cloud Bigtable keek (plusminus), was de prijs precies zo. Het lijkt erop dat het nu iets is gedaald, maar het is nog steeds verschrikkelijk veel voor lege opslagcapaciteit, vooral gezien mijn eerste verhaal laat zien hoe nietszeggend een lege grote tabel is in hun schaal.
Sorry dat ik de Apple-gemeenschap heb beledigd en niets goeds over Microsoft heb gezegd, enzovoort. Jullie hebben allemaal gelijk, ik waardeer alle discussies die deze artikel heeft opgeroepen! Maar soms is het nodig om wat te stoken om de discussie op gang te brengen, begrijp je?
Dank je voor het lezen.
Update 2, 19.08.2020. Stripe !
Update 3, 31.08.2020. Ik werd benaderd door een ingenieur van Google in de Cloud Marketplace, die een oude vriend van me bleek te zijn. Hij wilde begrijpen waarom C2D niet werkte, en uiteindelijk kwamen we erachter: de reden was dat ik enkele jaren geleden mijn netwerk had opgezet, en C2D werkt niet in verouderde netwerken vanwege de ontbrekende subnetparameter in hun sjablonen. Denk dat potentiƫle GCP-gebruikers ervoor moeten zorgen dat ze voldoende bekende ingenieurs bij Google hebben...
Bron: habr.com
