In che modo "il cloud computing" è diverso da "client-server"?

In senso stretto, non esiste un "Cloud". Non nel senso di ciò che stava facendo il CEO. C'è Internet, ovviamente. Ci sono servizi in hosting. C'è VPS. Esistono sistemi di distribuzione dei contenuti. Abbiamo (tecnici) hanno adattato al termine per fare riferimento a determinati modelli di servizi in hosting. Ma "Cloud" nei media consumer è in gran parte un termine di marketing liberamente tradotto come "internet". Il più delle volte, significa anche "ti addebito entro il mese".

Hai ragione nel ritenere che i due termini "cloud" e "client-server" non siano correlati. Avere un servizio ospitato "nel cloud" (voglio sempre aggiungere un drammatico "dun-dun-daaaaaaa" dopo aver usato quella frase) non rende l'app client-server meno client-server-y. Ad esempio, il "web" utilizza principalmente un modello client-server. Il browser web è il client. Il server web è il server. Il fatto che un server Web sia ospitato "nel cloud" non cambia il fatto che la relazione tra browser Web e server Web sia client-server.

Quindi il termine client-server definisce la relazione tra due entità in un sistema. Dove le entità sono fisicamente ospitate è irrilevante.

Fondamentalmente, sei corretto. I due non sono comparabili.

"Il cloud computing" è un termine generico pensato per fare due cose: in primo luogo, astrarre tutti i possibili usi di un modello client-server dietro un singolo termine, al contrario di casi d'uso più specifici come "file server", "database server "," server web "," server applicazioni "ecc .; e in secondo luogo, per astrarre l'architettura del server stesso, in termini di hardware, topologia, posizione e persino proprietà.

In un modello client-server tradizionale, che è ancora oggi di uso comune, un client si connette a un server che esegue un particolare lavoro. Questo server può ospitare un database o una serie di condivisioni di file o una pagina web. Quando il client si connette a quel server, vi è una comprensione implicita del tipo di comunicazione e trasmissione dei dati che deriverà tra i due computer. Potrebbe anche esserci una comprensione da parte del cliente o dell'utente finale delle capacità dell'hardware del server e dei suoi limiti. Questo "accoppiamento stretto" relativamente tra la macchina client e il suo server può porre problemi a un amministratore di sistema che deve rimuovere un server per la manutenzione; tutte le applicazioni dipendenti dalle risorse fornite da questo server devono essere puntate su un altro server, e non tutte le applicazioni e le infrastrutture sono progettate con questo tipo di ridondanza e tolleranza di failover in mente.

In un modello cloud, l'hardware, la topologia, la divisione del lavoro e persino il numero di macchine reali coinvolte sono tutte estratte dietro un singolo endpoint. L'analogia potrebbe essere attirata su una moderna "web application", in contrasto con le vecchie generazioni di "siti web" che erano più statici. Potremmo supporre che dietro le quinte ci siano un server applicativo e un server DB, ma non dobbiamo preoccuparcene; il web server, come parte del suo lavoro per servire l'intera applicazione agli utenti oltre il "bordo", fornisce un endpoint unificato che consente l'accesso controllato a tutti i dati e servizi forniti da altre macchine dietro questa porta principale.

Il risultato è che, con un unico endpoint esposto a fornire la funzionalità dell'applicazione, è tutto ciò di cui un utente consumatore dell'applicazione deve preoccuparsi, invece di dove ottenere i dati, dove chiamare tale e così processo di applicazione remota, ecc; ciò significa che gli amministratori e gli architetti del fornitore di servizi all'interno di questo cloud sono più o meno liberi di modificare le macchine, la topologia e altri specifici dettagli di implementazione di questo "servizio cloud" senza che i client siano più saggi. Se pensasse che fosse saggio, Facebook potrebbe ricostruire da zero l'intero sistema di archiviazione dati utilizzando un DBMS diverso e tutti i nuovi server, e finché il sito rimarrà disponibile durante la transizione, nessuno sarebbe mai più saggio; Infatti, Facebook ha fatto proprio questo, molte volte, espandendosi da un sito ospitato dalla macchina personale di Mark Zuckerberg in una stanza del dormitorio ad un hosting dedicato fuori dal campus, a server farm in diverse località in tutto il mondo.

Una parte fondamentale del "cloud computing" sono gli strumenti di gestione della distribuzione.

Nelle distribuzioni "classiche" si ordinava una macchina specifica per un'applicazione specifica e si eseguiva una configurazione abbastanza fissa.

In un ambiente cloud ci sono hardware più o meno standardizzati in un pool e un'API che crea e configura macchine virtuali su di esso da una qualche forma di template. I sistemi difettosi possono essere facilmente sostituiti, ridimensionati o ridimensionati in base alle esigenze e l'hardware può essere allocato secondo necessità, in modo automatizzato.

Ovviamente anche gli amministratori adeguati lo hanno fatto prima, ma oltre al puro marketing, vi è una base di API standardizzate (API AWS di Aamzons che viene anche offerta da strumenti come Eucalyptus per "private cloud") e strumenti (ad es. ) emergente.

