Caro Google Cloud, a compatibilidade com versões anteriores está matando você

Droga Google, não queria blogar de novo. Tenho tanta coisa para fazer. Blogar exige tempo, energia e criatividade que eu poderia usar de forma útil: meus livros, músicas , meus jogos e assim por diante. Mas você me irritou o suficiente para escrever.



Então, vamos acabar com isso.



Vou começar com uma história pequena, mas instrutiva, de quando comecei a trabalhar no Google. Sei que disse muitas coisas ruins sobre o Google ultimamente, mas fico chateado quando minha empresa doméstica toma decisões de negócios incompetentes regularmente. Dito isso, devemos prestar homenagem: a infraestrutura interna do Google é verdadeiramente extraordinária, e podemos dizer com segurança que não há nada melhor hoje. Os fundadores do Google foram engenheiros muito melhores do que eu jamais serei, e essa história apenas confirma esse fato.



Primeiro, um pequeno histórico: o Google tem uma tecnologia de armazenamento chamada Bigtable . Foi uma conquista técnica notável, um dos primeiros (se não o primeiro) armazenamento de valor-chave "infinitamente escalonável" (K / V): essencialmente, o início do NoSQL. Bigtable ainda se sente bem no espaço de armazenamento K / V bastante lotado atualmente, 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 grandes índices, e em algum ponto eles se tornaram um gargalo ao dimensionar o sistema. Os engenheiros do Bigtable quebraram a cabeça para descobrir como implementar a escalabilidade e, de repente, perceberam que poderiam substituir os servidores tablet por outros armazenamentos 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, e cada equipe tinha seu próprio repositório. Então, em uma das reuniões de sexta-feira, Larry Page perguntou casualmente de passagem: “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, eles nunca pularam para apenas um por motivos práticos de desenvolvimento (como as consequências de uma falha potencial), mas a teoria era interessante. Um repositório para todo o universo ( aliás, alguém sabe se a Amazon fez isso com seu Sable? )



De qualquer forma, aqui está a minha história.



Naquela época, trabalhei no Google por pouco mais de dois anos e um dia recebi um e-mail da equipe de engenharia da Bigtable algo assim:



Caro Steve,



Saudações da equipe do Bigtable. Gostaríamos de informar que você está usando um binário Bigtable muito antigo no data center [nome do datacenter]. Esta versão não é mais compatível e queremos ajudá-lo a atualizar para a versão mais recente.



Informe se você pode agendar algum tempo para trabalharmos juntos neste assunto. Atenciosamente



,

Equipe Bigtable


Você recebe muitos e-mails no Google, então, à primeira vista, li algo assim:



,



- . , ----. -----, -- .



, , --.



,

-


Quase a apaguei de imediato, mas no limite da consciência tive uma sensação dolorosa e dolorosa de que não se parecia muito com uma carta formal, embora seja óbvio que o destinatário se enganou, porque não usei o Bigtable.



Mas isso foi estranho.



O resto do dia pensei alternadamente sobre o trabalho e que tipo de carne de tubarão experimentar em uma micro-cozinha, das quais pelo menos três estavam perto o suficiente para sair da minha casa com um pão-de-ló bem apontado, mas a ideia de escrever não me deixou com um sentimento crescente. leve ansiedade.



Eles claramente chamaram meu nome. E o e-mail é enviado para o meu endereço de e-mail, não para o de outra pessoa e não é cc: ou bcc:. O tom é muito pessoal e claro. Talvez seja algum tipo de engano?



Por fim, a curiosidade levou a melhor e fui dar uma olhada no console Borg no data center que eles mencionaram.



E, claro, eu tinha o armazenamento BigTable sob meu controle. Desculpa, o que? Eu olhei seu conteúdo e - uau! Era da incubadora Codelab, onde passei minha primeira semana no Google em junho de 2005. Codelab forçou você a iniciar o Bigtable para que você escrevesse alguns valores lá, e provavelmente nunca fechei a loja depois disso. Ainda funcionava, embora mais de dois anos tivessem se passado.



