Você já deve ter presenciado uma situação onde alguém está defendendo a implementação de alguma ferramenta ou framework e uma o seguinte argumento: A Google utiliza isto! É claro, a pessoa pode não citar a Google, pode ser alguma outra grande empresa de tecnologia como Microsoft, Amazon, Apple ou alguma outra bigtech. Antes de começar a desconstruir este argumento, preciso comentar que é engraçado que raramente outras bigtechs menos populares sejam utilizadas como exemplo, apesar de já terem sido responsáveis por grandes inovações tecnológicas, como a Yahoo! que criou o Hadoop.

O ponto central, e mais óbvio, é que negócios de diferentes tamanhos e escalas precisam de diferentes soluções, seja em relação às tecnologias ou aos processos adotados. Uma solução que funciona para uma empresa do tamanho da Google talvez não funcione para uma startup. Na verdade, não é apenas um talvez. Uma solução aplicada em uma empresa do tamanho da Google provavelmente não irá funcionar se aplicada em uma startup se não forem feitas adaptações. Um exemplo comum são os bancos de dados analíticos como o BigQuery. Em alguns casos as empresas querem já começar utilizando este banco de dados, porém a sua massa de dados ainda é muito pequena e ela não quer ter o custo de ter vários bancos de dados. Então acaba por colocar todos os dados da empresa no BigQuery e começa a sofrer com diversos gargalos e um custo alto, porque o BigQuery não é um banco de dados apropriado para funções básicas diárias.

Muitas das soluções surgem quando as empresas crescem muito e a tecnologia atual não suporta mais realizar aquela atividade com eficiência (falamos um pouco sobre isto no artigo sobre NoSQL). Este é o caso do Data Mesh, que consiste em uma forma de organizar a área de dados quando esta se torna muito grande. Em seu livro, a criadora do conceito de Data Mesh diz explicitamente que o Data Mesh só deve começar a ser considerado a partir do momento em que a área de dados não está mais conseguindo se organizar pelo tamanho que acabou atingindo. Porém, é comum ver várias empresas pequenas dizendo que implementaram Data Mesh em seus processos. Obviamente isto nada mais é do que um grande surf no hype… e na maionese também.

Além do aspecto da dimensão da empresa, também há o aspecto do tipo de negócio. Desta vez vou utilizar uma metodologia como exemplo: o scrum. Esta metodologia foi criada pensando em um ambiente de fábrica de software. Porém, como eu trabalho na área de dados e já trabalhei em projetos de pesquisa, vi algumas situações onde o scrum acabava por gerar confusão quando tentavam aplicar ele as it is. Uma grande diferença entre um projeto de fábrica de software e um projeto de pesquisa é que o primeiro possui definições claras, enquanto o segundo possui muitas atividades exploratórias que se tornam difíceis de especificar. Quando eu atuei em um projeto de pesquisa que utilizava scrum era comum ter uma situação onde eu criava uma atividade chamada “investigação” e o scrum master sempre me perguntava coisas como “como podemos quebrar esta atividade em várias?”, ao que eu sempre respondia “como vou quebrar esta atividade se eu nem sei o que vou precisar fazer!?”. Já tive também a experiência de trabalhar em outro projeto de inovação, mas utilizando apenas kanban e as atividades fluíram muito melhor.

Existem diversas ferramentas que são adaptadas para sistemas mais simples ou empresas menores. O n8n é uma versão simplificada do airflow que funciona muito bem em projetos pequenos. O scrum também pode ser adaptado e aplicado com apenas parte das cerimônias. O postgres é um ótimo banco de dados para ser utilizado antes de se implementar um Oracle ou um SQL Server. E um sistema em bash pode ser adotado antes de se precisar implementar um Kafka. A propósito, já vi situações onde o Kafka foi implementado para alimentar um sistema que não era real time. Um total desperdício de recursos!

Muitas destas ferramentas que se tornam hype são fortemente influenciadas pelo marketing das bigtech. É claro, eles querem te convencer a usar o produto deles e para isso eles promovem diversos eventos de tecnologia com grandes profissionais dizendo como resolveram algum problema de forma quase milagrosa após implementar uma ferramenta específica. É claro que eu não estou dizendo que estes palestrantes estão mentindo, mas aquela ferramenta solucionou o problema que estava inserido em um contexto específico. Eu já atuei em um projeto onde foi proposto implementar um cluster Spark para aumentar a velocidade do processamento de alguns dados, porém a maior parte do tempo era gasto fazendo o download dos datasets. O mesmo paralelismo realizado pelo Spark poderia ser feito pelo Python e no final a maior dependência ia ser com a velocidade da internet. No fim, o Spark seria uma solução cara e complexa para um problema que poderia ter sido resolvido facilmente com um código mais otimizado (e foi!).

Da próxima vez que você ouvir alguém argumentar que uma determinada ferramenta ou framework precisa ser implementada porque uma bigtech também está utilizando, pergunte: e como o problema da bigtech se assemelha ao nosso? Possui a mesma escala? É o mesmo negócio? É preciso ter senso crítico, deixar de lado o hype e não ceder ao FOMO (Fear of Missing Out).