Tutto evolve. Persone, culture, comportamenti, pensieri. La nostra specie è destinata a cambiare costantemente. L’enterprise IT ne è un esempio perfetto. Il desiderio di avere qualcosa di meglio ha portato al passaggio dal bare metal alle macchine virtuali (VM) che permettono alle aziende di utilizzare al meglio le risorse per molteplici applicazioni con interdipendenze. Tuttavia, poiché molte applicazioni e microservizi cloud-native moderni richiedono agilità e una più granulare allocazione delle risorse, le VM possono diventare ingombranti e inefficienti, indebolendo il desiderio dello sviluppatore moderno di disporre di maggiori velocità ed efficacia.
L’avvento dei container ha indirizzato molti dei compromessi legati alle VM, ma la loro natura effimera e il focus sulle applicazioni stateless hanno fatto sì che una funzionalità importante fosse tralasciata: lo storage.
Persi in un container
I container sono stati creati inizialmente come stateless tool senza pensare allo storage. Dal loro avvento però, molti sviluppatori hanno capito che il desiderio di soluzioni piccole, leggere e portatili in grado di girare praticamente ovunque richiede uno storage persistente.
Molte applicazioni devono sempre persistere in termini di stato, dati e configurazione. Pensiamo a ciò che potrebbe succedere se facessimo girare un servizio come Lyft (servizio di condivisione di autovetture) e, durante il percorso, l’applicazione cloud-native si perdesse in un container e dovesse ripartire altrove. Senza uno storage persistente, si perderebbero i dati della corsa del cliente — problema per il cliente, ma molto più serio per l’autista. Qualunque sviluppatore o individuo che utilizza un database NoSQL riconoscerà che lo storage persistente è necessario per le loro stateful application.
I monoliti non sono stati creati per i microservizi
Purtroppo, i monolitici storage array tradizionali non sono stati realizzati pensando alle applicazioni moderne. Sono difficili da scalare e la capacità storage locale limitata. Le unità storage tradizionali sono inoltre costose da mantenere e aggiornare. Alcune, a seconda dell’età, potrebbero non essere più manutenute o aggiornate, e la maggior parte ha costi operativi elevati.
I container hanno bisogno di uno storage molto elastico e persistente e questo ha portato a un’ulteriore evoluzione nella quale gli sviluppatori hanno iniziato a integrare lo storage consumato dalle loro applicazioni, assicurandosi che siano in grado di gestirlo e utilizzarlo all’interno dei loro container. Il software-defined storage (SDS) permette alle applicazioni e ai componenti dello storage management di operare fianco a fianco all’intero del container. In questo modo si rende disponibile uno storage persistente per il container, garantendo che anche nel caso in cui il container o l’applicazione spariscano, i dati restano.
Un unico pannello di controllo? Sì grazie
Nonostante la disponibilità di container con storage persistente sia indubbiamente un traguardo, non è la sola innovazione resa disponibile dall’integrazione di storage e applicazioni nella stessa location. Tradizionalmente, la gestione dello storage era in mano agli storage administrator, ma avere lo storage e le applicazioni nello stesso container offre un unico pannello di controllo e gli sviluppatori possono così gestire entrambi. Non devono più preoccuparsi di incoerenze nello storage persistente tra ambienti di sviluppo, test e produzione; hanno un controllo molto più granulare, permettendo loro di massimizzare le performance del container e ottenere maggiore disponibilità.
In passato, quando uno sviluppatore aveva bisogno di più storage, doveva farne richiesta in anticipo allo storage admin. Così facendo però, doveva cercare di prevedere quanta capacità sarebbe stata necessaria — operazione impossibile perché non si può prevedere se un’applicazione avrà cinque o cinque milioni di richieste. Lo sviluppatore potrebbe quindi tendere a sovrastimare, portando potenzialmente lo storage administrator a sostenere che non c’è storage sufficiente per le sue esigenze e che quindi deve attendere il prossimo storage upgrade. Oppure, potrebbe essere sufficiente, ma far nascere il dubbio del perché un’azienda stia considerando una capacità storage così elevata. In entrambi i casi, questa richiesta espone le limitazioni di budget, efficienza, processi e scalabilità dello storage tradizionale per lo sviluppo di applicazioni moderne.
Il SDS aperto può abilitare lo sviluppatore a scalare le sue richieste storage in base all’applicazione. Avvalendosi di un orchestration framework come Kubernetes, è possibile scalare lo storage verso il basso o verso l’alto senza aprire un ticket con lo storage administrator; riducendo i tempi da ore a pochi secondi; ottimizzare la capacità ed evitare l’over-provisioning, tutto all’interno di un unico orchestration framework per la gestione di applicazioni, storage e infrastruttura. Oltre a contare sulla stessa esperienza utente dinamica, resiliente e agile indipendentemente da dove si decida di implementarle: bare metal, VM, o un’infrastruttura public o private cloud.
La prossima evoluzione
Gli sviluppatori hanno da sempre guardato allo storage con un senso di trepidazione. Era percepito come importante, ma potenzialmente causa di rallentamenti, un male necessario. Ma l’avvento dei container e del SDS ha portato molti di essi non solo ad abbracciare lo storage ma a contribuire a nuovi e interessanti progetti e strumenti che lo integrano nel processo di sviluppo applicativo. Sono passati dalla realizzazione di cose molto grandi che richiedono pianificazione, revisioni e dispendio di capitali, alla creazione di applicazioni e servizi agili e leggeri che, lavorando insieme, sono diventati qualcosa di più grande e migliore di quanto avessimo prima — la reale definizione dell’evoluzione. Così facendo, non solo stanno crescendo loro, ma offrono alle loro aziende modi più agili, efficienti e convenienti di realizzare e gestire applicazioni e storage.
Siamo ancora all’inizio di questo processo evolutivo, quindi gli sviluppatori hanno una grande opportunità di definire dove andremo, ma significa anche che le aziende devono operare una scelta in tema di processi storage. Sceglieranno le metodologie storage tradizionali che utilizzano da anni o prenderanno in considerazione il passaggio a un approccio SDS moderno che consentirà loro di massimizzare il ROI su VM e container?
Sceglieranno l’evoluzione?
*Irshad Raihan è product manager in Red Hat Storage
