Entenda em que momento e em quais situações essa abordagem de desenvolvimento de software é válida e quando não usar microsserviços é a melhor solução

A arquitetura de microsserviços tem sido bastante procurada por organizações que estão modernizando sua infraestrutura de TI. Entretanto, antes de investir nessa solução, é preciso estar ciente de que essa abordagem não atende as necessidades de todas as empresas.

Indicados, geralmente, para aplicações complexas compostas por vários componentes, os microsserviços atendem bem sistemas que precisam ter alta disponibilidade e escalabilidade.

No entanto, a utilização de microsserviços se popularizou nos últimos anos. De acordo com uma pesquisa da O’Reilly, realizada em 2020, a maioria dos 1.502 entrevistados relatou ter algum sucesso com microsserviços.

92% dos usuários disseram ter sido bem sucedidos, apesar de apenas 10% deles considerarem o sucesso como total. Em relação ao tempo de uso, quase um terço dos entrevistados (28%) afirmaram que suas organizações utilizam microsserviços há pelo menos 3 anos. No entanto, a maioria (61%) revelou usar há pouco mais de 1 ano.

A crescente adoção em microsserviços se deve, inclusive, porque em determinadas situações, a arquitetura facilita o desenvolvimento de múltiplos serviços ao mesmo tempo, o que aumenta a produtividade da equipe. Além disso, cada serviço pode ser testado e rodar de forma mais rápida e eficiente.

Assim, com o uso de serviços independentes e com baixo ou nenhum acoplamento, a possibilidade de adaptabilidade de linguagens, ferramentas e frameworks aumenta. E a ocorrência de falhas diminui, pois se acontecer um problema em parte do sistema, as demais partes continuam funcionando.

Entretanto, se a complexidade do seu projeto é baixa, a utilização de microsserviços pode não compensar, pelo alto custo de implantação e manutenção. Isso sem contar na adaptação e treinamento dos times envolvidos. Neste caso, talvez um modelo híbrido possa funcionar.

Portanto, se você quer saber quando uma empresa deve optar por microsserviços, por que nem sempre é a melhor solução para seus problemas de infraestrutura de TI e quais os desafios dessa abordagem, continue a leitura deste post e confira!

Saiba mais: Microsserviços: conceitos, vantagens e desvantagens desse tipo de arquitetura

Quando optar por microsserviços 

Se você, como gestor de infraestrutura, está planejando migrar de arquiteturas tradicionais para microsserviços, mas ainda tem dúvidas se essa é a melhor solução para o setor de TI da sua empresa, relacionamos, a seguir, 4 situações em que o uso de microsserviços é indicado. 

1. Quando existe a necessidade de escalar um componente individual ou implementar, rapidamente

De acordo com Peter Antony Rausch, arquiteto de soluções e líder de equipe na Supero Tecnologia, escalar apenas um componente individual não torna a arquitetura orientada a microsserviços. Escalando apenas um componente temos apenas o que podemos chamar de monolito distribuído. E complementa:

– Quanto a implementar de maneira mais rápida, é seguro afirmar que a complexidade do domínio específico de um serviço diminui com microsserviços, porém a complexidade do sistema como um todo aumenta, e muito. É importante, nessa situação, ter equipes especialistas nos domínios de negócio e também é fundamental perceber as dependências dos serviços. Os serviços precisam ter baixo acoplamento entre si, caso contrário seu deploy ficará dependente de outro serviço e isto ocasionará atrasos nas entregas.

2. Quando precisa reescrever sistemas legados em linguagens mais recentes

Neste ponto específico, considerar o uso de microsserviços é fundamental. O team leader da Supero  alerta que é a decisão deve ser feita olhando para o negócio. 

Para isso, alguns questionamentos devem ser feitos, como: precisamos de uma linguagem mais recente? O que vamos ganhar investindo em microsserviços? Essa é a arquitetura que precisamos agora? Afinal, o arquiteto de soluções lembra que microsserviços é uma das alternativas de abordagem, mas normalmente não é necessária.

