Uma estrat\u00e9gia de migra\u00e7\u00e3o de dados para a moderniza\u00e7\u00e3o de NoSQL falha quando trata a substitui\u00e7\u00e3o de banco de dados como um problema de transfer\u00eancia de dados. Na verdade, \u00e9 um problema de execu\u00e7\u00e3o de programa.<\/p>\n\n\n\n
Muitas iniciativas de moderniza\u00e7\u00e3o empresarial come\u00e7am com meses de avalia\u00e7\u00e3o de plataformas de banco de dados, compara\u00e7\u00e3o de recursos, testes de desempenho e sele\u00e7\u00e3o de uma arquitetura-alvo. No entanto, uma vez tomada a decis\u00e3o tecnol\u00f3gica, o trabalho mais dif\u00edcil ainda est\u00e1 por vir. As equipes descobrem que as depend\u00eancias de aplicativos s\u00e3o mais extensas do que o esperado, os modelos de dados exigem um redesign significativo, os cronogramas de implanta\u00e7\u00e3o tornam-se irreais e os procedimentos de revers\u00e3o n\u00e3o foram totalmente definidos. O resultado \u00e9 que os programas de moderniza\u00e7\u00e3o de banco de dados estagnam n\u00e3o porque a plataforma escolhida seja incapaz, mas porque o esfor\u00e7o necess\u00e1rio para executar a migra\u00e7\u00e3o foi subestimado.<\/p>\n\n\n\n
A moderniza\u00e7\u00e3o bem-sucedida depende da constru\u00e7\u00e3o de uma estrat\u00e9gia de execu\u00e7\u00e3o realista que alinhe arquitetura, aplica\u00e7\u00f5es, opera\u00e7\u00f5es e prioridades de neg\u00f3cios antes que a migra\u00e7\u00e3o comece. Organiza\u00e7\u00f5es que investem pesadamente na avalia\u00e7\u00e3o de tecnologia enquanto tratam o planejamento como uma atividade secund\u00e1ria frequentemente encontram estouros de cronograma, custos inesperados e per\u00edodos prolongados de opera\u00e7\u00e3o de sistemas paralelos.<\/p>\n\n\n\n
Este artigo analisa seis das lacunas de planejamento de migra\u00e7\u00e3o mais comuns que surgem ap\u00f3s o in\u00edcio do projeto e explora como resolv\u00ea-las antes que se tornem riscos de entrega. Abordaremos por que a sele\u00e7\u00e3o de tecnologia \u00e9 apenas o ponto de partida, como a tradu\u00e7\u00e3o do modelo de dados introduz complexidade oculta, por que a refatora\u00e7\u00e3o de aplicativos deve ter seu escopo definido antecipadamente, como a execu\u00e7\u00e3o em fases reduz o risco operacional, por que o planejamento de revers\u00e3o deve fazer parte de toda estrat\u00e9gia de moderniza\u00e7\u00e3o de dados e como construir um caso de neg\u00f3cios atraente que mantenha os esfor\u00e7os de moderniza\u00e7\u00e3o financiados e alinhados at\u00e9 a conclus\u00e3o.<\/p>\n\n\n\n
A sele\u00e7\u00e3o de tecnologia costuma ser a parte mais f\u00e1cil de uma iniciativa de moderniza\u00e7\u00e3o de dados. A nova plataforma \u00e9 aprovada, os or\u00e7amentos s\u00e3o alocados, os fornecedores s\u00e3o selecionados e as equipes de projeto est\u00e3o prontas para come\u00e7ar. O que frequentemente recebe menos aten\u00e7\u00e3o \u00e9 o plano de execu\u00e7\u00e3o necess\u00e1rio para entregar a migra\u00e7\u00e3o com sucesso. Como resultado, a implementa\u00e7\u00e3o se torna um exerc\u00edcio de resolu\u00e7\u00e3o de problemas inesperados, em vez de seguir uma estrat\u00e9gia de migra\u00e7\u00e3o de dados bem definida.<\/p>\n\n\n\n
Os primeiros 90 dias s\u00e3o quando as lacunas de planejamento normalmente aparecem, e tr\u00eas problemas respondem por muitos esfor\u00e7os de moderniza\u00e7\u00e3o estagnados:<\/p>\n\n\n\n
A tradu\u00e7\u00e3o de modelos de dados \u00e9 tratada como uma tarefa de banco de dados em vez de um exerc\u00edcio de design arquitetural.<\/strong> As equipes concentram-se em mover os dados sem contabilizar totalmente as altera\u00e7\u00f5es nas estruturas de documentos, estrat\u00e9gias de indexa\u00e7\u00e3o e padr\u00f5es de acesso a aplicativos.<\/p>\n\n\n\n A refatora\u00e7\u00e3o de aplica\u00e7\u00f5es \u00e9 descoberta durante a execu\u00e7\u00e3o em vez de ser planejada antecipadamente.<\/strong> A l\u00f3gica de consultas, as APIs e as camadas de acesso a dados geralmente exigem mais altera\u00e7\u00f5es do que o estimado inicialmente, expandindo o escopo do projeto ap\u00f3s o in\u00edcio do trabalho.<\/p>\n\n\n\n O planejamento de revers\u00e3o n\u00e3o est\u00e1 definido.<\/strong> Sem uma estrat\u00e9gia clara de fallback, os deployments tornam-se eventos de alto risco, do tipo tudo ou nada, que atrasam os lan\u00e7amentos e aumentam o risco operacional.<\/p>\n\n\n\n A maior parte do conte\u00fado sobre a moderniza\u00e7\u00e3o de NoSQL concentra-se em avaliar tecnologias de banco de dados ou explicar seus benef\u00edcios. Muito menos aten\u00e7\u00e3o \u00e9 dada ao planejamento da migra\u00e7\u00e3o NoSQL necess\u00e1rio para executar um programa de moderniza\u00e7\u00e3o de banco de dados bem-sucedido, mas \u00e9 a\u00ed que muitos projetos acabam tendo sucesso ou fracassando.<\/p>\n\n\n\n Uma estrat\u00e9gia de migra\u00e7\u00e3o de dados bem-sucedida envolve muito mais do que mover dados de uma plataforma para outra. Ela tamb\u00e9m exige a reformula\u00e7\u00e3o de como os dados s\u00e3o modelados para um banco de dados de documentos JSON, e essas decis\u00f5es devem ser tomadas por arquitetos, e n\u00e3o apenas por administradores de banco de dados.<\/p>\n\n\n\n Tr\u00eas escolhas de design t\u00eam o maior impacto no desempenho e na manutenibilidade da aplica\u00e7\u00e3o:<\/p>\n\n\n\n Essas decis\u00f5es arquiteturais influenciam o desempenho, a escalabilidade e o esfor\u00e7o de desenvolvimento muito depois que a migra\u00e7\u00e3o \u00e9 conclu\u00edda. Em vez de tratar a convers\u00e3o de esquema como um exerc\u00edcio de mapeamento \u00fanico, fa\u00e7a da modelagem de dados uma parte fundamental do seu planejamento de migra\u00e7\u00e3o. Para obter orienta\u00e7\u00f5es sobre como projetar esquemas orientados a documentos, consulte o site da Couchbase guia de modelagem de dados JSON flex\u00edvel<\/a>.<\/p>\n\n\n\n Muitos planos de estrat\u00e9gia de migra\u00e7\u00e3o de banco de dados focam em mover dados, mas subestimam as altera\u00e7\u00f5es na aplica\u00e7\u00e3o necess\u00e1rias para suportar a nova plataforma. Identificar essas mudan\u00e7as antecipadamente \u00e9 uma parte cr\u00edtica de qualquer estrat\u00e9gia de moderniza\u00e7\u00e3o de aplica\u00e7\u00f5es.<\/p>\n\n\n\n Tr\u00eas \u00e1reas de estrat\u00e9gia de moderniza\u00e7\u00e3o de aplica\u00e7\u00f5es <\/strong>merecem aten\u00e7\u00e3o antes que a migra\u00e7\u00e3o comece:<\/p>\n\n\n\n Uma forma pr\u00e1tica de estimar o escopo real \u00e9 realizar uma auditoria de refatora\u00e7\u00e3o de aplicativos em um aplicativo representativo antes de finalizar o planejamento da migra\u00e7\u00e3o. Os resultados normalmente revelam o esfor\u00e7o necess\u00e1rio em todo o portf\u00f3lio de aplicativos mais amplo, resultando em uma estrat\u00e9gia de migra\u00e7\u00e3o de banco de dados mais realista e em menos surpresas durante a execu\u00e7\u00e3o.<\/p>\n\n\n\n Se a sua equipe estiver procurando suporte \u00e0 migra\u00e7\u00e3o<\/a>, os Servi\u00e7os Profissionais do Couchbase podem fornecer orienta\u00e7\u00e3o especializada para avalia\u00e7\u00e3o e migra\u00e7\u00e3o, al\u00e9m de suporte pr\u00e1tico e treinamento, tudo adaptado \u00e0s suas necessidades.<\/p>\n\n\n\n Um dos maiores erros no planejamento de migra\u00e7\u00e3o \u00e9 tentar migrar todas as cargas de trabalho de uma s\u00f3 vez. Uma \u00fanica virada de chave pode parecer mais r\u00e1pida, mas maximiza o risco, dando \u00e0s equipes pouca oportunidade de aprender e se adaptar. Uma abordagem faseada faz o oposto, permitindo que as organiza\u00e7\u00f5es aprimorem seu processo antes de migrar sistemas cr\u00edticos para o neg\u00f3cio.<\/p>\n\n\n\n Um programa t\u00edpico de moderniza\u00e7\u00e3o de banco de dados segue tr\u00eas fases:<\/p>\n\n\n\n A execu\u00e7\u00e3o em fases reduz o risco operacional ao mesmo tempo em que melhora a confian\u00e7a na entrega. Mais importante ainda, transforma cada migra\u00e7\u00e3o em uma oportunidade de aprendizado que fortalece a estrat\u00e9gia geral de moderniza\u00e7\u00e3o de aplicativos e o programa de moderniza\u00e7\u00e3o de dados, em vez de tratar o primeiro implantamento em produ\u00e7\u00e3o como o exame final.<\/p>\n\n\n\n Se voc\u00ea estiver pronto para ter uma ideia do seu processo de migra\u00e7\u00e3o, n\u00f3s facilitamos para iniciar uma carga de trabalho piloto no Couchbase Capella<\/a>, nosso DBaaS totalmente gerenciado.<\/p>\n\n\n\n A maioria das equipes trata a migra\u00e7\u00e3o como um processo de via \u00fanica e, assim que a virada de chave come\u00e7a, n\u00e3o h\u00e1 volta. Na realidade, uma estrat\u00e9gia s\u00f3lida de migra\u00e7\u00e3o de banco de dados pressup\u00f5e que o *rollback* pode ser necess\u00e1rio e planeja isso desde o in\u00edcio.<\/p>\n\n\n\n Durante a janela de transi\u00e7\u00e3o e valida\u00e7\u00e3o, tanto o banco de dados legado quanto o de destino devem permanecer sincronizados para que as altera\u00e7\u00f5es possam fluir em ambas as dire\u00e7\u00f5es, se necess\u00e1rio. Essa sincroniza\u00e7\u00e3o bidirecional d\u00e1 \u00e0s equipes tempo para validar o comportamento da aplica\u00e7\u00e3o, o desempenho das consultas e a integridade dos dados antes de migrar definitivamente para a nova plataforma.<\/p>\n\n\n\n Antes de desativar o sistema de origem, estabele\u00e7a pontos de verifica\u00e7\u00e3o claros de consist\u00eancia de dados para verificar se os registros, as transa\u00e7\u00f5es e os resultados dos aplicativos s\u00e3o consistentes em ambos os ambientes. Igualmente importante \u00e9 o controle de roteamento de aplicativos, que permite que o tr\u00e1fego seja redirecionado de volta para o banco de dados legado por meio de altera\u00e7\u00f5es de configura\u00e7\u00e3o ou de infraestrutura, em vez de uma implanta\u00e7\u00e3o de c\u00f3digo de emerg\u00eancia.<\/p>\n\n\n\n Sem planejamento de revers\u00e3o, cada migra\u00e7\u00e3o se torna um evento de alto risco para o neg\u00f3cio. Com ele, a virada de chave se torna um ponto de decis\u00e3o controlado dentro de uma estrat\u00e9gia resiliente de migra\u00e7\u00e3o de dados. O planejamento de revers\u00e3o reduz o risco e, ao mesmo tempo, d\u00e1 aos *stakeholders* a confian\u00e7a de que os problemas podem ser resolvidos sem interromper a produ\u00e7\u00e3o.<\/p>\n\n\n\n A aprova\u00e7\u00e3o executiva pode iniciar a migra\u00e7\u00e3o de um banco de dados legado, mas o patroc\u00ednio sustentado \u00e9 o que a mant\u00e9m no caminho certo. \u00c0 medida que os cronogramas mudam e as prioridades competem, os arquitetos precisam conectar continuamente o progresso t\u00e9cnico a resultados de neg\u00f3cios mensur\u00e1veis.<\/p>\n\n\n\n Um caso de neg\u00f3cios eficaz deve refor\u00e7ar tr\u00eas \u00e1reas:<\/p>\n\n\n\n Em cada marco do projeto, seus arquitetos devem traduzir decis\u00f5es t\u00e9cnicas em termos de neg\u00f3cios que os executivos compreendam. Concentre-se em custos operacionais mais baixos, risco reduzido e entrega mais r\u00e1pida. Manter essa conex\u00e3o durante toda a execu\u00e7\u00e3o pode fazer a diferen\u00e7a entre concluir com sucesso o seu projeto de moderniza\u00e7\u00e3o de dados e perder o \u00edmpeto.<\/p>\n\n\n\nThe data model translation problem most architects underestimate<\/h2>\n\n\n\n
\n
\n
\n
Application modernization strategy: Scoping refactoring before migration starts<\/h2>\n\n\n\n
\n
\n
\n
Phased execution for enterprise database modernization<\/h2>\n\n\n\n
\n
\n
\n
Rollback planning: The gap in most database migration strategies<\/h2>\n\n\n\n
Building the internal business case for legacy database migration<\/h2>\n\n\n\n
\n
\n
\n