Le tante bugie sulla riduzione della complessità parte 2: Cloud

Il mondo sta diventando molto più complesso, la maggior parte delle persone sarà d'accordo. Un elemento importante in questa crescente complessità è stata la quantità enorme di logica della macchina che noi specie umane abbiamo aggiunto al mondo. Sia quella stessa logica che ciò che consente(si pensi alla globalizzazione del commercio e della comunicazione) ha reso la maggior parte delle nostre vite più complesse e complicate in un modo o nell'altro. E sebbene ci abbia portato molto, ha anche un numero considerevole di effetti collaterali indesiderati.

Ci imbattiamo nei limiti della nostra capacità di gestire questa complessità giornalmente. Che si tratti dei grandi progetti IT che invariabilmente vengono eseguiti in ritardo, costano troppo, forse addirittura falliscono. O come dobbiamo cercare di rimanere al sicuro in un mondo digitale pieno di fragilità della logica e le debolezze degli esseri umani.

[Nota 1: questo articolo vuole essere comprensibile (con un po 'di sforzo) da non specialisti. C'è un po 'di gergo in esso, ma faccio del mio meglio per spiegare tutto, inclusa una tabella sottostante con un'ampia spiegazione di una serie di termini chiave. Se non spiego un termine, è sicuro ignorarlo se non sai cosa sia (ad esempio, quando cito un 'server tomcat'), è utile per coloro che lo sanno, ma non proprio necessario sapere cosa vuol dire seguire la storia]

Quindi, non è una sorpresa che nell'IT, una spinta costante negli ultimi decenni sia stata la spinta a ridurre la complessità. "Ridurre la complessità" vende. Soprattutto i manager dell'IT sono sensibili ad essa poiché la complessità è generalmente il loro più grande problema. Quindi, nell'IT, le persone sono in una lotta perenne per rendere sopportabile la complessità. Un metodo che è stato popolare per decenni è stata la standardizzazione e la razionalizzazione degli strumenti digitali che utilizziamo, un metodo di base "riduciamo al minimo il numero di applicazioni che utilizziamo". Questa era in realtà la prima parte di questa storia: una storia di razionalizzazione delle applicazioni (non). Quella storia del 2015 spiega quanti sforzi di razionalizzazione fossero in parte bugie. (E già che ci siamo: goditi questo fumetto di Dilbert a cui si fa riferimento.) La maggior parte delle volte più applicazioni sono state sostituite da una singola piattaforma (in breve: una piattaforma è un software che può eseguire altri software) e le applicazioni dovevano essere "riscritte" per funzionare "all'interno" di quella piattaforma. Quindi ti sei ritrovato con una piattaforma in più, lo stesso numero di applicazioni e in generale alcuni nuovi modi extra di "programmazione", specifici per quella piattaforma. Ciò non significa che siano tutte bugie. La nuova piattaforma è generalmente dedicata a un certo tipo di applicazione, il che rende più semplice la programmazione di queste applicazioni. Ma la situazione non è così semplice come sostengono i fornitori della piattaforma. Come ci aveva già detto Frederick Brooks nel 1986: There Is No Silver Bullet.

Un altro obiettivo è stato quello di incapsulare (nascondere) la complessità e accedervi tramite interfacce più semplici. E un terzo è stato quello di automatizzare l'IT stesso, creando una "gestione IT" complessa. Tutti e tre hanno un ruolo quando iniziamo a esternalizzare l'IT a servizi cloud come Microsoft Azure o AWS.

[Nota 2: questo articolo me è sfuggito di mano. Totalmente. Da molto tempo non divago, come spesso faccio. Ma non è possibile nascondere la complessità latente senza parlarvene. E non capire quanto sia complesso il mondo IT reale porta a risultati negativi. Quando il software per supportare la campagna di vaccinazione contro il Covid-19 era in ritardo di alcune settimane Perché i test non erano ancora stati completati, ho letto da uno politico di spicco qualcosa come "Dai, un po 'di test, quanto può essere difficile ? ". Questa è una dimostrazione degna di nota di non capire quanto sia complesso l'IT. Ed è in parte per questo che scrivo questo. Perché finché i nostri leader non inizieranno a capirlo, creeranno sempre più disastri per ignoranza. Torna alla storia.]

I servizi cloud ci sono stati generalmente spiegati (venduti) con una grafica come questa:

Rappresentazione tipica di ciò che viene esternalizzato quando si passa al cloud
Per le persone non tecniche, ecco una spiegazione di base dei termini utilizzati nella figura sopra e nel testo.
On Premise: utilizzo del proprio hardware
Application: software che utilizzi, ad es. Microsoft Word.
Data: i dati nel programma, pronuncia il testo in Word.
Runtime: software necessario per l'esecuzione di altri software, ad es. funzionalità di base per programmi Java ("Java runtime"). (Java è un linguaggio di programmazione.)
Middleware: software più complesso richiesto per l'esecuzione di altri software, ma che può anche avere una propria funzione. Per esempio. un database.
Operative System: il livello più basso di software che si trova tra la macchina e tutti gli altri software. Come Windows o macOS a casa.
Virtualization: un modo per trasformare una "macchina" (computer) reale molto grande in molte macchine virtuali organizzando più sistemi operativi per condividere la grande macchina. La condivisione aumenta l'efficienza perché non tutti i sistemi operativi sono occupati contemporaneamente. Ha anche altri vantaggi.
Server: la grande macchina "reale". Come il tuo computer a casa ma molto più grande con più processori e molta memoria in modo che possa essere condiviso.
Storage: macchina separata ottimizzata per fornire spazio di archiviazione (dischi), può essere utilizzata da più server. A casa le persone a volte hanno anche questo sotto forma di NAS. Si tratta generalmente di "appliance", cioè hardware specializzato (in questo caso con molti dischi) con software specializzato per gestirle.
Network: macchina separata che consente il traffico dati tra i sistemi. Come il tuo modem, router e punto di accesso Wifi a casa. Ancora una volta, un'appliance con hardware specializzato (in questo caso interfacce di rete come antenne wifi e prese per cavi di rete) che dispone di software specializzato per gestirle.

Il suggerimento è questo: man mano che ci allontaniamo dal nostro IT "on-premise" (che include qualsiasi data center di co-hosting che utilizzi, in questo contesto significa semplicemente che possiedi il tuo hardware IT) a sempre di più nel cloud, esternalizziamo sempre di più, siamo responsabili di meno, la nostra vita si semplifica. Più cloud è più economico, più semplice e più flessibile. Che cosa c'è che non va?

Quello che non c'è da apprezzare è che questo suggerimento è in gran parte una bugia. E anche tra le peggiori bugie.

Prendiamo ad esempio il networking. Secondo il grafico, non appena passi al cloud, non è più tua responsabilità. Ma questa è una bugia, ad eccezione dell'opzione più a destra (SAAS - ne parleremo più avanti). Se imposti il ​​tuo IAAS o PAAS nel cloud pubblico, ad esempio Microsoft Azure, devi gestire un bel po 'di rete. Infatti, mentre Microsoft esegue l'hardware sottostante, gran parte di ciò che deve essere gestito sarà gestito da te. Decidi di segmentare, collegare in rete, VPN (reti private virtuali - un modo per proteggere il traffico tra le reti), instradare i firewall e così via, stai semplicemente utilizzando gli strumenti di Azure per configurarlo. È più facile, ma non è tutto finito.

È meglio spiegato usando un esempio. Supponi di aprire alcuni dei tuoi sistemi basati su cloud per l'accesso da Internet pubblico? Lo puoi fare. E supponi di non doverlo avere, perché questi sistemi contengono dati sensibili? E supponiamo che questi dati vengano rubati in una violazione pubblica? Di chi è la colpa? Microsoft per averti fornito una corda sufficiente per impiccarti, o tu? È chiaro che se si tratta di una grande notizia, il titolo non sarà "Microsoft era negligente con la sua sicurezza e gestione", ma "La società X era negligente con la sua sicurezza e gestione nel cloud".
Quindi, la realtà della situazione è quindi più simile a questa:

Una rappresentazione leggermente più realistica del self-sourcing rispetto all'outsourcing del cloud

L'hardware è davvero qualcosa che è completamente gestito da un provider di cloud. Ciò include cose come la connessione del server alle reti, l'alimentazione, ecc. E la sostituzione di unità disco, ventole, ecc. In una configurazione completamente auto-approvata, questo risulta effettivamente essere un affare limitato. La maggior parte del lavoro di questi tempi non è hardware, ma software. Le aziende che gestiscono i propri data center in loco non hanno molti operatori hardware del data center. Prendi gli ingegneri di rete. Possono posare alcuni cavi a uno switch, ma dopo di che si passa rapidamente alla console di gestione e gestisce l'interfaccia di gestione del throughput dell'appliance, in altre parole: il software funziona. Ingegneri di rete, ingegneri di archiviazione e ingegneri informatici allo stesso modo, il loro strumento principale non è un cacciavite, il loro strumento principale è una tastiera. Solo i server di base per le macchine virtuali hanno poco in termini di configurazione. Il networking e lo storage sono dispositivi, hardware specializzato con software specializzato. Il fornitore di servizi cloud ha un'interfaccia in cima a questi che ti dà quella "corda sufficiente per impiccarti", cioè gran parte di questo è effettivamente impostato e gestito da te. Microsoft non crea né gestisce le impostazioni del tuo firewall, ti offre solo un'interfaccia per creare un firewall virtuale in esecuzione sui loro dispositivi e gestirlo tu stesso. Quindi è una responsabilità condivisa, e soprattutto nel networking: svolgi la maggior parte del lavoro nello stesso modo in cui avresti dovuto fare quando gestivi i tuoi dispositivi. L'utilizzo di un firewall in Azure significa che Microsoft avvia un'appliance virtuale per te. E da quel momento in poi, il lavoro è tutto tuo.

L'unica forma di cloud in cui ti sbarazzi davvero di molte responsabilità è Software-as-a-Service, o SAAS. Questo perché SAAS in realtà semplifica le cose ... ... per il venditore. Come spiegato nell'articolo EAPJ Integrazione verticale contro standardizzazione (orizzontale), il grande vantaggio di SAAS è che il fornitore di un'applicazione non ha bisogno di supportare una miriade di paesaggi tecnici là fuori, nessuna miriade di diverse versioni di Linux, versioni di Java, così come le loro configurazioni (baseline di sicurezza, chiunque?), solo un singolo stack che gestiscono completamente da soli. Ciò comporta un'enorme standardizzazione per il venditore e il vantaggio di ciò può essere venduto (in parte) al cliente. La tua responsabilità è generalmente limitata a un po 'di armeggiare con le applicazioni (magari aggiungi plugin, fai un po' di configurazione) e ovviamente ai tuoi contenuti. (E anche l'outsourcing quasi totale di SAAS è una piccola bugia in quanto lascia fuori tutto ciò che devi fare per rendere i tuoi dati in quell'applicazione disponibili ad altre applicazioni, che spesso includono alcune cose negli strati inferiori, come puoi vedere, alcune la complessità è persino nascosta da me qui).

I servizi interessanti sono quindi IAAS e PAAS.
Come puoi vedere, con Infrastructure-as-a-Service, o IAAS, in realtà non c'è molto di cui sbarazzarsi. Ad eccezione dell'hardware e della virtualizzazione, devi occuparti di tutto il resto. Questo è il motivo per cui le cosiddette operazioni "alza e sposta" (sposta la tua infra così com'è nel cloud) sono per lo più fallite. C'è stato poco guadagno nel lavoro che dovevi fare - che è la maggior parte del tuo costo - e le risorse cloud che sono in uso costante sono molto più costose delle tue, cioè se hai un po 'di scalabilità. Quindi, l'eccessivo entusiasmo semplicistico delle politiche Cloud-First ha lasciato rapidamente il posto a enormi grattacapi. Soprattutto quelli finanziari.
Platform-as-a-Service, o PAAS, offre molti vantaggi. Una piattaforma è un software necessario per l'esecuzione di altri software. Le piattaforme cloud sono gestite completamente (OS) o in gran parte (altre, come i "server delle applicazioni" come Tomcat) e c'è molto meno che devi fare. Sono corretti e la gestione del ciclo di vita viene eseguita su di loro. Hanno configurazioni di base con alcuni modi per modificare i dettagli. Ancora un po 'di lavoro, ma molto meno di quando avresti installato la piattaforma stessa.

C'è anche un importante fattore fuorviante in IAAS che non è nel quadro. Se esegui IAAS nel cloud, ti ritroverai con non solo una macchina virtuale vuota, ma con una macchina virtuale (VM) con un sistema operativo (OS) in cima. Quando si configura la VM, è necessario indicare al provider di servizi cloud quale "immagine" (un file) utilizzare per inserire la macchina virtuale. Quell'immagine significa che installi un sistema operativo sopra di essa. Puoi fornire la tua immagine, ma il fornitore di servizi cloud ne fornisce anche alcune. Questo dà l'illusione che un sistema operativo in esecuzione faccia parte di IAAS, ma non lo è. Questo diventa chiaro quando guardi cose come le licenze (devi fornire le tue) e soprattutto la manutenzione / le operazioni. Sei completamente responsabile per il sistema operativo. Per la sua gestione del ciclo di vita, patch di sicurezza, registrazione, monitoraggio, gestione di identità e accessi e configurazione in generale. Fondamentalmente, l'immagine del sistema operativo che forniscono nasconde solo che lo stai fornendo tu stesso (copiando la loro). E fa anche dimenticare che l'installazione iniziale è solo una minima parte di ciò che significa utilizzare un sistema operativo.

Un quadro più realistico di ciò che sta accadendo potrebbe essere questo:

La versione più vera di IAAS-PAAS-SAAS
Questa immagine mostra più cose di cui sei responsabile quando usi l'IT (e chi non lo fa, in questi giorni?). Partendo dal basso verso l'alto:

Hardware	Il vero "ferro", le macchine reali (al contrario delle macchine virtuali di seguito). Questi possono essere dispositivi dedicati, ottimizzati per una determinata attività con hardware e software specializzati (rete, archiviazione), oppure possono essere computer più generici, versioni estremamente truccate del tuo PC a casa. Questi contengono i bit che costituiscono il cuore dell'IT: l'esecuzione della logica della macchina. Per esempio. CPU (processori) e RAM (memoria di lavoro).
Foundational Infra	L'hardware è separato da questi, la gestione effettiva di tutto il software è ciò che rappresentano le scatole. È bene menzionare qui che esistono tutti i tipi di soluzioni (iper) convergenti che offrono combinazioni di elaborazione, archiviazione e rete in un'unica appliance.
Directory	Generalmente trascurato. Ma in mondi infrastrutturali ampi e complessi è necessaria una configurazione che conservi le informazioni di base a cui tutti i componenti possono accedere con le informazioni reciproche. Esempio: per archiviare identità, gruppi di identità e credenziali e fornire a tali identità e gruppi i diritti di accesso (dopotutto, vogliamo che sia sicuro, giusto?) Abbiamo bisogno di un modo per archiviare e accedere a tali informazioni.
Networking	La funzione per impostare indirizzamento di rete, routing, switching, firewalling, in altre parole tutto ciò che serve per fare in modo che i sistemi possano effettivamente copiare i dati tra loro. Software specializzato che viene eseguito su hardware specializzato, ad es. con prese per cavi di rete o antenne per comunicazioni wireless.
Storage	La funzione che fornisce l'archiviazione "grezza". Per esempio. se il tuo sistema utilizza un'unità di rete condivisa, da qualche parte sotto di essa c'è un provider di archiviazione. Ma anche quella macchina virtuale utilizza questa memoria. Generalmente software che gira su hardware specializzato (ad es. Con molti dischi).
Compute (VM)	La funzione che fornisce macchine virtuali (VM) generiche. L'hardware generico menzionato sopra esegue "software di virtualizzazione" o "hypervisor" (un termine coniato da IBM già negli anni '60, perché il sistema operativo (sotto) è il "supervisore"). Una macchina (reale o virtuale) richiede un sistema operativo (come Windows o macOS) per fare qualcosa.
Platforms	Software che può eseguire altri software. In realtà uno stack teoricamente infinito e talvolta anche un web (vedi sotto).
Operating System (OS)	Il livello di piattaforma più basso. Viene distribuito su una macchina (virtuale o reale). Nel cloud, è per definizione distribuito su una macchina virtuale. Una VM con solo un sistema operativo e nient'altro è la versione più "sottile" di PAAS. Se utilizzi PAAS (o SAAS ovviamente), il sistema operativo è completamente gestito dal provider PAAS. Poiché si tratta di sistemi molto complessi, è difficile che funzionino bene e che si mantengano in buon ordine. Per esempio. per mantenere tali sistemi sicuri e funzionanti richiede una certa attenzione. Nessuna macchina può funzionare senza un sistema operativo, il software che "gestisce" la macchina.
Middleware	Una "piattaforma" generalmente complessa. Può essere una combinazione di archiviazione ed elaborazione dei dati come un database come Oracle, SQLServer, EnterpriseDB, CognosDB, MongoDB, ecc. Ecc. (Nota: per i database, in particolare, DBAAS è talvolta usato come termine: Database as a Service) o un Enterprise Service Bus (hub di comunicazione, come Tibco) o una piattaforma API (hub di comunicazione, come Mule). Il middleware spesso incorpora runtime (ad esempio, il middleware può incorporare runtime per eseguire PLSQL, Java e Javascript, tutti i linguaggi di programmazione, programmi). Il middleware può anche essere eseguito su un runtime stesso (ad esempio se il sistema stesso è scritto in Java), vedere di seguito.
Runtime	Una raccolta di funzioni logiche della macchina che un altro sistema può utilizzare (e quindi non ha bisogno di fornire se stesso). .Net, Java, Objective-C su macOS, sono linguaggi per computer per i quali l'esecuzione richiede un runtime. I runtime in questa definizione non hanno esistenza indipendente (vengono eseguiti solo quando viene eseguita l'applicazione) mentre il middleware generalmente viene eseguito anche senza alcun altro sistema distribuito su di esso.
Operations	Aspetto per lo più ignorato da tutti, tranne quelli che lo forniscono e tutti gli altri quando scoprono improvvisamente di averne bisogno. Perché tutto ciò richiede una sorta di operazione. Ad esempio notare e risolvere problemi. Perché cosa non li ha? Quindi, c'è registrazione, monitoraggio, gestione degli eventi, gestione degli incidenti, ecc. Esempio: supponiamo che il servizio PAAS abbia un problema e non venga eseguito. Qualcuno dovrebbe scoprirlo e fare qualcosa al riguardo e non dopo che il negozio online è rimasto inattivo per 10 ore. Inoltre: gestione dei disastri (backup, ripristino) o "continuità". Richiede interi stack (applicazioni, piattaforme).
Applications	La funzionalità a cui pensa solo la maggior parte delle persone. Acquistata o costruita, è la logica della macchina che utilizza tutto ciò che segue per fornire quella funzione.
Development & Deployment	Le applicazioni devono essere distribuite su una piattaforma prima di poter essere utilizzate. Se costruisci il tuo, vengono sviluppati e distribuiti. Parte di questo è ad esempio il test e la promozione dal test alla produzione. Lo sviluppo può includere tutti i tipi di controllo del codice sorgente e ambienti di sviluppo. Richiede interi stack (applicazioni, piattaforme).
Identity & Access	È essenziale che logica e dati siano 'al sicuro', cioè che riservatezza (accesso solo da parte di coloro che dovrebbero averli), integrità (i dati vengono modificati solo se devono cambiare) e disponibilità (non si desidera che essere non disponibile perché alcuni server si sono bloccati). La gestione delle identità e degli accessi è un aspetto importante della riservatezza e dell'integrità. Fa spesso uso della directory (sopra) per l'archiviazione.
Content	Sempre e unicamente tuo. Anche in SAAS, ciò che hai inserito come informazione nel sistema e ne sei uscito, è il motivo per cui lo usi in primo luogo. Questo è un aspetto in cui SAAS è spesso leggermente più complicato perché l'integrazione di sistemi SAAS con tutti gli altri sistemi può comportare configurazioni complesse di per sé.

