2 min de leitura ·

A Surpresa de Ver um "Simplão" Funcionar: O Exemplo do Filipe Deschamps e o Tabnews

Eu sempre fui o tipo de pessoa que adora abstrações. Camadas, microserviços, sistemas desacoplados, API externas... quanto mais complexo, mais "profissional" parecia ser. Eu acreditava que a solução perfeita para qualquer projeto era criar uma arquitetura complexa, separando tudo em camadas, APIs e serviços. E é até irônico, porque eu mesmo já escrevi um post dizendo que, às vezes, não precisamos quebrar tudo em microserviços. Mas, quando me dei conta, o vício por abstrações era maior do que eu.

Até que eu olhei o código do Tabnews e levei um baita choque. O cara fez tudo usando Next.js — e não foi só o front, não. Ele construiu a plataforma inteira, backend e frontend, com as API Routes do Next.

E aí vem a pergunta...
Por que complicar tanto, sendo que o Filipe fez tudo de forma simples e funcionou? Quando será que a simplicidade é a melhor escolha e quando devemos realmente optar por soluções mais complexas?

A lição...
Eu ficava preso ao perfeccionismo. Sempre buscava a "melhor" solução, com mil abstrações e modularizações, quando o que o projeto realmente precisava era de algo direto e funcional. Filipe fez isso de forma inteligente, sem se prender a padrões só porque são considerados "bons". E isso me fez repensar o quanto, muitas vezes, complicamos o simples.

Então, a reflexão é...
Será que estamos tão preocupados em abstrair e desacoplar que esquecemos de focar no que realmente importa? Quantos projetos eu poderia ter entregado mais rápido, sem perder tempo com detalhes que não faziam tanta diferença no final?

E calma... Eu não tô falando daqueles projetos gigantescos onde você recebe o escopo e você tem que seguir padrões, garantir escalabilidade e segurança, e toda aquela complexidade que a situação exige.

Estou falando dos projetos pessoais, aqueles onde você tem total controle, onde poderia ter feito de forma simples e eficiente, mas acabou travando no perfeccionismo e nas abstrações.

E você?
O que você tem feito? Está complicando demais suas soluções ou buscando o caminho mais direto e eficiente?

Deixa seu comentário aí!

maniero

20 dias atrás

Posso discordar? Especialmente de uma frase?

às vezes, não precisamos quebrar tudo em microserviços (sic)

Mesmo se eu inverter isso, ainda estarei falando uma mentira:

às vezes, precisamos quebrar tudo em microsserviços

Vamos falar a verdade:

quase nunca precisamos quebrar tudo em microsserviços

Às vezes, precisamos ter alguns microsserviços separados do monólito, mas fazer o sistema inteiro pensado assim, é muito difícil achar motivação técnica, até mesmo as grandes plataformas, inclusive algumas das maiores não usam a técnica e funcionam melhor do que as que adotam. Instagram, Shopfy, Wikipedia, Stack Overflow, etc. Esquece "ser escalável" isso é uma bobagem que até os mais ferrenhos proponentes já não estabelecem como diferencial.

Existem basicamente dois motivos principais que as pessoas adotam essa arquitetura:

a) Lei de Conway, fazer o sistema se encaixar com a estrutura já descentralizada da empresa que funciona como pequenas empresas em vez de algo mais centralizado. Isso tem vantagens e desvantagens, alguns fazem melhor que outros, e na hora de transpor isso para o software pode funcionar bem ou não.
b) a pessoa é deslumbrada e quer estar na moda sem saber 10% do que precisa sobre microsserviços, talvez ela só queira colocar no currículo que fez isso em um trabalho.

Eu sempre peço para as pessoas provarem o contrário quando discordam, ninguém o fez até hoje, elas só garantem que o caso delas é necessário. Só devemos adotar algo, especialmente complexo, quando podemos provar que será melhor. Nunca vi alguém publicando algo mostrando uma prova que o caso delas era necessário.

E eu observo alguns dos softwares mais famosos que adoraram essa arquitetura, quanto mais o tempo passa, mais lentos eles ficam para dar manutenção cometem mais erros, tem mais inconsistências e provavelmente vai ficando mais caro.

