IBM Cloud Private...For Dummies personalizzato per la propria organizzazione o azienda, contattare...

IBM Cloud Private

Edizione limitata

di Judith Hurwitz e Daniel Kirsch

HPE Synergy For Dummies, Edizione speciale HPE 46

Questi materiali sono di proprietà © 2018 John Wiley & Sons, Inc. Qualsiasi disseminazione, distribuzione o utilizzo non autorizzato èstrettamente proibito.

IBM Cloud Private For Dummies®, Edizione limitataPubblicato daJohn Wiley & Sons, Inc.111 River St.Hoboken, NJ 07030-5774www.wiley.com

Copyright © 2018 di John Wiley & Sons, Inc.

Al di fuori dei casi previsti dalle sezioni 107 o 108 del Copyright Act degli Stati Uniti del 1976 e senza la preventiva autorizzazione scritta dell’Editore, nessuna parte della presente pubblicazione può essere riprodotta, archiviata in un sistema o trasmessa in qualsiasi forma e tramite alcun mezzo, inclusi stru-menti elettronici o meccanici, fotocopiatrici, registratori o mezzi analoghi. Le richieste di pubblicazione all’Editore devono essere inviate a: Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, oppure all’indirizzo Internet http://www.wiley.com/go/permissions.

Marchi: Wiley, For Dummies, il logo Dummies Man, The Dummies Way, Dummies.com, Making Everything Easier, e i rispettivi aspetti grafici di vendita sono marchi o marchi registrati di titolarità di John Wiley & Sons, Inc. e/o dei suoi affiliati negli Stati Uniti e/o in altri Paesi e non possono essere utilizzati senza autorizzazione scritta. IBM e il logo IBM sono marchi registrati di International Business Machines Corporation. Tutti i marchi sono di proprietà dei rispettivi titolari. John Wiley & Sons, Inc., non è associato ad alcuno dei prodotti o dei fornitori menzionati in questo libro.

LIMITAZIONE DI RESPONSABILITÀ/ESCLUSIONE DI GARANZIA: L’AUTORE E L’EDITORE NON FORNISCONO ALCUNA DICHIARAZIONE O GARANZIA RELATIVAMENTE ALL’ACCURATEZZA O ALLA COMPLETEZZA DEI CONTENUTI DI QUEST’OPERA ED ESCLUDONO ESPRESSAMENTE OGNI TIPO DI GARANZIA, INCLUSE, A TITOLO DI ESEMPIO NON ESAUSTIVO, LE GARANZIE DI IDONETITÀ A UN FINE SPECIFICO. È VIETATO PRODURRE O ESTENDERE GARANZIE TRAMITE VENDITE O MATERIALE PUBBLICITARIO. LE STRATEGIE E I CONSIGLI CONTENUTI NELL’OPERA POTREBBERO NON ESSERE ADEGUATI A TUTTE LE SITUAZIONI. LA PRESENTE OPERA VIENE VENDUTA CON LA CONSAPEVOLEZZA CHE L’EDITORE NON FORNISCE STABILMENTE SERVIZI LEGALI, CONTABILI O ALTRI SERVIZI PROFESSIONALI. NEI CASI IN CUI SI RENDA NECESSARIA L’ASSISTENZA PROFESSIONALE, BISOGNERÀ RIVOLGERSI AD UN PROFESSIONISTA COMPETENTE. IN NESSUN CASO L’AUTORE O L’EDITORE POTRANNO ESSERE CONSIDERATI RESPONSABILI DI DANNI IN QUALSIASI MODO CONNESSI AI CONTENUTI DELL’OPERA. IL FATTO CHE UN’ORGANIZZAZIONE O UN SITO WEB VENGANO NOMINATI IN QUESTA OPERA COME POSSIBILE FONTE DI ULTERIORI INFORMAZIONI NON IMPLICA CHE L’AUTORE O L’EDITORE APPROVINO LE INFORMAZIONI O I CONSIGLI EVENTUALMENTE FORNITI DALL’ORGANIZZAZIONE O DAL SITO WEB. INOLTRE, I LETTORI DEVONO ESSERE CONSAPEVOLI CHE I SITI WEB ELENCATI IN QUEST’OPERA POTREBBERO ESSERE STATI SPOSTATI O DISATTIVATI NELL’INTERVALLO TEMPORALE COMPRESO TRA IL MOMENTO IN CUI L’OPERA È STATA SCRITTA E QUELLO IN CUI L’OPERA SARÀ LETTA.

Per informazioni di carattere generale su gli altri prodotti e servizi o su come creare un libro For Dummies personalizzato per la propria organizzazione o azienda, contattare il nostro Business Development Department negli USA al numero 877-409-4177 o all’indirizzo email [email protected]; in alternativa, visitare il sito web: www.wiley.com/go/custompub. Per informazioni sui diritti di licenza relativi al brand For Dummies di prodotti e servizi, scrivere all’indirizzo email: BrandedRights&[email protected].

ISBN: 978-1-119-52153-2 (pbk); ISBN: 978-1-119-52152-5 (ebk)

Prodotto negli Stati Uniti d’America

10 9 8 7 6 5 4 3 2 1

Ringraziamenti dell’EditoreDi seguito sono elencate alcune delle persone che hanno reso possibile la realizza-zione del presente libro:

Project Editor: Carrie A. Burchfield

Editorial Manager: Rev Mengle

Acquisitions Editor: Steve Hayes

Business Development Representative: Sue Blessing

IBM Contributor: Mohammed Abdula, Nancy Agosta, Roland Barcia, Andy Gower, Sanjay Joshi, David Lindquist, Eduardo Patrocinio, David Slovensky

Production Editor: Siddique Shaik



http://www.wiley.com

http://www.wiley.com/go/permissions

mailto:[email protected]

http://www.wiley.com/go/custompub

mailto:BrandedRights&[email protected]

Sommario iii

SommarioINTRODUZIONE .............................................................................................. 1

Informazioni su questo libro ............................................................... 1Ipotesi sul lettore .................................................................................. 2Icone utilizzate in questo libro ............................................................ 2

CAPITOLO 1 Spiegazionedelcloud privato ...................................... 3Definizione del contesto per il cloud privato .................................... 4La logica del cloud privato ................................................................... 5Requisiti del cloud privato ................................................................... 5

Provisioning dinamico .................................................................... 5Portabilità dei carichi di lavoro ...................................................... 6Gestione della sicurezza................................................................. 7Integrazione e connettività per accedere alle risorse ................ 7Gestione di un ambiente ibrido .................................................... 8

Definizione della strategia cloud di IBM ............................................ 8

CAPITOLO 2 Utilizzodelcloudprivatodapartedeiclienti .... 11

L’imprescindibile esigenza economica del cloud privato .............. 11Creazione di applicazioni cloud-native ............................................ 13Integrazione con dati e applicazioni ................................................ 14Trasferimento dei carichi di lavoro nel cloud ................................. 15Refactoring e modernizzazione ........................................................ 15

CAPITOLO 3 Uno sguardoallebasi tecnichediIBM Cloud Private ............................................................ 17Caratteristiche di IBM Cloud Private ................................................ 18Componenti essenziali di IBM Cloud Private .................................. 18

La scelta di un’infrastruttura flessibile ....................................... 19Piattaforma di contenitori Kubernetes ...................................... 19Servizi e software ottimizzati per il cloud .................................. 20Strumenti di gestione e DevOps integrati .................................. 21

CAPITOLO 4 DevOpsperilcloud privato ........................................ 23La natura mutevole di DevOps ......................................................... 23Integrazione continua (CI) ed erogazione continua (CD) ............... 25Il ruolo svolto da IBM UrbanCode nel CI/CD ................................... 27Un’esperienza utente migliore.......................................................... 27



iv IBMCloudPrivateForDummies,Edizionelimitata

CAPITOLO 5 Analisideidatinelcloud privato ............................. 29Il valore dell’analisi dei dati ............................................................... 29Il ruolo svolto dalla scienza dei dati nell’analisi dei dati ................ 30Comprendere il machine learning ................................................... 31

Il ruolo del cloud privato nell’analisi avanzata .......................... 32Gestione “ibrida” dei dati ............................................................. 32

Analisi avanzata a supporto del cloud ibrido .................................. 33Utilizzo delle fonti di dati locali.................................................... 33Analisi avanzata di tipo cloud-native .......................................... 34Supporto del cloud ibrido all’analisi avanzata ........................... 34

CAPITOLO 6 Gestionediunambientemulti-cloud .................... 35Preparare la strada verso la gestione dell’hybrid computing ....... 36Maggiore visibilità .............................................................................. 36Comprendere la logica relativa alla gestione multi-cloud ............. 37Requisiti della gestione di ambienti multi-cloud ............................ 37

Catalogo dei servizi ....................................................................... 37Gestione delle configurazioni ...................................................... 38Automazione e orchestrazione dei servizi ................................. 38

Creazione di una piattaforma bilanciata con la gestione delle API .................................................................... 39La gestione in un mondo di microservizi ........................................ 40IBM Cloud Automation Manager ...................................................... 41

Terraform ....................................................................................... 41Catalogo dei servizi interno a IBM CAM ..................................... 42Compositore di servizi .................................................................. 42

Controllo di un ambiente Multi-Cloud ............................................. 42Supporto per diversi strumenti di controllo ................................... 43Preparare la strada verso l’azione .................................................... 43



Introduzione 1

IntroduzioneIl cloud ibrido sta ridefinendo il modo in cui il software a supporto a supporto delle attività di dipendenti, clienti e partner viene creato ed eseguito all’interno delle organizzazioni. Questa industrializzazione del cloud computing ha implicazioni significative sulle imprese. I servizi cloud devono assicurare lo stesso livello di resilienza, sicu-rezza, scalabilità e prestazioni dei data center tradizionali. Le orga-nizzazioni devono sfruttare al meglio i servizi cloud sia pubblici che privati per poter supportare carichi di lavoro fra loro molto diversi, che vanno dai dati all’analytics, dai contenitori ai microservizi. Questo ambiente ibrido deve essere progettato in modo che l’infra-struttura di elaborazione sia ben gestita.

L’interesse delle aziende per il cloud è in continua crescita e così il cloud privato viene visto come un modo sicuro per ottimizzare l’ap-proccio operativo all’utilizzo dei servizi cloud. L’integrazione fra servizi di cloud pubblico e privato offre alle organizzazioni la possi-bilità di scegliere in base alle esigenze aziendali di sicurezza, confor-mità, flessibilità e prestazioni. Il ricorso a standard aperti quali Kubernetes, Cloud Foundry e Open Stack rende possibile incremen-tare i servizi applicativi e la portabilità dei dati.

Informazioni su questo libroLa diffusione del cloud ibrido a supporto delle aziende di livello enterprise rende sempre più essenziale garantire una base coerente e prevedibile per l’elaborazione di livello enterprise. È necessario supportare lo sviluppo, il deployment, la gestione e il controllo dell’intero ambiente. Sebbene siano molte le unità aziendali che hanno preferito approfittare della semplicità di accesso ai servizi del cloud pubblico, sono altrettanto numerose quelle che si stanno inte-ressando pragmaticamente al cloud privato, per supportare i carichi di lavoro di tipo mission critical che vogliono vedere protetti dietro il proprio firewall. Le aziende di livello enterprise necessitano di connettività, integrazione, sicurezza e portabilità dei carichi di lavoro oltre che della loro gestione complessiva.

E sono proprio questi i temi su cui questo libro potrà offrire un contributo. IBM Cloud Private For Dummies, in edizione limitata, contiene utili informazioni sulla funzione svolta dal cloud privato e sul modo in cui supporta le esigenze in continua evoluzione nel mondo dell’elaborazione. L’opera si concentra sull’offerta di cloud



2 IBM Cloud Private For Dummies, Edizione limitata

privato di IBM – IBM Cloud Private – coordinata con i servizi cloud pubblici di IBM.

Ipotesi sul lettoreLe informazioni contenute in questo libro si rivelano utili per molte persone, ma abbiamo fatto alcune supposizioni circa il lettore tipo, che immaginiamo essere:

» Informato sul cloud computing e desideroso di conoscere il ruolo svolto dal cloud privato nonchè dal modo in cui questo interagisce con il data center privato e il cloud pubblico;

» Interessato alla pianificazione di una strategia cloud di lungo periodo e desideroso di comprendere il valore del cloud privato e del modo in cui può essere utilizzato per sostenere gli obiettivi aziendali;

