En quoi le «cloud computing» est-il différent du «client-serveur»?

Regardant un PDG d'une nouvelle entreprise de «cloud computing» décrire son entreprise dans un programme de télévision financière aujourd'hui, il a dit quelque chose comme «le cloud computing est supérieur à l'informatique client-serveur à l'ancienne».

Maintenant, je suis confus. Quelqu'un peut-il expliquer ce que signifie "cloud computing" par opposition à client-serveur?

Pour autant que je le comprenne, le cloud computing est davantage un modèle de services réseau, de sorte que je ne possède ni ne gère le matériel physique. Le "cloud" est tout le truc du back-end. Mais je pourrais toujours avoir une application qui communique avec cet environnement "cloud". Et si j'exécute un site Web qui présente un formulaire qu'un utilisateur remplit, appuie sur un bouton de la page et renvoie un rapport généré par le serveur Web, n'est-ce pas la même chose que l'informatique «cloud»? Et ne considéreriez-vous pas mon navigateur Web comme le "client"?

Veuillez noter que ma question est spécifique au concept de "cloud computing" par rapport à "client-serveur".

Désolé s'il s'agit d'une question inappropriée pour ce site; c'est la plus proche de l'univers Stack et c'est ma première fois ici. Je suis un vieux temporisateur, programmant depuis les jours mainframe à la fin des années 70.

À strictement parler, il n'y a pas de «Cloud». Pas dans le sens de ce que ce PDG jaillissait. Il y a bien sûr un Internet. Il y a des services hébergés. Il y a des VPS. Il existe des systèmes de diffusion de contenu. Nous (les techniciens) nous sommes adaptés au terme pour référencer certains modèles de services hébergés. Mais «Cloud» dans les médias grand public est en grande partie un terme marketing vaguement traduit par «Internet». Plus souvent qu'autrement, cela signifie également «je peux vous facturer au mois».

Vous avez raison de penser que les deux termes, «cloud» et «client-serveur» ne sont pas liés. Avoir un service hébergé «dans le cloud» (je veux toujours ajouter un «dun-dun-daaaaaaa» dramatique après avoir utilisé cette phrase) ne fait pas une application client-serveur moins client-serveur-y. Par exemple, le «Web» utilise principalement un modèle client-serveur. Le navigateur Web est le client. Le serveur Web est le serveur. Le fait qu'un serveur Web soit hébergé «dans le cloud» ne change pas le fait que la relation navigateur Web / serveur Web est client-serveur.

Le terme client-serveur définit donc la relation entre deux entités dans un système. L'endroit où les entités sont physiquement hébergées n'est pas pertinent.

En gros, vous avez raison. Les deux ne sont pas comparables.

"Cloud computing" est un terme générique destiné à faire deux choses: premièrement, résumer toutes les utilisations possibles d'un modèle client-serveur derrière un seul terme, par opposition à des cas d'utilisation plus spécifiques comme "serveurs de fichiers", "serveurs de bases de données", «serveurs Web», «serveurs d'applications», etc .; et deuxièmement, résumer l'architecture du serveur lui-même, en termes de matériel, de topologie, d'emplacement et même de propriétaire.

Dans un modèle client-serveur traditionnel, qui est certainement encore couramment utilisé aujourd'hui, un client se connecte à un serveur qui effectue un travail particulier. Ce serveur peut héberger une base de données, une série de partages de fichiers ou une page Web. Lorsque le client se connecte à ce serveur, il existe une compréhension implicite du type de communication et de transmission de données qui s'ensuivra entre les deux ordinateurs. Le client ou l'utilisateur final peut également comprendre les capacités du matériel du serveur et ses limites. Ce couplage relativement "étroit" entre la machine cliente et son serveur peut poser des problèmes à un administrateur système qui doit arrêter un serveur pour la maintenance; toutes les applications dépendant des ressources fournies par ce serveur doivent être dirigées vers un autre serveur,

Dans un modèle cloud, le matériel, la topologie, la division du travail et même le nombre de machines réelles impliquées sont tous abstraits derrière un seul point de terminaison. L'analogie pourrait être tirée d'une «application Web» moderne, par opposition aux anciennes générations de «site Web» qui étaient plus statiques. Nous pourrions deviner qu'il y a un serveur d'applications et un serveur DB en coulisses, mais nous n'avons vraiment pas à nous en soucier; le serveur Web, dans le cadre de son travail pour servir l'application complète aux utilisateurs au-delà du «bord», fournit un point de terminaison unifié permettant un accès contrôlé à toutes les données et services fournis par d'autres machines derrière cette porte d'entrée.

Le résultat est que, avec un seul point de terminaison exposé pour fournir les fonctionnalités de l'application, c'est tout ce qu'un client client de l'application doit se soucier, au lieu de savoir où obtenir ses données, où appeler tel ou tel processus d'application à distance , etc; cela signifie que les administrateurs et les architectes du fournisseur de services au sein de ce cloud sont plus ou moins libres de modifier les machines, la topologie et d'autres détails d'implémentation spécifiques de ce "service cloud" sans que les clients soient plus sages. Facebook pourrait, s'il le jugeait sage, reconstruire l'intégralité de son système de stockage de données à partir de zéro en utilisant un SGBD différent et tous les nouveaux serveurs, et tant que le site resterait disponible pendant la transition, personne ne serait plus sage; en fait, Facebook a fait exactement cela, plusieurs fois,

Un élément clé du «cloud computing» est l'outillage de gestion du déploiement.

Dans les déploiements «classiques», on a commandé une machine spécifique pour une application spécifique et fait une configuration assez fixe.

