SlideShare uma empresa Scribd logo
1 de 26
Baixar para ler offline
Como automatizar
Sistemas Legados
utilizando ferramentas
de DevOps
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
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
Muito para escolher
• 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 ....
Muitos times trabalhando em Micro Services, deploy diário, volumes diferentes
Como é na HypeFlame/Agibank Hoje?
?
Não adianta escalar, ser resliente, alta disponibilidade se o todo não acompanhar
E os sistemas legados/Terceiros?
• 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
Quando menos esperamos
Temos config de DEV em PRD
PRD em DEV .....
Características das aplicações legadas
• 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....
• 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 ....
• 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 ?????
• 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 !
• 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
• 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
• 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
• 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
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
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
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
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
• 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
Com todas essas ferramentas
Podemos utilizar o Blue/Green por DNS
Muuuito testes em Homologação
Zero Down time
• 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
• 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
Como automatizar Sistemas Legados utilizando
ferramentas de DevOps

Mais conteúdo relacionado

Mais procurados

Implantando continuous delivery e seus oito principios
Implantando continuous delivery e seus oito principiosImplantando continuous delivery e seus oito principios
Implantando continuous delivery e seus oito principiosCarlos Felippe Cardoso
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariTaller Negócio Digitais
 
DevOps: princípios e práticas para a Entrega Contínua
DevOps: princípios e práticas para a Entrega ContínuaDevOps: princípios e práticas para a Entrega Contínua
DevOps: princípios e práticas para a Entrega ContínuaOtávio Calaça Xavier
 
Metodologias de desenvolvimento - Waterfall vs Agile
Metodologias de desenvolvimento - Waterfall vs AgileMetodologias de desenvolvimento - Waterfall vs Agile
Metodologias de desenvolvimento - Waterfall vs AgileMarcelo Murad
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014Rodrigo Campos
 
XP como aliado para conter a complexidade de um monolito de mais de 15 anos
XP como aliado para conter a complexidade de um monolito de mais de 15 anosXP como aliado para conter a complexidade de um monolito de mais de 15 anos
XP como aliado para conter a complexidade de um monolito de mais de 15 anosAnderson Silveira
 
Como funciona uma empresa ágil de desenvolvimento de software
Como funciona uma empresa ágil de desenvolvimento de softwareComo funciona uma empresa ágil de desenvolvimento de software
Como funciona uma empresa ágil de desenvolvimento de softwareElvis Lima
 
Devops - A cultura ágil voltada à infra-estrutura
Devops - A cultura ágil voltada à infra-estruturaDevops - A cultura ágil voltada à infra-estrutura
Devops - A cultura ágil voltada à infra-estruturaFernando Celarino
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Igor Abade
 
IFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOpsIFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOpsLeonardo Comelli
 
Arquitetura de Software para a Entrega Continua
Arquitetura de Software para a Entrega ContinuaArquitetura de Software para a Entrega Continua
Arquitetura de Software para a Entrega ContinuaOtávio Calaça Xavier
 
Da Integração à Entrega Contínua
Da Integração à Entrega ContínuaDa Integração à Entrega Contínua
Da Integração à Entrega ContínuaMarlon Bernardes
 
DevOps com Exemplos Práticos - QConRio 2014
DevOps com Exemplos Práticos - QConRio 2014DevOps com Exemplos Práticos - QConRio 2014
DevOps com Exemplos Práticos - QConRio 2014Leo Lorieri
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develJose Augusto Carvalho
 
Quando os rótulos não atendem as suas necessidades
Quando os rótulos não atendem as suas necessidadesQuando os rótulos não atendem as suas necessidades
Quando os rótulos não atendem as suas necessidadesJuliano Ribeiro
 
Processos de Software - 101
Processos  de Software - 101Processos  de Software - 101
Processos de Software - 101Lucas Amaral
 
DevOps - Estado da Arte
DevOps - Estado da ArteDevOps - Estado da Arte
DevOps - Estado da Arteilegra
 
Testes em uma startup do mundo financeiro
Testes em uma startup do mundo financeiroTestes em uma startup do mundo financeiro
Testes em uma startup do mundo financeiroLuiz Alberto Hespanha
 

Mais procurados (20)

Implantando continuous delivery e seus oito principios
Implantando continuous delivery e seus oito principiosImplantando continuous delivery e seus oito principios
Implantando continuous delivery e seus oito principios
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
 
DevOps: princípios e práticas para a Entrega Contínua
DevOps: princípios e práticas para a Entrega ContínuaDevOps: princípios e práticas para a Entrega Contínua
DevOps: princípios e práticas para a Entrega Contínua
 
DevOps
DevOpsDevOps
DevOps
 
