Microservices e Agile: o futuro da programação?

Este artigo é uma reprodução do artigo homônimo publicado na edição impressa da revista iMasters do mês de agosto de 2017.

Nenhum destes termos é exatamente novo, mas por algum motivo, jamais estiveram tão na moda como atualmente. Mas o que teriam, a arquitetura microservices e os métodos ágeis de desenvolvimento de software em comum? Ou melhor: por que seriam eles o futuro da programação? Não tenho a pretensão de ser eu a dizer como as empresas de tecnologia deveriam trabalhar, mas vou tentar trazer uma luz para esse assunto e provocar uma reflexão (espero) na forma como você trabalha.

Os métodos ágeis existem desde a virada do século, mas, mais recentemente, nos últimos cinco anos, uma nova onda de “agilistas” passou a defender um modelo que seria uma evolução dos métodos ágeis originais. Essa evolução foi proposta pelo Spotify em um famoso vídeo onde é apresentado o modelo de “squads” (esquadrões) do Spotify, que, em teoria, não possui grandes diferenças em relação ao Scrum Team original mas que propõe um mindset focado em um único produto à cada um dos times/squads ao invés do foco tradicional em projetos.

O termo viralizou entre as startups e hoje empresas como Nubank, Umbler, Agibank e Conta Azul, por exemplo, organizam-se em squads também. Organizar um squad ao redor de cada produto faz com que as pessoas “abracem” o mesmo como se fosse “seu” e que queiram o melhor para ele em termos de tecnologia, experiência, resultados, etc. Permite que os times tenham mais controle (e mais resultados) com seus OKRs, KPIs, etc. Como bem o Scrum prega, cada time decide como seu produto deve ser melhor desenvolvido com base na estratégia da empresa e isso inclui TODOS os aspectos técnicos, como linguagem utilizada, banco de dados, etc.

Tudo isso é muito lindo e é exatamente o que as empresas querem: esquadrões focados no produto que entreguem software rapidamente (já ouviu falar de CI?) com as melhores tecnologias para resolver cada problema. Mas sabemos que na prática não é tão simples assim, certo? Mas deveria, e já, já, eu explico o porquê.

Estamos há décadas desenvolvendo software em grandes e complexos blocos de software que a própria TI chama de monolíticos, em alusão às grandes pedras (monólitos). Não importa se você organiza sua aplicação em ‘x’ camadas. Se você não pode fazer o deploy de apenas uma delas sem precisar compilar o projeto inteiro, o seu software é monolítico. Se você não pode escrever uma de suas camadas em uma linguagem diferente das demais, também. E isso não é ruim, aprendemos a construir softwares assim desde a faculdade e construímos grandes softwares ao longo das décadas que a profissão de programador existe. É apenas uma característica, sem julgamentos.

No entanto, cada vez mais o mercado nos pede softwares maiores e mais complexos, e nossos monólitos ficam ainda maiores e mais complexos. Mas ao invés de ficarem igualmente resistentes como a analogia, estão mais para um castelo de cartas altíssimo, infelizmente. Isso porque as demandas atuais estão exigindo pluralidade de tecnologias. E as aplicações monolíticas não trabalham muito bem com pluralidade, não foram concebidas desta forma. Fato.

Mas então, como podemos alinhar diferentes tecnologias, diferentes produtos, mantendo uma alta velocidade de integração, qualidade e atendendo às expectativas, internas e externas, em relação aos projetos em que trabalhamos?

Com uma outra tendência que voltou muito forte após décadas: microservices.

Microservices não é algo exatamente novo, embora tenha-se voltado a falar dessa arquitetura há poucos anos. A ideia central é que você quebre sua aplicação em serviços bem pequenos, semelhante ao que SOA e CORBA propõem, mas sem as complicações que as grandes corporações criaram no em torno destas duas excelentes ideias (ESB?). Cada um desses microservices é auto suficiente na sua responsabilidade, é independente de linguagem, de persistência e comunica-se com os demais serviços através de protocolos comuns, como HTTP.

Não é à toa que tecnologias como Node.js, Elixir, Scala e Go (sem citar as funcionais em geral) estejam tão em alta ao mesmo tempo em que só se fala de arquitetura microservices e squads (não esqueçamos a persistência poliglota!). Ao que tudo indica, essa combinação de tecnologias leves e focadas em paralelismo, em micro serviços, mantidos por squads, para compor grandes soluções; são a “bola da vez” e podem ser a “salvação” para conseguirmos construir (e manter) os sistemas do futuro. Grandes empresas como Amazon, ThoughtWorks, Uber e Netflix acreditam nisso.

Por que eu não acreditaria? 🙂

Quer ler sobre microservices na prática? Dê uma olhada nesta série de artigos!