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!