A arquitetura de micros serviços surgiu nos últimos anos para descrever uma maneira específica de desenvolver software como um conjunto de serviços com deploy independente. Vem se tornando o estilo padrão para o desenvolvimento de aplicativos corporativos.
Trata-se de uma abordagem em que cada serviço executa seu próprio processo e se comunica através de mecanismos leves, muitas vezes em uma API com recursos HTTP. Esses serviços são organizados de acordo a segregação do negócio e funcionam através de mecanismos de deploy independentes totalmente automatizados. Há o mínimo possível de gerenciamento centralizado desses serviços. Por terem fronteiras de acoplamento bem definidas podem ser escritos em diferentes linguagens de programação e utilizar diferentes tecnologias de armazenamento de dados.
Aplicativos corporativos geralmente são construídos em três partes principais: a interface de usuário do lado do cliente (que consiste em páginas HTML e JavaScript executadas em um navegador na máquina do usuário) um banco de dados (que consiste em muitas tabelas inseridas em um sistema de gerenciamento de banco de dados comum, geralmente relacional), e um aplicativo do lado do servidor. Este último lida com as solicitações HTTP, executa a lógica do domínio, recupera e atualiza dados do banco de dados, e seleciona e preenche as visualizações HTML a serem enviadas para o navegador. Esse aplicativo do lado do servidor é monolítico, um executável lógico único. Qualquer alteração envolve a compilação completa e deploy de todo o sistema.
Aplicativos monolíticos podem funcionar bem, entretanto cada vez mais as instituições estão demandando ciclo de alterações do sistema mais rápidos, deploys específicos com alterações pontuais de código, bem como maior escalabilidade horizontal. No monolito uma pequena alteração em uma parte do sistema geralmente requer que todo o aplicativo seja compilado e deploy de todas as funcionalidades. Além disto escalar requer várias instancias da aplicação, o que exige mais recursos de infraestrutura.
A abordagem de microserviços tem sido usada para endereçar estas questões. Não se trata de uma ideia nova de arquitetura, mas um princípio de design já utilizado no Unix. Diferentemente das aplicações monolíticas basicamente os aplicativos são organizados como um conjunto de serviços responsabilidade bem definida, com deploy independente, que podem ser escritos em linguagens diferentes, e que podem ter sua base de dados individuais. Estas características permitem escalabilidade horizontal daquelas funcionalidades específicas representadas por serviços. Diferentemente da abordagem monolítica onde a aplicação precisa instanciada N vezes atrás de um balanceador de carga, com microservicos apenas as instâncias de serviços específicos precisam ser replicadas, melhorando a eficiência na alocação dos recursos de infraestrutura.
Benefícios abordagem de Microserviços:
- Viabiliza evolução contínua da tecnologia do serviço (GUI, I/O, Linguagem)
Uma vez que o sistema foi quebrado em partes individualizadas, e com responsabilidade única e bem definida, a evolução fica restrita ao serviço. É a estratégia “dividir para conquistar”. Com menos código as investidas evolutivas ou de refatoração (funcionais e tecnológicas) podem gerar resultados mais rapidamente sem comprometer todo o sistema (ex. Entity Spaces para Entity Framework da Microsoft, SQL Server para SAP HANA, WebForms para DTA ou Aurelia). - Permite escalabilidade horizontal eficiente
Ter um banco de dados separado (ou conjunto de tabelas específicas) aumenta a eficiência da escalabilidade horizontal, pois deixa de haver um ponto central de gargalos. - Possibilita escalabilidade por decomposição funcional
Na arquitetura de microservicos é possível escalar funcionalidades específicas de acordo com a necessidade do negócio e para um período desejado pelo incremento de instancias de serviços consumidores específicos. Além disto cada serviço pode ser instalado em hardware apropriado à sua característica particular de consumo de recursos (ex. CPU, Memória, I/O). - Menor ciclo de build, feedbacks mais rápidos (devOps)
Ter um “pedaço” menor e independente de código gera agilidade no ciclo de deploy contínuo de DevOps, pois não é necessário carregar todo o restante dos serviços juntos, mas apenas o que foi alterado. - Menor custo de on-boarding de desenvolvedores novos
Um microserviço representa uma parte isolada de um sistema, por isto é conciso e mais fácil de ser compreendido por um recém contratado. Ainda é possível organizar a equipe em times pequenos de especialistas cada qual zelando pela qualidade e estabilidade do seu. - Facilita gerenciamento de dependências
Com a abordagem de microserviços as dependências precisam ser respeitadas forçadamente pelos desenvolvedores, e o risco de implementação de acessos que quebrem a organização do sistema é menor. - Deploy não precisa ser “tudo ou nada”.
O deploy não precisa mais ser feita da aplicação completa, mesmo que a correção seja em uma funcionalidade bem simples no processamento. Com a abordagem de microservicos apenas o que foi alterado é enviado facilitando o trabalho de homologação do usuário final, e garantindo a integridade dos outros serviços.
Complexidades da abordagem de Microserviços:
- Complexidade de lidar com sistemas distribuídos
Os desenvolvedores precisam lidar com a comunicação eficiente entre os serviços escolhendo se esta será síncrona ou assíncrona, bem como lidar com o controle transacional dos processos. - Coordenação das equipes de desenvolvimento
Na implementação de funcionalidades que abrangem mais de um serviço é necessário um planejamento definindo uma ordenação das alterações entre as equipes.
Apresentados os benefícios e complexidades da abordagem de microserviços para aplicações que necessitem de escalabilidade e manutenção tecnológica, como uma ou aplicação SaaS, esta é geralmente a escolha certa. Sites conhecidos, tais como eBay, Amazon.com, Groupon e Gilt evoluíram de uma arquitetura monolítica para uma arquitetura de microservices e se apresentam como casos de sucesso.