» Interessato a conoscere l’offerta di cloud privato IBM e dei modi in cui può sostenere gli obiettivi aziendali; Interessato a conoscere l’interazione con il cloud pubblico di IBM e con gli altri servizi di cloud pubblico;

» Interessato a sapere come possono combinarsi fra loro tutti gli elementi del cloud computing al fine di supportare la gestione dei carichi di lavoro oltre che la conformità, la sicurezza, il deployment e lo sviluppo del software.

Icone utilizzate in questo libroAll’interno del libro vengono usate le seguenti icone per evidenziare alcune informazioni importanti.

Questa icona evidenzia informazioni che sarebbe meglio tenere a mente.

Questa icona identifica informazioni che possono risultare utili in diversi modi, dal momento che consentono di risparmiare tempo, denaro o problemi di varia natura

Questa icona evidenzia informazioni a cui è opportuno prestare attenzione per evitare problemi.

RICORDA

SUGGERIMENTO

AVVISO



CAPITOLO 1 Spiegazione del cloud privato 3

Capitolo 1

IN QUESTO CAPITOLO

» Il contesto del cloud privato

» La logica del cloud privato

» I requisiti del cloud privato

» Introduzione alla strategia cloud IBM

Spiegazione del cloud privato

Il cloud privato si sta affermando sempre più come un imperativo per le imprese di livello enterprise. Le aziende desiderano la fles-sibilità e l’elasticità del cloud pubblico senza voler rinunciare alla

gestione, alla struttura, all’architettura e alla sicurezza che hanno già nei loro data center privati.

L’ambito del cloud computing sta cambiando grazie a un gruppo di strumenti e di approcci che consentono di gestire i carichi di lavoro in modo prevedibile. Per riuscire a rispondere al cambiamento delle loro stesse esigenze, che variano a seconda dei carichi di lavoro e delle circostanze, le aziende stanno puntando a un set di servizi ibridi e multi-cloud. È in atto una transizione di notevoli proporzioni nel cloud computing, che va di pari passo con la sua crescita: Non possiamo più semplicemente limitarci a pensare in termini di singolo servizio: al contrario, dobbiamo pensare al ciclo di vita complessivo dell’attività di computing nel cloud.

In questo capitolo ci soffermeremo sull’evoluzione del cloud privato dal punto di vista del ciclo di vita e sulle modalità con cui i servizi cloud pubblici e privati sostengano le nuove esigenze dei carichi di lavoro. Questo esame viene svolto all’interno della strategia cloud di IBM. Presenteremo inoltre IBM Cloud Private.




Definizione del contesto per il cloud privato

Solo pochi anni fa, le aziende hanno scoperto quanto potevano essere utili i servizi cloud nel fornire una soluzione essenziale per l’approv-vigionamento di servizi di elaborazione e storage. I vantaggi finan-ziari risultavano immediati e del tutto evidenti. Molti dirigenti d’azienda hanno optato per il cloud pubblico per la semplicità di accesso ai servizi. Altre organizzazioni, preoccupate per aspetti quali sicurezza, conformità e livelli di servizio garantiti, hanno preferito continuare a sfruttare servizi di infrastrutture private per il provisio-ning automatizzato all’interno del firewall del proprio data center.

Nell’arco degli ultimi cinque anni il mercato dei servizi cloud è lette-ralmente esploso, dal momento che è cresciuto il numero delle aziende che hanno cominciato a capire le potenzialità legate all’uti-lizzo dei servizi cloud quando vengono posti alla base delle proprie esigenze di computing.

Il passare dal semplice utilizzo di alcuni servizi di storage ed elabora-zione a un’infrastruttura full stack per il cloud computing rappre-senta una necessità. È divenuto possibile avere un’unica soluzione a supporto di tutti i carichi di lavoro. Inoltre, all’interno di un ambiente multi-computing diviene imperativo applicare gli stessi standard di gestione a tutti i carichi di lavoro.

Sebbene ci siano stati dibattiti sul valore del cloud privato rispetto a quello pubblico, questi due modelli di deployment si stanno evol-vendo nella direzione di una piena integrazione collaborativa. Si può pensare al cloud pubblico come al servizio standardizzato basato su Internet e disponibile su richiesta con pagamento a consumo. Al contrario, il cloud privato può essere visto come un set di servizi basati su software che condividono le stesse API (Application Programming Interface) comuni fornite dal cloud pubblico. Il cloud privato che sta emergendo offre un insieme di servizi modulari per il ciclo di vita.

I servizi del cloud privato risiedono nel data center della società e sfruttano le API per consentire di utilizzare le capacità esistenti, incluse le virtual machine, i container o le applicazioni complete.

Sempre più spesso, i fornitori di cloud pubblico stanno aggiungendo servizi di livello enterprise per poter collegare le risorse del cloud pubblico alla linea delle applicazioni aziendali presenti nel data center. Analogamente, i servizi di cloud privato sfruttano sempre più

SUGGERIMENTO

RICORDA




spesso una varietà di servizi pubblici o in hosting. Dov’è la diffe-renza? In genere, i servizi di cloud pubblico offrono la possibilità di riunire una serie di servizi che rispondono a una data esigenza. Al contrario, un ambiente di cloud privato rappresenta un ecosistema di servizi maggiormente integrato. Molte organizzazioni hanno scoperto che entrambi i modelli possono risultare efficaci, a seconda della natura dei carichi di lavoro.

La logica del cloud privatoLa conoscenza dell’architettura e le abilità di programmazione richieste da un ambiente cloud pubblico sono spesso elevate. Nel corso del tempo, ci aspettiamo che il cloud pubblico cercherà di permettere ai servizi pubblici di agire come fossero un data center.

Per riuscirci, le organizzazioni si stanno rendendo conto di aver biso-gno di un mix di servizi cloud, pubblici e privati, così da riuscire a soddisfare le esigenze dei loro clienti. Ad esempio, un’applicazione concepita per il cloud senza dipendenze da servizi complessi o SLA (Service Level Agreement) può essere sviluppata nel cloud pubblico. In scenari diversi, un’organizzazione potrebbe voler sfruttare appli-cazioni core esistenti che si rivelerebbero difficili da riprogettare. Allo stesso tempo, le organizzazioni spesso necessitano delle presta-zioni derivanti dall’integrazione di questi servizi e di un controllo granulare per l’audit, le prestazioni e i risarcimenti. In genere queste esigenze si presentano contemporaneamente per le organizzazioni, portando alla necessità di integrare i servizi del cloud pubblico con quelli del cloud privato. Ad esempio, si potrebbe eseguire un’appli-cazione nel cloud privato, ma usare dataset pubblici o servizi video residenti nel cloud pubblico.

Requisiti del cloud privatoPer creare e gestire efficacemente un ambiente cloud privato è necessario rispondere a una serie di requisiti, che procederemo a esaminare qui di seguito.

Provisioning dinamicoUno dei vantaggi preferiti dagli sviluppatori riguardante il cloud pubblico consiste nella possibilità di approvvigionarsi di capacità di elaborazione e storage on demand. IBM Cloud Private, su cui ci soffermeremo poco più avanti in questo capitolo, nella sezione “Definizione della strategia cloud di IBM”, offre approvvigiona-




mento di tipo self-service. Tuttavia, una differenza c’è. Il cloud privato offre un approvvigionamento di tipo dinamico, eseguito sulla base delle regole che gestiscono l’aggiunta di ulteriore capacità di elaborazione o storage. Regole che possono anche prevedere dove debbano essere aggiunte tali risorse. È il caso, ad esempio, di un’ap-plicazione che necessita di ulteriore spazio di storage.

La regola nel cloud privato potrebbe prevedere la scelta del tipo di storage più appropriato nella posizione che meglio risponde ai requi-siti di conformità dell’azienda. Inoltre, le regole possono indicare quanto denaro è possibile spendere per quello storage. Ad esempio, un progetto pilota nato nel cloud potrebbe non aver bisogno della stessa velocità di storage che richiederà quella stessa applicazione una volta posta in produzione. Quando si aggiungono algoritmi di apprendimento al provisioning dinamico, diventa possibile tracciare il modo in cui vengono gestiti i carichi di lavoro. Inoltre, diventa possibile anche l’auto riparazione dei carichi di lavoro che non risul-tano in esecuzione così come previsto dai requisiti.

Portabilità dei carichi di lavoroUno degli obblighi più importanti per le organizzazioni consiste nella capacità di spostare i carichi di lavoro da un ambiente all’altro, qualora i requisiti dovessero cambiare. Ad esempio, un carico di lavoro potrebbe inizialmente risiedere nel data center. Tuttavia, se l’applicazione dovesse iniziare a richiedere maggiori risorse di elabo-razione o di storage, l’organizzazione potrebbe decidere di spostarla in un cloud pubblico piuttosto che acquistare ulteriori risorse locali. Le applicazioni devono tuttavia essere state progettate per consen-tire questa flessibilità e adattarsi ai cambiamenti.

Il vantaggio offerto da un ambiente di elaborazione ibrido consiste proprio nel fatto che fornisce il giusto mix di prestazioni richieste dal caso specifico. Carichi di lavoro complessi potrebbero sfruttare contenuti API locali, che richiedono bassa latenza e accesso rapido alle risorse. Potrebbe divenire necessario usare una struttura di cloud privato e accesso di rete a un set di risorse locali. La portabilità dei carichi di lavoro sfrutta inoltre la modularità della cosiddetta “containerisation” che supporta lo sviluppo in diversi linguaggi, visto che gli sviluppatori usano il linguaggio più appropriato per supportare lo specifico carico di lavoro (le questioni connesse ai DevOps saranno esaminate in maggior dettaglio nel capitolo 4). Uno dei principali vantaggi di questo aspetto consiste nel fatto che consente agli sviluppatori di estrarre i carichi di lavoro all’interno di container dotati di diverse caratteristiche strutturali e prestazionali

RICORDA

SUGGERIMENTO




di base. Questo approccio dimostra che le differenze tra i linguaggi e tra le risorse non influenzano le prestazioni e mitigano i conflitti tecnici.

Per rendere portatili le applicazioni o i servizi applicativi è necessario che il codice venga modificato in modo da consentire a svariati servizi di essere collegati insieme durante il runtime. Questo livello di modi-fica è funzionale alla soddisfazione dei clienti, che si aspettano una modifica dei servizi non appena emergono nuovi modi di gestione del business. Dopo aver “modularizzato” i servizi applicativi in modo che possano essere collegati insieme, è necessario poter gestire quei carichi di lavoro per poterli eseguire come previsto, senza latenze. I carichi di lavoro vanno bilanciati. Al variare dell’utilizzo dei carichi di lavoro, deve conseguentemente corrispondere un’adeguata varia-zione dei livelli di sicurezza e conformità. Questi requisiti - come la sicurezza, la gestione e il bilanciamento dei carichi - costituiscono le fondamenta del moderno cloud privato. Se ben eseguito, il cloud privato dispone della prevedibilità tipica del data center unita all’a-gilità tipica del cloud pubblico.

Gestione della sicurezzaLa sicurezza rappresenta una delle principali preoccupazioni per la maggior parte delle aziende. In molte situazioni, le prescrizioni di sicurezza e conformità hanno il compito di proteggere i dati sensibili dei clienti. Altro aspetto cruciale è quello della protezione della proprietà intellettuale dell’organizzazione. In un ambiente a elevata distribuzione come il cloud, la sicurezza deve essere implementata in modo tale da poter cambiare ed evolversi sulla base dell’uso e dell’e-sigenza dei carichi di lavoro. Questi carichi di lavoro potrebbero toccare tante reti diverse. In altri casi, potrebbero integrarsi con i dati che vengono distribuiti all’interno di un ambiente multi-cloud.

Integrazione e connettività per accedere alle risorseUn ambiente cloud privato deve essere in grado di connettersi ai dati e ai servizi applicativi necessari, accedendo sia al data center che al cloud pubblico. Potrebbe essere necessario spostare i servizi e i dati tra le reti, oppure potrebbe essere necessario eseguire un algoritmo all’origine dei dati. Sebbene molti strumenti siano in grado di fornire connessioni tra servizi, il cloud privato in genere richiede la capacità di gestire latenza, regole, accessi e autorizzazione, prevedibilità, dipendenze e gestione dei servizi connessi.




