Por volta de 2010, arquiteturas baseadas em microsserviços começaram a ganhar grande relevância no mercado de desenvolvimento de software. No entanto, no começo de 2020, 10 anos depois, foi possível começar a observar um movimento de retrocesso nessa abordagem, ao mesmo tempo que se observa um aumento no interesse em monolitos modulares e bem projetados.
Nós, do InfoQ, acreditamos que há um consenso na indústria de desenvolvimento de software de que não há uma melhor arquitetura, aquela que resolva todos os problemas. Exatamente por isso que nós acreditamos que é vital o processo de constante discussão e análise dos diversos modelos de arquitetura existente.
Nessa primeira edição do QTrends, trazemos para você uma série de conteúdos (infelizmente, quase todos em inglês) para que você possa ter mais informações em torno da discussão que ganhou força desde o início desse ano sobre microservices e monolitos.
O fim da era dos microservices?
Microsserviços, disponibilidade e gestão de riscos com Marty Abbott e Tanya Cordrey
Em um podcast gravado para o InfoQ, Marty Abbott e Tanya Cordey da AKF Partners, empresa responsável pela criação do AKF Scale Cube, discutiram uma série de tópicos relacionados à escolha de uma arquitetura e o impacto correspondente em toda a organização.
Um dos pontos principais da conversa foi que uma arquitetura baseada em microsserviços é bem utilizada quando implementada de acordo com a "granularidade" de uma funcionalidade de negócio. Profissionais de desenvolvimento deveriam evitar a construção de longas cadeias de chamadas de serviços, já que isso pode aumentar a probabilidade de falhas e pode, também, aumentar a complexidade para encontrar e diagnosticar eventuais problemas.
Domando o crescimento dos microsserviços
No QCon São Francisco de 2019, Tobias Kunze apresentou a palestra "Controlled Chaos: Taming Organic, Federated Growth of Microservices" debatendo os desafios que surgem como consequência de um "crescimento orgânico" de uma aplicação. Em sua apresentação, Tobias discutiu padrões que podem ser utilizados para monitorar e controlar diversos aspectos críticos de uma solução, tanto em uma perspectiva operacional quanto em uma perspectiva de segurança.
Um dos pontos principais trazido por Tobias é que profissionais de desenvolvimento devem evitar a implementação de sistemas distribuídos altamente acoplados. Ao invés disso, profissionais devem implementar "módulos" resilientes seguindo um padrão de serviços modulares projetados com DDD (Domain-Driven Design).
Se algo não funcionar corretamente, faça com que esse serviço se deteriore ao invés de falhar.
Microsserviços ainda valem a pena?
No QCon Londres de 2020 aconteceu um painel mediado por Nicky Wrightson (Principal Engineer na Skyscanner), onde foram apresentadas experiências ao migrar de um monolito para microsserviços e também houveram relatos de pessoas que precisaram voltar atrás dessa decisão em alguns casos.
O debate contou com fortes opiniões sobre monolitos, os desafios de sistemas distribuídos e também boas maneiras de se estruturar uma empresa para se implementar uma arquitetura de microsserviços com sucesso. A gravação do vídeo, disponibilizada no InfoQ, conta com uma transcrição completa do painel realizado.
O próximo passo das discussões sobre microservices
Em um recente artigo publicado no "The New Stack", Eran Levy resumiu algumas das mais recentes discussões da comunidade sobre a questão microsserviços x monolitos. Eran se concentrou em 4 tópicos principais:
- As organizações estão realmente preparadas para investir nas mudanças e aprendizados necessários?
- A estrutura dos serviços a serem construídos: a necessidade de se projetar sistemas baseados nos princípios da arquitetura de sistemas.
- A necessidade de retrospectivas para identificar as dores da implementação.
- A importância do suporte às decisões de arquitetura e desenvolvimento a longo prazo.
Em sua conclusão, Eran afirma que antes do mercado adotar uma solução para o desenvolvimento de sistemas em um âmbito mais amplo, é extremamente importante que as discussões sobre essas soluções também mostrem o que não funcionou, ao invés do foco ser exclusivamente nos benefícios.
Estudos de caso
A ida para os microsserviços e a fuga deles - Porque a Segment voltou ao monolito
Enquanto boa parte dos times de desenvolvimento, em algum momento de sua existência, consideraram implementar uma arquitetura de microsserviços, as vantagens descritas pela adoção de uma arquitetura desse tipo traz junto de si uma série de trade-offs. Em uma palestra no QCon Londres 2020, Alexandra Noona apresentou como a Segment quebrou seu monolito em uma série de microsserviços para, anos depois, voltar para uma solução monolítica.
Se os microsserviços são implementados de uma forma incorreta ou utilizado como um curativo sem o devido cuidado com as reais causas de falhas em seu sistema, você não será capaz de desenvolver novos produtos pois estará se afogando na complexidade criada.
A arquitetura de microsserviços foi utilizada pela primeira vez na Segment para tratar algumas falhas isoladas do monolito existente. Por outro lado, a medida que a empresa foi crescendo e integrando com mais sistemas externos, o custo operacional para a manutenção desses microsserviços se tornou inviável. A decisão de voltar ao monolito veio juntamente com uma nova proposta de arquitetura levando em conta os pontos relacionados à escala para acompanhar o crescimento da empresa. Apesar de algumas perdas em termos de modularidade, isolamento de ambientes e até mesmo visibilidade, a solução implementada em um monolito resolveu diversas questões em torno do custo operacional de manutenção, permitindo ao time retornar ao desenvolvimento de novas funcionalidades.
Alexandra mostrou uma série de pontos cruciais na evolução da arquitetura da Segment. Os problemas encontrados, bem como as decisões tomadas em um determinado momento certamente soarão familiar para qualquer profissional do desenvolvimento de software. E interessante observar que esses aprendizados só foram possíveis graças a uma retrospectiva do trabalho realizado, onde foi possível identificar cada uma das decisões que poderiam ter tido uma solução melhor. Alexandra mostrou as grandes decisões em uma linha do tempo, pontuando os prós e os contras de cada modificação realizada na arquitetura.
A discussão com as pessoas presentes na palestra soou como quando profissionais começam a trabalhar com um projeto com longa história. Em contraponto a frases como "É óbvio que vocês não deveriam ter feito isso como fizeram." foram contrapostas ao fato de que todas as decisões foram tomadas com as informações disponíveis no momento da decisão. Uma das conclusões da discussão foi a de que o investimento em alguns dias ou poucas semanas fazendo uma análise um pouco mais profundo podem ajudar a evitar algumas situações que podem levar anos para serem corrigidas.
E no Brasil?
No Brasil a discussão vem tomando corpo e ganhando mais espaço. Não é difícil encontrar no twitter (link, link, link, link, link) profissionais discutindo diversas questões em torno da adoção de arquiteturas de microsserviços, com um grande foco em como o mercado, mais uma vez, pecou em assumir uma solução única como a famosa "bala de prata" para resolver todos os problemas.
De toda forma, a onda dos microsserviços ainda parece ter uma vida longa por aqui, uma vez que ainda existem empresas no processo de migração para esse tipo de arquitetura. E se você quiser se inspirar em boas práticas no desenvolvimento de microservices, o Nubank acabou se estabelecendo com uma empresa que vem lidando com o assunto há bastante tempo, como você pode conferir nas palestras "Arquitetura funcional em Microservices: 4 anos depois" e "Sobrevivendo à escala: padrões para evoluir microsserviços resilientes a falhas". Tem também uma série de podcasts bem interessante organizada pelo pessoal da Lambda3 onde foram discutidas diversas questões relacionados ao tema.