O documento discute como automatizar sistemas legados utilizando ferramentas de DevOps. Primeiro, descreve as características problemáticas dos sistemas legados e a necessidade de tratá-los da melhor forma possível. Em seguida, apresenta como a HypeFlame/Agibank modularizou seu sistema legado, escolheu ferramentas adequadas e implementou pipelines de integração e entrega contínuas para tratá-lo de forma semelhante a microsserviços.

1. Como automatizar
Sistemas Legados
utilizando ferramentas
de DevOps

2. Rafael Salerno de Oliveira
• Solution Architect na HypeFlame/Agibank
• Mais de 15 anos em Desenvolvimento de Software
• Últimos 5 anos trabalhando com ferramentas de
Devops/Cloud
• Entusiasta
• TDD,DDD, linguagens funcionais
• XP, métodos ágeis
• Arquitetura Evolucionária
Apresentação

3. Toda empresa tem aquele sistema que:
• Em 6 meses vai morrer (5 anos depois....)
• Sistema de fornecedor (Java 1.5, .Net 3.5, Tomcat 6, etc)
• O Fornecedor instala e ninguém pode mexer
• Sistemas antigo que só o fulaninho pode fazer deploy
ou manutenção
Como conseguimos dar um ar de automação para esse tipo de sistema
Case Agibank/HypeFlame - Sistemas Legados/ Sistemas de Terceiros

4. Muito para escolher

5. • Micro Sevice Architecture ou Event Driven Architecture
• Stateless
• Dinâmicas
• Auto escaláveis
• Resilientes
• Tolerante a falha
• Continuos Integration
• Continuos Delivery
• Etc.. etc..
Como gostaríamos ....

6. Muitos times trabalhando em Micro Services, deploy diário, volumes diferentes
Como é na HypeFlame/Agibank Hoje?

7. ?
Não adianta escalar, ser resliente, alta disponibilidade se o todo não acompanhar
E os sistemas legados/Terceiros?

8. • Statefull
• Arquitetura monolítica
• Altamente acoplado
• Não tolera falhas
• Startup é lento
• Continuos deployment é difícil
• Uma dor a cada update
• Difícil de escalar
• Como falei anteriormente:
• Em 6 meses vai morrer (5 anos depois....)
• Sistema de fornecedor (Java 1.5, .Net 3.5, Tomcat
6, etc)
Características das aplicações legadas e de alguns fornecedores

9. Quando menos esperamos
Temos config de DEV em PRD
PRD em DEV .....
Características das aplicações legadas

10. • Nem tudo podemos construir em casa
• Build or Buy
• Nem todos seguem as arquiteturas mais atuais
• O Fornecedor atende requisitos de negócio
• Não é um grande problema técnico
• Aplicações legadas de 5, 10 anos atrás ainda
funcionam, não se paga uma reescrita.
É inevitável sempre existirão....

11. • Time Arquitetura + OPS devem
conhecer profundamente a
aplicação
• Tenham responsáveis de ambos
os times que acompanham o ciclo
da aplicação
• Nenhuma aplicação deve ir para
produção sem configurações
dinâmicas
• Processo em
Desenvolvimento/Homologação/
Produção devem ser iguais
É importante que:
Pensando nisso ....

12. • Se uma aplicação entrar em Produção com
configurações hard code, há grande chances de ele
ficar assim para sempre...
• Se ela fica assim pra sempre, qualquer oscilação
pode influenciar
• Se perdermos a maquina/instância, podemos ter
um grande problema.
• Qual a probabilidade de algo errado ocorrer na
atualização, de um ambiente para o outro???
• Muitos fornecedores descrevem como tem que ser
instalado, mas o cuidado é todo seu...
• Falhas custam muito caro !!!! (Milhões.....)
Mas por que isso ?????

13. • Times deve analisar juntos, como múltiplos perfis
• Arquiteto, DEV, OPS, DBA
• Analisar todo tipo de configuração dessa aplicação
• Workload
• Sistema Operacional
• Comportamento
• Configurações (banco, serviço)
• Componente que compõem
• Conhecer, estudar, perguntar, testar e testar
• Tratar o mais parecido possível de um Micro serviço
• Efêmero/ immutable infrastructure
• Config dinâmica
• Pipeline
• Testes automatizados
• Auto Scaling (se possível)
Como podemos tratar isso !