– Na reescrita de um sistema legado ou em migrações para arquitetura de microsserviços, quando se faz necessário, uma boa dica é começar pelo serviço de identidade. O serviço de identidade é responsável por todo o controle de usuários e perfis de acesso. Mais cedo ou mais tarde você vai precisar de um serviço de identidade para manter o usuário autenticado entre os diversos serviços.

3. Quando a performance do monolito no nível de sistema e de negócio caiu

Segundo Peter, pelo fato de microsserviços estarem em alta e na moda, muitos gestores de TI acham que só é possível escalar ou ter performance usando essa abordagem, mas ele desmente esse mito.

– Uma forma de escalar estrategicamente uma aplicação é o famoso Scale Clube, ou na tradução literal: cubo de escala, que é composto por 3 eixos:

• X – Horizontal Duplication (escala horizontal): colocar mais máquinas para processar).
• Y – Slit by Function or Service (decomposição funcional): aqui sim entram microsserviços.
• Z – Lookup Oriented Splits (ex: Customer Database) roda parcela dos dados: aqui temos, por exemplo, a instalação de um  um ERP em vários locais que têmsua própria infraestrutura, o que também é uma maneira de escalar.

Peter lembra ainda que a falta de performance sozinha não é um motivo para uso de microsserviços.

– Temos exemplos entre os sites mais acessados no mundo, como o StackOverflow, que é um grande monolito que possui uma equipe e estratégia com obsessão por performance. Eles trabalham cada detalhe do desenvolvimento focado em performance, pensando em cada byte alocado na memória. Portanto, performance é algo para se identificar o gargalo e trabalhar nele.

4. Quando a aplicação é grande o suficiente para ser quebrada em microsserviços

De acordo com o arquiteto de soluções da Supero, o ponto aqui não é só o tamanho da aplicação que deve ser observado, mas também a capacidade técnica da equipe que irá operar os microsserviços.

Afinal, conforme o tamanho da organização aumenta, mais domínios de negócio aparecem e novas equipes se formam. Neste momento, é interessante cada domínio de negócio ter sua independência no ciclo de desenvolvimento de software.

Uma estrutura de microsserviços bem implementada alinha negócios, pessoas e tecnologias para possibilitar um ciclo de desenvolvimento independente e acelerar o negócio.

– A lei de Conway diz que uma organização tende a replicar a sua estrutura no software. No entanto, a lei de Conway inversa diz que a estrutura do software tende a ser replicada na organização. Ou seja, ter uma estrutura técnica de software que não é replicada para a organização pode trazer grandes problemas de comunicação, desenvolvimento, estratégia, entre outros.

O que considerar ao optar por microsserviços

Peter Rausch afirma que, além de fatores estritamente ligados à aplicação, outros pontos devem ser considerados pelo gestor antes de optar pelo uso de microsserviços. 

Resumidamente, podemos pensar nas seguintes questões:

• Qual a maturidade da equipe: usa devops ou agile?
• Como a tecnologia vai impactar no desenvolvimento do sistema?
• Há um time especialista para configurar e implementar a nova arquitetura?
• Qual a real necessidade de escala da aplicação: está no core do negócio e vai ser expandida?
• Quais os custos dessa movimentação para o setor e para a empresa?

Respondidas essas perguntas, é hora de encarar os obstáculos que podem surgir com a implantação de microsserviços.

Leia também: Como ter sucesso com microsserviços?

Desafios de usar microsserviços

Embora os microsserviços ofereçam vantagens como agilidade, estabilidade, economia e automatização de tarefas, a abordagem pode ser bastante desafiadora na execução. Até para empresas que contam com recursos para o seu desenvolvimento e tomaram uma decisão embasada pela infraestrutura. 

A fim de auxiliar gestores de infraestrutura de TI, Peter elencou 5 desafios inerentes ao microsserviços e quais as estratégias para superá-los.