Existem vários aspectos notáveis ​​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 percebeu o armazenamento extra, e mesmo assim apenas porque a versão do binário estava desatualizada. Para comparação, uma vez pensei em usarBigtable no Google Cloud para meu jogo online. Na época, esse serviço custava cerca de US $ 16.000 por ano para um Bigtable vazio no GCP. Não estou dizendo que eles estão te traindo, mas na minha opinião pessoal, isso é muito dinheiro para uma porra de banco de dados vazio.



Outro aspecto notável é que o armazenamento ainda estava funcionando depois de dois anos... WTF? Os centros de dados vêm e vão; eles passam por interrupções, passam por manutenções de rotina, mudam o tempo todo. O hardware é atualizado, os interruptores são trocados, tudo é constantemente melhorado. Como diabos eles mantiveram meu programa funcionando por dois anos com todas essas mudanças? Isso pode parecer uma conquista modesta em 2020, mas foi bastante impressionante em 2005-2007.



E o aspecto mais maravilhoso é que uma equipe de engenharia externa em algum outro estado entra em contato comigo, o dono de uma instância minúscula e quase vazia do Bigtable, que está sem tráfego nos últimos dois anos - e oferece ajuda para atualizá-la. ...



Agradeci, retirei o cofre e a vida continuou como de costume. Mas treze anos depois, ainda penso nesta carta. Porque às vezes eu recebo e-mails como este do Google Cloud. Eles se parecem com isto:



Prezado usuário do Google Cloud,



Lembramos que estamos descontinuando o serviço [um serviço importante que você usa] a partir de agosto de 2020, após o qual você não poderá atualizar suas instâncias. Recomendamos que você atualize para a versão mais recente, que está em teste beta, não tem documentação, nenhum caminho de migração e está desatualizada antecipadamente com nossa gentil ajuda.



Temos o compromisso de garantir que essa mudança tenha o menor impacto possível para todos os usuários da plataforma Google Cloud.



Melhores amigos para sempre,

Google Cloud Platform


Mas dificilmente leio essas cartas, porque na verdade elas dizem o seguinte:



Caro destinatário,



Foda-se. Foda-se, foda-se, foda-se. Jogue fora tudo o que você faz porque não importa. O que importa é o nosso tempo. Gastamos tempo e dinheiro para sustentar nossas merdas e estamos cansados ​​disso, então não vamos mais suportar. Então abandone seus planos de merda 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 bagunçamos esse design muito mal, heh, mas isso é problema seu, não nosso.



Continuamos a trabalhar duro para tornar todos os seus projetos inutilizáveis ​​dentro de um ano.



Vá nah,

Google Cloud Platform


E o fato é que recebo essas cartas cerca de uma vez por mês. Isso acontece com tanta frequência e tão constantemente que eles inevitavelmente me empurraram para longe do GCP e para o campo de nuvem oposto. Não concordo mais em depender de seus desenvolvimentos proprietários, porque na verdade é mais fácil para um desenvolvedor manter um sistema de código aberto em uma máquina virtual vazia do que tentar acompanhar o Google com sua política de fechamento de produtos "desatualizados".



Antes de voltar para o Google Cloud porque estou ainda pertonão acabou de criticar, vamos dar uma olhada no trabalho 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; ele tem levado muitos funcionários do Google a pensar que suas decisões são sempre certas e que estar certo (por alguma definição vaga e confusa) é mais importante do que o atendimento ao cliente.



Aqui estão alguns exemplos arbitrá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 vivos e atualizados por décadas .



Compatibilidade com versões anteriores é a meta de design de todos os sistemas bem-sucedidos projetados parauso aberto , ou seja, implementado com código aberto e / ou padrões abertos. Eu sinto que estou dizendo algo muito óbvio que todos estão até desconfortáveis, mas não. Esta é uma questão política, portanto, são necessários exemplos.



