Por que você não deve mudar para microsserviços

O seu produto deve ser construído como um monólito ou consistir em microsserviços desde o início? Quando é o momento certo para adotar microservices? Por que você precisaria voltar?

Vladimir Fedak Blocked Desbloquear Seguir Seguindo 3 de janeiro

Microservices é o termo que se expandiu ultimamente e muitas empresas estão considerando migrar para essa arquitetura de software. Há várias opiniões expressas sobre os benefícios e a necessidade de passar de um aplicativo monolítico para microsserviços ou computação sem servidor . O uso de microsserviços pode trazer eficiência aos fluxos de trabalho em finanças, varejo, consultoria, bancos, marketing, análise de dados e outros setores.

Este gráfico da Statista mostra que microsserviços ou computação sem servidor já foram usados ativamente em 11% das implantações de produção a partir de 2017, e 18% mais dos entrevistados apontaram a adoção dessa tecnologia como sua principal prioridade para 2018.

No entanto, é fácil encontrar as histórias dos entusiastas desiludidos, que descobriram que os microsserviços não são um truque mágico para simplificar suas operações de TI, mas o uso dessa arquitetura tende a complicar demais sua rotina de entrega de software. Há também pontos de som destacando que os microsserviços são piores que os monólitos quando são mal projetados. É até ilustrado por uma imagem simples, se não muito polida:

Em suma, se um produto ou serviço é mal projetado, quebrá-lo em microsserviços não melhorará a qualidade. Assim dito, vamos pensar quando você deve mudar para microservices, e quando você não deve fazê-lo.

Quando usar microsserviços

Para usar microsserviços corretamente, você deve entender o que são microsserviços.

Microservices são a abordagem para a arquitetura de software, onde o produto é dividido em componentes desacoplados que interagem entre si via APIs, garantindo a continuidade do desempenho do produto .

Existem vários pontos importantes para lembrar:

  • Enquanto estes módulos são desacoplados em operações, eles ainda têm algumas funções sobrepostas e código
  • Além de executar sua função principal, os microsserviços devem suportar as conexões com outros módulos por meio de APIs
  • Embora os microsserviços possam ser desenvolvidos separadamente, as interdependências entre eles devem ser testadas antes do lançamento. Por exemplo, se algum recurso em microservice1 usar uma determinada versão de uma biblioteca em microservice2 e essa biblioteca for atualizada, você deverá atualizar o código microservice1 de acordo.

Isso nos leva ao primeiro ponto da lista – enquanto tecnicamente desacoplados, os microsserviços ainda são interdependentes, ou você deve duplicar alguma funcionalidade em cada um deles para diminuir o grau de interdependência.

Dito isso, as empresas geralmente consideram a adoção de microsserviços para um produto que já está em produção há algum tempo e tornou-se volumoso demais para ser atualizado e mantido como monólito. Ao dividi-lo em microsserviços desacoplados, os desenvolvedores querem:

  • Melhore a resiliência do sistema, pois qualquer parte do produto pode ser reinicializada separadamente
  • Diminuir a complexidade de desenvolvimento, pois muitas funções podem ser isoladas para reduzir o número de interações obrigatórias
  • Encurte o tempo de colocação no mercado de novos recursos, pois desenvolver uma nova versão de um módulo menor é mais rápido do que atualizar o produto como um todo.

Portanto, entender esses benefícios e aceitar a necessidade de investir esforços na implementação de microsserviços ocorre quando as empresas atingem um certo nível de complexidade em suas operações , e simplesmente o dimensionamento vertical ou horizontal não funciona mais.

No entanto, o que as pessoas tendem a esquecer é que, ao dividir um monólito, você multiplica o grau de sua complexidade operacional . Isso significa que você precisa de bases de código de teste separadas, sincronização de liberações para garantir a estabilidade operacional e a complicação do monitoramento do ambiente de produção em geral.

Quando é o momento certo para adotar a arquitetura de microsserviços para o seu software? Francamente – desde o início do desenvolvimento do MVP . Nesse caso, você poderá planejar com antecedência e construir a infraestrutura e os pipelines de CI / CD de acordo. A única questão é: sua equipe de TI possui o conhecimento necessário para projetar, implementar e manter esse sistema?

Uma solução de trabalho com microsserviços

Uma solução bem planejada executando microsserviços deve lidar com dimensionamento e balanceamento de carga automaticamente, deve ser capaz de fazer backups separados de cada serviço e restaurá-los sem afetar o desempenho do restante do sistema, deve ser seguro por design para excluir a chance de manipulação mal intencionada do lado de fora … Também deve manter o processo de desenvolvimento do produto o mais simples possível e automatizar a maioria dos processos.

Esses pontos podem parecer óbvios (obrigado, Cap!), Mas implementá-los em demandas completas de conhecimentos que normalmente não estão prontamente presentes em uma equipe que trabalha em aplicações monolíticas. Infelizmente, mergulhar de cabeça nesta tarefa pode levar a resultados horríveis, então é melhor NÃO mudar para microservices, a menos que sua equipe tenha 100% de experiência comprovada em fazer isso com sucesso .

Uma opção óbvia é contratar uma consultoria de TI confiável para auditar a infraestrutura, as ferramentas e os processos implementados e sugerir a melhor maneira de reconstruir o ecossistema de software e a arquitetura do produto. Siga o link para saber como o svit de TI lidou com essa tarefa para nosso parceiro de longa data, o Skillbyte .

Conclusões sobre quando usar microsserviços

Resumindo: um negócio deve crescer em tamanho e experiência operacional antes de tentar dividir seu produto em microsserviços. Mesmo assim, é melhor fazê-lo trabalhando com um provedor de serviços gerenciados confiável que tenha muita experiência bem-sucedida desse tipo. A alternativa para startups é optar por microsserviços desde o início, contratando um contratado para projetar a infraestrutura de TI necessária e construir seu produto para utilizá-lo com eficiência máxima.

A IT Svit tem ampla experiência em construir os microservices desde o início e dividir os produtos existentes em microsserviços. Também projetamos, implementamos e removemos a infraestrutura necessária, por isso, se você precisar introduzir microsserviços em suas operações – estamos prontos para ajudar !

Texto original em inglês.