Transferir como PDF, PPTX
Carregado porFábio Rosato
Vantagens e desvantagens de uma arquitetura microservices
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
Vantagens e desvantagens de uma arquitetura microservices
- 1. Fábio Rosato fabio.rosato@sensedia.com @frosato Vantagens edesvantagens de uma arquitetura microservices
- 2. Fábio Rosato Professional ServicesManager fabio.rosato@sensedia.com @frosato
- 3. SOA, Microservicese APIs Projetos bacanas e desafiadores Plataformas sensacionais Headquarter em Campinas, escritórios em SP, Rio e EUA
- 4.
- 5. Agenda Cenário Estratégia de evolução Dicas Vantagense desvantagens
- 6.
- 7.
- 8.
- 9.
- 10. Cloud Domain- driven design Service- oriented architecture Continuous delivery Elementos chaves paraa ascensão dos microservices…
- 11.
- 12.
- 13.
- 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.
- 17.
- 18.
- 19. http://www.martinfowler.com/bliki/StranglerApplication.html Application #1 StranglerApplication Strangler Application1
- 20. Strangle Application Domínios e sub-domínios2 Conceitos de negócio Bounded Context Domain Driven Design Contexto A Contexto B
- 21.
- 22. Governança 4 Definiçõesde 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.
- 24. Cultura Devops5 Times dedesenvolvimento e operação atuando juntos Time de desenvolvimento criando scripts de automação Ciclos de entregas mais curtos (diários)
- 25.
- 26. Alguns Fatores • Microservicesnão são necessariamente mais fáceis de escalar • Você pode aplicar mecanismos distintos de segurança para os microservices
- 27. Integração • Acertar aintegraçã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 suatecnologia 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’trepeat 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 ouSDKs • 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últiplasversõ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-sedos 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 econsequências
- 35. Módulos com FronteirasFortes
- 36. Fortes Fronteiras demó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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 RateLimiting 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.
- 51. Fábio Rosato fabio.rosato@sensedia.com @frosato www.slideshare.net/frosato/ Vantagens edesvantagens de uma arquitetura microservices