Je suis en train d'écrire une application Web ASP.Net à grande échelle.Justification de l'utilisation du nuage?
L'un des trucs que je ne peux pas savoir est comment justifier quand utiliser le nuage. Par exemple. Quand devrais-je utiliser google app engine/azure?
En outre, quand voudrais-je utiliser bigtable sur un dbms standard tel que Sql Server?
Merci
Cloud computing est tout évolutivité. Il vous permet de redimensionner ET de redimensionner sans avoir à retravailler vos conceptions.
Cela fonctionne bien pour les petits sites, puisque vous ne payez que pour les ressources utilisées, mais si vous avez besoin de passer à l'échelle, cela se passe automatiquement (à condition que votre application ait été conçue pour le cloud).
En outre, il existe théoriquement de bien meilleurs outils pour maintenir la disponibilité et la fiabilité dans le cloud. Par exemple, une mise à niveau du système peut se produire sans arrêter votre service, car les plates-formes de cloud computing peuvent automatiquement activer ou désactiver des serveurs pour gérer votre application.
Les développeurs d'Azure en ont beaucoup parlé.
De même, il peut y avoir une motivation financière pour utiliser le cloud. L'utilisation d'une architecture cloud hébergée peut être moins coûteuse que la gestion de plusieurs serveurs (DB, Web, etc.) qui seraient nécessaires pour un site traditionnel, au moins à l'avance. À mesure que votre utilisation augmente, le coût suit, mais en théorie, il peut être plus rentable.
Cette question est étroitement liée à une autre question posée aujourd'hui: « When shouldnt-you-use-a-relational-database? »
bases de données relationnelles et les bases de données non relationnelles (comme BigTable) répondre aux différents besoins. Non seulement dans l'échelle et la performance, mais dans la structure et l'utilisation des données.
Le «nuage» tel que je le comprends concerne principalement l'évolutivité. Autrement dit, l'architecture fait référence à une capacité d'augmenter la capacité de manière évolutive. En outre, le Cloud est fréquemment utilisé en référence au modèle SaaS (Software-as-a-Service), où quelqu'un d'autre s'occupe des serveurs, mais c'est un problème indépendant de l'architecture Cloud. C'est à dire. vous pouvez exploiter votre propre ensemble de serveurs dans une architecture Cloud. Donc, la justification de l'utilisation de l'architecture Cloud est que vous avez une application qui a besoin d'une capacité de calcul variable. Il serait donc exagéré d'avoir N serveurs dédiés pour correspondre à votre niveau d'activité de pointe. Le Cloud vous permet de varier votre utilisation des serveurs à mesure que votre niveau d'activité augmente (et diminue) au fil du temps. La justification de l'utilisation d'un modèle SaaS est que vous ne souhaitez pas exploiter un centre de données. Vous êtes prêt à renoncer à un certain contrôle et payer pour le service, de sorte que vous pouvez laisser les détails de l'opération aux experts de cette technologie. Ils gèrent les sauvegardes, les pannes matérielles, les mises à niveau, les opérations 24 h/24, 7 j/7, etc. Vous gérez votre application et votre entreprise.
Je ne connais pas grand chose d'autre que le moteur d'application et EC2.
Je vais essayer d'ajouter quelque chose aux réponses précédentes:
La meilleure chose à propos App Engine est c'est gratuit jusqu'à ce que vous attirez un certain nombre d'utilisateurs et vous êtes facturé pour ce que votre application utilise, le temps d'inactivité est Non chargé.
Une grande table peut différer d'une architecture rdbms mais du point de vue d'un développeur qui l'utilise, ce n'est pas si différent.
Une autre bonne chose est que python est supporté. La mauvaise chose est que la bibliothèque standard est paralysée. De plus, vous n'avez pas un contrôle total sur vos données dans le cloud (appengine), ce que je veux dire, c'est que vous ne pouvez pas empêcher les gens de google de jeter un coup d'œil sur ce que vous y stockez.
Je vous recommande de vous inscrire et de lire le High Scalability blog, en particulier les articles les plus visités, comme ceux sur l'architecture de divers grands sites, car vous en apprendrez beaucoup pour vous aider à prendre une décision. Il n'y a pas de règle stricte quant au moment où vous devriez ou ne devriez pas utiliser un service cloud ou passer d'une base de données relationnelle à un système de valeurs-clés tel que BigTable. En tout état de cause, l'un des avantages des services cloud est que si vous construisez votre application avec eux, elle sera immédiatement évolutive et nécessitera beaucoup moins de modifications plus tard si vous avez besoin de ce type de performance. Cependant, en vue d'une optimisation prématurée, il serait sage de s'assurer que vous avez besoin de ce genre d'évolutivité avant de décider de construire votre application sur une telle plate-forme. Il existe plusieurs concepts pour vous aider à utiliser un système de stockage de données comme BigTable, par exemple ne pas être capable de claquer des écritures comme dans une base de données relationnelle et de devoir calculer une grande partie de vos données plutôt que de le faire en fonction des informations de la base de données.
bien qu'encore une fois, vous pouvez apprendre beaucoup de lire le blog ci-dessus et les messages connexes à propos de Youtube, Plentyoffish, Google, etc.
Vous dites que vous êtes « en train d'écrire une grande échelle application ASP.NET ». Si vous avez réalisé des progrès significatifs, vous pouvez déjà justifier l'utilisation du moteur d'application Google ou d'Azure. Les deux nécessitent des architectures sensiblement différentes de celles que vous avez construites avec une application traditionnelle en raison de la prise en charge de la langue, des différences de base de données et de la maturité.
Google App Engine est Python uniquement commutation à elle nécessiterait une réécriture complète
grande table n'est pas une base de données relationnelle et nécessite très différentes bagouts de codage. SQL Data Services a d'abord annoncé être non-relationnel, mais se déplace pour être plus relationnel. Je n'ai pas vu à quel point il est proche d'une base de données MSSQL standard. Je considérerais le moteur de l'application Google comme une plate-forme relativement immature jusqu'à maintenant. La fonctionnalité de base de données est limitée, vous ne pouvez pas exécuter les processus d'arrière-plan, le profilage et les outils d'optimisation des performances sont limités au mieux. Azure est actuellement en aperçu de communauté limité, et n'est donc même pas disponible pour expédier un produit aujourd'hui.
Bien qu'il existe de nombreuses raisons valables d'utiliser une architecture en nuage, le passage à cette architecture nécessitera des architectures très différentes. Pensez à l'effet que la modification de cette architecture (et éventuellement l'attente de la disponibilité de la plateforme) peut avoir sur votre date de sortie.
Si vous êtes au début de votre projet, cloud vs.pas de nuage est une bonne question à poser. Si vous avez bien progressé, je pense que l'importance d'avoir accès au code de livraison et de tirer parti du travail que vous avez déjà effectué devrait l'emporter sur les avantages que vous pourriez constater.
J'ai déjà lu ce site. Super site c'est. – dotnetdev
En effet, c'est. :) – Rahul