Maldito Google, non quería volver bloguear. Teño moito que facer. A creación de blogs leva tempo, enerxía e creatividade, que podería aproveitar ben: os meus libros, , o meu xogo e así por diante. Pero xa me cabreches o suficiente como para que teña que escribir isto.
Entón, imos acabar con isto.
Permítanme comezar cunha historia breve pero instrutiva de cando comecei a traballar en Google. Sei que últimamente digo moitas cousas malas sobre Google, pero molestame cando a miña propia empresa toma regularmente decisións comerciais incompetentes. Ao mesmo tempo, hai que darlle o seu debido: a infraestrutura interna de Google é verdadeiramente extraordinaria, é seguro dicir que non hai nada mellor hoxe. Os fundadores de Google foron moito mellores enxeñeiros do que serei eu, e esta historia só confirma ese feito.
En primeiro lugar, un pequeno fondo: Google ten unha tecnoloxía de almacenamento de datos chamada . Foi un logro técnico notable, un dos primeiros (se non o primeiro) almacén de valores clave (K/V) "infinitamente escalables": esencialmente o comezo de NoSQL. Estes días Bigtable aínda está a facer ben no espazo de almacenamento K/V bastante ateigado, pero naquel momento (2005) era incriblemente xenial.
Unha cousa curiosa de Bigtable é que tiñan obxectos do plano de control interno (como parte da implementación) chamados servidores de tabletas, con índices grandes, e nalgún momento convertéronse nun pescozo de botella ao escalar o sistema. Os enxeñeiros de Bigtable estaban desconcertantes sobre como implementar a escalabilidade e de súpeto déronse conta de que podían substituír os servidores de tabletas por outro almacenamento de Bigtable. Polo tanto, Bigtable forma parte da implementación de Bigtable. Estas instalacións de almacenamento están aí en todos os niveis.
Outro detalle interesante é que durante un tempo Bigtable fíxose popular e omnipresente dentro de Google, tendo cada equipo o seu propio repositorio. Entón, nunha das reunións do venres, Larry Page preguntou casualmente de pasada: "Por que temos máis dunha Bigtable? Por que non só un?" En teoría, un almacenamento debería ser suficiente para todas as necesidades de almacenamento de Google. Por suposto, nunca acudiron só a un por razóns prácticas de desenvolvemento (como as consecuencias dun posible fracaso), pero a teoría era interesante. Un repositorio para todo o Universo (Por certo, alguén sabe se Amazon fixo isto co seu Sable?)
En fin, aquí está a miña historia.
Nese momento, levaba pouco máis de dous anos traballando en Google e un día recibín un correo electrónico do equipo de enxeñería de Bigtable que dicía algo así:
Estimado Steve,
Saúdos do equipo de Bigtable. Queremos informarte de que en [nome do centro de datos] estás a usar un binario de Bigtable moi, moi antigo. Esta versión xa non é compatible e queremos axudarche a actualizar á versión máis recente.
Avísame se podes programar algún tempo para traballar xuntos neste problema.
Todo o mellor,
Equipo Bigtable
En Google recibes moito correo, así que a primeira vista lin algo así:
Estimado destinatario,
Saúdos dalgún equipo. Queremos comunicar que bla, bla, bla, bla. Bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla, bla de inmediato.
Indícanos se podes programar parte do teu precioso tempo para bla, bla, bla.
Todo o mellor,
Algún tipo de mando
Case o borrei de inmediato, pero no límite da miña conciencia sentín unha dolorosa e molesta sensación de que non completamente aínda que parece unha carta formal obviamente, que o destinatario equivocouse porque non usei Bigtable.
Pero era estraño.
Pasei o resto do día pensando alternativamente no traballo e que tipo de carne de quenlla probar na microcociña, dos cales polo menos tres estaban o suficientemente preto como para golpear dende o meu asento cun lanzamento ben apuntado dun biscoito, pero o O pensamento de escribir nunca me deixou cunha crecente sensación de ansiedade leve.
Dixeron claramente o meu nome. E o correo electrónico enviouse ao meu enderezo de correo electrónico, non ao de outra persoa, e non é cc: ou bcc:. O ton é moi persoal e claro. Quizais isto sexa algún tipo de erro?
Finalmente, a curiosidade superoume e fun mirar a consola Borg no centro de datos que mencionaron.
E, por suposto, tiña almacenamento de BigTable xestionado. Síntoo, que? Mirei o seu contido, e vaia! Foi da incubadora Codelab na que me sentei durante a miña primeira semana en Google en xuño de 2005. Codelab obrigouche a executar Bigtable para escribir algúns valores alí e, ao parecer, nunca pechei o almacenamento despois diso. Seguía funcionando aínda que pasaran máis de dous anos.
Hai varios aspectos destacables desta historia. En primeiro lugar, o traballo de Bigtable foi tan insignificante na escala de Google que só dous anos despois alguén se decatou do almacenamento extra, e só porque a versión do binario estaba desactualizada. A modo de comparación, unha vez considerei usar para o meu xogo en liña. Nese momento, este servizo custaba aproximadamente 16 dólares ao ano. baleiro Bigtable en GCP. Non digo que che estean estafando, pero na miña opinión persoal, iso é moito diñeiro para unha base de datos baleira.
Outro aspecto destacable é que o almacenamento aínda traballando despois de dous anos. WTF? Os centros de datos van e veñen; experimentan interrupcións, fan un mantemento programado, cambian todo o tempo. Actualízase o hardware, cámbianse os interruptores, todo se mellora constantemente. Como diaños foron capaces de manter o meu programa funcionando durante dous anos con todos estes cambios? Este pode parecer un logro modesto en 2020, pero en 2005-2007 foi bastante impresionante.
E o aspecto máis marabilloso é que un equipo de enxeñería externo noutro estado achégase a min, o propietario dunha pequena instancia case baleira de Bigtable, que ten tráfico cero nos últimos dous anos, e ofrecen axuda para actualizalo.
Dínlles as grazas, eliminei o almacenamento e a vida continuou como sempre. Pero trece anos despois, sigo pensando nesa carta. Porque ás veces recibo correos electrónicos similares de Google Cloud. Parecen así:
Estimado usuario de Google Cloud,
Como recordatorio, interromperemos o servizo [servizo esencial que utilizas] a partir de agosto de 2020, despois do cal non poderás actualizar as túas instancias. Recomendamos actualizar á versión máis recente, que está en probas beta, non ten documentación, non ten ruta de migración e xa está desactualizada coa nosa amable axuda.
Comprometémonos a garantir que este cambio teña un impacto mínimo en todos os usuarios da plataforma Google Cloud.
Mellores amigos para sempre,
Google Cloud Platform
Pero case nunca lin esas cartas, porque o que realmente din é:
Estimado destinatario,
Vai ao inferno. Fódete, fódete, fódete. Deixa todo o que fas porque non importa. O que importa é o noso tempo. Perdemos tempo e cartos mantendo a nosa merda e estamos cansados diso así que non o apoiaremos máis. Así que deixa os teus putos plans e comeza a buscar a nosa documentación de merda, pedindo anacos nos foros e, por certo, a nosa nova merda é completamente diferente á antiga, porque fomos bastante mal este deseño, heh, pero ese é o teu. problema, non o noso.
Seguimos facendo esforzos para garantir que todos os seus desenvolvementos queden inservibles nun ano.
Por favor, vete
Google Cloud Platform
E o caso é que recibo este tipo de cartas aproximadamente unha vez ao mes. Isto ocorre tan a miúdo e tan constantemente que inevitablemente afastado eu de GCP ao campamento anti-nube. Xa non estou de acordo en depender dos seus desenvolvementos propietarios, porque de feito é máis fácil para os devops manter un sistema de código aberto nunha máquina virtual espida que tratar de seguir o ritmo de Google coa súa política de pechar produtos "obsoletos".
Antes de volver a Google Cloud porque eu nin sequera preto non rematou de criticalos, vexamos o desempeño da empresa noutros ámbitos. Os enxeñeiros de Google se enorgullecen da súa disciplina de enxeñaría de software, e isto é o que realmente causa problemas. O orgullo é unha trampa para os incautos e levou a moitos empregados de Google a pensar que as súas decisións sempre son correctas e que ter razón (según algunha definición vaga e difusa) é máis importante que preocuparse polos clientes.
Vou dar algúns exemplos aleatorios doutros grandes proxectos fóra de Google, pero espero que vexa este patrón en todas partes. É o seguinte: A compatibilidade con versións anteriores mantén os sistemas vivos e actualizados durante décadas.
A compatibilidade con versións anteriores é o obxectivo de deseño de todos os sistemas exitosos para os que se deseña aberto uso, é dicir, implementado con código fonte aberto e/ou estándares abertos. Sinto que estou dicindo algo demasiado obvio que ata todos están incómodos, pero non. Esta é unha cuestión política, polo que son necesarios exemplos.
O primeiro sistema que escollerei é o máis antigo: GNU Emacs, que é unha especie de híbrido entre o Bloc de notas de Windows, o núcleo do sistema operativo e a Estación Espacial Internacional. É un pouco difícil de explicar, pero en poucas palabras, Emacs é unha plataforma creada en 1976 (si, hai case medio século) para programar para facerche máis produtivo, pero disfrazado de editor de texto.
Eu uso Emacs todos os días. Si, tamén uso IntelliJ todos os días, converteuse nunha poderosa plataforma de ferramentas por dereito propio. Pero escribir extensións para IntelliJ é unha tarefa moito máis ambiciosa e complexa que escribir extensións para Emacs. E máis importante, todo o escrito para Emacs consérvase para sempre.
Aínda uso o software que escribín para Emacs en 1995. E estou seguro de que alguén está a usar módulos escritos para Emacs a mediados dos 80, se non antes. Poden requirir un pequeno axuste de cando en vez, pero isto é bastante raro. Non sei nada que escribín para Emacs (e escribín moito) que requira unha re-arquitectura.
Emacs ten unha función chamada make-obsolete para entidades obsoletas. A terminoloxía de Emacs para conceptos informáticos fundamentais (como o que é unha "xanela") a miúdo difire das convencións da industria porque Emacs presentounos hai moito tempo. Este é un perigo típico para aqueles que se adiantan ao seu tempo: todos os seus termos son incorrectos. Pero Emacs ten un concepto de desaprobación, que na súa xerga chámase obsolescencia.
Pero no mundo de Emacs parece haber unha definición de traballo diferente. Unha filosofía subxacente diferente, se queres.
No mundo de Emacs (e en moitas outras áreas, que trataremos a continuación), o estado da API obsoleta significa basicamente: "Realmente non deberías usar este enfoque, porque mentres funciona, padece varias deficiencias que imos lista aquí. Pero ao final do día, é a túa elección".
No mundo de Google, ser obsoleto significa: "Incumprimos o noso compromiso contigo". É verdade. Isto é o que significa esencialmente. Isto significa que te obrigarán regularmente facer algún traballo, quizais moito, como castigo por crer neles : Temos o mellor software. O máis rápido! Fais todo segundo as instrucións, inicias a túa aplicación ou servizo, e despois bam, despois dun ou dous anos rompe.
É como vender un coche usado que definitivamente se avaria despois de 1500 km.
Estas son dúas definicións filosóficas completamente diferentes de "obsolescencia". Definición de cheiro de Google . Non o creo de feito obsolescencia planificada no mesmo sentido que Apple. Pero Google definitivamente planea romper os teus programas, dun xeito indirecto. Seino porque traballei alí como enxeñeiro de software durante máis de 12 anos. Teñen pautas internas vagas sobre canto se debe seguir a compatibilidade con versións anteriores, pero en última instancia, depende de cada equipo ou servizo individual. Non hai recomendacións de nivel empresarial ou de enxeñería, e a recomendación máis atrevida en termos de ciclos de obsolescencia é "intentar dar aos clientes entre 6 e 12 meses para actualizar antes de romper todo o seu sistema".
O problema é moito máis grande do que pensan, e persistirá durante anos porque a atención ao cliente non está no seu ADN. Máis sobre isto a continuación.
Neste punto vou facer unha declaración ousada de que Emacs ten éxito en gran medida e mesmo basicamente porque se toman tan en serio a compatibilidade cara atrás. En realidade, esta é a tese do noso artigo. Os sistemas abertos exitosos e de longa duración deben o seu éxito ás microcomunidades que viviron ao seu redor durante décadas extensións/complementos. Este é o ecosistema. Xa falei sobre a natureza das plataformas e o importante que son, e como Google nunca en toda a súa historia corporativa entendeu o que implica crear unha plataforma aberta exitosa fóra de Android ou Chrome.
En realidade, debería mencionar Android brevemente porque probablemente estea pensando niso.
En primeiro lugar Android non é Google. Case nada teñen en común entre eles. Android é unha empresa que foi adquirida por Google en xullo de 2005, permitiuse que a empresa operase de forma máis ou menos autónoma e, de feito, mantívose en gran parte intacta nos anos intermedios. Android é unha pila de tecnoloxía notoria e unha organización espinosa igualmente notoria. Como dixo un Googler: "Non podes iniciar sesión en Android".
Nun artigo anterior, discutín o mal que foron algunhas das primeiras decisións de deseño de Android. Diablos, cando escribín ese artigo estaban lanzando unha merda chamada "aplicacións instantáneas" que agora son (sorpresa!) , e simpatizo por se fose o suficientemente estúpido como para escoitar a Google e mover o seu contido a estas aplicacións instantáneas.
Pero aquí hai unha diferenza, unha diferenza significativa, que é que a xente de Android realmente entende o importantes que son as plataformas, intentan o mellor para manter as antigas aplicacións de Android funcionando. De feito, os seus esforzos por manter a compatibilidade con versións anteriores son tan extremos que ata eu, durante a miña breve etapa na división de Android hai uns anos, atopeime a min mesmo tentando convencelos de que abandonasen o soporte para algúns dos dispositivos e API máis antigos (equivoqueime). , como ocorreu en moitas outras cousas pasadas e presentes. Perdón, rapaces Android! Agora que estiven en Indonesia, entendo por que os necesitamos).
Os usuarios de Android impulsan a compatibilidade cara atrás ata extremos case inimaxinables, acumulando cantidades enormes de débeda técnica antiga nos seus sistemas e cadeas de ferramentas. Oh meu deus, deberías ver algunhas das cousas tolas que teñen que facer no seu sistema de compilación, todo en nome da compatibilidade.
Por iso, outorgo a Android o cobizado premio "You're Not Google". Realmente non queren converterse en Google, que non sabe crear plataformas duradeiras, senón en Android sabe, como facelo. Google está sendo moi intelixente nun aspecto: permitir que as persoas fagan as cousas á súa maneira en Android.
Non obstante, as aplicacións instantáneas para Android foron unha idea bastante estúpida. E sabes por que? Porque esixían reescribe e redeseña a túa aplicación! É coma se a xente simplemente reescriba dous millóns de aplicacións. Supoño que Instant Apps foi unha idea de Googler.
Pero hai unha diferenza. A compatibilidade con versións anteriores ten un custo elevado. O propio Android soporta a carga destes custos, mentres que Google insiste en que a carga sexa asumida vostede é, cliente de pago.
Podes ver o compromiso de Android coa compatibilidade con versións anteriores nas súas API. Cando tes catro ou cinco subsistemas diferentes facendo literalmente o mesmo, é un sinal seguro de que hai un compromiso coa compatibilidade con versións anteriores no núcleo. O que no mundo das plataformas é sinónimo de compromiso cos teus clientes e co teu mercado.
O principal problema de Google aquí é o seu orgullo pola súa hixiene de enxeñería. Non lles gusta cando hai moitas formas diferentes de facer o mesmo, coas formas antigas e menos desexables sentadas xunto ás formas novas e máis elegantes. Aumenta a curva de aprendizaxe para os novos no sistema, aumenta a carga de manter as API legadas, diminúe a velocidade das novas funcións e o pecado principal é que non é bonito. Google, como Lady Ascot da Alicia no país das marabillas de Tim Burton:
Lady Ascot:
- Alicia, sabes do que máis medo?
- Decadencia da aristocracia?
-Tiña medo de que o faría netos feos.
Para comprender o compromiso entre fermoso e práctico, vexamos a terceira plataforma exitosa (despois de Emacs e Android) e vexamos como funciona: o propio Java.
Java ten moitas API obsoletas. O desuso é moi popular entre os programadores de Java, aínda máis popular que na maioría das linguaxes de programación. O propio Java, a linguaxe principal e as bibliotecas están constantemente en desuso das API.
Por poñer só un dos miles de exemplos, consideradas obsoletas. Quedou obsoleto desde o lanzamento de Java 1.2 en decembro de 1998. Xa pasaron 22 anos desde que este foi obsoleto.
Pero o meu código real en produción aínda está matando fíos todos os días. De verdade pensas que é bo? Absolutamente! Quero dicir, por suposto, se tivese que reescribir o código hoxe, implementaríao de forma diferente. Pero o código do meu xogo, que fixo felices a centos de miles de persoas nas últimas dúas décadas, está escrito cunha función para pechar fíos que colgan demasiado, e eu nunca tivo que cambialo. Coñezo o meu sistema mellor que ninguén, teño literalmente 25 anos de experiencia traballando con el na produción e podo dicir con certeza: no meu caso, pechar estes fíos de traballo específicos é completamente inocuo. Non paga a pena o tempo e esforzo para reescribir este código, e agradecerlle a Larry Ellison (probablemente) que Oracle non me obrigase a reescribilo.
Oracle probablemente entenda tamén as plataformas. Quen sabe.
Pódense atopar probas en todas as API básicas de Java, que están plagadas de ondas de obsolescencia, como as liñas dun glaciar nun canón. Podes atopar facilmente cinco ou seis xestores de navegación de teclado diferentes (KeyboardFocusManager) na biblioteca Java Swing. En realidade, é difícil atopar unha API de Java que non estea obsoleta. Pero aínda funcionan! Creo que o equipo de Java só eliminará realmente unha API se a interface supón un problema de seguridade evidente.
Aquí está a cousa, xente: os desenvolvedores de software estamos todos moi ocupados e en todas as áreas do software atopámonos con alternativas competidoras. Nun momento dado, os programadores na linguaxe X están considerando a linguaxe Y como unha posible substitución. Ai, non me cres? Queres chamalo Swift? Como, todo o mundo está migrando a Swift e ninguén o abandona, non? Vaia, que pouco sabes. As empresas están contando os custos dos equipos de desenvolvemento móbil dual (iOS e Android) e comezan a darse conta de que eses sistemas de desenvolvemento multiplataforma con nomes divertidos como Flutter e React Native realmente funcionan e poden usarse para reducir o tamaño dos seus dispositivos. equipos móbiles dúas veces ou, pola contra, facelos dúas veces máis produtivos. Hai diñeiro real en xogo. Si, hai compromisos, pero, por outra banda, cartos.
Supoñamos hipotéticamente que Apple tomou un indicio de Guido van Rossum e declarou que Swift 6.0 é incompatible con Swift 5.0, ao igual que Python 3 é incompatible con Python 2.
Probablemente contei esta historia hai uns dez anos, pero hai uns quince anos fun ao Foo Camp de O'Reilly con Guido, sentei nunha tenda con Paul Graham e un montón de grandes tiros. Sentámonos na calor abafante esperando a que Larry Page voase no seu helicóptero persoal mentres Guido voaba sobre "Python 3000", que chamou polo número de anos que tardarían todos en migrar alí. Seguimos preguntándolle por que rompía a compatibilidade e el respondeu: "Unicode". E preguntamos, se tivésemos que reescribir o noso código, que outros beneficios veríamos? E el respondeu: "Yoooooooooooooooooooooooooooooooooooooooooo".
Se instalas o SDK de Google Cloud Platform ("gcloud"), recibirás a seguinte notificación:
Estimado destinatario,
Queremos lembrarche que a compatibilidade con Python 2 quedou en desuso, así que que te jodas
… etcétera. Círculo da vida.
Pero a cuestión é que cada desenvolvedor ten unha opción. E se os obrigas a reescribir código a miúdo, poderían pensar outro opcións. Non son os teus reféns, por moito que quixeses que sexan. Son os teus convidados. Python segue sendo unha linguaxe de programación moi popular, pero carallo, Python 3(000) creou tal desorde en si mesmo, nas súas comunidades e entre os usuarios das súas comunidades que hai quince anos que non se aclaran as consecuencias.
Cantos programas Python foron reescritos en Go (ou Ruby, ou algunha outra alternativa) por mor desta incompatibilidade cara atrás? Canto software novo se escribiu en algo que non sexa Python, aínda que iso podería ser escrito en Python, se Guido non queimara toda a aldea? É difícil dicilo, pero Python sufriu claramente. É unha gran desorde e todos perden.
Entón, digamos que Apple toma un exemplo de Guido e rompe a compatibilidade. Que cres que vai pasar a continuación? Ben, quizais o 80-90% dos desenvolvedores reescriba o seu software se é posible. Noutras palabras, o 10-20% da base de usuarios vai automaticamente a algún idioma competidor, como Flutter.
Fai isto varias veces e perderás a metade da túa base de usuarios. Igual que no deporte, no mundo da programación, a forma actual tamén importa. todo. Calquera que perda a metade dos seus usuarios en cinco anos será considerado un gran perdedor. Debes estar de moda no mundo das plataformas. Pero aquí é onde non admitir versións antigas arruinaráche co paso do tempo. Porque cada vez que te desfaces dalgúns programadores, (a) pérdesos para sempre porque están enfadados contigo por incumprir o contrato e (b) pérdesos ante os teus competidores.
Irónicamente, tamén axudei a Google a converterse nunha prima donna que ignora a compatibilidade con versións anteriores cando creei Grok, un sistema de análise e comprensión do código fonte que facilita a automatización e a instrumentación do propio código, de xeito similar a un IDE, pero aquí se almacenan os servizos na nube. representacións materializadas de todos os miles de millóns de liñas de código fonte de Google nun gran almacén de datos.
Grok proporcionou aos Googlers un marco poderoso para realizar refactorizacións automatizadas en toda a súa base de código (literalmente en Google). O sistema calcula non só as túas dependencias ascendentes (das que dependes), senón tamén descendendo (que depende de ti) así que cando cambias de API sabes a todos os que estás rompendo! Deste xeito, cando fagas cambios, podes verificar que todos os consumidores da túa API se actualizaron á nova versión e, en realidade, moitas veces coa ferramenta Rosie que escribiron, podes automatizar completamente o proceso.
Isto permite que a base de código de Google estea internamente limpa case de forma sobrenatural, xa que teñen a estes servos robóticos correndo pola casa e limpando todo automaticamente se cambian o nome de SomeDespicablyLongFunctionName a SomeDespicablyLongMethodName porque alguén decidiu que era un neto feo e que necesitaba durmir.
E francamente, funciona bastante ben para Google... internamente. Quero dicir, si, a comunidade Go de Google si se ríe ben coa comunidade Java de Google polo seu hábito de refactorización continua. Se reinicias algo N veces, iso significa que non só o arruinaches N-1 veces, senón que despois dun tempo queda bastante claro que probablemente o arruinaches tamén no enésimo intento. Pero, en xeral, seguen por encima de todo este alboroto e manteñen o código "limpio".
O problema comeza cando intentan impoñer esta actitude aos seus clientes na nube e aos usuarios doutras API.
Presenteime un pouco a Emacs, Android e Java; vexamos a última plataforma exitosa de longa duración: a propia Web. Podes imaxinar cantas iteracións pasou HTTP desde 1995, cando usamos etiquetas intermitentes e iconas "En construción" nas páxinas web.
Pero aínda funciona! E estas páxinas seguen funcionando! Si, xente, os navegadores son os campións do mundo da compatibilidade con versiones anteriores. Chrome é outro exemplo da rara plataforma de Google que ten as cabezas enroscadas correctamente e, como poderías ter adiviñado, Chrome funciona efectivamente como unha empresa de area separada do resto de Google.
Tamén quero agradecer aos nosos amigos dos desenvolvedores de sistemas operativos: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., por facer un traballo tan xenial de compatibilidade con versións anteriores nas súas exitosas plataformas (Apple obtén un C no mellor dos casos con The a desvantaxe é que rompen todo todo o tempo sen ningunha razón, pero dalgún xeito a comunidade evita con cada lanzamento e os contedores de OS X aínda non están completamente obsoletos... aínda).
Pero espera, dis. Non estamos comparando mazás con laranxas: sistemas de software autónomos nunha única máquina como Emacs/JDK/Android/Chrome con sistemas multiservidor e API como servizos en nube?
Ben, onte twittei sobre isto, pero ao estilo de Larry Wall (creador da linguaxe de programación Perl - aprox. por.) co principio de "sucks/reglas" busquei a palabra. obsoleto nos sitios de desenvolvedores de Google e Amazon. E aínda que AWS ten centos veces máis ofertas de servizos que GCP, a documentación para desenvolvedores de Google menciona a desaprobación unhas sete veces máis a miúdo.
Se alguén en Google está lendo isto, probablemente estea preparado para sacar gráficos ao estilo de Donald Trump que mostren que en realidade están facendo todo ben e que non debería facer comparacións inxustas como "número de mencións da palabra obsoleta versus número de servizos" "
Pero despois de todos estes anos, Google Cloud segue sendo o servizo número 3 (nunca escribín un artigo sobre o intento fallido de converterse no número 2), pero se hai que crer que os iniciados, hai certa preocupación de que pronto poidan caer No 4.
Non teño ningún argumento convincente para "probar" a miña tese. Todo o que teño son os vistosos exemplos que acumulei durante 30 anos como programador. Xa mencionei a natureza profundamente filosófica deste problema; nalgúns aspectos está politizado nas comunidades de desenvolvedores. Algúns cren iso creadores ás plataformas deberían preocuparse pola compatibilidade, mentres que outros pensan que isto é unha preocupación usuarios (os propios desenvolvedores). Un de cada dous. De feito, non é unha cuestión política cando decidimos quen debe asumir os custos dos problemas comúns?
Polo tanto, isto é política. E probablemente haxa respostas con rabia ao meu discurso.
Como usuario Google Cloud Platform, e como usuario de AWS durante dous anos (mentres traballaba para Grab), podo dicir que hai unha gran diferenza entre as filosofías de Amazon e Google no que se refire ás prioridades. Non desenvolvo activamente en AWS, polo que non sei moi ben con que frecuencia eliminan as API antigas. Pero hai a sospeita de que isto non ocorre con tanta frecuencia como en Google. E creo de verdade que esta fonte de constante controversia e frustración en GCP é un dos maiores factores que frean o desenvolvemento da plataforma.
Sei que non nomeei exemplos específicos de sistemas GCP que xa non son compatibles. Podo dicir que case todo o que usei, dende redes (desde as máis antigas ata VPC) ata o almacenamento (Cloud SQL v1-v2), Firebase (agora Firestore cunha API completamente diferente), App Engine (nin sequera comecemos) , puntos finais da nube Punto final da nube e ata... Non sei - absolutamente todo isto Obrigáronche a reescribir o código despois dun máximo de 2-3 anos e nunca automatizaron a migración por ti, e moitas veces . Como se así fose.
E cada vez que miro AWS, pregúntome por que diaños aínda estou en GCP. Está claro que non necesitan clientes. Precisan compradores. Entendes a diferenza? Déixame explicar.
Google Cloud ten , onde a xente propón as súas solucións de software, e para evitar o efecto restaurante baleiro, necesitaba enchelo con algunhas propostas, polo que contrataron cunha empresa chamada Bitnami para crear unha morea de solucións que se despregan con "un clic", ou deberían. Escríboo eu mesmo "solucións", porque estas non solucionan nada. Simplemente existen como caixas de verificación, como recheo de mercadotecnia e a Google nunca lle importou se algunha das ferramentas funciona realmente. Coñezo xestores de produtos que estiveron no asento do condutor e pódoche asegurar que a estas persoas non lles importa.
Tomemos, por exemplo, unha solución de implantación supostamente "dun clic". . Estaba farto das travesuras de Google Cloud SQL, así que comecei a pensar en construír o meu propio clúster Percona como alternativa. E esta vez Google pareceu facer un bo traballo, íanme aforrar tempo e esforzo con só premer un botón!
Pois xenial, imos. Sigamos a ligazón e premamos neste botón. Seleccione "Si" para aceptar todas as opcións predeterminadas e implementar o clúster no seu proxecto na nube de Google. Haha, non funciona. Ningunha desta merda funciona. A ferramenta nunca se probou e comezou a podrecer desde o primeiro minuto, e non me estrañaría que máis da metade das "solucións" sexan despregamentos cun só clic (agora entendemos por que as comiñas) en xeral non funciona. Esta é unha escuridade absolutamente desesperada, onde é mellor non entrar.
Pero Google ten razón anima que os uses. Eles queren que ti mercou. Para eles é unha transacción. Non queren nada apoiar. Non forma parte do ADN de Google. Si, os enxeñeiros apóianse mutuamente, como demostra a miña historia con Bigtable. Pero en produtos e servizos para a xente común eles sempre foron despiadados , que non cumpre o listón de rendibilidade aínda que teña millóns de usuarios.
E isto supón un verdadeiro desafío para GCP porque este é o ADN detrás de todas as ofertas na nube. Non están intentando apoiar nada; É ben sabido que se negan a aloxar (como servizo xestionado) calquera software de terceiros ata que, ata que AWS fai o mesmo e constrúe un negocio exitoso ao seu redor, e cando os clientes literalmente demandan o mesmo. Non obstante, é necesario un esforzo para que Google soporte algo.
Esta falta de cultura de apoio, unida á mentalidade de "rompémola para facelo máis bonito", afasta aos desenvolvedores.
E iso non é bo se queres construír unha plataforma de longa duración.
Google, esperta, carallo. Agora é 2020. Aínda estás perdendo. É hora de mirarse ao espello e responder se realmente queres seguir no negocio da nube.
Se queres quedar, entón deixa de romper todo. Rapaces, sodes ricos. Os desenvolvedores non o somos. Entón, cando se trata de quen asumirá a carga da compatibilidade, cómpre asumilo. Non para nós.
Porque hai polo menos tres nubes máis moi boas. Eles chaman.
E agora pasarei a arranxar todos os meus sistemas rotos. Eh.
Ata a próxima!
P.S. Actualización despois de ler algunhas das discusións deste artigo (as discusións son xeniais, por certo). O soporte de Firebase non se interrompeu e non teño ningún plan que eu coñeza. Non obstante, teñen un erro de transmisión desagradable que fai que o cliente Java se bloquee en App Engine. Un dos seus enxeñeiros axudoume a resolver este problema, cando traballaba en Google, pero en realidade nunca solucionaron o erro, así que teño que ter que reiniciar a aplicación GAE todos os días. E así foi dende hai catro anos! Agora teñen Firestore. Vai levar moito traballo migrar a el xa que é un sistema completamente diferente e o erro de Firebase nunca se solucionará. Que conclusión se pode sacar? Podes obter axuda se traballas nunha empresa. Probablemente sexa o único que use Firebase en GAE porque rexistro menos de 100 claves nunha aplicación 100 % nativa e deixa de funcionar cada dous días debido a un erro coñecido. Que podo dicir que non sexa usalo baixo o seu propio risco. Estou cambiando a Redis.
Tamén vin algúns usuarios de AWS máis experimentados dicir que normalmente AWS nunca deixa de admitir ningún servizo, e SimpleDB é un gran exemplo. As miñas suposicións de que AWS non ten a mesma enfermidade de fin de soporte que Google parecen estar xustificadas.
Ademais, notei que hai 20 días o equipo de Google App Engine rompeu o hospedaxe dunha biblioteca Go crítica, pechando unha aplicación GAE dun dos desenvolvedores principais de Go. Foi realmente estúpido.
Finalmente, escoitei que os googlers xa comentan este tema e que, en xeral, están de acordo comigo (¡Quérovos!). Pero parecen pensar que o problema é irresoluble porque a cultura de Google nunca tivo a estrutura de incentivos adecuada. Pensei que sería bo dedicar un tempo a discutir a experiencia absolutamente incrible que tiven traballando cos enxeñeiros de AWS mentres traballaba en Grab. Algún día no futuro, espero!
E si, en 2005 tiñan diferentes tipos de carne de quenlla no bufé xigante do edificio 43, e o meu favorito era a carne de quenlla martelo. Non obstante, en 2006, Larry e Sergei desfixéronse de todos os lanches pouco saudables. Entón, durante a historia de Bigtable en 2007, realmente non había tiburóns e enganoino.
Cando mirei a nube Bigtable hai catro anos (da ou tome), aquí foi onde estaba o custo. Parece que caeu un pouco agora, pero iso aínda é moito para un almacén de datos baleiro, especialmente porque a miña primeira historia mostra o intrascendente que é unha mesa grande baleira á súa escala.
Perdón por ofender á comunidade de Apple e non dicir nada bo sobre Microsoft, etc. Estás ben, agradezo moito a discusión que xerou este artigo. Pero ás veces hai que facer ondas un pouco para comezar unha discusión, sabes?
Grazas por ler.
Actualización 2, 19.08.2020/XNUMX/XNUMX. Raia !
Actualización 3, 31.08.2020/2/2. Contactoume un enxeñeiro de Google en Cloud Marketplace que resultou ser un vello amigo meu. El quería descubrir por que CXNUMXD non funcionaba, e finalmente descubrimos que era porque eu construíra a miña rede hai anos, e CXNUMXD non funcionaba en redes legadas porque faltaba o parámetro de subrede nos seus modelos. Creo que é mellor que os potenciais usuarios de GCP se aseguren de coñecer suficientes enxeñeiros en Google...
Fonte: www.habr.com