Nesta segunda edição da QTrends, continuamos com o foco na Arquitetura de aplicações e seguimos na discussão em torno da ascensão e queda dos microsserviços. Como dissemos na edição anterior, arquiteturas baseadas em microservices começaram a ter um grande destaque no mercado de desenvolvimento de software por volta de 2010. No entanto, no início desse ano, cerca de 10 anos após o boom, começamos a observar um movimento contrário: a fuga dos microsserviços e um crescimento na busca de arquiteturas baseada em monólitos modulares.
Repetindo um de nossos mantras: nós do InfoQ não acreditamos que exista A melhor arquitetura. Nem por isso deixamos de discutir e analisar os mais diversos estilos de arquitetura de aplicações. Para nós, discussões e análises como essa são vitais para o mercado. Se você conferir nossa última análise sobre as tendências em arquiteturas e design de aplicações, verá que microsserviços, sistemas distribuídos apropriadamente e monólitos modulares estão bem representados nessa análise.
Confira os conteúdos que separamos para você, quase todos em inglês, para aprofundar a discussão iniciada na edição anterior em torno do debate microsserviços e monólitos.
Monólitos modulares
As razões por trás das idas e vindas aos microsserviços: podcasts com Sam Newman
Sam Newman vem se consolidando como uma das grandes vozes em torno do assunto microsserviços. Seu livro "Building Microservices", publicado em 2014, virou uma referência no assunto e é possível encontrar diversas palestras dele sobre o assunto, como o keynote "Microservices, an unexpected journey: where they came from, where they're going" no QCon São Paulo 2015. Destacamos aqui 3 podcasts gravados com sua presença, onde são debatidos diversas questões em torno do assunto microservices.
Em um dos mais recentes podcasts do InfoQ, Sam Newman abordou diversos aspectos em torno de uma migração para microsserviços como a importância do correto entendimento do problema a ser resolvido quando se decide pela migração, as mudanças que empresa e pessoas precisam realizar nesse processo e o porquê de empresas começaram a fazer o caminho inverso: saindo dos microservices e voltando aos monólitos.
Em outro podcast, dessa vez produzido pela Ambassador, Sam Newman falou sobre a importância de times de desenvolvimento tomarem para si a responsabilidade sobre os microsserviços (em inglês, ele chama esse conceito de microservices ownership). Também discutiu sobre as melhores maneiras de se conduzir o desenvolvimento local de um sistema baseado em microservices e compartilhou suas opiniões sobre o modelo de implantação release trains. De uma forma bastante resumida, nesse modelo, novas versões são colocadas em produção em intervalos regulares, como se fossem trens saindo da estação em nos pré-definidos. Cabe o time de desenvolvimento escolher em qual versão uma nova funcionalidade será disponibilizada e trabalhar.
Por fim, em um podcast produzido pela Confluent, Sam Newman explicou questões relacionadas à decomposição de bancos de dados e como realizar joins em arquiteturas baseadas em event streaming.
Dos monólitos para os microsserviços: a jornada da Shapeways
A Shapeways é uma empresa fundada em 2007 que oferece uma plataforma para a criação e desenvolvimento de produtos através de impressões 3D. Presente em mais de 140 países, sua plataforma conta com mais de 1 milhão de pessoas e com uma produção e entrega de mais de 185 mil itens por mês. Seu Vice-Presidente de Engenharia, Matt Boyle, publicou recentemente uma série de 7 artigos descrevendo a jornada da empresa saindo dos monólitos e caminhando rumo aos microsserviços.
A série de conteúdos é bastante ampla e aborda todas as motivações que levaram ao processo de migração para os microsserviços, como foi o processo de identificação do candidato a primeiro serviço a ser migrado, além dos padrões de migração que foram utilizados através de um service mesh. Um tema central apresentado nos diversos artigos publicados é a velocidade de desenvolvimento. Segundo Matt,
Embora os microsserviços, por si só, não aumentem a velocidade obrigatoriamente, eles podem melhorá-la consideravelmente em alguma situações específicas.
Os benefícios e desafios de um monólito modular
O time da JRebel fez uma publicação recente listando os benefícios e desafios da criação de um monólito modular e também fazendo uma comparação entre essa abordagem, uma abordagem com microsserviços e uma abordagem com monólitos tradicionais.
Na análise realizada, o time da JRebel argumenta que utilizar as melhores práticas da modularização pode ajudar a se usufruir dos benefícios dos microsserviços, sem ter que lidar com os custos associados ao refactoring. Por outro lado, o time também faz um alerta para uma certa precaução:
Monólitos modulares tem perdas significativas quando comparados aos microsserviços, especialmente no que diz respeito aos testes contínuos, integração e implementação contínua.
Simon Brown, criador do modelo C4 para arquitetura de soluções, vem discutindo os monólitos modulares há mais de 10 anos e, recentemente, recomendou uma importante publicação, feita em 2019, pelo time de desenvolvimento da Spotify: "Deconstructing the Monolith: Design Software that Maximizes Developer Productivity".
Plataforma Apollo Data Graph Platform: uma camada intermediária para GraphQL
Em um podcast recentemente gravado pelo InfoQ, Matt DeBergalis, fundador e CTO da Apollo, apresentou alguns dos porquês da utilização de GraphSQL e da necessidade de uma plataforma com a Apollo Data Graph. Como grandes pontos de destaque desse podcast estão os pontos de atenção para a modelagem de dados em um contexto corporativo e como uma adoção incremental de GraphQL pode ajudar o desacoplamento de soluções frontend e backend, independentemente dessas soluções serem desenvolvidas em uma arquitetura monolítica ou baseada em microsserviços.
Estudos de caso
Não é necessário utilizar microsserviços para decompor um monólito
O monólito não é um inimigo. Microsserviços não devem ser sua escolha padrão.
Esses foram os dois pontos principais trazidos por Sam Newman em sua palestra "Monolith Decomposition Patterns" no QCon Londres 2020.
Destacando alguns dos tópicos listados em seu livro recém publicado, "Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith", Sam Newman deu um conselho às pessoas presentes para que o foco do desenvolvimento seja no resultado e não na tecnologia,. Além disso, que sempre se lembrem que o objetivo de se utilizar microsserviços é a realização de implantações independentes. Para ser possível alcançar esse objetivo, Sam diz que é necessário adotar uma abordagem incremental de decomposição e não iniciar o processo pensando que o monólito é um inimigo a ser aniquilado.
Nas palavras de Sam Newman, é importante sempre perguntar para si mesmo:
Quais problemas eu estou tentando resolver? E quais desses a atual arquitetura impede de serem resolvidos?
Técnicas de Domain-Driven Design (DDD), como um exercício de modelagem em cima da arquitetura monolítica existente, podem ser bastante úteis para se encontrar os limites de cada serviço para ser possível realizar a quebra do grande monólito.
Sam disse que o termo monólito tornou-se um substitutivo para o termo legado. Em sua análise, essa é uma mudança extremamente inapropriada, uma vez que monólito diz respeito a uma unidade de implantação. Disse também que os monólitos modulares são baseados em ideias já descrita na década de 70, como a programação estruturada.
Embora seja indispensável ter boa disciplina para respeitar os limites de cada módulo e evitar uma arquitetura macarrônica (em inglês esse cenário é chamado de "Big Ball of Mud"), Sam Newman acredita que a maioria das empresas fariam melhor com os desprezados monólitos modulares do que fazem com microsserviços. Definir bons limites para cada um dos módulos "pode deixar mais fácil o trabalho de diferentes times trabalharem em conjunto, conseguindo abordar e resolver diferentes aspectos do mesmo sistema".
Apesar de seu posicionamento favorável aos monólitos modulares, Sam foi enfático ao alertar sobre o risco do "pior dos monólitos, o monólito distribuído". Segundo ele, um monólito distribuído possui diversos serviços, mas todos eles precisam ser implantados ao mesmo tempo, o que requer muita coordenação entre os times envolvidos para realizar uma entrega. Indicou que um sinal que de você está atuando em um monólito distribuído é a existência de uma pessoa em sua empresa cujo único papel é o de ser um gerente de implantação. Uma boa referência para evitar os problemas dos monólitos distribuídos é uma palestra realizada em um QCon pela Blanca Garcia Gil, onde ela conta como a BBC refez a arquitetura de um monólito distribuído.
A mensagem principal de Sam Newman, ao fim de sua apresentação, foi:
Microsserviços não devem ser sua escolha padrão. É necessário que você realmente pense, cuidadosamente, se essa abordagem é a ideal para você.
Você pode encontrar mais informações sobre essa apresentação do Sam Newman, bem como o vídeo da palestra, neste conteúdo recém publicado no InfoQ Brasil.
Por esses lados...
Nossa percepção continua como dissemos na edição anterior. A discussão parece tomar um corpo maior, vemos um maior engajamento de pessoas quando publicamos conteúdos sobre esse assunto, mas ainda está longe de ser, de fato, uma discussão colocada no mercado nacional.
E é exatamente sobre isso que gostaríamos de contar com sua ajuda. Você conhece alguém ou alguma empresa que está em fase de retorno a uma solução mais monolítica depois de ter migrado para microsserviços? Se conhecer, recomenda pra gente. Pode nos acionar aqui mesmo pelos comentários ou nas redes sociais.