Os sistemas distribuídos (coleção de computadores independentes entre si que se apresenta ao usuário como um sistema único e coerente) se tornaram mais granularizados nos últimos 10 anos, mudando das aplicações monolíticas densamente codificadas para pequenos, e auto-contidos, microserviços. Muitas organizações entenderam que abraçar arquiteturas refinadamente granulares de microserviços pode oferecer software mais rápido, e pode abraçar novas tecnologias. Mas o que é a arquitetura dos microserviços, e de onde surgiu este tipo de arquitetura?
O mundo da arquitetura dos sistemas de informação esteve dominado até recentemente por um conjunto de conceitos: domain-driven design; continuous delivery; on-demand virtualization; infrastructure automation; small autonomous teams; systems at scale. Os microserviços surgiram deste mundo. Eles (microserviços) não foram inventados ou descritos antes dos fatos; eles emergiram como uma tendência, ou um padrão, de uso no mundo real. Mas eles somente passaram a existir por causa de tudo que veio antes (Newman, 2015).
Para explicar o estilo arquitetural do microserviço, é útil compará-lo ao estilo monolítico, ou seja, uma aplicação monolítica construída como uma única unidade (frequentemente aplicada para resolver problemas de negócios, tais como ERP, CRM, HCM)(Figura 1 à frente). Aplicações empresariais são frequentemente construídas a partir de três partes principais: uma interface de usuário do lado do cliente (consistindo de páginas HTML e de javascript rodando em um browser na máquina do usuário), um banco de dados (consistindo de muitas tabelas inseridas em um sistema de gerenciamento de banco de dados comum, usualmente relacional), e uma aplicação do lado do servidor. A aplicação do lado do servidor irá lidar com solicitações HTTP, executar lógica de domínio, recuperar e atualizar dados do banco de dados, e selecionar e popular HTML vistas para serem enviadas para o browser. Esta aplicação do lado do servidor é um monolítico – um único logicamente executável. Qualquer mudança para o sistema envolve construir e empregar uma nova versão da aplicação do lado do servidor (Lewis and Fowler, 2014).
Este servidor monolítico é um modo natural de enfocar tal sistema. Toda a lógica para lidar com uma solicitação opera em um único processo, permitindo que você use as características básicas de sua linguagem para dividir a aplicação em classes, funções, e namespaces (nomes de espaços). Com algum cuidado você pode rodar e testar a aplicação no laptop do desenvolvedor, e usar um deployment pipeline (linha de empregabilidade) para assegurar que mudanças são adequadamente testadas e empregadas na produção. Você pode escalar horizontalmente o monolítico ao rodar muitas instâncias por trás de um load-balancer (balanceador de carregamento)(Lewis and Fowler, 2014).
Aplicações monolíticas podem ter sucesso, mas as pessoas estão crescentemente sentindo frustrações com elas – especialmente à medida que mais aplicações são empregadas na cloud. Ciclos de mudanças são combinados juntos – uma mudança feita numa pequena parte da aplicação requer que o monolítico inteiro seja reconstruído e re-empregado. Ao longo do tempo é frequentemente difícil manter uma boa estrutura modular, tornando difícil manter mudanças que devem somente afetar um módulo dentro daquele módulo. A escalagem requer escalonamento da aplicação inteira, mais do que as partes dela, o que requer mais recursos (Lewis and Fowler, 2014).
Estas frustrações levaram ao estilo arquitetural dos microserviços: construção de aplicações como serviços. Da mesma forma que os serviços são empregados e escalados independentemente, cada serviço também provê uma fronteira modular da empresa, permitindo mesmo que diferentes serviços sejam escritos em diferentes linguagens de programação. Os microserviços também podem ser gerenciados por diferentes equipes (Lewis and Fowler, 2014).
A arquitetura dos microserviços está bem alinhada com os movimentos em direção às ofertas de SaaS – Software as a Service - baseadas na Cloud (tratada no livro deste editor) e na Economia das APIs (discutida aqui na newsletter do dia 30/10/2016). De alguma forma, ela pode ser traçada com os primeiros dias da SOA- Service Oriented Architecture, com o foco na descoberta de serviços. O que mudou foi a proliferação de RESTful APIs (ver a newsletter do dia 30/10/2016 acima referida) e a popularidade dos serviços híbridos de integração de serviços da SaaS Cloud, mais a disponibilidade de plataformas virtualizadas e containers, junto também com ferramentas avançadas para gerenciá-los (Jarman, 2015).
Esse movimento de integração/convergência foi recentemente tratado pela empresa Gartner, a qual aponta para o futuro dos microservices (o mais novo hype topic segundo ela). O que Gartner está dizendo aos seus seguidores é que os sistemas hyper-converged são okay para serem aplicados hoje, e estão destinados a se desenvolverem nas infraestruturas compostas de microserviços em 2020 (ver Figura 2 à frente).
No Brasil o tema dos microserviços vem despertando grande atenção, e é possível observar a existência de empresas como a Sensedia, baseada em Campinas/SP, a qual que vem prestando relevantes serviços na promoção e no desenvolvimento dessa promissora arquitetura!
Se sua empresa, organização ou instituição deseja saber mais sobre a economia dos microserviços, fique a vontade para nos contatar!
Referências
Jarman, Peter (2015). Microservices: a New Application Paradigm. https://www.infosys.com/digital/insights/Documents/microservices-application-paradigm.pdf
Lewis, James and Martin Fowler. Microservices. http://martinfowler.com/articles/microservices.html
Newman, Sam (2015). Building Microservices: Designing Fine-Grained Systems. https://www.amazon.com/dp/B00T3N7XB4/ref=rdr_kindle_ext_tmb
