Vantagens e desvantagens de uma arquitetura microservices
•
21 gostaram•7,195 visualizações
Este documento discute as vantagens e desvantagens de uma arquitetura de microserviços. As principais vantagens incluem a capacidade de implantar serviços independentemente, permitindo entregas contínuas mais rápidas. As principais desvantagens incluem a complexidade operacional adicional e a consistência eventual de dados entre serviços. O documento fornece dicas para lidar com desafios como integração, diversidade tecnológica e segurança.
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Vantagens e desvantagens de uma arquitetura microservices
Semelhante a Vantagens e desvantagens de uma arquitetura microservices (20)
Vantagens e desvantagens de uma arquitetura microservices
- 1. Fábio Rosato fabio.rosato@sensedia.com @frosato Vantagens e desvantagens de uma arquitetura microservices
- 2. Fábio Rosato Professional Services Manager fabio.rosato@sensedia.com @frosato
- 3. SOA, Microservices e APIs Projetos bacanas e desafiadores Plataformas sensacionais Headquarter em Campinas, escritórios em SP, Rio e EUA
- 5. Agenda Cenário Estratégia de evolução Dicas Vantagens e desvantagens
- 6. Cenário
- 8. Hype
- 9. Hype?
- 10. Cloud Domain- driven design Service- oriented architecture Continuous delivery Elementos chaves para a ascensão dos microservices…
- 14. Application #1 Application #2 Application #3 Application #n Cenário Real
- 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. Evolução
- 18. http://www.martinfowler.com/bliki/StranglerApplication.html Strangler Application Application #1 Strangler Application 1
- 19. http://www.martinfowler.com/bliki/StranglerApplication.html Application #1 Strangler Application Strangler Application1
- 20. Strangle Application Domínios e sub-domínios2 Conceitos de negócio Bounded Context Domain Driven Design Contexto A Contexto B
- 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. Cultura Devops5
- 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. Dicas
- 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. 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. 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. 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. 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. 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. 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. 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. Vantagens e desvantagens benefícios e consequências
- 35. Módulos com Fronteiras Fortes
- 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. Distribuição
- 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
- 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
- 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
- 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
- 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
- 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. 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. Obrigado!
- 51. Fábio Rosato fabio.rosato@sensedia.com @frosato www.slideshare.net/frosato/ Vantagens e desvantagens de uma arquitetura microservices