Migrar centenas de aplicações legadas para a AWS sem travar

Começar por um inventário que mostre do que cada aplicação precisa

Antes de alguém tocar na AWS, liste todas as aplicações que correm nas VM legadas e registe os factos que determinam o esforço de migração. Uma folha de cálculo partilhada chega para começar. O que importa é que cada aplicação tenha uma linha, um responsável e as mesmas colunas.

Depois, classifique cada aplicação num pequeno número de vias, como atualizar, reconstruir e desativar. As equipas podem então planear por via, em vez de discutir cada aplicação a partir do zero.

• Versão do runtime e da framework, assinalando tudo o que já esteja em fim de vida
• Bases de dados, partilhas de ficheiros e tarefas agendadas de que a aplicação depende
• Integrações de entrada e de saída, incluindo nomes de anfitrião e endereços IP escritos diretamente no código
• Método de autenticação e segredos guardados na VM
• Responsável de negócio, nível de utilização e janela de indisponibilidade aceitável

Decidir entre atualizar ou reconstruir aplicação a aplicação, não uma vez para todo o programa

Nenhuma estratégia única serve centenas de aplicações. Algumas precisam apenas de uma atualização da framework, de configuração externalizada e de um novo destino de deploy. Outras carregam tanto código morto ou uma estrutura tão emaranhada que reconstruí-las sobre uma base limpa é mais rápido do que repará-las.

A decisão deve seguir critérios escritos, para que equipas diferentes cheguem à mesma resposta. Uma regra útil: se instalar a aplicação no esqueleto-padrão obriga, de qualquer forma, a reescrever a maior parte dos controladores e do acesso a dados, reconstrua-a. Se a lógica de negócio passa praticamente intacta, atualize-a.

O programa do Crédit Agricole, que levou 600+ aplicações internas de VM legadas para a AWS, usou os dois caminhos. As aplicações foram refeitas sobre o esqueleto CodeIgniter interno do banco, umas atualizadas e outras reconstruídas de raiz.

• Atualizar quando o código é legível, o comportamento é claro e a diferença de versão da framework é pequena
• Reconstruir quando a lógica de negócio está misturada com a apresentação por todo o lado ou a aplicação depende de funcionalidades da linguagem que foram removidas
• Desativar quando a utilização é quase nula e o responsável de negócio concorda, porque a migração mais barata é a que não se faz

Dividir o parque em blocos e entregar cada bloco a uma equipa

A esta escala, uma única equipa central torna-se o ponto de estrangulamento. Um modelo por blocos atribui um lote de aplicações relacionadas a uma pequena equipa, que fica responsável por elas da análise à transição.

Agrupe os blocos por dependências partilhadas, não por ordem alfabética. As aplicações que partilham uma base de dados ou que se chamam umas às outras devem mudar em conjunto, caso contrário o mesmo trabalho de integração repete-se em várias equipas.

Os blocos também tornam o progresso mensurável. Cada equipa reporta os mesmos estados para cada aplicação, como analisada, migrada, testada, em produção na AWS e desativada, e o quadro do programa é a soma desses estados. O programa do Crédit Agricole funcionou assim, e a SDK Enterprises realizou 50+ das suas migrações de aplicações como parte da equipa do programa.

Construir um esqueleto-padrão e fazer todas as aplicações assentarem nele

Um esqueleto aplicacional comum é o que transforma centenas de migrações num processo repetível. Fixa as decisões que não devem ser tomadas de novo para cada aplicação: estrutura de pastas, configuração por variáveis de ambiente, formato dos registos, verificações de saúde, pontos de ligação da autenticação e pipeline de deploy.

Cada aplicação migrada passa então a diferir apenas na lógica de negócio. Os revisores sabem onde procurar, as equipas de operação recebem registos e alarmes coerentes, e uma correção no esqueleto chega a todas as aplicações construídas sobre ele.

Mantenha o esqueleto pequeno e versionado. Se crescer até se tornar uma framework própria, as equipas vão começar a contorná-lo.

Planear a transição e a reversão antes da primeira migração

Cada aplicação precisa de um plano de transição que diga como passa o tráfego, como passam os dados e como se volta atrás. Estas decisões tomam-se antes de a primeira aplicação mudar. Improvisar uma reversão em pleno incidente é a forma como os programas de migração perdem a confiança do negócio.

• Janela de congelamento: combinar com o responsável de negócio quando param as alterações na VM antiga
• Sincronização de dados: migrar os dados com antecedência e fazer uma sincronização final das diferenças durante a janela de transição
• Mudança de tráfego: alterar o DNS ou o encaminhamento do balanceador de carga, com TTL de DNS baixos definidos dias antes
• Testes de fumo: uma verificação curta e automatizada do início de sessão, dos ecrãs principais e das integrações logo após a mudança
• Critério de reversão: uma pessoa identificada e condições escritas para voltar atrás
• VM antiga mantida: pará-la mas não a apagar até a aplicação ter funcionado sem problemas na AWS durante um período acordado

Escrever runbooks que qualquer equipa consiga seguir desde o primeiro dia

Um runbook é a lista de verificação de uma operação repetível: preparar uma aplicação, fazer a transição, revertê-la, desativar a VM. Escreva cada um uma vez, teste-o nas primeiras aplicações e atualize-o sempre que algo surpreender uma equipa.

Bons runbooks indicam comandos, responsáveis e resultados esperados, não intenções. «Verificar se a aplicação funciona» não é um passo. «Iniciar sessão com o utilizador de teste e confirmar que o painel carrega os dados da conta» é.

Os runbooks são também o que permite aos engenheiros que chegam a meio do programa tornarem-se produtivos depressa. Um especialista que chegue na sexta semana deve conseguir fazer a transição de uma aplicação seguindo os documentos, depois de uma sessão de trabalho em par.

O lugar de uma equipa externa numa grande migração

Os grandes programas precisam muitas vezes de capacidade adicional durante um período definido, sem abdicar do controlo. Assumimos blocos de migração dentro de programas maiores, trabalhando sobre o esqueleto, os runbooks e as ferramentas do cliente, com os nossos engenheiros e especialistas freelancers selecionados, ao abrigo de um único contrato.

Perguntas frequentes