O documento discute os desafios e oportunidades na migração de sistemas monolíticos para microserviços. Apresenta estratégias como o pattern "strangler", onde novas funcionalidades são desenvolvidas como microserviços estrategicamente estrangulando partes do monolito, e a replicação de dados para permitir a evolução independente. Também aborda como lidar com dados e aplicações durante o processo de migração incremental para microserviços.

1. Convivendo e
Migrando para
Microserviços
DESAFIOS E OPORTUNIDADES
SÃO PAULO – 8/11/2018

2. Agenda
• Introdução
• Provocação
• O primeiro pattern (Strangler)
• Macro cenário – dados e aplicações
• Dados
• Aplicações
• Conclusão
• Perguntas

3. iurovski@everis:~$ > whoami
Danilo Iurovski
Digital Architect everis
Atuando desde 1998 no mercado de TI (dev, engenheiro, arquiteto)
Mercado financeiro – foco em altos volumes, latência, etc.
Experiência em projetos de inovação
Período sabático como Gerente de Projetos
Binge-watcher e cinéfilo (tive uma vídeo locadora de VHS)
danilo.iurovski@everis.com
https://www.linkedin.com/in/daniloiurovski/
11 99322-4428

4. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Num passado recente assumimos que:

5. Migração incremental
“The only thing a Big Bang
migration guarantees is a big
*Bang*.”
-- Martin Fowler

6. O estrangulamento
Sementes distribuídas
por pássaros fazem
este novo tipo de planta
crescer fincando suas
raízes na planta antiga
competindo pelo solo,
até estrangular ela e
tomar seu lugar...
Strangler Pattern
https://www.martinfowler.com/bliki/StranglerApplication.html

7. O verdadeiro estrangulamento
Duas abordagens comuns no mercado:
• Realizar o estrangulamento inicial pelas
funcionalidades que trazem mais valor ao negócio,
porque estas normalmente sofrem evoluções mais
constantes e adotar uma arquitetura orientada a
microserviços com todo seu entorno de devsecops e
sua infraestrutura em cloud traz benefícios e agilidade
para os times;
• Construir as funcionalidades novas já na plataforma de
aplicação moderna. É importante começar a reduzir ou
frear as evoluções do sistema legado.
O monolito residual pode permanecer por tempo
indeterminado – partes de menor valor par ao negócio, mais
estável e com poucas mudanças, podem ou não migrar.

8. Dados e Aplicações
UI
Camada de Negócios
Interface de Dados
Microserviço
UI
Microserviço Microserviço Microserviço
Microserviço
Seu próprio data store
COMO???
Não esquecer do entorno: DevSecOps, Infaestrutura, Processos, Novos Skills, novos times!

9. Dados
DDD
O modelo de dados do monolito normalmente está defasado....
Como os microserviços possuem seus dados segregados por domínios e não mais
centralizados, é provável que novas estruturas de dados se formem para refletir melhor
um domínio específico... (Campos, valores, etc.)
Esse é o primeiro passo.
Dica: os domínios funcionais dos microserviços normalmente fazem uma analogia a
estrutura de comunicação da empresa (Conway’s Law)
Replicate Data to
avoid widespread
changes
Split the
Domain Model
Refactor the
Database

10. Dados
MONOLITO
MONOLITO SERVIÇO DE ENVIO
Replique os dados do novo serviço para o monolito
EXEMPLO
QUEBRANDO
BARREIRAS
Período transitório
(não afeta os clientes
originais).
Mantenha os registros
originais em read-only

11. Dados – Replicando e convivendo
Scripts
ETL
Triggers
CDC
Levar em conta que cada informação tem uma periodicidade de atualização.
Tecnologias como o Change Data Capture são muito úteis para intervalos
pequenos de sincronização (Kafka Connector, Attunity, Apache NiFi,
StreamSets, etc.)
Big Data

12. Aplicações – Novas Funcionalidades
“Ahhh, não consigo parar meus projetos, o PO e as metas de negócios não param!”
J.D. – Arquiteto
Sênior
Sincronismo de bases

13. Aplicações – Novas Funcionalidades
SÍNCRONO ASSÍNCRONO
Anti-corruption Layer Pattern

14. Aplicações – Migrando partes do Monolito
FATIAMENTO

15. Perguntas

16. Algumas referências

17. Muito obrigado!