Motivação para o uso de microsserviços
Uma das principais coisas que devemos saber sobre microsserviços é o histórico e a motivação para a adoção dos mesmos. O termo foi empregado pela primeira vez em 2005, por Peter Rodgers.
Cerca de 15-20 anos atrás, o modelo mais comum de desenvolvimento era o de Aplicações Monolíticas. As grandes aplicações podiam até ser compostas de módulos menores de acordo com alguma segmentação técnica ou de recursos, mas havia um empacotamento de artefato para implementação em servidores de aplicação.
Devido à complexidade deste empacotamento e dificuldade de isolamento entre os componentes, era comum que um determinado módulo com problemas trouxesse impacto também a outros módulos em execução no mesmo servidor.
Além das dificuldades em tempo de execução, o fato de vários componentes serem empacotados e distribuídos em conjunto acabava gerando desafios para o processo de desenvolvimento das equipes de produto. Para ter sucesso em grandes aplicações monolíticas, era necessário um excelente trabalho de organização de roadmap entre diversas equipes de desenvolvimento. Isso frequentemente impactava a velocidade e eficiência das equipes – uma vez que é muito mais fácil desenvolver produtos e atualizá-los sem impacto se a equipe estiver no controle completo sobre a implementação e atualização das aplicações que desenvolve.
A ideia de desenvolver e empacotar aplicações menores tem então duas motivações principais:
- Tolerância a falhas nas aplicações
- Autonomia para equipes de Produto
Microsserviços numa casca de noz
É nesse contexto que surgem os microsserviços, um estilo de arquitetura de desenvolvimento que divide uma aplicação em um conjunto de serviços menores e com propósito mais específico. Essa divisão busca produzir serviços que:
- Sejam facilmente mantidos e testáveis;
- Tenham baixo acoplamento (dependência) entre si;
- Sejam implementados de forma independente e isolada;
- Possuam uma divisão funcional coerente com o domínio de negócio;
- A responsabilidade de manter seja de uma pequena equipe.
Afinidade com a computação em nuvem
É preciso esclarecer que não há nenhuma restrição prática na adequação de aplicações monolíticas aos modelos de desenvolvimento praticados nativamente na nuvem. É perfeitamente possível que uma aplicação escrita há 20 anos consiga ter benefícios por rodar na nuvem em vez de data centers on-premises. Porém, embora seja possível, é bem raro encontrar aplicações antigas que já sejam bem preparadas para ter sucesso na nuvem.
Há algumas características de arquitetura que encontramos com frequência em aplicações tradicionais que dificultam bastante a transição para a nuvem. Há também muitos casos nos quais as aplicações legadas na nuvem custam mais caro do que em ambientes tradicionais sem que as empresas tenham nenhum benefício adicional por estarem na nuvem.
Os microsserviços possuem características técnicas e funcionais que se encaixam muito bem com os modelos oferecidos pelas plataformas de nuvem. Alguns dos benefícios principais que as empresas buscam quando planejam migrar para a nuvem são:
- Elasticidade: capacidade de crescer e diminuir o tamanho da infraestrutura de acordo com a demanda de clientes;
- Tolerância a falhas: capacidade de projetar arquiteturas mais redundantes e resilientes, frequentemente distribuídas geograficamente. Isto normalmente melhora a disponibilidade das aplicações e serviços, que conseguem suportar falhas em componentes individuais;
- Auto-serviço: capacidade do time conseguir contratar e configurar os recursos necessários com autonomia, sem etapas humanas no processo;
- Contratação sob-demanda: o modelo de contratação de nuvem geralmente permite o consumo e pagamento sob-demanda sem pagamentos adiantados. Este modelo facilita muito a experimentação e validação de produtos sem investimentos expressivos em estágio inicial.
Modernização de Aplicações
O movimento de adoção da nuvem não é novo, com early-adopters construindo aplicações baseadas na nuvem há mais de 10 anos. Porém as empresas tradicionais que compõem mais de 80% da economia mundial ainda estão nos primeiros passos da adoção e migração para a nuvem.
Como as aplicações dessas empresas tem um modelo majoritariamente pré-nuvem, a maioria delas não está preparada para execução em nuvem com sucesso. Para alcançar o nível ótimo de adequação às características da nuvem, é necessário modernizar as aplicações em alguns aspectos de arquitetura e processo de desenvolvimento.
Teremos outros artigos mais detalhados abordando este processo mais profundamente, mas deixamos uma ótima referência do que normalmente é necessário: Twelve Factor-App.
Os 6 Rs da Amazon para migração de aplicações para nuvem
A Amazon Web Services propôs, em 2016, uma abordagem com 6 possíveis caminhos para a migração de qualquer aplicação ou produto para a nuvem. Embora os detalhes do processo de migração possam ser bem complexos, a análise das opções que temos não é difícil de entender. São elas:
Rehosting (também conhecido como Lift and Shift): este é um processo de migração sem modernização, basicamente reconfigurando os servidores e aplicações no novo ambiente da nuvem usando máquinas virtuais. Normalmente ele funciona, é rápido de migrar, mas não traz benefícios relevantes. Na maioria dos casos os custos na nuvem aumentam comparando com o ambiente anterior onde a aplicação estava.
Replatforming: neste processo, é feito um ajuste de configurações da aplicação sem demandar reescrita relevante de código. Algumas adequações pontuais permitem que as aplicações e serviços executem em serviços gerenciados da plataforma de nuvem e já consigam ter bons benefícios. Exemplos simples deste processo são:
- Adequação de bases de dados para executar como Bancos de Dados Gerenciados;
- Gravar sessão de aplicações web em serviços de cache gerenciados;
- Configurar uploads de arquivos para usarem um serviço gerenciado em vez de gravar em discos locais nos servidores;
Repurchasing: neste caso, em vez de migrar uma aplicação para nuvem, há uma contratação de novo serviço para substituição ao anterior. Exemplos comuns são a substituição de sistemas de gestão como ERPs e CRMs que executavam em data centers por novas versões contratadas em modelo SaaS, de software-como-serviço. Este processo provavelmente envolverá uma migração de dados entre os sistemas, mas não uma migração convencional de ambiente.
Refactoring: este é o caminho mais avançado e talvez mais complexo, no qual a aplicação é aprimorada com reescrita de código para se adequar às arquiteturas nativas da nuvem. Porém, sem dúvida é um caminho que pode contribuir muito para a competitividade das empresas. Os ganhos de eficiência e agilidade no lançamento de produtos e também na experimentação de negócios são expressivos e a empresa consegue aprender bem rápido sobre seus clientes e sobre seu mercado.
Retire: este caso ocorre quando a empresa identifica que, em um cenário de migração para a nuvem, aquela aplicação/serviço deixa de ser necessária. Um exemplo seria uma aplicação de autenticação/autorização que atenda a requisitos específicos de uma empresa e que seja substituída por um modelo equivalente disponível em uma solução SaaS.
Retain: este caso é muito comum em data centers tradicionais com alto volume de transações ou mensagens. A aplicação pode ter uma arquitetura e protocolos de comunicação não suportados pela nuvem, como aplicações tradicionais que usavam comunicação Multicast como padrão. Este modelo de comunicação até pouco tempo não era suportado em nuvens públicas e inviabilizava uma migração sem reescrita. Neste cenário, caso a aplicação ainda seja necessária para a empresa, ela precisa ser mantida no ambiente original. Cenários como esse frequentemente motivam a adoção de nuvens híbridas para manter a comunicação entre todas as aplicações e serviços necessários.
Como avançar e ter sucesso com microsserviços
Falamos um pouco sobre as características e motivações para o uso de microsserviços, mas é prudente esclarecer também alguns pontos de atenção na adoção desse caminho.
Isso porque as arquiteturas de microsserviços podem ser bem complexas e tornar o processo de desenvolvimento mais lento e custoso do que seria em uma aplicação tradicional. Há desafios ligados a monitoramento, integração entre serviços e segurança que muitas vezes não justificam este maior investimento no desenvolvimento da solução.
Uma recomendação importante é buscar sempre a clareza sobre qual dor ou problema se busca resolver através dos microsserviços. Sabendo quais são as dores, não custa questionar se realmente já foram sentidas ou se poderão aparecer também no futuro. Um erro muito comum entre engenheiros de software é acreditar sempre que poderão alcançar um volume de acessos e criticidade fabulosos e desenhar uma arquitetura capaz de lidar com tudo isso.
O que frequentemente é visto em eventos de tecnologia são palestras de engenheiros da Netflix, Spotify e Amazon, entre outros gigantes mundiais. As arquiteturas descritas ali resolvem problemas que nunca serão enfrentados por 99,9% dos profissionais; então, não faz sentido lidar diariamente com uma complexidade mais alta do que nossos problemas requerem, não é mesmo?
Deixamos então a recomendação de ter a arquitetura mais simples possível, aquela que resolve o seu problema, e somente perseguir um modelo mais sofisticado quando as necessidades se tornarem evidentes. O sucesso do produto às vezes pede a tecnologia mais cotidiana e confiável possível. A sabedoria guia sempre as melhores decisões.
