Fala pessoal, neste artigo vou descrever um pouco sobre o MEU entendimento sobre o estilo arquitetural de Microserviços, o que precisamos conhecer de tecnologias e as preocupações que devemos ter ao adotar esse conceito que é relativamente novo no mercado (estamos falando do primeiro estilo arquitetural pós-DevOps).
O sucesso na implementação de arquiteturas distribuídas com microserviços depende diretamente do seu conhecimento de várias tecnologias e conceitos, vamos tentar passar por algumas(não todas) para ajudar a esclarecer e e tentar te ajudar a ter sucesso na construção de seus sistemas.
Farei uma série de artigos (no mínimo 3) sobre o que estudei deste tema tendo em vista que é muito conteúdo para somente um artigo ok?
O que vamos ver ao longo desta serie de artigos sobre Microserviços:
- Quais são as vantagens e desvantagens em sistema monolíticos;
- Quais são as vantagens e desvantagens em Microserviços;
- Devo migrar meus sistemas para Microserviços?
- Conceitos de Api Gateway;
- Diferença entre Api Gateway e Api Manager;
- Como trabalhar com autenticação;
- Comunicação entre Microserviços;
- Virtualização e descoberta de serviços
- Resiliência;
- Logs e Telemetria;
- DevOps
Quais são as vantagens e desvantagens dos sistemas monolíticos?
Antes de entrar nos conceitos e tecnologias dos Microserviços precisamos falar um pouco sobre sistemas monolíticos e entender as vantagens e desvantagens dessa abordagem.
Não são todos os sistemas que irão se enquadrar em Microserviços e também nem todo sistema monolítico deverá ser transformado em Microserviços, portanto é essencial saber as vantagens e desvantagens das duas abordagens
Vantagens:
- Estruturalmente mais simples, praticamente todo o sistema está em uma mesma estrutura de código o que torna mais simples o entendimento e manutenção. Debugar um sistema monolítico também é mais simples e não existe muitas camadas para se preocupar;
- Desenvolvimento, teste e implantação de forma mais fácil pois estamos falando somente de uma aplicação ou seja normalmente o sistema todo estará escrito em uma só linguagem de programação, o teste é mais simples por estar todas as funcionalidades juntas e a implantação não terá a preocupação de quebrar outros sistemas;
- Boa abordagem para aplicações pequenas;
- Não há duplicidade de código e classes entre os módulos, ou seja existe a possibilidade de centralizar funções e métodos para serem utilizados em todo o sistema;
- Fluxo de publicação mais simples ou seja alterou, compilou é só publicar.
Desvantagens:
- Ficar preso a uma tecnologia se por exemplo seu sistema estiver construido em .NET dificilmente irá conseguir construir algo em Java para o mesmo sistema, raramente você irá trocar sua base de dados e muito mais raro ainda trocar seu servidor de aplicação;
- Difícil entendimento e manutenção conforme cresce sua aplicação da mesma forma que é fácil o entendimento de uma aplicação monolítica simples existe a tendência que ela cresça e fique enorme dificultando a manutenção principalmente se voçe trabalhar em um grupo de desenvolvedores para a mesma solução;
- Ter um grande ponto de falha uma simples falha ou bug pode parar todo o sistema;
- Queda na qualidade de código quanto mais cresce seu monolítico mais vai acontecer a queda de qualidade e irá se tornar mais difícil implementar códigos melhores e mais performáticos conforme vão surgindo no mercado;
- Adoção de contínuos deployment fica mais difícil sendo uma única aplicação, ainda nesse cenário temos a preocupação de parar todo o sistema, programar o deploy, testar tudo e liberar depois para o usuário final
Quais são as vantagens e desvantagens dos Microserviços?
A melhor definição que encontrei sobre Microserviços foi a seguinte:
“Serviços pequenos e autônomos e desacoplados trabalhando de forma conjunta, a fim de atender a uma demanda especifica”
Vantagens:
- Escalabilidade pode-se escalar somente um Microserviço de seu sistema, não existindo mais a necessidade de escalar o stack inteiro de seu sistema monolítico para ganho de performance por exemplo, isso impacta diretamente no custo e carga do sistema. Para que vou gastar processamento e maquina para uma funcionalidade que não é necessária? Serviços individuais são mais fáceis de entender e podem ser implantados e escalados de forma independente.
- Adoção de novas tecnologias com mais facilidade, não é mais necessário amarrar desenvolvedores a uma tecnologia especifica, podendo ser utilizada a melhor tecnologia no momento para atender cada caso, tornando possível a evolução do sistema continuamente e assim evitando que ele fique obsoleto e se torne legado em pouco tempo;
- Baixo acoplamento, o baixo acoplamento garante que o sistema NÃO tenha um único grande ponto de falha permitindo que a manutenção de um serviço não impacte diretamente em outras funcionalidades do sistema, quanto menor o acoplamento mais fácil será a manutenção e a substituição do Microserviço;
- Deploy de forma independente, um Microserviço não deve ter ligação direta com outro Microserviço possibilitando assim que seja efetuado o deploy de forma independente;
- Equipes separadas e independentes posso ter em um mesmo sistemas varias equipes cada uma cuidando de um conjunto de Microserviços;
- Organizado em torno dos recursos do negócio um Microserviço deve estar sempre focado em um domínio de negocio, desenvolvedores e envolvidos devem ter o conhecimento de desenvolvimento DDD (Domain Drive Design) e conhecer sobre Bounded Context (contextos delimitados). Quando se fala de Microserviços é importante conhecer e estudar seu negócio para ter certeza que a arquitetura serve para seu contexto.
Desvantagens:
- Complexibilidade de deploy, um sistema de Microserviços pode crescer muito o que torna o deploy uma tarefa muito complicada, neste cenário entra o DevOps para gerenciar processos de deploy e entrega continua o que vai acarretar também em necessidade de governança;
- Gerenciamento de dados distribuídos ou seja gerenciar os dados de um sistema de Microserviços se torna uma das atividades mais complicadas nesse cenário;
- Testes são mais complicados imagine testar um fluxo composto por vários Microserviços, sendo que em muitos cenários o resultado de um impacta no negócio de outro;
- Dificuldade para programador iniciante que terá mais dificuldade para entender a estrutura do sistema como um todo, levando em consideração que poderá ter um “mix” de tecnologias envolvidas e também um “mix” de conceitos;
- Controle de transações que conhecemos em sistemas monolíticos a nível de banco de dados com rollbacks e commits é praticamente inexistente em mecanismos de Microserviços;
- Desenvolvedores qualificados são necessários pois o dev deve conhecer mais tecnologias e estar sempre antenado com mais frameworks do que o desenvolvedor de um sistema monolítico.
Devo migrar meus sistemas para Microserviços?
Em minha opinião você só deveria migrar seu monolítico ou legado se você e sua equipe tiverem respostas positivas para as perguntas abaixo:
- Realmente preciso migrar?
- Minha equipe é qualificada ?
- Conhecem o mínimo de DDD (Domain Drive Design)?
- Tenho algum domínio sobre a cultura DevOps?
- Sabemos como centralizar os logs dos microserviços
- Sabemos como descobrir quais microserviços estão on-line
- Como vamos fazer para controlar todas as configurações de sistemas e ambientes?
- Como vamos escalar a aplicação?
- Como vamos controlar quais sistemas estão fora Os que caíram por algum problema?
- Como vamos monitorar os erros?
- Como vamos monitorar funcionalidades que são mais utilizadas?
- Sabemos testar sistemas de microserviços
Caso você e sua equipe respondam de modo positivo as perguntas acima, basta partir para a escolha de um padrão para migração.
Um dos mais conhecidos é o padrão estrangulador ou Strangler Pattern que orienta a substituição incremental de partes especificas de suas funcionalidades por novos serviços e aplicativos.
O estrangulamento de software é o conceito que prega a transformação gradual de sistemas legados. Em um mundo de microserviços esta pode ser uma técnica útil para quebrar o sistema legado e migrar para a arquitetura de microserviços.
Uma última dica deste primeiro artigo é a leitura e entendimento do manifesto “The Twelve-Factor App” ou os Doze Fatores, este manifesto descreve as boas praticas para serem seguidas na construção de sistemas distribuídos. Mais informações sobre esse manifesto neste link.
Bom por enquanto é isso, no próximo artigo (parte 2) vou falar sobre Api Gateway, diferenças entre Api Gateway e Api Manager, como trabalhar com autenticação em microserviços e também sobre comunicação (filas).
Espero ter transmitido conhecimento e gostaria de receber feedbacks deste artigo ou assuntos a incluir, entendo que o mundo de microserviços é grande e ainda não tive a experiência real de implementar essa arquitetura.
Se gostou e ajudou de alguma forma dá uma curtida ae e comenta se for possível!