Analisar os critérios de decisão para o modelo de seleção e migração de ferramentas
Agora que exploramos as opções de metodologias de migração e opções de ferramentas, podemos explorar os critérios de decisão que precisamos considerar para executar nossas migrações para o Servidor Flexível do Banco de Dados do Azure para PostgreSQL. Os três principais critérios que nos ajudam a fazer nossas escolhas são Tempo de inatividade, Local do banco de dados de origem e Personalização.
Tempo de inatividade
O tempo de inatividade é uma faceta fundamental das atividades de migração e a duração aceitável para os stakeholders nos ajuda a decidir se precisamos executar uma atividade de migração offline ou online.
Normalmente, as atividades de migração são planejadas com bastante antecedência para garantir que os controles de alteração apropriados e a governança associada sejam concluídos para a atividade. Esse planejamento permite que uma caixa de diálogo com os principais stakeholders entenda por quanto tempo o sistema pode ficar offline. Nessa situação, é aconselhável saber quanto tempo leva para que as diferentes opções possam estabelecer durações mínimas e máximas de tempo de inatividade estimadas.
Estabelecer o tempo de inatividade mínimo necessário para executar um recortado do aplicativo é fundamental. Em última análise, esse é o valor que você precisa para colocar o sistema offline mesmo para uma atividade de migração online (ou tempo de inatividade mínimo). A complexidade do aplicativo vai ditar essa escala de tempo. Para um aplicativo relativamente simples, esse processo pode ser um caso de parar um serviço, atualizar um arquivo de configuração e, em seguida, ativá-lo novamente. Em ambientes mais complexos, esse processo pode demorar muito mais se houver vários servidores e camadas de aplicativo em jogo.
Entender a duração necessária para atividades de migração online ou offline é o próximo elemento importante relacionado ao tempo de inatividade. Se for uma migração offline, o tempo necessário para extrair, transferir e carregar os dados da origem para o destino seguido de validação e verificação será o tempo de inatividade. Esse tempo de inatividade é então colocado entre o tempo necessário para desativar o aplicativo/carga de trabalho e o tempo necessário para ativar novamente o aplicativo/carga de trabalho.
Se for uma migração online (tempo de inatividade mínimo), o tempo de inatividade será a duração necessária para sincronizar as alterações finais da origem para o destino depois que o aplicativo estiver desativado. Adicione a esse tempo de inatividade, a validação e as atividades de verificação antes de reconfigurar e habilitar o aplicativo/carga de trabalho.
Depois que tivermos essas informações, podemos examinar os elementos técnicos da migração para ajudar a estabelecer quais são nossas opções viáveis.
Local do banco de dados de origem
O local do banco de dados de origem a serem migrados desempenha um papel devido às restrições que provavelmente estarão em vigor para qualquer configuração específica.
Fontes locais ou não do Azure
Para um banco de dados local ou não localizado do Azure, a restrição de chave normalmente é a conectividade de rede entre a origem e o destino. Os três pontos a serem considerados aqui são largura de banda, latência e volume de dados. Depois de entendermos esses pontos, podemos tomar uma decisão informada sobre qual tipo de migração é viável.
Se tivermos um grande volume de dados para migrar e uma quantidade proporcionalmente pequena de largura de banda, provavelmente um despejo e restauração simples não serão viáveis. Considerando que, se tivermos um grande volume de dados e uma grande quantidade de largura de banda, será menos preocupante.
Da mesma forma, se for uma migração online em que a sincronização de dados ocorrerá, a latência será um dos principais fatores. Se a latência for alta, poderá haver impactos adversos no desempenho do sistema porque o processo de sincronização leva muito tempo para ser concluído.
Um fator importante a ser considerado ao migrar de outros provedores de nuvem é se eles cobram pela saída de dados. Nesse caso, ser capaz de minimizar o volume físico dos dados que estão sendo transferidos pode ser uma consideração. Em situações como essa, a tecnologia de compactação pode ser importante para despejos ou fluxos de dados usados para sincronização.
Outros serviços baseados no Azure
Haverá situações em que você deseja migrar de outros serviços baseados no Azure para o Servidor Flexível do Banco de Dados do Azure para PostgreSQL. Esses bancos de dados de origem podem estar em VMs do Azure, contêineres ou possivelmente no Servidor Único do Banco de Dados do Azure para PostgreSQL. Nesse caso, há um conjunto diferente de considerações a serem exploradas, mas, ao mesmo tempo, várias oportunidades para se beneficiar de otimizações dentro dos serviços do Azure para esses cenários.
Personalização
A área final de consideração é a quantidade de personalização necessária ou desejada. Essa consideração pode assumir a forma de necessidade de modificar a estrutura do banco de dados de origem para dar suporte à replicação de dados, como alternativa, isso pode significar como é fácil automatizar por meio de script.
Um bom exemplo seria automatizar a migração offline de um banco de dados por meio de pg_dump e pg_restore, mas ao mesmo tempo incluindo a compactação e a descompactação dos arquivos de despejo.
Tomada de decisão
Agora que passamos pelo processo de coleta de todas essas informações, podemos trabalhar com os stakeholders para determinar a melhor opção para um determinado cenário. Ao tomar a decisão sobre qual metodologia e tecnologia devem ser usadas, é importante não apenas trabalhar com os stakeholders de negócios, mas também com os stakeholders técnicos. Essa colaboração ajuda a evitar uma situação em que a empresa conduz para uma migração mínima de tempo de inatividade, que a equipe técnica não está em posição de entregar devido a restrições de pessoal, recurso ou tecnologia.
O importante aqui é gerenciar as expectativas e ter um diálogo aberto e honesto. Também é importante garantir que a empresa assuma a propriedade das tarefas de validação que ficam fora da responsabilidade das equipes técnicas que fornecem a migração de banco de dados. Essa validação pode envolver verificações de consistência e validação de dados e testes de experiência do usuário.