Olhando para o passado há cerca de cinco anos, você pode ver o quanto mudou desde então a atitude em relação à arquitetura dos microsserviços. No começo eles eram extremamente populares. Após o sucesso da Netflix, Amazon e Gilt.com, os desenvolvedores decidiram que o desenvolvimento de fato de microsserviços não é diferente do desenvolvimento de aplicativos. Agora, todos entendiam que os microsserviços são um novo estilo arquitetural eficaz para resolver certos problemas, tem seus prós e contras.
Para entender o que são microsserviços e em que casos eles devem ser usados, procuramos Jaime Buelta, autor do Docker prático para microsserviços com Python. Ele falou sobre as vantagens dessa arquitetura e também compartilhou recomendações para os desenvolvedores que planejam mudar de monólitos para ela.
Benefícios e riscos
Um aplicativo monolítico tradicional combina todos os seus recursos em um único módulo conectado. No caso de microsserviços, o oposto é verdadeiro. O aplicativo é dividido em serviços menores e independentes que podem ser implantados, atualizados e substituídos independentemente. Cada microsserviço é criado para uma finalidade comercial e pode interagir com outros microsserviços usando mecanismos simples.
Buelta explica: “Uma arquitetura de microsserviço é uma maneira de estruturar um sistema no qual vários serviços independentes se comunicam de uma certa maneira (isso geralmente acontece com os serviços da web RESTful). Um recurso importante é que cada microsserviço é capaz de atualizar e implantar independentemente dos outros. ”
A arquitetura de microsserviço define não apenas como você cria seu aplicativo, mas também como sua equipe está organizada.
“Uma equipe independente pode ser totalmente responsável pelo microsserviço. Isso permite que as organizações cresçam sem unir os desenvolvedores ”, explica Buelt.
Uma das principais vantagens dos microsserviços é que eles permitem introduzir inovações sem nenhum impacto especial no sistema como um todo. Com a ajuda dos microsserviços, você pode executar o dimensionamento horizontal, ter limites claros de módulos, usar uma variedade de tecnologias e conduzir o desenvolvimento paralelo.
Quando perguntado sobre os riscos associados aos microsserviços, Buelta respondeu: “A principal dificuldade na implementação da arquitetura (especialmente ao mudar de um monólito) é criar um design no qual os serviços sejam realmente independentes. Se isso não for possível, as comunicações entre serviços se tornarão mais difíceis, o que levará a custos adicionais. Os microsserviços precisam de profissionais que moldem a direção do desenvolvimento a longo prazo. Eu recomendo que as organizações que desejam mudar para uma arquitetura como essa designem alguém responsável pelo "quadro geral". Precisamos olhar para os microsserviços mais amplamente ”, disse Jaime.
Transição do monólito para microsserviços
Martin Fowler, um conhecido autor e consultor de software, aconselha aderir ao princípio de "o primeiro é um monólito". Isso se deve ao fato de que o uso de uma arquitetura de microsserviço desde o início do desenvolvimento é arriscado, pois na maioria dos casos é adequado apenas para sistemas complexos e grandes equipes de desenvolvimento.
“O principal critério que deve encorajá-lo a mudar para uma nova arquitetura é o tamanho da sua equipe. Grupos pequenos não devem fazer isso. Nessas condições, os desenvolvedores já entendem tudo o que acontece com o aplicativo e sempre podem fazer uma pergunta esclarecedora a um colega. O monólito funciona perfeitamente nessas situações e, portanto, quase todo sistema começa com ele ”, disse Jaime. Isso confirma a “regra das duas pizzas” da Amazon, segundo a qual a equipe responsável por um microsserviço pode ser alimentada com duas pizzas - caso contrário, é muito grande.
“À medida que a empresa cresce e as equipes de desenvolvimento aumentam, pode ser necessária uma melhor coordenação. Os programadores geralmente começam a interferir entre si. Compreender o propósito de um pedaço de código específico está se tornando mais difícil. Nesses casos, a transição para microsserviços faz sentido - isso ajudará a compartilhar responsabilidades e trará clareza à imagem geral do sistema. Cada equipe pode definir seus próprios objetivos e trabalhar principalmente de forma independente, fornecendo uma interface externa clara. No entanto, para que essa transição faça sentido, deve haver muitos desenvolvedores ”, acrescenta Buelt.
Recomendações para migrar para microsserviços
Respondendo a uma pergunta sobre quais recomendações práticas os desenvolvedores podem usar ao mudar para microsserviços, Buelta disse: "A chave para uma arquitetura bem-sucedida de microsserviços é que cada serviço seja o mais independente possível".
Surge a pergunta: "Como você pode tornar os serviços independentes?" A melhor maneira de descobrir a interdependência de um sistema é pensar em novas possibilidades: “Se você deseja adicionar uma nova função, ela pode ser implementada alterando apenas um serviço? Que tipos de funções exigirão a coordenação de vários microsserviços? Eles serão usados com frequência ou raramente? É impossível criar o design perfeito, mas pelo menos você pode usá-lo para tomar as decisões corretas e informadas ”, explica Buelt.
Jaime recomenda mudar para a arquitetura corretamente, para que você não precise refazer tudo mais tarde. “Depois que a transição estiver concluída, a alteração dos limites dos microsserviços será mais difícil. Vale a pena dedicar mais tempo à fase inicial do projeto ", acrescenta.
Mover de um padrão de design para outro é um passo sério. Perguntamos quais problemas Jaime e sua equipe enfrentaram durante a migração para microsserviços, aos quais ele respondeu:
“De fato, as principais dificuldades estão relacionadas às pessoas. Esses problemas geralmente são subestimados, mas a mudança para microsserviços realmente muda a maneira como os desenvolvedores trabalham. A tarefa não é fácil! Ele acrescenta: “Eu pessoalmente encontrei problemas semelhantes. Por exemplo, eu tive que treinar e dar conselhos aos desenvolvedores. É especialmente importante explicar por que certas mudanças são necessárias. Isso ajuda as pessoas a entender as razões para introduzir todas as inovações de que talvez não gostem.
Ao mudar de uma arquitetura monolítica, muitas dificuldades podem surgir ao implantar um aplicativo que foi lançado anteriormente como um único módulo. Requer uma análise mais completa para garantir a compatibilidade com versões anteriores e minimizar os riscos. Às vezes, lidar com essa tarefa é muito difícil ".
Razões para escolher Docker, Kubernetes e Python como sua pilha de tecnologia
Perguntamos a Buelt que tecnologia ele prefere para implementar microsserviços. Quanto à escolha da linguagem, a resposta foi simples: “Python é a melhor opção para mim. Esta é minha linguagem de programação favorita! .. Essa linguagem é adequada para microsserviços. É conveniente ler e fácil de usar. Além disso, o Python possui ampla funcionalidade para desenvolvimento da Web e um ecossistema dinâmico de módulos de terceiros para qualquer necessidade. Essas necessidades incluem a conexão com outros sistemas, como bancos de dados, APIs externas, etc. ”
O Docker é frequentemente apontado como uma das ferramentas mais importantes para microsserviços. Buelta explicou o porquê:
“O Docker permite encapsular e copiar o aplicativo em pacotes padronizados convenientes. Isso reduz a incerteza e a complexidade do ambiente. Também simplifica bastante a transição do desenvolvimento para a produção de aplicativos. Além disso, o tempo necessário para usar o equipamento é reduzido. Você pode colocar vários contêineres em ambientes diferentes (mesmo em diferentes sistemas operacionais) em uma caixa física ou máquina virtual. ”
Sobre o Kubernetes:
“O Kubernetes permite implantar vários contêineres do Docker de maneira coordenada. Isso faz com que os desenvolvedores pensem de maneira agrupada, lembrando o ambiente de produção. Ele também permite definir um cluster usando o código para que novas implantações ou alterações na configuração sejam definidas nos arquivos. Tudo isso possibilita métodos como o GitOps (escrevi sobre eles em meu livro), mantendo a configuração completa no sistema de controle de versão. Cada alteração é feita de uma maneira específica e reversível, pois é uma mesclagem regular do git. Graças a isso, é muito fácil restaurar ou duplicar a infraestrutura. ”
“Você precisa gastar tempo aprendendo Docker e Kubernetes, mas vale a pena. Ambas as ferramentas são muito poderosas. Além disso, eles incentivam você a trabalhar de forma a evitar problemas durante a produção ”, diz Buelt.
Microsserviços multilíngues
Ao desenvolver microsserviços, você pode usar uma variedade de tecnologias, pois, idealmente, uma equipe independente é responsável por cada uma delas. Buelta compartilhou sua opinião sobre os microsserviços multilíngues: “Os microsserviços multilíngues são ótimos! Essa é uma das principais vantagens da arquitetura. Um exemplo típico de um microsserviço multilíngue é a transferência de código herdado escrito em um idioma para um novo. Um microsserviço pode substituir qualquer outro que forneça a mesma interface externa. No entanto, seu código será completamente diferente. Por exemplo, mudei de aplicativos PHP antigos, substituindo-os por análogos escritos em Python. " Jaime acrescentou: “Trabalhar com duas ou mais plataformas ao mesmo tempo ajudará a melhor entendê-las e em quais casos é melhor usá-las.”
Embora a capacidade de usar microsserviços multilíngues seja uma grande vantagem arquitetural, também pode aumentar os custos de transação. Buelta aconselha: “Precisamos conhecer a medida. Não faz sentido usar sempre uma nova ferramenta e privar a equipe da oportunidade de compartilhar conhecimento entre si. Números específicos podem depender do tamanho da empresa, mas, como regra, não faz sentido usar mais de dois ou três idiomas diferentes sem uma boa razão. Você não precisa aumentar a pilha de tecnologia - os desenvolvedores poderão compartilhar conhecimento e começar a usar as ferramentas disponíveis com mais eficiência.
Sobre o autor
Jaime Buelta é um programador profissional e desenvolvedor de Python que, ao longo dos anos de sua carreira, encontrou muitas tecnologias diferentes. Ele desenvolveu software para vários campos e indústrias, incluindo aeroespacial, redes e comunicações, bem como sistemas SCADA industriais, serviços de videogame on-line e serviços financeiros.
Como parte de várias empresas, ele lidou com áreas funcionais como marketing, gerenciamento, vendas e design de jogos. Jaime é um ávido defensor da automação e quer que os computadores façam todo o trabalho duro, permitindo que as pessoas se concentrem em coisas mais importantes. Atualmente, ele vive em Dublin e fala regularmente em conferências da PyCon na Irlanda.