Nell'architettura client-server "tradizionale" sono state assegnate staticamente delle risorse (o almeno sono presentate come tali - non ho esperienza del periodo pre-cloud, quindi correggimi se ho torto e dipendono da false marketing). Il server database è stato chiamato db.yourcompany.com e il server web ha comunicato con esso. Se si desidera aumentare le risorse, è possibile aggiungere un altro server Web dedicato e fornire il bilanciamento del carico ecc.

D'altro canto, lo stress da nubi è stato messo sull'astrazione di livelli inferiori e indica come viene costruito il "server". Ad esempio hai:

• HAAS (Hardware As A Service) - il cliente (azienda) ottiene un computer in hosting su cui possono installare qualsiasi sistema operativo desiderato. La differenza è che non "realmente" ottengono un computer ma una macchina virtuale in una fattoria. Poiché è virtualizzato, non è necessario preoccuparsi dei dettagli di livello inferiore come la quantità di potenza di calcolo, pagare le bollette indipendentemente dal fatto che la macchina sia utilizzata, come sia connessa ecc.
• PAAS (Platform As A Service) - un livello più alto - scrivi un'applicazione che in qualche modo corre da qualche parte. Dato che l'API è abbastanza generale, i fornitori di servizi cloud possono allocare risorse su richiesta, quindi se la tua applicazione subisce uno slash, pagherai per più risorse piuttosto che soffrire di DDOS non dannoso.
• SAAS (Software As A Service) - ancora un altro livello più alto - non scrivi un'applicazione - ne usi una. Non ti interessa come viene implementato o quali risorse utilizza. È disponibile ovunque e in qualsiasi momento.

Si noti che, mentre nella maggior parte dei casi è implicito che il servizio effettivo è esternalizzato a società di grandi dimensioni (ad esempio Amazon o Google) non è necessario il caso: grandi aziende o università distribuiscono i propri cloud interni per consentire una gestione più semplice delle risorse. Ciò consente di aggiungere le risorse all'applicazione per la loro esecuzione da aggiungere secondo necessità. Se il nuovo avvio interno ha avuto successo, non è necessario preoccuparsi che i server siano sovraccaricati. Tuttavia, dal momento che l'economia di scala gioca il ruolo, di solito è fatto solo quando ci sono requisiti speciali (ad esempio per quanto riguarda la sicurezza).

Dal punto di vista dell'utente, è trasparente e ha un aspetto di architettura client-server. Il server web potrebbe vivere "nel cloud" mentre si utilizza semplicemente il vecchio HTTP. I problemi e le soluzioni delle idee ricorrono infatti ai mainframe degli anni 50 e attualmente tornano più come contrasto ai PC client spessi .

Detto questo potrebbe anche essere una parola d'ordine in una data frase e affermare che la società è dinamica e si concentra sulle proprie competenze di base mentre consente ai propri dipendenti.

Can someone please explain what "cloud computing" means in contrast to client-server?

Dipende dalla tua prospettiva. Per le aziende, il cloud computing è buono perché (di solito) ti consente di essere più flessibile con il numero di macchine che supportano i tuoi servizi. Questa flessibilità ti consente di essere più reattivo, il che dovrebbe farti risparmiare denaro. Le aziende possono anche trarre vantaggio dal fatto che il fornitore di servizi cloud faccia backup, disaster recovery, sicurezza fisica e tutte le altre infrastrutture che non vogliono gestire. Ciò di solito porta a risparmi e qualità migliorata.

Dal punto di vista del consumatore, l'elevata qualità della connessione e l'affidabilità sono buone. Alcuni fornitori di servizi cloud aiutano anche a distribuire i propri server per aiutare la latenza del consumatore.

Per i programmatori ... è praticamente una programmazione client-server in cui il server è difficile da raggiungere e occasionalmente è necessario utilizzare alcune API specializzate.

Penso sia giusto dire che "cloud computing" e "client-server" sono molto simili. Dal mio punto di vista, il cloud computing sembra dipendere più dal server che dal modello "client-server". In teoria, alcune forme di cloud computing possono accadere indipendentemente da una connessione client. Il vantaggio di un'applicazione che funziona solo nel cloud senza alcuna comunicazione con il client non sembra molto utile, quindi ha senso creare una qualche forma di comunicazione client con quel server.

Essenzialmente penso che si basi principalmente su dove viene eseguita la maggior parte della tua potenza di calcolo. In genere un server ha specifiche migliori, in termini di hardware e potenza di calcolo, rispetto a un computer utente standard per gestire semplicemente molte connessioni client e operazioni simultanee per servire tali connessioni. Il cloud computing utilizza questo come un vantaggio spostando quello che normalmente sarebbe il codice di esecuzione del client sul server e consentendo al client di essere il più "stupido" possibile. Richiedendo così meno risorse utente, per gestire lo stesso tipo di operazioni.

Potrebbe non essere la migliore risposta, ma è così che la vedo io.