Essa frase não é minha, já a vi em diversas publicações, inclusive ela é citada no nosso episódio do DevShow sobre Arquitetura (para conferir, clique aqui).
O fato é que ela faz muito sentido pra mim, principalmente na atualidade, onde vejo um movimento imenso em prol de “construir uma bazuca para matar uma mosca”, sendo que muitas vezes sequer sabem se o que realmente querem matar é uma mosca.
Isso se aplica muito as decisões arquiteturais que tenho tido contato. Não pretendo me estender muito aqui, a intenção é passar o recado, alertar quem está confuso em meio a tantas opiniões e deixar a reflexão por conta de cada um.
Nos cases de sucesso de grandes empresas que vemos por aí, é fácil (e eu até entendo) maravilhar-se e inspirar-se com toda a arquitetura montada para suportar um negócio. Mas é preciso apenas um momento de sanidade para entender que a parte crucial desses cases é o negócio em si e não a tecnologia. É necessário entender que a tecnologia é o meio e não o fim.
Pense grande
Você pode e deve pensar grande! Voe, mas fique ancorado ao chão.
Por que eu digo isso? Você deve analisar, buscar e aprender com os cases de grande sucesso, mas é preciso considerar que, na esmagadora maioria das vezes, os cenários serão muito menores, mais simples ou apenas diferentes.
Não “viaje” tanto em cases de outras empresas ao ponto de se desconectar do que o seu negócio realmente precisa. Implementar e utilizar tecnologias sem necessidade, não é lindo e nem mostra o quanto você é qualificado, só mostram egos inflados e o descaso em atender o negócio de forma racional. E tenha certeza, mais cedo ou mais tarde, a conta virá!
Para atender um cenário, você precisa se envolver e entendê-lo, estar em sintonia e falar a mesma linguagem do negócio. Muitas vezes isso é um exercício não tão comum para quem atua exclusivamente na área técnica, mas deveria ser.
Não há nenhum problema em ser entusiasta, querer aprender e testar diversas tecnologias, mas em produção essas não deveriam ser suas motivações na adoção das tecnologias para o seu projeto.
Comece pequeno
Esse tópico se encaixa em várias situações, as quais devem ser analisadas de formas diferentes. Abordarei apenas um dos cenários, onde um novo projeto está nascendo, o que é bem comum e vemos com frequência em startups (mas não se limitam a elas).
Os primeiros dias de um projeto/ideia é o momento onde você menos conhece sobre o negócio. Acredite, quando eu falo negócio, não estou falando do ramo de atividade, estou falando especificamente do produto que se quer construir.
“Ter pessoas qualificadas no time que já trabalharam com o mesmo ramo de atividade auxilia no processo?“
Com toda a certeza, mas não é determinante. Como mencionei acima, existem diferenças entre conhecer o ramo da atividade e o negócio, já que cada negócio tem seu próprio Core Domain, com suas próprias estratégias, diferenciais competitivos, formas de operacionalização (muitas vezes divergentes do convencional), entre muitas outras particularidades.
Uma empresa geralmente não quer ser case por implementar determinadas tecnologias (a menos que ela seja desse nicho). Ela quer ser referência no negócio que ela se propõe a entregar, as tecnologias utilizadas são uma ferramenta para que ela possa atingir esse objetivo.
Quando o cenário permitir, as abordagens mais simples são muito eficazes para se começar, não só no aspecto de ter uma entrega mais rápida, mas sim em validar o negócio o mais rápido possível. Note, quando menciono “abordagens mais simples”, isso não significa que são porcas feitas de qualquer forma.
Falar que implementa alguma tecnologia, deixando de lado as preocupações básicas que ela implica, é no mínimo irresponsável, além de estar fazendo qualquer coisa, menos aquilo que disse ou se propôs a fazer.
Pode não parecer, pois o que é tratado nesse artigo se encaixa para a tomada de decisões no geral, porém ele foi motivado por uma discussão sobre a adoção de Microsserviços, onde li alguns absurdos do tipo:
“Microsserviços são recomendados para 90% dos projetos”
“MicroserviceFirst” (Tá maluco? Isso é sério?)
Essas bizarrices aparecem quando vejo pessoas falando que fazem (ou acham que fazem) microsserviços, indicando indiscriminadamente, mas não conhecem e/ou não se preocupam com coisas básicas (isso ficou muito claro nessa discussão), como estratégia de DevOps, monitoramento, tolerância a falhas, rastreabilidade, entre diversas outras.
Na melhor das hipóteses (e estou sendo bem otimista aqui) quem indica algo como “MicroserviceFirst” trabalha em um cenário muito avançado em uma empresa grande e infelizmente acaba ficando preso em uma bolha, sem conseguir enxergar a realidade da maioria dos cenários na atualidade (que passa longe de uma abordagem “MicroserviceFirst”).
“Preciso ter um time qualificado para trabalhar com Microsserviços?“
Óbvio! Isso já deveria estar bem claro, mas para muitos parece que não. Uma empresa com 20 desenvolvedores não maduros o suficiente para trabalhar com isso, simplesmente não farão algo bom, e mais, farão qualquer coisa, menos microsserviços.
“Ah mas se algo não é feito da maneira correta, não é culpa dos microsserviços“
Obviamente não é culpa dos Microsserviços (inclusive não tenho nada contra eles), a culpa é de quem tomou a decisão de implementar sem ter diversos cuidados e sem avaliar os pré-requisitos para executar tal projeto (inclusive a qualificação do time). Uma escolha arquitetural equivocada pode matar o seu projeto e trazer um belo prejuízo financeiro, afinal, ambiente de produção não é o seu playground.
Evolua Rapidamente
Seguindo o mesmo princípio do tópico anterior, o cenário abordado aqui é onde temos o início de um novo projeto.
Quando você começa pequeno, você entrega o suficiente para aquele momento e de forma mais rápida. Você monitora, analisa, valida e identifica no que precisa evoluir.
E se o meu negócio ou estratégia fracassar? Ok, isso pode acontecer. Se for o caso, o quanto antes você falhar melhor, já que isso comprometerá menos tempo e recursos. Agora, já imaginou o tamanho do prejuízo se você tivesse criado um megaprojeto com uma megaestrutura sem antes “sentir” as necessidades do cliente?
Fazendo uma simples analogia, dado que temos um cenário onde um novo estabelecimento físico é criado (do zero) com a proposta de entregar algo diferenciado/inovador para atender um determinado perfil de cliente.
Ao iniciar as operações, você não aluga uma sala gigantesca, a divide em diversos setores com milhares de produtos e aloca recursos baseando-se na desculpa de “quando eu tiver uma grande demanda, já terei a estrutura e os recursos necessários”. Geralmente a lógica correta é exatamente oposta: Você evolui de forma consciente conforme sua demanda! Por qual motivo? Após iniciar com uma estrutura mais simples e entrar em operação, você é capaz de monitorar e analisar o comportamento dos clientes, coletar feedbacks, entender quais são os interesses, os setores/departamentos mais visitados e a partir disso expandir para uma estrutura maior, mais inteligente e já validada. Percebe a relação entre as coisas?
Como já mencionei anteriormente, a evolução do seu produto vem da observação, monitoramento e análise. Quanto mais rápido você executar esses passos, mais rápido será a sua evolução.
A propósito, velocidade não é sinônimo de má qualidade.
Conclusão
Já reparou que ao longo de quase todo o texto, o termo “negócio” aparece? É algo óbvio, mas as vezes me vejo na obrigação de lembrar que sem ele, você não teria o porquê de implementar nada, portanto ele deve ser o principal fator a ser considerado no momento da definição da sua arquitetura.
A reflexão que esse artigo propõe é destinada a projetos que estão nascendo, quando você está cheio de incertezas sobre o que precisa (ou melhor, sobre o que seus clientes precisam). Se o seu caso for a construção de uma segunda versão do seu produto, não vejo problemas em considerar abordagens mais complexas, uma vez que você já terá métricas e experiência suficiente para fazer uma escolha racional baseando-se no seu cenário já validado.
Uma das frases que eu mais escuto quando ouço alguém advogar cegamente sobre microsserviços:
“Ah mas a Netflix possui uma arquitetura de microsserviços e tudo funciona muito bem”.
E a minha resposta para isso vem em três frases:
1) Sim, eles implementam microsserviços porque são a Netflix!
2) Eles não são a Netflix porque implementam microsserviços!
3) Você não é a Netflix!
Por fim, é importante não terceirizar suas decisões! Não se baseie em cases de sucesso de grandes empresas onde o cenário muitas vezes não tem nenhuma relação com o seu (tanto em nicho de mercado, demanda, orçamento, maturidade e cultura do time, entre diversas outras).
Ainda sobre não terceirizar suas decisões, o Fabio Akita postou um vídeo enquanto eu ainda escrevia esse artigo e creio que o conteúdo dele passe uma mensagem muito importante e que está diretamente ligada com o conteúdo desse artigo. Fica aqui a recomendação para você assistir.
Caso ainda não tenha visto o meu último artigo, ele também propõe uma discussão relacionada a Monolitos e Microsserviços. Confira abaixo.
Caso pense diferente ou não concorde, tudo bem, esse é um direito seu. Só espero que esse artigo te leve a refletir um pouco mais sobre suas decisões e quais são as suas motivações ao tomá-las. Sinta-se a vontade para compartilhar com seus amigos e deixar sua opinião nos comentários.
