Nota: O seguinte artigo irá ajudá-lo com: Os microsserviços dominarão 2021? Com certeza talvez
Comentário: os microsserviços estavam na moda em 2020, mas os desenvolvedores estão aprendendo que os aplicativos monolíticos também têm seu lugar.
Como sempre, Kelsey Hightower provavelmente está certa. No início de 2020, Hightower sugeriu que “monólitos são o futuro”. O problema, ele apontou, é que os desenvolvedores não estão construindo microsserviços, mas construindo aplicativos monolíticos distribuídos: “Agora você ou de escrever código ruim para construir infraestrutura ruim sobre a qual você implanta o código ruim”. É um código de lixo (e expansão de microsserviços) até o fim.
Então, 2021 é o ano do monólito? Com certeza talvez.
VEJO: Microsserviços: a base dos aplicativos corporativos de amanhã (recurso especial ZDNet/TechRepublic) | Baixe a versão gratuita em PDF (TechRepublic)
Resolvendo e criando problemas
Mas primeiro, vamos lembrar por que os microsserviços têm sido um grande benefício para a computação. Primeiro, os microsserviços permitem que equipes diferentes colaborem no mesmo sistema sem necessariamente usar as mesmas ferramentas (banco de dados, idioma etc.). Também facilita a criação de aplicativos altamente escaláveis, pois, em vez de ter que dimensionar um aplicativo monolítico, as equipes podem dividir esses aplicativos em serviços menores, dimensionando cada um de forma independente. Como bônus, cada microsserviço manteria o estado, eliminando a necessidade de o aplicativo associado ser executado em uma única máquina.
Tudo bem, certo?
Não exatamente. De acordo com Ryland Goldstein, da Temporal, “o primeiro problema que as pessoas notaram quando mudaram para microsserviços foi que de repente se tornaram responsáveis por muitos tipos diferentes de servidores e bancos de dados”. Esses problemas de infraestrutura foram resolvidos, em parte, pela introdução do Kubernetes e ofertas sem servidor, mas deixou o problema persistente de código ruim. (Veja o ponto de Hightower acima: Código ruim em infraestrutura ruim.) Empresas como a Temporal pretendem oferecer plataformas de orquestração de microsserviços que permitem que os desenvolvedores se concentrem na lógica de negócios enquanto deixam o gerenciamento da infraestrutura de microsserviços para a Temporal, uma abordagem interessante que pode ajudar. (Claro, o Hacker News tem muitas opiniões sobre isso.)
Mas há uma pergunta mais fundamental a ser respondida, e ela remonta ao cerne do argumento de Hightower: você realmente precisa de microsserviços?
CONSULTE: Prepare-se para computação sem servidor (recurso especial ZDNet/TechRepublic) | Baixe a versão gratuita em PDF (TechRepublic)
De volta ao futuro dos monólitos
Isso não é simplesmente uma questão para equipes menores considerarem, como o estimado Martin Fowler postulou: “Enquanto [microservices] é uma arquitetura útil – muitas, na verdade, a maioria das situações se sairiam melhor com um monólito.”
Por quê? Fowler sugeriu (pelo menos) três razões. Em primeiro lugar, os sistemas distribuídos são mais difíceis de programar, pois as chamadas remotas são lentas e estão sempre em risco de falha. Em segundo lugar, manter uma consistência forte é difícil para um sistema distribuído, o que deixa todos a descobrir como gerenciar a consistência eventual. E, finalmente, a maioria das empresas não tem uma equipe de operações madura capaz de gerenciar muitos serviços, a maioria dos quais será redistribuída regularmente.
VEJO: Pesquisa: Microsserviços trazem entrega de aplicativos mais rápida e maior flexibilidade para empresas (TechRepublic )
Além disso, o líder de engenharia da Lyft, Matt Klein, ofereceu outra dificuldade importante introduzida pelos microsserviços: “A outra grande mudança que vem com o desenvolvimento de microsserviços é o surgimento da rede como um substrato instável que não pode ser evitado. Todo desenvolvedor deve, em última análise, lidar com problemas de rede, tanto em termos de transporte quanto em termos de ferramentas muito mais complexas necessárias para depuração.” (É claro que Klein seria o primeiro a defender uma abordagem baseada em microsserviços, já que desenvolveu o Envoy precisamente para ajudar a Lyft a se afastar de uma abordagem baseada em monolíticos.)
Mas isso pode ser um longo caminho para dizer que um novo paradigma de desenvolvimento e implantação não salvará os desenvolvedores de maus hábitos. Shaun Gehring, líder sênior de engenharia de produtos da Comcast Cable, chega a isso quando argumentou: “Seu sucesso na implementação dependerá da quantidade de planejamento que você colocar”.
Em outras palavras, perguntar se os monólitos (ou microsserviços) são o futuro é a pergunta errada. É realmente uma questão de uma empresa individual/equipe de desenvolvedores e o que eles estão preparados para colocar no aplicativo/infraestrutura. Entrada de lixo, saída de lixo, e isso vale tanto para microsserviços quanto para monólitos.
