Portare l’applicazione in cloud: Object Storage
Proponiamo un ciclo di articoli dedicato a sviluppatori che vogliono approfondire l’uso della tecnologia cloud e il concetto di scalabilità orizzontale: vediamo come passare da un’applicazione tradizionale ad un’applicazione cloud-oriented.
Clicca qui per leggere l’articolo precedente!
In questo articolo analizziamo il primo step del processo necessario a portare un’applicazione tradizionale in cloud. Nello specifico, parliamo di come rendere l’applicazione meno dipendente dal file system, cioè il server (fisico o virtuale).
Introduzione all’Objective Storage
Per intraprendere questo primo passo dobbiamo introdurre un servizio: l’Object Storage, che in Amazon Web Services si chiama S3 (Simple Storage Service). L’Object Storage è il supporto in cui le applicazioni vanno a salvare qualsiasi file venga generato o caricato per essere messo a disposizione dall’applicazione stessa. Può essere utilizzato anche da applicazioni che NON sono installate in cloud: per questo lo consideriamo come il primo step del processo.
Quindi: interveniamo sulla nostra applicazione, installata normalmente in uno o più enterprise server siano essi fisici o virtuali, e facciamo in modo che i file usati dall’applicazione (vedi sopra) non siano più nel file system dei nostri server, ma siano condivisi tramite questo Object Storage.
Questo passaggio va effettuato tramite modalità che rispettino le caratteristiche dell’applicazione. Tuttavia, esistono decine di librerie compatibili con S3, praticamente in tutti i linguaggi di programmazione esistenti usati per il web.
Nel peggiore dei casi, è possibile implementare le specifiche perché, sostanzialmente, si può accedere ai file presenti sul file system con delle richieste HTTP ormai consolidate e standardizzate (S3 è infatti uno dei primi servizi che AWS ha messo a disposizione, già nel 2007). Se devo ottenere un certo file uso un GET, se devo crearlo uso un POST, e così via.
Un client molto famoso per ruby è https://github.com/fog/fog-aws, ma il funzionamento è analogo per altri client in altri linguaggi.
Nuove gestione dei file e backup (quando serve)
Una volta concluso questo passaggio, dobbiamo aggiornare anche il nostro sistema di gestione dei file: ogni volta che creiamo un file e ogni volta che importiamo un file (in modo persistente o transiente) dobbiamo farlo transitare su S3.
In questo modo sarà accessibile dal nostro application server ovunque questo si trovi (in cloud o in enterprise).
Abbiamo aggiornato la gestione dei file e migrati i file pre-esistenti?
Adesso potremmo avere bisogno di storicizzare i file, ossia di avere un livello di backup: la presenza o meno di questa necessità dipende dalla tipologia dei file e dalla tipologia di bucket utilizzata; i bucket sono infatti automaticamente ridondati su tutta la region, quindi su almeno tre differenti location.
Tuttavia, può sempre essere utile fare un pensierino su Glacier e sapere come funziona!
Se invece preferiamo muoverci con maggiore cautela e approfondire questi concetti, possiamo usare Minio, un progetto open source che consente di installare un servizio locale compatibile con S3 e può essere installato anche su un cluster EKS.