Un elenco più completo degli elementi chiave dei paesaggi IT

Una versione abbreviata di cui sarebbe:

Abbreviazione della versione più vera di IAAS-PAAS-SAAS

Credere che il passaggio al cloud ti liberi da molto lavoro è vero solo per SAAS. In tutti gli altri casi, tale convinzione è una forma di miopia del data center e si basa anche sull'ignorare una terribile quantità di IT che ha a che fare con il funzionamento di quel singolo bit - l'applicazione. In un certo senso, dobbiamo ringraziare i matematici che hanno avviato l'IT (e introdotto il concetto fuorviante di "non funzionali").

A parte: strati antichi e un importante malinteso

Ciò che mi infastidisce davvero, a proposito, sono questi tre livelli (una spiegazione più dettagliata di questi di seguito):

L'antica rappresentazione delle "piattaforme", con noi dagli anni '90.

Questo viene da un tempo in cui la vita era molto più semplice e anche allora non era vero. Fornisce un modo semplice ma falso di comprensione. In realtà, esistono anche i seguenti modelli:

Esempi di modelli reali che esistono quando parliamo di applicazioni in esecuzione

In effetti, in teoria abbiamo un numero illimitato di piattaforme in esecuzione all'interno di altre piattaforme. In pratica, le penalizzazioni delle prestazioni tendono a limitare il livello di profondità. E non solo, alcuni sistemi sono in realtà miscele di applicazioni e piattaforme, una situazione che chiamo stack di applicazioni complesse. Esempi sono SAS, Tibco o molti altri. Sono costituiti da una combinazione di piattaforme in cui distribuire il proprio "codice" e applicazioni per gestirli e utilizzarli. Ho già detto che la realtà è molto più complicata di quanto suggeriscano le immagini semplicistiche? Quindi, la realtà è più simile a questa:

