Microsserviços – Parte I

Este texto é de James Lewis e Martin Fowler, disponível em: http://martinfowler.com/articles/microservices.html


O termo “Arquitetura de Microsserviço” surgiu no últimos anos para descrever uma forma particular de desenhar aplicações de software como conjuntos de serviços implantados independentemente. Não há uma definição precisa desse estilo de arquitetura, mas há características comuns na organização de capacidades de negócio, implantação automatizada, inteligência nos endpoints, e controle descentralizado de linguagens e dados.

Conteúdo:

“Microsserviços” – mais um termo novo nas ruas abarrotadas da arquitetura de software. Mesmo que a nossa inclinação seja passar por essas coisas com um relance desdenhoso, essa terminologia descreve um estilo de sistemas de software que achamos cada vez mais atraente. Vimos tantos projetos usando esse estilo nos últimos anos, e os resultados foram positivos até agora, tanto que alguns colegas adotaram como o estilo padrão para construir aplicações corporativas. Tristemente, no entanto, não há muita informação que defina o estilo e como fazê-lo.

Em resumo, o estilo arquitetural de microsserviço [1] é uma abordagem para desenvolver uma única aplicação como um conjunto de pequenos serviços, cada um rodando em seu próprio processo e se comunicando com mecanismos leves, normalmente com uma API HTTP. Esses serviços são construídos em torno de capacidades de negócio e implantados independentemente por um mecanismo automatizado. Há um mínimo de gerenciamento centralizado dos serviços, os quais podem ser escritos em linguagens de programação diferentes e usar tecnologias diferentes de armazenamento de dados.

Para explicar esse estilo, é útil compará-lo com o estilo monolítico: uma aplicação monolítica construída como uma única unidade. As aplicações corporativas são construídas comumente em três partes: uma interface de usuário (client-side) constituída por páginas HTML e javascript rodando em um navegador de internet na máquina do usuário; um banco de dados, constituído de várias tabelas inseridas em um sistema de gerenciamento de bancos de dados, normalmente relacional, e uma aplicação no servidor. A aplicação do servidor vai tratar as requisições HTML e executar a lógica do domínio, recuperar e atualizar os dados no banco, e selecionar e popular as visões HTML a serem enviadas para o navegador. Essa aplicação do servidor é um monolito – um único executável lógico [2]. Qualquer mudança no sistema envolve construir e implantar uma nova versão da aplicação do servidor.

O servidor monolítico é a abordagem natural para construir um sistema desse tipo. Toda a sua lógica para tratar uma requisição roda em um único processo, permitindo que você use as funcionalidades básicas da sua linguagem para dividir a aplicação em classes, funções e namespaces. Com algum cuidado, você pode rodar e testar a aplicação no laptop do desenvolvedor, e usar o pipeline de implantação para garantir que as mudanças são propriamente testadas e implantadas na produção. Você pode escalar horizontalmente o monolito rodando várias instâncias atrás de um balanceador de carga.

As aplicações monolíticas pode ser bem sucedidas, mas as pessoas se sentem cada vez mais frustradas com elas – especialmente quando mais aplicações são implantadas na nuvem. Ciclos de mudanças ficam amarrados – uma mudança feita em uma pequena parte da aplicação requer que o monolito inteiro seja reconstruído e implantado. Com o tempo, fica cada vez mais difícil manter uma boa estrutura modular, tornando mais difícil fazer com que as mudanças em um módulo só afetem esse módulo. Escalar requer escalar a aplicação inteira, em vez de apenas as partes que requerem mais recursos.

Essas frustrações levaram ao estilo arquitetural de microsserviços: construir aplicações com conjuntos de serviços. Além do fato de que serviços são implantáveis e escaláveis independentemente, cada serviço também provê uma fronteira modular firme, e permite que diferentes serviços sejam escritos em diferentes linguagens de programação. Eles também podem ser gerenciados por equipes diferentes.

Não alegamos que o estilo de microsserviços seja novo ou inovador, suas raízes retomam desde os princípios do Unix. Mas achamos que poucas pessoas consideram a arquitetura de microsserviços, e que muitos desenvolvimentos de software seriam melhores se a usassem.


[1] O termo “microsserviço” foi discutido em um workshop de arquitetos de software perto de Veneza em maio de 2011 para descrever o que os participantes viram como um estilo arquitetural comum que muitos estavam explorando recentemente. Em maio de 2012, o mesmo grupo decidiu que “microsserviço” era o termo mais adequado. James apresentou algumas dessas ideias como um caso de estudo em março de 2012 no 33rd Degree na Cracóvia em Microsserviços – Java à moda Unix, assim como Fred George quase na mesma época. Adrian Cockroft no Netflix, descrevendo sua abordagem como “SOA refinado”, foi pioneiro no estilo na escala web, assim como muitos outros mencionados no seu artigo – Joe Walnes, Dan North, Evan Botcher e Graham Tackley.

[2] O termo “monolito” é usado pela comunidade Unix há algum tempo. Aparece no A Arte da Programação Unix para descrever sistemas que ficam muito grandes.

Anúncios
Marcado com: , , ,
Publicado em Microsserviços

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: