Migrazione di database: cinque possibili insidie

I requisiti delle attuali infrastrutture IT sono chiaramente definiti: devono essere veloci, agili, scalabili e altamente disponibili. I sistemi legacy, come i sistemi di gestione di database relazionali (RDBMS), sono sopraffatti da questo a causa delle loro strutture. Sono troppo rigidi e limitati per fornire i dati e le informazioni necessarie per le applicazioni moderne e distribuite in scenari IT ibridi e multi-cloud. La migrazione verso una piattaforma di database flessibile che padroneggia i vantaggi di RDBMS, NoSQL e cloud con edge computing sembra quindi logica e convincente. Tuttavia, questo nasconde aspetti parziali che richiedono molta attenzione per realizzare un cambiamento così moderno nel modo più pulito e con il minor rischio possibile. Secondo Couchbase, un fornitore di una moderna piattaforma di gestione dei dati, ci sono cinque insidie che si nascondono durante una migrazione di database:

1. La migrazione dei dati. È fatale adottare il modello di dati del vecchio sistema di gestione di database relazionale 1:1 quando si passa a un nuovo database (come NoSQL). Per utilizzare correttamente i vantaggi dei moderni database e per essere in grado di supportare nuovi casi d'uso e SLA (Service Level Agreements), è necessario un nuovo modello di dati - proprio come un'auto sportiva ha bisogno di pneumatici adeguati per dispiegare tutto il suo potenziale.
2. La migrazione del framework dell'app. Lo stesso vale per la logica dell'applicazione. Il quadro di programmazione deve essere adattato alle possibilità del nuovo database. Questo riguarda, per esempio, l'adattamento delle librerie di programmazione (SDK) al nuovo database. Se questo non è sufficiente perché il framework nel sistema legacy non è più aggiornato (per esempio Cobol), l'intero framework deve essere sostituito.
3. La migrazione delle applicazioni. Un errore comune è l'approccio big-bang. Proprio come ha poco senso voler subito inseguire i tempi sul Nürburgring con un'auto sportiva appena acquistata, anche il rischio di migrazione dovrebbe essere minimizzato attraverso un approccio successivo. Una migrazione passo dopo passo con un Data Connector bidirezionale tra il vecchio e il nuovo mondo toglie la pressione del tempo e assicura che le operazioni regolari possano continuare indisturbate dal punto di vista dell'utente.
4. L'importanza dei partner di migrazione. Le soluzioni in-house pure sono spesso viste come una presunta prova di qualificazione, ma sono di solito illusorie. L'inclusione di una consulenza esterna con una preziosa conoscenza delle migliori pratiche e delle tipiche fonti di errore può proteggere da percorsi errati, abbreviare il processo di migrazione e quindi in ultima analisi anche aiutare a mantenere i costi sotto controllo. Questa esperienza può essere apportata dai partner del sistema IT o dal produttore del database.
5. I cambiamenti organizzativi. La migrazione tecnica del sistema di database da sola di solito non è sufficiente per raggiungere il supporto previsto per gli obiettivi dell'azienda. Questo richiede anche cambiamenti operativi interni, come un'organizzazione più orientata a DevOps. Questo cambia anche il ruolo classico degli amministratori di database, che diventano più coinvolti nello sviluppo di app con microservizi e automazione CI/CD.

"La migrazione dei database fa parte di un processo completo di modernizzazione delle infrastrutture IT", spiega Steffen Schneider, Head of Solutions Engineering Central Europe di Couchbase. "Le aziende dovrebbero vedere questo come un'opportunità per riposizionarsi tecnicamente e organizzativamente, ma anche in termini di mentalità, e quindi assicurare la loro competitività".

Fonte e ulteriori informazioni: Couchbase