Trabalhar com microsserviços pode ajudar a acelerar a entrega no desenvolvimento de aplicações, ao permitir (e possibilitar) que as equipes trabalhem de forma bastante independente. Por outro lado, a sobrecarga operacional que acompanha os microsserviços pode ser muito grande. O que significa que o uso das ferramentas adequadas é um aspecto crucial quando se trata de microsserviços. Nicky Wrightson, engenheira principal do Skyscanner, apresentou um painel na QCon Londres 2020 com convidados que contaram como fizeram a mudança de uma aplicação monolítica para microsserviços e, em um dos casos, a mudança acabou até mesmo retornando para a aplicação monolítica.
Entre eles, Luke Blaney (engenheiro principal do Financial Times), Matt Heath (engenheiro backend da Monzo), Alexandra Noonan (engenheira de software da Segment) e Manuel Pais (consultor organizacional e instrutor de TI). Com opiniões distintas e complementares sobre sistemas operacionais distribuídos e sobre a melhor maneira de estruturar uma organização para ter sucesso com um tipo de arquitetura baseada em microsserviços, esse profissionais contam como tem sido suas experiências trabalhando com microsserviços.
Neste post, apresentamos algumas das principais reflexões compartilhadas entre eles.
Benefícios para as organizações
Para Blaney, o verdadeiro benefício para o Financial Times e para os clientes é em termos de agilizar a entrega e isolar as coisas. Monzo é um banco online baseado na Inglaterra. Usar microsserviços significa que diferentes tipos de sistemas podem ser trabalhados de maneira independente, tal qual as equipes de desenvolvimento. E isso, conta Matt Heath, ajuda a lidar com a complexidade de um banco.
Noonan, no entanto, acabou fazendo o caminho inverso para uma abordagem mais monolítica, por duas razões principais: 1) a sobrecarga operacional que acompanha os microsserviços é muito grande, e faz-se necessario um bom conjunto de ferramentas para testar, implementar e manter esses microsserviços; e 2) quando finalmente foi entendida a raiz do problema que se tentava resolver com microsserviços, mas isso não foi realmente algo resolvido. “Assim que finalmente entendemos o problema central, fomos capazes de resolvê-lo, e voltar para a aplicação monolítica foi o que nos ajudou a resolvê-lo com mais facilidade”, comenta Noonan.
Benefícios para a organização das equipes
Para Manuel Pais, é preciso pensar o momento certo de usar microsserviços para resolver problemas de arquitetura de aplicações. Frequentemente, é prematuro tentar otimizar algo com microservices, mas como se fala muito sobre microservices, as pessoas tendem a pensar em uma “solução mágica”. As organizações geralmente não percebem que, para realmente se beneficiar dos microsserviços, elas precisam fazer muito mais mudanças. Não apenas uma mudança na arquitetura técnica da aplicação: é necessário voltar um passo trás, pensar sobre a lei de Conway e como as estruturas das equipes de trabalho estão mapeadas conforme os serviços oferecidos. Elas devem estar alinhadas em grande parte – não uma a uma, mas devem estar alinhadas.
Além disso, a carga cognitiva também deve ser considerada: em Team Topologies, revelamos que em quase todas as organizações algumas equipes se sentem sobrecarregadas. Mas se pedirmos a elas que sejam “donas” de seus serviços e sejam capazes de construir, testar, operar, oferecer suporte e entendê-los o suficiente para isso, elas provavelmente terão muito trabalho a fazer. Logo, precisamos pensar primeiro no tamanho certo do software para as equipes, e a próxima questão é se os microsserviços ajudarão nisso ou não.
Conselhos sobre a adoção ou amadurecimento da arquitetura de microsserviços
Para Blaney, é preciso manter o controle, uma vez que ele pode facilmente fugir de você. “Comecei com alguns serviços e achei que seria fácil, mas tem que vincular dados, monitorar todas essas coisas, controlar tudo. Então minha dica é: faça isso desde o início. Não espere até ter 100 microsserviços e se perguntar qual foi o primeiro que você criou. Comece do início. Certifique-se de documentar essas coisas à medida que avança porque, uma vez que você tenha muitas delas, é muito fácil perder uma no meio do caminho”, conta ele, que é engenheiro principal no Financial Times.
Pais já tem um ponto de vista um pouco diferente. Para ele, o ideal é iniciar avaliando a carga cognitiva da equipe. “Esse é um problema comum. Essencialmente, pergunte às equipes – porque há um aspecto psicológico aqui também. Se um membro da equipe não compreende sua parte no sistema bem o suficiente, sejam microsserviços ou qualquer outra coisa, ele vai ficar ansioso. É preciso realmente intervir quando a pessoa de plantão não espera que que nada aconteça em alguma parte do software porque, caso contrário, vão haver problemas”.
A segunda coisa é seguir a Lei de Conway. “Imprima-o e coloque-o em seu escritório para que todos se lembrem de que não podemos projetar software isoladamente, sem pensar nas estruturas das equipes”, brinca Manuel Pais.
“A terceira coisa é que os microsserviços são realmente benéficos se estiverem alinhados com o fluxo de valor do negócio. Isso acontece o tempo todo; acesse o Twitter e você verá pessoas reclamando que têm microsserviços, mas para qualquer tipo de recurso ou mudança de negócios, elas precisam de coordenação entre 3, 4 ou 5 equipes de microsserviços diferentes. E não era bem isso que desejaríamos alcançar com um deploy independente. Além disso, fluxos de negócios independentes são nosso objetivo. Não é apenas o lado técnico em si que conta”
Alexandra Noonan, engenheira de software da Segment, é preciso em primeiro lugar se certificar de que os microsserviços irão efetivamente resolver o problema antes de sair adotando o modelo. “Por exemplo, na minha organização, pensamos que iríamos conseguir esse grande isolamento do ambiente, mas isso não resolveu o problema. Então, antes de mais nada, é preciso se certificar de que os microsserviços serão capazes de resolver a raiz dos problemas”, conta ela.
“A partir daí, certifique-se de compreender totalmente as compensações que virão com isso. Acho que o que realmente nos incomodou foi a sobrecarga operacional quando mudamos para os microsserviços. Tínhamos apenas 10 engenheiros na época, e você quase precisa de uma equipe DevOps dedicada para ajudar a construir ferramentas para manter essa infraestrutura. E nós não tínhamos isso. Foi o que acabou nos derrubando e por isso voltamos à estrutura monolítica. Simplesmente não tínhamos os recursos para desenvolver todas essas ferramentas e automação que vêm integradas aos microsserviços”
Certifique-se de estar extremamente familiarizado com as compensações, de ter uma boa história sobre cada uma delas e de se sentir confortável com essas compensações ao fazer a troca pelos microsserviços.
Já Matt Heath, do banco online Monzo, recomenda “manter as coisas simples”. Para ele, quanto mais simples e consistentes forem os serviços, mais consistentes serão as ferramentas de monitoramento e seus processos de desenvolvimento. Manter as coisas simples empurra grande parte da complexidade para fora, e essencialmente para a plataforma. “Você precisa de muitas ferramentas e investimento em equipes para trabalhar nessas ferramentas. A maior parte desse ferramental existe muito melhor do que há cinco anos e continuará a melhorar”.
—