LE NEWS DI JASPIT

Durante le fasi di sviluppo di una mission-critical application fare errori significa spesso dover ricominciare da zero e perdere tempo prezioso. Dunque è essenziale scegliere gli strumenti e le piattaforme giuste per dare buone basi al proprio progetto. Un mission-critical system, o una mission-critical application, è una piattaforma o un sistema informatico di fatto essenziale per la sopravvivenza di un’azienda. Quando un sistema mission critical va in crash, o viene bloccato per qualche motivo, le procedure di Business sono significativamente influenzate e nei casi peggiori forzatamente interrotte.

Alla base di moltissime mission-critical application c’è un buon database open source. Queste tecnologie vengono scelte sempre più spesso per creare piattaforme legate al core business, tuttavia scegliere la giusta soluzione non è semplice, ecco perché in questo articolo vogliamo analizzare i punti chiave da prendere in considerazione durante la selezione di un database per il proprio progetto.

Obbiettivi di un progetto

Esistono diversi fattori rilevanti durante la selezione di un database, ma prima di tutto bisogna tenere in mente l’obbiettivo da raggiungere. In modo da evitare test e innumerevoli configurazioni di prova bisogna sempre tenere in mente lo specifico task che dobbiamo andare a svolgere durante le nostre operazioni. L’obbiettivo primario potrebbe essere la fornitura di un backend standardizzato per il database, che poi potrà anche essere gestito da un team dedicato alla sua manutenzione. In altri casi l’obbiettivo è sostituire un’applicazione ormai obsoleta tramite un backend che sfrutta una nuova tecnologia open source.

Una volta definite le direttive chiave ci si può focalizzare sui bisogni primari, andando a capire ciò di cui si ha bisogno. Questo renderà il lavoro molto più semplice e favorirà il dialogo tra gli sviluppatori e la filiera di aziende che sta dietro allo sviluppo di un applicativo.

Carichi di lavoro

Valutare il carico di lavoro significa eseguire una stima delle operazioni quotidiane che dovrà eseguire il database. Anche se i database open source sono progettati per gestire una vasta gamma di operazioni non è detto che siano ottimizzati per ciò che serve al proprio progetto. Esistono numerosi database che sono specializzati in determinati settori, ad esempio MongoDB è un transactional database che ha la capacità di eseguire il rollback o di annullare un’operazione se non viene completata come previsto (anche se oggi si tratta di una feature molto comune), MySQL ha invece grandi capacità di JSON storage e questo può far comodo a chi preferisce tale formato al classico XML.

A seconda delle feature di un determinato database è meglio optare per l’alternativa che più si adatta alle nostre esigenze. Fare la scelta sbagliata prima o poi porterà a colli di bottiglia che diventeranno irrisolvibili fino a che non si cambierà database.

Non reinventare la ruota

La tecnologia evolve e si sviluppa in modo molto rapido e dall’oggi al domani può nascere un nuovo database open source che si adatta perfettamente alle esigenze del nostro progetto. Quindi nella maggior parte dei casi non è necessario “reinventare la ruota” o sviluppare soluzioni ex novo, visto che quasi sicuramente esistono già database che possono svolgere un compito nel modo che desideriamo.

È estremamente probabile che qualcuno abbia già inventato una soluzione per un determinato problema. Non c’è nulla di male nello sfruttare il bagaglio di conoscenze rappresentato da successi ed insuccessi di altri progetti per determinate quale sia la strada migliore per noi.

Evitare da subito soluzioni complesse

Più sarà complesso il proprio database environment, più sarà difficoltosa la manutenzione e complessa la gestione i costi. E’ possibile ottenere da subito livelli di uptime notevoli e prestazioni elevate, ma spesso ciò questo porta alla creazione di un sistema poco pratico e difficile da adattare quando si incontrano problemi.

Booking.com è arcinoto per essere uno dei migliori portali dove prenotare un hotel, ma non molti sanno che le sue performance sono dovute ad un immenso database MySQL. Il database dell’azienda adottava inizialmente una semplice architettura master–replica e via via si è andato evolvendo introducendo sistemi di load balancer. L’architettura generale è rimasta però abbastanza semplice, non si è dunque partiti subito con qualcosa di complesso, anzi, per gestire gli immensi carichi di lavoro si è rimasti ben ancorati ad una struttura facile da mantenere e da sistemare in caso di inconvenienti.

Chiedi ad un esperto

Quando si ha un dubbio è meglio rivolgersi direttamente una persona che abbia esperienza diretta, magari comprovata dal suo curriculum. Uno dei punti forti della community open source è che si trova sempre qualcuno disposto a condividere le sue conoscenze e competenze o che, magari, l’ha già fatto su uno dei tanti portali o forum dedicati ad un argomento.