Gestione di un ambiente ibridoIl cloud privato non è un ambiente unificato tipico del data center. Il cloud privato necessita di un livello di tipo software che rimuove le dipendenze connesse con un singolo hardware o un’infrastruttura virtualizzata. I responsabili dell’IT e delle unità aziendali devono poter contare su una soluzione coerente e prevedibile che permetta di gestire tutti i diversi servizi come se facessero parte di un unico sistema integrato. Un cloud privato ben progettato prevede un metodo intuitivo per verificare il funzionamento corrente dei servizi e per individuare la posizione di eventuali colli di bottiglia all’interno dell’ambiente distribuito.

Definizione della strategia cloud di IBMLa strategia cloud IBM punta a realizzare un modello ibrido. IBM offre due importanti implementazioni di cloud: IBM Cloud - offerta di cloud pubblico - e IBM Cloud Private.

IBM Cloud Private è una piattaforma applicativa per lo sviluppo e la gestione di applicazioni residenti all’interno di container locali. Questo ambiente integrato è composto da diversi componenti, quali l’orchestratore di container Kubernetes, un ambiente Cloud Foun-dry, un repository di immagini privato, una console di gestione e i framework di controllo.

Il design di IBM Cloud Private svolge quattro funzioni:

» Il cliente ha la possibilità di lasciare il proprio data center applicativo invariato e implementare un set di API che offrono la flessibilità di gestire e controllare i carichi di lavoro facendoli interagire con quelle applicazioni esistenti in modo più versatile e scalabile.

» I servizi definiti su base software consentono ai carichi di lavoro di essere scomposti in modo da poter essere “contai-nerizzati” senza dipendenze. I servizi così basati su container vengono poi collegati insieme da un set di API coerenti. Si tratta delle API che IBM ha implementato nel cloud pubblico.

» Questi stessi servizi basati su container vengono poi utilizzati per creare applicazioni native nel cloud, che sfruttano API comuni e che possono facilmente connettersi con dati e servizi ad elevata distribuzione. Per approfondire ulterior-mente l’architettura del Cloud privato IBM, fare riferimento al capitolo 3

RICORDA

RICORDA




» L’ambiente offre la possibilità di applicare soluzioni di analisi avanzata nel cloud, tra cui machine learning, intelligenza artificiale e analisi cognitiva. Tutto ciò aumenta la manegge-volezza e il ricorso all’analisi per la soluzione dei problemi aziendali.

Un punto essenziale nel design della strategia cloud di IBM consiste nel creare un gruppo di servizi progettati per essere connessi e gestiti insieme attraverso API ben definite e coerenti.

IBM ha predisposto un set coerente di API all’interno delle offerte cloud, sia pubblico che privato. La strategia cloud IBM è dunque basata su un’infrastruttura di tipo software-defined. Ciò significa che il cloud può supportare qualsiasi ambiente già esistente, inclusi virtualizzazioni, bare metal, container e automazioni.

Dal punto di vista logico, IBM Cloud Private svolge un controllo sul data center esistente dotato di connessione a servizi cloud di tipo hosted o pubblico. Per questo motivo, IBM ha progettato un insieme di servizi stratificati sopra i servizi infrastrutturali. Un approccio, questo, che risponde a numerose esigenze dei clienti, ognuna con una propria tipologia di carichi di lavoro diversa da supportare.

RICORDA

APERTURA ALL’OPEN SOURCE

L’open source pervade l’architettura di IBM Cloud Private. Si tratta di una mossa pragmatica dal momento che i clienti hanno la necessità che l’ar-chitettura supporti architetture cloud fra loro diverse e vogliono che siano garantite portabilità e modularità. I concetti fondamentali dell’open- source stanno alla base sia di IBM Cloud sia di IBM Cloud Private. Ad esempio, IBM supporta una strategia di tipo “open container”. Ciò signi-fica che IBM supporta Kubernetes, Docker e Cloud Foundry, oltre a lin-guaggi di programmazione diffusi come Java, Python, R, Node.js, implementazioni di database quali mongoDB e Postgres.

Il vantaggio di poter sfruttare l’open source è chiaro: consentire a IBM di fornire agli sviluppatori un insieme di strumenti ben noto e portabile. In più, vista l’ampiezza e la varietà della sua offerta di servizi, IBM può garan-tire tutto il supporto necessario all’uso di queste offerte open-source






CAPITOLO 2 Utilizzo del cloud privato da parte dei clienti 11

Capitolo 2

IN QUESTO CAPITOLO

» La scoperta dell’esigenza economica dei cloud privati

» Creazione di applicazioni cloud-native

» Rendere sicuri e integrati servizi applicativi e dati

» Prolungare la vita delle applicazioni importanti in uso

» Refactoring e modernizzazione per guadagnare agilità

Utilizzo del cloud privato da parte dei clienti

Sebbene i vantaggi del cloud computing siano evidenti, le aziende stanno sempre più spesso sperimentando l’esigenza di trovare un proprio approccio al cloud, che varia in funzione della natura dei

loro carichi di lavoro. Ad esempio, i responsabili aziendali potrebbero volere che i propri carichi di lavoro restassero protetti dietro il firewall aziendale per ragioni di sicurezza o di conformità. Inoltre, le aziende desiderano poter sfruttare gli investimenti fatti nei propri data center in relazione alle loro applicazioni LoB (Line of Business). In questo capitolo, vengono presentati i casi d’uso più significativi insieme ai modi in cui le imprese usano il cloud privato per rispondere alla continua evoluzione delle proprie esigenze operative.

L’imprescindibile esigenza economica del cloud privato

Dal momento che le aziende hanno iniziato a mettere il cloud al centro delle proprie strategie e pianificazioni nel settore computing, il cloud privato sta sempre più assumendo un ruolo centrale. Il punto è che i carichi di lavoro non sono tutti uguali. Sono numerose le ragioni e le situazioni che fanno la differenza quando si tratta di scegliere la piatta-forma più adeguata. Gli aspetti più evidenti per molte aziende sono




sicurezza e conformità. Molte società vogliono essere certe di poter avere un controllo totale sulla sicurezza dei propri data center. Benché un cloud pubblico possa essere considerato sicuro al pari di un data center, i responsabili IT vogliono poter avere il controllo diretto. Inoltre, sebbene siano molti i cloud pubblici che consentono di ospitare carichi di lavoro basati su specifici requisiti di conformità, alcune organizzazioni necessi-tano di uno SLA (Service Level Agreement) che garantisca il rispetto dei regolamenti.

Infatti, molti carichi di lavoro esistenti tendono a sfruttare una gran varietà di servizi, alcuni dei quali sono strettamente legati all’ambiente del data center. Altri servizi prevedono dipendenze dal sistema opera-tivo e da consistenti blocchi di codice, che non sarebbe facile trasformare nel breve periodo. È il caso ad esempio di uno scheduler che stabilisce quando vadano emesse le fatture ai clienti in base ai prodotti e ai servizi acquisiti. E questi blocchi di codice pre-esistente potrebbero contenere anche regole di autorizzazione complesse.

Nonostante la volontà sia quella di superare questi servizi monolitici, va anche detto che una transizione in blocco non sarebbe economicamente sostenibile. Le organizzazioni devono poter scadenzare la transizione, preservando la propria capacità di soddisfare le richieste dei clienti. Un’organizzazione IT potrebbe iniziare con la “containerizzazione” delle applicazioni o di estesi componenti di un carico di lavoro. Ciò assi-curerebbe, nel frattempo, una migliore agilità. Il passo successivo potrebbe essere quello di un esame volto a stabilire i costi e le necessità del nuovo piano di sviluppo. Per approfondimenti sui container, fare riferimento al capitolo 3.

Un altro aspetto egualmente rilevante è quello dei requisiti di latenza. Molte applicazioni hanno dipendenze verso fonti di dati e applicazioni che si trovano in azienda. Un eventuale spostamento di questi ambienti complessi nel cloud pubblico potrebbe avere un impatto negativo sulla velocità di esecuzione di un processo o di una query. Allo stesso tempo, tuttavia, è importante essere in grado di trasformare i data center in modelli di elaborazione più agili, trasformandone i servizi di computing. Questa trasformazione implica la necessità di ridisegnare middleware, servizi di networking, servizi catalog e motori di regole. Una volta trasformate queste funzioni in servizi modulari, è possibile ridefinire la funzione di computing nel suo insieme come gruppo di moduli collega-bili, capaci di interagire ogni volta che occorre. Ed è proprio grazie alla ridefinizione di questi servizi che a quel punto è possibile sfruttare servizi infrastrutturali e piattaforme in modi più flessibili e parametrati alle esigenze. Se sorge l’esigenza di un aumento di computing o di storage, non sarà più necessario trasformare il data center. Al contrario, per rispondere a un aumento di domanda, l’infrastruttura IT potrà essere

AVVISO




ridisegnata in modo da richiedere on-demand a un cloud pubblico ulte-riori risorse computazionali o di storage.

Conbinando servizi on-premise e di cloud privato con servizi di cloud pubblico, si favorisce un nuovo livello di pragmatismo capace di creare valore per i clienti dell’azienda. Molte organizzazioni sono giunte alla conclusione che il modello di data center tradizionale si è rivelato troppo rigido per rispondere all’evoluzione delle esigenze aziendali. Il cloud privato, coordinato con i servizi del cloud pubblico, è invece in grado di risolvere molte delle esigenze inderogabili di questa nuova era di trasfor-mazione digitale.

Creazione di applicazioni cloud-nativeMolte organizzazioni vorrebbero raggiungere l’agilità tipica delle appli-cazioni cloud-native, ma desiderano al contempo controllare come distribuire le applicazioni all’interno del proprio firewall. Queste orga-nizzazioni spesso hanno esigenze di sicurezza e conformità che le spin-gono verso il cloud privato. Inoltre, molte organizzazioni desiderano mantenere il controllo totale sulla propria infrastruttura e non inten-dono affidare i loro dati a un ambiente multitenant. Va detto però che, per restare competitive, queste aziende hanno la necessità di creare una nuova generazione di applicazioni.

Le applicazioni cloud-native si stanno sempre più affermando come la soluzione più efficiente per ottenere applicazioni modulari e scalabili. Le caratteristiche distintive di questo tipo di applicazioni sono elencate di seguito:

» Le applicazioni sono composte da diversi servizi. Queste applicazioni sono in genere basate su un’architettura di microser-vizi e gestite all’interno di un framework che le contiene.

» Le applicazioni cloud-native hanno il vantaggio di consentire alle imprese di integrare servizi e dati di terze parti. Le appli-cazioni cloud-native dispongono di API che permettono agli sviluppatori di accedere facilmente ad altre risorse, creando così nuove capacità con maggiore rapidità.

» Ogni singola parte di un’applicazione cloud-native è elastica. Se alcuni servizi necessitano di maggiori risorse, l’applicazione cloud-native è in grado di procurarsele senza che si verifichi alcun malfunzionamento o rallentamento dell’applicazione nel suo complesso.

» Le applicazioni cloud-native possono essere composte da una varietà di microservizi basati su API. Questa caratteristica

SUGGERIMENTO

RICORDA




permette di supportate un modello di fornitura continua, che prevede aggiornamenti frequenti del software.

Integrazione con dati e applicazioniUno dei vantaggi di un ambiente cloud ibrido consiste nella capacità di collegarsi a dati e applicazioni residenti in sistemi interni ed esterni. Anche quando le società decidono di sviluppare e distribuire applicazioni cloud-native, si troveranno ad aver spesso bisogno di raggiungere e poter sfruttare in modo efficiente i servizi dati di terze parti, come nel caso dei dati demografici e meteorologici. Allo stesso tempo, resta la necessità di realizzare un’integrazione con le fonti di dati interne, come i dati transazionali dei clienti e i sistemi di inventario dei prodotti. Le organizzazioni possono sfruttare i servizi essenziali del cloud basati sulle API Watson.

L’analisi dei dati è un’esigenza primaria per le organizzazioni che passano al cloud ibrido. In molti casi, l’analisi rappresenta una precon-dizione della capacità di fornire analisi predittive in un’applicazione aziendale. Inoltre, gli scienziati dei dati hanno stabilito che il cloud privato rappresenta la piattaforma ideale per creare e gestire modelli di machine learning. Spesso si tratta di dati così sensibili che le organizza-zioni sono obbligate a mantenerli all’interno del proprio firewall. Per ulteriori dettagli su scienza dei dati e machine learning nel cloud privato, fare riferimento al capitolo 5.

RISPOSTA A NUOVI TIPI DI COMPETIZIONE

