Após migração de 11 semanas para Kubernetes, empresa esquece por que existe (2020)
(theolognion.com)- A startup do Vale do Silício Xenobroom Inc. decidiu migrar sua infraestrutura de servidores existente para Kubernetes em maio de 2020, quando o uso diário disparou durante a pandemia
- A migração foi além de uma simples melhoria de deploy e virou um trabalho de longo prazo para reavaliar e redesenhar a configuração baseada em scripts bash e VPS
- O escopo continuou aumentando, com atualizações de dependências e bibliotecas, conversão de partes do PostgreSQL para armazenamento KV distribuído e aproveitamento da flexibilidade da AWS
- O antigo servidor de staging e os deploys diários baseados na branch develop foram substituídos por um fluxo de trabalho de CI somente em produção, roteamento dinâmico, testes A/B e suporte a dependências regionais
- Quando a migração parecia ter terminado, ninguém na equipe conseguia lembrar o propósito do produto; usuários e investidores também admitiram não entender o produto original, tornando a restauração praticamente impossível
Escopo ampliado pela migração para Kubernetes
- A Xenobroom Inc. começou a atualizar sua infraestrutura de servidores em maio de 2020
- Segundo fragmentos do diário do CEO e notas de engenharia do CTO, o uso diário aumentou rapidamente durante a pandemia
- Depois disso, a empresa decidiu migrar a infraestrutura existente para Kubernetes
- O trabalho levou mais tempo do que o previsto
- Foi necessário recriar, revisar e reengenheirar os scripts bash simples e as máquinas VPS
- Internamente, a empresa viu nisso uma oportunidade para também atualizar dependências de software e bibliotecas
- A mudança de infraestrutura levou a uma reestruturação maior
- A empresa avaliou que grandes partes do banco de dados PostgreSQL, que rodava em uma única máquina, poderiam ser trocadas por armazenamento KV distribuído
- Também foi usado o argumento de aproveitar a flexibilidade da AWS
- O servidor de staging simples, com deploys diários a partir da branch develop, desapareceu
- Em seu lugar, foi introduzido um fluxo de trabalho de CI somente em produção com roteamento dinâmico, em uma configuração que passou a oferecer suporte fluido a testes A/B e dependências regionais
Perda do propósito do produto e ajuda externa
- Quando o processo de migração parecia concluído, ninguém dentro da empresa conseguia se lembrar do propósito do produto
- Usuários e investidores também não conseguiram resolver a situação
- Ambos os grupos admitiram publicamente que nunca haviam entendido direito o produto desde o início
- Após algumas semanas de downtime, restaurar o significado do produto tornou-se praticamente impossível
- O CEO buscou ajuda de Phutar Afrayughum, um médium e especialista em percepção extrassensorial
- Ele é apresentado como alguém que ajudou o Google a aumentar sua participação no mercado de apps de mensagens e também participou do desenvolvimento do framework Material Design
- No entanto, essa ajuda é tratada como “allegedly”, sem ser afirmada como fato
1 comentários
Opiniões do Hacker News
Este texto é ainda mais engraçado: diz que depois de demitir 20% dos gerentes intermediários, a produtividade de desenvolvimento aumentou por acaso em 3x
https://www.theolognion.com/p/company-accidentally-increased...
No meu $dayjob também estamos fazendo uma migração dessas; ela começou há 2 anos, mas ainda não chegou nem a 30%
As pessoas que antes gritavam mais alto “temos que ir para Kubernetes, temos que matar o monólito” agora esqueceram Kubernetes porque estão brincando com LLMs
Algumas pessoas realmente gostam de provas de conceito e de coisas novas e brilhantes, e esse papel até parece ter alguma utilidade
Por isso, pessoas inteligentes parecem trabalhar bastante satisfeitas até em gigantes de tecnologia antiéticas, empresas de publicidade e empresas de vigilância
Não importa muito por que a empresa existe, nem o que ela faz de fato fora do próprio computador; o que importa é a tecnologia e a liberdade de buscar coisas novas
A empresa gosta da produtividade e do entusiasmo que elas geram, e paga bem por isso
Em geral, esses desenvolvedores também têm consciência, mas muitas vezes essa consciência é absorvida e exibida na forma de ativismo social benigno e amigável às empresas
Alguém vai marcando caixinhas para poder dizer “já trabalhei com X”
Em equipes pequenas, esse tipo de abordagem pode travar a produtividade muito rapidamente, e costuma vir embrulhado no desejo de resolver todos os problemas
Mas o resultado é que nenhum problema é resolvido e, em vez disso, surgem ainda mais problemas novos
Para uma promoção é preciso um pacote de promoção, e para um pacote de promoção é preciso um projeto grande e pesado
No fim, como o problema central a resolver deixa de ser uma necessidade do negócio e passa a ser a promoção, surgem projetos enormes em busca de um problema
O que foi descrito nem parece ser uma prova de conceito. O requisito básico de uma prova de conceito é, antes de tudo, funcionar; isso está mais para criar uma configuração para seguir a manada e parecer ocupado
Do ponto de vista do funcionário, também não parece ser um ambiente bom para ficar por muito tempo
Esse blog tem muitos outros textos ainda mais engraçados. Gostei especialmente deste:
https://www.theolognion.com/p/dev-builds-perfect-note-taking...
E também tem este:
https://www.theolognion.com/p/ai-solves-all-political-econom...
Assim os outros podem economizar dois cliques
Sei que é piada, mas, se fizessem uma análise post-mortem, a causa do fracasso provavelmente seria algo como: “muitas pessoas dentro da empresa acharam que esta era uma oportunidade para também fazer upgrades de dependências de software e bibliotecas. Também viram que uma grande parte do banco de dados PostgreSQL que rodava em uma única máquina poderia ser transformada em um armazenamento distribuído de chave-valor, aproveitando a enorme flexibilidade da AWS”
É preciso proteger o escopo
Há muita gente no mundo mais focada na tecnologia que usa do que no produto que constrói
Focar no produto significa conhecer o escopo e não projetar demais cedo demais
A piada foca em Kubernetes, mas daria para fazer a mesma coisa com renderização no servidor, AI, $modernFrontendLib ou $modernLanguage
Se o negócio não é vender infraestrutura de nuvem, use um provedor de nuvem pronto
Se você já está pagando um provedor de nuvem, em especial, é melhor não usar Kubernetes
Na vida real, uma migração para Kubernetes de 11 semanas teria sido considerada um enorme sucesso
Claro que operar o banco de dados teria sido um pouco difícil. Afinal, teriam esquecido de configurar direito o armazenamento do Kubernetes, então os dados teriam sumido depois que um pod se moveu de repente
Se nem Docker usava, é bem provável que, em uma migração parecida, o problema não seja o Kubernetes em si
Nunca foi tão fácil e barato operar sistemas quanto agora
Mas os engenheiros preferem montar uma expedição para entregar uma pizza, escalar o Everest, tirar uma foto da pizza no topo, trazê-la de volta para casa de avião, alugar uma Lamborghini para correr o Rally da Mongólia e só então, 18 meses depois, entregar a pizza
Enquanto isso, quem simplesmente pegar uma scooter barata e descer a rua vence
Se é uma tecnologia complexa, é preciso aprendê-la primeiro. É preciso tentar antes em um serviço pequeno e sem importância
Faça uma coisa de cada vez e comece simples
Migrei nossos serviços para Kubernetes sem problemas, mas levei 2 anos aprendendo e experimentando ao mover serviços pequenos
Depois de tentar várias abordagens, cheguei à forma mais adequada, que não era algo que se encontrasse imediatamente na internet
Usamos GitOps, mas sem automação; simplesmente executamos
kubectl apply -kpara o que for necessário. Na época, julgamos que o flux era desnecessariamente complexo para começarAgora que já temos dezenas de serviços e mais entendimento, estamos pensando em adotar o flux
Em 1977, trabalhei como jovem advogado litigante em um escritório de advocacia que cobrava por hora.
Registrávamos em papel que trabalho havia sido feito em cada caso, e os funcionários administrativos cortavam tiras destacáveis dos papéis concluídos e as colavam na parte interna da pasta de papel de cada caso.
Em 1979, comprei um RadioShack Tandy I e logo mergulhei fundo, em casa, no Foxbase, um programa de banco de dados baseado em DOS. Mais tarde ele virou FoxPro e foi adquirido pela Microsoft no início dos anos 1990.
Em 1981, abri meu próprio escritório de advocacia, e a inovação mais recente em produtividade de escritório na época eram o fax e máquinas de escrever elétricas com uma tela de uma linha, memória e um pequeno disco para armazenar formulários. As empresas ainda não usavam computadores pessoais.
Meu escritório logo chegou a cerca de 10 advogados e 12 pessoas de equipe de apoio, e comprei computadores Compaq para todas as secretárias.
Passei muito tempo escrevendo um programa de controle de horas e faturamento para substituir a colagem manual de tiras, e também aprendi a instalar redes e fiz a instalação eu mesmo.
Outros escritórios de advocacia que eu conhecia não tinham computador nenhum, mas nós tínhamos mais de 10 para a equipe de apoio e 4 ou 5 Compaq “portáteis” para os advogados revisarem as faturas antes de enviá-las aos clientes.
Ao mesmo tempo, eu estava arruinando meu negócio. Numa época em que os outros nem sequer tinham um computador, nós tínhamos tecnologia de nível mundial, mas eu não me concentrava no trabalho jurídico nem em conquistar clientes corporativos; ficava de porta fechada, só programando.
No fim, fechei o escritório em 1994.
Ainda assim, foi uma época empolgante. Logo todos os escritórios de advocacia passaram a ter computadores para processamento de texto, mas ainda não havia programas comerciais de faturamento.
Por cerca de 24 meses, todos os advogados de outros escritórios com quem trabalhei quiseram o meu programa de faturamento.
Mas, mesmo atolado no trabalho dos casos, eu só me dedicava à programação divertida, e minha prática jurídica era o laboratório perfeito para o programa. Infelizmente, essa programação arruinou meu negócio.
Se ainda houver alguma foto, eu gostaria de ver.
Na minha área, dá para trocar “Kubernetes” por GraphQL/React/Next que continua valendo igual.
Claro, trata-se de migrar um app que funciona perfeitamente bem — e que, em sua maior parte, é CRUD.
Mesmo sem nenhuma necessidade dos trade-offs trazidos por GraphQL ou por um front-end interativo, fazem isso mesmo assim.
Quanto mais tempo passo neste setor, mais vejo que as pessoas em cargos de responsabilidade muitas vezes não sabem o que estão fazendo.
São recompensadas por mudanças, desde que possam ao menos fingir que essa mudança está gerando resultados, ou que algum dia vai gerar.
Estou há 4 meses brigando dia e noite para mover 500 mil blobs de um MinIO auto-hospedado para um armazenamento de blobs gerenciado, e o trabalho realmente produtivo, que não seja política e burocracia, não chega a 1 semana.
Então uma migração para Kubernetes em 11 semanas soa como um grande sucesso.