O desafio de implantar Arquitetura de Microsserviços
O conceito de arquitetura de microsserviços (ou microservices, em inglês) surgiu como uma forma de facilitar o trabalho dos desenvolvedores de software, em sua árdua busca pelo melhor produto para seus clientes.
E é claro, especialmente para empresas que desejam eficiência e produtividade aliadas à agilidade e redução de custos.
Hoje, os microsserviços podem ser inseridos dentro da estrutura de um negócio visando dinamizar as atividades e gerar flexibilidade, através da divisão de processos e fluxo rápido e integrado de informações.
Tudo isso também contribui para a descentralização dos serviços e permite que mais pessoas tenham acesso a soluções eficazes para resolver problemas semelhantes.
Na teoria, é bem simples: garanta que seus serviços estejam sendo expostos com boa granularidade, sem fortes dependências uns com os outros, e que cada serviço seja útil, com uma função clara e indivisível.
Na prática, isso pode gerar uma série de outras preocupações.
Então, nesse artigo vamos cair de cabeça em como implantar a Arquitetura de Microsserviços na sua empresa!
A Arquitetura de Microsserviços
Tradicionalmente, softwares são construídos como uma estrutura fechada com começo, meio e fim. Ou melhor, back-end e front-end.
Essa filosofia acaba gerando peças muito grandes (arquitetura monolítica), normalmente focadas em resolver grandes necessidades e problemas organizacionais. Se você quiser usar somente as funções que fazem gráficos do Excel para alguma outra aplicação, terá que abrir o Excel e carregar outras funcionalidades desnecessárias naquele momento.
A Arquitetura de Microsserviços, ao contrário das anteriores de Arquitetura Monolítica ou até SOA, destaca-se por explorar a ideia de granularidade, o que facilita a execução do próprio serviço e a adaptação às mudanças.
A ideia é dividir um determinado sistema em serviços acionáveis e modulares, de modo que a união de pequenas partes realize um trabalho maior. Assim, os microsserviços permitem a integração entre vários serviços e a inserção de vários componentes no sistema.
Além disso, você tem mais flexibilidade e poder de alterar funcionalidades que deram errado ou não estão funcionando bem, sem que seja necessário refazer partes inteiras de um sistema. Ou ainda, ter de jogar tudo fora porque a realidade da sua empresa mudou.
Assim, implantar a arquitetura de microsserviços gera mais agilidade!
Decompondo aplicações em serviços
A forma mais usual para escalar uma aplicação é executando várias cópias idênticas de aplicação (por meio de um balanceador de cargas), realizando um processo chamado decomposição, com a finalidade de resolver problemas comuns na arquitetura monolítica, implicando em que alguns serviços poderão ser muito pequenos enquanto outros serão significativamente maiores.
Com o conceito de três dimensões, é possível entender como os microsserviços são úteis no particionamento e escalabilidade de uma aplicação monolítica. Temos três eixos de escalabilidade:
- X: referente à escalabilidade horizontal, para ampliar a capacidade e disponibilidade da aplicação (cada servidor executa uma cópia idêntica do código);
- Z: semelhante à do eixo X, mas requer a presença de um componente que se responsabilize pelo roteamento das requisições ao servidor adequado;
- Y: é a terceira dimensão da escalabilidade, a horizontal, denominada decomposição funcional e é responsável por dividir a aplicação em uma série de serviços. A cada serviço corresponde um conjunto de funções (gerenciamento de pedidos, gerenciamento de clientes e assim por diante).
Lembrando que, enquanto o eixo Z divide elementos semelhantes, o eixo Y divide elementos distintos.
Implantar Microsserviços depende de um bom particionamento
A divisão, ou particionamento, do sistema deve ser bem elaborada, mas há abordagens que te ajudarão a implantar a arquitetura de microsserviços na estrutura do seu negócio.
Veja alguns tipos de particionamento que podem ser utilizados:
- Por verbos/casos de uso: o caso Checkout, por exemplo, em que um serviço de conclusão de pedidos, ou Checkout UI service, implementa a interface com as pessoas que usam o sistema.
- Por sinônimos/recursos: como exemplo, considere que, para gerenciamento do catálogo de mercadorias, a empresa pode ter o Catalog Service. Nesse caso, o serviço se responsabiliza por todas as atividades que envolvem os recursos/entidades relacionados.
O importante é que cada serviço possua poucas responsabilidades, de acordo com o Princípio de Responsabilidade Única (SRP, Single Responsibility Principle). Ou seja, um serviço exposto deve ter um único e claro papel dentro da arquitetura.
Se for o caso em que um serviço possui mais de uma responsabilidade, você deve aplicar algum particionamento, como citado acima.
As funcionalidades Unix constituem outro exemplo de modelagem de serviços, em que cada funcionalidade realiza somente uma operação definida (podendo, no entanto, ser combinada, por meio de shell script, com outras funcionalidades a fim de realizar atividades mais complexas). Ao longo dos anos, esse baixo acoplamento facilitou que diversas variações do sistema operacional fossem lançadas, como Ubuntu, Fedora, Solaris e tantas outras.
As vantagens da Arquitetura de Microsserviços
Implantar a arquitetura de microsserviços em sua empresa vai proporcionar diferentes benefícios para a estrutura do seu negócio:
- Os desenvolvedores usufruem de liberdade maior para o desenvolvimento de serviços de modo independente;
- Implantação automática através de ferramentas de integração contínua e código aberto, como Hudson, Jenkins e outras;
- O container web tem inicialização mais rápida;
- Possibilidade de utilizar códigos escritos em linguagens diferentes para diferentes serviços, usando uma “linguagem franca” para comunicação entre eles (como Json ou XML);
- Oportunidade para os desenvolvedores usarem as tecnologias mais atuais;
- Arquitetura de fácil compreensão e adaptável às mudanças, o que favorece o aprendizado, contribuindo para maior produtividade da equipe;
- Fácil ampliação e integração dos microsserviços com serviços terceirizados, através de APIs, por exemplo;
- Código organizado em função de capacidades de negócio, dando mais visão das ofertas e necessidades dos clientes;
- Mudanças necessárias poderão ser aplicadas somente sobre o serviço específico, sem necessidade de modificar todo o aplicativo. Atualizações de funcionalidades também passam a ser menos complexas;
- Gerenciamento otimizado das falhas (por exemplo, caso um serviço venha a falhar, os outros continuarão trabalhando).
Através dos microsserviços, é possível identificar falhas e gargalos com mais eficiência, visto que o particionamento favorece uma visão mais detalhada de cada serviço.
A adesão à Arquitetura de Microsserviços
Muitos consideram os microsserviços como uma maneira de entregar SOA por meio de serviços com alto nível de granularidade. Os microsserviços permitem desenvolver as capacidades de negócio, distribuindo-as e organizando-as de maneira funcional.
Trata-se de uma lógica que une tecnologia e negócios, focando em dar mais poder e dinamicidade para uma empresa.
Dessa forma, os microsserviços cumprem os objetivos de qualquer arquitetura, reduzindo também os custos de manutenção e criação. Nossa plataforma de API Management permite que grandes empresas tenham uma arquitetura ágil e segura. Se quiser saber mais, fica a vontade para falar com a gente.
E aí, o que pensa agora sobre essa Arquitetura? Confira também esse novo conteúdo sobre Event Driven Architecture.
Para mais informações sobre implantação de uma Arquitetura de Microsserviços, confira nosso Webinar gratuito sobre o assunto:
Confira também o vídeo do APIX com o tema “Trilha Técnica | Microservices boas práticas do campo de batalha”:
Oi Ricardo,
Gostei muito do seu artigo, mas gostaria de perguntar como nessa nova arquitetura, poderia se pensar na dependência de micro serviços de missão mais crítica. Ex.: Em uma loja on-line, caso o micro serviço de “calculo de frete” caia, ele pode não ser essencial e o sistema como um todo se encarrega de confirmar por email esse valor, no entanto o micro serviço de “cadastro de cliente” é essencial a qualquer pedido, se o mesmo cai, como lidamos com isso? Seria uma quebra prioritária como tratamos no sistema monólito?
Outra pergunta, ainda usando o exemplo acima, se temos o micro serviço de “cadastro de cliente”, todos os micro serviços que se relacionam com o mesmo teriam somente a referencia (tipo uma key) do mesmo? Ou cada um implementa sua “versão” da interface?
Caso haja algum link, mesmo que seja em inglês que você queira me indicar, estou muito curioso.
att