L’attività di una società di gestione finanziaria era stata messa alla prova dalle emergenti società di tecnofinanza nate nel cloud. Di fatto, i clienti di questa società desideravano le stesse applicazioni intuitive e facili da uti-lizzare che erano state create dai concorrenti. La società ha deciso di creare applicazioni cloud-native in un cloud privato per connettere appli-cazioni locali e servizi di terze parti. L’obiettivo è stato quello di ottenere l’aggiornamento continuo dell’applicazione, di pari passo alla crescita delle aspettative dei clienti. La società voleva riuscire a creare un approc-cio software modulare, che avrebbe aiutato gli sviluppatori a creare ser-vizi software basati su API standard. La società ha utilizzato i container e un approccio DevOps a integrazione continua per scrivere nuovo codice. Le applicazioni così generate hanno potuto sfruttare una nuova genera-zione di middleware modulare, che consentisse di connettersi facilmente ai servizi residenti localmente e nel cloud pubblico.




Trasferimento dei carichi di lavoro nel cloud

Cosa significa trasferire un’applicazione esistente nel cloud? In un mondo perfetto, sarebbe preferibile trasformare le applicazioni esistenti in base a una architettura moderna. Tuttavia, in alcune situazioni, semplicemente non si dispone del tempo necessario per riprogettare applicazioni esistenti. Trasferendole nel cloud, si consente a queste applicazioni di accedere alle API e connettersi così a una varietà di servizi cloud, oltre che sfruttare la scalabilità e la modularità tipica dell’infra-struttura cloud. Alcune applicazioni sono tuttavia troppo frammentate o sono applicazioni pre-assemblate che non è possibile modificare con facilità. In questi casi, è consigliabile spostarle nel cloud così come sono. Altri software quali i servizi middleware possono essere spostati nel cloud dal momento che le licenze (come WebSphere) possono essere spostate nel cloud senza alcun costo aggiuntivo. Per alcune aziende, la migrazione nel cloud delle applicazioni esistenti potrebbe essere il primo passo verso un approccio più flessibile al computing.

Refactoring e modernizzazioneIn teoria, le organizzazioni potrebbero ricreare daccapo le proprie appli-cazioni, partendo da una progettazione essenziale e moderna. Nella pratica, le organizzazioni mantengono da decenni enormi quantità di proprietà intellettuale all’interno delle applicazioni. Molto spesso, queste applicazioni sono sistemi di record che rappresentano il motore

GESTIONE DEI PREZZI

Un’azienda del settore alberghiero ha intenzione di introdurre un modello di prezzi più flessibile, basato su diversi fattori, tra cui le condi-zioni meteorologiche e le informazioni dei social media sui prossimi eventi nella zona. La nuova applicazione per il cloud privato potrebbe sfruttare le tecniche emergenti di machine learning insieme all’analisi dei dati non strutturati. Potrebbe inoltre integrare i servizi di analisi basati su cloud con le fonti di dati sempre provenienti dal cloud. Il cloud privato consente all’azienda di mantenere i suoi dati esclusivi dietro il firewall. Allo stesso tempo, gli sviluppatori possono creare nuovi servizi innovativi da integrare nella piattaforma tramite le API. L’ambiente cloud garantisce un vantaggio in termini di prestazioni, scalabilità e modularità, indispen-sabile per restare competitivi e seguire l’evoluzione dei bisogni dei clienti.




della business continuity. All’interno di queste applicazioni vi sono servizi “core” come la fatturazione, la gestione delle transazioni, la gestione dei clienti e così via. Per le aziende con migliaia di clienti, non è sostenibile l’idea di ricominciare da zero. Le regole aziendali e le best practice rimangono all’interno di queste applicazioni. I processi codifi-cati sono basati sulle regole di conformità e di governance.

Tuttavia, molte di queste applicazioni tradizionali sono spesso fonte di problemi. Molte sono scritte in forma di codice integrato, dove dati, regole e processi sono strettamente interconnessi. In genere, è difficile aggiornare il software quando l’azienda adotta nuovi metodi di business. Alcune organizzazioni, che non dispongono del tempo o delle risorse necessarie, potrebbero decidere di spostare le applicazioni esistenti nel cloud senza modificarle. È possibile spostare le licenze middleware, come WebSphere, dalla posizione locale al cloud privato in modo che supporti le applicazioni. In genere a questa procedura si dà il nome di lift and shift. Sebbene si tratti di una procedura pragmatica, in realtà non si fa altro che rinviare la soluzione dei problemi riguardanti l’inflessibilità del codice.

L’infrastruttura del cloud privato può sfruttare i microservizi e la tecno-logia dei container per avviare il processo di trasformazione e moderniz-zazione delle applicazioni esistenti.

RIDUZIONE DELLE SPESE IN CONTO CAPITALE

Un’azienda manifatturiera stava affrontando la sfida lanciata da competi-tor emergenti in grado di personalizzare i prodotti tramite l’uso di un nuovo gruppo di applicazioni. Questi concorrenti erano in grado di pre-vedere le preferenze dei clienti e ottimizzare la personalizzazione dei prodotti. L’azienda manifatturiera comprese che il passaggio a un ambiente di servizi più flessibile avrebbe potuto aiutarla a restare com-petitiva. Gli sviluppatori investirono del tempo per selezionare i servizi “core” presenti nelle applicazioni esistenti e trasformarli in nuovi micro-servizi. Questi nuovi servizi furono inseriti all’interno di contenitori con API ben definite. Nel frattempo, altri sviluppatori crearono nuovi servizi in grado di aggiornare le capacità dell’azienda, rendendola così in grado di offrire prodotti maggiormente personalizzati ai propri clienti



CAPITOLO 3 Uno sguardo alle basi tecniche di IBM Cloud Private 17

Capitolo 3

IN QUESTO CAPITOLO

» Uno sguardo alle caratteristiche di IBM Cloud Private

» Esame dei componenti essenziali di IBM Cloud Private

Uno sguardo alle basi tecniche di IBM Cloud Private

IBM Cloud Private è una soluzione di livello enterprise pre-assem-blata che mette a disposizione una piattaforma singola posizio-nata dietro al firewall. L’azienda può scegliere se sfruttare il

proprio portfolio di software in locale o integrare con semplicità software e dati di nuova generazione ottimizzati per il cloud. IBM Cloud Private è stata creata su framework open-source, quali Kubernetes e Cloud Foundry, e assicura flessibilità, controllo, sicu-rezza e facilità di integrazione con i cloud pubblici. Inoltre, gli stru-menti di gestione del cloud sono inclusi all’interno della soluzione, così da consentire la gestione e l’ottenimento di insight all’interno di applicazioni e infrastrutture multi-cloud.

IBM Cloud Private è stato sviluppato sulla base dell’enorme espe-rienza di IBM nell’aiutare gli sviluppatori a creare applicazioni cloud-native e modificare applicazioni monolitiche dando loro una struttura più flessibile all’interno di applicazioni basate su microservizi.

In questo capitolo vengono fornite informazioni utili a comprendere le caratteristiche essenziali di IBM Cloud Private e i vantaggi a cui le




aziende di livello enterprise possono accedere grazie a questa soluzione.

Caratteristiche di IBM Cloud PrivateLe organizzazioni che adottano la piattaforma IBM Cloud Private possono disporre di:

» Un installatore unico che configura rapidamente un cluster Kubernetes-based dotato di nodi master, worker e proxy;

» La console di gestione del cluster di IBM Cloud Private per gestire, controllare e risolvere i problemi di applicazioni e cluster da un’unica console centralizzata e sicura;

» Un registro di immagini Docker privato per avere un servizio di registro locale che funziona nello stesso modo di un servizio di registro basato su cloud nel Hub Docker;

» Reti tenant isolate con Calico che assicura prestazioni elevate e isolamento di rete all’interno dei cluster;

» Funzioni di monitoraggio e logging efficienti con stack ELK per raccogliere, archiviare ed eseguire query di log e metriche;

» L’app centre, una posizione centralizzata da cui è possibile cercare e installare pacchetti all’interno dei cluster;

» Funzionalità di gestione della sicurezza per un’ampia gamma di strumenti e servizi.

Per ulteriori informazioni, visitate il sito web www.ibm.com/ cloud-computing/products/ibm-cloud-private.

Componenti essenziali di IBM Cloud Private

IBM Cloud Private non è una piattaforma monolitica; al contrario, è composta da un gruppo di servizi di componenti e infrastrutture. Il denominatore comune è rappresentato dal fatto che tutti i servizi hanno lo scopo di valorizzare l’infrastruttura, il software e i servizi esistenti del cliente, fornendo capacità open source alle funzioni core. Tutti i servizi che compongono il cloud privato sono stati progettati per funzionare in modo integrato, come in un sistema unico. IBM Cloud Private è constituito dai componenti chiave descritti in questa sezione.

RICORDA



https://www.ibm.com/cloud-computing/products/ibm-cloud-private/

https://www.ibm.com/cloud-computing/products/ibm-cloud-private/


La scelta di un’infrastruttura flessibileMolte aziende non hanno una singola piattaforma software o hardware nei loro data center. Al contrario, dispongono di diversi sistemi e componenti che si rivelano essenziali per l’operatività quotidiana. Inoltre, le centinaia di unità aziendali usano cloud pubblici diversi. L’ambiente di IBM Cloud Private può funzionare in qualsiasi ambiente hardware esistente, incluse le piattaforme basate su Intel e le soluzioni IBM Power Systems. IBM Cloud Private supporta inoltre OpenStack, VMWare, IBM Z, IBM Storage, IBM Hypercon-verged Systems e i fornitori cloud di terze parti. IBM Cloud Private è stato progettato per essere compatibile con i principali produttori di sistemi quali Cisco, Dell/EMC, Lenovo, Intel e NetApp.

Piattaforma di contenitori KubernetesLa “containerizzazione” costituisce la base della struttura del cloud privato. Il suo valore è chiaro. Mettendo il codice all’interno di container, è possibile creare un servizio che includa tutte le dipen-denze necessarie al funzionamento di quel dato servizio. Ogni contenitore è supportato da un’API (Application Programming Interface) standard. Pertanto, un contenitore può essere utilizzato per gestire microservizi creati da zero oppure per riprodurre un servizio o un’applicazione esistenti attraverso modalità nuove, proprio grazie all’incapsulamento all’interno dei container.

IBM Cloud Private offre la scelta fra diversi runtime di applicazione open-source, in linea con le offerte di cloud pubblico IBM, la tecno-logie Cloud Foundry o i container Kubernetes. I clienti possono optare per l’approccio di sviluppo di Cloud Foundry ovvero quello più portatile e personalizzabile dei container Kubernetes e Docker. La coerenza con il cloud pubblico di IBM offre la possibilità di scegliere i modelli di deployment lungo il ciclo di vita dei carichi di lavoro, insieme a un’esperienza di gestione coerente nel corso della maturazione e dell’evoluzione dei carichi di lavoro.

IBM Cloud Private ha incluso nei container anche i servizi di analisi, dati e middleware. Include inoltre il lavoro di un installatore unico che configura rapidamente un cluster Kubernetes-based dotato di nodi master, worker e proxy tramite un installatore basato su Ansi-ble. Essendo tutto inglobato in container, IBM consente di usare gli stessi servizi di runtime applicativi open-source su entrambi i cloud IBM, pubblico e privato.

RICORDA




I container gestiscono il modo in cui il codice esistente e quello di nuova creazione possono essere combinati al fine di ottenere un comportamento coerente e prevedibile. L’uso di un’architettura a container permette di manovrare e orchestrare le applicazioni e i loro servizi. Questo approccio inoltre è alla base della possibilità di spostare le applicazioni in piattaforme cloud diverse per meglio adattarsi alle esigenze dell’azienda.

Servizi e software ottimizzati per il cloudUno dei vantaggi derivanti dall’adozione dell’architettura a contai-ner all’interno di un cloud privato consiste nella capacità di creare una versione multitenant, grazie alla quale è possibile configurare diverse versioni di uno stesso ambiente cloud privato per ciascuno degli stakeholder IT, che riceverà un proprio gruppo di servizi personalizzati all’interno del cloud privato, rispondente al processo aziendale designato all’interno del firewall. Le reti tenant isolate utilizzano Calico (un servizio di policy di rete per i cluster Kuberne-tes) per migliorare le prestazioni e l’isolamento delle reti all’interno dei cluster.