La realtà delle piattaforme, ogni piattaforma può ospitare più piattaforme. In effetti, finché puoi "distribuire" qualcosa su di esso, puoi considerarlo una piattaforma.
Quindi: bugie, grandi bugie
Quindi, quella prima grafica, popolare in molte sale riunioni, è fuorviante. Mente. Ignorando la realtà, rimani responsabile di gran parte di ciò che la grafica dice di non fare. Si trova tralasciando tutte le cose che si spostano sulla nuvola che difficilmente tocca. E come tale inquadra le cose in modo irrealistico. E l'inquadratura funziona. Prendi questi due grafici, non correlati a questa storia:

Entrambi visualizzano esattamente la stessa cosa. Ma a sinistra, tralasciando molto sulla scala y, la crescita sembra molto più drammatica che a destra. L'immagine originale IAAS-PAAS-SAAS fa l'opposto: tralasciando tutte le cose che rimangono le stesse, suggerisce una semplificazione che non c'è davvero.

Tutto questo è una forma di ciò che molte bugie nell'IT hanno in comune: la semplificazione dei suggerimenti è facile. La realtà è che la complessità cresce costantemente nella rivoluzione dell'informazione. Mentre c'è un sacco di incapsulamento in corso, e le persone agiscono come se l'incapsulamento significasse che non c'è più. Oppure tendiamo ad agire in modo che se non possiamo vederlo, non è lì. E poi ci stupiamo quando le cose non funzionano perfettamente (o non funzionano affatto).
Addendum: Cloud: privato, pubblico, ibrido, privato virtuale …