Metodologias de desenvolvimento - Waterfall vs Agile
Metodologias de desenvolvimento - Waterfall vs AgileMetodologias de desenvolvimento - Waterfall vs Agile
Metodologias de desenvolvimento - Waterfall vs Agile
 
DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014DevOps no mundo real - QCON 2014
DevOps no mundo real - QCON 2014
 
XP como aliado para conter a complexidade de um monolito de mais de 15 anos
XP como aliado para conter a complexidade de um monolito de mais de 15 anosXP como aliado para conter a complexidade de um monolito de mais de 15 anos
XP como aliado para conter a complexidade de um monolito de mais de 15 anos
 
Kanban
KanbanKanban
Kanban
 
Como funciona uma empresa ágil de desenvolvimento de software
Como funciona uma empresa ágil de desenvolvimento de softwareComo funciona uma empresa ágil de desenvolvimento de software
Como funciona uma empresa ágil de desenvolvimento de software
 
Devops - A cultura ágil voltada à infra-estrutura
Devops - A cultura ágil voltada à infra-estruturaDevops - A cultura ágil voltada à infra-estrutura
Devops - A cultura ágil voltada à infra-estrutura
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?
 
IFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOpsIFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOps
 
Arquitetura de Software para a Entrega Continua
Arquitetura de Software para a Entrega ContinuaArquitetura de Software para a Entrega Continua
Arquitetura de Software para a Entrega Continua
 
Da Integração à Entrega Contínua
Da Integração à Entrega ContínuaDa Integração à Entrega Contínua
Da Integração à Entrega Contínua
 
DevOps com Exemplos Práticos - QConRio 2014
DevOps com Exemplos Práticos - QConRio 2014DevOps com Exemplos Práticos - QConRio 2014
DevOps com Exemplos Práticos - QConRio 2014
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e devel
 
Quando os rótulos não atendem as suas necessidades
Quando os rótulos não atendem as suas necessidadesQuando os rótulos não atendem as suas necessidades
Quando os rótulos não atendem as suas necessidades
 
Processos de Software - 101
Processos  de Software - 101Processos  de Software - 101
Processos de Software - 101
 
DevOps - Estado da Arte
DevOps - Estado da ArteDevOps - Estado da Arte
DevOps - Estado da Arte
 
Testes em uma startup do mundo financeiro
Testes em uma startup do mundo financeiroTestes em uma startup do mundo financeiro
Testes em uma startup do mundo financeiro
 

Semelhante a Como automatizar Sistemas Legados utilizando ferramentas de DevOps

ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122Bruno Souza
 
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...tdc-globalcode
 
Integração Contínua com Hudson
Integração Contínua com HudsonIntegração Contínua com Hudson
Integração Contínua com HudsonLuis Reis
 
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitQualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitDomingos Teruel
 
ASP.Net Performance – A pragmatic approach - Luis Paulino
ASP.Net Performance – A pragmatic approach - Luis PaulinoASP.Net Performance – A pragmatic approach - Luis Paulino
ASP.Net Performance – A pragmatic approach - Luis PaulinoComunidade NetPonto
 
Incluindo Ferramentas de Segurança no Pipeline
Incluindo Ferramentas de Segurança no PipelineIncluindo Ferramentas de Segurança no Pipeline
Incluindo Ferramentas de Segurança no PipelineClaudio Romao
 
Sonarqube
SonarqubeSonarqube
SonarqubeCDS
 
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...tdc-globalcode
 
Como escolher o modelo ideal de TFS para sua empresa
Como escolher o modelo ideal de TFS para sua empresaComo escolher o modelo ideal de TFS para sua empresa
Como escolher o modelo ideal de TFS para sua empresaCDS
 
SonarQube
SonarQubeSonarQube
SonarQubeCDS
 
Os príncipios por trás do DevOps
Os príncipios por trás do DevOpsOs príncipios por trás do DevOps
Os príncipios por trás do DevOpsGuilherme Cardoso
 
Open4Education | MC122 - Introdução a ALM OpenSource
Open4Education | MC122 - Introdução a ALM OpenSourceOpen4Education | MC122 - Introdução a ALM OpenSource
Open4Education | MC122 - Introdução a ALM OpenSourcetdc-globalcode
 
TDD com Código Legado - "Atualizado"
TDD com Código Legado - "Atualizado"TDD com Código Legado - "Atualizado"
TDD com Código Legado - "Atualizado"Cesar Romero
 
Negócios e Open Source
Negócios e Open SourceNegócios e Open Source
Negócios e Open SourceOpenBossa
 
Conhecimentos para tomar atitude e migrar sua aplicação para asp.net core
Conhecimentos para tomar atitude e migrar sua aplicação para asp.net coreConhecimentos para tomar atitude e migrar sua aplicação para asp.net core
Conhecimentos para tomar atitude e migrar sua aplicação para asp.net coreRodrigo Kono
 
TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...
TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...
TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...tdc-globalcode
 

Semelhante a Como automatizar Sistemas Legados utilizando ferramentas de DevOps (20)

ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
 
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
TDC2016SP - Versionando sua infraestrutura: Como e porque fazer, baseado em c...
 
Integração Contínua com Hudson
Integração Contínua com HudsonIntegração Contínua com Hudson
Integração Contínua com Hudson
 
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitQualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnit
 
ASP.Net Performance – A pragmatic approach - Luis Paulino
ASP.Net Performance – A pragmatic approach - Luis PaulinoASP.Net Performance – A pragmatic approach - Luis Paulino
ASP.Net Performance – A pragmatic approach - Luis Paulino
 
Incluindo Ferramentas de Segurança no Pipeline
Incluindo Ferramentas de Segurança no PipelineIncluindo Ferramentas de Segurança no Pipeline
Incluindo Ferramentas de Segurança no Pipeline
 
Sonarqube
SonarqubeSonarqube
Sonarqube
 
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
TDC2017 | São Paulo - Trilha Containers How we figured out we had a SRE team ...
 
Introdução ao XP
Introdução ao XPIntrodução ao XP
Introdução ao XP
 
Como escolher o modelo ideal de TFS para sua empresa
Como escolher o modelo ideal de TFS para sua empresaComo escolher o modelo ideal de TFS para sua empresa
Como escolher o modelo ideal de TFS para sua empresa
 
SonarQube
SonarQubeSonarQube
SonarQube
 
Os príncipios por trás do DevOps
Os príncipios por trás do DevOpsOs príncipios por trás do DevOps
Os príncipios por trás do DevOps
 
Open4Education | MC122 - Introdução a ALM OpenSource
Open4Education | MC122 - Introdução a ALM OpenSourceOpen4Education | MC122 - Introdução a ALM OpenSource
Open4Education | MC122 - Introdução a ALM OpenSource
 
TDD com Código Legado - "Atualizado"
TDD com Código Legado - "Atualizado"TDD com Código Legado - "Atualizado"
TDD com Código Legado - "Atualizado"
 
Apresentação Executiva
Apresentação ExecutivaApresentação Executiva
Apresentação Executiva
 
Negócios e Open Source
Negócios e Open SourceNegócios e Open Source
Negócios e Open Source
 
Conhecimentos para tomar atitude e migrar sua aplicação para asp.net core
Conhecimentos para tomar atitude e migrar sua aplicação para asp.net coreConhecimentos para tomar atitude e migrar sua aplicação para asp.net core
Conhecimentos para tomar atitude e migrar sua aplicação para asp.net core
 
Startups e DevOps
Startups e DevOpsStartups e DevOps
Startups e DevOps
 
Apresentacao dev ops
Apresentacao dev opsApresentacao dev ops
Apresentacao dev ops
 
TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...
TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...
TDC2018SP | Trilha Modern Web - Blazor - C# rodando no navegador padrao, sem ...
 

Mais de Rafael Salerno de Oliveira (20)

Aws route 53
Aws route 53Aws route 53
Aws route 53
 
Aws Network Introduction
Aws Network Introduction Aws Network Introduction
Aws Network Introduction
 
Aws system manager
Aws system managerAws system manager
Aws system manager
 
Clean code
Clean codeClean code
Clean code
 
Kontena
KontenaKontena
Kontena
 
Docker hub
Docker hubDocker hub
Docker hub
 
Docker cloud
Docker cloudDocker cloud
Docker cloud
 
Front end architecture
Front end architectureFront end architecture
Front end architecture
 
Domain driven design com functional programing(f#)
Domain driven design com functional programing(f#)Domain driven design com functional programing(f#)
Domain driven design com functional programing(f#)
 
Virtual box
Virtual boxVirtual box
Virtual box
 
Serf
SerfSerf
Serf
 
Vagrant
VagrantVagrant
Vagrant
 
V8 Google
V8 GoogleV8 Google
V8 Google
 
Thinking in systems
Thinking in systemsThinking in systems
Thinking in systems
 
Design pattern for mobile Android IOS
Design pattern for mobile Android IOSDesign pattern for mobile Android IOS
Design pattern for mobile Android IOS
 
Batoo jpa
Batoo jpaBatoo jpa
Batoo jpa
 
Hammock Driven Development
Hammock Driven DevelopmentHammock Driven Development
Hammock Driven Development
 
Responsibility Driven Design
Responsibility Driven DesignResponsibility Driven Design
Responsibility Driven Design
 
Service Design Patterns - Study Case
Service Design Patterns - Study Case  Service Design Patterns - Study Case
Service Design Patterns - Study Case
 
Hammock Driven Design
Hammock Driven DesignHammock Driven Design
Hammock Driven Design
 

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
  • 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