Per garantire la coerenza, il cloud privato fornisce un catalogo comune di servizi che accelerano la produttività dello sviluppatore. La gestione scalabile dei microservizi è resa possibile da questa base comune di servizi. Inoltre, il catalogo supporta la scalabilità auto-matica delle applicazioni sia in senso orizzontale che verticale. I servizi del catalogo sono al centro delle attività di gestione e manu-tenzione di servizi software quali i microservizi e i container. La struttura del catalogo semplifica il controllo, la distribuzione e la manutenzione del software e dei servizi, così da favorire la rapidità delle attività di sviluppo e testing. I servizi principali utilizzati per gestire i cataloghi sono chart di Helm, template di Terraform, buil-dpack di Cloud Foundry.

IBM Cloud Private offre un’ampia gamma di servizi di analisi, dati e middleware operativo e di gestione, facilmente accessibili e coerenti, sia per applicazioni cloud-native nuove che per quelle esistenti. Le piattaforme dati e middleware cloud-native basate su Kubernetes, quali Microservice Builder, Data Science Experience e API-Connect, cooperano con IBM Cloud Private così da offrire microservizi di ultima generazione. IBM Cloud Private permette di utilizzare midd-leware per cloud di livello enterprise, per sfruttare le capacità di sviluppo delle applicazioni esistenti quali Java, Spring e Open Liberty. In più, offre la gestione e la connettività API per integrare pubblico e privato con le funzionalità esistenti in azienda.

RICORDA

RICORDA




IBM Cloud Private prevede funzionalità a supporto dello sviluppo di nuove applicazioni basate sui microservizi, dell’evoluzione e moder-nizzazione delle applicazioni esistenti e dell’integrazione fra appli-cazioni nuove ed esistenti. Insieme ai framework di runtime delle applicazioni, IBM mette a disposizione una serie di servizi di gestione fondamentali per questi framework e per le applicazioni che vengono su di essi distribuite. Per velocizzare la produttività degli sviluppatori, viene fornito un catalogo comune di servizi open e di livello enterprise. Questo catalogo comprende software gestito e di facile distribuzione che offre casi d’uso di produzione, test e sviluppo.

I servizi applicativi quali il middleware, i servizi dati e i servizi di sicurezza sono essenziali per rendere il cloud privato operativo e scalabile. Questo insieme di servizi di base comune è alla base della gestione scalabile dei microservizi: ad esempio, Istio (una piatta-forma aperta per la connessione, la gestione e la sicurezza di Kuber-netes), il controllo di Prometheus (un toolkit open-source per il monitoring e l’alerting) e il logging di ELK Stack (funzione svolta tramite tre diffusi strumenti: Elasticsearch, Logstash e Kibana).

IBM Cloud Private è stata progettata per offrire una soluzione end-to-end per applicazioni, includendo linguaggi e framework open-source più diffusi, DevOps integrati, soluzioni di livello enter-prise leader di settore e monitoring integrato, tutti presenti all’in-terno del portafoglio IBM per middleware, dati e analisi.

Strumenti di gestione e DevOps integratiI servizi di gestione e di integrazione sono essenziali per poter creare un ambiente cloud che agisca come fosse un singolo sistema. Ad esempio, tutti i servizi interni al cloud privato devono fondarsi sulla sicurezza. Parliamo di servizi quali il supporto all’identificazione, autenticazione e autorizzazione, in aggiunta a strumenti di alerting, auditing e di sicurezza per la scansione di immagini Docker o di container e altri servizi.

IBM Cloud Private è dotato di una console di gestione del cluster sicura e centralizzata per gestire, controllare e risolvere i problemi di applicazioni e cluster. Agli strumenti di gestione esistenti nell’im-presa viene aggiunto un gruppo di strumenti nuovi per la gestione del cloud. Tra le funzionalità di gestione più importanti ricordiamo:

SUGGERIMENTO

RICORDA




» L’accesso API alla piattaforma core per consentire elevati livelli di automazione necessari al CI/CD (Continuous Integration & Continuous Delivery).

» L’integrazione dei servizi e degli strumenti DevOps open-source e IBM per dare vita a repository di codice, deploy-ment, automazione di test e passaggio alla produzione.

» Nuove funzionalità di creazione, distribuzione e gestione di applicazioni basate su microservizi, tra cui Microprofile, Spring, Node, Microservice Builder e Istio.

» Funzionalità di valutazione della sicurezza integrate nella toolchain di DevOps (DevSecOps con IBM Vulnerability Advisor for Containers).

» Funzionalità di monitoring e logging guidate da analisi e create a partire da framework aperti ed estendibili (Prometheus, Istio, ELK, Grafana).

» Catalogo di servizi e software di facile gestione, manuten-zione e distribuzione che velocizza le fasi di sviluppo e test (chart di Helm, Template di Terraform, buildpack di Cloud Foundry).

» Metodi e architetture delle soluzioni best practice e servizi IBM Cloud Garage che favoriscono le trasformazioni delle imprese.

IL PRAGMATISMO DI UN’ARCHITETTURA IBRIDA

Ogni organizzazione possiede un enorme numero di applicazioni, dati, piattaforme, reti, strumenti di gestione e requisiti di sicurezza. Le archi-tetture di cloud ibrido permettono alle imprese di sfruttare i propri inve-stimenti esistenti, insieme a servizi flessibili, scalabili e modulari in modo che funzionino secondo le aspettative dei clienti. La sintesi tra i migliori servizi di cloud pubblico e privato rappresenta l’approccio più pragmatico per rispondere all’incessante necessità di innovare.



CAPITOLO 4 DevOps per il cloud privato 23

Capitolo 4

IN QUESTO CAPITOLO

» Uno sguardo alla natura mutevole di DevOps

» Favorire l’integrazione continua (CI) e l’erogazione continua (CD)

» Esame del ruolo svolto da IBM UrbanCode nel CI/CD

» Un’esperienza utente di livello superiore

DevOps per il cloud privato

Il cloud sta trasformando il modo in cui le organizzazioni si approcciano allo sviluppo, al deployment e all’utilizzo del software. Uno dei principali vantaggi offerti dall’architettura

cloud consiste nel consentire di astrarre la logica delle applicazioni, così da poter progettare le applicazioni in modo dinamico, utiliz-zando una nuova generazione di strumenti di sviluppo per applica-zioni cloud-based. In questo capitolo ci soffermeremo sui cambiamenti che stanno interessando l’approccio DevOps, sulla loro relazione con l’adozione del cloud e su come le società possono far evolvere le proprie strategie DevOps per allinearsi meglio alle imple-mentazioni di cloud privato.

La natura mutevole di DevOpsL’evoluzione delle architetture e delle implementazioni cloud ha l’effetto di produrre un continuo cambiamento nel mondo della progettazione, dello sviluppo e della distribuzione del software. La modularità può essere considerata il cuore della natura dei processi di DevOps, dal momento che attiene alle fasi di creazione, distribu-zione e rilascio del codice. Uno stretto allineamento dei processi di DevOps alle implementazioni del cloud privato è essenziale, tenuto conto dei cambiamenti in atto:




» Incremento nell’adozione di applicazioni basate su microser-vizi per la gestione, la distribuzione e la generazione di codice su cloud in cui è prevista scalabilità e gestione di una domanda variabile;

» Disponibilità di servizi e strumenti di DevOps nuovi ed integrati tramite cui dare vita a repository di codice, deploy-ment, automazione dei test e passaggio alla produzione all’interno degli ambienti cloud;

» Utilizzo di tecnologie container per gestire i microservizi interni alle applicazioni;

Tenuto conto delle profonde variazioni negli approcci e nelle archi-tetture della tecnologia cloud, le organizzazioni DevOps stanno ora iniziando a concentrarsi sull’integrazione e sull’erogazione conti-nue in ambienti di sviluppo agili. Il bisogno di abbassare i costi, aumentare la velocità del time to market e ridurre i rischi, sta creando l’urgenza di produrre soluzioni che combinino processi di DevOps con modelli di cloud privato. La base di una nuova genera-zione di progettazione, sviluppo, distribuzione e utilizzo del software risiede nelle necessità di avere prestazioni, elasticità e modularità di tipo self-service.

IBM GARAGE METHOD

Utilizzare a pieno DevOps rappresenta la chiave per il successo della soluzione IBM Cloud Private. IBM Cloud Garage Method è l’approccio con cui IBM sostiene i settori operativi, di sviluppo ed economici nella proget-tazione, erogazione e convalida di nuove funzioni. Pratiche, architetture e toolchain coprono l’intero ciclo di vita del prodotto, dal principio fino alla ricezione, in risposta ai feedback del cliente e alle variazioni nel mercato.

L’IBM Garage Method è composto dalle seguenti aree:

• Cultura: processo di trasformazione attraverso l’integrazione di innovazioni tecnologiche, di processo e aziendali che consentano di creare team capaci di apprendere rapidamente dalle esperienze di mercato.

• Pensiero: incremento progressivo dell’adozione di soluzioni inno-vative tramite l’uso di IBM Design Thinking e delle relative proce-dure di progettazione.




Integrazione continua (CI) ed erogazione continua (CD)

Le applicazioni e i microservizi vengono costantemente aggiornati a seguito della creazione da parte delle aziende di nuovi servizi capaci di rispondere ai bisogni mutevoli dei clienti. Per questo motivo, il cloud è diventato il veicolo più pratico ed efficace per lo sviluppo e la distribuzione delle applicazioni. Le tecniche di CI/CD (Continuous Integration/Continuous Delivery) consentono ai team di fornire software più rapidamente e con meno rischi. Enfatizzando l’aspetto della rapida erogazione di codice utilizzabile attraverso l’automa-zione di build, test e deployment, le società possono comprendere più rapidamente il valore del modello CD (Continuous Delivery).

Con queste tecniche infatti l’azienda necessita di comprendere rapi-damente se le modifiche apportate all’applicazione hanno avuto i risultati desiderati. Per essere certi che i clienti siano soddisfatti

• Codice: adozione di pratiche di sviluppo volte alla creazione di applicazioni cloud-native capaci di rilasciare funzioni incrementali, raccogliere feedback e misurare risultati.

• Erogazione: accelerazione del time-to-market grazie al ricorso all’integrazione continua, al deployment ininterrotto e all’automazione di processi trasparenti e ripetibili.

• Esecuzione: utilizzo di soluzioni ad elevata disponibilità tramite Cloud Foundry, container o macchine virtuali, all’interno di piatta-forme cloud di qualsiasi tipo, inclusi i cloud pubblici, dedicati, pri-vati o ibridi.

• Gestione: garanzia di eccellenza operativa tramite il controllo con-tinuo delle applicazioni e l’adozione di pratiche di alta disponibilità e immediato ripristino, volte a velocizzare l’individuazione e la risoluzione dei problemi.

• Apprendimento: sperimentazione continua tramite il testing di ipotesi, con l’uso di misure chiare per l’adozione di decisioni e con individuazione di soluzioni all’interno dei backlog per una più effi-cace reattività.

Per ulteriori informazioni su IBM Cloud Garage Method, visitare il sito web www.ibm.com/cloud/garage.



http://www.ibm.com/cloud/garage


delle modifiche, il processo deve prevedere testing frequenti di unità, build, deployment e integrazioni, oltre a rilasci di codice.

Parte del processo di CI/CD prevede l’uso di pipeline - una sequenza automatizzata di attività che permette alle organizzazioni di gene-rare, testare e distribuire servizi al sistema target. Il valore dei servizi di pipeline, come Jenkins, consiste nella capacità di fornire agli sviluppatori la visibilità sull’intero processo di DevOps.

Molte organizzazioni oggi dispongono di topologie multi-cloud che possono rendere insostenibili le distribuzioni manuali di codice, di per sé lente e soggette a errori. Quando alle organizzazioni IT viene chiesto di supportare diversi data center e numerosi cloud, anche i deployment codificati possono diventare rischiosi, difficili da trac-ciare e costosi da gestire. Ne consegue che le topologie multi-cloud necessitano di un modello di deployment automatizzato.

IBM usa tecnologie aperte come GitHub Enterprise e Jenkins per generare architetture CI/CD. Ulteriori dettagli su queste architetture sono disponibili all’indirizzo https://goo.gl/1XU5qt.

In uno degli esempi, il modello usa Jenkins Helm Chart per instal-lare un pod Jenkins Master con il Plugin Kubernetes in un Cluster Kubernetes. Helm è un gestore di pacchetti Kubernetes progettato per semplificare il deployment di risorse Kubernetes riutilizzabili e precedentemente impacchettate. Questa configurazione consente a Jenkins di avvalersi di pod effimeri per eseguire lavori e pipeline Jenkins, senza la necessità di avere server slave/worker dedicati sempre attivi. Un approccio questo che riduce i costi dell’infrastrut-tura Jenkins. IBM Cloud Private fornisce inoltre acceleratori come Microservice Builder che genera file Jenkins per le applicazioni dei microservizi.

È possibile utilizzare Jenkins in combinazione al IBM Cloud Private in svariate situazioni. Inoltre, Jenkins può essere visto anche come una soluzione completa di automazione del deployment all’in-terno di cloud pubblici e privati. Senza contare che può essere utiliz-zato per la distribuzione di servizi containerizzati distinti, eventualmente necessari alla gestione dei container con le macchine virtuali.

RICORDA



https://goo.gl/1XU5qt


Il ruolo svolto da IBM UrbanCode nel CI/CDLa suite di prodotti IBM UrbanCode è stata concepita per supportare il CI/CD. UrbanCode Build, UrbanCode Deploy e UrbanCode Release agevolano la rapidità del feedback e l’erogazione continua in un ambiente di sviluppo agile. La suite inoltre permette l’audit trail, il versioning e le approvazioni necessari nella fase di produzione. Questi prodotti hanno la funzione di rendere più prevedibili i rilasci e consentire di ridurre i tempi tra le fasi di concept, rollout e feedback, velocizzando il time to market.

Ad esempio, UrbanCode Deploy è una soluzione IBM che permette di automatizzare i rilasci, utilizzata dai team di DevOps per mettere in produzione le attività automatizzate della pipeline. È scalabile verso l’alto fino alle distribuzioni di livello enterprise, con la gestione di migliaia di server. UrbanCode Deploy permette ai team IT di distri-buire servizi ad un tipo di deployment eterogeneo, come nel caso di cloud privati o pubblici. In più, consente di eseguire l’audit e il trac-ciamento di ciò che accade al codice dell’applicazione. Una funzione particolarmente utile quando si sposta il codice dalla fase di test a quella di produzione. Essere a conoscenza di ciò che accade interna-mente è essenziale in un ambiente cloud ibrido in cui il codice viene modificato di continuo. Ad esempio, quali sono le modifiche appor-tate al codice? Chi ha fatto tali modifiche? Il codice è sicuro o si sono verificate aperture di backdoor nel codice che possono averne compromesso la sicurezza? UrbanCode Deploy fornisce funzioni di audit del codice che consentono ai team di DevOps di tracciarne l’integrità.

Per ulteriori informazioni su IBM UrbanCode consultare developer.ibm.com/urbancode.

Un’esperienza utente migliorePensiamo a un compagnia aerea e a ciò che le occorre per fornire un servizio eccellente che porti i clienti a destinazione in modo rapido e sicuro. In un mondo perfetto, i clienti acquistano i biglietti, li mostrano al terminal, salgono sull’aero e partono. Ma, come ben sappiamo, le cose tendono spesso a farsi più complicate. Possono verificarsi problemi meccanici, sovrapposizione di orari, cancella-zioni di voli, ritardi sulla pista e un’ampia gamma di fenomeni atmosferici come uragani o tempeste di neve. Le compagnie aeree



https://developer.ibm.com/urbancode/

https://developer.ibm.com/urbancode/


potrebbero dover riprogrammare centinaia di voli, riproteggere migliaia di clienti e recuperare migliaia di tonnellate di bagagli.

Una compagnia aerea si convinse che, per gestire con successo queste problematiche, fosse necessario ottimizzare i processi DevOps così da rispondere all’esigenza di una continua integrazione ed erogazione di microservizi. Uno degli obiettivi principali consi-steva nel riuscire a migliorare l’esperienza vissuta dai clienti più importanti della compagnia. Le applicazioni monolitiche vennero suddivise in microservizi attraverso l’uso di Microservices Builder. Il codice che non poteva essere riscritto venne incapsulato. I micro-servizi furono automatizzati attraverso i servizi pipeline, oltre ad essere combinati all’interno di container gestiti in modo da offrire un nuovo modello self-service. Le applicazioni generate nel cloud privato furono estese per sfruttare servizi chiave come i dati mete-orologici, in modo da offrire ai passeggeri la possibilità di ri-preno-tare i voli avendo chiare le condizioni meteo. I servizi furono testati e messi in produzione.

I risultati furono notevoli. La compagnia aerea riuscì a trasformare i propri servizi principali, come la prenotazione del posto, la rotta dell’aereo, la registrazione dei dati di localizzazione e il traccia-mento dei clienti, in una serie di microservizi ospitati in container orchestrati. Il team di DevOps riuscì così a generare e distribuire rapidamente nuovi servizi riducendo i rischi.

Questo approccio permise sia ai clienti che alle agenzie di ripro-grammare rapidamente i voli al cambio delle situazioni. I processi di DevOps utilizzati furono alla base della scalabilità on-demand e dell’elaborazione dei dati. L’ambiente di cloud privato riuscì a gestire il carico e supportare i bisogni dei clienti della compagnia aerea. Fu anche possibile collegarsi perfettamente con il cloud pubblico e accedere ai servizi chiave come i dati meteorologici. Grazie all’approccio di CI/CD appena implementato nel cloud privato, la compagnia aerea continuerà ad aggiungere nuovi servizi e ulteriori innovazioni, riuscendo così a ottenere crescita e competitività.



CAPITOLO 5 Analisi dei dati nel cloud privato 29

Capitolo 5

IN QUESTO CAPITOLO

» Comprendere il valore dell’analisi dei dati

» Uno sguardo al ruolo svolto dalla scienza dei dati nell’analisi dei dati

» Comprendere il machine learning

» Importanza del cloud ibrido quando si esegue l’analisi

Analisi dei dati nel cloud privato

L’idea di sfruttare un gran quantitativo di dati per comprendere meglio modelli e anomalie è stato un obiettivo inseguito per decenni da numerose aziende. Un ambiente di cloud ibrido

costituisce una piattaforma ideale per molti progetti di analisi inten-siva dei dati, perché è costruito su un modello di computazione distribuita. Ad esempio, un’applicazione basata sull’analisi può contare sui dati provenienti da un gran numero di fonti che si trovano nel cloud privato, nei cloud pubblici oltre che all’interno dell’azienda in caso di applicazioni meno recenti. Le analisi che utilizzano dati dei clienti e altri dati sensibili possono essere eseguite in locale, all’in-terno di cloud privati. Inoltre, sfruttando il cloud pubblico è possibile accedere a risorse computazionali molto potenti on demand.

In questo capitolo, esaminiamo l’innovazione offerta dai modelli di machine learning e dall’analisi dei dati nel contesto dl cloud privato.

Il valore dell’analisi dei datiIl ricorso all’analisi per adottare migliori decisioni di business prevede, in genere, la necessità di unire diversi gruppi di dati prove-nienti da diverse fonti. Ad esempio, potrebbe essere necessario sviluppare un modello di analisi predittivo per migliorare la




conoscenza delle aspettative dei clienti e delle tendenze. Il modello necessita di dati accurati e puntuali provenienti dal sistema dei dati, diverse applicazioni SaaS (Software-as-a-Service), dati dei social media e dati demografici. Sfruttando le prestazioni e l’elasticità di un cloud privato, le organizzazioni possono analizzare dati complessi in prossimità della rispettiva fonte. In altre parole, molte volte i dataset più estesi sono gestiti all’interno del data center. Molte organizza-zioni preferiscono mantenere i dati protetti dietro il proprio firewall, per diverse ragioni. Inoltre, l’essere in grado di svolgere l’analisi in prossimità della sede dei dati risulta spesso più pratico, tenuto conto dell’aumento di velocità e della corrispondente ridotta necessità di spostare i dati.

Uno dei principali benefici dello svolgimento dell’analisi dei dati all’interno di un ambiente cloud consiste nella capacità di fornire un’interfaccia self-service. L’estrazione di fonti di dati eterogenee attraverso un’interfaccia di portale permette a un numero maggiore di professionisti aziendali di analizzare dati complessi. In questo caso, gli scienziati dei dati riescono a creare modelli che possono essere trasformati in un gruppo di moduli self-service utili anche agli altri dipendenti.

Il ruolo svolto dalla scienza dei dati nell’analisi dei dati

Il potenziale della scienza dei dati sta diventando sempre più chiaro a molte aziende. Tuttavia, non è facile riuscire a trovare le risorse e i talenti necessari a creare ed eseguire modelli. Infatti, non esistono abbastanza scienziati dei dati a sostegno del tipo di analisi richiesto dalle aziende. Per rispondere efficacemente a questa esigenza, le organizzazioni IT devono trovare servizi di supporto che implemen-tino la prevedibilità e la ripetibilità nel processo della scienza dei dati.

Per aiutare ad affrontare la sfida insita nel mettere il machine lear-ning a servizio dell’enterprise, IBM ha creato il framework Data Science Experience (DSX) con l’obiettivo di semplificare la collabora-zione fra colleghi. Gli scienziati dei dati possono creare un repository composto da algoritmi predittivi e prescrittivi, dati curati e modelli pre-testati. L’ambiente DSX è stato progettato con componenti open-source, così da permettere agli scienziati dei dati di sfruttare le librerie di machine learning e le altre risorse che si trovano all’in-terno della comunità open-source. La piattaforma supporta le tecno-logie open-source più diffuse, incluso R, Python e Spark. DSX mette

SUGGERIMENTO




a disposizione un gruppo di servizi in grado di connettere queste fonti di dati dell’impresa con una varietà di strumenti di machine learning attraverso un’interfaccia utente. I servizi forniti all’interno di questo framework includono anche un’ampia varietà di notebook sulla scienza dei dati. Inoltre, DSX è dotato di meccanismi di sicu-rezza che impediscono l’accesso ai dati non autorizzato. Anche se l’ambiente è condiviso, l’utente può accedere solo ai dataset che è autorizzato a vedere e utilizzare.

Comprendere il machine learningIl machine learning è un insieme di potenti tecnologie in grado di aiutare le organizzazioni ad evolvere la loro capacità di esaminare i dati. Questo approccio tecnologico è decisamente diverso dagli altri modi in cui le aziende hanno tradizionalmente utilizzato i dati e creato le applicazioni. Piuttosto che partire dalla logica di settore e poi applicare i dati, le tecniche di machine learning permettono ai dati di modellare la logica necessaria a conseguire gli obiettivi azien-dali. Uno dei principali vantaggi di questo approccio consiste nel superamento di presunzioni e preconcetti.

Il machine learning è una tipologia di Intelligenza Artificiale (IA) che consente a un sistema di imparare dai dati piuttosto che dalla programmazione. Tuttavia, non si tratta di un processo semplice, dal momento che vengono utilizzati numerosi algoritmi per creare dei modelli, che saranno poi in grado di apprendere dai dati in modo iterativo, per migliorare, descrivere i dati stessi e prevedere i risultati.

Capita spesso che ci si trovi a interagire con le tecniche di machine learning all’interno delle applicazioni senza neanche rendercene conto. Ad esempio, quando si visita un sito web di e-commerce e si inizia ad esaminare i prodotti o a leggere le recensioni, è probabile che si riceveranno suggerimenti per prodotti similari che potrebbero interessarci. Analogamente, quando si chiama un call center dedi-cato ai clienti, l’operatore potrebbe offrire suggerimenti basati sui dati che gli vengono forniti. Non esistono eserciti di sviluppatori che abbiano inserito nel codice questo tipo di suggerimenti. Al contrario, i suggerimenti sono frutto di un modello di machine learning. Il modello analizza i dati storici associandoli ai dati che gli vengono forniti in tempo reale per fare previsioni sulla prossima azione più probabile.




Il ruolo del cloud privato nell’analisi avanzataAccostandosi al machine learning, molte organizzazioni hanno scoperto che l’utilizzo di un ambiente di cloud privato rappresenta la via più pragmatica per assicurarsi scalabilità, sicurezza e confor-mità. Il cloud privato fornisce una piattaforma che si trova dietro il firewall, capace di offrire le prestazioni e l’elasticità necessarie per supportare le complessità dell’analisi avanzata. Sicuramente sono tante le organizzazioni che usano il cloud pubblico per analizzare quantità estese di dati. Tuttavia, in alcune situazioni, questa via non è praticabile. Le aziende iniziano ad applicare modelli di machine learning a quelle iniziative strategiche che potrebbero essere in grado di cambiare il modo in cui viene gestito il proprio business. Molte aziende pertanto esitano a gestire quei dati in un cloud pubblico per questioni legate alla sicurezza e alla privacy. Anche se il cloud pubblico dispone di un’infrastruttura di sicurezza sofisti-cata, molte aziende si sentono più sicure a controllare internamente questi asset strategici. Inoltre, è necessario anche prendere speciali misure di sicurezza relativamente a determinate tipologie di dati, come nel caso dei referti medici, delle informazioni che permettono di identificare le singole persone, della registrazione dei clienti o dei dati bancari.

In alcune situazioni, le società potrebbero decidere di lanciare all’in-terno del cloud pubblico alcune analisi dei loro dati che implicano l’utilòizzo di fonti di dati pubblici, passando al cloud privato solo quando si tratta di utilizzare dati relativi a iniziative di business strategiche o dati dei clienti. Quando i dati si trovano in un cloud privato è possibile utilizzare servizi di cloud pubblico, come ad esempio le API Watson di IBM, per applicare l’analisi cognitiva ai casi aziendali, mentre i dati si trovano protetti e al sicuro all’interno del cloud privato.

Gestione “ibrida” dei datiOltre a utilizzare i dati in un ambiente di cloud ibrido, molte orga-nizzazioni conservano i dati in ambienti eterogenei. Ad esempio, è possibile conservare i dati strutturati all’interno di sistemi CRM e transazionali e i dati non strutturati all’interno di un data lake. In molti casi, i dati vengono conservati all’interno di database di diversi fornitori. L’obiettivo della gestione dei dati ibrida consiste nella possibilità di utilizzare questi dati in modo che soddisfino esigenze aziendali. A questo scopo le aziende necessitano di un modo per gestire e ottenere gli insight derivanti da questi dati, ovunque essi risiedano. Come parte del proprio approccio alla gestione dei dati




ibrida, IBM fornisce un motore Common SQL, che permette alle organizzazioni di sfruttare i dati ovunque si trovino attraverso Db2, Oracle, SQL Server e altre fonti di dati. Se usato in unione con Db2 Warehouse di IBM, l’analisi può essere eseguita lì dove i dati risiedono.

Analisi avanzata a supporto del cloud ibridoLe organizzazioni non hanno a disposizione un unico modo per gestire e analizzare i dati. Abbiamo rilevato tre diversi scenari:

» La maggior parte dei dati dell’organizzazione viene archiviata dietro al firewall e la società desidera eseguire l’analisi in locale.

» L’organizzazione o la divisione interna a una società archi-viano la maggior parte dei dati nel cloud e desiderano analizzare i dati distribuiti al suo interno.

» L’organizzazione vuole utilizzare un approccio ibrido in cui vengono riuniti i dati in locale con quelli presenti nel cloud, per analizzarli usando gli uni come contesto degli altri.

Non sorprende che la maggior parte delle società preferisca l’ap-proccio ibrido, in cui l’analisi avviene insieme su dati in locale e dati nel cloud pubblico.

Questi scenari hanno un elemento in comune: vogliono tutti utiliz-zare le moderne tecniche di IA e machine learning per poterle appli-care ai dati. E non si tratta di un problema di facile soluzione. Le organizzazioni devono conoscere la struttura, l’origine e la veridi-cità dei propri dati. Se non si ha una cura approfondita per i propri dati è molto facile adottare decisioni operative sbagliate.

In questa sezione, ci occuperemo di ognuno di questi scenari.

Utilizzo delle fonti di dati localiI data warehouse sono stati una costante dei data center per decenni. Sebbene questi sistemi di dati siano spesso complessi, offrono un ricco set di risorse che permettono di comprendere meglio i clienti e il mercato. Tuttavia, le organizzazioni in genere effettuano delle ricerche nei dati, piuttosto che delle vere e proprie analisi avanzate. I framework e gli strumenti di machine learning stanno modifi-cando questo stato di cose. Molte organizzazioni IT vogliono poter




applicare gli algoritmi di machine learning a questi dati. Uno degli approcci più pragmatici consiste nell’utilizzo dei framework e dei notebook di machine learning per acquisire i dati che sono conser-vati nei warehouse o nei data lake così da poter svolgere l’analisi. Inoltre, è possibile sfruttare i software di connessione per acquisire ulteriori fonti di dati all’interno di un framework, così da poter analizzarne i dati, ottenere insight e prevedere i risultati.

Analisi avanzata di tipo cloud-nativeSia le società consolidate che quelle nate nel cloud hanno enormi quantità di dati archiviati nei cloud pubblici o privati e più precisa-mente in diverse applicazioni SaaS, database cloud e repository di storage cloud. Mentre i data warehouse o i data lake possono essere centralizzati nel data center, i dati del cloud sono distribuiti in modo diffuso. Per eseguire analisi avanzata e machine learning in un ambiente così distribuito, le società necessitano di una piattaforma di analisi capace di raccogliere insieme i dati.

Va aggiunto che, dal momento in cui si stanno aggregando dati provenienti da dataset diversi appartenenti tra l’altro ad applica-zioni e ambienti diversi, è necessario aver previsto un processo che curi il controllo della versione.

Supporto del cloud ibrido all’analisi avanzataMolte aziende stanno operando all’interno di un mondo ibrido, composto da un data center, un cloud privato e l’utilizzo di risorse residenti in cloud pubblici. Tuttavia capita spesso che molte aziende non riescano ad esaminare i propri dati in un contesto comune e complessivo. È probabile che i dati relativi ai clienti archiviati nell’applicazione CRM vengano analizzati separatamente rispetto ai dati relativi alle vendite e all’inventario che risiedono in locale. E invece i veri vantaggi offerti dall’analisi avanzata e dal machine learning emergono proprio quando i singoli set di dati vengono esaminati costituendo l’uno il contesto dell’altro. In questo scena-rio, si preferisce mantenere i dati dove sono, ovvero non si ha inten-zione di spostare certe tipologie di dati nel cloud, così come non si desidera trasferire enormi quantità di dati del cloud all’interno del proprio data center. L’analisi di tutti i dati all’interno dello stesso contesto comune permette di iniziare a individuare pattern capaci di mettere in discussione preconcetti di lunga data sull’azienda, indi-viduando così nuove opportunità di business.

RICORDA



CAPITOLO 6 Gestione di un ambiente multi-cloud 35

Capitolo 6

IN QUESTO CAPITOLO

» Preparare la strada verso la gestione di un ambiente ibrido

» Visibilità come principio essenziale

» La logica relativa alla gestione multi-cloud

» Requisiti della gestione multi-cloud

» Strumenti e servizi necessari a gestire un ambiente multi-cloud

Gestione di un ambiente multi-cloud

Per riuscire a rispondere ai mutevoli bisogni del mercato, l’IT deve sviluppare un nuovo approccio alla gestione delle risorse. I responsabili aziendali richiedono che il computing venga

gestito in modo organizzato e prevedibile, a prescindere dal luogo in cui si trovano i carichi di lavoro o dal modo in cui siano stati proget-tati. I modelli di deployment devono essere gestiti come fossero in un ambiente unico. Per questi motivi la gestione IT necessita della capacità di ottenere un ambiente multi-cloud che sfrutti la standar-dizzazione e l’automazione. Questo capitolo esamina le problemati-che e le tecnologie correlate alla gestione di un ambiente multi-cloud. Inoltre fornisce informazioni utili sulle modalità con cui IBM Cloud Private si integra in questa gestione.




Preparare la strada verso la gestione dell’hybrid computing

Per fare in modo che diversi sistemi funzionino come fossero un ambiente unico, è di vitale importanza garantirsi visibilità, controllo e sicurezza, tanto per i singoli elementi quanto per il loro complesso. Ipotizzando di avere 20 diversi team di sviluppo in un’organizza-zione, ciascun gruppo potrebbe scegliere una diversa piattaforma cloud e una varietà di strumenti di DevOps. Tutto ciò potrebbe non avere conseguenze nelle prime fasi di creazione e gestione delle singole applicazioni, ma è facile che i problemi possano affacciarsi quando queste applicazioni e questi servizi diventeranno strumen-tali al funzionamento dell’azienda, specialmente se tali applicazioni e servizi dovranno essere condivisi tra le diverse unità aziendali.

Maggiore visibilitàUno dei vantaggi del cloud privato consiste nel fatto che tutti gli elementi dell’ambiente sono controllati dall’organizzazione. Nel passaggio a un ambiente ibrido, è importante riuscire a mantenere visibilità e controllo dell’ambiente. Esistono molte tecniche utiliz-zate nell’ambiente cloud, tra cui: macchine virtuali (VM), microser-vizi, piattaforme di gestione delle API e architetture serverless (dove il cloud gestisce dinamicamente l’allocazione delle risorse e dei container della macchina).

In un ambiente di cloud ibrido, l’organizzazione ha bisogno di gestire diversi servizi, come le applicazioni del data center, i SaaS (Software as a Service), le IaaS (Infrastructure as a Service) e le PaaS (Platform as a Service). Ecco perché risulta essenziale per la gestione IT la possibilità di disporre di una tecnica di estrazione semplificata o di un dashboard che gestisca l’ambiente multi-cloud.

Questi strumenti di gestione o dashboard aggregano i dati prove-nienti da diversi servizi e piattaforme, sia nel cloud che in locale. Alcuni di questi strumenti di gestione stanno ora utilizzando il machine learning e l’analisi avanzata per comprendere i modelli di comportamento ripetuti tra i diversi ambienti cloud, così da poter garantire che i servizi unificati funzionino nel modo desiderato.




Comprendere la logica relativa alla gestione multi-cloud

L’ambiente multi-cloud necessita di una soluzione che consenta di gestire in modo centralizzato i carichi di lavoro e le relative risorse sottostanti tra tutti i servizi che vengono utilizzati nel cloud. Cos’è che rende la cosa così complessa? Ogni ambiente cloud prevede il proprio gruppo di servizi e soluzioni di gestione delle risorse.

Requisiti della gestione di ambienti multi-cloud

Per creare una piattaforma operativa è necessario che tutti i servizi siano identificati e gestiti in modo unificato. Pertanto, occorre disporre di un gruppo di servizi che creino un ambiente coeso. Tali servizi saranno elencati di seguito in questa sezione.

Catalogo dei serviziUn catalogo di servizi svolge una funzione essenziale nella gestione dei servizi all’interno di un ambiente cloud ibrido. È importante stabilire il contesto all’interno di una varietà di servizi IT, a prescin-dere dal luogo in cui questi siano fisicamente localizzati. Il catalogo dei servizi ha proprio la funzione di individuare e definire i servizi a disposizione di sviluppatori e utenti, permettendo così di conseguire gli obiettivi operativi. Il catalogo definisce i parametri e le caratteri-stiche di ciascun servizio descrivendo, ad esempio, chi è autorizzato a utilizzare il servizio, il modo in cui può essere utilizzato, quali sono i requisiti di sicurezza richiesti e quali sono le sue dipendenze.

Il catalogo permette inoltre al team IT di gestire i servizi che vengono distribuiti di solito, in modo da assicurare la conformità, la coerenza e la sicurezza rispetto a quanto previsto dalle policy aziendali. In genere un catalogo elenca servizi IT quali provisioning, storage, immagini VM, autenticazione e processi aziendali.

Ciascun servizio individuato e gestito nel catalogo dei servizi deve essere valutato con cura. Il servizio va individuato sia dal team IT che dall’azienda come risorsa importante che dovrà essere utilizzata dalle diverse unità aziendali. Dopo che il servizio è stato individuato, AVVISO




deve esserne testata l’accuratezza. Questi servizi devono inoltre essere accompagnati dalle policy che ne regolano l’uso. Chi all’in-terno del team IT o dell’azienda è autorizzato a usare questo servizio e a quale scopo? Quali modelli di deployment sono consentiti per utilizzare questo servizio? Può essere eseguito in un determinato cloud pubblico o privato? In che modo il servizio si integra con gli altri servizi? Il catalogo dei servizi fornisce una guida su quelli che possono essere integrati attraverso API (Application Programming Interface) ben definite.

Uno dei vantaggi offerti dal catalogo dei servizi consiste nel fatto che conserva i dettagli del servizio astratti da quelli relativi all’utente di quel servizio. Il codice effettivo viene incapsulato in modelli, contai-ner o immagini Docker. Il catalogo inoltre indica come e quando è possibile modificare un servizio.