Cloud pubblico. Cloud privato. Cloud ibrido. Cloud privato virtuale. Cloud inverso. Ehm, cosa? Ecco alcune definizioni utili:

Cloud	Ambiguo. In origine un termine per Internet pubblico in contrapposizione alle comunicazioni fisse di proprietà dell'organizzazione (Wide Area Network o WAN). Viene ora utilizzato sia per i "fornitori di cloud" che per il "modello di cloud". In quanto "fornitori di servizi cloud", sta per qualsiasi organizzazione che offre servizi IT tramite Internet. Il "modello cloud" sta per accesso "self-service" al provisioning completamente automatizzato di componenti e servizi IT (PAAS e IAAS). A causa del self-service, la capacità hardware sottostante deve superare i picchi di domanda. Entro questi limiti, c'è elasticità (su richiesta).
Private Cloud	Il "modello cloud" sull'hardware che gestisci tu stesso. Poiché non avrai hardware illimitato, generalmente c'è un limite notevole all'elasticità. Se si incontra tale limite, è necessario eseguire il lento processo di aggiunta dell'hardware prima di poter superare i limiti esistenti. Il costo è fisso per la tua organizzazione (la capacità definisce il costo).
Public Cloud	Il "modello cloud" sull'hardware di proprietà di fornitori di cloud specializzati (ad es. Microsoft Azure, Amazon AWS). A causa delle loro dimensioni gigantesche, hanno un'elasticità effettivamente illimitata per ogni cliente. L'hardware non è dedicato a te (il tuo Funziona sullo stesso hardware di quello di altre organizzazioni), ma il provider cloud garantisce una certa prestazione. Poiché vogliono realizzare un profitto, utilizzano modelli pay-as-you-go. Aumenta il tuo IAAS e SAAS, paga di più per unità di tempo. Ridimensiona, paga di meno. Se non sei in grado di ridimensionarlo (ad es. Se il tuo software non può essere eseguito in questo modo), Public Cloud è più costoso del possedere il tuo hardware, ad eccezione delle organizzazioni molto piccole.
Hybrid Cloud	A - sorpresa - mix di varie forme di cloud, per lo più privato e pubblico. Questa sarà la realtà per la maggior parte delle organizzazioni tranne quelle molto piccole.
Virtual Private Cloud	Servizi cloud in esecuzione su hardware di proprietà di un provider cloud ma dedicato per te. Amazon e Azure lo chiamano "host dedicati".

Addendum: IAAS + (o "Sistema operativo gestito", il livello PAAS più basso utile che i fornitori di servizi cloud non possono fornire)

Ripetendo quanto spiegato sopra, c'è una confusione derivante dai tecnicismi dell'utilizzo di IAAS nel cloud: le persone tendono a pensare che IAAS significhi che si ottiene un sistema operativo, ad es. una macchina Windows o Linux dal provider di servizi cloud. Ma non è così, sembra solo così.

Quello che ottieni con IAAS è una macchina virtuale, più o meno una condivisione del tempo sull'hardware di elaborazione sottostante (così come la rete sottostante, l'archiviazione, ecc. Che è necessario per funzionare - nota di nuovo: generalmente questi devono essere impostato (nel cloud ancora principalmente da te) prima di poter effettivamente creare una macchina virtuale). Una macchina del genere, proprio come a casa, è inutile senza un sistema operativo. A casa questo è generalmente Windows o macOS. Ma il sistema operativo non fa davvero parte del servizio IAAS che ottieni. Ciò che ottieni non è altro che un'installazione iniziale (con licenza) perché senza l'immagine del sistema operativo scritta sulla sua memoria non puoi usare la macchina. Dopodiché, sei da solo. Non è gestito, mantenuto, monitorato, patchato, ecc. Tutto ciò è sotto la tua responsabilità. Confrontalo con l'utilizzo di un server delle applicazioni (PAAS). Quel PAAS potrebbe essere semplicemente un server Tomcat. Ma le patch, gli aggiornamenti, ecc. Di quel server Tomcat vengono eseguiti dal provider PAAS (così come per qualsiasi cosa sotto di esso, come il sistema operativo). Fondamentalmente "as-a-service" significa che il fornitore di servizi mantiene il servizio in buon ordine. Quindi ciò che ottieni con IAAS è una condivisione del tempo sull'hardware di elaborazione sottostante, non un sistema operativo, anche se la condivisione del tempo è inizialmente seminata con un'immagine del sistema operativo (possibilmente la tua). IAAS potrebbe essere meglio chiamato VHAAS (Virtual Hardware as a Service).
C'è una buona ragione per cui i provider di servizi cloud non offrono un sistema operativo gestito. I sistemi operativi sono bestie complesse e ci sono così tante variabili che è impossibile automatizzarlo abbastanza bene da essere utile per tutti i diversi usi nel mondo. Ad esempio, un'azienda può avere requisiti di sicurezza diversi da un'altra. E fornire un'interfaccia attraverso la quale tutti questi clienti possono effettuare le proprie impostazioni in un modo che non interferisca con la tua responsabilità come fornitore di servizi è annullabile.

Ma avere un sistema operativo gestito è esattamente ciò che è utile per i team di applicazioni aziendali in molte organizzazioni. I reparti dell'infrastruttura forniscono sistemi operativi gestiti ai loro colleghi IT che possono quindi installare ed eseguire piattaforme e applicazioni su di essi, ad es quei sistemi che sono stati acquistati dai fornitori. Mentre questi colleghi possono installare e mantenere il software, il reparto IT si occupa di patch di sicurezza, linee di base di sicurezza, aggiornamenti, registrazione e monitoraggio, ecc. Tutte quelle persone "extra" tendono a dimenticarsi. E, nel classico mondo del non-self-service (il reparto IT fornisce un nuovo sistema operativo) questo è generalmente ciò che accade. Non è quello che ottieni con IAAS nel cloud.

Quindi, dove lavoro, abbiamo quello che chiamiamo un DevOps-Ready Data Center (DRDC) che è in realtà un provider PAAS locale. Fornisce tutti i tipi di piattaforme come self-service agli utenti finali, come il server Tomcat, il database o un server IIS, ma in modo gestito. Questi PAAS sono completamente mantenuti (patch, linee di base di sicurezza) tutti eseguiti come infrastruttura come codice (utilizzando a.o. Puppet, ServiceNow, Icinga2, ELK, GitLab). E non solo queste macchine sono gestite, sono completamente configurate, quindi ci sono monitoraggio, registrazione, strumenti di sviluppo (in locale: XLD / XLR), identità e accesso, continuità e, soprattutto, gestione delle modifiche (ITIL). Quindi uno dei livelli PAAS che possiamo effettivamente offrire è solo un sistema operativo gestito. Lo chiamiamo IAAS +, ma in realtà è il livello più basso di PAAS che puoi fare. In una foto:

IAAS + locale (in realtà il livello più basso di PAAS) rispetto a Classic-IAAS-PAAS

La soluzione ottimale per i team DevOps è ovviamente una forma più "grossa" di PAAS, ad esempio un server di applicazioni Tomcat su cui è possibile distribuire applicazioni Java o un runtime Mule su cui è possibile distribuire API. Più è automatizzato per loro, meglio è. Ma se un PAAS "grasso" non è un'opzione, IAAS + è un buon secondo. L'aspetto più dispendioso in termini di tempo per la manutenzione delle piattaforme è dopo tutto il sistema operativo. Fornendo un "sistema operativo gestito" invece di un "dispositivo hardware gestito" (come fanno i fornitori di cloud con IAAS) fornisci qualcosa che i fornitori di servizi cloud non possono. E, naturalmente, l'utilizzo di "IAAS in outsourcing" come infrastruttura di base in "Sistema operativo gestito" è un passo logico successivo. In altre parole: la capacità di fare "sistema operativo gestito" porta alla possibilità di fare "sistema operativo gestito" o "IAAS +" nel cloud, dopotutto. Nifty, vero? Ma difficile, però (pensa da solo a tutto il networking, l'archiviazione, l'identità e l'accesso e così via che devono essere automatizzati prima di poterlo fare). Il valore è tuttavia eccezionale: consente la combinazione di agilità e DevOps senza perdere il controllo o diventare estremamente inefficiente mantenendo il controllo. Tuttavia, se vogliamo agilità e controllo in questo mondo di quantità incredibili di logica della macchina connessa, non ci sono altre opzioni. Per combattere la complessità di tutta quella logica della macchina, c'è poco che possiamo fare se non aggiungere ancora più logica della macchina. E sì, c'è un limite lì da qualche parte ...

Grazie a Henk Dado e Michel Jongmans per il loro contributo attraverso le nostre discussioni e MarkThePotato