Comment concevoir des applications pour le cloud computing où plusieurs clouds peuvent être impliqués

Question

Je viens juste de finir de regarder cette question: https://stackoverflow.com / questions / 753122 / quelle-plateforme-informatique-en-nuage-devrait-je-choisir

Toutefois, je ne suis pas certain de ce que je devrais faire pour concevoir une application destinée aux ingénieurs de sécurité. Un temps de disponibilité élevé est donc important.

Ainsi, si mon application est écrite en ASP.NET, avec SQL Server, il semblerait que mon meilleur choix est de concevoir pour Azure, mais la solution d'Amazon serait-elle un bon choix? Comment puis-je décider si je dois avoir tout sur le même système ou les données sur le cloud d'Amazon et ASP.NET sur Azure?

Je travaille sur une autre application qui traite des informations relatives aux services publics, à l'eau et à l'électricité. Il contient donc des informations sur l'utilisation et la facturation. Elle a été écrite en PHP avec SQL Server. Serait-ce une bonne application pour le cloud computing? Il semblerait que la solution d’Amazon soit la meilleure solution pour PHP. C’est donc ma seule option, mais comment décidez-vous quelles parties de leurs offres utiliser?

En gros, ma question concerne l'architecture de l'application. Concevoir pour l'hébergement est facile, mais le cloud computing ajoute de nouveaux défis.

Ma principale préoccupation concerne uniquement la conception de mon application.

Si je choisis la langue, est-ce que cela me verrouille dans une solution cloud?

Quand voudrais-je que la base de données soit dans un nuage différent de celui de l'application?

Si je veux utiliser le framework LIFT (écrit en scala), est-ce que l'un d'entre eux me permettra d'installer tout ce dont j'ai besoin?

Answer 1

Nous exécutons un SaaS de services financiers assez volumineux sur Amazon AWS.

Deux problèmes généraux sont en jeu ici: l'architecture des applications et les services de plate-forme cloud.

J'ai constaté que l'architecture de nos applications est essentiellement la même que si nous effectuions un déploiement sur des machines virtuelles internes ou du matériel réel. Nous avons créé une application à plusieurs niveaux relativement standard utilisant principalement des outils open source (Java, Spring, Hibernate, MySQL, Terracotta, ...). Une base de données à haute disponibilité / tolérante aux erreurs doit être prise en compte (les options matérielles ne sont pas disponibles), mais cela mis à part, nous ne sommes pas vraiment "ciblés". une implémentation cloud particulière.

Les services de plate-forme en nuage sont une autre affaire. J'entends par là des choses comme:

• Démarrage / Arrêt / Surveillance / Gestion / Évolutivité des instances
• Disponibilité / Redondance (par exemple, Amazon a des zones de disponibilité)
• Déploiement / Initialisation / Configuration des instances
• Sauvegarde / récupération de fichier
• Sécurité (par exemple, contrôle du pare-feu)

Il existe peu ou pas de normalisation dans ce domaine, bien que ce soit un domaine d’intérêt actif.

De manière générale, vous voudrez probablement concevoir votre application de manière neutre, mais vous créerez des procédures opérationnelles très spécifiques.

En ce qui concerne la séparation de la présentation et du DB entre différents fournisseurs, je ne le suggérerais pas car:

• Si l'un des fournisseurs tombe en panne, vous êtes en panne
• Le transfert de données sur Internet est plus lent, plus coûteux et moins sécurisé que le transfert de données au sein d'un fournisseur de cloud.

Une meilleure utilisation de plusieurs fournisseurs de cloud serait de déployer des copies entières de votre application sur deux ou plus, en équilibrant la charge entre les deux ou éventuellement en ayant un en veille active au cas où le principal cesserait de fonctionner. Toutefois, si vous capturez des données transactionnelles, vous aurez besoin d’une stratégie pour réconcilier les données saisies dans l’environnement de secours. Cela peut être viable ou non, selon la nature de votre demande.

Vous pouvez généralement installer le logiciel de votre choix sur vos serveurs virtuels, bien que je ne dispose pas d'une expérience spécifique avec Azure. Si vous utilisez AWS ou des services similaires, l'installation de LIFT ne posera pas de problème.

Answer 2

Le choix d’une langue ne vous verrouille pas chez un fournisseur; Cependant, la conception pour s'exécuter sur Windows ne. La virtualisation Windows est un marché beaucoup plus étroit que la virtualisation Linux; Xen, la technologie utilisée par Linode, Slicehost, etc., ne virtualisera pas Windows plus d’une fois.

Avec vos applications ciblées pour Windows, vos choix sont nettement plus minces. Sur mon marché, je sais qu'Amazon s'adresse à Windows (tout comme Azure, évidemment). Cependant, des solutions plus rentables comme la nôtre et celle de Slicehost ne le feront pas - Windows vous coûtera une prime.

Comme pour la ségrégation dans les nuages: principale raison de segmenter votre application en plusieurs "nuages". est de fournir la fiabilité des applications. Les nuages ??s’effondrent - certes, rarement - et le fait d’avoir tous vos œufs dans le même panier vous coûtera cher pour une application nécessitant une haute disponibilité. Cependant, avec votre base de données dans un nuage distinct de votre application, vous allez souffrir de latence pour utiliser SQL sur Internet (vous aurez également besoin d'une architecture pour protéger ce trafic, comme un tunnel SSH ou un chiffrement au niveau du protocole que SQL Server pourrait offrir [pas vraiment sûr, je suis un gars de PostgreSQL]).

Ne tombez pas dans le piège consistant à penser que l’hébergement en nuage est très différent de l’hébergement. En fait, ils sont presque les mêmes. Dans mon entreprise, nous sommes d’avis que l’hébergement en nuage n’est qu’une nouvelle façon de penser au même hébergement. Ce n'est rien de magique.

Pour concevoir un hébergement en nuage, votre application doit simplement disposer de fonctionnalités de partage et être consciente que des nœuds peuvent être ajoutés ou supprimés à tout moment. Ce n’est pas très difficile à expliquer, cela dépend de la façon dont vous l’archivez; généralement, seule une application d’équilibrage de charge connaît même la sémantique spécifique au cloud.

Answer 3

C’est l’aube de "Cloud Computing". et comme dans tout cas de ce genre, les concurrents posent leurs "pièges à souris". en espérant en attraper le plus possible. Il faudra un certain temps avant que les joueurs arrivent à définir un terrain d’entente (c’est-à-dire des normes, sous une forme ou une autre) et d’ici là, leurs armes de "différenciation" nous obligera à choisir des côtés.

Je suppose que cela concerne également les "entreprises". et cela va être rejeté .. mais bon, je pense aux aspects commerciaux avant la technologie / langue. En fin de compte, il s'agit de gagner de l'argent.

Si quelqu'un pense que ne soit pas bloqué par un fournisseur d'informatique en nuage (les types SaaS / PaaS, tandis que les vendeurs de type IaaS sont plus avancés) dès le début du jeu, vous êtes prêt pour certains grandes surprises. Feu au loin!

AVERTISSEMENT: je ne représente aucun fournisseur d'informatique en nuage, quel que soit son type (SaaS, PaaS, IaaS). Est-ce que les gens qui m'ont voté se soucieraient d'identifier leur allégeance?