Gestione delle configurazioniI dipartimenti IT utilizzano i servizi di gestione delle configurazioni software per mantenere traccia di tutte le versioni e i moduli del codice che vengono creati durante il processo di sviluppo del software. La gestione della configurazione raccoglie dati relativi alle dipendenze tra i servizi eseguiti in diversi modelli di deployment. In un ambiente multi-cloud, è prevista la gestione di diverse risorse, inclusi i servizi di bare metal, immagini VM e container. Ogni ambiente ha esigenze di gestione delle configurazioni proprie diverse da quelle di altri ambienti, che vanno quindi attentamente controllate. In un ambiente multi-cloud è necessario coordinare gli approcci alla gestione delle configurazioni.

Uno degli aspetti rilevanti della gestione delle configurazioni consi-ste nella capacità di riuscire a implementare regole di governance e sicurezza all’interno dell’ambiente multi-cloud, la qual cosa non è affatto facile, se si considera che ambienti di cloud diversi possono avere gestioni delle configurazioni diverse.

Automazione e orchestrazione dei serviziL’automazione dei servizi definisce il processo automatizzato che distribuisce un servizio in modo coerente. L’orchestrazione dei servizi si concentra invece sulla coordinazione di questi servizi al fine di garantire disponibilità, resilienza e prestazioni. Per poter riunire i servizi presenti in diversi cloud, è necessario definire i modelli o i pattern di interazione reciproca dei servizi, con modalità che assicurino la conformità alle regole di governance.

SUGGERIMENTO

RICORDA




L’orchestrazione dei servizi opera fondamentalmente quando si intende creare un’applicazione a partire da servizi esistenti. Ciò prevede che i processi vengano gestiti e orchestrati attraverso l’uso di wrapper di API. Se il catalogo dei servizi ha la funzione di indivi-duare e classificare i servizi, l’automazione e l’orchestrazione costi-tuiscono le tecniche necessarie a collegare fra loro questi servizi in modo da creare flussi di lavoro. Attività che si ripetono con bassa frequenza possono essere gestite attraverso l’automazione dei servizi. Si tratta in genere di servizi non visibili all’utente. L’auto-mazione viene utilizzata per attività quali l’apertura di un ticket di assistenza o il provisioning di un’istanza cloud.

Al contrario, l’orchestrazione dei servizi interviene quando l’attività prevede la riunione di diversi servizi definiti nel catalogo per creare un nuovo processo di business. Il valore dell’orchestrazione dei servizi risulta evidente quando ci si sposta nel modello “As-a-Ser-vice”, dove vengono utilizzati una varietà di servizi predefiniti e li si collega insieme in modo dinamico. Un contrasto netto con le appli-cazioni tradizionali, scritte come un processo end-to-end. L’orche-strazione va implementata insieme alla gestione delle prestazioni dell’applicazione: non sarebbe sufficiente limitarsi a collegare le applicazioni fra loro. La criticità sta proprio nella necessità di assi-curare che, quando questi servizi danno vita a una nuova applica-zione, le prestazioni soddisfino le esigenze aziendali.

Creazione di una piattaforma bilanciata con la gestione delle API

Tutti i servizi menzionati in questo capitolo sono indispensabili alla creazione di un sistema ben funzionante, costituito da componenti che risiedono in ambienti diversi, quali cloud pubblici, privati e data center locali. La gestione di un ambiente multi-cloud necessita di standardizzazione e automazione. Senza la standardizzazione, un’organizzazione sarebbe costretta a conoscere tutti i dettagli di ogni singolo ambiente cloud e di ogni singola piattaforma. Senza la standardizzazione, un ambiente multi-cloud non sarebbe neanche immaginabile. Infatti, è proprio la standardizzazione che permette l’automazione delle attività necessarie alla creazione di un cloud ibrido. La gestione delle API rappresenta un sistema che apporta coerenza all’utilizzo delle API durante tutto il loro ciclo di vita. Si tratta di un punto critico, visto che le API costituiscono anche un mezzo essenziale per la condivisione di questa proprietà intellet-tuale con clienti e partner.




Tramite un normale portale o una piattaforma di gestione delle API si ottiene l’amministrazione centralizzata per eseguire il deploy-ment in modo più semplice e sicuro. La piattaforma di gestione delle API integra un gruppo di strumenti che agevolano i processi di build, debug e deploy di queste API. Il portale di gestione delle API può essere utilizzato anche per scoprire le API esistenti e le regole che governano il loro utilizzo. Inoltre, il portale può monitorare le prestazioni delle API, così da agevolare la gestione delle prestazioni del sistema.

Ad esempio, IBM offre IBM API Connect, progettato per gestire le API lungo tutto il loro ciclo di vita, dalla creazione, alla messa in sicurezza e all’analisi sul loro utilizzo. Per ulteriori informazioni, visitare la pagina Web developer.ibm.com/apiconnect.

La gestione in un mondo di microserviziI vantaggi offerti dai microservizi assumono sempre più importanza per le aziende (i microservizi vengono esaminati in maggior detta-glio nei capitoli 3 e 4). Sebbene sia semplice comprendere i vantaggi dei microservizi, più complessa può risultare la loro gestione. Piut-tosto che avere applicazioni estese gestite come singolo servizio, in un mondo fatto di microservizi containerizzati si hanno applicazioni composte da dozzine se non migliaia di microservizi. A seconda dell’approccio di sviluppo scelto dall’organizzazione, è molto proba-bile che i microservizi:

» Adotteranno diversi linguaggi e tecnologie;

» Saranno seguiti da team diversi nel dipartimento di sviluppo;

» Integreranno un proprio controllo di versione e supporto all’aggiornamento.

Vista l’importanza dei microservizi, in che modo è possibile creare un ambiente di gestione che comprenda questi servizi e permetta loro di funzionare bene insieme? In estrema sintesi, è necessario che vi sia un livello software-defined che si collochi al di sopra di tutti i sistemi e permetta a questi microservizi di interagire. I microservizi includono a loro volta un insieme di API standardizzate in grado di interagire con questo livello superiore.

SUGGERIMENTO



https://developer.ibm.com/apiconnect/


IBM Cloud Automation ManagerIBM Cloud Automation Manager (CAM) è stato progettato apposita-mente per offrire al team IT centrale la possibilità di conseguire una gestione reattiva tra i diversi cloud adottati dall’azienda. IBM CAM definisce un gruppo di modelli di automazione che contengono un set di risorse insieme con i relativi attributi verso molti ambienti, tra cui i cloud VMware, OpenStack, IBM Cloud, Amazon EC2 e Microsoft Azure.

Per riuscire a gestire con più semplicità un ambiente multi-cloud, IBM CAM supporta modelli progettati in Terraform, che è possibile applicare a una gran varietà di ambienti. In questo modo si ottiene la capacità di gestire ambienti multi-cloud attraverso modelli che possono essere configurati sulla base dell’infrastruttura adottata. L’automazione comporta il fatto che si può fare a meno di scrivere codice manualmente. Pertanto, è possibile integrare i microservizi in VM e container, all’interno di oggetti singoli che saranno poi collocati nel catalogo dei servizi.

Per ulteriori informazioni su IBM CAM visitare la pagina Web www.ibm.com/us-en/marketplace/cognitive-automation.

TerraformIBM CAM utilizza Terraform, uno strumento open-source suppor-tato da tutti i più importanti fornitori di cloud, come linguaggio di configurazione. Si tratta di un ambiente software per la creazione, la modifica e il versioning IaaS. Terraform crea configurazioni basate sulla piattaforma, per poi generare un piano esecutivo. Se la confi-gurazione cambia, Terraform applica le modifiche necessarie. Questo strumento è in grado di gestire istanze VM, storage, network e applicazioni, oltre a creare un grafico di tutte le risorse di elabora-zione, mettendo in parallelo la creazione e la modifica di eventuali risorse indipendenti. Terraform può fornire l’erogazione automa-tizzata di stack di applicazioni archiviate in IBM Cloud, AWS di Amazon, Microsoft Azure, Google Cloud Platform, VMware, Open-Stack e PowerVC.

Per le attività di configurazione, gestione e aggiornamento dei servizi necessarie in Terraform viene spesso utilizzato Chef. Inoltre, grazie all’uso di Terraform, è possibile approfittare dei servizi IBM Cloud tra cui l’ampia gamma di API Watson che include le opera-zioni di text-to-speech.



https://www.ibm.com/us-en/marketplace/cognitive-automation


Catalogo dei servizi interno a IBM CAMTramite il catalogo dei servizi, nel gestore di automazione è possi-bile vedere ciò che è essenziale all’interno di un ambiente multi-cloud. Lo scopo è quello di fornire all’IT un insieme di servizi cloud che agevolino il deployment dell’intero stack di applicazioni cloud. Nato come applicazione di microservizi, IBM CAM offre un’interfac-cia grafica capace di integrare i servizi del data center con i servizi applicativi, in modo che possano essere utilizzati secondo uno schema self-service.

Compositore di serviziIl compositore di servizi è uno strumento grafico che utilizza un spazio con un’interfaccia drag-and-drop tramite cui creare servizi applicativi che potranno così essere pubblicati nel catalogo dei servizi. Il compositore di servizi supporta anche i moduli di confi-gurazione di Terraform per VM, bilanciatori di carico e reti. Il suo scopo è quello di collegare insieme diverse attività, inclusi i modelli di automazione, nell’ordine in cui dovranno essere eseguite.

Controllo di un ambiente Multi-CloudL’IT deve avere la possibilità di monitorare il complesso di piatta-forme e servizi che costituiscono il cloud ibrido. Pertanto, è neces-sario poter controllare l’attività dei microservizi, oltre che dei servizi transazionali, di rete e dei dati. Tutti i sistemi forniscono il collega-mento della propria attività, inclusi i dettagli sulle prestazioni e sulle azioni in corso tra e con i servizi. Il software di gestione forni-sce l’analisi, talvolta anche in tempo reale, sul modo in cui i sistemi risultano in esecuzione, basandosi su quella relativa ai dati.

Ad esempio, IBM Cloud offre IBM Cloud Monitoring, che permette ai team di DevOps di ottenere informazioni utili circa la prestazione delle applicazioni e l’ utilizzo delle risorse. Inoltre, questo servizio consente ai team di individuare e risolvere potenziali problemi prima che producano effetti negativi. Le organizzazioni in genere si dotano di numerosi strumenti di controllo e gestione a supporto dei propri carichi di lavoro.




Supporto per diversi strumenti di controllo

IBM ha rilevato che la maggior parte delle imprese di livello enter-prise ha implementato numerosi e diversi strumenti di controllo nei propri data center e svariati ambienti cloud. Per questo motivo, invece di creare un diverso gruppo di strumenti di monitoraggio, IBM fornisce un set di API che i partner possono utilizzare per ampliare la propria offerta relativa al controllo all’interno della piattaforma IBM Cloud Management.

Preparare la strada verso l’azioneUn cloud privato fornisce la piattaforma di integrazione necessaria a sviluppare rapidamente nuove funzioni, insieme alle API che si integrano con le applicazioni e i dati esistenti. Grazie ad esso, le imprese possono sfruttare gli investimenti fatti nell’infrastruttura esistente.

IBM Cloud Private offre una soluzione locale e integrata, che funziona con IaaS, PaaS e con i servizi. Questa soluzione è costruita su tecnologie di servizi di dati e container con collegamenti alle API su cloud pubblici. Si tratta di una piattaforma singola che può essere eseguita sull’infrastruttura locale esistente e garantisce la sicurezza, la conformità, le prestazioni e l’efficienza economica necessarie a un’impresa di livello enterprise. IBM Cloud Private offre agli svilup-patori un’ampia scelta di linguaggi, framework, runtime e servizi per creare applicazioni e microservizi di tipo cloud-native.nment through standardization and automation. This Capitolo examines the issues and technologies needed to manage a multi-cloud envi-ronment. In addition, we provide insights into how IBM Cloud Private has addressed multi-cloud management.






http://dummies.com

WILEY END USER LICENSE AGREEMENTGo to www.wiley.com/go/eula to access Wiley’s ebook EULA.

http://www.wiley.com/go/eula

Date post:	17-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

IBM Cloud Private...For Dummies personalizzato per la propria organizzazione o azienda, contattare...

Documents