Dans un environnement cloud, il y a du matériel plus ou moins standardisé dans un pool et une API qui crée et configure des machines virtuelles sur celui-ci à partir d'une certaine forme de modèles. Grâce à cela, les systèmes défectueux peuvent être facilement remplacés, augmentés ou réduits en fonction des besoins et le matériel peut être alloué selon les besoins, et ce de manière automatisée.

Bien sûr, les administrateurs appropriés ont déjà fait la plupart de cela auparavant, mais en plus du marketing pur, il existe une fondation d'API standardisées (Aamzons AWS API qui est également proposée par des outils comme Eucalyptus pour les "nuages ​​privés") et des outils (c.-à-d. Marionnettes) qui émergent.

Dans l'architecture client-serveur `` traditionnelle '', vous disposiez de ressources attribuées statiquement (ou du moins, elles sont présentées comme telles - je n'ai pas d'expérience de la période pré-cloud, veuillez donc me corriger si je me trompe et dépendre d'un faux marketing). Le serveur de base de données s'appelait db.yourcompany.com et votre serveur Web a communiqué avec lui. Si vous souhaitez augmenter les ressources, vous pouvez ajouter un autre serveur Web dédié et fournir un équilibrage de charge, etc.

D'un autre côté, le stress du cloud a été mis sur l'abstraction des niveaux inférieurs et indique la façon dont le «serveur» est construit. Par exemple, vous avez:

• HAAS (Hardware As A Service) - le client (entreprise) obtient un ordinateur hébergé sur lequel il peut installer le système d'exploitation de son choix. La différence est qu'ils n'obtiennent pas «vraiment» un ordinateur mais une machine virtuelle dans une batterie de serveurs. Parce qu'il est virtualisé, ils n'ont pas besoin de se soucier des détails de niveau inférieur comme la quantité de puissance de calcul, de payer les factures, peu importe si la machine est utilisée, comment elle est connectée, etc.
• PAAS (Platform As A Service) - un niveau plus élevé - vous écrivez une application qui s'exécute quelque part quelque part. Comme l'API est suffisamment générale, les fournisseurs de cloud peuvent allouer des ressources à la demande, donc si votre application est slashdotted, vous paierez pour plus de ressources plutôt que de souffrir de DDOS non malveillant.
• SAAS (Software As A Service) - encore un niveau supérieur - vous n'écrivez pas d'application - vous en utilisez une. Peu importe comment il est mis en œuvre ou quelles ressources il utilise. Il est disponible partout et à tout moment.

Veuillez noter que, dans la plupart des cas, il est sous-entendu que le service réel est externalisé à une grande entreprise (disons Amazon ou Google), ce n'est pas nécessaire - les grandes entreprises ou les universités déploient leurs propres clouds internes pour faciliter la gestion des ressources. Cela permet d'ajouter les ressources à l'application à exécuter au besoin. Si le nouveau démarrage interne réussit, ils n'ont pas à s'inquiéter de la surcharge des serveurs. Cependant, comme l'économie d'échelle joue un rôle, elle n'est généralement effectuée qu'en cas d'exigences particulières (par exemple en matière de sécurité).

Du point de vue de l'utilisateur, il est transparent et a une allure d'architecture client-serveur. Le serveur Web peut vivre «dans le cloud» lors de l'utilisation de l'ancien HTTP simple. Les problèmes d'idées et les solutions remontent en effet aux mainframes des années 50 et actuellement ils reviennent davantage en contraste avec les PC clients épais.

Cela dit, cela pourrait aussi être un mot à la mode dans une phrase donnée et déclarer que l'entreprise est dynamique et se concentre sur ses compétences de base tout en permettant à ses employés.

Quelqu'un peut-il expliquer ce que signifie "cloud computing" par opposition à client-serveur?

Cela dépend de votre point de vue. Pour les entreprises, le cloud computing est bon car il vous permet (généralement) d'être plus flexible avec le nombre de machines prenant en charge vos services. Cette flexibilité vous permet d'être plus réactif, ce qui devrait vous faire économiser de l'argent. Les entreprises peuvent également profiter de laisser le fournisseur de cloud faire des sauvegardes, la reprise après sinistre, la sécurité physique et tous les autres trucs d'infrastructure qu'ils ne veulent pas traiter. Cela conduit généralement à des économies et à une amélioration de la qualité.

Du point de vue du consommateur, la qualité et la fiabilité accrues de la connexion sont bonnes. Certains fournisseurs de cloud aident également à distribuer leurs serveurs pour améliorer la latence des consommateurs.

Pour les programmeurs ... c'est à peu près la programmation client-serveur où le serveur est difficile d'accès et vous avez parfois besoin d'utiliser des API spécialisées.

Je pense qu'il est juste de dire que «cloud computing» et «client-serveur» sont très similaires. De mon point de vue, le cloud computing semble s'appuyer davantage sur le serveur que le modèle "client-serveur". En théorie, certaines formes de cloud computing peuvent se produire indépendamment d'une connexion client. L'avantage d'une application ne s'exécutant que sur le cloud sans communication client ne semble pas très utile, il est donc logique de créer une certaine forme de communication client avec ce serveur.

Essentiellement, je pense que cela dépend principalement de l'endroit où se fait la majorité de votre puissance de calcul. Un serveur a généralement de meilleures spécifications, en termes de matériel et de puissance de calcul, qu'un ordinateur utilisateur standard afin de gérer simplement de nombreuses connexions client et opérations simultanées pour servir ces connexions. Le cloud computing utilise cela comme un avantage en déplaçant ce qui serait normalement du code exécuté par le client vers le serveur et en permettant au client d'être aussi "stupide" que possible. Nécessitant ainsi moins de ressources utilisateur, pour gérer le même type d'opérations.

Ce n'est peut-être pas la meilleure réponse, mais c'est ainsi que je le vois.