1. Em sistemas distribuídos a garantia de transnacionalidade é mais complexa 

Nesse caso, é preciso contar com estratégias de tratativas, a fim de manter os dados consistentes, sendo que há uma rede envolvida e a rede sempre falha. Para isso, estratégias de impotência e resiliência são cruciais.

2. Disponibilidade

Quando temos um serviço e mantemos 99% de disponibilidade dele, ao optarmos por dois serviços com 99% de disponibilidade, teremos 98% de disponibilidade do sistema. Para isso, a utilização de um Event Bus, centralizando a comunicação nele, é muito importante.

3. Manter vários serviços aumenta o custo de infraestrutura 

Para isto, é necessário não só políticas para aumento de escala, quanto para diminuição da escala, o que chamamos de elasticidade. Ferramentas como container e orquestradores de containers facilitam muito o trabalho.

4. Caching para minimizar a comunicação com a rede e manter a performance do sistema 

Ter um caching de determinadas informações é muito importante. Pois aqui, o complexo não é a implementação, mas sim as estratégias de atualização da informação.

5. Desenhar a estrutura de microsserviços 

Este é o maior desafio do negócio e a tarefa mais complexa. Você deve saber o que dividir e como dividir. Aqui, a grande lição é olhar pro negócio! 

Utilizar o conceito Domain Driven Design ajuda muito. Itens como o tempo da informação começam a se tornar importantes e, então, é preciso atender ao Teorema CAP e tratar com consistência eventual dos dados, ou seja, em algum momento o dado consultado pode não ser o dado mais atualizado.

Contudo, é importante salientar que um dos maiores ofensores de performance em sistema é a rede. Em um sistema com microsserviços, há comunicação o tempo todo com a rede e, apesar de haver escala, a performance é sempre um ponto de atenção.

Veja: SOA vs. microsserviços: como determinar qual a arquitetura ideal?

Quando não usar microsserviços

Se mesmo diante dos desafios, os microsserviços ainda são uma opção para você, veja 3 situações de quando, definitivamente, não usar.

1. Quando o sistema não é tão complexo

Como já mencionado, muitas vezes o problema não é só a complexidade dos sistemas, mas o fator escala e equipes especialistas. Sempre olhar para o seu negócio e ver a sua necessidade é a melhor maneira de descobrir que essa não é a melhor solução para sua empresa.

2. Quando não há equipe suficiente e experiente

Montar uma estrutura de microsserviços com uma equipe de três ou quatro pessoas pode ser um tiro no pé. Você, possivelmente, não terá pessoas com know-how suficiente de negócio, técnico e devops para manter e desenvolver a aplicação. 

3. Quando o objetivo não está claro

Saber por que você está criando microsserviços e para atender quais necessidades é fundamental para garantir o sucesso da operação. É importante lembrar que a complexidade de desenvolvimento é transferida de forma bem agressiva para a operação e monitoramento do sistema. Portanto, se o ambiente não está preparado, não se arrisque.

Confira ainda: Fábrica de software é a solução para o seu projeto?

Conte com um fornecedor especializado

Como vimos ao longo deste post, adotar a arquitetura de microsserviços pode ser uma excelente solução ou uma escolha equivocada, tudo vai depender das necessidades da sua empresa e o quanto ela está preparada para essa abordagem.

De qualquer forma, independente de implementar ou não microsserviços, você como gestor de infraestrutura de TI sabe que tudo o que envolve o setor requer um nível grande de confiança e segurança.

Portanto, para manter seus sistemas atualizados, conte com um time de profissionais especializados em soluções de TI sob demanda para o seu negócio.

Invista em um fornecedor com experiência e credibilidade no mercado de tecnologia. 

Conheça a Supero e saiba mais sobre os serviços personalizados que atendem às suas necessidades em projetos e sustentação.

Entre em contato e agende um horário com um de nossos consultores.