Risultati
37 risultati
-
italia
5.1 Metodologia di lavoro
La pratica della retrospettiva è stata introdotta per rispondere alla necessità di effettuare riflessioni regolari sull’andamento del progetto, in modo da correggerne il funzionamento prima che sia finito. Questo in contrasto con le tradizionali review post-mortem, che danno informazioni utilizzabili solo in progetti seguenti e che non aiutano dunque a raggiungere il successo nei progetti in corso. La retrospettiva è conosciuta come pratica della metodologia Agile in quanto uno dei principi del manifesto Agile è incentrato proprio sulla riflessione in team: «Ad intervalli regolari il team riflette su come diventare più efficace, dopodichè regola e adatta il proprio comportamento di conseguenza.». Lo scopo generale di una retrospettiva è stimolare l’analisi e la riflessione e incoraggiare il miglioramento continuo. In particolare, gli obiettivi sono:. aumentare il livello di interazione e condivisione del team. identificare cosa è andato bene e cosa non ha funzionato in relazione a processi, strumenti e dinamiche di gruppo. discutere e scoprire opportunità di miglioramento e definire un piano d’azione per implementarlo. enfatizzare e dare uguale tempo di valutazione e condivisione a ciò che andato bene. È importante concentrarsi sul positivo e identificare ciò che è andato bene in modo da continuare a farlo. La retrospettiva è un modo per spronare i membri del team a riflettere su quello che succede intorno a loro nel corso del progetto e ad identificare azioni che possano migliorare sia il processo che l’esecuzione. In concreto, si tratta di un incontro di circa un’ora che si tiene alla fine di una iterazione durante il quale il team riflette su quanto accaduto durante l’iterazione appena trascorsa e individua le azioni per migliorare la successiva. Si consiglia di eseguire la retrospettiva con regolarità includendo sia il team tecnico dell’amministrazione che il team tecnico del fornitore. Per eseguire una retrospettiva efficace è importante trovare la tecnica ed il formato più adatto al contesto. Per approfondire puoi consultare il libro di Esther Derby “Agile Retrospectives: Making Good Teams Great” o altre risorse disponibili online, come ad esempio questo articolo ...
-
italia
6.4 La validazione
Questo tipo di test sono utilizzati quando più applicativi sono interconnessi: quando un applicativo è impattato dalla migrazione, tutti gli applicativi che ne dipendono sono anch’essi impattati. Le tecniche di testing adottate sull’applicativo i cui dati sono stati migrati possono essere utilizzate per validare il funzionamento anche degli applicativi che dipendono da esso ...
-
italia
6.2 Buone pratiche
Nella migrazione si consiglia di utilizzare le seguenti buone pratiche:. trasferire i dati utilizzando la connessione internet se la loro dimensione è ragionevole rispetto alla connessione disponibile; utilizzare una connessione diretta con la piattaforma cloud per grandi quantità di dati;. utilizzare una connessione sicura durante il trasferimento dei dati verso il sistema di destinazione in modo da proteggere le informazioni sensibili. utilizzare i servizi di migrazione dei dati forniti direttamente dal cloud provider, se disponibili. assicurarsi che i dati nel database sorgente non possano essere modificati durante tutto il processo di migrazione e di validazione. comparare i tempi di esecuzione di un insieme di query sul sistema sorgente con quelli del sistema di destinazione per capire l’impatto sulle performance. suddividere la migrazione di tabelle con grandi quantità di dati in parti più piccole per migliorare le performance nel trasferimento. verificare che l’applicazione funzioni correttamente dopo la migrazione ...
-
italia
6.1 La preparazione
Prima di iniziare la migrazione vera e propria di un applicativo e dei suoi dati verso una piattaforma in cloud, è necessario considerare una serie di attività preparatorie, in modo da ridurre il rischio di problemi nella transizione che porterebbero ad un conseguente aumento dei tempi per poterla portare a termine. Le attività preparatorie mirano ad identificare eventuali problematiche da analizzare e risolvere prima di proseguire. La mancata risoluzione di queste potrebbe essere anche motivo per valutare una differente strategia di migrazione. Quando si vuole migrare un applicativo in cloud è importante seguire le seguenti buone pratiche:. assicurarsi che sia possibile fare import ed export di tutti i dati attraverso funzionalità proprie del database di destinazione o strumenti specifici del provider cloud ...
-
italia
4.1 Le strategie di migrazione
La strategia di Re-architect ha come obiettivo quello di ripensare significativamente l’architettura core di un applicativo in ottica cloud, attraverso un processo di redesign iterativo ed incrementale che miri ad adottare appieno i servizi cloud-native offerti dai cloud service provider per massimizzare i benefici che ne derivano. Esempi di redesign dell’architettura riguardano:. l’adozione di lambda-function per scomporre un applicativo in modalità service-oriented sfruttando la capacità di autoscaling che dimensiona l’utilizzo sulla base del traffico effettivo. l’utilizzo di API gateway per definire ed esporre interfacce applicative pubbliche o ad accesso controllato per favorire l’interoperabilità con sistemi esterni. la trasformazione dell’applicativo in componenti stateful e stateless, ovvero con o senza stato interno persistente, per poter configurare lo scaling e l’availability in modo differenziato e sfruttare quindi in modo ottimale le risorse non essendo costretti ad un dimensionamento basato sul caso peggiore. la creazione di un layer di integrazione che permetta di rimuovere la necessità di duplicazione dei dati tra applicativi diversi, consentendone il recupero direttamente dalla sorgente primaria. La strategia di re-architect, rispetto alle altre viste finora, permette di massimizzare lo sfruttamento delle potenzialità del cloud in termini di scalabilità, ridondanza, continuità del servizio, costi infrastrutturali e di gestione, ecc. Essa è al tempo stesso la più complessa da condurre in quanto richiede una conoscenza specialistica della piattaforma cloud utilizzata, ovvero principi di design cloud-native, metodologie consolidate di test coverage, test automation, refactoring o trasformazione del codice sorgente in modo controllato. Possiamo rappresentare il re-architect con il seguente diagramma:. Benefici. maggiore riduzione delle risorse utilizzate a livello di infrastruttura e delle attività per la loro gestione rispetto a re-host e re-platform nel breve e medio periodo. ottimizzazione dei costi nel lungo termine grazie all’utilizzo delle risorse basato sull’effettiva necessità e non su quella prevista. migliore sfruttamento delle caratteristiche proprie del cloud come disponibilità, scalabilità, osservabilità, resilienza, provisioning delle risorse. miglioramento delle modalità di sviluppo e validazione attraverso strumenti avanzati per la sperimentazione come l’A/B testing e deployment indipendenti delle componenti applicative. responsività alle variazioni di carico impreviste grazie ad uno scaling in real time. incremento della sicurezza grazie alla disponibilità di funzionalità avanzate. Rischi. difficoltà nel reperire le competenze necessarie per le trasformazioni che si vogliono operare, principalmente legate alla conoscenza dei sistemi in cloud, tecniche di refactoring e principi di design di applicativi cloud native. aumento del rischio di instabilità dell’applicativo in caso di trasformazioni multiple contemporanee: è altamente raccomandato di prioritizzare solo le trasformazioni che portano ad un beneficio tangibile ed applicarle in modo iterativo e controllato per validarne l’effetto. rischio di significativo lock-in con il cloud service provider. Caratteristiche degli applicativi migrabili con re-architect. Di seguito una lista di caratteristiche che permettono di identificare gli applicativi la cui migrazione in cloud può essere preferibile con un approccio re-architect:. centralità nella strategia di trasformazione digitale dell’ente. necessità di un ammodernamento tecnologico e riduzione del debito tecnico per facilitare evoluzioni future. bisogno di aumentare e ridurre la capacità di gestione del traffico per rispondere a necessità contingenti e variabili. necessità di adeguamento alle linee guida del nuovo modello di interoperabilità del sistema informativo della PA. Caratteristiche sul scheda di assessment dell’applicativo. Rispetto al scheda di assessment dell’applicativo compilata nella fase di assessment vi sono determinate caratteristiche che rendono un servizio candidabile per questa strategia. Evoluzione del servizio nei prossimi 3 anni per valutarne l’importanza e l’opportunità di investimenti sull’applicativo. Stack tecnologico per valutare la necessità di ammodernamento. Uso di componenti sostituibili con l’equivalente servizio cloud-native. Criticità per identificare opportunità di miglioramento strutturale della soluzione. Periodi di utilizzo per valutarne la variabilità e confronto tra # medio di utenti e # massimo e minimo di utenti con l’obiettivo di identificare scostamenti rilevanti. Utilizzo effettivo delle componenti infrastrutturali in confronto al dimensionamento delle componenti infrastrutturali per valutare un sovra o sotto dimensionamento. Connettività minima necessaria = internet. Modificabilità del codice sorgente = parziale o completa. Presenza di test di validazione per verificare il miglioramento apportato dalle modifiche intraprese e ridurre il rischio di regressione durante il processo. Disponibilità di documentazione tecnica che supporti il processo di rifattorizzazione. Queste caratteristiche evidenziano un applicativo centrale per la visione strategica dell’amministrazione giustificandone l’investimento in tempo, competenze e costi per un redesign dell’architettura possibile grazie alla proprietà del codice sorgente o alla capacità di influenzare la roadmap evolutiva definita dal produttore ...
-
italia
7.1 Verifica degli indicatori di performance
Oltre agli indicatori di risultato, vanno anche considerati i benefici più ampi del cloud, come l’agilità e le migliori prestazioni delle applicazioni, che forniscono valore a lungo termine all’amministrazione. 7.1.2.1 Governance. Il cloud è un ambiente complesso e dinamico. È incredibilmente facile creare nuove risorse infrastrutturali per i servizi dell’amministrazione ma è altrettanto facile perdere di vista la loro esistenza senza una buona governance del cloud atta mantenere sotto controllo i costi e la sicurezza. visibilità sul cloud: vi è piena visibilità sull’inventario cloud? È noto dove si stanno spendendo i soldi? Esiste un quadro completo delle misure di sicurezza?. controllo dei costi: si sta facendo un uso efficiente dell’infrastruttura cloud? È possibile identificare le risorse inutilizzate e sottoutilizzate?. precisione dei rapporti: i rapporti sui costi sono più accurati? Quanto spesso è necessario correggere gli errori nei rapporti?. cicli di audit interno: ci vuole più o meno tempo per controllare i costi IT?. conformità: il cloud soddisfa gli obiettivi di conformità? È possibile ospitare carichi di lavoro che trattano dati sensibili?. 7.1.2.2 Agilità e prestazioni. Un miglioramento del servizio IT e della sua gestione non solo dimostrano che la migrazione in cloud sta producendo risultati tangibili ma è anche un chiaro segno che lo staff è motivato, condivide la visione e ha compreso il valore del cloud. obiettivi di prestazione: quali sono gli obiettivi di prestazioni IT? Le prestazioni delle applicazioni sono in linea con le aspettative? Ed i il numero di incidenti, guasti e richieste di modifica? Quanto spesso è necessario implementare correzioni di codice e miglioramenti delle applicazioni?. disponibilità del servizio: l’ambiente cloud è più robusto? Quante interruzioni di servizio si sperimentano? E quanto durano?. impatto sul mercato: quali nuovi servizi sono stati sviluppati? Si assiste ad un time to market più veloce?. open source: si sfruttano le tecnologie open source? Riducono il carico di lavoro dei team di sviluppo e operations?. 7.1.2.3 Automazione. I processi automatizzati riducono il carico di lavoro manuale sulla gestione dell’infrastruttura, aiutano a rimanere in controllo di infrastrutture complesse e dinamiche e forniscono risposte immediate ad eventi come modifiche alla configurazione o improvvisi aumenti del carico di lavoro. ottimizzazione delle risorse: si stanno acquistando risorse infrastrutturali dimensionate correttamente rispetto ai bisogni? È possibile ridimensionarle a seconda del carico? È necessario mantenere le risorse attive durante le ore non di punta? È possibile sfruttare l’automazione per eseguire automaticamente queste funzioni?. 7.1.2.4 Soddisfazione degli utenti dei servizi. Modernizzando il reparto IT, rendendo efficienti i costi e rinnovando le applicazioni legacy, è possibile ribaltare i benefici del cloud sugli utilizzatori degli applicativi attraverso una migliore esperienza utente e funzionalità prima non attuabili. latenza delle applicazioni: la velocità con cui gli applicativi in cloud rispondono alle interazioni degli utenti, rispetto alla controparte on-premise. ticket al servizio di supporto: vi sono meno richieste grazie alla stabilità e scalabilità del cloud?. tempo di risoluzione dei ticket: in cloud vi è la possibilità di operare sulla propria infrastruttura in maniera più avanzata. È importante misurare l’impatto di questo cambiamento sull’operatività del supporto tecnico. sondaggi sulla soddisfazione degli utenti: le risposte indicano eventuali problemi nel servizio? ...
-
italia
7.2 Monitoraggio di nuove soluzioni SaaS aggiunte al Cloud Marketplace
Come illustrato più volte in questo documento, il principio “Cloud First” nel contesto del programma di abilitazione al Cloud delle PA, prevede che le pubbliche amministrazioni che si apprestano a migrare i propri applicativi in cloud valutino in prima istanza la presenza di servizi SaaS nel catalogo dei servizi cloud qualificati da AGID (Cloud Marketplace). Lo sviluppo del mercato dei prodotti software verso la modalità SaaS, infatti, offre un costante aumento di soluzioni in cloud che possono rimpiazzare software precedentemente disponibile solo on-premise con la corrispondente versione cloud-native realizzata dal medesimo produttore o con soluzioni equivalenti o migliorative proposte da nuovi soggetti. Adottando, ove possibile, la strategia di Sostituzione o Re-purchase, presentata in dettaglio nel capitolo 4.1.3, le pubbliche amministrazioni possono godere dei benefici del cloud da subito con ridotti costi iniziali. All’interno del Cloud Marketplace è possibile ricercare i servizi SaaS qualificati e visualizzarne la scheda tecnica che mette in evidenza le caratteristiche tecniche, il modello di costo e i livelli di servizio dichiarati dal fornitore in sede di qualificazione. Poiché il mercato è in continua evoluzione ed il Cloud Marketplace è continuamente in aggiornamento, si raccomanda di monitorare attivamente e con cadenza regolare questo catalogo per assicurarsi che le nuove soluzioni aggiunte vengano considerate per la migrazione dei servizi ancora non prioritizzati (vedi capitolo 3.2 per il processo di prioritizzazione) ...
-
italia
3.2 Scheda di assessment dell’applicativo
Le informazioni riguardo al mercato aiutano ad esplorare le opportunità presenti sul mercato per una migrazione al cloud dell’applicativo. I campi da riempire in questa sezione sono:. Alternative SaaS: esistenza di alternative SaaS per l’applicativo in analisi all’interno del Cloud Marketplace di AGID. Disponibilità di import dei dati: garanzia che il fornitore SaaS provveda la possibilità di importare i dati all’interno del servizio SaaS tramite formati pubblici e aperti ...
-
italia
3.1 Costruire una mappa degli applicativi e dei servizi attivi
Come decidere ora l’ordine con cui migrare le applicazioni nel cloud? È una domanda molto importante, perché un successo iniziale durante la migrazione al cloud è fondamentale per continuare il percorso di adozione del cloud. Viceversa, un insuccesso precoce può pregiudicare la prosecuzione. Benché i vantaggi del cloud siano chiari, osservare e analizzare in dettaglio gli aspetti di ogni applicazione che è stata creata o implementata nell’organizzazione può essere complicato e dispendioso in termini di tempo. Sebbene non esista una risposta valida per tutti gli scenari, esistono alcune buone pratiche che è possibile utilizzare per iniziare a fare una valutazione di alto livello sull’ordine con cui migrare gli applicativi. Questo tipo di pianificazione anticipata può semplificare il processo di migrazione e rendere più fluida l’intera transizione cloud. Il seguente framework aiuta ad identificare l’ordine con cui procedere con la valutazione di dettaglio (vedo 3.2) per la migrazione degli applicativi. Esso si basa su quattro livelli di priorità come illustrato nel seguente grafico:. I software con “opportunità da cogliere” hanno una priorità maggiore rispetto a quelli con “rischio minimo” che a loro volta sono da privilegiare rispetto agli applicativi “semplici da migrare”. I software che non rientrano in nessuno dei livelli precedenti sono da considerare per ultimi. Identificare per ogni software presente nella lista il livello di priorità. Tale livello può essere identificato sulla base dei principi specificati nelle sezioni seguenti ed utilizzando le domande proposte come esempi. Si raccomanda di considerare i molteplici aspetti che le domande fanno emergere nell’insieme per valutare l’appartenenza al livello. Procedere, per uno specifico applicativo, in modo sequenziale partendo dal livello di priorità più alta (“opportunità da cogliere”) fino a quello a priorità più bassa (“altro”). Se il software può essere considerato per il livello di priorità in esame, si passa all’applicativo successivo ripartendo dal livello a priorità più alta. Un applicativo può logicamente ricadere in più livelli: va associato solo al livello di priorità più alta tra quelli applicabili. Una volta completata la classificazione degli applicativi sui quattro livelli, procedere con lo step successivo per gli applicativi appartenenti al livello di priorità più alto (non necessariamente in modo contemporaneo). In caso ad un livello appartengano un numero significativo di applicativi è raccomandato di iterare la prioritizzazione utilizzando le dimensioni a priorità inferiore, ad es. se il livello “opportunità da cogliere” ha decine di applicativi, si può raffinare la prioritizzazione considerando per ognuno il livello di rischio, identificando quelli a rischio minimo. Se necessario, si può ulteriormente raffinare dando priorità, tra quelli con opportunità da cogliere e rischio minimo, a quelli più facili da migrare. 3.1.3.1 Livello 1: opportunità da cogliere. Gli applicativi che si consiglia di approfondire per primi per la migrazione sono quelli che a oggi hanno maggiori opportunità di trarre vantaggio (soprattutto in termini di costi) dal cloud. Ecco alcune domande da porsi per identificare gli applicativi appartenenti a questo livello:. Si prevedono significativi risparmi di costi con la migrazione al cloud di questo applicativo? Ad es. La licenza software è in scadenza?. Si può risparmiare sulle spese per le strutture, l’alimentazione ed il raffreddamento?. Si può risparmiare sui costi di connettività?. È necessaria una soluzione di disaster recovery?. Adotta già una soluzione di disaster recovery onerosa?. Questo applicativo richiede un aggiornamento hardware imminente che rende più interessante il passaggio al cloud prima piuttosto che più avanti nel tempo?. Questo applicativo richiede un incremento delle risorse hardware?. Questo applicativo richiede frequente manutenzione hardware?. Ci sono applicativi nel cloud (soluzioni Saas) che renderebbero questa applicazione notevolmente migliore?. Ci sono requisiti di conformità normativa per questa applicazione non ancora soddisfatti che possono essere risolti sul cloud?. Identificare questi applicativi, primi candidati per la migrazione, permetterà all’amministrazione di ottenere successi rapidi che producono vantaggi tangibili e immediati per gli utenti e l’organizzazione stessa. 3.1.3.2 Livello 2: ridurre al minimo il rischio di migrazione. Laddove il primo livello si concentra sulle opportunità, il secondo livello si concentra sul rischio. Quali applicazioni puoi spostare con un rischio relativamente basso per la continuità del servizio? Ci sono una serie di domande che l’IT può farsi per aiutare a valutare quali applicazioni sono meno rischiose da migrare, ovvero tra le più interessanti da migrare nelle prime fasi di un progetto di migrazione cloud. Per esempio:. Qual è la criticità di questa applicazione per l’organizzazione? Qual è la sensibilità rispetto ai tempi di inattività? molto importante, 24x7 mission-critical? moderatamente importante? bassa importanza, ambiente dev / test? Guida: gli applicativi con minore criticità espongono ad un rischio minore. Un alto numero di dipendenti e/o cittadini dipendono da questa applicazione? Guida: un minor numero di utilizzatori rappresenta un rischio minore. Qual è il livello dell’ambiente di questa applicazione (produzione, staging, test, sviluppo)? Guida: gli ambienti non di produzione hanno un rischio minore. Quante dipendenze e/o integrazioni non interoperabili ha questa applicazione (ovvero che non utilizzano API)? Guida: dipendenze/integrazioni basate su API rappresentano un rischio minore. Qual è la conoscenza del team IT di questa applicazione? Guida: maggiore è la conoscenza, minore è il rischio. Il team IT ha una documentazione completa e aggiornata per questa applicazione e la sua architettura? Diagramma di sistema, diagramma di rete, diagramma del flusso di dati, documentazione sulla build/deploy, documentazione della manutenzione in corso, .. Guida: più completa ed aggiornata è la documentazione, minore è il rischio. Quali sono i requisiti di conformità normativa per questa applicazione? Guida: maggiori requisiti di conformità introducono più variabili da controllare, aumentando il rischio. Qual è la sensibilità ai tempi di fermo e / o di risposta per questa applicazione? Guida: garantire tempi di risposta molto ridotti in specifici contesti possono rappresentare un rischio maggiore. Impatto elevato in caso di tempi di fermo rappresenta un rischio maggiore. Ci sono responsabili d’area desiderosi e disposti a migrare i loro applicativi in anticipo?. Porsi delle domande come quelle in elenco aiuta a classificare le applicazioni dal rischio più basso al più alto. Le applicazioni a basso rischio dovrebbero essere migrate per prime e le applicazioni a rischio più elevato dovrebbero invece essere migrate più tardi. 3.1.3.3 Livello 3: facilità di migrazione al cloud pubblico. Il terzo livello in questo framework ruota attorno alla facilità con cui è possibile migrare potenzialmente un’applicazione al cloud. A differenza del rischio, che riguarda l’importanza relativa di tale applicazione, la facilità di migrazione riguarda il modo in cui il trasferimento dell’applicazione verso il cloud sarà privo di attriti. Alcune buone domande da porsi includono:. Come è stata sviluppata questa applicazione? Acquisto di terze parti da un produttore rilevante (ancora in attività?), acquisto di terze parti da un produttore minore (ancora in attività?), scritto in-house (autore ancora in organizzazione?), scritto da un partner (ancora attivo? Ancora un partner?). Quanto è nuova questa applicazione? È stata progettata per l’esecuzione on-premise o nel cloud? Adotta microservizi? È multi-tier?. È possibile migrare questa applicazione utilizzando approcci semplici come lift-and-shift (re-host)? Utilizza macchine virtuali o container?. Questa applicazione è strettamente dipendente da uno specifico sistema operativo o è flessibile rispetto a questo aspetto?. Questa applicazione (o i suoi dati) ha requisiti normativi, di conformità per l’esecuzione on-premise? Guida: la conformità può aumentare la complessità della migrazione. Quali sono le considerazioni sui dati per questa app? Sono aggiornati di frequente? Ci sono altri sistemi dipendenti da questo set di dati?. Quando si pianificano le applicazioni da migrare nel cloud, è possibile che a volte applicazioni di Livello 3 possano andare prima del Livello 2 (o anche Livello 1). Questo è assolutamente normale. Livello 2 e Livello 3 implicano molte variabili, quindi è comune avere un po” di scambi lungo il percorso di migrazione mantenendo comunque il senso logico della sequenza. 3.1.3.4 Livello 4: altro. Il quarto ed ultimo livello di questo framework raccoglie tutti quegli applicativi che non hanno un evidente beneficio dalla migrazione al cloud, rappresentano un rischio significativo nella migrazione per i servizi che supportano e hanno una complessità specifica nella migrazione. Questo tipo di applicativi sono tipicamente applicativi molto personalizzati o costituiti da soluzioni ad hoc per necessità particolari, per cui la loro migrazione pone sfide che altri applicativi di mercato non pongono e per i quali non ci si può affidare a conoscenza diffusa sul mercato. Questi applicativi possono essere lasciati in fondo al processo di migrazione perché la combinazione dei fattori li rende meno appetibili dal punto di vista del valore generato rispetto agli altri e la complessità della migrazione richiede un’esperienza consolidata che si può avere dopo aver completato con successo le migrazioni precedenti ...
-
italia
3.4 Migrazione delle licenze software in cloud
La gestione delle licenze in una prospettiva che privilegi la migrazione al cloud deve seguire questi approcci:. Le licenze in scadenza vanno considerate con priorità per la migrazione ad una soluzione cloud-based (applicativo “opportunità da cogliere”) e le licenze mantenute attive solo il tempo minimo necessario a completare la migrazione. Le licenze ad uso perpetuo vanno considerate per BYOL se possibile o per la dismissione ed il passaggio ad una soluzione cloud con la relativa licenza. In caso vi siano investimenti significativi in ammortamento è necessario definire un termine per la dismissione della licenza e pianificare la migrazione in modo che il sistema in cloud sia disponibile e pienamente operativo per quel termine. I software middleware on-premise sotto licenza come ad esempio gli application server o DBMS sono tipicamente sfruttati da più di un applicativo. Questi componenti non vengono migrati immediatamente in quanto sono necessari a tutti quegli applicativi ancora on-premise e in attesa di migrazione. Il risultato è una situazione ibrida in cui è necessario mantenere attivi sia i middleware on-premise che i middleware, o loro alternative, in cloud. Oltre che l’impatto sulla gestione, questa duplicazione di ambienti anche se temporanea comporta un costo relativo alle licenze per le quali è dunque importante considerare bene l’impatto sul costo della migrazione ed eventuali accordi possibili con i fornitori di servizi su tipologie di licenze ibride ...
-
italia
1.1 Cos’è il cloud
Questo modello consente di semplificare drasticamente la gestione dei sistemi informativi, sia eliminando la gestione relativa ad applicativi fruibili direttamente online, sia trasformando le infrastrutture fisiche in servizi virtuali fruibili in base al consumo di risorse. Rispetto alle tradizionali soluzioni hardware, il modello cloud consente di:. avere importanti vantaggi di costo nell’utilizzo del software, in quanto consente di pagare le risorse come servizi in base al consumo (“pay per use”), evitando investimenti iniziali nell’infrastruttura e costi legati alle licenze di utilizzo. ridurre i costi complessivi collegati alla location dei data center (affitti, consumi elettrici, personale non ICT). avere maggiore flessibilità nel provare nuovi servizi o apportare modifiche, con costi accessibili. effettuare in maniera continua gli aggiornamenti dell’infrastruttura e delle applicazioni. ridurre i rischi legati alla gestione della sicurezza (fisica e logica) delle infrastrutture IT. La maggior parte dei servizi di cloud computing rientra in tre ampie categorie:. Consulta il catalogo dei servizi SaaS qualificati da AgID. platform-as-a-service (PaaS), ovvero piattaforma distribuita come servizio: si tratta di servizi cloud che forniscono strumenti e ambienti per lo sviluppo, il test, la distribuzione e la gestione di applicazioni software, solitamente tramite strumenti specifici forniti dal provider stesso e pannelli di configurazione fruibili via browser web. Una soluzione PaaS è progettata per consentire agli sviluppatori di progettare e creare concentrandosi sulle funzionalità dell’applicativo, lasciando al fornitore del servizio aspetti come la configurazione, la gestione dell’ambiente di esecuzione dell’archiviazione o dei database. Consulta il catalogo dei servizi PaaS qualificati da AgID. infrastructure-as-a-service (IaaS), ovvero infrastruttura distribuita come servizio: si tratta di servizi cloud che permettono di allocare risorse infrastrutturali fisiche e virtuali (server, macchine virtuali, risorse di archiviazione e networking) su richiesta mediante interfacce grafiche o mediante API (Application Programming Interfaces) con pagamento in base al consumo. Consulta il catalogo dei servizi IaaS qualificati da AgID. Vi sono inoltre diversi modelli di dispiegamento dei servizi:. cloud privato: installato dall’utente nel suo data center per suo utilizzo esclusivo. I servizi vengono forniti da elaboratori che si trovano interamente nel dominio del cliente che detiene controllo e totale responsabilità della gestione delle macchine sulle quali vengono conservati i dati e vengono eseguiti i suoi processi, assieme ai complessi aspetti relativi alla sicurezza dei dati. Oltre allo scenario in cui si possiede interamente l’infrastruttura sui propri data center, un altro scenario possibile è invece quello in cui l’utente installa il proprio cloud privato nel data center di un terzo soggetto (tipicamente un fornitore di servizi cloud), in cui dispone di macchine dedicate. In questo caso, l’utente ha il controllo delle macchine anche se non risiedono nel suo dominio, e può configurarle secondo le proprie necessità. cloud ibrido: combinazione del modello pubblico e di quello privato, ovvero un modello in cui l’utente utilizza risorse sia del suo cloud privato che di un cloud pubblico. Ad esempio, un utente che dispone di un cloud privato, può utilizzare le risorse di un cloud pubblico per gestire improvvisi picchi di lavoro che non possono essere soddisfatti facendo ricorso unicamente alle risorse disponibili nel cloud privato. Tuttavia questo modello comporta comunque la proprietà e conseguente gestione della parte privata delle infrastrutture, risultando in maggiori costi e rischi. Ulteriori informazioni nella definizione di cloud ibrido. Le linee guida in questo documento saranno orientate al modello di cloud pubblico, in quanto più allineato agli obiettivi della strategia di cloud enablement, ovvero:. riduzione dell’onere di manutenzione ed ammodernamento continuo dell’infrastruttura e delle competenze necessarie per farlo. incremento della facilità di adozione delle soluzioni e dei servizi progressivamente disponibili grazie all’evoluzione di mercato. adozione di servizi ai più alti standard qualitativi di mercato, riflessi negli SLA garantiti. È possibile consultare le definizioni del modello cloud e le proprietà specifiche dei servizi facendo riferimento al documento del NIST. Non tutti i servizi e le infrastrutture di cloud computing sono uguali. In alcuni casi tali servizi possono anche non rispettare i principali standard di sicurezza, garanzie operative e affidabilità definiti a livello internazionale. Questa disomogeneità può rappresentare un rischio quando si affidano i propri dati a provider che non garantiscono dei livelli minimi di sicurezza e affidabilità. Il modello Cloud della PA consente di mitigare tale rischio, qualificando servizi e infrastrutture cloud secondo specifici parametri di sicurezza e affidabilità idonei per le esigenze della pubbliche amministrazioni. Il Cloud della PA si compone di infrastrutture e servizi, qualificati da AGID sulla base di un insieme minimo di requisiti, che possono essere confrontati e consultati sul Cloud Marketplace. Il sito cloud.italia.it contiene un approfondimento sulla qualificazione dei servizi cloud e sul catalogo dei servizi cloud qualificati ...
-
italia
1.2 Perché usare il cloud
Sfruttando le potenzialità del cloud, le pubbliche amministrazioni hanno l’opportunità di migliorare la qualità dei propri servizi, siano questi ad uso interno o ad uso del cittadino. Grazie al cloud, l’amministrazione può gestire i servizi in maniera più efficiente ed efficace, riuscendo a concentrarsi maggiormente sulle funzionalità da offrire ai propri utenti. Prima di tutto, il cloud garantisce un rapido accesso a tutte le informazioni indipendentemente dalla propria postazione fisica. I dati sono infatti accessibili ovunque, attraverso una molteplicità di device e secondo standard di sicurezza elevati, presentato precedentemente. Inoltre, l’adozione del cloud favorisce l’uso di architetture moderne, basate su principi tecnologici avanzati come ad esempio il basso accoppiamento dei componenti e il “design for failure” (per approfondimento si veda il capitolo 5.4.3), lontani dalla struttura monolitica degli applicativi legacy. Questo rende gli applicativi molto più adeguati alle necessità di interoperabilità e comunicazione tra diversi servizi (e tra le rispettive basi di dati). Le soluzioni SaaS dei cloud service provider (CSP) qualificati da AGID e consultabili sul Cloud Marketplace, ad esempio, offrono tutte uno strato di interoperabilità fruibile tramite API. Questo permette di avere maggiore flessibilità nel provare nuovi servizi o apportare modifiche. Nel caso un applicativo debba essere scomposto nelle sue parti prima di essere migrato al cloud (si veda il capitolo 4.1.6 per la strategia di migrazione Re-architect), l’amministrazione ha la possibilità di usare questo cambiamento come occasione per ridisegnare il servizio anche nel suo processo per renderlo più adatto alle esigenze degli utenti (e per questa finalità si consiglia di consultare le linee guida che si trovano sul sito di designers.italia.it). Infine, grazie alla scalabilità reale del cloud, si ha un miglioramento dell’accessibilità e della disponibilità dei servizi. Usando applicativi in cloud, l’amministrazione può assicurarsi che tali applicativi siano disponibili anche durante i picchi di accesso. Ad esempio, nel caso di un servizio con picchi di traffico solo in determinati periodi dell’anno (come il servizio di iscrizione alle scuole elementari dove i genitori accedono e iscrivono i propri figli solo ad inizio anno) si ha la sicurezza di non incorrere in downtime o momenti di disservizio durante i periodi di maggiore carico ...