O primeiro sistema que escolhi é o mais antigo: GNU Emacs, que é uma espécie de híbrido entre o Bloco de Notas do Windows, o kernel do sistema operacional e a Estação Espacial Internacional. É um pouco difícil de explicar, mas em poucas palavras, o Emacs é uma plataforma criada em 1976 (sim, quase meio século atrás) para programar para aumentar sua produtividade, mas se disfarça 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. Mas escrever extensões para IntelliJ é muito mais ambicioso e difícil do que escrever extensões para Emacs. E o mais importante, qualquer coisa escrita para o Emacs durará para sempre .



Ainda uso o software que escrevi para o Emacs em 1995. E tenho certeza que alguém está usando módulos escritos para o Emacs em meados dos anos 80, se não antes. Eles podem exigir pequenos ajustes de vez em quando, mas isso é realmente muito raro. Não sei de nada que já escrevi para o Emacs (e tenho escrito muito) que teria que re-arquitetar a arquitetura.



Emacs tem uma função chamada tornar obsoleto para entidades legadas. 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 os introduziu há muito tempo. Este é um perigo típico para quem está à frente de seu tempo: todos os seus termos estão incorretos. Mas o Emacs tem um conceito de obsolescência, que em seu jargão é chamado de obsolescência .



Mas no mundo do Emacs parece haver uma definição de trabalho diferente. Outra filosofia subjacente, se preferir.



No mundo do Emacs (e em muitas outras áreas que abordaremos a seguir), o status da API legada basicamente significa: “Você realmente não deveria usar esta abordagem, porque embora funcione, sofre de várias desvantagens que listaremos aqui. Mas no final, a escolha é sua. "



No mundo do Google, o status de produto legado significa "Não cumprimos nossa obrigação para com você". É realmente. Isso é o que essencialmente significa. Isso significa que eles o forçarão a fazer algum trabalho regularmente , talvez muito trabalho, como punição por acreditar em seus anúncios coloridos : nós 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 1.500 km.



Estas são duas definições filosóficas completamente diferentes de "obsolescência". A definição do Google cheira a obsolescência planejada . Eu não acredito que realmente sejaobsolescência planejada no mesmo sentido da Apple. Mas o Google está definitivamente planejando quebrar seus programas de uma forma indireta. Eu 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, mas no final das contas isso depende de cada equipe ou serviço individual. Não há recomendação corporativa ou de grau de engenharia, e a recomendação mais ousada em termos de ciclos de obsolescência é "tente dar aos clientes 6-12 meses para atualizar antes de quebrar todo o sistema."



O problema é muito mais sério do que eles pensam e persistirá por muitos anos, porque o atendimento ao cliente não faz parte de seu DNA. Mais sobre isso abaixo.



Por enquanto, vou fazer a afirmação ousada de que o Emacs é bem-sucedido em grande parte, e principalmente , porque eles levam a compatibilidade com versões anteriores muito a sério. Na verdade, essa é a tese de nosso artigo. Os sistemas de código aberto de longa duração bem-sucedidos devem seu sucesso às microcomunidades que viveram em torno de extensões / plug-ins por décadas . Este é o ecossistema. Já falei sobre a essência 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, além do Android ou Chrome.



Na verdade, tenho que mencionar brevemente o Android, porque você provavelmente pensou sobre isso.



Primeiro, Android não é Google... Eles não têm quase nada a ver um com o outro. Android é uma empresa que foi comprada pelo Google em julho de 2005, esta empresa foi autorizada a funcionar de forma mais ou menos autônoma e de fato permaneceu praticamente intacta ao longo dos anos. O Android é uma pilha de tecnologia infame e uma organização espinhosa igualmente infame. Como disse um googler: "Você não pode simplesmente entrar no Android."



Em um post anterior, eu discuti como alguns dos primeiros designs do Android eram ruins. Caramba, quando eu escrevi esse artigo, eles estavam implantando uma merda chamada "Instant Apps" que agora (surpresa!) Obsoletose eu simpatizaria se você fosse estúpido o suficiente para ouvir o Google e trazer seu conteúdo para esses apps instantâneos.



