Vantagens e desvantagens de uma arquitetura microservices

1.973 visualizações

Publicada em

A demanda cada vez maior por agilidade, inovação e escalabilidade das soluções digitais tem impulsionado a adoção da arquitetura baseada em microservices. Os benefícios desta abordagem são reais e significativos, mas esse estilo arquitetural traz uma série de novos desafios.

Nesta apresentação, vamos fazer um mergulho profundo a partir de exemplos detalhados sobre as vantagens e desvantagens dessa abordagem arquitetural, como por exemplo:

Explorar como realizar a decomposição funcional e como definir taxonomias e granularidades adequadas para os microservices;

Como solucionar problemas arquiteturais como Client-side service discovery e Server-side service discovery, invocação, logging e monitoramento;

Definir protocolos de comunicação (HTTP, AMQP e Websocket) de forma minimizar a latência e lidar com outros requisitos não funcionais;

Como atacar questões de replicação de dados e regras de negócio e dados;

Design Patterns para problemas arquiteturais recorrentes;
Como conduzir a operação e evolução de um sistema nesta abordagem.

Publicada em: Software

Vantagens e desvantagens de uma arquitetura microservices

  1. 1. Fábio Rosato fabio.rosato@sensedia.com @frosato Vantagens e desvantagens de uma arquitetura microservices
  2. 2. Fábio Rosato Professional Services Manager fabio.rosato@sensedia.com @frosato
  3. 3.  SOA, Microservices e APIs  Projetos bacanas e desafiadores  Plataformas sensacionais  Headquarter em Campinas, escritórios em SP, Rio e EUA
  4. 4. Alguns Clientes
  5. 5. Agenda Cenário Estratégia de evolução Dicas Vantagens e desvantagens
  6. 6. Cenário
  7. 7. Microservices está no Hype
  8. 8. Hype
  9. 9. Hype?
  10. 10. Cloud Domain- driven design Service- oriented architecture Continuous delivery Elementos chaves para a ascensão dos microservices…
  11. 11. Fazendo as comparações...
  12. 12. WEB UI EMAIL Adapter URA Adapter Pagamentos Adapter Clientes Pacotes Reservas Avaliações Recomendações PagamentosNotificações DB Adapter REST API Monolítica Arquitetura http://alistair.cockburn.us/Hexagonal+architecture Plataforma de Viagem
  13. 13. Clientes Pacotes Reservas Avaliações Recomendações Pagamentos Notificações Microservices Arquitetura Pagamentos Adapter URA Adapter EMAIL Adapter API Gateway REST API REST API REST API REST API REST API REST/AMPQ API REST/AMQP API WEB UI Plataforma de Viagem
  14. 14. Application #1 Application #2 Application #3 Application #n Cenário Real
  15. 15. Cenário Real Application #1 Application #2 Application #3 Application #n Aplicações moníliticas nem sempre modularizadas Comunicação interna e externa caso-a-caso sem padrão definido Ciclos de entrega longos (meses) Dificuldade para evoluir e implantar novas tecnologias Obsolecência tecnológica Grandes bases compartilhadas √ √ √ √ √ √
  16. 16. Evolução
  17. 17. Manter e evoluir!
  18. 18. http://www.martinfowler.com/bliki/StranglerApplication.html Strangler Application Application #1 Strangler Application 1
  19. 19. http://www.martinfowler.com/bliki/StranglerApplication.html Application #1 Strangler Application Strangler Application1
  20. 20. Strangle Application Domínios e sub-domínios2  Conceitos de negócio  Bounded Context  Domain Driven Design Contexto A Contexto B
  21. 21. Strangle Application Microservices 3 Microservice #n Database HTTP/REST
  22. 22. Governança 4  Definições de padrões mínimos principalmente na fronteira externa da aplicação (contexto de conexão)  Informações para tomadas de decisões em tempo de design e runtime  Importante na medida certa!
  23. 23. Cultura Devops5
  24. 24. Cultura Devops5  Times de desenvolvimento e operação atuando juntos  Time de desenvolvimento criando scripts de automação  Ciclos de entregas mais curtos (diários)
  25. 25. Dicas
  26. 26. Alguns Fatores • Microservices não são necessariamente mais fáceis de escalar • Você pode aplicar mecanismos distintos de segurança para os microservices
  27. 27. Integração • Acertar a integração é o aspecto mais importante da tecnologia associada a microservices. • Prefira integrações direitas para aumentar a autonomia • Evitar de fazer alterações que mudem o contrato
  28. 28. Integração • Mantenha sua tecnologia de APIs agnóstica (REST HTTP / AMQP) • Faça seus serviços simples para os consumidores – De nada adianta ter um microservice bacana se ele é difícil de ser utilizado • Esconda os detalhes de implementação internos
  29. 29. Composição - Coreografia Microservice #1 Microservice #2 Microservice #n Banco Relacional Documentos Key/Store Data Base API API API Microservice #c Camada de coreografia Camada de dados
  30. 30. DRY – don’t repeat yourself Código repetitivo você pode colocar em um componente (library), mas cuidado! Evoluções nos componentes impactam todos os microservices que dependem deles.
  31. 31. Client Library ou SDKs • Criar um client library facilita o consumo do microservices e mitiga o uso indevido • O problema é a diversidade tecnológica e a manutenção dos Client Library • Cuidado: não deixe vazar lógicas que deveriam estar no servidor para dentro do client da API. (Acoplamento)
  32. 32. Uso de múltiplas versões de serviços concorrentes • Manter instâncias de serviços novos e velhos e rotear para um ou outro – Utilize nas situações que alterar os consumidores mais velhos tem um custo muito alto – Ou em situações de um curto período de tempo com implantações blue/greenn • Coexistir diferentes endpoint
  33. 33. Architectural Safety • Proteja-se dos serviços laranjas podres: aqueles que estragam todos os outros • Os butterflies são potencialmente mais danosos. Monitore! Microservice #1 Microservice #2 Microservice #3REST API REST API REST API Microservice #4 REST API butterfly
  34. 34. Vantagens e desvantagens benefícios e consequências
  35. 35. Módulos com Fronteiras Fortes
  36. 36. Fortes Fronteiras de módulos • Microservices – A dissociação modular de microservices funcionam melhor porque os limites dos módulos são uma barreira para referências entre os módulos – Você até pode ter um grande acoplamento com microservices, mas o esforço certamente será maior – O desafio é definir o domínios e sub-domínios – Funciona bem para equipes isoladas (esquadrões) • Monolítica – É perfeitamente possível ter limites firmes de módulos em sistemas monolíticos, mas requer disciplina e acompanhamento – É mais fácil bular as fronteiras, e esse atalho feito amplamente minam a estrutura modular do sistema e o tornam um “lixo”
  37. 37. Distribuição
  38. 38. Distribuição • Grande desvantagem: – Ser muito distribuído – Desempenho • Latência de rede • Custo de serialização e deserialização • Falácias da computação distribuída* • Dicas (Mitigações): – Aumentar a granularidade das chamadas – Usar chamadas assíncronas • melhoria de desempenho • Porém é: – Difícil de acertar – Difícil de depurar – Confiabilidade • Programa-se para o fracasso e suas consequências * Falácias da computação distribuída: http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
  39. 39. Implantação Independente
  40. 40. Implantação Independente • Simplicidade – A unidade microservice é mais simples, em tese é mais fácil de implantar – Problemas no microservice, se ele for bem desenhado, tendem a propagar menos impacto no ambiente todo • Scripts de automatização – Quase um pré-requisito: é difícil ser ágil fazendo implantações manuais • Entrega contínua – Redução do tempo de ciclo entre uma ideia e o software em execução – Respostas mais rápida as mudanças do mercado – Vantagem competitiva • Feedbacks mais rápidos – E ciclo de correções mais rápidos
  41. 41. Consistência Eventual #sqn
  42. 42. Consistência Eventual • Causa: descentralização de dados da abordagem • É um efeito colateral para garantir a disponibilidade – Tradeoff entre disponibilidade e consistência dos dados • Cache é importante! – Invalidação de cache é difícil – Dica: Utilize eventos para invalidar cache • Tolerância a inconsistência (teorema de CAP) – Consistency – Availability – Tolerance to network partitions http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
  43. 43. Diversidade Tecnológica
  44. 44. Diversidade Tecnológica • Liberdade – Fortalece a as escolhas independentes de tecnologia – Algumas linguagens e tipos de armazenamento de dados são mais adequados para determinados tipos de problemas – O objetivo é resolver o problema através das escolhas mais inteligentes – Experimentações de novas tecnologias • Padronização – As questões de interface (HTTP/REST, AMQP), ferramentas de ambiente e monitoração • Bibliotecas – Mais controle no versionamento de bibliotecas
  45. 45. Complexidade Operacional
  46. 46. Complexidade Operacional • Produtividade – Para algumas equipes pode ser um fardo que mina a produtividade • Tensão – Pequenos módulos independentes e implantações rápidas traz uma pressão adicional para operação • Agilidade – É praticamente impossível garantir um ambiente operacional de dezenas de serviços sem automação • Responsabilidade – A uma tendência da complexidade subir para a camada de interconexões dos serviços • Skills e Ferramentas – Requer algumas competências, habilidades e ferramental • Colaboração – Introduzir uma cultura DevOps: uma maior colaboração entre os desenvolvedores, operações e pessoal de infraestrutura
  47. 47. Complexidade Operacional
  48. 48. Application #1 Application #2 Application #3 Application #n Cenário Inicial - pós adoção de microservices Microservice #1 Microservice #2 Microservice #n Banco Relacional Documentos Key/Store Data Base REST API REST API REST API API Gateway
  49. 49. API Gateway Service aggregation Rate Limiting Monitoring & Alerts Authentication Models Policy Enforcement Exception handling Analytics on API Consumption Endereça questões como: Atenção: Não despreze a latência Gateway não resolve tudo mas ajuda em várias questões não funcionaisRate Limiting Policy JSON Threat Policy Payload Size Policy IP Filtering Policy
  50. 50. Obrigado!
  51. 51. Fábio Rosato fabio.rosato@sensedia.com @frosato www.slideshare.net/frosato/ Vantagens e desvantagens de uma arquitetura microservices

×