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 ce qu'il y a en arrière-plan. 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 minuteur, 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 rend 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, pour abstraire 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 qui dépendent des ressources fournies par ce serveur doivent être dirigées vers un autre serveur, et toutes les applications et infrastructures ne sont pas conçues avec ce type de redondance et de tolérance de basculement à l'esprit.
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 "Edge", 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 cela à plusieurs reprises, en passant d'un site hébergé depuis la machine personnelle de Mark Zuckerberg dans un dortoir à un hébergement dédié hors campus, à des batteries de serveurs dans plusieurs endroits du monde.
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 facilement être remplacés, augmentés ou réduits en fonction des besoins et le matériel peut être alloué selon les besoins, même 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 base 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'est-à-dire des marionnettes) qui émergent.
Dans l'architecture client-serveur `` traditionnelle '', vous disposiez de ressources statiquement affectées (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é, dans le cloud, le stress a été mis sur l'abstraction des niveaux inférieurs et indique comment 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 ressemble à l'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 à mainframes des années 5 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é de connexion accrues sont bonnes. Certains fournisseurs de cloud aident également à distribuer leurs serveurs pour aider la latence du consommateur.
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.