Maldito Google, eu não queria blogar de novo. Eu tenho tanta coisa para fazer. Blogar exige tempo, energia e criatividade, que eu poderia aproveitar bem: meus livros, , meu jogo e assim por diante. Mas você me irritou o suficiente para que eu tenha que escrever isso.
Então vamos acabar com isso.
Deixe-me começar com uma história curta, mas instrutiva, de quando comecei a trabalhar no Google. Sei que tenho dito muitas coisas ruins sobre o Google ultimamente, mas fico chateado quando minha própria empresa toma regularmente decisões de negócios incompetentes. Ao mesmo tempo, devemos dar-lhe o devido valor: a infraestrutura interna do Google é verdadeiramente extraordinária, é seguro dizer que não há nada melhor hoje. Os fundadores do Google eram engenheiros muito melhores do que eu jamais serei, e esta história apenas confirma esse fato.
Primeiro, algumas informações básicas: o Google possui uma tecnologia de armazenamento de dados chamada . Foi uma conquista técnica notável, um dos primeiros (se não o primeiro) armazenamento de valores-chave (K/V) “infinitamente escalável”: essencialmente o início do NoSQL. Hoje em dia, o Bigtable ainda está indo bem no espaço de armazenamento K/V bastante lotado, mas na época (2005) era incrivelmente legal.
Uma coisa engraçada sobre o Bigtable é que eles tinham objetos de plano de controle interno (como parte da implementação) chamados servidores tablet, com índices grandes, e em algum momento eles se tornaram um gargalo na hora de dimensionar o sistema. Os engenheiros do Bigtable estavam intrigados sobre como implementar a escalabilidade e, de repente, perceberam que poderiam substituir os servidores tablet por outro armazenamento do Bigtable. Portanto, o Bigtable faz parte da implementação do Bigtable. Essas instalações de armazenamento existem em todos os níveis.
Outro detalhe interessante é que por um tempo o Bigtable se tornou popular e onipresente dentro do Google, com cada equipe tendo seu próprio repositório. Então, em uma das reuniões de sexta-feira, Larry Page perguntou casualmente: “Por que temos mais de um Bigtable? Por que não apenas um? Em teoria, um armazenamento deveria ser suficiente para todas as necessidades de armazenamento do Google. É claro que eles nunca recorreram a apenas um por razões práticas de desenvolvimento (como as consequências de um fracasso potencial), mas a teoria era interessante. Um repositório para todo o Universo (A propósito, alguém sabe se a Amazon fez isso com seu Sable?)
De qualquer forma, aqui está minha história.
Na época, eu trabalhava no Google há pouco mais de dois anos e um dia recebi um e-mail da equipe de engenharia do Bigtable mais ou menos assim:
Prezado Steve,
Olá da equipe do Bigtable. Gostaríamos de informar que em [nome do data center] você está usando um binário Bigtable muito antigo. Esta versão não é mais suportada e queremos ajudá-lo a atualizar para a versão mais recente.
Por favor, deixe-me saber se você pode agendar algum tempo para trabalharmos juntos nesta questão.
Tudo de bom,
Equipe Bigtable
No Google você recebe muitos e-mails, então à primeira vista li algo assim:
Prezado Destinatário,
Olá de alguma equipe. Queremos comunicar isso, blá, blá, blá, blá. Blá, blá, blá, blá, blá, e blá, blá, blá imediatamente.
Por favor, deixe-nos saber se você pode agendar algum do seu precioso tempo para blá, blá, blá.
Tudo de bom,
Algum tipo de comando
Quase o apaguei imediatamente, mas no limite da minha consciência senti uma sensação dolorosa e incômoda de que não é bem assim parece uma carta formal obviamente, que o destinatário se enganou porque eu não usei o Bigtable.
Mas foi estranho.
Passei o resto do dia pensando alternadamente no trabalho e que tipo de carne de tubarão experimentar na microcozinha, das quais pelo menos três estavam perto o suficiente para acertar do meu assento com um arremesso certeiro de um biscoito, mas o pensar em escrever nunca me deixou com uma sensação crescente de leve ansiedade.
Eles disseram claramente meu nome. E o e-mail foi enviado para o meu endereço de e-mail, não para o de outra pessoa, e não é cc: ou cco:. O tom é muito pessoal e claro. Talvez isso seja algum tipo de erro?
Por fim, a curiosidade tomou conta de mim e fui dar uma olhada no console Borg no data center que eles mencionaram.
E, claro, eu tinha o armazenamento do BigTable sob gerenciamento. Desculpa, o que? Eu olhei para o seu conteúdo e uau! Foi da incubadora Codelab em que participei durante minha primeira semana no Google, em junho de 2005. Codelab forçou você a executar o Bigtable para escrever alguns valores lá, e aparentemente nunca fechei o armazenamento depois disso. Ainda estava funcionando, embora mais de dois anos tivessem se passado.
Existem vários aspectos dignos de nota nesta história. Em primeiro lugar, o trabalho do Bigtable era tão insignificante na escala do Google que apenas dois anos depois alguém notou o armazenamento extra, e apenas porque a versão do binário estava desatualizada. Para efeito de comparação, uma vez considerei usar para o meu jogo online. Na época, esse serviço custava aproximadamente US$ 16 por ano. vazio Bigtable no GCP. Não estou dizendo que eles estão enganando você, mas na minha opinião pessoal, isso é muito dinheiro para uma porra de um banco de dados vazio.
Outro aspecto digno de nota é que o armazenamento ainda trabalhando depois de dois anos. O que é isso? Os data centers vêm e vão; eles passam por interrupções, passam por manutenções programadas, mudam o tempo todo. O hardware é atualizado, os interruptores são trocados, tudo está em constante melhoria. Como diabos eles conseguiram manter meu programa funcionando por dois anos com todas essas mudanças? Isto pode parecer uma conquista modesta em 2020, mas em 2005-2007 foi bastante impressionante.
E o aspecto mais maravilhoso é que uma equipe externa de engenharia em algum outro estado se aproxima de mim, o proprietário de uma instância minúscula e quase vazia do Bigtable, que tem tráfego zero nos últimos dois anos - e estão oferecendo ajuda para atualizá-lo.
Agradeci, apaguei o armazenamento e a vida continuou normalmente. Mas treze anos depois, ainda penso naquela carta. Porque às vezes recebo e-mails semelhantes do Google Cloud. Eles se parecem com isto:
Prezado usuário do Google Cloud,
Como lembrete, descontinuaremos o serviço [serviço essencial que você usa] a partir de agosto de 2020, após o qual você não poderá atualizar suas instâncias. Recomendamos atualizar para a versão mais recente, que está em teste beta, não possui documentação, não possui caminho de migração e está desatualizada com nossa gentil ajuda.
Estamos empenhados em garantir que esta mudança tenha um impacto mínimo em todos os usuários da plataforma Google Cloud.
Melhores amigas para sempre,
Plataforma Google Cloud
Mas quase nunca leio essas cartas, porque o que elas realmente dizem é:
Prezado Destinatário,
Vá para o inferno. Foda-se, foda-se, foda-se. Largue tudo o que você faz porque não importa. O que importa é o nosso tempo. Perdemos tempo e dinheiro mantendo nossas porcarias e estamos cansados disso, então não vamos apoiá-las mais. Então desista dos seus malditos planos e comece a vasculhar nossa documentação de merda, implorando por recados nos fóruns e, a propósito, nossa merda nova é completamente diferente da merda antiga, porque nós estragamos bastante esse design, heh, mas essa é sua problema, não nosso.
Continuamos a fazer esforços para garantir que todos os seus empreendimentos se tornem inutilizáveis no prazo de um ano.
Por favor, vá se foder
Plataforma Google Cloud
E o fato é que recebo essas cartas uma vez por mês. Isso acontece com tanta frequência e constantemente que eles inevitavelmente afastado me do GCP para o campo anti-nuvem. Não concordo mais em depender de seus desenvolvimentos proprietários, porque na verdade é mais fácil para os devops manter um sistema de código aberto em uma máquina virtual simples do que tentar acompanhar o Google com sua política de fechar produtos “desatualizados”.
Antes de voltar para o Google Cloud porque mesmo perto não terminamos de criticá-los, vejamos o desempenho da empresa em algumas outras áreas. Os engenheiros do Google se orgulham de sua disciplina de engenharia de software e é isso que realmente causa problemas. O orgulho é uma armadilha para os incautos e levou muitos funcionários do Google a pensar que suas decisões são sempre corretas e que estar certo (por alguma definição vaga e confusa) é mais importante do que se preocupar com os clientes.
Darei alguns exemplos aleatórios de outros grandes projetos fora do Google, mas espero que você veja esse padrão em todos os lugares. É o seguinte: a compatibilidade com versões anteriores mantém os sistemas ativos e atualizados por décadas.
A compatibilidade com versões anteriores é o objetivo do projeto de todos os sistemas bem-sucedidos projetados para aberto uso, isto é, implementado com código-fonte aberto e/ou padrões abertos. Sinto que estou falando algo tão óbvio que todo mundo fica até desconfortável, mas não. Esta é uma questão política, por isso são necessários exemplos.
O primeiro sistema que escolherei é o mais antigo: GNU Emacs, que é uma espécie de híbrido entre o Windows Notepad, o kernel do sistema operacional e a Estação Espacial Internacional. É um pouco difícil de explicar, mas resumindo, o Emacs é uma plataforma criada em 1976 (sim, quase meio século atrás) para programação para torná-lo mais produtivo, mas disfarçado de editor de texto.
Eu uso o Emacs todos os dias. Sim, eu também uso o IntelliJ todos os dias, ele se tornou uma plataforma de ferramentas poderosa por si só. Mas escrever extensões para o IntelliJ é uma tarefa muito mais ambiciosa e complexa do que escrever extensões para o Emacs. E o mais importante, tudo o que foi escrito para o Emacs é preservado para sempre.
Ainda uso o software que escrevi para o Emacs em 1995. E tenho certeza de que alguém está usando módulos escritos para Emacs em meados dos anos 80, se não antes. Eles podem exigir alguns ajustes de vez em quando, mas isso é muito raro. Não sei de nada que já escrevi para o Emacs (e escrevi muito) que exigisse uma rearquitetura.
O Emacs possui uma função chamada tornar obsoleta para entidades obsoletas. A terminologia do Emacs para conceitos fundamentais de computador (como o que é uma "janela") geralmente difere das convenções da indústria porque o Emacs as introduziu há muito tempo. Este é um perigo típico de quem está à frente do seu tempo: todos os seus termos estão incorretos. Mas o Emacs tem um conceito de depreciação, que em seu jargão é chamado obsolescência.
Mas no mundo Emacs parece haver uma definição funcional diferente. Uma filosofia subjacente diferente, se preferir.
No mundo do Emacs (e em muitas outras áreas, que abordaremos abaixo), o status da API obsoleta significa basicamente: "Você realmente não deveria usar esta abordagem, porque embora funcione, ela sofre de várias deficiências que iremos lista aqui. Mas no final do dia, a escolha é sua."
No mundo do Google, ser obsoleto significa: “Estamos violando nosso compromisso com você”. Isto é verdade. Isto é o que significa essencialmente. Isso significa que eles vão forçar você regularmente fazer algum trabalho, talvez muito trabalho, como punição por acreditar neles : Temos o melhor software. O mais rápido! Você faz tudo de acordo com as instruções, inicia seu aplicativo ou serviço e, bam, depois de um ou dois anos ele quebra.
É como vender um carro usado que com certeza vai quebrar depois de 1500 km.
Estas são duas definições filosóficas completamente diferentes de “obsolescência”. A definição de cheiro do Google . Eu não acredito nisso de fato obsolescência planejada no mesmo sentido da Apple. Mas o Google está definitivamente planejando quebrar seus programas, de forma indireta. Sei disso porque trabalhei lá como engenheiro de software por mais de 12 anos. Eles têm diretrizes internas vagas sobre o quanto a compatibilidade com versões anteriores deve ser seguida, mas, em última análise, isso depende de cada equipe ou serviço individual. Não há recomendações de nível empresarial ou de engenharia, e a recomendação mais ousada em termos de ciclos de obsolescência é “tentar dar aos clientes de 6 a 12 meses para atualizar antes de quebrar todo o sistema”.
O problema é muito maior do que pensam e persistirá nos próximos anos porque o atendimento ao cliente não está no seu DNA. Mais sobre isso abaixo.
Neste ponto farei uma declaração ousada de que o Emacs é um grande sucesso e até mesmo basicamente porque eles levam a compatibilidade com versões anteriores muito a sério. Na verdade, esta é a tese do nosso artigo. Sistemas abertos bem-sucedidos e duradouros devem seu sucesso às microcomunidades que vivem ao seu redor há décadas extensões/plug-ins. Este é o ecossistema. Já falei sobre a natureza das plataformas e como elas são importantes, e como o Google nunca, em toda a sua história corporativa, entendeu o que acontece na criação de uma plataforma aberta de sucesso fora do Android ou do Chrome.
Na verdade, devo mencionar brevemente o Android porque você provavelmente está pensando nisso.
Em primeiro lugar, Android não é Google. Eles não têm quase nada em comum um com o outro. Android é uma empresa que foi comprada pelo Google em julho de 2005, a empresa foi autorizada a operar de forma mais ou menos autônoma e, na verdade, permaneceu praticamente intocada nos anos seguintes. O Android é uma pilha de tecnologia notória e uma organização espinhosa igualmente notória. Como disse um Googler: “Você não pode simplesmente fazer login no Android”.
Em um artigo anterior, discuti o quão ruins foram algumas das primeiras decisões de design do Android. Caramba, quando escrevi aquele artigo, eles estavam lançando uma porcaria chamada "aplicativos instantâneos", que agora são (surpresa!) , e simpatizo se você foi estúpido o suficiente para ouvir o Google e mover seu conteúdo para esses aplicativos instantâneos.
Mas há uma diferença aqui, uma diferença significativa, que é que o pessoal do Android realmente entende o quão importantes são as plataformas, eles fazem o possível para manter os aplicativos Android antigos funcionando. Na verdade, seus esforços para manter a compatibilidade com versões anteriores são tão extremos que até eu, durante meu breve período na divisão Android, há alguns anos, me vi tentando convencê-los a abandonar o suporte para alguns dos dispositivos e APIs mais antigos (eu estava errado , como aconteceu em muitas outras coisas do passado e do presente. Desculpe, pessoal do Android! Agora que estive na Indonésia, entendo por que precisamos deles).
O pessoal do Android leva a compatibilidade com versões anteriores a extremos quase inimagináveis, acumulando enormes quantidades de dívidas técnicas legadas em seus sistemas e cadeias de ferramentas. Oh meu Deus, você deveria ver algumas das coisas malucas que eles têm que fazer em seu sistema de construção, tudo em nome da compatibilidade.
Por isso, concedo ao Android o cobiçado prêmio “Você não é o Google”. Eles realmente não querem se tornar o Google, que não sabe como criar plataformas duráveis, mas o Android sabe, como fazer isso. E assim o Google está sendo muito inteligente em um aspecto: permitir que as pessoas façam as coisas à sua maneira no Android.
No entanto, os aplicativos instantâneos para Android foram uma ideia bastante estúpida. E você sabe por quê? Porque eles exigiram reescrever e redesenhar seu aplicativo! É como se as pessoas simplesmente reescrevessem dois milhões de aplicativos. Acho que o Instant Apps foi ideia de algum Googler.
Mas há uma diferença. A compatibilidade com versões anteriores tem um custo alto. O próprio Android arca com o ônus desses custos, enquanto o Google insiste que o ônus seja arcado você, cliente pagante.
Você pode ver o compromisso do Android com a compatibilidade retroativa em suas APIs. Quando você tem quatro ou cinco subsistemas diferentes fazendo literalmente a mesma coisa, é um sinal claro de que existe um compromisso com a compatibilidade com versões anteriores. O que no mundo das plataformas é sinônimo de comprometimento com seus clientes e com seu mercado.
O principal problema do Google aqui é o orgulho de sua higiene de engenharia. Eles não gostam quando há muitas maneiras diferentes de fazer a mesma coisa, com as formas antigas e menos desejáveis ao lado das formas novas e mais sofisticadas. Aumenta a curva de aprendizado para aqueles que são novos no sistema, aumenta a carga de manutenção de APIs legadas, diminui a velocidade de novos recursos e o pecado capital é que não é bonito. Google - como Lady Ascot de Alice no País das Maravilhas de Tim Burton:
Senhora Ascot:
- Alice, você sabe do que eu mais tenho medo?
- O declínio da aristocracia?
- Eu estava com medo de ter netos feios.
Para entender a relação entre beleza e praticidade, vamos dar uma olhada na terceira plataforma de sucesso (depois do Emacs e do Android) e ver como ela funciona: o próprio Java.
Java tem muitas APIs desatualizadas. A depreciação é muito popular entre os programadores Java, ainda mais popular do que na maioria das linguagens de programação. O próprio Java, a linguagem principal e as bibliotecas estão constantemente descontinuando as APIs.
Para citar apenas um entre milhares de exemplos, considerado obsoleto. Ele está obsoleto desde o lançamento do Java 1.2 em dezembro de 1998. Já se passaram 22 anos desde que isso foi descontinuado.
Mas meu código real em produção ainda está matando threads todos os dias. Você realmente acha que isso é bom? Absolutamente! Quero dizer, é claro, se eu reescrevesse o código hoje, eu o implementaria de forma diferente. Mas o código do meu jogo, que deixou centenas de milhares de pessoas felizes nas últimas duas décadas, foi escrito com uma função para fechar threads que ficam pendurados por muito tempo, e eu nunca tive que mudar isso. Conheço meu sistema melhor do que ninguém, tenho literalmente 25 anos de experiência trabalhando com ele em produção e posso dizer com certeza: no meu caso, fechar esses threads de trabalho específicos é completamente inofensivo. Não vale a pena gastar tempo e esforço para reescrever este código, e agradeço a Larry Ellison (provavelmente) que a Oracle não me forçou a reescrevê-lo.
A Oracle provavelmente também entende de plataformas. Quem sabe.
As evidências podem ser encontradas nas principais APIs Java, que estão repletas de ondas de obsolescência, como as linhas de uma geleira em um desfiladeiro. Você pode encontrar facilmente cinco ou seis gerenciadores de navegação de teclado diferentes (KeyboardFocusManager) na biblioteca Java Swing. Na verdade, é difícil encontrar uma API Java que não esteja obsoleta. Mas eles ainda funcionam! Acho que a equipe Java só removerá realmente uma API se a interface apresentar um problema de segurança evidente.
O problema é o seguinte, pessoal: nós, desenvolvedores de software, estamos todos muito ocupados e, em todas as áreas do software, enfrentamos alternativas concorrentes. A qualquer momento, os programadores da linguagem X estão considerando a linguagem Y como uma possível substituta. Ah, você não acredita em mim? Você quer chamá-lo de Swift? Tipo, todo mundo está migrando para o Swift e ninguém está desistindo, certo? Uau, quão pouco você sabe. As empresas estão contabilizando os custos de equipes duplas de desenvolvimento móvel (iOS e Android) - e estão começando a perceber que esses sistemas de desenvolvimento multiplataforma com nomes engraçados como Flutter e React Native realmente funcionam e podem ser usados para reduzir o tamanho de seus equipes móveis duas vezes ou, inversamente, torná-las duas vezes mais produtivas. Há dinheiro real em jogo. Sim, existem compromissos, mas, por outro lado, dinheiro.
Vamos supor hipoteticamente que a Apple tolamente seguiu a sugestão de Guido van Rossum e declarou que o Swift 6.0 é incompatível com versões anteriores do Swift 5.0, assim como o Python 3 é incompatível com o Python 2.
Provavelmente contei essa história há cerca de dez anos, mas há cerca de quinze anos fui ao O'Reilly's Foo Camp com Guido, sentei-me em uma barraca com Paul Graham e um bando de figurões. Ficamos sentados sob o calor sufocante esperando Larry Page voar em seu helicóptero pessoal enquanto Guido falava sobre “Python 3000”, que ele batizou em homenagem ao número de anos que todos levariam para migrar para lá. Continuamos perguntando por que ele estava quebrando a compatibilidade e ele respondeu: “Unicode”. E perguntamos: se tivéssemos que reescrever nosso código, que outros benefícios veríamos? E ele respondeu “Yoooooooooooouuuuuuuniiiiiiiicoooooode”.
Se você instalar o SDK do Google Cloud Platform (“gcloud”), receberá a seguinte notificação:
Prezado Destinatário,
Gostaríamos de lembrar que o suporte para Python 2 foi descontinuado, então vá se foder
… e assim por diante. Círculo da vida.
Mas a questão é que todo desenvolvedor tem uma escolha. E se você forçá-los a reescrever o código com bastante frequência, eles poderão pensar em outro opções. Eles não são seus reféns, não importa o quanto você queira que eles sejam. Eles são seus convidados. Python ainda é uma linguagem de programação muito popular, mas caramba, Python 3(000) criou uma bagunça tão grande em si mesmo, em suas comunidades e entre os usuários de suas comunidades que as consequências não foram esclarecidas por quinze anos.
Quantos programas Python foram reescritos em Go (ou Ruby, ou alguma outra alternativa) devido a esta incompatibilidade com versões anteriores? Quanto software novo foi escrito em algo diferente de Python, embora poderia ser escrito em Python, se Guido não tivesse incendiado a vila inteira? É difícil dizer, mas o Python sofreu claramente. É uma grande bagunça e todos perdem.
Então, digamos que a Apple siga a sugestão de Guido e quebre a compatibilidade. O que você acha que vai acontecer depois? Bem, talvez 80-90% dos desenvolvedores reescrevam seu software, se possível. Em outras palavras, 10-20% da base de usuários vai automaticamente para alguma linguagem concorrente, como o Flutter.
Faça isso várias vezes e você perderá metade da sua base de usuários. Assim como nos esportes, no mundo da programação a forma atual também importa. всё. Qualquer pessoa que perder metade de seus usuários em cinco anos será considerada um grande perdedor. Você deve estar na moda no mundo das plataformas. Mas é aqui que o não suporte a versões mais antigas irá arruiná-lo com o tempo. Porque toda vez que você se livra de alguns desenvolvedores, você (a) os perde para sempre porque eles estão com raiva de você por quebrar o contrato e (b) os entrega aos seus concorrentes.
Ironicamente, também ajudei o Google a se tornar uma prima donna que ignora a compatibilidade com versões anteriores quando criei o Grok, um sistema de análise e compreensão de código-fonte que facilita a automatização e instrumentação do próprio código - semelhante a um IDE, mas aqui o serviço de nuvem armazena representações materializadas de todos os bilhões de linhas de código-fonte do Google em um grande data warehouse.
Grok forneceu aos Googlers uma estrutura poderosa para realizar refatorações automatizadas em toda a sua base de código (literalmente em todo o Google). O sistema calcula não apenas suas dependências upstream (das quais você depende), mas também Rio abaixo (o que depende de você), então, quando você altera as APIs, você conhece todos que está quebrando! Dessa forma, ao fazer alterações, você pode verificar se cada consumidor de sua API foi atualizado para a nova versão e, na realidade, muitas vezes com a ferramenta Rosie que eles escreveram, você pode automatizar completamente o processo.
Isso permite que a base de código do Google seja internamente quase sobrenaturalmente limpa, já que eles têm esses servos robóticos correndo pela casa e limpando tudo automaticamente se renomearem SomeDespicablyLongFunctionName para SomeDespicablyLongMethodName porque alguém decidiu que era um neto feio e que ele precisava ser colocado para dormir.
E, francamente, funciona muito bem para o Google... internamente. Quero dizer, sim, a comunidade Go do Google ri muito com a comunidade Java do Google por causa de seu hábito de refatoração contínua. Se você reiniciar algo N vezes, isso significa que você não apenas estragou tudo N-1 vezes, mas depois de um tempo fica bem claro que você provavelmente estragou tudo na enésima tentativa também. Mas, em geral, eles permanecem acima de todo esse alarido e mantêm o código “limpo”.
O problema começa quando eles tentam impor essa atitude aos seus clientes de nuvem e usuários de outras APIs.
Eu apresentei um pouco o Emacs, Android e Java; vejamos a mais recente plataforma de sucesso: a própria Web. Você pode imaginar quantas iterações o HTTP passou desde 1995, quando usamos tags flashing? e ícones "Em construção" em páginas da web.
Mas ainda funciona! E essas páginas ainda estão funcionando! Sim, pessoal, os navegadores são os campeões mundiais em compatibilidade com versões anteriores. O Chrome é outro exemplo da rara plataforma do Google que tem suas cabeças aparafusadas corretamente e, como você deve ter adivinhado, o Chrome opera efetivamente como uma empresa em sandbox separada do resto do Google.
Também quero agradecer aos nossos amigos desenvolvedores de sistemas operacionais: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, etc., por fazerem um ótimo trabalho de compatibilidade com versões anteriores em suas plataformas de sucesso (a Apple obtém um C na melhor das hipóteses com The A desvantagem é que eles quebram tudo o tempo todo sem um bom motivo, mas de alguma forma a comunidade contorna isso a cada lançamento, e os contêineres do OS X ainda não estão completamente obsoletos... ainda).
Mas espere, você diz. Não estamos comparando maçãs com laranjas - sistemas de software autônomos em uma única máquina como Emacs/JDK/Android/Chrome versus sistemas multi-servidor e APIs como serviços em nuvem?
Bem, eu twittei sobre isso ontem, mas no estilo de Larry Wall (criador da linguagem de programação Perl - aprox. por.) no princípio de "é uma merda/regras", procurei a palavra obsoleta nos sites de desenvolvedores do Google e da Amazon. E embora a AWS tenha centenas vezes mais ofertas de serviços do que o GCP, a documentação do desenvolvedor do Google menciona a suspensão de uso cerca de sete vezes mais frequentemente.
Se alguém no Google estiver lendo isso, provavelmente está pronto para extrair gráficos no estilo Donald Trump, mostrando que está realmente fazendo tudo certo e que eu não deveria fazer comparações injustas como "número de menções à palavra obsoleto versus número de serviços" "
Mas depois de todos esses anos, o Google Cloud ainda é o serviço número 3 (nunca escrevi um artigo sobre a tentativa fracassada de se tornar o número 2), mas, se acreditarmos nos insiders, há algumas preocupações de que em breve eles poderão cair para Nº 4.
Não tenho argumentos convincentes para “provar” minha tese. Tudo o que tenho são os exemplos coloridos que acumulei ao longo de 30 anos como desenvolvedor. Já mencionei a natureza profundamente filosófica deste problema; de certa forma, é politizado nas comunidades de desenvolvedores. Alguns acreditam que criadores plataformas deveriam se preocupar com compatibilidade, enquanto outras pensam que isso é uma preocupação usuários (os próprios desenvolvedores). Um em cada dois. Na verdade, não é uma questão política decidir quem deve suportar os custos dos problemas comuns?
Então isso é política. E provavelmente haverá respostas raivosas ao meu discurso.
Как usuário Google Cloud Platform, e como usuário da AWS há dois anos (enquanto trabalhava para Grab), posso dizer que há uma enorme diferença entre as filosofias da Amazon e do Google quando se trata de prioridades. Como não desenvolvo ativamente na AWS, não sei muito bem com que frequência eles removem APIs antigas. Mas há uma suspeita de que isso não aconteça com tanta frequência como no Google. E eu realmente acredito que esta fonte de constante controvérsia e frustração no GCP é um dos maiores fatores que impedem o desenvolvimento da plataforma.
Sei que não citei exemplos específicos de sistemas GCP que não são mais suportados. Posso dizer que quase tudo que usei, desde redes (das mais antigas até VPC) até armazenamento (Cloud SQL v1-v2), Firebase (agora Firestore com uma API completamente diferente), App Engine (nem vamos começar) , endpoints de nuvem Cloud Endpoint e até... não sei - absolutamente tudo isso forçaram você a reescrever o código após no máximo 2 a 3 anos, e eles nunca automatizaram a migração para você, e muitas vezes . Como se fosse para ser assim.
E toda vez que olho para a AWS, me pergunto por que diabos ainda estou no GCP. Eles claramente não precisam de clientes. Eles precisam compradores. Você entende a diferença? Deixe-me explicar.
O Google Cloud tem , onde as pessoas propõem suas soluções de software, e para evitar o efeito do restaurante vazio, precisavam preenchê-lo com algumas propostas, então contrataram uma empresa chamada Bitnami para criar um monte de soluções que são implantadas com “um clique”, ou deveriam Eu mesmo escrevo “soluções”, porque elas não resolvem absolutamente nada. Eles simplesmente existem como caixas de seleção, como preenchimento de marketing, e o Google nunca se importou se alguma das ferramentas realmente funciona. Conheço gerentes de produto que estiveram no comando e posso garantir que essas pessoas não se importam.
Tomemos, por exemplo, uma solução de implantação supostamente “com um clique”. . Eu estava farto das travessuras do Google Cloud SQL, então comecei a pensar em construir meu próprio cluster Percona como alternativa. E desta vez o Google parecia ter feito um bom trabalho, eles iriam me poupar algum tempo e esforço com o clique de um botão!
Bem, ótimo, vamos lá. Vamos seguir o link e clicar neste botão. Selecione “Sim” para concordar com todas as configurações padrão e implantar o cluster em seu projeto de nuvem do Google. Haha, não funciona. Nenhuma dessas porcarias funciona. A ferramenta nunca foi testada e começou a apodrecer desde o primeiro minuto, e não me surpreenderia se mais da metade das "soluções" fossem implantações de um clique (agora entendemos o porquê das aspas) em geral não funciona. Esta é uma escuridão absolutamente desesperadora, onde é melhor não entrar.
Mas o Google está certo impulsos você usá-los. Eles querem que você comprou. Para eles é uma transação. Eles não querem nada apoiar. Não faz parte do DNA do Google. Sim, os engenheiros apoiam uns aos outros, como evidenciado pela minha história com o Bigtable. Mas em produtos e serviços para pessoas comuns eles sempre foram implacáveis em , que não atende aos padrões de lucratividade, mesmo que tenha milhões de usuários.
E isso representa um verdadeiro desafio para o GCP porque este é o DNA por trás de todas as ofertas de nuvem. Eles não estão tentando apoiar nada; É bem sabido que eles se recusam a hospedar (como um serviço gerenciado) qualquer software de terceiros até então, até que a AWS faça o mesmo e construa um negócio de sucesso em torno disso, e quando os clientes literalmente exigirem o mesmo. No entanto, é preciso algum esforço para que o Google apoie algo.
Essa falta de cultura de suporte, aliada à mentalidade “vamos quebrar para deixar mais bonito”, afasta os desenvolvedores.
E isso não é bom se você deseja construir uma plataforma duradoura.
Google, acorde, droga. É 2020 agora. Você ainda está perdendo. É hora de se olhar no espelho e responder se você realmente deseja permanecer no negócio de nuvem.
Se você quiser ficar então pare de quebrar tudo. Pessoal, vocês são ricos. Nós, desenvolvedores, não. Portanto, quando se trata de quem assumirá o fardo da compatibilidade, você precisa assumir isso. Não para nós.
Porque há pelo menos mais três nuvens realmente boas. Eles acenam.
E agora irei consertar todos os meus sistemas quebrados. Eh.
Até a próxima vez!
Atualização do PS depois de ler algumas das discussões neste artigo (as discussões são ótimas, aliás). O suporte do Firebase não foi descontinuado e não há planos que eu conheça. No entanto, eles têm um bug de streaming desagradável que faz com que o cliente Java pare no App Engine. Um de seus engenheiros me ajudou a resolver esse problema, quando trabalhei no Google, mas eles nunca corrigiram o bug, então tenho uma péssima solução alternativa de ter que reiniciar o aplicativo GAE todos os dias. E assim tem sido durante quatro anos! Eles agora têm Firestore. Será preciso muito trabalho para migrar para ele, pois é um sistema completamente diferente e o bug do Firebase nunca será corrigido. Que conclusão pode ser tirada? Você pode obter ajuda se você trabalha em uma empresa. Provavelmente sou o único que usa o Firebase no GAE porque registro menos de 100 chaves em um aplicativo 100% nativo e ele para de funcionar a cada dois dias devido a um bug conhecido. O que posso dizer além de usá-lo por sua própria conta e risco. Estou mudando para Redis.
Também vi alguns usuários mais experientes da AWS dizerem que a AWS geralmente nunca para de oferecer suporte a nenhum serviço, e o SimpleDB é um ótimo exemplo. Minhas suposições de que a AWS não tem a mesma doença de fim de suporte que o Google parecem ser justificadas.
Além disso, notei que há 20 dias a equipe do Google App Engine quebrou a hospedagem de uma biblioteca Go crítica, fechando um aplicativo GAE de um dos principais desenvolvedores Go. Foi realmente estúpido.
Por fim, ouvi Googlers já discutindo esse assunto e concordando comigo em geral (amo vocês!). Mas eles parecem pensar que o problema é insolúvel porque a cultura do Google nunca teve a estrutura de incentivos adequada. Achei que seria bom dedicar algum tempo para discutir a experiência absolutamente incrível que tive trabalhando com engenheiros da AWS enquanto trabalhava na Grab. Algum dia no futuro, espero!
E sim, em 2005 eles tinham diferentes tipos de carne de tubarão no bufê gigante do prédio 43, e minha favorita era a carne de tubarão-martelo. No entanto, em 2006, Larry e Sergei livraram-se de todos os lanches não saudáveis. Então, durante a história do Bigtable em 2007, realmente não havia tubarões e eu enganei você.
Quando olhei para o Cloud Bigtable há quatro anos (mais ou menos), era aí que estava o custo. Parece ter caído um pouco agora, mas ainda é muito para um data warehouse vazio, especialmente porque minha primeira história mostra como uma grande tabela vazia é inconsequente em sua escala.
Desculpe por ofender a comunidade Apple e não dizer nada de bom sobre a Microsoft, etc. Você está bem, eu realmente aprecio toda a discussão que este artigo gerou! Mas às vezes é preciso agitar um pouco para iniciar uma discussão, sabe?
Obrigado por ler.
Atualização 2, 19.08.2020/XNUMX/XNUMX. Listra !
Atualização 3, 31.08.2020/2/2. Fui contatado por um engenheiro do Google no Cloud Marketplace que era um velho amigo meu. Ele queria descobrir por que o CXNUMXD não estava funcionando, e finalmente descobrimos que era porque eu havia construído minha rede anos atrás e o CXNUMXD não estava funcionando em redes legadas porque o parâmetro de sub-rede estava faltando em seus modelos. Acho que é melhor para os usuários em potencial do GCP terem certeza de que conhecem engenheiros suficientes no Google...
Fonte: habr.com