La creazione e la gestione di applicazioni cloud native richiedono un cambio di prospettiva netto nelle modalità con cui si approcciano e si sviluppano progetti digitali.
La collaborazione tra sviluppatori e IT Operations, i cosiddetti
DevOps, permette una distribuzione ininterrotta di aggiornamenti incrementali, con meno rischi per i clienti e feedback continui. Se lo sviluppo di applicazioni cloud native ha ancora molto in comune con il ciclo di vita dello sviluppo software tradizionale, per altri aspetti ne diverge concretamente, anche nei termini. Ecco perché abbiamo pensato questo glossario, per spiegare meglio la terminologia alla base dello sviluppo delle applicazioni cloud native.
Monolite
Un'applicazione monolitica è un programma eseguibile distribuito come singola entità, che include tutte le funzionalità: dall'interfaccia utente al codice di accesso ai dati, ecc. L'avvio di una nuova applicazione come entità singola è più facile da sviluppare, distribuire e testare. Non essendo modulare è difficile da aggiornare, ridimensionare, anche nello stack tecnologico.
Container
I container sono pacchetti di software che contengono file di configurazione, librerie, dipendenze, ecc., ossia tutti gli elementi necessari per essere eseguiti su qualsiasi infrastruttura, astraendo il livello dell'applicazione. Tradizionalmente le applicazioni venivano sviluppate in un ambiente informatico specifico e spesso presentavano bug quando venivano eseguite in un ambiente diverso.
Utilizzando un'architettura containerizzata, gli sviluppatori possono creare un
ambiente di lavoro leggero, rapido nell’avvio e nello spegnimento, facilmente
modificabile in base alle esigenze, altamente
portatile e quindi con
meno rischi di errori.
La separazione data da questo “involucro”, infine, permette alle applicazioni eseguite al suo interno di svolgere i loro compiti in maniera sicura e senza che ci si debba preoccupare dell’ambiente esterno.
Un'altra opzione per ridurre la complessità della gestione dell'infrastruttura dei container consiste nell'utilizzare
container-as-a-service (Caas). Si tratta di un servizio basato su cloud, a consumo, che offre alle organizzazioni un sistema per gestire le applicazioni virtualizzate, eliminando così la necessità di gestire gli elementi di supporto dell'infrastruttura del contenitore come cluster e macchine virtuali.
Serverless
Il termine serverless rimanda a un modello di cloud che consente di creare ed eseguire applicazioni senza entrare in contatto con il server sottostante. In questo tipo di ambiente il server è comunque presente ma il provisioning, la scalabilità e la gestione fanno capo al Cloud Provider.
Ne consegue che con le funzioni serverless si fa un ulteriore passo avanti nell'astrazione e si elimina la necessità di gestire qualsiasi infrastruttura: tutto ciò di cui si ha bisogno è il codice che si vuole eseguire e
il fornitore di servizi cloud si occupa del resto. Gli sviluppatori devono semplicemente creare pacchetti di codice all'interno di container per il deployment.
DevOps e CI/CD
La metodologia DevOps consiste in un approccio allo
sviluppo applicativo (inteso come automazione e progettazione) delle piattaforme migliore e più efficace sia in termini di rapidità dei rilasci, siano essi prodotti o funzionalità software ex novo o aggiornati, sia di valore sia di qualità, il tutto reso possibile da un’erogazione rapida e iterativa dei servizi IT. Infatti il termine "DevOps" combina "Development" (sviluppo) e "Operations" (operazioni), ma va ben oltre il semplice significato di questi due termini; nella pratica i developers, che solitamente creano codici in un ambiente di sviluppo standard, lavorano a stretto contatto con il personale IT operativo (Operations) per velocizzare le fasi di creazione, collaudo e rilascio dei software, senza rinunciare all'affidabilità e alla sicurezza. Tornando al glossario cloud native, l’approccio DevOps permette di coniugare le applicazioni esistenti con le più moderne infrastrutture e app cloud native.
Figlio del DevOps è il metodo CI/CD che consiste nell’automazione costante (in tutte le fasi di sviluppo applicativo) e il monitoraggio continuo delle app: dalle fasi di integrazione e test a quelle di distribuzione e deployment, per consentire la distribuzione frequente delle applicazioni ai clienti.
Open Source Software
Codice sorgente che chiunque può visualizzare, modificare e migliorare. Rappresenta oltre
l'80% della base di codice delle applicazioni moderne, diverso dal software proprietario utilizzabile, modificabile, migliorabile o dai “proprietari” del codice o in seguito a un accordo commerciale. Per assicurarsi che i componenti open source (e i relativi sottocomponenti) inseriti nella base di codice di un'organizzazione siano privi di vulnerabilità e altri problemi, gli strumenti di analisi della composizione del software sono una scelta comune.
Object Storage
Conosciuto anche come storage basato su oggetti (anziché file system e blocchi di dati), l'object storage è un’architettura che archivia dati non strutturati, infatti risulta particolarmente utile nel supportare applicazioni cloud native che richiedono
un'infrastruttura di supporto scalabile e flessibile.
Workload
Il carico di lavoro è un termine generico per
applicazioni o calcolo in esecuzione nel cloud. Si è evoluto dalle macchine virtuali per includere container, funzioni serverless, database e altri servizi che consumano risorse basate su cloud. I servizi di carico di lavoro cloud tradizionali ora offrono molte più scelte tra sistemi operativi, tipi di processore e configurazioni del processore, persino adattando le offerte di elaborazione per l'intelligenza artificiale, l'apprendimento automatico e il calcolo ad alte prestazioni (HPC).
I vantaggi del
cloud computing ibrido sono molti, ma ci sono nuovi rischi e minacce. Le organizzazioni devono garantire che i requisiti di conformità siano soddisfatti mantenendo la sicurezza unificata su tutti i carichi di lavoro: server fisici, virtuali, cloud o container.
Virtual Private Cloud e Virtual Network
L'utilizzo di
reti private nel cloud pubblico consente agli utenti di distribuire le risorse in una rete virtuale definita, vagamente simile a una rete tradizionale in stile data center.
Le risorse nella rete privata sono isolate dalle altre risorse nel cloud pubblico. Questa operazione viene eseguita mediante il provisioning di sottoreti, intervalli riservati di indirizzi IP che fungono da sezione divisa della rete del cloud pubblico per uso privato e LAN virtuali come parte della rete virtuale. Le reti virtuali possono essere ulteriormente personalizzate con tabelle di routing e traduzione degli indirizzi di rete. Le VPN possono anche essere utilizzate per collegare l'infrastruttura locale alla rete virtuale nel cloud tramite una connessione privata e sicura.
Microservizi e API
Un'applicazione basata su microservizi è costituita da
componenti indipendenti, ognuno dei quali
esegue un processo dell'applicazione come servizio. Sono liberamente accoppiati e comunicano tramite API. L’abbinamento rende più semplice apportare modifiche e aggiungere servizi senza influire sull'intera base di codice. Un'architettura di microservizi è importante: senza di essa è possibile sfruttare le tecnologie native del cloud, come i container, ma senza giovare di molti dei vantaggi di un'architettura specifica di nuova generazione.
Infrastructure as code (IaC)
Le applicazioni native del cloud in genere richiedono che l'infrastruttura cloud di supporto funzioni correttamente. L'
infrastruttura come codice (IaC) consente di eseguire automaticamente il provisioning di ciò che è necessario per un’applicazione. Poiché IaC è solo codice (in un modello), è possibile applicare i processi DevOps in modo simile per la distribuzione automatizzata, coerente e ripetibile dell'infrastruttura cloud, che viene continuamente migliorata e distribuita. Ciò consentirà la prevenzione automatizzata e proattiva delle configurazioni errate e darà la tranquillità che il codice alla base dell’infrastruttura cloud sia completamente conforme e allineato alle best practice del settore.
Repository
I repository di codice conservano tutto il codice, la documentazione, le note e altre risorse che supportano un progetto di sviluppo software. I repository privati sono
accessibili solo a chi è all'interno dell'organizzazione. In genere, il codice personalizzato o proprietario viene conservato in un repository privato per impedire al pubblico o ai concorrenti di accedere a queste informazioni. Gli archivi pubblici sono accessibili e spesso prevedono la collaborazione/l'input di un'ampia gamma di persone, come una community. Il vantaggio è che si può risparmiare tempo nello sviluppo di codice personalizzato: parte di ciò che si sta cercando potrebbe già esistere in un repository pubblico.
Scopri l’offerta Aruba Enterprise per il cloud native