Falando do Tabnews, eu não sei se ele é tão simples assim. Eu sou mais radical em simplicidade. E não gosto de soluções lock-in, mas ok, ele não me causa maiores problemas, o maior problema que causava, arrumaram e era extremamente simples, mas ficou anos sem ninguém fazer. Tem outros problemas, mas já acostumei. Eu hoje entendo qual era o objetivo dele melhor que antes, então nem reclamo mais.

"Melhor" é algo altamente subjetivo sem parâmetro algum e nunca serve para balizar nada. Mas se eu criar a minha definição simplista e olhando só uma faceta, melhor é o simples, sempre. Grande parte do que se ensina hoje, geralmente falando que é melhor, que é boa prática, é o complicado.

Eu tenho diversas postagens e vou reunir tudo de forma mais estruturada fundamentando porque está "todo mundo" fazendo software errado, e o maior problema é justamente usar coisas que a pessoa nunca vai precisar ou se precisar não é tão difícil assim mudar. O YAGNI é conhecido da maioria dos programadores que passaram razoavelmente do Hello World, mas quase ninguém o segue. Porque tem o contrário bombardeando a cabeça das pessoas. E esse é outro caso das pessoas não saberem porque estão fazendo aquilo e não conseguem provar a necessidade, mas brigam que tem que fazer assim e ponto.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

phaxe

17 dias atrás

Entendo teu ponto e respeito a visão, mas discordo de algumas partes, especialmente da ideia de que “quase nunca precisamos quebrar tudo em microsserviços”.

Isso é uma generalização que pode ser tão perigosa quanto o hype que critica. Tem cenários sim onde quebrar tudo (ou quase tudo) faz sentido, principalmente quando o sistema cresce junto com os times. Quando você tem várias equipes trabalhando em domínios diferentes, com autonomia de deploy, linguagens diferentes, SLAs separados… tentar forçar tudo dentro de um monólito vira uma dor de cabeça enorme.

Dizer que nunca viu alguém provar que era necessário não quer dizer que esses casos não existam. Cuidado com o argumento por ignorância (argumentum ad ignorantiam). Empresas como Netflix, Amazon, Mercado Livre e várias outras não quebraram seus sistemas à toa. Não foi moda, foi necessidade real de escalar pessoas, processos e domínios de forma separada.

Sobre o argumento dos grandes que usam monólitos (Instagram, Stack Overflow etc), eu entendo, mas cuidado aí. Esses caras têm engenheiros de outro planeta que fazem milagre com monólito. Não dá pra pegar como exemplo universal. E mesmo o Instagram já quebrou partes do sistema sim. A Stack Overflow vive com devs extremamente sêniores cuidando de um código legado com carinho absurdo. Não é o tipo de cenário que a maioria enfrenta.

E cara, falar que escalar é “bobagem” é um pouco demais. Escalar independente é uma vantagem real quando o sistema exige. Talvez não seja teu caso hoje, e tudo bem. Mas não dá pra desconsiderar que, pra certas realidades, é uma baita diferença.

Concordo com você que tem muita gente deslumbrada adotando o padrão só pra parecer moderno, e isso é um problemão. Mas daí a dizer que quase nunca é necessário, acho perigoso. Tem muito time sofrendo com monólito por medo ou preconceito com microsserviços também.

No fim, o problema não é usar ou não usar microsserviços. É usar sem saber por quê. Mas o mesmo vale pra não usar também.

maniero

17 dias atrás

Eu trabalhei no que é provavelmente a maior base de código que existe no Brasil, e não tem problema, mesmo não estando tão organizado quanto deveria. Essa necessidade de organização toda separada é uma fantasia que as pessoas criam, ou precisam porque estão fazendo muita coisa errada, ou é gosto organizacional, conforme eu disse no meu comentário.

Preciso falar do Linux?

Antes de manis nada estamos falando de um sistema que é ou deveria ser um monólito e que vão fazer como microsserviços. Não estamos falando de sistemas que são naturalmente distintos e não precisam um do outro para funcionar, certo? Porque isso existe há décadas e não é microsserviços. Essa arquitetura propõe quebrar algo que deveria ser uma coisa só. Por exemplo o SO tem um serviço de autenticação isolado do resto do site, porque é uma tarefa completamente diferente e que não depende do conteúdo principal dele. Isso não é uma arquitetura de microsserviços.