Mas há uma diferença, uma diferença significativa, que é que o pessoal do Android realmente entende como as plataformas são importantes, eles tentam o melhor 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 mesmo eu, durante minha breve passagem pela divisão do 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 estava 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 mantém a compatibilidade com versões anteriores a extremos quase inimagináveis, acumulando uma enorme dívida de tecnologia obsoleta em seus sistemas e conjuntos de ferramentas. Oh meu Deus, você deveria ter visto algumas coisas malucas que eles têm que fazer em seu sistema de compilação, tudo em nome da compatibilidade.



Por isso, dou ao Android o cobiçado prêmio You Are Not Google. Eles realmente não querem se tornar o Google, que não sabe como construir plataformas que duram, mas o Android sabe como fazer isso. E então o Google é muito sábio em um aspecto: ele permite que as pessoas no Android façam as coisas à sua maneira.



No entanto, os aplicativos instantâneos do Android foram uma ideia muito idiota. Você sabe por quê? Porque eles exigiramreescreva e redesenhe seu aplicativo ! Como se as pessoas simplesmente pegassem e reescrevessem dois milhões de aplicativos. Acho que os aplicativos instantâneos foram ideia de algum googler.



Mas há uma diferença aqui. A compatibilidade com versões anteriores é cara. O próprio Android arca com esses custos, enquanto o Google insiste que você , o cliente pago, arraste o fardo .



Você pode ver o compromisso do Android com a compatibilidade com versões anteriores em suas APIs. Quando você tem quatro ou cinco subsistemas diferentes para fazer literalmente a mesma coisa, é um sinal claro de que o compromisso com a compatibilidade com versões anteriores está no centro. 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 maneiras mais antigas e menos desejáveis ​​ao lado de maneiras mais novas e bizarras. Ele aumenta a curva de aprendizado para iniciantes no sistema, aumenta a carga de manutenção de APIs legadas, diminui a velocidade de novos recursos e o principal pecado é o horror. Google - como Lady Ascot de "Alice no País das Maravilhas" de Tim Burton:



Lady Ascot:

- Alice, sabe do que tenho mais medo?

- O declínio da aristocracia?

- Tive medo de ter netos feios .



Para entender a relação entre o bonito e o prático, 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 uma tonelada de APIs legadas. A depreciação é muito popular entre os programadores Java, ainda mais popular do que a maioria das linguagens de programação. No próprio Java, a linguagem e as bibliotecas principais, as depreciações de API ocorrem constantemente.



Se você pegar apenas um dos milhares de exemplos, o fechamento de streams está obsoleto. Ele está obsoleto desde o lançamento do Java 1.2 em dezembro de 1998. Já se passaram 22 anos desde que ele foi suspenso.



Mas meu código de produção real ainda mata threads todos os dias... 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 a função de fechar threads que ficam pendurados por muito tempo e nunca precisei alterá-lo . Conheço meu sistema melhor, tenho literalmente 25 anos de experiência trabalhando com ele na produção e posso dizer com certeza: no meu caso, fechar esses fluxos de trabalho específicos é totalmente inofensivo . Você não deve perder tempo e esforço reescrevendo este código e elogie Larry Ellison (provavelmente) que a Oracle não me forçou a reescrevê-lo.



Provavelmente a Oracle também entende de plataforma. Quem sabe.



Você pode encontrar provas para todas as principais APIs Java que estão repletas de ondas de obsolescência, como as linhas de uma geleira em um desfiladeiro. Na biblioteca Java Swing, você pode encontrar facilmente cinco ou seis gerenciadores de navegação de teclado diferentes (KeyboardFocusManager). 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 a API se a interface causar um grave problema de segurança.



O negócio é o seguinte: nós, desenvolvedores de software, estamos todos muito ocupados e em todas as áreas do software nos deparamos com alternativas concorrentes. A qualquer momento, os programadores X veem Y como uma possível substituição. Oh você não acredita em mim? Você quer ser chamado de Swift? Tipo, todo mundo migra para o Swift e ninguém desiste, 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 de plataforma cruzada de nomes engraçados, como Flutter e React Native, funcionam e podem reduzir o tamanho de suas equipes móveis. duas vezes ou, inversamente, torná-los duas vezes mais produtivos. O dinheiro real está em jogo. Sim, existem compromissos, mas, por outro lado, o de-e-money.



