O documento discute a preparação de arquiteturas para micro-serviços, abordando desafios como controle de estado, escalabilidade e disponibilidade. Ele também apresenta princípios como automação, integração contínua e orquestração de containers para evoluir aplicações monolíticas para arquiteturas baseadas em micro-serviços de forma gradual.

1. Preparando sua arquitetura para
Micro-Serviços

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. 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. 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. Micro-Serviços

6. Micro-Serviços

7. Micro-Serviços

8. Então eu já devo começar minha
aplicação com micro-serviços?

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. Startups/Inovação
Enquanto você está validando seu produto com ciclos
rápidos, é muito mais fácil e barato usar monolitos
vs

11. Preparando sua aplicação
para Micro-Serviços

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. 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. Controle de Estado em instâncias individuais
• Sessões Web/HTTP
• Uploads e gerenciamento de arquivos locais
• Caches locais

15. Como resolver?

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. 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. Como resolver?

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. 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. Como resolver?

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. Inspiração - 12 Factor App

24. I - Base de Código
• Base de código em repositórios independentes para cada micro-
serviço e com Pipelines independentes

25. II - Dependências
• Declare e isole as dependências
• Matriz de resiliência

26. III - Configurações
• Gerência de configuração fácil de automatizar e manter

27. IV - Serviços de Apoio
• Tratar os serviços de apoio também como micro-serviços e
dependências desacopladas

28. V - Build, Release, Run
• Pipelines com etapas distintas e bem granulares

29. VI - Processos
• Execute a aplicação como um ou mais processos que não
armazenam estado
• Infraestrutura imutável

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. 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. IX - Descartabilidade
• Maximizar a robustez com inicialização e desligamento rápido
• Ouvi falar em Containers??

33. X - Dev/Prod Semelhantes
• Mantenha os ambientes o mais próximos possível
• Infrastructure as Code :)

34. XI - Logs
• Trate Logs como fluxo de eventos
• Centralizadores de logs permitem escalabilidade horizontal e
melhor visibilidade

35. XII - Processos Admin
• Ferramentas de administração separadas em processos pontuais

36. Como chegar lá?

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. 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. Cloud + Private PaaS

40. contato@rivendel.com.br
Obrigado!