O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Preparando sua arquitetura para microservicos

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 40 Anúncio

Preparando sua arquitetura para microservicos

Baixar para ler offline

Palestra descrevendo de forma geral o processo para criar arquiteturas adequadas para micro-serviços e também para refatorar uma aplicação antiga para esta arquitetura.

Palestra descrevendo de forma geral o processo para criar arquiteturas adequadas para micro-serviços e também para refatorar uma aplicação antiga para esta arquitetura.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Preparando sua arquitetura para microservicos (20)

Anúncio

Mais recentes (20)

Preparando sua arquitetura para microservicos

  1. 1. Preparando sua arquitetura para Micro-Serviços
  2. 2. Bruno Pereira • Fundador e CEO da Rivendel Tecnologia • Construiu sua 1a API REST em 2007 na Globo.com • Cloud/DevOps desde 2009 • Atuando há muitos anos com times de Produto e Operações que buscam arquiteturas escaláveis e tolerantes a falhas
  3. 3. Sobre a Rivendel • Fundada há 4 anos, especializada em Cloud/DevOps • Parceiros AWS, Microsoft Azure e Google Cloud • Também experientes em OpenStack/CloudStack • Trabalha muito com Startups e também com Inovação/Digital em enterprises. • Suporta milhares de micro-serviços em Produção :) • 150+ clientes atendidos em 4 anos. Mais de 60 DevOps.
  4. 4. Micro-Serviços • Estilo de Arquitetura que usa componentes pequenos e com baixo acoplamento • Cada micro-serviço geralmente implementa uma pequena função de negócio que compõe aplicações maiores • Permitem o desacoplamento tecnológico com o desenvolvimento usando múltiplas linguagens e frameworks harmonicamente na arquitetura
  5. 5. Micro-Serviços
  6. 6. Micro-Serviços
  7. 7. Micro-Serviços
  8. 8. Então eu já devo começar minha aplicação com micro-serviços?
  9. 9. Startups/Inovação “Startups são organizações temporárias projetadas para buscar um modelo de negócios repetível e escalável” Steve Blank Premissa: se estamos inovando, ainda não conhecemos o modelo de negócios que dará certo (e se dará)
  10. 10. Startups/Inovação Enquanto você está validando seu produto com ciclos rápidos, é muito mais fácil e barato usar monolitos vs
  11. 11. Preparando sua aplicação para Micro-Serviços
  12. 12. Objetivos Gerais • Construir arquiteturas escaláveis horizontalmente • Arquiteturas tolerantes a falhas em múltiplos componentes • Gestão de Mudança e deploys sem dor
  13. 13. Desafios Comuns • Controle do Estado em instâncias individuais • Componentes que permitam aumentar linearmente a escrita • Alta disponibilidade geográfica • Processos de deploy mais leves e seguros
  14. 14. Controle de Estado em instâncias individuais • Sessões Web/HTTP • Uploads e gerenciamento de arquivos locais • Caches locais
  15. 15. Como resolver?
  16. 16. Controle de Estado em instâncias individuais • Sessões Web/HTTP • Repositório de sessão compartilhado: Memcached, Redis, DynamoDB, etc • Uploads e gerenciamento de arquivos locais • Sistema de arquivos distribuído e compartilhado: S3, Azure Blob, OpenStack Swift, GlusterFS, etc • Caches locais • Sistemas de cache distribuídos: memcached, redis, Infinispan, Elastic Search, etc
  17. 17. Componentes que aumentem linearmente a escrita • Bancos de dados relacionais são os vilões comuns • Capacidade de escrita limitada pela capacidade de 1 único nó • Topologias multi-master são raras e normalmente caras
  18. 18. Como resolver?
  19. 19. Componentes que aumentem linearmente a escrita • Usar outros tipos de bancos de dados em conjunto com o relacional • Muitos bancos NoSql suportam particionamento: CAP Theorem • Implementar o máximo de processamento assíncrono, com abordagens de retentativas e capacidade de controlar a vazão
  20. 20. Alta disponibilidade geográfica • Falhas em datacenters individuais são comuns • Falhas em componentes individuais são ainda mais comuns • Cada vez mais precisaremos de arquiteturas distribuídas de alto volume
  21. 21. Como resolver?
  22. 22. Alta disponibilidade geográfica • Falhas em datacenters individuais são comuns • Topologias multi-datacenter, com nuvens públicas ou híbridas • Falhas em componentes individuais são ainda mais comuns • Privilegiar componentes de software que permitam replicação distribuída e preferencialmente sharding • Cada vez mais precisaremos de arquiteturas distribuídas de alto volume • Avaliar o uso de componentes clusterizáveis e sem limitações de armazenamento, escrita e leitura
  23. 23. Inspiração - 12 Factor App
  24. 24. I - Base de Código • Base de código em repositórios independentes para cada micro- serviço e com Pipelines independentes
  25. 25. II - Dependências • Declare e isole as dependências • Matriz de resiliência
  26. 26. III - Configurações • Gerência de configuração fácil de automatizar e manter
  27. 27. IV - Serviços de Apoio • Tratar os serviços de apoio também como micro-serviços e dependências desacopladas
  28. 28. V - Build, Release, Run • Pipelines com etapas distintas e bem granulares
  29. 29. VI - Processos • Execute a aplicação como um ou mais processos que não armazenam estado • Infraestrutura imutável
  30. 30. VII - Vínculo de porta • Exporte serviços fazendo bindings nas portas • Usar sempre DNS para permitir indireção e a melhor resolução
  31. 31. VIII - Concorrência • Dimensione por um modelo de processo • Testes de carga validam capacidade do processo e o quanto a arquitetura cresce linearmente aumentando as unidades • Ninguém mais precisa de Appliance de Teste de carga :)
  32. 32. IX - Descartabilidade • Maximizar a robustez com inicialização e desligamento rápido • Ouvi falar em Containers??
  33. 33. X - Dev/Prod Semelhantes • Mantenha os ambientes o mais próximos possível • Infrastructure as Code :)
  34. 34. XI - Logs • Trate Logs como fluxo de eventos • Centralizadores de logs permitem escalabilidade horizontal e melhor visibilidade
  35. 35. XII - Processos Admin • Ferramentas de administração separadas em processos pontuais
  36. 36. Como chegar lá?
  37. 37. Visão Geral do processo • Automação em Ops: provisionamento de ambientes automatizado e versionado • Continuous Integration/Deploy: controle fino processo de build, integração e deploy de cada aplicação em cada ambiente • Orquestração: tipicamente um orquestrador gerencia todo o ciclo de vida de containers
  38. 38. Considerações Adicionais • Autenticação/Autorização especialmente para micro-serviços expostos na internet • Web Application Firewalls são recomendados • API Gateways também • Service Discovery: normalmente resolvido pelo orquestrador • Monitoramento através de health checks ricos e métricas de negócio
  39. 39. Cloud + Private PaaS
  40. 40. contato@rivendel.com.br Obrigado!

×