DCODER

Tag: aws

  • Como levar seu sistema para a nuvem sem parar a operação

    Migre em etapas, com o sistema antigo ligado até o novo provar que funciona. A ordem que dá certo é sempre a mesma: inventário, containerização, ambiente paralelo, migração de dados por último e um plano de volta escrito antes de começar.

    Migração de infraestrutura é daqueles projetos em que o sucesso é invisível, ninguém percebe, e o fracasso vira reunião de diretoria. A diferença entre os dois raramente está na escolha do provedor.

    Antes de tudo, o inventário honesto

    Toda migração que dá errado começa com alguém achando que sabe o que está rodando no servidor. Levante, sem pressa:

    • Todo processo ativo, incluindo aquele cron que alguém configurou em 2016 e ninguém sabe o que faz, mas que gera o relatório que o financeiro usa todo dia 5.
    • Todas as pastas escritas em disco. Upload de arquivo é o item que mais atrapalha migrações, porque some do diagrama e reaparece em produção.
    • Todos os endereços fixos: IP em regra de firewall de terceiro, certificado, integração que confia no IP de saída.
    • As versões reais de linguagem, banco e bibliotecas. “Deve ser a 12” não vale. Confira.

    Esse levantamento leva de dois a cinco dias e evita as três surpresas mais caras da fase final.

    Containerize antes de orquestrar

    A tentação é ir direto para Kubernetes. Não vá. O primeiro passo é fazer a aplicação rodar dentro de um container, em qualquer lugar.

    Esse exercício expõe todo o acoplamento com o servidor atual: caminho absoluto de arquivo, dependência instalada manualmente, variável de ambiente que só existe naquela máquina, fuso horário do sistema. É um trabalho chato e é onde mora metade do valor da migração, porque no fim você tem um sistema que qualquer pessoa consegue subir em qualquer lugar.

    Se depois disso um par de containers atrás de um balanceador der conta do seu volume, ótimo. Você não precisa de orquestrador. Kubernetes é excelente e tem um custo operacional bem real. Adote quando o problema justificar.

    Ambiente paralelo, não substituição

    Suba o ambiente novo completo enquanto o antigo continua atendendo. Aponte para ele uma cópia do banco. Deixe rodando por uma ou duas semanas com tráfego espelhado ou com uso interno da equipe.

    É nesse período que aparecem as diferenças sutis. Timeout diferente. Biblioteca de imagem que gera saída ligeiramente distinta. Consulta que era rápida no disco antigo e ficou lenta no armazenamento novo. Descobrir isso com o sistema antigo ligado é inconveniente. Descobrir na madrugada da virada é outra coisa.

    Dados por último, e com ensaio

    Banco de dados é sempre a última peça e a única que não tem desfazer confortável. O procedimento que funciona:

    1. Faça a carga completa antecipadamente e mantenha replicação contínua do antigo para o novo.
    2. Ensaie a virada inteira em ambiente de teste, com cronômetro. Você precisa saber se a janela é de oito minutos ou de duas horas antes de prometer qualquer coisa a alguém.
    3. Na virada real, coloque o sistema em modo somente leitura, espere a replicação zerar, aponte o DNS e valide com um roteiro de testes escrito antes.
    4. Mantenha o ambiente antigo intacto e desligado por, no mínimo, duas semanas.

    O plano de volta precisa estar escrito

    Não é pessimismo, é procedimento. Antes da virada, o documento responde: qual é o critério objetivo para desistir, quem toma essa decisão, quais comandos executar, quanto tempo leva e o que acontece com os dados gravados no ambiente novo enquanto ele esteve no ar.

    Se ninguém consegue responder à última pergunta, a janela de virada precisa ser curta o bastante para que a resposta seja “nenhum dado relevante”. É por isso que se migra de madrugada, não por tradição.

    O que costuma pagar a conta

    O ganho raramente vem do preço do servidor. Muita empresa migra e passa a gastar mais. O retorno real aparece em outros lugares.

    Ambiente reproduzível, para começar: subir uma cópia idêntica para testar deixa de ser projeto e vira comando. Publicação sem medo, porque com integração contínua soltar uma correção passa a ser rotina em vez de evento. Recuperação testada, já que backup que ninguém restaurou não é backup, e na nuvem restaurar para validar custa alguns reais. E elasticidade, se a carga for irregular. Se for constante, um servidor dedicado pode sair mais barato, e não há problema nenhum em admitir isso.

    A DCODER faz migração para nuvem, containerização e automação de publicação com Docker, Kubernetes e AWS, com plano de volta escrito antes da primeira alteração. Fale com o estúdio em dcoder.io.