Microsserviços – Parte V

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

Sugiro começar por aqui: Microsserviços – Parte I


Gerenciamento de Dados Descentralizado

Decentralização do gerenciamento de dados se apresenta de inúmeras formas diferentes. No nível mais abstrato, significa que um modelo conceitual do mundo será diferente entre sistemas. Isso é um problema comum ao integrar uma grande empresa, a visão de vendas de um cliente será diferente da visão de suporte. Algumas coisas chamadas de “clientes” na visão de vendas podem nem aparecer na visão de suporte. As coisas que existem em comum podem ter atributos diferentes, ou pior, atributos em comum mas com semânticas diferentes.

Esse problema é comum entre aplicações, mas pode acontecer dentro das aplicações, particularmente quando a aplicação é dividida em componentes separados. Uma forma útil de pensar sobre isso é a noção tirada do Design Orientado a Domínio (Domain Driven Design, DDD) sobre Contexto Limitado. O DDD divide um domínio complexo em múltiplos contextos limitados e mapeia as relações entre eles. Esse processo é útil tanto para arquiteturas monolíticas quanto para microsserviços, mas há uma correlação natural entre serviço e fronteira do contexto que ajuda a esclarecer isso, e quando descrevemos as capacidades de negócio, reforçamos as separações.

Assim como descentraliza as decisões sobre modelos conceituais, os microsserviços também descentralizam as decisões sobre armazenamento de dados. Assim como as aplicações monolíticas preferem um só banco de dados para persistência de dados, empresas preferem um único banco de dados para uma gama de aplicações – muitas dessas decisões são orientadas pelos modelos de licenciamento dos fornecedores. Microsserviços preferem deixar que cada serviço gerencie seu próprio banco de dados, seja por diferentes instâncias da mesma tecnologia de banco de dados, ou seja por sistemas diferentes – uma abordagem chamada de Persistência Poliglota. Você pode usar persistência poliglota em um monolito, mas é mais frequente com microsserviços.

Decentralizar a responsabilidade dos dados entre microsserviços tem implicações no gerenciamento das atualizações. Uma abordagem comum para lidar com atualizações é usar transações que garantem consistência ao atualizar múltiplos recursos. Essa abordagem é geralmente usada com monolitos.

Usar transações como essa ajuda com a consistência, mas impõe um acoplamento temporal significativo, o que é problemático entre muitos serviços. As transações distribuídas são difíceis de implementar e, como consequência da arquitetura de microsserviços, enfatizam a coordenação sem transação entre serviços, com reconhecimento explícito de que a consistência pode ser apenas eventual e de que problemas são resolvidos por operações compensatórias.

Escolher gerenciar as inconsistências dessa forma é o novo desafio para muitos times de desenvolvimento, mas é um que comumente corresponde às práticas de negócio. Geralmente, os negócios lidam com certo grau de inconsistência para poder responder rapidamente à demanda, enquanto possuem algum tipo de processo para lidar com os erros. Essa troca vale a pena enquanto o custo de corrigir os erros é menor que a perda do negócio sob uma consistência maior.

Automação da Infraestrutura

Técnicas de automação da infraestrutura evoluiram muito nos últimos poucos anos – a evolução da nuvem e AWS em particular reduziram a complexidade operacional de construir, implantar e operar microsserviços.

Muitos dos produtos ou sistemas construídos com microsservios estao sendo construidos por times com grande experiência em Entrega Contínua e sua precursora, Integração Contínua. Os times construindo software dessa forma fazem grande uso das técnicas de automação da infraestrutura. Isso é ilustrado no pipeline de build mostrado abaixo.

Pipeline de build básico:

  1. Compilar, realizar testes unitários e funcionais, rodam na máquina de build
  2. Teste de aceitação, implantado na máquina de build
  3. Teste de integração, implantado no ambiente de integração
  4. Teste de aceitação do usuário, implantado no ambiente de testes de aceitação do usuário
  5. Teste de performance, implantado no ambiente de performance
  6. Implantação na produção

Como este artigo não é sobre Entrega Contínua, chamaremos a atenção a apenas algumas funcionalidades. Queremos a maior confiança possível de que o software está funcionando, então rodamos vários testes automatizados. A promoção de um software para o próximo passo no pipeline significa que automatizamos a implantação para cada novo ambiente.

Uma aplicação monolítica será construída, testada e empurrada por esses ambientes alegremente. Uma vez que você investiu automatizando o caminho para a produção para um monolito, implantar mais aplicações não espanta ninguém. Um dos objetivos da Entrega Contínua é deixar a implantação tediosa, então seja uma ou três aplicações, não importa se ainda for tediosa [12].

Deixe fácil fazer a coisa certa

Um efeito colateral que encontramos do aumento da automatização como consequência da entrega e implantação contínua é a criação de ferramentas úteis para ajudar os desenvolvedores e o pessoal de operação. Ferramentas para criar artefatos, gerenciar bases de código, manter serviços simples ou para adicionar monitoramento e logs são bem comuns. O melhor exemplo na web é provavelmente o conjunto de ferramentas de código aberto do Netflix, mas há outros, incluindo Dropwizard que usamos bastante.

Outra área onde vemos times usando vasta automatização da infraestrutura é no momento de gerenciar os microsserviços em produção. Em contraste com a afirmação acima de que, enquanto a implantação seja tediosa, não há muitas diferenças entre monolitos e microsserviços, o panorama operacional para cada um pode ser surpreendentemente diferente.


[12] Estamos sendo um pouco ingênuos aqui. Obviamente, implantar mais serviços, em topologias mais complexas, é mais difícil que implantar um monolito. Por sorte, os padrões reduzem essa complexidade – investimento em ferramentas ainda é uma necessidade.

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: