Questo articolo è una traduzione di un post di Frédéric Faure (system architect presso Ysance) sulle differenze tra l’utilizzo di una infrastruttura di cloud computing quale AWS e costruirne una propria di tipo fisico. La riportiamo in quanto riteniamo l’articolo molto corretto.

Ho notato molte domande circa le differenze inerenti alla scelta
tra una infrastruttura Cloud come AWS (Amazon Web Services) e una
tradizionale infrastruttura fisica. In primo luogo, ci sono un certo numero di
nozioni preconcette su questo argomento che cercherò di decodificare per voi.
Poi, si deve comprendere che ogni infrastruttura ha i suoi vantaggi e
svantaggi: una infrastruttura Cloud-tipo non deve necessariamente soddisfare i vostri
requisiti in ogni caso, comunque, deve essere in grado di soddisfarne alcuni di essi
ottimizzando o facilitando le funzionalità offerte da una tradizionale infrastruttura fisica.
Dimostrerò quindi le differenze che ho notato tra i due metodi, in modo da aiutarvi a farvi la vostra propria idea.

Il Framework

Cloud

Ci sono diversi tipi di possibilità di utilizzo del Cloud e continuerò trattando AWS che sono
servizi di infrastruttura-oriented, piuttosto che i servizi di Google-type (GAE – Google App Engine),
per citarne uno, che offre un ambiente di esecuzione per le vostre applicazioni web sviluppate con
le API fornite (simile ad un framework). In realtà, per quanto riguarda questi ultimi, non si può parlare per i clienti (coloro che detingono la carta di credito) circa la gestione delle infrastrutture, perché noi carichiamo la nostra applicazione utilizzando le API fornite e lasciamo l’intera gestione dell’ infrastruttura al fornitore di servizi. Ciò non significa che è un servizio minore di cloud computing, ma semplicemente un altro tipo di servizio di Cloud, più orientato al PaaS delle infrastrutture-oriented.

Physical Infrastructure

Per quanto concerne le infrastrutture fisiche, esaminerò il concetto di self-hosted infrastrutture e allo stesso tempo la nozione di infrastruttura manutenuta da un hosting provider. Analogamente, guarderò le infrastrutture basate direttamente su hardware, così come quelle basate sugli ambienti virtualizzati. Il cloud computing si basa anche sulla virtualizzazione, ma non siamo così interessati a tale tecnologia qui, piuttosto il modo in cui essa viene prestata ai clienti (voi). In effetti, si possono semplicemente avviare istanze tramite una console, come si fa per EC2, se avete un ESX (VMware), per esempio, ma si tratta “solo” di un hypervisor che partiziona il server fisico in più computer virtuali. Ci si dovrà ancora occupare dell’ acquisto di attrezzature (blade, ecc), la configurazione della rete, ecc. Ma torneremo su questi dettagli più tardi.

Cloud computing = Systems administrators marked down?

Sì, le vendite sono su! Siete alla ricerca di un maglione, una giacca, … un amministratore di sistemi? Capita spesso di incontrare persone che pensano che il Cloud (nel caso di AWS) consentirà loro di abilitarli senza un amministratore esperto di sistemi, e di costruire un’infrastruttura con inferiore competenza. La risposta è ovvia: SBAGLIATO!

Forse un intelligente lancio di vendita può convincere che i vari servizi sono così user-friendly, che si può fare tutto da soli, e che le AMI preconfezionate (Amazon Machine Image) renderanno la vita facile, ma va da sé che una volta avviato le istanze EC2, ci si collega a computer (SSH / porta 22 per Linux e TSE / porta 3.389 per Windows), allora dovrete impostare dei parametri, fare la messa a punto, ecc.

Ciò che vale per gli amministratori di sistema di fronte ad AWS vale anche per gli architetti di sistemi in ambito dei servizi di cloud computing che danno accesso agli strati più alti (PaaS come Google App Engine). Una persona con esperienza nel settore, in grado di configurare i requisiti infrastrutturali è necessaria: lo strumento può cambiare ma le competenze devono essere ancora disponibili. Si noti tuttavia che se si utilizza
GAE, non hai bisogno di un amministratore di sistemi per l’applicazione. Se l’editor di servizio Cloud offre un servizio in un dato livello (Haas, IAAS, PaaS, ecc), non c’è più bisogno di personale per gestire gli strati inferiori. Tuttavia, accettiamo il Framework fornito dal Cloud provider.

Gli amministratori di sistema non possono essere eliminati, ma il loro ruolo sta cambiando: sta diventando più di uno sviluppatore. In effetti, essere in grado di tirare le risorse al volo consentirà una gestione dell’infrastruttura programmabile ed automatizzabile tramite script, che richiameranno le API fornite da Amazon che consente la comunicazione con i suoi servizi web. Tutto su Amazon è webServices: EC2, EBS, SQS, S3, SimpleDB: l’unica operazione non-SOAP o REST che esiste è quando ci si connette direttamente alle istanze EC2 che abbiamo richiamato tramite il WebService o quando le istanze EC2 dialogano con l’EBS che abbiamo richiamato tramite … ti lascio indovinare.

L’amministratore può quindi, piuttosto che andare in sala server, aggiungere un disco, collegare un server (nel caso di una architettura fisica) oppure prendere il telefono e chiedere all’host provider di farlo (prendere un caffè … chiamare di nuovo … prendere uno Xanax o una pillola Prozac …), richiedere le risorse attraverso uno script in Ruby o Python … Quindi è possibile automatizzare l’infrastruttura di Cloud e molto, molto di più, inoltre, con una serie di script e strumenti.

Il mestiere dell’ amministratore di sistemi è quindi in evoluzione tra una infrastruttura fisica e una infrastruttura di Cloud tipo AWS : sarà sempre più di uno sviluppatore. Ma gli amministratori di sistemi tuttavia restano essenziali.

Elastic è fantastico!

Come ho detto prima, una delle differenze essenziali tra i due tipi di infrastrutture è la flessibilità e il dinamismo forniti dalla soluzione di Cloud, rispetto ad una tradizionale architettura fisica (sia che si basi sulla virtualizzazione o no). Ciò significa l’eliminazione del tempo
necessario per installare e configurare la logistica (acquisto attrezzature, l’installazione del sistema operativo, il collegamento alla rete – la rete fisica e la configurazione delle interfacce, ecc.) Analogamente, quando
non è più necessario un elemento di hardware (un’istanza virtuale EC2, un volume EBS, un oggetto S3, ecc), si può restituirlo al pool di risorse: sarà reinizializzato in modo che nessuno dei tuoi dati possa essere recuperato, e
messo a disposizione di nuovo fino alla chiamata successiva al servizio web.

Hai anche accesso completo a taluni elementi quali i gruppi di sicurezza (firewall) impostati per ogni istanza … E questo è molto utile. E molto pratico, in particolare rispetto ad un tradizionale hosting provider: ti ricordi l’ultima volta che hai dovuto cambiare le regole del firewall?

Ma non è solo sui pro ed i contro dell’acquisto del server rispetto alle istanze in esecuzione. I servizi AWS sono supportati da centri dati già industrialmente organizzati e collaudati. Tutta le norme di sicurezza
che devono essere soddisfatte in termini di protezione antincendio, raffreddamento dei sistemì, ridondanza elettrica dell’ alimentazione, la sicurezza fisica contro le effrazioni, la distribuzione dell’hardware su 2 o più
datacenter fisici per il disaster recovery, ecc comportano un investimento iniziale e colossale, anche quando tutto è installato, ancora non sarà in grado di ricreare la stessa qualità all’interno della vostra azienda
(99% del tempo, in ogni caso). È possibile ottenere tutto questo però, o parte di esso, con un tradizionale hosting provider.

Ma ci sono anche tutti i servizi software-like, come ad esempio la durata di gestione dei dati (Ridondanza / replica , su EBS e su S3), l’accessibilità o elevata disponibilità, il monitoraggio hardware (per ricevere un avviso quando i componenti fisici mostrano segni di indebolimento), le procedure
per i guasti, ecc.  Vi lascio leggere i 9 Principi di S3
(versione francese), cosi da capire quanto concetti sono inclusi. Non otterrete tutto ciò con un hosting provider tradizionale (e dimenticare di averla @Home). La qualità del servizio S3 è effettivamente un enorme vantaggio, soprattutto rispetto ai prezzi attuali … Parliamo di prezzi!

I costi

Non ci sono regole fisse. Con il Cloud, si paga per la risorsa di ora in ora e quando non la utilizzi più, si smette di pagare. Le istanze possono anche essere riservate per un anno o per tre anni: reserved instances: si paga una tassa all’inizio, e poi si paga la tariffa di utilizzazione ad un tasso agevolato, che vi conduce a un punto di non ritorno a partire da una certa
percentuale di utilizzo delle risorse nel corso dell’anno (o tre anni).
Per calcolare facilmente quanto la vostra infrastruttura vi costerà, usate il nuovo Calcolatore
fornito da Amazon. In tutti i casi una parte è correlata
all’utilizzo orario e un altra al traffico / volume memorizzato.

Si può fare il confronto tra il costo della vostra infrastruttura locale o con quello del vostro hosting
provider. Il prezzo fissato del Cloud è particolarmente interessante nei seguenti casi:

  • Il prezzo fissato è imbattibile per ProofOfCconcepts, manifestazioni/presentazioni o architetture di test di carico/validazione.
  • E ‘molto attraente per le applicazioni o le API montate su un modello economico di tipo SaaS e per il quale è necessario spendere soldi in risorse solo quando il cliente paga per utilizzare le API di cui sopra.
  • E ‘un buon prezzo per le social applications su Facebook, per esempio, che possono decollare durante la notte per fenomeni sociali dei media e si possono verificare dei boom (o dei drop) nelle hits.
  • E ‘anche conveniente quando si lancia una nuova società, o uno specifico progetto all’interno di una maggiore entità e non si vuole investire pesantemente nella logistica fin dall’inizio.

Per tutti i molti altri casi specifici, dovrete fare i vostri propri calcoli.

Rallentamento? O, naturalmente, non………

Di solito, non importa quale tipo di infrastruttura si possiede, gli stessi componenti e meccanismi dovrebbero essere installati. Tuttavia, bisogna riconoscere che spesso gli aspetti accoglienti di una infrastruttura “home”-hosted possono portare ad una mancanza di rigore su molte questioni. Il fatto che Amazon, con la sua AWS, offre una soluzione dinamica e volatile per questi EC2, costringe a installare meccanismi (che dovrebbero essere standard) al fine di considerare un guasto o un piano di disaster recovery più gravi, data la natura volatile dello strumento, e per identificare i dati importanti con l’obiettivo di garantire la durabilità dei dati (EBS, backup S3, ecc.)

Network e risorse condivise

La rete è un elemento importante … e in più di un modo! In effetti, la configurazione della Cloud è già preparata per voi, e questo è conveniente. Ma questo significa anche che non si
controlla, e di conseguenza non è possibile controllare e quindi diagnosticare, per esempio,
le cause di un rallentamento. Vi è una simile mancanza di trasparenza relativamente alle risorse condivise in una Cloud: al nostro livello non è possibile stimare l’impatto di altre persone che utilizzano la risorsa che si condivide (come il computer fisico su cui si basa la nostra istanza EC2, il dispositivo fisico che usiamo come periferica collegata alla rete EBS, la rete di banda, ecc.). L’unico monitoraggio possibile è limitato alle funzioni entrata/uscita sulla istanza (ad esempio, un EBS è una periferica collegata alla rete, quindi … non vi è alcuna possibilità di verifica delle condizioni di connettività, solo con l’ I/O dei dischi). Il monitoraggio che si può fare è concentrato sulla macchina virtuale EC2 (l’istanza è gestita da un hypervisor basato su una virtualizzazione di tipo Xen). Una totale visibilità della nostra infrastruttura non è quindi possibile su una Cloud. Questo deve essere preso in considerazione …e accettato, se si desidera implementare la propria architettura sulla Cloud. È inoltre necessario valutare la stessa mancanza di trasparenza per le altre risorse condivise come accennato in precedenza (uso di EBS, ecc.)

Allo stesso modo, un multicast non è possibile quando si tratta di protocolli di comunicazione: da ricordare per taluni cluster. Questo vincolo è comprensibile, dato l’impatto di vasta portata che una cattiva gestione multicast può avere.