Suponha, hipoteticamente, que a Apple tolamente pegou o exemplo de Guido van Rossum e anunciou 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.



Eu provavelmente contei essa história há dez anos, mas há quinze anos eu fui ao Foo Camp de O'Reilly com Guido, sentei-me em uma barraca com Paul Graham e um monte de grandes solavancos. Sentamos no calor sufocante e esperamos que Larry Page decolasse em seu helicóptero pessoal, enquanto Guido murmurava monotonamente sobre o Python 3000, que ele batizou com o nome do número de anos que levaria todo mundo para migrar para lá. Perguntamos a ele o tempo todo por que quebra a compatibilidade e ele respondeu: “Unicode”. E perguntamos, se tivermos que reescrever nosso código, que outros benefícios veremos? E ele respondeu “Yoooooooooooooouuuuuuuniiiiiiicoooooooode”.



Se você instalar o Google Cloud Platform SDK (“gcloud”), receberá a seguinte notificação:



Caro destinatário,



Gostaríamos de lembrá-lo de que o suporte ao Python 2 foi descontinuado, e você também?


… Etc. O circulo da vida.



Mas a questão é que todo desenvolvedor tem uma escolha. E se você fizer com que eles reescrevam o código com freqüência suficiente, eles podem pensar em outras 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 diabos, Python 3 (000) criou tal bagunça por conta própria, 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 essa incompatibilidade com versões anteriores? Quanto software novo foi escrito em algo diferente de Python, mesmo que possa ter sidoescrito em Python, se Guido não tivesse incendiado a aldeia inteira? É difícil dizer, mas Python claramente sofreu. Esta é uma grande bagunça e todo mundo é um perdedor.



Digamos que a Apple siga o exemplo do Guido e quebre a compatibilidade. O que você acha que vai acontecer depois? Bem, talvez 80-90% dos desenvolvedores reescreverão seu software se puderem. Em outras palavras, 10-20% da base de usuários vai automaticamente para algum idioma concorrente, como Flutter.



Faça isso algumas vezes e você perderá metade de sua base de usuários. Como no esporte, no mundo da programação, a forma atual também significa tudo.... Qualquer um que perder metade de seus usuários em cinco anos será considerado um grande perdedor. Você deve ser uma tendência no mundo das plataformas. Mas é aqui que se recusar a oferecer suporte a versões mais antigas o matará com o tempo. Porque toda vez que você se livra de uma parte dos desenvolvedores, você (a) os perde para sempre, porque eles estão com raiva de você por quebrar o contrato, e (b) os dá para seus concorrentes.



Ironicamente, eu também ajudei a transformar o Google no tipo de prima donna compatível com versões anteriores quando criei o Grok, um sistema de análise e compreensão de código-fonte que facilita a automação e ferramentas baseadas em código - semelhante a um IDE, mas aqui as lojas de serviços em nuvem se materializaram representações 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 refatoração automatizada em toda a base de código (literalmente em todo o Google). O sistema calcula não apenas suas dependências de upstream (das quais você depende), mas também as dependências de downstream (que dependem de você), portanto, quando você altera a API, conhece todos que quebrou! Dessa forma, quando você faz alterações, pode verificar se todos os consumidores de sua API estão atualizados 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 eles renomearem SomeDespicablyLongFunctionName para SomeDespicablyLongMethodName, porque alguém pensou que era um neto feio, e seu precisa ser colocado para dormir.



E para ser honesto, funciona muito bem para o Google ... internamente. Quero dizer, sim, a comunidade Go no Google ri muito da comunidade Java no Google por causa de seu hábito de refatoração contínua. Se você reiniciar algo N vezes, significa que você não apenas estragou tudo N-1 vezes, mas depois de um tempo, ficou claro que provavelmente você estragou na enésima tentativa. Mas, em geral, eles ficam acima dessa confusão e mantêm o código "limpo".



Os problemas começam quando eles tentam impor essa atitude a seus clientes em nuvem e usuários de outras APIs.



