Morte por mil microsserviços
(renegadeotter.com)- A crítica é que a cultura de adotar microsserviços como padrão aumentou custos e complexidade para resolver problemas que não existem, em vez de responder a questões reais de escala
- O fechamento do ecossistema de JavaScript/Node.js, práticas no estilo FAANG e a abundância de capital de risco se combinaram para criar entre startups um clima de imitação de arquitetura web-scale
- Mesmo com Docker e Kubernetes, as dificuldades dos sistemas distribuídos — como desenvolvimento, depuração, implantação, testes e garantia de resiliência — não desaparecem
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow e WhatsApp começaram com bases de código monolíticas ou ainda mantêm um monólito no núcleo
- Como a maioria das empresas não atinge a escala que realmente exige sistemas distribuídos, o mais realista é separar em serviços apenas as cargas que precisam claramente de isolamento e escalabilidade
A cultura de venerar a complexidade
- A sátira sobre fracassar ao explicar um labirinto complexo de microsserviços para obter apenas a data de aniversário de um usuário mira o excesso de engenharia da cultura tecnológica atual
- O problema é que o objetivo mudou de resolver desafios imediatos para queimar dinheiro tentando resolver problemas que não existem
- A crítica a JavaScript e Node.js não é só sobre uma tecnologia específica, mas se conecta ao risco de ecossistemas de software fechados que fazem o setor reaprender lições já conhecidas
- O setor já passou por experiências de bater em muros de complexidade como CORBA e SOAP e depois recuar
As condições que criaram a moda dos microsserviços
- Desenvolvedores que usavam JavaScript no navegador passaram a se autodenominar “full-stack” e entraram no desenvolvimento de servidores e no código assíncrono; o Node inicial era quase um projeto de aprendizado individual, e o JavaScript do começo era uma opção problemática para desenvolvimento de servidores
- Como se o mundo fora do Node praticamente não existisse, surgiu um pensamento dogmático de que o jeito do Node era o único jeito
- Depois, profissionais vindos de FAANG entraram em startups e difundiram “o jeito que fazíamos no Google” como se fosse a resposta certa, sem considerar contexto ou escala
- Um exemplo representativo é a pressão de que, sem um
User Preferences Serviceseparado, não haveria escalabilidade
- Um exemplo representativo é a pressão de que, sem um
- No período de abundância de capital de risco, tornou-se mais importante mostrar crescimento explosivo aos investidores do que receita, e as empresas contrataram rapidamente engenheiros de software caros para fazê-los construir “alguma coisa”
Sistemas distribuídos continuam difíceis
- Os microsserviços foram apresentados como “uma nova forma de escrever software escalável”, mas na essência estão ligados aos problemas de sistemas distribuídos que existem há muito tempo
- No passado, sistemas distribuídos eram vistos como ferramentas difíceis e arriscadas, quase um último recurso para problemas particularmente complicados
- Em sistemas distribuídos, todas as tarefas a seguir ficam mais difíceis e mais demoradas
- desenvolvimento
- depuração
- implantação
- testes
- garantia de resiliência
- O desenvolvimento baseado em microsserviços não conta com ferramentas padrão nem frameworks comuns, e mesmo nos anos 2020 o trabalho com sistemas distribuídos ficou apenas um pouco mais fácil
- Docker e Kubernetes não removem magicamente a complexidade essencial de um ambiente distribuído
Casos em que a simplicidade gerou resultados melhores
- Resumo de 5 anos de auditorias de código em startups conclui que as startups que deram certo adotaram uma abordagem quase descaradamente Keep It Simple
- Migração precoce para microsserviços, arquiteturas dependentes de computação distribuída e design centrado em mensageria foram armadilhas importantes que colocaram várias empresas em dificuldade
- Muitas startups constroem sistemas simples e de bom desempenho, mas ainda assim sentem uma falsa inferioridade por “não fazer microsserviços desde o primeiro dia”
- À pergunta “o que há de errado em ter só um monólito em Django e uma instância de MySQL mantidos por alguns engenheiros?”, a resposta quase sempre é “não há nada de errado”
- Até engenheiros experientes se sentem inadequados na cultura tecnológica atual, mas o problema real pode ser um ambiente misturando autoconfiança injustificada, desperdício e efeito Dunning-Kruger
Empresas que cresceram com monólitos
- A ideia de que não dá para crescer sem abandonar o monólito é praticamente um mito
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify e StackOverflow começaram com uma base de código monolítica, e algumas ainda mantêm um monólito no núcleo
- O StackOverflow trata como motivo de orgulho, em sua página de performance, operar um site enorme com pouco hardware
- A Shopify ainda usa um monólito em Rails e processa bilhões de jobs com o comprovado Resque
- O WhatsApp cresceu enormemente com um monólito em Erlang e cerca de 50 engenheiros
- A organização de engenharia foi mantida pequena, com cerca de 50 pessoas
- As equipes individuais têm de 1 a 3 pessoas e alta autonomia
- Há preferência por poucos servidores, expandindo cada um deles verticalmente o máximo possível
- O Instagram foi adquirido por bilhões de dólares com uma equipe de 12 pessoas, e o Threads segue o modelo do Instagram
Não se deve resolver problemas que não existem
- A pergunta central é: “qual problema isso resolve?”
- Se escala é o problema, é preciso ter dados que mostrem o que deve ser separado em um serviço à parte e por quê
- Sistemas distribuídos são criados para escala e resiliência, mas é preciso considerar inclusive o que acontece quando um serviço fica lento ou cai e o tráfego se desloca para outros serviços
- Os fatores necessários a considerar variam conforme os padrões de uso e as características de carga do sistema
- backpressure
- circuit breakers
- filas
- jitter
- timeouts razoáveis em todos os endpoints
- proteções para que pequenas mudanças não causem falhas generalizadas
- A maioria das empresas não chega à escala gigantesca que realmente exige sistemas distribuídos
- Tentar imitar Amazon e Google sem ter a escala, a especialização e os recursos dessas empresas costuma desperdiçar tempo e dinheiro
- Fica o alerta de que um sistema distribuído ruim é ainda pior do que os próprios sistemas distribuídos
O ideal e a realidade de serviços e APIs por equipe
- A tentativa de alinhar a topologia distribuída à estrutura da empresa parte da ideia de que dividir o problema em pedaços menores o tornará mais fácil
- No ideal, um microsserviço teria uma equipe dedicada, seria mantido com rigor, ficaria escondido atrás de uma API versionada bonita e retrocompatível, e exigiria pouca ou nenhuma comunicação com outras equipes
- Na realidade, canais de Slack ficam cheios de releases, bugs, mudanças de configuração, mudanças quebrando compatibilidade e avisos
- Todo mundo precisa estar sempre por dentro de tudo, e é comum equipes já sobrecarregadas assumirem vários microsserviços de forma improvisada
- Conforme as pessoas mudam de função ou saem da empresa, a propriedade dos serviços também muda, e o resultado passa a ser várias golf carts ruins em vez de um bom carro de corrida
O que os microsserviços fazem você perder
-
Enfraquecimento do DRY
- Microsserviços, por natureza, não são DRY, e cada serviço acaba carregando boilerplate duplicado
- Em microsserviços pequenos, o peso do código de infraestrutura cresce tanto que a instância média pode ficar mais parecida com código de “serviço” do que com código de produto
- Mesmo tentar extrair código comum leva a opções dolorosas
- criar bibliotecas compartilhadas exige definir estratégias de versão e atualização
- é possível forçar atualizações criando pull requests periódicos em todos os repositórios
- reunir tudo em um monorepo cria seus próprios problemas
- resta permitir alguma duplicação de código ou fazer cada equipe reinventar a roda repetidamente
-
Piora da experiência do desenvolvedor
- Experiência do desenvolvedor é a quantidade de atrito e esforço necessários para criar uma nova funcionalidade ou corrigir um bug
- Em um ambiente de microsserviços, é preciso ter um mapa mental do sistema inteiro para saber quais serviços subir para uma tarefa específica, com que equipe falar e a quem perguntar o quê
- A Spotify criou o Backstage para catalogar inúmeros sistemas e serviços, o que indica o alto custo desse jogo
- Empresas que não são a Spotify acabam montando soluções próprias improvisadas, das quais é difícil esperar robustez e portabilidade
- Iniciar um novo serviço também exige automatizar muita coisa
- permissões de desenvolvedor no GitHub/GitLab
- variáveis de ambiente e configurações padrão
- CI/CD
- verificações de qualidade de código
- configurações de code review
- regras e proteções de branch
- monitoramento e observabilidade
- test harness
- infraestrutura como código
- Se várias linguagens de programação forem usadas, essa lista se multiplica pelo número de linguagens
- Refinar toda essa automação pode levar meses, criando a situação de ter que escolher entre construir o produto ou construir ferramentas
-
A dificuldade dos testes de integração
- Mesmo que testes unitários e testes de um único serviço passem, isso não significa que o caminho crítico continue intacto após cada commit
- Testes de integração em ambientes distribuídos passaram a ser tratados como um problema quase impossível, e em seu lugar entrou a observabilidade
- Observabilidade virou um novo setor da indústria e exige não apenas custo financeiro, mas também tempo de desenvolvedor
- Observabilidade não funciona instantaneamente como um plugin; é preciso entender e implementar coisas como canary releases e feature flags
- Dividir o problema não o torna mais fácil de resolver; você apenas ganha um conjunto de problemas mais difíceis
Monólito não significa automaticamente código bom
- Defender o monólito não significa dizer que “monólito é código bom e microsserviços são código ruim”
- Na prática, há muitos monólitos medianos feitos por equipes apressadas ou apenas comuns
- A diferença é que sistemas distribuídos são muito mais severos com atalhos, más decisões e modos de falha não considerados
- Se não forem operados sempre em alto nível, sistemas distribuídos cobram o preço
Talvez não precise ser micro, basta ser um serviço
- Um serviço não precisa necessariamente ser “micro”; em muitos casos, apenas um serviço já basta
- Algumas startups foram longe a ponto de criar um serviço por função, mostrando até onde um cargo cult não validado pode chegar
- Começar com um monólito é uma opção clara
- O padrão “trunk & branches” também pode servir bem em vários casos
- O núcleo funcional fica com um monólito principal, o “arroz com feijão”
- Cargas claramente identificáveis e que precisam de escalabilidade separada ficam com serviços branch
- Um
Image-Resizing Serviceque consome muita CPU faz mais sentido como serviço separado do que umUser Registration Service - O critério para separar um serviço passa por perguntar se o volume de registros por segundo é alto o suficiente para exigir escalabilidade horizontal independente
O recuo da moda e escolhas mais realistas
- O superaquecimento dos microsserviços parece estar esfriando, e com a contração do fluxo de capital de risco o mercado vem forçando empresas a tomar decisões mais sensatas
- Gastar dinheiro com arquitetura web-scale sem ter um problema de escala web não é sustentável
- Se você precisa ir de Nova York à Filadélfia, a solução adequada ao problema é comprar uma passagem de 90 minutos da Amtrak, não construir uma nave espacial complexa
1 comentários
Opiniões no Hacker News
Eu sou uma das pessoas que sempre defendeu fortemente microsserviços, ajudei a construir a plataforma da Netflix e viajei pelo mundo pregando suas vantagens, mas, ao aconselhar startups, quase sempre digo para começar com um monólito
É muito mais fácil manter a base de código e o banco de dados em um só lugar, e isso escala por bastante tempo. Se você usar um armazenamento chave/valor como o DynamoDB, perde parte dos recursos relacionais, mas consegue aguentar ainda mais
Um monólito também pode ser implantado no Lambda, e você pode obter as vantagens do Lambda sem dividir serviços
Só depois de crescer é que você deve separar, como microsserviços com seus próprios armazenamentos de dados, as partes que precisam escalar de forma independente ou ter deploy separado
Microsserviços consomem pelo menos 25% do tempo de engenharia só para manter a plataforma, então não têm valor se você não conseguir recuperar esse ganho de eficiência
Enquanto estiver crescendo — ou, na maioria dos casos — é melhor nem usar microsserviços
E, por favor, não divida os dados. Dados são muito mais complexos de gerenciar do que código
Sempre dá para tornar as coisas mais complexas depois. Você pode extrair partes de um monólito e transformá-las em serviços; é difícil, claro, mas nem se compara a remover de um sistema a complexidade que já foi introduzida
Quem já tentou transformar vários microsserviços de volta em um monólito sabe que, em geral, o esforço fica parecido com reescrever tudo do zero
Se quisesse, esse tipo de produto poderia literalmente rodar o ambiente de produção em um notebook
Em um emprego anterior, fizeram uma festa de microsserviços para atender 300 clientes. Era um negócio em que alguns milhares de clientes já seriam um sucesso, e dezenas de milhares seriam um enorme sucesso
Como normalmente não se gasta 25% do tempo de engenharia mantendo a plataforma, acaba-se com algo que nem roda localmente e cujo ambiente de produção fica colado com fita adesiva
Em uma entrevista recente, me pediram para projetar um sistema para “500 milhões de usuários simultâneos”, mas a empresa era, em geral, do tipo com poucos clientes e alta receita por cliente
Ainda não sei se era um teste para eu apontar que 500 milhões é um número absurdo — cerca de 10% da população mundial conectada à internet — ou se eles realmente acreditavam que uma startup poderia chegar a isso
Respondi que me concentraria no mais simples: construir um monólito e verificar se as funcionalidades e o produto eram o que as pessoas queriam. Não fui contratado
Trabalho em um enorme monólito com cerca de 800 contribuidores, e até adicionar um campo simples como aniversário do usuário é igualmente complexo. Só que a complexidade não é toda técnica; como mexe no código de todo mundo, exige “alinhamento organizacional”
O desenho e as revisões se repetem sem fim, exigem aprovação de pelo menos 2 arquitetos e entram em vários ciclos de planejamento. O código em si leva menos de meio dia
No code review, é preciso atingir 90% de cobertura de testes, mas há tantos testes que um único PR fica grande demais, então ele é dividido em vários PRs e acaba entrando ao longo de vários releases semanais
Por isso, a funcionalidade fica escondida atrás de uma feature flag, e hoje existem 13.000 feature flags
Quando entra em produção e recebe dashboards e monitoramento, ela é ligada e desligada repetidas vezes. Não temos certeza de por que a funcionalidade de aniversário quebrou o serviço de cobrança, mas parece ser a causa, então serão necessárias semanas de análise
No fim, um ano depois, o engenheiro responsável por esse trabalho pode receber uma boa avaliação e virar candidato a promoção. E logo em seguida é colocado em outro projeto quebrado que entra em seu terceiro ano de desenvolvimento: permitir que o usuário configure o fuso horário
Nem microsserviços nem monólitos são martelos universais ou balas de prata; por outro lado, também não são o mal em si. Ambos são ferramentas com trade-offs, combinadas a trade-offs de contextos diferentes em cada organização
O problema é engenheiros se encantarem com complexidade, confundirem “simplicidade” com “quebra-galho” e organizações copiarem cegamente ferramentas e padrões de arquitetura
Achar que basta usar uma arquitetura ou um design pattern para obter benefícios, e aplicá-los ingenuamente, não faz esses benefícios aparecerem
Tentei manter em mente que engenharia de software é uma luta sem fim contra a complexidade; às vezes tive sucesso, às vezes fracassei
Essa luta precisa acontecer sempre e deve ser a prioridade máxima. Caso contrário, coisas assim acontecem
Não existe arquitetura ou ideologia que encerre essa guerra; isso é simplesmente a essência da profissão
No ambiente de produção, impedíamos que essas flags de release fossem ativadas, e os desenvolvedores precisavam remover o código da flag antes dos testes finais e do release
Isso acrescenta um pouco de trabalho a cada funcionalidade que precisa de flag, mas, depois de alguns meses, o retorno em redução da complexidade da base de código é enorme
Microsserviços não são uma solução para um problema técnico, mas para um problema social
Uma equipe com N engenheiros exige N² de coordenação. Equipes grandes caem em reuniões, e-mails e revisões de design sem fim; equipes pequenas são mais eficazes, mas têm dificuldade para manter sistemas grandes
Ao dividir o sistema em subsistemas, cada equipe pode se concentrar na sua peça do quebra-cabeça, reduzindo a coordenação entre pessoas
É verdade que microsserviços acrescentam complexidade e overhead, mas essa abordagem permite que organizações grandes construam sistemas grandes rapidamente e façam melhorias iterativas
Agora, em vez de conexão direta, passam a ser necessárias reuniões “cross-functional” entre equipes e uma camada de comunicação complexa
Se você encontrou uma decomposição em que quase não são necessárias conexões entre subsistemas, então essas conexões provavelmente nem existiam no sistema original, e também não haveria problema N²
O que vi repetidamente foi uma única equipe gigantesca em que “todo mundo é responsável por todos os microsserviços” e, no fim, ninguém é responsável por nada
Para resolver um “problema de pessoas”, transformam um problema técnico trivial em um problema complexo de sistema distribuído
Agora sim você tem um problema de verdade
Ele dava suporte a dois tipos de banco de dados e também tinha um executor de tarefas escalável horizontalmente
Em certo momento éramos 35 pessoas, mas, com demissões, ficamos em 7; e foi aí que começamos a entregar muito mais. Porque o tempo gasto alinhando todo mundo caiu muito
Havia muito menos reuniões, aprovações, revisões, planejamento, retrospectivas e reuniões de gestão; os desenvolvedores ganharam mais autonomia e simplesmente faziam o trabalho
As funcionalidades eram facilmente concluídas em metade do tempo, e os outros 50% eram usados para pagar dívida técnica. Como reduzíamos a complexidade sem piedade, a velocidade para adicionar novas funcionalidades também aumentou
Alguns projetos talvez precisem de mais gente, mas acredito que há um limite superior para a complexidade que se consegue adicionar a um sistema dentro de determinado período
Se, depois de passar desse limiar, você aumenta o número de desenvolvedores, a quantidade de funcionalidades por semana fica igual, mas todo mundo trabalha um pouco menos e passa mais tempo se comunicando
Repita esse processo até chegar a milhares de pessoas e adicionar um único campo passa a levar meses
Fico curioso se alguém considerou simplesmente mover para pastas diferentes
Não é preciso modularizar com repositório novo e configuração nova de Docker. Basta usar pastas
Um padrão que vejo com frequência é este: os CTOs ou VPs atuais criaram o monólito original, ou participaram da sua criação
Ninguém quer dizer ao CTO que aquele código é horrível. Ou talvez seja apenas um código que, com a mudança dos tempos, precisa de uma reformulação completa, sem que isso tenha relação com o fato de ser um monólito
O CTO está ocupado com marketing ou captação de investimento e não decide entre microsserviços e monólito; então um arquiteto recém-contratado toma a decisão
Todo mundo aplaude os microsserviços. Isso combina bem com a narrativa de uma empresa de tecnologia séria e em rápido crescimento, e ninguém quer ser o único a discordar ou a criticar o CTO
Quase nunca é porque alguém acredita sinceramente que microsserviços sejam o melhor trade-off. É porque gostam do próprio trabalho, gostam de contratar mais gente e isso se encaixa bem na narrativa da empresa
Durante a grande reformulação, dá para reescrever e melhorar muito código; basta chamar isso de migração para microsserviços
No fim, vira uma forma de reescrever em massa código antigo e ruim, sem ferir os sentimentos do CTO, seguindo a multidão e sob uma justificativa que quase todo mundo apoia
Seja um engenheiro líder individual, seja um CTO/fundador, no fim a pessoa olha para trás e conclui que poderia ter feito melhor, e vê, com alegria e horror, os benefícios e as desvantagens dos padrões e processos que a equipe seguiu de boa-fé
Gosto ainda mais do texto porque ele confirma o meu viés
Venho dizendo isso há anos, mas vejo a febre dos microsserviços mais como uma desculpa para engenheiros medianos manterem a demanda por eles. A mediocridade alimenta isso e, ao mesmo tempo, mantém muitas empresas de tecnologia funcionando
Não há engenheiros competentes em número suficiente que saibam lidar direito com UNIX e criar sistemas minimalistas bonitos como o StackOverflow
Por isso, os microsserviços como cortina de fumaça para encobrir a mediocridade vão continuar existindo. Ainda mais porque provedores de nuvem como a AWS se promovem por todos os canais possíveis e fazem os tomadores de decisão seguirem esse caminho
Se você não fala de nuvem, microsserviços e frameworks novos não comprovados, é tratado como um velho ultrapassado
Mesmo que esses sistemas raramente sejam os mais eficientes, robustos ou seguros
Minha empresa atual cria software usado internamente por outras empresas, com no máximo 200 usuários simultâneos e sem picos de uso
Seria um ambiente perfeito para um servidor web comum, sem problemas inesperados de escala, mas todo mundo quer ir para a nuvem
Acho que o motivo é que a diretoria, os programadores e até os clientes foram convencidos pelo marketing da nuvem e acreditam que a nuvem é legal
As empresas não enviam para o produto apenas o organograma, mas também todas as disfunções e bagagens históricas
Mesmo que cinco anos atrás fosse uma plataforma bonita, com um modelo de dados e APIs eficientes e bem projetados, além de código bem escrito e testado, cinco anos depois ela pode virar uma bagunça completa por causa de mudanças constantes de direção do CEO, pedidos de clientes de última hora empurrados pela equipe de vendas, gerentes de produto adicionando funcionalidades que não eram necessárias nem solicitadas, e falta de pessoal e de tempo
Um dia você se vê diante de uma pilha enorme de dívida técnica, em uma situação em que correções de bugs e adição de funcionalidades demoram mais do que deveriam, e microsserviços soam como o canto da sereia sussurrando que não é preciso queimar tudo e recomeçar do zero
Pode parecer picuinha, mas há um ponto maior aqui. A escolha da tecnologia raramente é o gargalo
Em contrapartida, microsserviços têm muito mais partes móveis e modos de falha, portanto são bem mais complexos, e é muito mais provável que engenheiros medianos — e também muitos engenheiros acima da média — criem problemas com eles
Parece que falhamos em ensinar adequadamente à geração atual o que importa neste trabalho
Estou no meio de uma migração para microsserviços em uma equipe pequena, então me identifico. O maior problema é a observabilidade
Quando algo dá errado em produção, descobrir exatamente o que deu errado vira uma tarefa enorme
Não basta acompanhar os logs de uma única aplicação distribuída; é preciso olhar ao mesmo tempo os logs de várias aplicações distribuídas, com mensagens misturadas entre si
Seria bom se tivéssemos ferramentas para visualizar tracing, mas, por sermos uma equipe pequena, a capacidade humana é limitada e ainda não temos esse tipo de ferramenta
Por outro lado, o monólito já tinha integração com NewRelic havia alguns anos. Havia problemas de desempenho, mas a maioria foi resolvida com índices e algumas views materializadas
É fácil entender o que deu errado e, mesmo com código antigo e cheio de condições de corrida, resolver os problemas em si não é difícil
Tenho medo do momento em que cada microsserviço tiver sua própria instância de banco de dados e precisarmos atualizá-las depois. Eu queria que tivéssemos vários bancos de dados em uma única instância de banco de dados, mas essa arquitetura não está entre as opções
Logging centralizado e tracing de chamadas entre serviços/execução de código não são novidades. Só que muitas vezes são empurrados para depois, e aí se cai nesse tipo de situação desagradável
Como as ferramentas certas não foram colocadas desde o início, a equipe fica menor e mais limitada. Porque sabe pouco ou quase nada sobre o que os serviços estão fazendo
As instâncias de banco de dados podem ser atualizadas uma de cada vez. A menos que haja bugs graves, como de segurança, não há necessidade de pressa só porque é possível atualizar
Ler textos assim dá uma sensação estranhamente terapêutica. Porque eu gritava a mesma coisa dez anos atrás, mas era tratado como herege e mandavam eu ficar quieto
Desculpem se o paradigma de “microsserviços” deixou um gosto amargo na minha boca. Eu vivenciei na prática o que acontece quando se adota por completo uma tecnologia da moda sem entender totalmente seus trade-offs
Muito tempo atrás, quando fui contratado pela StumbleUpon, era a época em que alguém apresentado como um doutor em ciência da computação de ponta tentava transformar um monólito PHP que funcionava bem e dava lucro em uma arquitetura de microsserviços em Scala/Java
O processo de onboarding incluía até um 1:1 estranho com aquele cientista da computação maluco; ele discursava com entusiasmo sobre as vantagens dos microsserviços, e desviava com habilidade de perguntas como “por que criaríamos um serviço distribuído só para somar uma lista de números?”, com gestos do tipo “você não entenderia por que isso é muito melhor”
Depois de mais de 30 novas contratações e mais de 4 anos de desenvolvimento intenso, a empresa, que já não dava lucro, ficou apenas com um inferno distribuído mais lento, cheio de bugs e impossível de depurar
O projetista geral e arquiteto decidiu que aquele era um bom momento para tirar um “sabático” e, pouco tempo depois, mais uma rodada de investimento — nem sei qual — acabou, e todo mundo teve que procurar emprego
Este texto, pegando emprestada a analogia da Amtrak, saiu completamente dos trilhos
O autor parte do pressuposto de que, se alguém criou microsserviços péssimos, teria ficado tudo magicamente bem se tivesse simplesmente feito um monólito
É como dizer que, mesmo que, com o mesmo nível de design e engenharia, se tenha criado microsserviços lixo, se o objetivo fosse um monólito o resultado teria sido dourado
Há bastante autossatisfação ao longo do texto, e o comentário sobre desenvolvedores JS full-stack é um exemplo disso
Mas quase não há conteúdo de uma perspectiva real de engenharia. Você espera métricas ou dados, e o que recebe é só um discurso prolixo
Gerenciar a complexidade para manter baixo o custo de mudança do sistema é um bom objetivo, mas não é isso que este texto propõe
Se tivesse reconhecido esse ponto, ou apresentado dados, ou ao menos uma anedota, o texto teria sido melhor
Na nossa equipe, eu escolheria um desenvolvedor front-end brilhante e entusiasmado, que quer ampliar sua visão e crescer como desenvolvedor full-stack, em vez de alguém que acredita que já sabe tudo e não tem mais para onde crescer
Estou lutando contra essa tendência no meu emprego atual e tivemos algum sucesso em certas equipes, mas muito menos em outras. Essas equipes agora estão brigando com o monólito distribuído que elas mesmas criaram
Ironicamente, todos os ex-FAANMG são do lado pró-monólito
Parece que muita gente não percebe que microsserviços são resultado de um processo iterativo. No fim, trata-se de extrair do monólito as partes que precisam escalar
Microsserviços exigem muita infraestrutura básica que você não quer manter a menos que realmente precise
A maioria das empresas também não tem a plataforma adequada para dar suporte a esse padrão
Concordo. Na nossa empresa, as ferramentas não funcionam direito, então desistimos do próprio debugging
Para executar um serviço na máquina local, é preciso ajustar os outros 9 para se conectarem a ele
Se você chega a criar uma “funcionalidade” para clientes, obviamente precisa mexer em pelo menos 2 serviços ao mesmo tempo e mover mais dados
Se coloca um breakpoint de um lado, o outro lado dá timeout
Então todos os desenvolvedores implantam builds de release em uma VM local e, sem hot reload, espalham console.log, System.PrintLines() e _logger, depois ficam lendo arquivos de log dispersos
Naturalmente, pretendo abandonar o barco
Seria melhor ainda migrar tudo para tracing distribuído, mas, para rastrear requisições direito, é preciso padronizar os metadados de tracing de ponta a ponta, então o investimento é maior
É provável que ajude mais em operações do que no desenvolvimento, mas ainda assim ajudará. Só ter informações decentes de spans já dá muitos insights para entender a bagunça
Se um breakpoint de um lado faz o outro dar timeout, fico me perguntando se não há uma forma de aumentar ou desativar timeouts no modo de desenvolvimento