Maleït Google, no volia tornar a escriure al blog. Tinc molt a fer. Fer blocs requereix temps, energia i creativitat, que podria aprofitar bé: els meus llibres, , el meu joc i així successivament. Però m'has enfadat prou perquè hagi d'escriure això.
Així que acabem amb això.
Permeteu-me començar amb una història breu però instructiva de quan vaig començar a treballar a Google. Sé que últimament he estat dient moltes coses dolentes sobre Google, però em molesta quan la meva pròpia empresa pren regularment decisions empresarials incompetents. Al mateix temps, hem de donar-li el seu merescut: la infraestructura interna de Google és realment extraordinària, es pot dir que avui no hi ha res millor. Els fundadors de Google van ser molt millors enginyers que jo mai, i aquesta història només confirma aquest fet.
Primer, una mica de fons: Google té una tecnologia d'emmagatzematge de dades anomenada . Va ser un assoliment tècnic notable, un dels primers (si no el primer) magatzem de valors-clau "infinitament escalable" (K/V): essencialment el començament de NoSQL. En aquests dies, Bigtable encara va bé a l'espai d'emmagatzematge K/V bastant concorregut, però en aquell moment (2005) era increïblement genial.
Una cosa curiosa de Bigtable és que tenien objectes de pla de control intern (com a part de la implementació) anomenats servidors de tauletes, amb índexs grans, i en algun moment es van convertir en un coll d'ampolla en escalar el sistema. Els enginyers de Bigtable estaven desconcertats sobre com implementar l'escalabilitat i, de sobte, es van adonar que podien substituir els servidors de tauletes per un altre emmagatzematge de Bigtable. Per tant, Bigtable forma part de la implementació de Bigtable. Aquestes instal·lacions d'emmagatzematge hi són a tots els nivells.
Un altre detall interessant és que durant un temps Bigtable es va fer popular i omnipresent dins de Google, i cada equip tenia el seu propi repositori. Així que en una de les reunions del divendres, Larry Page va preguntar de passada: "Per què tenim més d'una Bigtable? Per què no només un?" En teoria, un emmagatzematge hauria de ser suficient per a totes les necessitats d'emmagatzematge de Google. Per descomptat, mai van anar a només un per motius pràctics de desenvolupament (com les conseqüències d'un possible fracàs), però la teoria era interessant. Un dipòsit per a tot l'Univers (Per cert, algú sap si Amazon va fer això amb el seu Sable?)
De totes maneres, aquí teniu la meva història.
En aquell moment, feia poc més de dos anys que treballava a Google i un dia vaig rebre un correu electrònic de l'equip d'enginyeria de Bigtable que anava com això:
Benvolgut Steve,
Hola de l'equip de Bigtable. Ens agradaria informar-vos que a [nom del centre de dades] esteu utilitzant un binari de Bigtable molt, molt antic. Aquesta versió ja no és compatible i volem ajudar-vos a actualitzar a la darrera versió.
Si us plau, fes-me saber si pots programar un temps per treballar junts en aquest tema.
Tot el millor,
Equip Bigtable
A Google rebeu molt de correu, així que a primera vista vaig llegir una cosa com això:
Benvolgut destinatari,
Hola d'algun equip. Volem comunicar-ho bla bla bla bla bla. Bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla, bla bla bla de seguida.
Si us plau, fes-nos saber si pots programar part del teu preciós temps per bla, bla, bla.
Tot el millor,
Algun tipus d'ordre
Gairebé el vaig esborrar de seguida, però al límit de la meva consciència vaig sentir la sensació dolorosa i molesta que no realment però sembla una carta formal òbviament, que el destinatari s'ha equivocat perquè no vaig fer servir Bigtable.
Però era estrany.
Vaig passar la resta del dia alternativament pensant en la feina i en quina mena de carn de tauró provar a la microcuina, de les quals almenys tres estaven prou a prop per colpejar des del meu seient amb un llançament ben apuntat d'una galeta, però el El fet d'escriure mai em va deixar amb una sensació creixent d'ansietat lleu.
Van dir clarament el meu nom. I el correu electrònic s'ha enviat a la meva adreça de correu electrònic, no a la d'una altra persona, i no és cc: o bcc:. El to és molt personal i clar. Potser això és algun tipus d'error?
Finalment, la curiositat em va imposar i vaig anar a mirar la consola Borg al centre de dades que van esmentar.
I, per descomptat, tenia l'emmagatzematge de BigTable sota gestió. Ho sento, què? Vaig mirar el seu contingut i vaja! Va ser de la incubadora Codelab on vaig seure durant la meva primera setmana a Google el juny de 2005. Codelab us va obligar a executar Bigtable per escriure alguns valors allà i, pel que sembla, mai vaig tancar l'emmagatzematge després d'això. Encara funcionava tot i que havien passat més de dos anys.
Hi ha diversos aspectes destacables d'aquesta història. En primer lloc, el treball de Bigtable era tan insignificant a l'escala de Google que només dos anys després algú es va adonar de l'emmagatzematge addicional, i només perquè la versió del binari estava obsoleta. Per comparar, una vegada vaig pensar en utilitzar per al meu joc en línia. En aquell moment, aquest servei costava aproximadament 16 dòlars anuals. buit Bigtable a GCP. No dic que t'estan estafant, però en la meva opinió personal, això són molts diners per a una base de dades buida.
Un altre aspecte a destacar és que l'emmagatzematge segueix treballant després de dos anys. WTF? Els centres de dades vénen i van; experimenten interrupcions, es fan un manteniment programat, canvien tot el temps. S'actualitza el maquinari, s'intercanvien els interruptors, tot es millora constantment. Com dimonis van poder mantenir el meu programa en funcionament durant dos anys amb tots aquests canvis? Pot semblar un èxit modest el 2020, però el 2005-2007 va ser força impressionant.
I l'aspecte més meravellós és que un equip d'enginyeria extern d'algun altre estat s'acosta a mi, el propietari d'una petita instància gairebé buida de Bigtable, que té trànsit zero durant els darrers dos anys, i ofereixen ajuda per actualitzar-lo.
Els vaig donar les gràcies, vaig eliminar l'emmagatzematge i la vida va continuar com de costum. Però tretze anys després, encara penso en aquella carta. Perquè de vegades rebo correus electrònics similars de Google Cloud. Es veuen així:
Benvolgut usuari de Google Cloud,
Com a recordatori, interromprem el servei [servei essencial que utilitzeu] a partir de l'agost de 2020, després del qual no podreu actualitzar les vostres instàncies. Us recomanem que actualitzeu a l'última versió, que està en fase de proves beta, no té documentació, no té camí de migració i ja està obsoleta amb la nostra amable ajuda.
Ens comprometem a garantir que aquest canvi tingui un impacte mínim en tots els usuaris de la plataforma de Google Cloud.
Millors amics per sempre,
Google Cloud Platform
Però gairebé mai no llegeixo aquestes cartes, perquè el que en realitat diuen és:
Benvolgut destinatari,
Ves a l'infern. Fot-te, fot-te, fot-te. Deixa anar tot el que fas perquè no importa. El que importa és el nostre temps. Perdem temps i diners mantenint la nostra merda i estem cansats d'això, així que ja no ho suportarem. Així que deixeu els vostres putos plans i comenceu a buscar entre la nostra documentació de merda, demanant trossos als fòrums, i, per cert, la nostra merda nova és completament diferent de la merda antiga, perquè hem fet malament aquest disseny, eh, però aquest és el vostre problema, no el nostre.
Continuem fent esforços per garantir que tots els vostres desenvolupaments esdevinguin inutilitzables en un any.
Si us plau, fot
Google Cloud Platform
I el cas és que rebo aquestes cartes aproximadament un cop al mes. Això passa tan sovint i tan constantment que inevitablement allunyat jo de GCP al camp antinúvol. Ja no accepto dependre dels seus desenvolupaments propietaris, perquè de fet és més fàcil per als devops mantenir un sistema de codi obert en una màquina virtual nua que intentar mantenir-se al dia amb Google amb la seva política de tancar productes "obsolets".
Abans torno a Google Cloud perquè jo ni tan sols a prop No s'ha acabat de criticar-los, mirem el rendiment de l'empresa en alguns altres àmbits. Els enginyers de Google estan orgullosos de la seva disciplina d'enginyeria de programari, i això és el que realment causa problemes. L'orgull és una trampa per als incautos, i ha fet que molts empleats de Google pensin que les seves decisions sempre són correctes i que tenir la raó (segons una definició vaga i difusa) és més important que preocupar-se pels clients.
Posaré alguns exemples aleatoris d'altres projectes grans fora de Google, però espero que veieu aquest patró a tot arreu. És el següent: La compatibilitat enrere manté els sistemes vius i actualitzats durant dècades.
La compatibilitat enrere és l'objectiu de disseny de tots els sistemes d'èxit dissenyats obert ús, és a dir, implementat amb codi font obert i/o estàndards oberts. Em sembla que estic dient una cosa massa evident que fins i tot tothom està incòmode, però no. Aquest és un tema polític, per tant calen exemples.
El primer sistema que triaré és el més antic: GNU Emacs, que és una mena d'híbrid entre el Bloc de notes de Windows, el nucli del sistema operatiu i l'Estació Espacial Internacional. És una mica difícil d'explicar, però en poques paraules, Emacs és una plataforma creada l'any 1976 (sí, fa gairebé mig segle) per programar per fer-te més productiu, però disfressat com un editor de text.
Utilitzo Emacs cada dia. Sí, també faig servir IntelliJ cada dia, s'ha convertit en una potent plataforma d'eines per dret propi. Però escriure extensions per a IntelliJ és una tasca molt més ambiciosa i complexa que escriure extensions per a Emacs. I el que és més important, es conserva tot allò escrit per a Emacs per sempre.
Encara faig servir el programari que vaig escriure per a Emacs l'any 1995. I estic segur que algú està utilitzant mòduls escrits per a Emacs a mitjans dels anys 80, si no abans. Pot ser que requereixin una mica de retoc de tant en tant, però això és molt rar. No sé res que hagi escrit per a Emacs (i n'he escrit molt) que requereixi una re-arquitectura.
Emacs té una funció anomenada make-obsolete per a entitats obsoletes. La terminologia d'Emacs per als conceptes informàtics fonamentals (com ara què és una "finestra") sovint difereix de les convencions de la indústria perquè Emacs els va introduir fa molt de temps. Aquest és un perill típic per a aquells que s'avança al seu temps: tots els vostres termes són incorrectes. Però Emacs sí que té un concepte de depreciació, que en el seu argot s'anomena obsolescència.
Però al món Emacs sembla que hi ha una definició de treball diferent. Una filosofia subjacent diferent, si voleu.
Al món d'Emacs (i en moltes altres àrees, que tractarem a continuació), l'estat de l'API obsolet significa bàsicament: "Realment no hauríeu d'utilitzar aquest enfocament, perquè mentre funciona, pateix diverses deficiències que llista aquí. Però al final del dia, és la teva elecció".
Al món de Google, ser obsolet significa: "Estem incomplint el nostre compromís amb tu". Això és cert. Això és el que significa essencialment. Això vol dir que et forçaran regularment fer alguna feina, potser molta, com a càstig per creure-hi : Tenim el millor programari. El més ràpid! Ho fas tot seguint les instruccions, inicies la teva aplicació o servei, i després bam, al cap d'un any o dos es trenca.
És com vendre un cotxe usat que definitivament es trencarà al cap de 1500 km.
Aquestes són dues definicions filosòfiques completament diferents de "obsolescència". Definició de l'olfacte de Google . Això no ho crec de fet obsolescència planificada en el mateix sentit que Apple. Però Google definitivament té previst trencar els vostres programes, d'una manera indirecta. Ho sé perquè hi vaig treballar com a enginyer de programari durant més de 12 anys. Tenen directrius internes vagues sobre quanta compatibilitat enrere s'ha de seguir, però en última instància, depèn de cada equip o servei individual. No hi ha recomanacions a nivell empresarial o d'enginyeria, i la recomanació més atrevida pel que fa als cicles d'obsolescència és "intentar donar als clients entre 6 i 12 mesos per actualitzar abans de trencar tot el seu sistema".
El problema és molt més gran del que pensen i persistirà durant anys perquè l'atenció al client no està al seu ADN. Més sobre això a continuació.
En aquest punt faré una afirmació atrevida que Emacs té èxit en gran mesura i fins i tot bàsicament perquè es prenen molt seriosament la compatibilitat enrere. De fet, aquesta és la tesi del nostre article. Els sistemes oberts d'èxit i de llarga vida deuen el seu èxit a les microcomunitats que han viscut al seu voltant durant dècades. extensions/connectors. Aquest és l'ecosistema. Ja he parlat de la naturalesa de les plataformes i de la importància que tenen, i de com Google mai en tota la seva història corporativa ha entès què passa per crear una plataforma oberta d'èxit fora d'Android o Chrome.
De fet, hauria d'esmentar Android breument perquè probablement hi esteu pensant.
En primer lloc, la Android no és Google. Gairebé no tenen res en comú entre ells. Android és una empresa que va ser comprada per Google el juliol de 2005, la companyia va poder operar de manera més o menys autònoma i, de fet, s'ha mantingut pràcticament intacta durant els anys transcorreguts. Android és una pila de tecnologia notòria i una organització espinosa igualment notòria. Tal com va dir un Googler, "No només podeu iniciar sessió a Android".
En un article anterior, vaig parlar de com de dolentes eren algunes de les primeres decisions de disseny d'Android. Heck, quan vaig escriure aquest article estaven llançant una merda anomenada "aplicacions instantànies" que ara són (sorpresa!) , i em compadoixo si fossis prou estúpid per escoltar Google i traslladar el teu contingut a aquestes aplicacions instantànies.
Però aquí hi ha una diferència, una diferència significativa, que és que la gent d'Android realment entén la importància de les plataformes, fan tot el possible perquè les aplicacions d'Android antigues funcionin. De fet, els seus esforços per mantenir la compatibilitat enrere són tan extrems que fins i tot jo, durant la meva breu estada a la divisió d'Android fa uns anys, em vaig trobar intentant convèncer-los que deixin de donar suport a alguns dels dispositius i API més antics (estava equivocat). , com va passar en moltes altres coses del passat i del present. Ho sento nois Android! Ara que he estat a Indonèsia, entenc per què els necessitem).
La gent d'Android impulsa la compatibilitat cap enrere fins a extrems gairebé inimaginables, acumulant quantitats massives de deute tècnic heretat als seus sistemes i cadenes d'eines. Déu meu, hauríeu de veure algunes de les coses boges que han de fer al seu sistema de compilació, tot en nom de la compatibilitat.
Per això, dono a Android el cobejat premi "No ets Google". Realment no volen convertir-se en Google, que no sap crear plataformes duradores, sinó Android sap, com fer-ho. I, per tant, Google està sent molt intel·ligent en un aspecte: permetre que la gent faci les coses a la seva manera a Android.
Tanmateix, les aplicacions instantànies per a Android eren una idea bastant estúpida. I saps per què? Perquè ho demanaven reescriviu i redissenyeu la vostra aplicació! És com si la gent simplement reescrigués dos milions d'aplicacions. Suposo que Instant Apps va ser una idea d'alguns de Google.
Però hi ha una diferència. La compatibilitat enrere té un cost elevat. Android mateix assumeix la càrrega d'aquests costos, mentre que Google insisteix que la càrrega s'ha de fer càrrec ets, client de pagament.
Podeu veure el compromís d'Android amb la compatibilitat enrere a les seves API. Quan teniu quatre o cinc subsistemes diferents fent literalment el mateix, és un senyal segur que hi ha un compromís amb la compatibilitat enrere al nucli. La qual cosa en el món de les plataformes és sinònim de compromís amb els teus clients i el teu mercat.
El principal problema de Google aquí és el seu orgull per la seva higiene d'enginyeria. No els agrada quan hi ha moltes maneres diferents de fer el mateix, amb les maneres velles i menys desitjables al costat de les maneres noves i més elegants. Augmenta la corba d'aprenentatge per als nous al sistema, augmenta la càrrega de mantenir les API heretades, alenteix la velocitat de les noves funcions i el pecat principal és que no és bonic. Google, com Lady Ascot de l'Alícia al país de les meravelles de Tim Burton:
Lady Ascot:
- Alícia, saps de què tinc més por?
- La decadència de l'aristocràcia?
- Tenia por que ho hauria fet néts lletjos.
Per entendre el compromís entre bonic i pràctic, fem una ullada a la tercera plataforma d'èxit (després d'Emacs i Android) i veiem com funciona: el mateix Java.
Java té moltes API obsoletes. La depreciació és molt popular entre els programadors de Java, fins i tot més popular que en la majoria dels llenguatges de programació. Java mateix, el llenguatge bàsic i les biblioteques estan constantment obsoletes les API.
Per prendre només un dels milers d'exemples, considerada obsoleta. Ha quedat obsolet des del llançament de Java 1.2 el desembre de 1998. Han passat 22 anys des que això va ser obsolet.
Però el meu codi real en producció encara està matant fils tots els dies. De veritat creus que és bo? Absolutament! Vull dir, per descomptat, si hagués de reescriure el codi avui, l'implementaria d'una altra manera. Però el codi del meu joc, que ha fet feliç a centenars de milers de persones durant les últimes dues dècades, està escrit amb una funció per tancar fils que pengen massa, i jo mai ho havia de canviar. Conec el meu sistema millor que ningú, tinc literalment 25 anys d'experiència treballant amb ell en producció, i puc dir amb seguretat: en el meu cas, tancar aquests fils de treball específics és completament sense valor. No val la pena el temps i l'esforç per reescriure aquest codi, i agrair a Larry Ellison (probablement) que Oracle no m'hagi obligat a reescriure-lo.
Probablement Oracle també entén les plataformes. Qui sap.
Es poden trobar proves a les API bàsiques de Java, que estan plenes d'onades d'obsolescència, com les línies d'una glacera en un canó. Podeu trobar fàcilment cinc o sis gestors de navegació de teclat diferents (KeyboardFocusManager) a la biblioteca Java Swing. De fet, és difícil trobar una API de Java que no estigui obsoleta. Però encara funcionen! Crec que l'equip de Java només eliminarà realment una API si la interfície suposa un problema de seguretat evident.
Aquí està la cosa, gent: els desenvolupadors de programari estem molt ocupats i en totes les àrees del programari ens trobem davant d'alternatives competidores. En un moment donat, els programadors del llenguatge X consideren el llenguatge Y com un possible substitut. Oh, no em creus? Vols anomenar-ho Swift? Com, tothom està migrant a Swift i ningú l'abandona, oi? Vaja, que poc en saps. Les empreses estan comptant els costos dels equips de desenvolupament mòbil duals (iOS i Android) i comencen a adonar-se que aquests sistemes de desenvolupament multiplataforma amb noms divertits com Flutter i React Native realment funcionen i es poden utilitzar per reduir la mida del seu equips mòbils dues vegades o, per contra, fer-los dues vegades més productius. Hi ha diners reals en joc. Sí, hi ha compromisos, però, en canvi, diners.
Suposem hipotèticament que Apple va agafar tontament una indicació de Guido van Rossum i va declarar que Swift 6.0 és incompatible cap enrere amb Swift 5.0, de la mateixa manera que Python 3 és incompatible amb Python 2.
Probablement vaig explicar aquesta història fa uns deu anys, però fa uns quinze anys vaig anar al Foo Camp d'O'Reilly amb Guido, vaig asseure's en una tenda de campanya amb Paul Graham i un munt de grans. Ens vam asseure a la calor asfixiant esperant que Larry Page volés amb el seu helicòpter personal mentre Guido feia un xip sobre "Python 3000", que va anomenar pel nombre d'anys que trigaria a tothom a emigrar-hi. Li vam preguntar per què trencava la compatibilitat i va respondre: "Unicode". I vam preguntar, si haguéssim de reescriure el nostre codi, quins altres avantatges veuríem? I ell va respondre: "Yoooooooooooooooooooooooooooooooooooooooooooooooo".
Si instal·leu l'SDK de Google Cloud Platform ("gcloud"), rebreu la notificació següent:
Benvolgut destinatari,
Ens agradaria recordar-vos que el suport per a Python 2 ha quedat obsolet, així que us fot
… etcètera. El cercle de la vida.
Però la qüestió és que cada desenvolupador té una opció. I si els obligueu a reescriure el codi amb prou freqüència, podrien pensar-hi un altre opcions. No són els vostres ostatges, per molt que vulgueu que ho siguin. Són els teus convidats. Python segueix sent un llenguatge de programació molt popular, però carai, Python 3(000) va crear un desastre en si mateix, a les seves comunitats i entre els usuaris de les seves comunitats que les conseqüències no s'han aclarit des de fa quinze anys.
Quants programes Python s'han reescrit a Go (o Ruby, o alguna altra alternativa) a causa d'aquesta incompatibilitat cap enrere? Quant de programari nou s'ha escrit en una altra cosa que no sigui Python, encara que això podria ser escrit en Python, si Guido no hagués cremat tot el poble? És difícil de dir, però Python ha patit clarament. És un gran embolic i tothom perd.
Per tant, suposem que Apple pren un exemple de Guido i trenca la compatibilitat. Què creus que passarà després? Bé, potser el 80-90% dels desenvolupadors reescriuran el seu programari si és possible. En altres paraules, el 10-20% de la base d'usuaris passa automàticament a algun idioma competidor, com Flutter.
Fes-ho diverses vegades i perdràs la meitat de la teva base d'usuaris. Igual que en l'esport, en el món de la programació, la forma actual també importa. tot. Qualsevol que perdi la meitat dels seus usuaris en cinc anys serà considerat un gran perdedor. Has d'estar de moda en el món de les plataformes. Però aquí és on no admetre versions anteriors us arruïnarà amb el temps. Perquè cada vegada que et desfàs d'alguns desenvolupadors, (a) els perds per sempre perquè estan enfadats amb tu per haver trencat el contracte i (b) els regales als teus competidors.
Irònicament, també vaig ajudar a Google a convertir-se en una prima donna que ignora la compatibilitat cap enrere quan vaig crear Grok, un sistema d'anàlisi i comprensió del codi font que facilita automatitzar i instrumentar el codi en si, semblant a un IDE, però aquí les botigues de serveis al núvol. representacions materialitzades de tots els milers de milions de línies del codi font de Google en un gran magatzem de dades.
Grok va proporcionar als Googlers un marc potent per dur a terme refactoritzacions automatitzades a tota la seva base de codis (literalment a tot Google). El sistema calcula no només les vostres dependències aigües amunt (de les quals depeneu), sinó també riu avall (que depèn de vosaltres) així que quan canvieu d'API, coneixeu tots els que esteu trencant! D'aquesta manera, quan feu canvis, podeu comprovar que tots els consumidors de la vostra API s'han actualitzat a la nova versió i, en realitat, sovint amb l'eina Rosie que van escriure, podeu automatitzar completament el procés.
Això permet que la base de codis de Google estigui neta internament de manera gairebé sobrenatural, ja que tenen aquests servents robòtics que corren per la casa i ho netejaran automàticament si canvien el nom de SomeDespicablyLongFunctionName a SomeDespicablyLongMethodName perquè algú va decidir que era un nét lleig i que calia dormir.
I francament, funciona força bé per a Google... internament. Vull dir, sí, la comunitat Go de Google fa una bona rialla amb la comunitat Java de Google a causa del seu hàbit de refactorització contínua. Si reinicieu alguna cosa N vegades, això vol dir que no només l'heu enganxat N-1 vegades, sinó que al cap d'un temps queda clar que probablement també ho heu enganxat a l'enèsim intent. Però, en general, es mantenen per sobre de tot aquest enrenou i mantenen el codi "net".
El problema comença quan intenten imposar aquesta actitud als seus clients al núvol i als usuaris d'altres API.
Us he presentat una mica Emacs, Android i Java; mirem l'última plataforma d'èxit de llarga vida: la mateixa web. Us imagineu quantes iteracions ha passat HTTP des de 1995, quan vam fer servir etiquetes intermitents? i les icones "En construcció" a les pàgines web.
Però encara funciona! I aquestes pàgines encara funcionen! Sí, nois, els navegadors són els campions mundials en retrocompatibilitat. Chrome és un altre exemple de la rara plataforma de Google que té els caps enganxats correctament i, com haureu endevinat, Chrome funciona de manera efectiva com una empresa de sorra separada de la resta de Google.
També vull donar les gràcies als nostres amics dels desenvolupadors de sistemes operatius: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., per fer un treball tan gran de compatibilitat enrere a les seves plataformes d'èxit (Apple obté una C en el millor dels casos amb The L'inconvenient és que ho trenquen tot tot el temps sense una bona raó, però d'alguna manera la comunitat s'escapa amb cada llançament, i els contenidors OS X encara no estan completament obsolets... encara).
Però espera, dius. No estem comparant pomes amb taronges: sistemes de programari autònoms en una sola màquina com Emacs/JDK/Android/Chrome versus sistemes multiservidor i API com els serveis al núvol?
Bé, vaig tuitejar sobre això ahir, però a l'estil de Larry Wall (creador del llenguatge de programació Perl - aprox. per.) sobre el principi de "xup/regles" vaig buscar la paraula. obsolet als llocs de desenvolupadors de Google i Amazon. I encara que AWS ho té centenars vegades més ofertes de serveis que GCP, la documentació per a desenvolupadors de Google esmenta l'obligació aproximadament set vegades més sovint.
Si algú de Google està llegint això, probablement estigui disposat a treure gràfics a l'estil de Donald Trump que mostren que realment ho estan fent tot bé i que no hauria de fer comparacions injustes com "nombre d'esments de la paraula obsolet versus nombre de serveis" "
Però després de tots aquests anys, Google Cloud segueix sent el servei número 3 (mai no vaig escriure un article sobre l'intent fallit de convertir-se en el número 2), però si cal creure-ho, hi ha algunes preocupacions que aviat podrien caure a Núm. 4.
No tinc cap argument convincent per "provar" la meva tesi. Tot el que tinc són els exemples vistosos que he acumulat durant 30 anys com a desenvolupador. Ja he esmentat la naturalesa profundament filosòfica d'aquest problema; d'alguna manera està polititzat a les comunitats de desenvolupadors. Alguns creuen això creadors les plataformes haurien de preocupar-se per la compatibilitat, mentre que altres pensen que això és una preocupació usuaris (els mateixos desenvolupadors). Un de cada dos. De fet, no és una qüestió política quan decidim qui ha d'assumir els costos dels problemes comuns?
Així que això és política. I probablement hi haurà respostes enfadades al meu discurs.
Com l’usuari Google Cloud Platform, i com a usuari d'AWS durant dos anys (mentre treballava per a Grab), puc dir que hi ha una gran diferència entre les filosofies d'Amazon i Google pel que fa a les prioritats. No desenvolupo activament a AWS, així que no sé molt bé amb quina freqüència eliminen les API antigues. Però hi ha la sospita que això no passa tan sovint com a Google. I realment crec que aquesta font de controvèrsia i frustració constant a GCP és un dels principals factors que frenen el desenvolupament de la plataforma.
Sé que no vaig posar exemples concrets de sistemes GCP que ja no són compatibles. Puc dir que gairebé tot el que he utilitzat, des de xarxes (des de les més antigues fins a VPC) fins a emmagatzematge (Cloud SQL v1-v2), Firebase (ara Firestore amb una API completament diferent), App Engine (ni comencem) , punt final del núvol Punt final del núvol i fins a... No ho sé - absolutament tot això us van obligar a reescriure el codi després d'un màxim de 2-3 anys i mai no van automatitzar la migració per a vosaltres, i sovint . Com si hagués de ser així.
I cada vegada que miro AWS, em pregunto per què dimonis encara estic a GCP. És evident que no necessiten clients. Ells necessiten compradors. Enteneu la diferència? Deixa'm explicar.
Google Cloud ho té , on la gent proposa les seves solucions de programari, i per evitar l'efecte restaurant buit, calia omplir-lo amb algunes propostes, així que van contractar amb una empresa anomenada Bitnami per crear un munt de solucions que es despleguen amb "un clic", o haurien de Jo mateix ho escric "solucions", perquè aquestes no solucionen res. Simplement existeixen com a caselles de selecció, com a emplenat de màrqueting, i a Google mai li ha importat si alguna de les eines funciona realment. Conec gestors de producte que han estat al seient del conductor i us puc assegurar que a aquesta gent no els importa.
Preneu, per exemple, una solució de desplegament suposadament "d'un sol clic". . Estava malalt de les travessias de Google Cloud SQL, així que vaig començar a pensar en crear el meu propi clúster Percona com a alternativa. I aquesta vegada Google semblava haver fet una bona feina, m'estalviarien temps i esforç amb el clic d'un botó!
Doncs genial, anem. Seguim l'enllaç i cliquem aquest botó. Seleccioneu "Sí" per acceptar tota la configuració predeterminada i desplegar el clúster al vostre projecte al núvol de Google. Haha, no funciona. Res d'aquesta merda funciona. L'eina no es va provar mai i va començar a podrir-se des del primer minut, i no m'estranyaria que més de la meitat de les "solucions" siguin desplegaments d'un sol clic (ara entenem per què les cometes) en general no funciona. Aquesta és una foscor absolutament desesperada, on és millor no entrar.
Però Google té raó anima tu per utilitzar-los. Ells volen que ho facis comprat. Per a ells és una transacció. No volen res suport. No forma part de l'ADN de Google. Sí, els enginyers es donen suport mútuament, com ho demostra la meva història amb Bigtable. Però en productes i serveis per a la gent normal que sempre van ser despietats , que no compleix el llistó de rendibilitat encara que tingui milions d'usuaris.
I això representa un veritable repte per a GCP perquè aquest és l'ADN darrere de totes les ofertes al núvol. No estan intentant donar suport a res; És ben sabut que es neguen a allotjar (com a servei gestionat) qualsevol programari de tercers fins que, fins que AWS fa el mateix i construeix un negoci d'èxit al seu voltant, i quan els clients, literalment, exigeixen el mateix. Tanmateix, cal esforçar-se perquè Google admeti alguna cosa.
Aquesta manca de cultura de suport, unida a la mentalitat de “trenquem-la per fer-la més bonica”, aliena els desenvolupadors.
I això no és bo si voleu construir una plataforma de llarga vida.
Google, desperta, carai. Ara som el 2020. Encara estàs perdent. És hora de mirar-se al mirall i respondre si realment voleu mantenir-vos al negoci del núvol.
Si vols quedar-te doncs deixa de trencar-ho tot. Nois, sou rics. Els desenvolupadors no ho fem. Per tant, quan es tracta de qui assumirà la càrrega de la compatibilitat, cal que ho assumeixis. No per a nosaltres.
Perquè hi ha almenys tres núvols més molt bons. Fan senyals.
I ara passaré a arreglar tots els meus sistemes trencats. Eh.
Fins la pròxima vegada!
Actualització de PS després de llegir algunes de les discussions sobre aquest article (els debats són fantàstics, per cert). El suport de Firebase no s'ha interromput i no hi ha plans que conec. Tanmateix, tenen un error de reproducció desagradable que fa que el client Java s'atura a App Engine. Un dels seus enginyers em va ajudar a resoldre aquest problema, quan treballava a Google, però en realitat mai no van solucionar l'error, així que tinc una solució alternativa d'haver de reiniciar l'aplicació GAE cada dia. I així ha estat durant quatre anys! Ara tenen Firestore. Es necessitarà molta feina per migrar-hi, ja que és un sistema completament diferent i l'error de Firebase mai es solucionarà. Quina conclusió es pot extreure? Podeu obtenir ajuda si treballes en una empresa. Probablement sóc l'únic que utilitza Firebase a GAE perquè registro menys de 100 claus en una aplicació 100% nativa i deixa de funcionar cada dos dies a causa d'un error conegut. Què puc dir més que utilitzar-lo sota el teu propi risc. Em canvio a Redis.
També he vist que alguns usuaris d'AWS amb més experiència diuen que AWS no deixa de donar suport a cap servei, i SimpleDB n'és un bon exemple. Les meves suposicions que AWS no té la mateixa malaltia de final de suport que Google sembla estar justificada.
A més, em vaig adonar que fa 20 dies l'equip de Google App Engine va trencar l'allotjament d'una biblioteca Go crítica, tancant una aplicació GAE d'un dels desenvolupadors principals de Go. Va ser realment estúpid.
Finalment, he escoltat que els Googlers ja parlen d'aquest tema i que en general estan d'acord amb mi (us estimo nois!). Però sembla que pensen que el problema és insoluble perquè la cultura de Google mai va tenir l'estructura d'incentius adequada. Vaig pensar que seria bo prendre's una estona per parlar de l'experiència absolutament increïble que vaig tenir treballant amb enginyers d'AWS mentre treballava a Grab. Algun dia en el futur, espero!
I sí, l'any 2005 sí que tenien diferents tipus de carn de tauró al bufet gegant de l'edifici 43, i la meva preferida era la carn de tauró martell. Tanmateix, el 2006, Larry i Sergei es van desfer de tots els aperitius poc saludables. Així que durant la història de Bigtable el 2007 realment no hi havia taurons i us vaig enganyar.
Quan vaig mirar el núvol Bigtable fa quatre anys (donar o rebre), aquí és on era el cost. Ara sembla que ha baixat una mica, però això encara és molt important per a un magatzem de dades buit, sobretot perquè la meva primera història mostra com d'inconseqüent és una taula gran buida a la seva escala.
Ho sento per ofendre la comunitat d'Apple i no dir res agradable sobre Microsoft, etc. Estàs bé, agraeixo molt tota la discussió que ha generat aquest article! Però de vegades cal fer onades una mica per iniciar una discussió, saps?
Gràcies per llegir.
Actualització 2, 19.08.2020/XNUMX/XNUMX. ratlla !
Actualització 3, 31.08.2020/2/2. Em va contactar un enginyer de Google a Cloud Marketplace que va resultar ser un vell amic meu. Volia esbrinar per què CXNUMXD no funcionava, i finalment ens vam adonar que era perquè havia construït la meva xarxa fa anys, i CXNUMXD no treballava en xarxes heretades perquè faltava el paràmetre de subxarxa a les seves plantilles. Crec que és millor que els usuaris potencials de GCP s'assegurin que coneixen prou enginyers a Google...
Font: www.habr.com