14. • Troca de Core Banking
• Nova oportunidade
• Porem ....
• Aplicação com código + de 10 anos
• Tecnologias não tão atuais
• Complexidade alta
• Tempo curto
Agibank/HypeFlame Case

15. • Habilitar para o time trabalhar em
DEV !!!
• Conhecer profundamente a
aplicação
• Antes de automatizar o ambiente
testar manualmente os steps de
instalação
• Testes em ambientes paralelos
• Planejar o Pipeline para o time ser
independente
2
O que vamos fazer ....
Primeiro Passo

16. • Modularizar
• Separando as responsabilidades
• Escolhe as ferramentas adequadas
• Adequar os arquivos de configuração
• (DEV/QA/HLG/PRD)
• Properties
• XML
• JSON
• Shell
• Etc...
2
Segundo Passo

17. • Core banking tem muitas responsabilidades
• Conta Corrente
• Crédito
• Investimentos
• Limites de Crédito
• Núcleo
• Etc...
• Base da Aplicação
• Configurações por Ambiente
Objetivo: Independência para os times
- config
- Base de código
Objetivo: Juntar tudo, aplicar configurações
Criando módulos

18. Antes de escolher, o que queremos fazer ???
Ter certeza das suas necessidades!
Relembrando....
• Aplicações Efêmeras/Stateless
• Dinâmicas
• Auto escaláveis
• Resilientes
• Tolerante a falha
• Continuos Integration
• Continuos Delivery
• Etc.. etc..
Escolhendo Ferramentas

19. Objetivo: Independência para os times
Objetivo: Juntar tudo, aplicar configurações
Pensar Cloud Native
Objetivo: Precisamos de uma base de Sistema Operacional
Objetivo: Queremos uma infra imutável
Qualquer um do time
tem que realizar um deploy
São muitas maquinas que pode nascer/ estar Rodando
Quero correlacionar os logs com quem chamou
Escolhendo Ferramentas

20. Tudo que pode ser base para essa aplicação e muda pouco ou nada fica na imagem:
• Stack de logs
• Monitoramento
A infraestrutura pode mudar, de ambiente para ambiente, bem como as configs
Escolhendo Ferramentas

21. São muitas maquinas que pode nascer/ estar Rodando
Quero correlacionar os logs com quem chamou
Maquinas sobem de acordo com o Workload
Inicios do dia são 4
meio dia por volta de 6 a 8
Picos de 12
Instalado 1x
Logs/Monitoring

22. • Vários times fazendo melhorias, configurações
• Tempos de releases diferentes em cima da mesma base
Criação do ambiente = até Deploy
Como funciona:
• DEV - pode adicionar novos arquivos
• QA - apenas com infra imutável
• HLG - apenas com infra imutável
• PRD - apenas com infra imutável
• Diariamente os ambientes DEV/QA/HLG/
• São destruídos a noite e criados na parte da manhã
• Para testar scripts, alterações
Pipeline – CI/CD

23. Com todas essas ferramentas
Podemos utilizar o Blue/Green por DNS
Muuuito testes em Homologação
Zero Down time

24. • O caminho foi difícil ...
• Hoje o time de desenvolvimento
• Aplica patchs
• Novas Versões
• Novos desenvolvimentos
• Tratar uma aplicação com mais de 10 anos como se fosse um
Micro service
• Monolito com AutoScaling UP and Scaling Down
• + 200 desenvolvedores,
• + 25 squads
• + 600 micro serviços
• Deploy sem impacto no Negócio e Micro Serviços
Resultados/Benefícios

25. • Mesmo que aplicação não seja de terceiros conheça bem
• Por mais difícil que seja busque a ideia de:
• Stateless
• Immutable infrastructure
• Auto Scaling
• Resiliencia
• CI/CD
• Automatize o máximo que puder
• Se não der crie configs por ambiente
• Faça o suficiente para tirar a pressão do time
• Não deixe o projeto/Sprint/atividade dos desenvolvedores parados por
falta de ambiente
• Não busque perfeição na primeira versão + caminhe em direção do ideal
• Faça v1, v2 ....v10
• Você pode trabalhar em melhoria em um segundo momento
Aprendizados

26. Como automatizar Sistemas Legados utilizando
ferramentas de DevOps