Caramba, Google, eu não queria voltar a escrever em um blog. Eu tenho tantas coisas a fazer. Manter um blog exige tempo, energia e criatividade que eu poderia usar de maneira mais produtiva: meus livros, , meu jogo e assim por diante. Mas você me irritou o suficiente, então vou ter que escrever isso.
Então vamos acabar com isso.
Vou começar com uma pequena, mas instrutiva, história dos tempos em que comecei a trabalhar no Google. Sei que ultimamente falei muitas coisas negativas sobre o Google, mas me frustra quando a empresa que eu tanto valorizo toma decisões de negócios incompetentes. Dito isso, é justo reconhecer: a infraestrutura interna do Google é realmente extraordinária, pode-se dizer com confiança que hoje não existe nada melhor. Os fundadores do Google eram engenheiros muito melhores do que eu jamais serei, e essa história só confirma esse fato.
Um pouco de contexto: o Google possui uma tecnologia de armazenamento de dados chamada . Esse foi um grande feito técnico, um dos primeiros (se não o primeiro) repositórios de pares "chave-valor" que era "infinitamente escalável" (key-value store, K/V): essencialmente, o início do NoSQL. Hoje em dia, o Bigtable ainda se sai bem em um espaço de armazenamento K/V bastante lotado, mas naquela época (2005) era incrivelmente impressionante.
Um detalhe curioso sobre o Bigtable é que eles tinham objetos internos de plano de controle (como parte da implementação) chamados servidores tablet, com grandes índices, e em algum momento se tornaram um gargalo ao escalar o sistema. Os engenheiros do Bigtable ficaram quebrando a cabeça para implementar a escalabilidade e, de repente, perceberam que poderiam substituir os servidores tablet por outros repositórios do Bigtable. Assim, o Bigtable é parte da implementação do Bigtable. Esses repositórios estão lá 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. Assim, em uma de suas reuniões de sexta-feira, Larry Page perguntou casualmente: "Por que temos mais de um Bigtable? Por que não usar apenas um?" Teoricamente, um único repositório deveria ser suficiente para todas as necessidades de armazenamento do Google. Claro, eles nunca adotaram apenas um por razões práticas de desenvolvimento (por exemplo, as consequências de uma possível falha), mas a teoria era interessante. Um repositório para todo o universo (a propósito, alguém sabe se a Amazon fez algo semelhante com o seu Sable?)
De qualquer forma, aqui está a minha história.
Na época, eu estava na Google há pouco mais de dois anos, e um dia recebi um e-mail da equipe de engenharia do Bigtable com um conteúdo mais ou menos assim:
Caro Steve,
Saudações da equipe do Bigtable. Queremos informar que no data center [nome do data center] você está usando um arquivo binário do Bigtable muito, muito antigo. Esta versão não é mais suportada, e queremos ajudar você a migrar para a versão mais recente.
Por favor, informe se você pode agendar um tempo para trabalharmos juntos nessa questão.
Atenciosamente,
Equipe Bigtable
No Google, você recebe muitos e-mails, então à primeira vista eu li mais ou menos assim:
Caro destinatário,
Saudações de alguma equipe. Queremos informar que blá-blá-blá-blá-blá. Blá-blá-blá-blá-blá-blá, e blá-blá-blá imediatamente.
Por favor, avise-nos se você pode agendar parte do seu precioso tempo para blá-blá-blá.
Atenciosamente,
Alguma equipe
Eu quase apaguei imediatamente, mas na borda da minha consciência senti uma pressão incômoda, mas persistente, de que isso não era exatamente como uma carta formal, embora obviamente, isso indicava que o destinatário estava errado, pois eu não usava o Bigtable.
Mas era estranho.
O restante do dia eu alternava entre pensar no trabalho e em qual tipo de carne de tubarão experimentar na micro-cozinha, das quais pelo menos três estavam perto o suficiente para serem atingidas com um preciso lançamento de biscoito, mas o pensamento sobre o e-mail não me deixava, acompanhando-me com uma crescente sensação de leve ansiedade.
Eles claramente mencionaram meu nome. E a carta foi enviada para meu endereço de e-mail, e não para o de outra pessoa, e isso não é cc: ou bcc:. O tom é muito pessoal e claro. Pode ser um erro?
Finalmente, a curiosidade tomou conta e eu fui dar uma olhada na console Borg no data center que eles mencionaram.
E claro, eu tinha um armazenamento BigTable sob minha gestão. O quê? Eu olhei para seu conteúdo e — nossa! Era do incubador Codelab, onde estive na minha primeira semana de trabalho no Google em junho de 2005. O Codelab fazia você iniciar o Bigtable para que você registrasse alguns valores, e aparentemente eu não desativei o armazenamento depois disso. Ele ainda estava funcionando, embora já tivessem se passado mais de dois anos.
Há alguns aspectos notáveis nesta história. Primeiro, o uso do Bigtable foi tão insignificante na escala do Google que apenas dois anos depois alguém notou o armazenamento extra, e isso só porque a versão do binário estava desatualizada. Para comparação, uma vez considerei usar para o meu jogo online. Naquela época, esse serviço custava cerca de $16.000 por ano por um Bigtable vazio no GCP. Não digo que eles estão te enganando, mas, na minha opinião, é muito dinheiro por um banco de dados completamente vazio.
Outro aspecto notável é que o armazenamento ainda estava funcionando após dois anos. WTF? Data centers vão e vêm; eles enfrentam interrupções, passam por manutenções programadas, estão sempre mudando. O hardware é atualizado, os switches são trocados, tudo está em constante evolução. Como, diabos, conseguiram manter meu programa ativo por dois anos considerando todas essas mudanças? Pode parecer uma conquista modesta em 2020, mas entre 2005 e 2007 foi bastante impressionante.
E o aspecto mais surpreendente é que uma equipe de engenheiros de fora, em algum outro estado, entra em contato comigo, o proprietário de uma pequena instância quase vazia do Bigtable que tem zero tráfego nos últimos dois anos — e oferece ajuda para atualizá-lo.
Agradeci a eles, excluí o armazenamento e a vida seguiu em frente. Mas treze anos depois, ainda penso naquela carta. Porque às vezes recebo cartas semelhantes do Google Cloud. Elas se parecem com isso:
Prezado usuário do Google Cloud,
Lembramos que estamos descontinuando o serviço [importante serviço que você usa] a partir de agosto de 2020, após o que você não poderá mais atualizar suas instâncias. Recomendamos que você migre para a versão mais recente, que está em fase beta, não possui documentação, não possui um caminho de migração e que já está obsoleta com a nossa gentil assistência.
Estamos nos esforçando para que essa mudança tenha um impacto mínimo em todos os usuários da plataforma Google Cloud.
Melhores amigos para sempre,
Plataforma de Nuvem Google
Mas eu quase não leio esses e-mails, porque na verdade eles dizem o seguinte:
Caro destinatário,
Vá para o inferno. Vá, vá, vá. Descarte tudo o que você está fazendo, porque isso não importa. O que importa é o nosso tempo. Estamos gastando tempo e dinheiro para manter nossa porcaria, e estamos cansados disso, então não a manteremos mais. Então, esqueça seus planos enfadonhos e comece a vasculhar nossa documentação ruim, implorando por migalhas nos fóruns, e, a propósito, nossa nova porcaria é completamente diferente da velha porcaria, porque realmente estragamos esse design, hehe, mas esse é o seu problema, não o nosso.
Ainda estamos empenhados em tornar todos os seus desenvolvimentos inutilizáveis dentro de um ano.
Por favor, vá se danar,
Plataforma de Nuvem Google
E o fato é que recebo esses e-mails cerca de uma vez por mês. Isso acontece com tanta frequência e de forma tão constante, que eles inevitavelmente afastaram me de GCP para o lado dos opositores da nuvem. Eu não concordo mais em depender de seus desenvolvimentos proprietários, porque na verdade é mais fácil para um devops manter um sistema de código aberto em uma máquina virtual do que tentar acompanhar o Google com sua política de encerramento de produtos "obsoletos".
Antes de voltar ao Google Cloud, porque eu nem perto não terminei de criticá-los, vamos analisar o trabalho da empresa em algumas outras áreas. Os engenheiros do Google se orgulham de sua disciplina no desenvolvimento de software, e isso realmente causa problemas. O orgulho é uma armadilha para os imprudentes, levando muitos funcionários do Google a acreditar que suas decisões são sempre corretas e que a correção (segundo alguma definição vaga) é mais importante do que a preocupação com os clientes.
Vou citar alguns exemplos aleatórios de outros grandes projetos além do Google, mas espero que você veja esse padrão em todo lugar. Ele é o seguinte: a retrocompatibilidade mantém a vitalidade e a relevância dos sistemas por décadas.
A retrocompatibilidade é um objetivo de design de todos os sistemas bem-sucedidos destinados a uso aberto , ou seja, implementados com código aberto e/ou em padrões abertos. Sinto que estou dizendo algo tão óbvio que chega a ser desconfortável, mas não é. Esta é uma questão política, portanto, exemplos são necessários.
O primeiro sistema que escolho é o mais velho: GNU Emacs, uma espécie de híbrido entre o Bloco de Notas do Windows, o núcleo do sistema operacional e a Estação Espacial Internacional. É um pouco complicado de explicar, mas em poucas palavras, Emacs é uma plataforma criada em 1976 (sim, quase meio século atrás) para programação, com o intuito de aumentar sua produtividade, mas disfarçada de editor de texto.
Eu uso Emacs todos os dias. Sim, eu também uso IntelliJ todos os dias, que já se tornou uma poderosa plataforma de ferramentas por conta própria. Mas escrever extensões para IntelliJ é uma tarefa muito mais ambiciosa e complexa do que escrever extensões para Emacs. E o mais importante, tudo o que é escrito para Emacs permanece para sempre.
Ainda uso o software que escrevi para Emacs em 1995. E tenho certeza de que alguém usa módulos escritos para Emacs desde os anos 80, se não antes. De vez em quando, eles podem exigir ajustes mínimos, mas isso é realmente bastante raro. Não sei de nada que escrevi para Emacs (e escrevi bastante) que precisasse reestruturar sua arquitetura.
No Emacs existe uma função chamada make-obsolete para entidades obsoletas. A terminologia do Emacs para conceitos fundamentais da computação (como o que é uma "janela") muitas vezes difere das convenções do setor, porque o Emacs as introduziu há muito tempo. Este é um perigo típico para aqueles que estiveram à frente de seu tempo: todos os seus termos estão incorretos. Mas no Emacs realmente existe o conceito de obsolescência, que em sua gíria é chamado de obsolescência.
Mas no mundo do Emacs, parece haver outra definição de trabalho. Outra filosofia fundamental, se você quiser.
No mundo do Emacs (e em muitas outras áreas que veremos a seguir), o status de APIs obsoletas significa principalmente: "Você realmente não deve usar essa abordagem, porque, embora funcione, ela apresenta várias desvantagens que listaremos aqui. Mas, no final, a sua escolha é sua."
No mundo do Google, o status de um produto obsoleto significa: "Estamos quebrando nossos compromissos com você." É realmente isso. É assim que, em essência, isso significa. Isso significa que eles vão fazer você realizar regularmente algum trabalho, possivelmente um grande trabalho, em punição por ter acreditado em sua : temos o melhor software. O mais rápido! Você segue todas as instruções, roda seu aplicativo ou serviço e então — pum, depois de um ou dois anos ele quebra.
É como vender um carro usado que vai definitivamente quebrar após 1500 km.
Essas são duas definições filosóficas completamente diferentes de "obsolescência". A definição do Google tem cheiro de . Eu não acredito que isso seja na verdade obsolescência programada no mesmo sentido que a da Apple. Mas o Google definitivamente planeja quebrar seus programas, de maneira indireta. Eu sei disso porque trabalhei lá como engenheiro de software por mais de 12 anos. Eles têm diretrizes internas vagamente definidas sobre até que ponto manter a compatibilidade retroativa, mas, no final, isso depende de cada equipe ou serviço individual. Não há diretrizes em nível corporativo ou de engenharia, e a recomendação mais ousada em termos de ciclos de obsolescência é "tente dar aos clientes de 6 a 12 meses para atualizar antes de quebrar todo o sistema deles."
O problema é muito mais sério do que pensam, e ele persistirá por muitos anos, porque o cuidado com os clientes não faz parte do seu DNA. Saiba mais sobre isso abaixo.
Neste momento, vou fazer uma afirmação ousada de que o Emacs é bem-sucedido em grande parte e até mesmo principalmente porque leva a sério a compatibilidade retroativa. Na verdade, esse é o argumento do nosso artigo. Sistemas abertos bem-sucedidos e duradouros devem seu sucesso às microcomunidades que vivem há décadas em torno de extensões/plugin. Isso é o que chamamos de ecossistema. Eu já refleti sobre a essência das plataformas e sobre quão importantes elas são, e que o Google nunca entendeu ao longo da sua história corporativa o que é necessário para criar uma plataforma aberta de sucesso, exceto pelo Android ou Chrome.
Na verdade, eu devo mencionar brevemente o Android, porque você provavelmente já pensou nele.
Em primeiro lugar, O Android não é o Google.Eles não têm quase nada em comum. O Android é uma empresa que foi comprada pelo Google em julho de 2005, e essa empresa foi autorizada a operar mais ou menos de forma autônoma, e na verdade ela permanecia, em grande parte, intocada ao longo dos anos. O Android é um stack técnico notoriamente complexo e uma organização igualmente notoriamente complicada. Como disse um funcionário do Google, 'não é fácil apenas entrar no Android'.
Em um dos artigos anteriores, eu já refleti sobre quão ruins foram algumas das primeiras decisões de design do Android. Poxa, quando escrevi aquele artigo, eles estavam implementando uma porcaria chamada 'aplicativos instantâneos', que agora (s surpresa!) , e lamento se você foi suficientemente ingênuo para ouvir o Google e transferir seu conteúdo para esses aplicativos instantâneos.
Mas aqui há uma diferença, uma diferença significativa, que é que as pessoas do Android realmente entendem o quão importantes são as plataformas, e elas se esforçam ao máximo para manter a funcionalidade de aplicativos Android antigos. Na verdade, seus esforços para manter a compatibilidade retroativa são tão extremos que até eu, durante minha breve passagem pelo departamento do Android há alguns anos, descobri que estava tentando convencê-los a abrir mão do suporte a alguns dos dispositivos e APIs mais antigos (estava errado, assim como em muitas outras coisas do passado e do presente. Desculpe, pessoal do Android! Agora que estive na Indonésia, entendo por que precisamos deles).
As pessoas do Android mantêm a compatibilidade retroativa até extremos quase inimagináveis, o que acumula uma enorme quantidade de dívidas técnicas desatualizadas em seus sistemas e cadeias de ferramentas. Oh Deus, você teria que ver algumas das coisas malucas que eles têm que fazer em seu sistema de build, 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 consegue criar plataformas duradouras, enquanto o Android sabe como fazer isso. conhece, e por isso o Google age com grande sabedoria em um aspecto: permite que as pessoas do Android façam tudo à sua maneira.
No entanto, os aplicativos instantâneos para Android foram uma ideia bastante estúpida. E sabe por quê? Porque eles exigiam reescrever e reorganizar seu aplicativo! Como se as pessoas simplesmente pegassem e reescrevessem dois milhões de aplicativos. Presumo que os aplicativos instantâneos foram uma ideia de algum funcionário do Google.
Mas aqui há uma diferença. A compatibilidade retroativa vem com altos custos. O Android mesmo arca com o peso desses custos, enquanto o Google insiste que esse peso seja suportado você, pelo cliente pago.
Você pode ver o comprometimento do Android com a compatibilidade retroativa em suas interfaces de API. Quando você tem quatro ou cinco subsistemas diferentes para realizar praticamente a mesma função, isso é um sinal claro de que há um compromisso com a compatibilidade retroativa. O que, no mundo das plataformas, é sinônimo de compromisso com seus clientes e seu mercado.
O principal problema do Google aqui é seu orgulho em relação à sua higiene de engenharia. Eles não gostam quando existem muitas maneiras diferentes de fazer a mesma coisa, especialmente quando métodos antigos e menos desejáveis coexistem com novos métodos mais intrigantes. Isso aumenta a curva de aprendizado para novatos no sistema, sobrecarrega o suporte de APIs obsoletas, desacelera a velocidade de novas funcionalidades, e o maior pecado – é feio. O Google é como a Senhora Escot de "Alice no País das Maravilhas" de Tim Burton:
Senhora Escot:
— Alice, sabes o que eu mais temo?
— A queda da aristocracia?
— Eu temia por ter netos feios.
Para entender o compromisso entre o bonito e o prático, vamos olhar para a terceira plataforma bem-sucedida (depois do Emacs e do Android) e ver como ela funciona: o próprio Java.
No Java, há um monte de APIs obsoletas. A obsolescência é muito popular entre os programadores Java, até mais do que na maioria das linguagens de programação. Na própria Java, a linguagem principal e bibliotecas, a obsolescência de APIs acontece constantemente.
Se pegarmos apenas um dos milhares de exemplos, é considerado obsoleto. Isso se tornou obsoleto desde o lançamento do Java 1.2 em dezembro de 1998. Já se passaram 22 anos desde que isso ficou obsoleto.
Mas meu código de produção ainda mata threads todo dia. Isso é bom? Absolutamente! Quero dizer, claro, se eu reescrevesse o código hoje, eu o implementaria de maneira diferente. Mas o código do meu jogo, que fez centenas de milhares de pessoas felizes nas últimas duas décadas, foi escrito com a função de fechamento de threads que ficam pendentes por muito tempo, e eu nunca precisei alterá-lo. Eu conheço meu sistema melhor que ninguém, tenho literalmente 25 anos de experiência trabalhando nele em produção, e posso afirmar com precisão: no meu caso, o fechamento dessas threads específicas é completamente inofensivo. Não vale a pena gastar tempo e energia reescrevendo este código, e que louvor a Larry Ellison (provavelmente) que a Oracle não me forçou a reescrevê-lo.
Provavelmente, a Oracle também entende de plataformas. Quem sabe.
Você pode encontrar evidências em todas as principais APIs do Java, que são permeadas por ondas de obsolescência, como as linhas de uma geleira em um cânion. Na biblioteca Java Swing, é fácil encontrar cinco ou seis diferentes gerenciadores de foco de teclado (KeyboardFocusManager). Na realidade, é difícil encontrar uma API do Java que não esteja obsoleta. Mas elas ainda funcionam! Acho que a equipe do Java realmente removerá uma API apenas se a interface causar uma problemática de segurança gritante.
Aqui está a questão, pessoal: nós, desenvolvedores de software, estamos todos muito ocupados, e em cada área do software enfrentamos alternativas concorrentes. A qualquer momento, programadores na linguagem X estão considerando a linguagem Y como uma possível substituição. Oh, você não acredita em mim? Quer mencionar Swift? Como se todos estivessem migrando para Swift e ninguém estivesse desistindo, certo? Uau, como você sabe pouco. As empresas estão considerando os custos de equipes de desenvolvimento móvel duplicadas (iOS e Android) - e estão começando a entender que esses sistemas de desenvolvimento multiplataforma com nomes engraçados, como Flutter e React Native, realmente funcionam, e com isso podem reduzir o tamanho de suas equipes móveis pela metade ou, ao contrário, aumentar sua produtividade em até duas vezes. Estão em jogo verdadeiras quantias de dinheiro. Sim, existem compromissos, mas, por outro lado, dinheiro.
Suponha hipoteticamente que a Apple, por engano, seguisse o exemplo de Guido van Rossum e anunciasse que o Swift 6.0 não é compatível com o Swift 5.0, da mesma forma que o Python 3 não é compatível com o Python 2.
Provavelmente, já contei essa história há cerca de dez anos, mas há quinze anos fui para o acampamento Foo Camp da O'Reilly com Guido, sentei-me na barraca com Paul Graham e uma variedade de grandes nomes. Estávamos suando sob o calor sufocante, esperando que Larry Page aterrissasse em seu helicóptero particular, enquanto Guido falava monótonamente sobre o 'Python 3000', que ele nomeou pela quantidade de anos que levaria para todos migrarem para lá. Nós perguntávamos o tempo todo por que ele estava quebrando a compatibilidade, e ele respondia: 'Unicode'. E nós perguntávamos, se teríamos que reescrever nosso código, que outras vantagens veríamos? E ele respondia 'Vocêuuuuuuuniiiiiiicooooooode'.
Se você instalar o SDK do Google Cloud Platform ('gcloud'), você receberá a seguinte notificação:
Caro destinatário,
Gostaríamos de lembrá-lo de que o suporte ao Python 2 foi descontinuado, então siga em frente.
… e assim por diante. O ciclo da vida.
Mas a verdade é que cada desenvolvedor tem uma escolha. E se você fizer com que eles reescrevam o código com frequência suficiente, eles podem considerar outras opções. outros Eles não são seus reféns, por mais que você queira. Eles são seus convidados. O Python ainda é uma linguagem de programação muito popular, mas, caramba, o Python 3(000) criou uma confusão tão grande em suas comunidades e entre os usuários dessas comunidades que as consequências não conseguem ser resolvidas há quinze anos.
Quantos programas em Python foram reescritos em Go (ou Ruby, ou alguma outra alternativa) devido a essa incompatibilidade retroativa? Quanto novo software foi escrito em algo diferente de Python, mesmo que pudesse ser escrito em Python se Guido não tivesse queimado a vila? É difícil dizer, mas o Python claramente sofreu. É uma grande confusão, e todos saem perdendo. Então, suponha que a Apple siga o exemplo de Guido e quebre a compatibilidade. O que você acha que vai acontecer em seguida? Bem, talvez 80-90% dos desenvolvedores reescrevam seu software, se puderem. Em outras palavras, 10-20% da base de usuários automaticamente migram para alguma linguagem concorrente, como o Flutter.
Faça isso algumas vezes — e você perderá metade da sua base de usuários. Assim como no esporte, no mundo da programação, o desempenho atual também é tudo.
. Qualquer um que perder metade dos usuários em cinco anos será considerado um Grande Fracasso. Você precisa estar em sintonia com o mundo das plataformas. Mas é aqui que a descontinuação do suporte a versões antigas eventualmente irá te prejudicar. Porque toda vez que você se livra de uma parte dos desenvolvedores, você (a) os perde para sempre, porque eles ficam chateados com você por quebrar o contrato, e (b) os entrega aos seus concorrentes. Por ironia do destino, eu também ajudei o Google a se tornar essa diva que ignora a compatibilidade retroativa quando criei o Grok, um sistema de análise e compreensão de código-fonte que facilita a automação e o fornecimento de ferramentas baseadas no próprio código — é parecido com um IDE, mas aqui o serviço em nuvem armazena visões materializadas de todos os bilhões de linhas de código-fonte do Google em um grande repositório de dados.Qualquer um que perder metade de seus usuários em cinco anos será considerado um Grande e Gordo Fracassado. Você deve acompanhar as tendências do mundo das plataformas. Mas é aqui que a falta de suporte para versões antigas pode acabar com você ao longo do tempo. Porque cada vez que você se livra de uma parte dos desenvolvedores, você (a) os perde para sempre, porque eles ficam irritados com você por romper o contrato, e (b) os entrega para seus concorrentes.
Por ironia do destino, eu também ajudei o Google a se tornar essa diva que ignora a compatibilidade retroativa quando criei o Grok, um sistema de análise e interpretação de código-fonte que facilita a automação e o fornecimento de ferramentas com base no próprio código — é parecido com uma IDE, mas aqui o serviço em nuvem armazena visualizações materializadas de todos os bilhões de linhas de código-fonte do Google em um grande repositório de dados.
A Grok forneceu aos engenheiros do Google uma base poderosa para realizar refatoração automatizada em toda a base de código (literalmente em todo o Google). O sistema calcula não apenas suas dependências ascendentes (das quais você depende), mas também descendentes (que dependem de você), portanto, ao mudar a API, você sabe exatamente quem está quebrando! Assim, ao fazer alterações, você pode verificar se cada consumidor da sua API foi atualizado para a nova versão, e na realidade, muitas vezes com a ferramenta Rosie, que eles criaram, você pode automatizar completamente o processo.
Isso permite que a base de código do Google permaneça quase sobrenaturalmente "limpa" internamente, uma vez que esses servos robotizados se movem pela casa, limpando automaticamente tudo se eles renomearam SomeDespicablyLongFunctionName para SomeDespicablyLongMethodName, porque alguém decidiu que essa era uma neta feia e precisava ser aposentada.
E, sinceramente, isso funciona muito bem para o Google... internamente. Quero dizer, sim, a comunidade Go no Google realmente faz piadas amigáveis sobre a comunidade Java no Google por causa de seu hábito de refatoração contínua. Se você reinicia algo N vezes, isso significa que você não apenas estragou isso N-1 vezes, mas com o tempo se torna claro que você provavelmente também estragou isso na N-ésima tentativa. Mas, em grande parte, eles permanecem acima dessa confusão e mantêm o código "limpo".
Os problemas começam quando eles tentam impor essa mentalidade a seus clientes de nuvem e usuários de outras APIs.
Eu te introduzi um pouco ao Emacs, Android e Java; agora vamos olhar para a última plataforma de sucesso e longevidade: a própria Web. Você pode imaginar quantas iterações o HTTP passou desde 1995, quando usávamos tags piscantes e ícones "Em desenvolvimento" nas páginas da web.
Mas ainda funciona! E essas páginas ainda funcionam! Sim, pessoal, os navegadores são campeões mundiais em retrocompatibilidade. O Chrome é mais um exemplo raro de uma plataforma do Google que está com a cabeça no lugar certo, e, como você já deve ter adivinhado, o Chrome age de forma eficaz como uma empresa isolada, separada do resto do Google.
Gostaria também de agradecer aos nossos amigos entre os desenvolvedores de sistemas operacionais: Windows, Linux, NÃO APPLE, FreeBSD e assim por diante, pelo grande trabalho que fizeram em manter a compatibilidade retroativa em suas plataformas de sucesso (a Apple recebe, no melhor dos casos, um três menos, pois eles continuam a quebrar tudo sem razão, mas de alguma forma a comunidade consegue lidar com isso a cada lançamento, e os contêineres com OS X ainda não estão completamente obsoletos... por enquanto).
Mas espere, você dirá. Não estamos comparando maçãs com laranjas - sistemas de software autônomos em uma única máquina, como Emacs/JDK/Android/Chrome, com sistemas multi-servidor e APIs, como nos serviços em nuvem?
Bem, escrevi sobre isso ontem no Twitter, mas no estilo de Larry Wall (o criador da linguagem de programação Perl - nota do tradutor) com o princípio ‘lixo/rulez’, procurei a palavra está obsoleto nos sites para desenvolvedores do Google e da Amazon. E embora a AWS tenha centenas de vezes mais ofertas de serviços do que o GCP, a documentação do desenvolvedor do Google menciona obsolescência cerca de sete vezes mais frequentemente.
Se alguém do Google estiver lendo isso, com certeza eles estão prontos para apresentar gráficos no estilo de Donald Trump, mostrando que estão fazendo tudo certo, e que eu não deveria fazer comparações injustas, como ‘o número de menções à palavra deprecated em relação ao número de serviços’.
Mas, após tantos anos, o Google Cloud ainda é o serviço nº 3 (eu ainda não escrevi um artigo sobre a tentativa mal-sucedida de ser nº 2), mas se acreditarmos nos insiders, há algumas preocupações de que eles possam em breve cair para o nº 4.
Não tenho argumentos sólidos para 'provar' minha tese. Tudo o que tenho são exemplos coloridos que acumulei ao longo de 30 anos trabalhando como desenvolvedor. Já mencionei a natureza profundamente filosófica desse problema; de certa forma, ele é politizado nas comunidades de desenvolvedores. Alguns acreditam que os criadores das plataformas devem se preocupar com a compatibilidade, enquanto outros acham que essa é uma preocupação dos usuários (os próprios desenvolvedores). Uma das duas opções. E não é, de fato, uma questão política quando decidimos quem deve arcar com os custos de problemas compartilhados?
Portanto, isso é política. E com certeza haverá respostas furiosas à minha declaração.
Como usuário como usuário da plataforma em nuvem do Google e tendo trabalhado com a AWS por dois anos (na empresa Grab), posso afirmar que há uma enorme diferença entre as filosofias da Amazon e do Google quando se trata de prioridades. Não sou um desenvolvedor ativo na AWS, então não sei bem com que frequência eles descontinuam APIs antigas. Mas suspeito que isso não aconteça tão frequentemente quanto no Google. E sinceramente acredito que essa fonte constante de disputas e frustrações no GCP é um dos maiores fatores que impedem o desenvolvimento da plataforma.
Sei que não citei exemplos concretos de sistemas GCP cujo suporte foi descontinuado. Posso dizer que quase tudo o que utilizei, desde redes (das mais antigas ao VPC) até armazenamento (Cloud SQL v1-v2), Firebase (agora Firestore com uma API totalmente diferente), App Engine (melhor nem começarmos), endpoints em nuvem Cloud Endpoint e até... não sei — tudo isso me fez reescrever o código no máximo a cada 2-3 anos, e nunca houve uma migração automatizada para você, e muitas vezes . Como se fosse assim que deveria ser.
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 de compradores. Entende a diferença? Deixe-me explicar.
O Google Cloud tem um , onde as pessoas oferecem suas soluções de software, e para evitar o efeito de um restaurante vazio, era preciso preenchê-lo com algumas ofertas, então eles fecharam um contrato com a Bitnami para criar uma série de soluções que são implementadas "com um clique", ou eu mesmo deveria escrever "soluções", porque essas não resolvem nada. Elas existem apenas como marcadores, como uma enchente de marketing, e o Google nunca se preocupou se alguma dessas ferramentas realmente funcionava. Conheço gerentes de produtos que estavam no comando e posso assegurar que essas pessoas não se importam.
Por exemplo, vamos considerar a solução de um suposto "clicar e implantar" . Estou desesperado com as travessuras do Google Cloud SQL, então comecei a considerar como alternativa a criação do meu próprio cluster Percona. E desta vez, o Google aparentemente fez algo certo, eles estavam prestes a economizar um pouco do meu tempo e esforço com o toque de um botão!
Ótimo, vamos lá. Vamos seguir o link e clicar nesse botão. Escolhemos "Sim" para concordar com todas as opções padrão e implantar o cluster em nosso projeto em nuvem do Google. Haha, não funciona. Nada disso 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" para implantação com um clique (agora entendemos por que as aspas) não funcionassem. geralmente não funcionam. É uma escuridão absolutamente desesperadora, da qual é melhor não entrar.
Mas o Google está diretamente incentivando você a usá-los. Eles querem que você os compra. Para eles, é uma transação. Eles não querem nada suportar. Isso não faz parte do DNA do Google. Sim, os engenheiros se apoiam, como mostra minha história com o Bigtable. Mas em produtos e serviços para o público em geral, eles sempre foram implacáveis em , que não atinge o nível de rentabilidade, mesmo que tenha milhões de usuários.
E isso representa um verdadeiro problema para a GCP, porque esse DNA está por trás de todas as ofertas em nuvem. Eles não se esforçam para manter nada; é bem conhecido 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, é necessário fazer um certo esforço para fazer com que o Google mantenha algo.
Essa falta de cultura de suporte, combinada com o princípio de "vamos quebrar para tornar mais bonito", afasta os desenvolvedores deles.
E isso não é bom se você quer construir uma plataforma duradoura.
Google, acorde, droga. Estamos em 2020. Você ainda está perdendo. É hora de olhar firmemente no espelho e responder se realmente deseja permanecer no negócio de nuvem.
Se você quer ficar, então pare de quebrar tudo. Vocês são ricos. Nós, desenvolvedores, não somos. Portanto, quando se trata de quem arcará com o fardo da compatibilidade, vocês precisam assumir isso. Não nós.
Porque ainda há pelo menos três nuvens realmente boas. Elas estão nos atraindo.
Agora vou seguir em frente e consertar todos os meus sistemas quebrados. Ah.
Até a próxima!
P. S. Atualização após ler algumas discussões sobre este artigo (as discussões são magníficas, por sinal). O suporte ao Firebase não foi interrompido, e não há planos, que eu saiba. No entanto, eles têm um erro incômodo de streaming que faz com que o cliente Java pare no App Engine. Um dos engenheiros deles me ajudou a lidar com esse problema, quando eu trabalhava no Google, mas eles nunca realmente corrigiram o bug, então eu tenho um contorno ruim, tendo que reiniciar o aplicativo GAE todos os dias. Já faz quatro anos! Agora eles têm o Firestore. Vai ser muito trabalho migrar para ele, já que é um sistema completamente diferente, e o erro do Firebase nunca será corrigido. Qual é a conclusão? Você pode obter ajuda, se trabalhar em uma empresa. Provavelmente, eu sou o único que usa o Firebase no GAE, porque estou registrando menos de 100 chaves em um aplicativo 100% nativo, e ele para de funcionar a cada poucos dias devido a um erro conhecido. O que se pode dizer, exceto usar por sua conta e risco. Estou migrando para o Redis.
Eu também ouvi alguns usuários mais experientes da AWS dizendo que a AWS normalmente nunca descontinua serviços, e o SimpleDB é um ótimo exemplo. Minhas suposições de que a AWS não tem essa doença de descontinuação de suporte como o Google parecem estar corretas.
Além disso, notei que 20 dias atrás a equipe do Google App Engine quebrou o hosting de uma biblioteca crítica do Go, bloqueando o aplicativo GAE de um dos principais desenvolvedores do Go. Realmente, foi algo estúpido.
Finalmente, ouvi que os googlers já estão discutindo essa questão e, de modo geral, concordam comigo (amo vocês, pessoal!). Mas parece que eles veem o problema como impossível de resolver, porque na cultura do Google nunca houve uma estrutura de incentivos adequada. Acho que seria bom arranjar um tempo para discutir a experiência absolutamente incrível de trabalhar com os engenheiros da AWS, quando eu trabalhei na empresa Grab. Alguma hora no futuro, espero!
Sim, em 2005, eles realmente tinham diferentes tipos de carne de tubarão em um enorme buffet no prédio 43, e eu gostava mais da carne dos tubarões-de-galhardo. Porém, em 2006, Larry e Sergey eliminaram todos os lanches não saudáveis. Portanto, durante a história do Bigtable em 2007, não havia realmente tubarões e eu te enganei desprezivelmente.
Quando observei o Bigtable na nuvem há cerca de quatro anos (mais ou menos), o custo era exatamente esse. Parece que agora ele diminuiu um pouco, mas ainda é um valor horrível para um repositório de dados vazio, especialmente considerando que minha primeira história mostra quão irrelevante é uma grande tabela vazia em sua escala.
Desculpe por ofender a comunidade Apple e por não ter dito nada bom sobre a Microsoft etc. Vocês estão todos certos, eu realmente aprecio todas as discussões que este artigo gerou! Mas às vezes é preciso agitar um pouco as coisas para iniciar uma discussão, vocês entendem?
Obrigado por ler.
Atualização 2, 19.08.2020. Stripe !
Atualização 3, 31.08.2020. Um engenheiro do Google na Cloud Marketplace entrou em contato comigo e era um velho amigo. Ele queria descobrir por que o C2D não estava funcionando, e acabamos descobrindo: a razão é que eu criei minha rede há alguns anos e o C2D não funciona em redes obsoletas devido à falta do parâmetro de sub-rede em seus templates. Eu acho que seria melhor para usuários potenciais do GCP garantirem que tenham engenheiros familiarizados no Google...
Fonte: habr.com