Sim, eu nunca disse que não existem casos que deveriam, mas todos os casos que eu tive contato, e foram muitos, aconteceu isso, eu não estou provando que todos os casos estão errados, até porque eu estaria falando uma bobagem muito grande, e eu deixei claro que existem casos reais que precisam, nem que seja por motivos não técnicos. Se as pessoas adotassem por necessidade real me parece que apareceria um caso que a pessoa teria provado. As pessoas falam coisas genéricas, mas ninguém fala "fizemos os testes com os dois em condições adequadas em ambos, e este se saiu melhor que aquele e por isso abandonamos aquele e ficamos com este". Ninguém fez uma postagem em um blog ou vídeo mostrando com dados que tiveram argumento de produtividade, qualidade ou outras questões, principalmente no longo prazo. Geralmente tem no meio, no começo paga o preço da curva de aprendizado, e depois começa pagar o preço pela bagunça que vai se tornando. Não existe milagre.

Cuidado com o argumento por ignorância (argumentum ad ignorantiam). Empresas como Netflix, Amazon, Mercado Livre e várias outras não quebraram seus sistemas à toa. Não foi moda, foi necessidade real de escalar pessoas, processos e domínios de forma separada

Prove. Ou pelo menos dê um argumento consistente, você deu uma opinião sem nenhum embasamento. Eu não falei se eles fizeram certo ou não. A Amazon eu sei que não fizeram muito não, porque voltaram atrás em várias coisas. Eu falei que muitos fazem, eu sei de plataformas que estão pagando um preço alto pela escolha que fizeram. Você tem acesso aos custos e todo ambiente da Netflix, do ML ou algum outro? Se você não tem, você está fantasiando.

Fazer microsserviços direito é absurdamente mais difícil do que fazer monólito, por isso essa arquitetura é combatida por alguns dos mais proeminentes engenheiros. Então não sei porque precisa engenheiros de outro planeta. Onde eu trabalhei tinham engenheiros bem ruinzinhos. E usando sua lógica o SO, IG, WP têm engenheiros de outro planeta, e a Netflix, Amazon e ML têm engenheiros de merda. Talvez eu concorde, se tiver mais evidências, mas o fato de escolherem microsserviços, e se foi sem necessidade, realmente prova seu ponto, eles são uma merda.

Esse é o argumento que mais ouço, e é o mais sem sentido possível. Pergunte para quem quiser que seja referência em microsserviços se eles recomendam fácil. Todos vão te dizer que só faça quando for a única solução viável, é complexidade demais, é ineficiência/custo demais, precisa de uma justificativa muito forte.

Você está me dizendo que microsserviços é coisa para júniores? Eu conheço todo mundo (que importa) que trabalha ou trabalhava lá. A Team Principal é brasileira, você sabia? Ela boa, mas não é uma sumidade, ela faz o básico bem-feito, como todo bom engenheiro deve fazer. Não tem milagres, não tem algo que só poucas pessoas sabem fazer, não tem nada demais, é super simples, na verdade, é justamente ser simples que faz ser bom.

Mas novamente, se o seu ponto é que microsserviços deve ser adotado por pessoas que não sabem bem o que estão fazendo, eu concordo. Por isso eu disse que as que sabem, não adotam.

Continue ignorando os casos que eu citei então. Ou continue achando que nesses lugares habitam extraterrestres que escalaram em monólito. Ou ache que esses casos são fraquinhos, que talvez o seu é que precisa de escala maior que os deles. Lembrando, o SO consegue rodar em um servidor sem problemas, sem atrasos na maioria das requisições, eles já testaram isso, só mantém vários por redundância a mitigar ataques. Você pode continuar com sua opinião, claro, mas estou te dando a oportunidade de rever alguns conceitos que tem olhar para casos que refutam totalmente o que você está afirmando.

Tem muita gente boa dizendo exatamente "quem está sofrendo com monólito, nem passe perto de microsserviços, faça o monólito funcionar bem, aí se não tiver jeito mesmo é que deve ir para algo mais complexo".

Você poderia refutar pelo menos parte do que eu disse com dados detalhados de uma implementação que se provou claramente melhor. Não estou falando de percepção, de algo observado no começo.