Ciò è dovuto al modo di operare del Cloud: ha modi semplici, che mascherano un certo numero di elementi che non controlleremo più.

Sulla chiamata di supporto, monitoraggio, BCP (Business Continuity Planning) e le sanzioni

Una domanda mi è stata posta spesso “Se Amazon fornisce un servizio di call-support (per quanto riguarda le vostre applicazione/infrastrutture in esecuzione sul AWS)? “La risposta è no. AWS deve essere visto come un insieme di strumenti offerti da Amazon che garantisce che questi strumenti sono sempre su che lavorano bene. Essi sostengono questi strumenti e lo sviluppo delle loro diverse funzioni. Tuttavia, tu sei responsabile per l’utilizzo degli strumenti (in ogni caso essi non possiedono le chiavi private delle istanze EC2 …), quindi non c’è alcun pacchetto di monitoraggio/supporto su chiamata/BCP (Business Continuity Pianificazione).

A differenza dei contratti specifici che si possono firmare con l’ hosting provider, è necessario fornire a questi informazione di se stessi, o per quanto riguarda il servizio oncall-support per esempio, è possibile darlo in out-source a società di gestione. Idem per il monitoraggio: Amazon offre il CloudWatch Amazon, ma le informazioni (% di CPU, lettura / byte scritti su disco e in/out byte della rete) è troppo conciso per un controllo vero e proprio come previsto da Centreon / Nagios, Cacti, zabbix o Munin. Il CloudWatch
viene usato dall’ Auto Scaling, ma non sostituisce un monitoraggio vero.  Alcuni
tradizionali fornitori di hosting offrono pacchetti di monitoraggio come loro servizi.

Per quanto riguarda il BCP e le sanzioni relative, l’importo è per essere ospitati internamente: sei tu responsabile delle risorse e di come gestisci i failure  / disaster recovery, in linea con le capacità degli strumenti (l’AWS). Questo è dove è importante capire la natura globale dell’architettura dei servizi di Amazon: se non capisco come lo strumento funziona, non sarà possibile attuare un efficace BCP. Per quanto riguarda le sanzioni, non c’è niente di insolito: significano semplicemente un piccolo bill per il mese in cui tu sei sotto il ‘Servizio non disponibile’ categoria definita dai criteri di Amazon. Questo non ha nulla a che fare con le sanzioni sulla base delle somme perse a causa della indisponibilità.

E ‘assolutamente necessario prendere in considerazione i servizi web Amazon come uno strumento. Nonostante sia disponibile un supporto AWS  supporto (che è possibile chiamare per domande e problemi a livello di strumenti) che è possibile pagare, non sarà mai possibile ottenere il pieno potenziale contrattuale che si avrebbe con un provider di hosting più tradizionale, e più in generale, tu sei responsabile per la tua architettura a tutti i livelli (compresa la sicurezza di istanze: della perdita delle chiavi!).

Sicurezza

Sicurezza … spesso un argomento tabù, non appena si comincia a parlare di Cloud Computing. Io non intendo l’integrità dei dati memorizzati o anche la gestione degli accessi su istanze virtuali di cui siamo responsabili, sto parlando della riservatezza dei dati memorizzati su diversi servizi (S3,EBS, EC2, SQS, ecc) o di dati in transito tra tali servizi.

Il primo punto chiave è che il livello di sicurezza di cui sono dotati i datacenter di Amazon, non solo fisicamente ma – altrettanto importante – in termini programmatici, sarà sempre molta strada avanti rispetto il vostro medio
CED aziendale, anche del datacenter del più piccolo dei fornitori di hosting. In primo luogo perché è il business di Amazon: un problema di sicurezza rivelato nella loro infrastruttura avrebbe conseguenze immediate in termini di reazioni degli utenti (e quindi in termini di business). Si tratta pertanto di un dettaglio essenziale, soprattutto in quanto Amazon deve dimostrare se stessa in questo delicato settore e sono quindi obbligati a fare del loro meglio per vincere sui propri clienti. Inoltre, il numero stesso dei suoi struttura permette loro di mettere in comune i loro investimenti in sicurezza e di farli pagare per se stessi: questo
non è concepibile per le più piccole, o le aziende che non sono specializzati in essa. Amazon ha quindi i mezzi e l’obbligo di garantire la sicurezza.

Che cosa provoca il mio scetticismo è che il Cloud non è facilmente controllabile. Bisogna avere fede. Non è più rischioso che porre la vostra fiducia in un fornitore di hosting tradizionale, o nel vostro team interno …
Ma è nuovo di zecca! Quindi, attenzione! Una reazione normale. Ma forse questo è esattamente l’occasione per noi di lavorare sulla sicurezza al nostro livello, qualcosa spesso trascurata, a causa di eccesso di fiducia o per mancanza di interesse. Il primo compito è quello di criptare le informazioni: i dati memorizzati così come i dati in transito. Ricordatevi di prendere in considerazione il carico di CPU di crittografia/decrittografia. Il secondo
è quello di comprendere appieno i meccanismi di sicurezza dei vari servizi di Amazon:

AWS Multi-Factor Authentication

  • Access Credentials: Access Keys, X.509 Certificates & Key Pairs
  • Sign-In Credentials: E-mail Address, Password & AWS Multi-Factor Authentication Device
  • Account Identifiers: AWS Account ID & Canonical User ID

Poi si dovrà selezionare il personale che sarà autorizzato ad accedere alle diverse chiavi di sicurezza.

Conclusioni

L’evoluzione delle funzioni nella gestione dell’infrastruttura può essere vista chiaramente in questa prima parte: dalla gestione delle risorse fisiche per mezzo di API, meccanismi che garantiscono la durabilità dei dati,
disponibilità di servizi, ecc fino alla fornitura di alimentazione del server e della sicurezza fisica del datacenter, che sono tutti supportati in modo trasparente.

Risultato finale: dobbiamo “solo” usare le API che dialogano con un server remoto. Questa è la differenza con le infrastrutture fisiche. La virtualizzazione (che è un aspetto di AWS) che conosciamo ed è già utilizzata da tempo, è utilizzata da Amazon: non è tanto una rivoluzione tecnica – anche se non nego la complessità della realizzazione ed il sostegno che c’è in essa – come il servizio offerto con esso, che fornisce il reale valore aggiunto. E’ abbinato ad un nuovo modello economico ‘ pay-as-you-use ‘ aas (as a service). Ciò ha consentito l’emergere di alcune applicazioni (come i giochi che si trovano sui social network), che solo pochi anni fa sarebbero stati altrimenti compromessi dall’ investimento iniziale.

I servizi forniti dal Cloud Computing inevitabilmente portano con sè una certo riduzione del grado di controllo e della visibilità su alcune parti delle infrastrutture, in particolare sulla rete. Questo è il prezzo che si deve
pagare, sia esso del tutto trascurabile, o veramente problematico: tutto dipende dalle vostre esigenze.


AWS dovrebbe essere vista come uno strumento completo, ma che non ci libera dal dover compiere tutti le migliori pratiche o ottenere tutte le componenti standard di una infrastruttura: server di log, monitoraggio, BCP, configuration manager, ecc. Tutti questi elementi sono e continueranno ad essere una vostra responsabilità. Non bisogna avere troppa ingenua aspettativa: come AWS offre Haas e IAAS, si ha ancora bisogno di un amministratore di sistemi competente, ed uno in particolare che comprenda pienamente l’architettura di AWS (altrimenti si potrebbe rimanere delusi) – se si passa GAE (Google App Engine), avrete comunque bisogno di un architetto che comprende pienamente l’architettura di GAE, ecc. Il business è
in costante evoluzione.


Per quanto riguarda la sicurezza AWS, sono ragionevolmente fiducioso. Va sottolineato innanzitutto che l’informazione e i dati sono probabilmente meno sicuri all’interno della vostra azienda che affidati ad Amazon (comunque nella maggior parte dei casi – non generalizzo). L’esposizione di AWS nella Rete e l’impegno di Amazon al business implica che Amazon tiene alla sicurezza molto seriamente. Inoltre, siete responsabili di un gran parte di questa sicurezza (gestione delle chiavi, ecc) e credetemi, che è sicuramente la caratteristica più rischiosa. Quando si tratta di trasferimento e la memorizzazione dei dati, pensate alla “cifratura”.

Share This