Dados e Microservices: lidando com bancos legados na era de serviços distribuídos

Sem dúvida a característica que causa maior perplexidade em Microservices é o "um banco de dados por Microservice". Entretanto a maioria das equipes não tem o privilégio de iniciar algo do zero: você sempre tem um banco de dados relacional legado para manter.

Como eu escolho qual parte do meu banco de dados devo separar? Como eu faço migrations com zero downtime? Como eu integro esses dados depois? O que é CQRS? Como uso? Participe dessa palestra para ter as respostas para muitas dessas perguntas!

Transcript

1. Dados e Microservices: Lidando com bancos legados na era de serviços distribuídos Edson Yanaga Director of Developer Experience @yanaga
2. Join developers.redhat.com 2 Java Champion Microsoft MVP
3. http://developers.redhat.com/promotions/ migrating-to-microservice-databases
4. “Now, every company is a software company” — Forbes
5. Join developers.redhat.com 5
6. DevOps & Microservices
7. Feedback Loop
8. Batch Size
9. Join developers.redhat.com 9 Janela de Manutenção
10. Zero Downtime
11. Join developers.redhat.com 11 Blue Green Deployments
12. Join developers.redhat.com 12 Deployment
13. Join developers.redhat.com 13 Deployment Proxy
14. Join developers.redhat.com 14 Blue Proxy Green
15. Join developers.redhat.com 15 Blue Proxy Green
16. Join developers.redhat.com 16 Blue Proxy Green
17. Join developers.redhat.com 17 Blue Proxy Green
18. Código é fácil, estado é difícil
19. E o meu banco de dados relacional?
20. Join developers.redhat.com 20
21. Zero Downtime Migrations
22. Compatibilidade Retroativa e Futura
23. Baby Steps = O menor Batch Size possível
24. Muitas linhas = Locks longos
25. Utilize shards em seus Updates
26. Join developers.redhat.com ALTER TABLE customers RENAME COLUMN wrong TO correct; 26
27. Join developers.redhat.com ALTER TABLE customers ADD COLUMN correct VARCHAR(20); UPDATE customers SET correct = wrong WHERE id BETWEEN 1 AND 100; UPDATE customers SET correct = wrong WHERE id BETWEEN 101 AND 200; ALTER TABLE customers DELETE COLUMN wrong; 27
28. Join developers.redhat.com 28 Cenários Adicionar uma Coluna Renomear uma Coluna Alterar o Tipo/Formato de uma Coluna Remover uma Coluna
29. Join developers.redhat.com 29 Adicionar uma coluna 1 ADD COLUMN 2 Código calcula o valor de leitura e escreve na nova coluna 3 Atualize os dados utilizando shards 4 Código lê e escreve na nova coluna
30. Join developers.redhat.com 30 Renomear uma Coluna 1 ADD COLUMN 2 Código lê da coluna antiga e escreve em ambas 3 Copiar os dados usando shards 4 Código lê da nova coluna e escreve em ambas 5 Código lê e escreva na nova coluna 6 Remover a coluna (mais tarde)
31. Join developers.redhat.com 31 Alterar o Tipo/Formato de uma Coluna 1 ADD COLUMN 2 Código lê da coluna antiga e escreve em ambas 3 Copiar os dados usando shards 4 Código lê da nova coluna e escreve em ambas 5 Código lê e escreva na nova coluna 6 Remover a coluna (mais tarde)
32. Join developers.redhat.com 32 Remover uma Coluna 1 NUNCA REMOVA UMA COLUNA 2 Pare de ler a coluna mas continue escrevendo nela 3 Código para de escrever na coluna 4 Remova a coluna (mais tarde)
33. E a minha integridade referencial?
34. Remova-as e recrie-as depois de finalizadas as migrations
35. Características de Microservices https://martinfowler.com/microservices/
36. • Componentization via Services • Organized around Business Capabilities • Products not Projects • Smart endpoints and dumb pipes • Decentralized Governance • Decentralized Data Management • Infrastructure Automation • Design for failure • Evolutionary Design
37. Extraindo o Banco de Dados do seu Microservice
38. Join developers.redhat.com 38 Um Banco de Dados por Microservice
39. Join developers.redhat.com 39 Mas eu tenho um banco de dados monolítico!
40. Join developers.redhat.com 40
41. Separar não é fácil, mas como eu integro os dados depois?
42. Modelos de Consistência de Dados
43. Consistência Forte Consistência Eventual
44. CRUD & CQRS
45. Join developers.redhat.com 45 CRUD (Create, Read, Update, Delete)
46. Join developers.redhat.com 46 CQRS (Command Query Responsibility Segregation)
47. Join developers.redhat.com 47 CQRS com data stores separadas
48. CQRS & Event Sourcing
49. Join developers.redhat.com 49 Cenários Shared Tables Database View Database Materialized View Mirror Table using Trigger Mirror Table using Transactional Code Mirror Table using ETL Mirror Table using Data Virtualization Event Sourcing Change Data Capture
50. Join developers.redhat.com 50 Shared Tables Integração rápida Consistência forte Baixa coesão e alto acoplamento
51. Join developers.redhat.com 51 Database View Alternativa mais fácil de implementar O mais difundido suporte entre DBMSs Possíveis problemas de desempenho Consistência forte Um banco de dados deve ser alcançável pelo outro Atualizável dependendo do DBMS
52. Join developers.redhat.com 52 Database Materialized View Melhor desempenho Consistência forte ou eventual Um banco de dados deve ser alcançável pelo outro Atualizável dependendo do DBMS
53. Join developers.redhat.com 53 Database Trigger Depende de suporte do DBMS Consistência forte Um banco de dados deve ser alcançável pelo outro
54. Join developers.redhat.com 54 Transactional Code Qualquer código: Stored Procedures ou Transações Distribuídas Consistência forte Possíveis problemas de coesão/acoplamento Possíveis problemas de desempenho Atualizável dependendo de como foi implementado
55. Join developers.redhat.com 55 Ferramentas de ETL Muitas ferramentas disponíveis Depende de um gatilho externo (geralmente timer) Pode agregar de múltiplos datasources Consistência eventual Integração somente leitura
56. Join developers.redhat.com 56 Virtualização de Dados Acesso de “tempo real” Consistência forte Pode agregar de múltiplos datasources Atualizável dependendo da solução
57. Join developers.redhat.com 57
58. Join developers.redhat.com 58 Event Sourcing Estado da informação é um fluxo de eventos Facilita auditoria Consistência eventual Normalmente combinado com um Message Bus Alta escalabilidade
59. Join developers.redhat.com 59 Change Data Capture O datasource de leitura é atualizado através de um fluxo de eventos Consistência eventual Normalmente combinado com um Message Bus Alta escalabilidade
60. http://debezium.io
61. Registre-se em developers.redhat.com Feedback é bem vindo! @yanaga
62. plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews Obrigado!