Eu apresentei um pouco o Emacs, Android e Java; Vamos dar uma olhada na mais recente plataforma de longa vida de sucesso: a própria web. Você pode imaginar quantas iterações o HTTP passou desde 1995, quando usamos tags <blink> piscando e ícones em construção nas 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 de compatibilidade com versões anteriores. O Chrome é outro exemplo de uma rara plataforma do Google que tem suas cabeças aparafusadas corretamente e, você adivinhou, o Chrome efetivamente atua como uma empresa isolada separada do resto do Google.



Também quero agradecer aos nossos amigos entre os desenvolvedores de sistemas operacionais: Windows, Linux, NOT APPLE FOLLOW YOU APPLE, FreeBSD e assim por diante, por fazer tanto trabalho de compatibilidade com versões anteriores em suas plataformas de sucesso (a Apple obtém, no máximo, um triplo menos, já que eles quebram tudo constantemente sem um bom motivo, mas de alguma forma a comunidade lida com isso em cada versão, e até agora os contêineres do OS X não estão completamente desatualizados ... 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, com sistemas de vários servidores e APIs como serviços em nuvem?



Bem, eu twittei sobre isso ontem, mas no estilo de suck / rule de Larry Wall, pesquisei a palavra obsoleto nos sites de desenvolvedores do Google e da Amazon. Embora a AWS tenha centenas de 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 do Google ler isso, provavelmente está pronto para puxar diagramas que mostram o estilo Donald Trump de que, na verdade, estão fazendo tudo certo e que não devo fazer comparações injustas, como "o número de menções à palavra obsoleta dependendo do número de serviços "



Mas depois de tantos anos, o Google Cloud ainda é # 3 (eu nunca escreveu um artigo sobre a tentativa fracassada de se tornar # 2), mas se você acredita que os insiders, existem alguns medos que em breve poderá afundar a # 4.



Eu não tenho nenhuma convincente argumentos para "provar" sua tese. Tudo o que tenho são exemplos coloridos que acumulei ao longo de 30 anos como desenvolvedor. Já mencionei a natureza profundamente filosófica desse problema; de certa forma, é politizado nas comunidades de desenvolvedores. Algumas pessoas pensam que os criadores de plataformas devem se preocupar com a compatibilidade, enquanto outras acreditam que essa é uma preocupação dos usuários.(os próprios desenvolvedores). Um em cada dois. Na verdade, não é uma questão política quando decidimos quem deve arcar com os custos dos problemas comuns?



Então, isso é política. E certamente haverá reações iradas ao meu discurso.



Como usuário da plataforma de nuvem do Google, bem como usuário da AWS por dois anos (na Grab), posso dizer que há uma grande diferença entre as filosofias da Amazon e do Google no que diz respeito às prioridades. Não estou desenvolvendo ativamente na AWS, então não sei muito bem com que frequência eles removem APIs antigas. Mas suspeita-se que isso não aconteça com tanta frequência como no Google. E eu realmente acredito que essa fonte de controvérsia e frustração constantes no GCP é uma das maiores restrições no desenvolvimento da plataforma.



Eu sei que não citei exemplos específicos de sistemas GCP que não são mais compatíveis. Posso dizer que praticamente tudo que usei, da rede (do mais antigo ao VPC) ao armazenamento (Cloud SQL v1-v2), Firebase (agora Firestore com uma API completamente diferente), App Engine (nem vamos começar), endpoints de nuvem e antes ... Eu não sei - absolutamente tudo isso fez você reescrever o código em no máximo 2-3 anos, e eles nunca automatizaram a migração para você, e muitas vezes não havia nenhum caminho de migração documentado . Como se devesse ser.



E sempre que olho para a AWS, me pergunto por que diabos ainda estou sentado no GCP. Eles claramente não precisam de clientes. Eles querem compradores . Você entende a diferença? Deixe-me explicar.



O Google Cloud tem um Marketplace onde as pessoas oferecem suas soluções de software e para evitar o efeito de um restaurante vazio, eles tiveram que enchê-lo com algumas sugestões, então eles contrataram a Bitnami para criar um monte de soluções que são implantadas "com um clique", ou Eu mesmo tenho que escrever as "soluções", porque elas não resolvem absolutamente nada. Eles existem apenas como caixas de seleção, como preenchimento de marketing, e o Google nunca se importou se alguma das ferramentas realmente funcionou. Conheço gerentes de produto que dirigiram e posso garantir que essas pessoas não se importam.



Tome, por exemplo, a solução de implantação "um clique" Percona... Eu estava entediado de morte com as travessuras do Google Cloud SQL, então comecei a considerar a criação de meu próprio cluster Percona como alternativa. E desta vez o Google parecia estar fazendo um bom trabalho, eles iam 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 todos os padrões e implantar o cluster em seu projeto de nuvem do Google. Haha, não funciona. Nada dessa merda funciona. A ferramenta nunca foi testada e começou a apodrecer desde o primeiro minuto, e não me surpreenderia se mais de metade das “soluções” para a implantação de um clique (agora entendemos por que as aspas) fazer não funcionar em todos. Esta é uma escuridão absolutamente desesperadora, onde é melhor não entrar.



Mas o Google explicitamente incentiva você a usá-los. Eles querem que você os compre . Para eles, é uma transação. Eles não querem apoiar nada . Não faz parte do DNA do Google. Sim, os engenheiros se apoiam, como evidenciado pela minha história com o Bigtable. Mas em produtos e serviços para pessoas comuns, eles sempre foram implacáveis ​​ao encerrar qualquer serviço que não alcançasse o padrão de lucratividade, mesmo que tivesse milhões de usuários.



E isso representa um verdadeiro desafio para o GCP, porque esse DNA está por trás de todas as ofertas de nuvem. Eles não procuram apoiar nada; é sabido que eles se recusam a hospedar (como um serviço gerenciado) qualquer software de terceiroscontanto que a AWS não faça o mesmo e não construa um negócio de sucesso ao redor, e quando os clientes exigem exatamente o mesmo. No entanto, é preciso algum esforço para fazer o Google apoiar algo.



Essa falta de cultura de suporte, juntamente com o princípio de “vamos quebrar para torná-lo bonito”, afasta os desenvolvedores deles.



E isso não é bom se você deseja construir uma plataforma de longa duração.



Google acorda porra. É 2020. Você ainda está perdendo. É hora de olhar no espelho de perto e responder se você 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. Portanto, quando se trata de quem vai assumir o fardo da compatibilidade, você precisa assumir. Não para nós.



Porque há pelo menos mais três nuvens realmente boas. Eles acenam para eles.



Agora vou consertar todos os meus sistemas quebrados. Eh.



Até a próxima vez!



PS Update depois de ler algumas das discussões neste artigo (as discussões são ótimas, a propósito). O Firebase não foi descontinuado e não há planos que eu saiba. No entanto, eles têm um erro de streaming desagradável que está fazendo com que o cliente Java pare no App Engine. Um de seus engenheiros me ajudou com esse problema quando eu estava trabalhando no Google, , , GAE. ! Firestore. , , , Firebase . ? , . , , Firebase GAE, 100 100% , - . , . Redis.



, AWS , AWS , SimpleDB — . , AWS , Google, , .



, , 20 Google App Engine Go, GAE Go. , .



, , ( , !). , , Google . , , AWS, Grab. - , !



, 2005 43, . 2006 . Bigtable 2007 .



Bigtable (-), . , , , , , .



, Apple Microsoft . . , , ! , , ?



.



2, 19.08.2020. Stripe API!



Atualização 3, 31/08/2020. Fui contatado por um engenheiro do Google no Cloud Marketplace que acabou por ser um velho amigo meu. Ele queria descobrir por que o C2D não funcionava e, no final, descobrimos: o motivo é que criei minha rede há alguns anos e o C2D não funciona em redes legadas devido à falta do parâmetro de sub-rede em seus modelos. Acho que é melhor para os usuários em potencial do GCP garantir que eles tenham engenheiros familiares suficientes no Google ...



All Articles