PRÉSENTATION DE WINDOWS AZURE

Transcription

1 PRÉSENTATION DE WINDOWS AZURE DAVID CHAPPELL OCTOBRE 2010 AVEC LA PARTICIPATION DE MICROSOFT CORPORATION

2 TABLE DES MATIÈRES Présentation de Windows Azure... 2 Calcul... 4 Stockage... 6 Fabric Controller... 7 Réseau de distribution de contenu... 9 Connexion Utilisation de Windows Azure : les scénarios Création d'une application Web évolutive Création d'une application de traitement parallèle Création d'une application Web évolutive avec un traitement en arrière-plan Création d'une application Web avec des données relationnelles Migration d'une application Web avec données relationnelles sur site Utilisation du stockage cloud à partir d'une application locale ou hébergée Compréhension de Windows Azure : présentation plus détaillée Création d'applications Windows Azure Étude du service de calcul Étude du service de stockage Blobs Tables Files d'attente Étude du Fabric Controller Perspectives d'avenir Conclusions Pour plus d'informations À propos de l'auteur

3 PRESENTATION DE WINDOWS AZURE Le Cloud computing est devenu réalité. Exécuter des applications et stocker des données sur des machines dans un centre de données accessible via Internet peut apporter un grand nombre d'avantages. Cependant, quel que soit l'endroit où elles sont exécutées, les applications sont conçues sur une plateforme. Pour ce qui est des applications sur site, comme celles exécutées au sein du centre de données d'une organisation, cette plateforme inclut généralement un système d'exploitation, un dispositif de stockage, voire éventuellement d'autres ressources. Les applications exécutées dans le cloud nécessitent une fondation similaire. C'est là tout l'objectif de Windows Azure. Intégré à la plateforme Windows Azure, Windows Azure est une fondation permettant l'exécution des applications et le stockage de données dans le cloud. La figure 1 illustre cette approche. Entreprises Utilisateurs finaux Internet Applications Données Windows Azure Centre de données Microsoft Figure 1 : les applications Windows Azure s'exécutent dans les centres de données Microsoft et sont accessibles via Internet. Plutôt que de fournir un logiciel que les clients de Microsoft peuvent installer et exécuter eux-mêmes sur leur propre ordinateur, Windows Azure est actuellement à considérer comme un service. Les clients l'utilisent pour exécuter des applications et stocker des données sur des machines accessibles via Internet appartenant à Microsoft. Ces applications peuvent fournir des services aux entreprises et/ou à des clients particuliers. Voici quelques exemples des types d'applications pouvant être développées dans Windows Azure : Un éditeur de logiciel indépendant (ISV) peut créer une application ciblant les entreprises, une approche souvent qualifiée de Software as a Service (SaaS). Windows Azure a été notamment conçu 2

4 afin de prendre en charge les applications SaaS de Microsoft. Les ISV peuvent donc également l'utiliser comme fondation pour un certain nombre d'applications cloud orientées entreprise. Un ISV peut créer une application SaaS ciblant les clients particuliers plutôt que les entreprises. En effet, Windows Azure est destiné à la prise en charge de logiciels très évolutifs, de sorte qu'une entreprise prévoyant de cibler un vaste marché de consommateurs peut très bien le concevoir comme une plateforme pour une nouvelle application. Les entreprises peuvent utiliser Windows Azure pour créer et exécuter des applications qui sont utilisées par leurs employés. Si cette situation n'implique probablement pas toute l'ampleur d'une application ciblant les utilisateurs, la fiabilité et la facilité de gestion qu'offre Windows Azure constitue tout de même un choix attractif. Afin de prendre en charge les applications et les données cloud, Windows Azure est composé de cinq éléments, comme l'illustre la figure 2. Applications et données Réseau de distribution de contenu (CDN) Connexion Calcul Stockage Fabric Controller Figure 2: Windows Azure est composé de cinq éléments principaux : le service de calcul (Compute), le stockage (Storage), le Fabric Controller, le réseau de distribution de contenu (CDN) et Connexion (Connect). Ces éléments sont les suivants : Windows Azure Service de calcul (Compute) : permet d'exécuter des applications dans le cloud. Ces applications évoluent dans un environnement similaire à Windows Server, bien que le modèle de programmation de Windows Azure ne soit pas exactement identique au modèle de Windows Server sur site. Stockage (Storage) : permet de stocker des données binaires et structurées dans le cloud. Fabric Controller : permet de déployer, de gérer et de contrôler des applications. Le Fabric Controller gère également les mises à jour vers le logiciel système par le biais de la plateforme. Réseau de distribution de contenu (CDN) : accélère l'accès global aux données binaires au sein du stockage de Windows Azure en assurant la maintenance de copies mises en cache de ces données à travers le monde. 3

5 Connexion (Connect) : permet de créer des connexions au niveau de l'ip entre les ordinateurs sur site et les applications Windows Azure. La suite de cette section présente chacune de ces technologies. CALCUL Le service de calcul Windows Azure compute peut exécuter un grand nombre d'applications. Cependant, quel que soit l'objectif d'une application, elle doit être mise en place sous la forme d'un ou de plusieurs rôles. Windows Azure exécute ensuite plusieurs instances de chaque rôle, à l'aide d'un équilibrage de charge intégré pour propager les requêtes sur ces dernières. La figure 3 en est l'illustration. Instances de rôle Web Instances de rôle de travail Instances de rôle d'ordinateur virtuel IIS Équilibreur de charge HTTP/HTTPS, TCP Ordinateurs virtuels Applications et données Réseau de distribution de contenu (CDN) Connexion Calcul Stockage Fabric Controller Figure 3 : Une application s'exécutant sous Windows Azure se compose d'une combinaison libre d'instances de rôle Web, d'instances de rôle de travail et d'instances de rôle d'ordinateur virtuel. Dans la version actuelle de Windows Azure, les développeurs peuvent choisir parmi trois types de rôles : Les rôles Web, dont l'objectif principal est de simplifier la création d'applications Web. Chaque instance de rôle Web dispose d'une préconfiguration d'internet Information Services (IIS) 7. Dès lors, la création d'applications à l'aide d'asp.net, Windows Communication Foundation (WCF) ou d'autres technologies Web s'en trouve simplifiée. Les développeurs peuvent également créer des applications en code natif, l'utilisation de.net Framework n'est pas obligatoire. Cela signifie que les développeurs peuvent installer et exécuter d'autres technologies non Microsoft, comme PHP et Java. Les rôles de travail, conçus pour exécuter une vaste gamme de codes Windows. La différence principale entre un rôle Web et un rôle de travail est que les rôles de travail ne disposent pas d'une préconfiguration d'iis et le code qu'ils exécutent n'est donc pas hébergé par IIS. Un rôle de travail 4

6 peut par exemple exécuter une simulation, gérer un traitement vidéo ou effectuer pratiquement tout autre type d'opération. Les applications interagissent fréquemment avec les utilisateurs par le biais d'un rôle Web et délèguent ensuite des tâches à un rôle de travail qui prend en charge leur traitement. Là encore, un développeur peut utiliser librement.net Framework ou tout autre logiciel exécuté sous Windows et comprenant des technologies non Microsoft. Les rôles d'ordinateur virtuel, chacun exécutant une image Windows Server 2008 R2 fournie par l'utilisateur. Entre autres fonctionnalités, un rôle d'ordinateur virtuel peut parfois s'avérer utile dans le cadre de la migration d'une application Windows Server sur site sous Windows Azure. Un développeur peut passer par le portail Windows Azure pour envoyer une application. Outre l'application, il envoie des informations de configuration indiquant à la plateforme le nombre d'instances de chaque rôle à exécuter. Le Fabric Controller de Windows Azure crée ensuite un ordinateur virtuel (VM) pour chaque instance et exécute le code correspondant au rôle de l'ordinateur virtuel concerné. Comme illustré dans la figure 3, les utilisateurs de l'application peuvent lancer des requêtes à l'aide des protocoles HTTP, HTTPS et TCP, entre autres. À leur arrivée, ces requêtes font l'objet d'un équilibrage de charge entre toutes les instances d'un rôle. Puisque l'équilibrage de charge ne permet pas la création d'une affinité avec une instance de rôle particulière (absence de prise en charge des sessions associées), il n'y a pas moyen de garantir que les requêtes multiples de la part du même utilisateur seront envoyées à la même instance d'un rôle. Dès lors, les instances de rôle Windows Azure ne doivent pas maintenir leur état elles-mêmes entre les requêtes. En revanche, tout état spécifique au client doit être écrit dans le stockage de Windows Azure, stocké dans SQL Azure (un autre composant de la plateforme Windows Azure), ou maintenu de façon externe par un autre biais. Un développeur peut utiliser une combinaison libre d'instances de rôle Web, d'instances de rôle de travail et d'instances de rôle d'ordinateur virtuel afin de créer une application Windows Azure. Si la charge de l'application augmente, il peut utiliser le portail Windows Azure pour demander plus d'instances pour n'importe quel rôle de cette application. Si la charge baisse, il peut diminuer le nombre d'instances en cours d'exécution. Windows Azure présente également une API permettant de programmer ces tâches (modifier le nombre d'instances à exécuter ne nécessite pas d'intervention manuelle), mais la plateforme ne met pas les applications à l'échelle automatiquement sur la base de leur charge. Pour créer des applications Windows Azure, un développeur utilise les mêmes langues et outils que pour toute application Windows. Il doit écrire un rôle Web à l'aide d'asp.net et de Visual Basic, par exemple, ou utiliser WCF et C#. De même, il doit créer un rôle de travail dans un des langages.net, travailler directement en C++ sans.net Framework, ou utiliser Java. Même si Windows Azure offre des compléments pour Visual Studio, l'utilisation de cet environnement de développement n'est pas obligatoire. Par exemple, un développeur ayant installé PHP peut choisir d'utiliser un autre outil pour écrire les applications. Pour permettre la surveillance et le débogage des applications Windows Azure, chaque instance peut appeler une API d'enregistrement écrivant les informations dans un journal d'application courant. Un développeur peut également configurer le système pour recueillir des compteurs de performance pour une application, mesurer l'utilisation de l'uc, stocker des vidages sur incident en cas d'échec et bien plus encore. Ces informations sont conservées dans le stockage de Windows Azure. Un développeur peut écrire du code pour l'étudier. Par exemple, si une instance de rôle de travail se bloque trois fois en une heure, le code personnalisé peut envoyer un à l'administrateur de l'application. 5

7 La capacité à exécuter le code est une partie essentielle d'une plateforme cloud, mais cela n'est pas suffisant. Les applications ont également besoin d'un stockage permanent. Répondre à ce besoin est l'objectif du service de stockage de Windows Azure, décrit ci-après. STOCKAGE Les applications fonctionnent avec les données de différentes façons. C'est pourquoi le service de stockage de Windows Azure offre plusieurs options. La figure 4 illustre les différents choix. Blobs Tables Files d'attente HTTP/HTTPS, OData Applications et données Réseau de distribution de contenu (CDN) Connexion Calcul Stockage Fabric Controller Figure 4 : Le stockage de Windows Azure offre des blobs, des tables et des files d'attentes. La manière la plus simple de stocker des données dans Windows Azure est d'utiliser des blobs. Un blob comprend des données binaires et comme l'illustre la figure 4, la hiérarchie est simple : chaque conteneur peut contenir un ou plusieurs blobs. Les blobs peuvent être de taille importante (jusqu'à un téraoctet) et peuvent également être associés à des métadonnées, comme les informations concernant le lieu où a été prise une photo JPEG ou l'identité du chanteur d'un fichier MP3. Les blobs fournissent également le stockage sous-jacent pour les lecteurs Windows Azure, un mécanisme permettant à une instance de rôle de Windows Azure d'interagir avec le stockage permanent comme s'il s'agissait d'un système de fichiers local NTFS. Les blobs sont adaptés à certaines situations, mais ne sont pas assez structurés pour d'autres. Pour que les applications fonctionnent avec les données de manière plus précise, le stockage de Windows Azure fournit des tables. Ne vous laissez pas tromper par le nom, il ne s'agit pas de tableaux relationnels. Les données que contient chacune d'entre elles sont en fait stockées dans un groupe d'entités contenant des propriétés. Plutôt que d'utiliser le SQL, une application peut rechercher les données d'une table à l'aide des conventions définies par OData. Cette approche permet un stockage de montée en charge (une mise à l'échelle en diffusant les données sur plusieurs machines) de manière bien plus efficace que le ferait une 6

8 base de données relationnelle standard. D'ailleurs, une seule table Windows Azure peut contenir des milliards d'entités comprenant plusieurs téraoctets de données. Les blobs et les tables sont dédiés au stockage et à l'accès des données. La troisième option de stockage de Windows Azure, les files d'attente, a un tout autre objectif. La première fonction des files d'attente est de fournir un moyen aux instances de rôle Web de communiquer de manière asynchrone avec les instances de rôle de travail. Par exemple, un utilisateur peut envoyer une requête pour effectuer une tâche nécessitant une grande capacité de calcul via une interface Web mise en place par un rôle Web Windows Azure. L'instance de rôle Web recevant cette requête peut écrire un message dans une file d'attente décrivant le travail à effectuer. Une instance de rôle de travail en attente dans cette file d'attente peut ensuite lire le message et exécuter la tâche spécifiée. Les résultats peuvent être renvoyés via une autre file d'attente ou gérés d'une autre manière. Indépendamment de la manière dont les données sont stockées (dans des blobs, des tables ou des files d'attentes), toutes les informations contenues dans le stockage de Windows Azure sont répliquées trois fois. Cette réplication comporte une tolérance de pannes, puisque la perte d'une copie n'est pas grave en soi. Cependant, le système assure une cohérence importante, de sorte qu'une application lisant immédiatement les données qui viennent d'être écrites est assurée de les reprendre. Windows Azure conserve également une copie de sauvegarde de toutes les données dans un autre centre de données dans la même partie de l'environnement. Si le centre de données comprenant la copie principale n'est pas disponible ou a été supprimé, cette sauvegarde reste accessible. Il est possible d'accéder au stockage de Windows Azure via une application Windows Azure, via une application sur site, ou via une application exécutée sur un hébergeur ou sur une autre plateforme cloud. Dans tous les cas, les trois styles de stockage de Windows Azure utilisent les conventions de REST pour identifier et exposer les données, comme l'illustre la figure 4. Les blobs, les tables et les files d'attente sont tous nommés à l'aide des URI et sont accessibles via les opérations HTTP standard. Un client.net peut utiliser une bibliothèque fournie par Windows Azure à cette fin, mais ce n'est pas obligatoire (une application peut également effectuer des appels HTTP bruts). La création d'applications Windows Azure utilisant des blobs, des tables et des files d'attente peut être utile. À la place, les applications qui s'appuient sur un stockage relationnel peuvent utiliser SQL Azure, un autre composant de la plateforme Windows Azure. Les applications exécutées sur Windows Azure (ou ailleurs) peuvent utiliser cette technologie pour obtenir un accès basé sur du SQL au stockage relationnel dans le cloud. FABRIC CONTROLLER Toutes les applications Windows Azure et toutes les données du stockage de Windows Azure résident dans un centre de données Microsoft. Dans le centre de données, l'ensemble de machines dédiées à Windows Azure et les logiciels exécutés sur ces dernières sont gérés par le Fabric Controller. La figure 5 illustre cette approche. 7

9 Stockage Instances de rôle Agent Fabric Agent Fabric Fabric Controller Applications et données Réseau de distribution de contenu (CDN) Connexion Calcul Stockage Fabric Controller Figure 5 : Le Fabric Controller interagit avec les applications Windows Azure via un agent Fabric. Le Fabric Controller est lui-même une application distribuée qui est répliquée sur un groupe de machines. Il possède toutes les ressources dans son environnement : les ordinateurs, les commutateurs, les équilibreurs de charge et bien plus encore. Puisque qu'il peut communiquer avec un agent Fabric sur chaque ordinateur, il s'occupe également de chaque application Windows Azure dans Fabric (il est intéressant de noter que le Fabric Controller considère le stockage de Windows Azure comme une autre application, ainsi, les détails de la gestion des données et de la réplication ne sont pas visibles pour le Fabric Controller). Cette connaissance générale permet au Fabric Controller d'effectuer un certain nombre d'actions utiles. Par exemple, il gère toutes les applications en cours, en offrant une image instantanée de ce qui se passe. Il est possible de décider à quel endroit les nouvelles applications doivent être exécutées, en choisissant des serveurs physiques pour optimiser l'utilisation matérielle. À cette fin, le Fabric Controller dépend des informations de configuration qui sont téléchargées avec chaque application de Windows Azure. Ce fichier offre une description XML de ce dont nécessitent les applications : le nombre d'instances de rôle Web, le nombre d'instances de rôle de travail et plus encore. Lorsque le Fabric Controller déploie une nouvelle application, il utilise ce fichier de configuration pour déterminer le nombre d'ordinateurs virtuels à créer. Une fois ces ordinateurs virtuels créés, le Fabric Controller surveille chacun d'eux. Si par exemple une application nécessite cinq instances de rôle Web et qu'une d'entre elles échoue, le Fabric Controller en démarrera automatiquement une nouvelle. De même, si la machine sur laquelle un ordinateur virtuel tourne échoue, le Fabric Controller démarrera une nouvelle instance du rôle sur une nouvelle machine en réinitialisant l'équilibrage de charge au besoin pour pointer vers ce nouvel ordinateur virtuel. 8

10 Windows Azure offre actuellement aux développeurs le choix parmi cinq tailles d'ordinateur virtuel. Les différentes options sont : Extra-petite, avec une UC 1 GHz cœur unique, 768 Mo de mémoire et 20 Go de stockage d'instance. Petite, avec une UC 1,6 GHz cœur unique, 1,75 Go de mémoire et 225 Go de stockage d'instance. Moyenne, avec une UC double cœur 1,6 GHz, 3,5 Go de mémoire et 490 Go de stockage d'instance. Large, avec une UC 1,6 GHz quatre cœurs, 7 Go de mémoire, et Go de stockage d'instance. Extra-large, avec une UC 1,6 GHz huit cœurs, 14 Go de mémoire et Go de stockage d'instance. Une instance extra-petite partage un cœur de processeur avec d'autres instances extra-petites. Cependant, pour toutes les autres tailles, chaque instance dispose d'au moins un cœur dédié. Cela signifie qu'il est possible de prévoir les performances de cette application et qu'il n'y a pas de limite arbitraire concernant la durée pendant laquelle une instance peut s'exécuter. Par exemple, une instance de rôle Web peut prendre autant de temps que nécessaire pour la gestion d'une requête de la part d'un utilisateur, alors qu'une instance de rôle de travail peut calculer la valeur de pi à un million de chiffres. Pour les rôles Web et de travail (et non les rôles d'ordinateur virtuel), le Fabric Controller gère également le système d'exploitation pour chaque instance. Cette gestion comprend notamment l'application de correctifs du système d'exploitation et la mise à jour d'autres logiciels système, entre autres. Ce principe de fonctionnement permet aux développeurs de se consacrer uniquement à la création d'applications : ils n'ont pas à se soucier de la gestion de la plateforme proprement dite. Il est cependant important de comprendre que le Fabric Controller considère toujours qu'au moins deux instances de chaque rôle sont exécutées. Ce système lui permet d'arrêter l'une d'entre elles pour mettre à jour ses logiciels sans arrêter l'ensemble de l'application. C'est pour cette raison, entre autres, qu'il est généralement déconseillé d'exécuter une seule instance d'un rôle de Windows Azure. RESEAU DE DISTRIBUTION DE CONTENU Les blobs sont couramment utilisés pour stocker les informations auxquelles vous aurez accès à partir de plusieurs emplacements. Par exemple, une application pour des vidéos destinées à des clients Flash, Silverlight ou HTML 5 dans le monde. Pour améliorer les performances dans ce genre de situations, Windows Azure offre un réseau de distribution de contenu. Un réseau de distribution de contenu stocke les copies d'un blob sur des sites plus proches des clients qui l'utilisent. La figure 6 illustre cette approche. 9

11 Blobs Windows Azure Applications et données Réseau de distribution de contenu (CDN) Connexion Calcul Stockage Fabric Controller Figure 6 : Le réseau de distribution de contenu de Windows Azure met en cache des copies de blobs dans le monde entier, ce qui permet aux utilisateurs d'accéder aux informations plus rapidement. Cette illustration n'est pas à prendre la lettre : le réseau de distribution de contenu de Windows Azure dispose en fait de bien plus d'emplacements de mise en cache qu'il n'y paraît. Le concept est néanmoins correct. La première fois qu'un utilisateur accède à un blob en particulier, le réseau de distribution de contenu stocke une copie du blob en question dans un emplacement géographiquement proche de l'utilisateur. Lors de la prochaine connexion au blob, son contenu est transmis par le cache plutôt que par l'original, dont l'emplacement est plus lointain. Par exemple, supposons que Windows Azure est utilisé pour fournir des vidéos d'un événement sportif d'une journée à un public disséminé sur une vaste étendue géographique. Le premier utilisateur qui accède à une vidéo en particulier ne bénéficiera pas des avantages du réseau de distribution de contenu, car ce blob n'est pas encore mis en cache dans un emplacement plus proche. Cependant, tous les autres utilisateurs situés à proximité géographique bénéficieront de meilleures performances, étant donné que la copie mise en cache permet à la vidéo de se charger plus rapidement. CONNEXION Il est utile d'exécuter des applications dans le cloud de Microsoft. Mais les applications et les données que nous utilisons au sein de nos organisations ne sont pas près de disparaître. Il est dès lors important de connecter efficacement les environnements sur site avec Windows Azure. Windows Azure Connect est conçu pour contribuer à y parvenir. En fournissant une connexion au niveau IP entre une application Windows Azure et des machines s'exécutant en dehors du cloud de Microsoft, cette combinaison est plus simple à réaliser. La figure 7 illustre cette approche. 10

12 Applications et données Instances de rôle Agent de terminaison IPsec Ordinateur Windows sur site Windows Azure Calcul Applications et données Réseau de distribution de contenu (CDN) Connexion Calcul Stockage Fabric Controller Figure 7 : Windows Azure Connect permet des communications au niveau IP entre un ordinateur Windows sur site et une application Windows Azure. Comme l'illustre la figure, l'utilisation de Windows Azure Connect nécessite l'installation d'un agent de terminaison sur chaque ordinateur sur site se connectant à une application Windows Azure (étant donné que la technologie s'appuie sur IP v6, l'agent de terminaison n'existe actuellement que pour Windows Server 2008, Windows Server 2008 R2, Windows Vista et Windows 7). L'application Windows Azure doit également être configurée pour fonctionner avec Windows Azure Connect. Une fois cette configuration effectuée, l'agent peut utiliser IPsec pour interagir avec un rôle en particulier au sein de cette application. Veuillez notez qu'il ne s'agit pas d'un réseau privé virtuel à part entière (VPN). Si Microsoft a fait part de ses intentions d'offrir ce type de service à terme, Windows Azure Connect est une solution plus simple. Sa configuration ne nécessite pas de contacter votre administrateur réseau, par exemple. Vous devez uniquement être en mesure d'installer l'agent de terminaison sur l'ordinateur local. Cette approche permet également d'éluder la complexité potentielle de la configuration d'ipsec : Windows Azure Connect s'en charge pour vous! Une fois la technologie mise en place, les rôles d'une application Windows Azure semblent se trouver sur le même réseau IP que l'ordinateur virtuel. Ce système permet d'effectuer des opérations du type suivant : Une application Windows Azure peut accéder directement à une base de données sur site. Par exemple, supposons qu'une organisation migre une application Windows Server existante élaborée à l'aide d'asp.net dans un rôle Web Windows Azure. Si la base de données utilisée par cette application doit rester sur site, une connexion Windows Azure Connect peut permettre à l'application, désormais exécutée sous Windows Azure, d'accéder à la base de données sur site de façon similaire à ce qui se faisait jusqu'alors. Même la chaîne de connexion ne doit pas être modifiée. 11

13 Une application Windows Azure peut être jointe à un domaine sur l'environnement sur site. Cette opération permet aux utilisateurs sur site de disposer d'une authentification unique pour accéder à l'application cloud. Elle permet également à l'application d'utiliser des comptes et des groupes Active Directory existants pour le contrôle d'accès. Il est important d'assurer une bonne intégration du cloud dans l'environnement sur site actuel. En autorisant la connexion directe au niveau IP, Windows Azure Connect facilite cette intégration pour les applications Windows Azure. UTILISATION DE WINDOWS AZURE : LES SCENARIOS Comprendre les composants de Windows Azure est important mais demeure insuffisant. La meilleure méthode pour se faire une idée des possibilités offertes par cette plateforme est de parcourir des exemples illustrant la façon dont vous pourriez l'exploiter. C'est pourquoi cette section aborde plusieurs scénarios concernant l'utilisation de Windows Azure : créer une application Web évolutive, créer une application de traitement parallèle, créer une application Web avec un traitement en arrière-plan, créer une application Web avec des données relationnelles, effectuer la migration d'une application Web avec données relationnelles sur site et utiliser le stockage cloud à partir d'une application locale ou hébergée. CREATION D'UNE APPLICATION WEB EVOLUTIVE Supposons qu'une organisation souhaite créer une application Web accessible via Internet. De nos jours, le choix commun est d'exécuter cette application dans un centre de données au sein de l'organisation ou chez un hébergeur. Toutefois, dans nombre de cas, une plateforme cloud comme Windows Azure est un choix plus judicieux. Par exemple, si l'application doit gérer un grand nombre d'utilisateurs simultanés, il est logique de la créer sur une plateforme conçue spécialement pour prendre en charge cette situation. Le support intrinsèque des applications et des données évolutives fourni par Windows Azure peut gérer des charges beaucoup plus volumineuses que les technologies Web conventionnelles. Supposons que la charge de l'application varie de manière significative, avec des pics occasionnels au milieu de longues périodes d'utilisation réduite. Ce schéma peut se retrouver par exemple pour un site de billetterie en ligne, un site d'actualités vidéo comprenant occasionnellement des informations très populaires, une application utilisée principalement à certaines heures de la journée, etc. L'exécution de ce type d'application dans un centre de données conventionnel nécessite toujours de posséder assez de machines disponibles pour pouvoir gérer les pics, même si la majorité de ces systèmes ne sont généralement pas utilisés. Si l'application est créée sur Windows Azure, l'organisation responsable de son exécution peut accroître le nombre d'instances utilisées uniquement lorsque cela est nécessaire, puis revenir à un nombre plus petit. Puisque le coût de Windows Azure est basé sur l'utilisation (vous payez chaque instance à l'heure), cela vous reviendra certainement moins cher que la maintenance d'un grand nombre de machines pour la plupart inutilisées. Pour créer une application Web fortement évolutive sur Windows Azure, un développeur doit utiliser les rôles Web et les tables. La figure 8 illustre cette approche. 12

14 Application Web évolutive Instance de rôle Web Tables Utilisateurs Figure 8 : Une application Web évolutive peut utiliser des instances de rôle Web et des tables. Dans cet exemple, les clients sont des navigateurs, donc la logique d'application peut être mise en place à l'aide d'asp.net ou d'une autre technologie Web. Il est également possible de créer une application Web évolutive exposant des services Web basés sur RESTful ou SOAP à l'aide de WCF et qui appelle ensuite ces services depuis un client Silverlight, par exemple. Dans les deux cas, le développeur précise le nombre d'instances à exécuter par le rôle Web, puis le Fabric Controller de Windows Azure crée le nombre d'ordinateurs virtuels. Comme décrit précédemment, le Fabric Controller gère également ces instances, assurant que le nombre demandé est toujours disponible. Concernant le stockage de données, l'application utilise les tables de stockage de Windows Azure offrant un stockage de montée en charge pouvant gérer de très grandes quantités de données. CREATION D'UNE APPLICATION DE TRAITEMENT PARALLELE Les applications Web évolutives sont utiles mais elles ne sauraient résumer l'utilité plus vaste de Windows Azure. Prenons l'exemple d'une organisation nécessitant occasionnellement une grande capacité de calcul pour une application de traitement parallèle. Beaucoup de situations correspondent à cet exemple : modélisation financière, rendu dans une entreprise d'effets spéciaux cinématographiques, développement de nouveaux médicaments dans une entreprise pharmaceutique, etc. Il est possible de maintenir un important cluster de machines pour répondre à un besoin occasionnel, mais cela représente un certain coût. Toutefois, Windows Azure peut fournir ces ressources au besoin, en proposant un cluster de calcul à la demande. Un développeur peut utiliser des rôles de travail pour créer ce type d'application. Même s'il ne s'agit pas d'un choix unique, les applications parallèles utilisent généralement des datasets importants qui peuvent être stockés dans les blobs Windows Azure. La figure 9 illustre ce type d'application. 13

15 Application de traitement en parallèle Instance de rôle Web Files d'attente Instance de rôle de travail Blobs Utilisateur Figure 9 : Une application de traitement parallèle doit utiliser une instance de rôle Web, un grand nombre d'instances de rôle de travail, des files d'attentes et des blobs. Dans le scénario illustré, le travail parallèle est effectué par un nombre d'instances de rôle de travail s'exécutant simultanément, chacune utilisant les données de blobs. Puisque Windows Azure n'impose pas de limite de durée d'exécution d'une instance, chacune peut effectuer une quantité arbitraire de travail. Pour interagir avec l'application, l'utilisateur s'appuie sur une instance de rôle Web unique. Via cette interface, l'utilisateur peut déterminer le nombre d'instances de travail devant s'exécuter. Il peut démarrer et arrêter ces instances, accéder aux résultats, et plus encore. La communication entre l'instance de rôle Web et les instances de rôle de travail dépend des files d'attentes du stockage de Windows Azure. Compte tenu de la quantité énorme de puissance de calcul disponible dans le cloud, cette nouvelle approche pourrait métamorphoser l'aspect des calculs complexes. Par exemple, Microsoft Windows HPC Server permet désormais de créer un cluster de calcul à l'aide des instances du rôle de travail Windows Azure en accompagnement ou à la place de serveurs physiques sur site. Quelle que soit la méthode employée pour y parvenir, exploiter cette nouvelle source de puissance de calcul peut s'avérer utile dans de nombreuses circonstances. CREATION D'UNE APPLICATION WEB EVOLUTIVE AVEC UN TRAITEMENT EN ARRIERE- PLAN On peut probablement dire que de nos jours, la majorité des applications créées proposent une interface de navigation. Les applications qui se dédient exclusivement à accepter et à répondre à des requêtes de navigateur sont utiles, mais également restrictives. Il existe de nombreux cas dans lesquels le logiciel accessible via le Web requiert un lancement de travail s'exécutant en arrière-plan, indépendamment de la requête/réponse de l'application. C'est le cas par exemple d'une application Web de partage de vidéos. Elle doit accepter les requêtes de navigation venant probablement d'un grand nombre d'utilisateurs simultanés. Certaines de ces requêtes vont télécharger de nouvelles vidéos, lesquelles doivent être traitées et stockées pour un accès ultérieur. 14

16 Il serait préjudiciable de faire attendre l'utilisateur pendant le traitement. Au lieu de cela, la partie de l'application acceptant les requêtes de navigateur doit pouvoir lancer une tâche en arrière-plan effectuant ce travail. Les rôles Web et de travail peuvent être combinés pour effectuer ce scénario. La figure 10 illustre ce type d'application. Application Web évolutive avec traitement en arrière-plan Tables Instance de rôle Web Files d'attente Instance de rôle de travail Blobs Utilisateurs Figure 10 : Une application Web évolutive avec un traitement en arrière-plan peut utiliser de nombreuses capacités de Windows Azure. De la même manière que l'application Web évolutive décrite précédemment, cette application utilise un nombre d'instances de rôle Web pour gérer les requêtes des utilisateurs. Pour pouvoir prendre en charge un grand nombre d'utilisateurs simultanés, elle utilise des tables pour stocker les informations relatives à leur profil. Concernant le traitement en arrière-plan, il dépend des instances de rôle de travail, en faisant passer les tâches via les files d'attente. Dans cet exemple, ces instances de rôle de travail fonctionnent sur des données blob. D'autres approches sont cependant possibles. Cet exemple illustre la manière dont une application peut utiliser de nombreuses capacités de base que Windows Azure présente : les instances de rôle Web, les instances de rôle de travail, les blobs, les tables et les files d'attente. Même si cela n'est pas illustré dans la figure, une application de partage vidéo peut également utiliser le réseau de distribution de contenu de Windows Azure pour accélérer l'accès. Même si toutes les applications ne nécessitent pas forcément l'intégralité de ces fonctionnalités, le fait qu'elles soient toutes disponibles est essentiel à la prise en charge des scénarios plus complexes comme celui-ci. CREATION D'UNE APPLICATION WEB AVEC DES DONNEES RELATIONNELLES Les blobs et les tables de Windows Azure sont nécessaires pour certaines situations. Cependant, pour beaucoup d'autres, les données relationnelles sont plus appropriées. Prenons l'exemple d'une organisation qui souhaite élaborer et exécuter une application destinée à ses propres employés sous Windows Azure. La durée de vie de l'application en question sera peut-être courte, voire imprévisible. Lui 15

17 attribuer un serveur au sein du centre de données de l'entreprise n'est donc pas justifié. Il se peut également que l'application doive être opérationnelle aussi vite que possible, rendant de fait inacceptable l'attente nécessaire à ce que le service informatique interne fournisse un serveur. L'organisation en question peut également considérer qu'exécuter l'application sous Windows Azure sera moins onéreux et plus simple. Quelle qu'en soit la raison, cette application n'a pas forcément besoin de la mise à l'échelle massive proposée par les tables de Windows Azure. En revanche, ses créateurs peuvent préférer utiliser l'approche relationnelle qu'ils connaissent déjà à l'aide d'outils de création de rapports familiers. Dans ce genre de cas, l'application peut utiliser Windows Azure avec SQL Azure, comme l'illustre la figure 11. Nouvelle application Web avec données relationnelles Instance de rôle Web SQL Azure Utilisateurs Figure 11 : Une application Windows Azure peut utiliser SQL Azure pour travailler avec des données relationnelles. SQL Azure propose un large sous-ensemble de fonctionnalités de SQL Server, y compris la création de rapports, en tant que service cloud géré. Les applications peuvent créer des bases de données, exécuter des requêtes SQL et plus encore. En revanche, il n'est pas nécessaire d'administrer le système de base de données sur le matériel sur lequel il est exécuté (Microsoft s'en charge). Il est possible d'accéder à une base de données SQL Azure à l'aide du protocole Tabular Data Stream (TDS), de la même manière que pour les versions locales de SQL Server. Cela permet à une application de Windows Azure d'accéder aux données relationnelles à l'aide de mécanismes traditionnels comme Entity Framework et ADO.NET. Par ailleurs, étant donné que SQL Azure est un service cloud, les coûts se calculent sur la base de l'utilisation. Comme Windows Azure et SQL Azure offrent des télécopies cloud de leurs homologues locaux, le déplacement du code et des données pour ce type d'application entre les deux univers est immédiat. Les éléments ne sont pas parfaitement identiques (par exemple, le code Windows Azure doit être en mesure d'exécuter plusieurs instances), mais le cloud et l'environnement sur site sont assez similaires. Cette probabilité est utile pour chaque action nécessitant de créer une application dont le code et les données peuvent exister soit de manière locale, soit dans le cloud. 16

18 MIGRATION D'UNE APPLICATION WEB AVEC DONNEES RELATIONNELLES SUR SITE Plutôt que de créer une nouvelle application Web pour Windows Azure, supposons qu'une organisation souhaite migrer une application Windows Server existante sur cette plateforme cloud. Une méthode d'approche consiste à utiliser le rôle d'ordinateur virtuel Windows Azure. Ce cas est fort semblable au précédent, comme l'illustre la figure 12. Application Web avec données relationnelles migrée sur site Instance de rôle d'ordinateur virtuel SQL Azure Utilisateurs Figure 12 : Certaines applications sur site peuvent être migrées sur Windows Azure à l'aide du rôle d'ordinateur virtuel et de SQL Azure. Pour utiliser un rôle d'ordinateur virtuel, une organisation crée un disque dur virtuel (VHD) depuis un ordinateur sur site exécutant Windows Server 2008 R2. Cette image peut ensuite être téléchargée sur Windows Azure et exécutée au sein d'un rôle d'ordinateur virtuel. Comme l'illustre la figure, l'application peut accéder à des données relationnelles de SQL Azure. Une autre option consiste à conserver ces données sur site, en y accédant directement par le biais de Windows Azure Connect comme décrit précédemment. Le rôle d'ordinateur virtuel peut être utile. Il est important de comprendre, cependant, que migrer une application Windows Server sur Windows Azure peut nécessiter plus d'étapes que la préparation d'un packaging sur un disque dur virtuel et son exécution dans un rôle d'ordinateur virtuel. Tout d'abord, n'oubliez pas que le Fabric Controller de Windows Azure suppose qu'il existe au moins deux instances de chaque rôle exécutées à tout moment (afin de répondre aux conditions du contrat de niveau de service Windows Azure Service Level Agreement, SLA). N'oubliez pas que Windows Azure équilibre les charges de toutes les demandes des utilisateurs parmi les instances d'un rôle. Si l'application en cours de migration est conçue pour fonctionner de cette manière (elle est peut-être déjà exécutée dans une batterie de serveurs Web avec équilibrage de charge, par exemple), elle peut s'exécuter sans peine sous Windows Azure sans modifications importantes. En revanche, si l'application s'exécute normalement sur une instance unique, une refonte sera sans doute nécessaire pour qu'elle s'exécute avec succès sous Windows Azure. 17

19 UTILISATION DU STOCKAGE CLOUD A PARTIR D'UNE APPLICATION LOCALE OU HEBERGEE Windows Azure propose un éventail de capacités, mais parfois une application ne nécessite que l'une d'entre elles. Prenons l'exemple d'une application locale ou hébergée devant stocker une quantité significative de données. Par exemple, une organisation peut souhaiter archiver de vieux s, en économisant de l'argent sur le stockage tout en gardant le courrier accessible. Un site Web d'actualités exécuté sur un hébergeur peut nécessiter un emplacement évolutif, accessible dans le monde entier pour stocker de grandes quantités de texte, d'images, de vidéos et d'informations de profil des utilisateurs. Un site de partage de photos peut souhaiter décharger les enjeux du stockage de ses informations sur un tiers fiable. Toutes ces situations peuvent être traitées par le stockage de Windows Azure, comme l'illustre la figure 13. Blobs Tables Application sur site ou hébergée Figure 13 : Une application locale ou hébergée peut utiliser les blobs ou les tables de Windows Azure pour stocker ses données dans le cloud. Comme mentionné précédemment, une application sur site ou hébergée peut accéder directement au stockage de Windows Azure. Cet accès est susceptible d'être plus lent que lors d'un travail avec un stockage local, mais il est également moins cher, plus évolutif et plus fiable. Pour certaines applications, ce compromis est vraiment valable. Même si cela n'est pas illustré dans la figure, les applications peuvent utiliser SQL Azure de la même manière. COMPREHENSION DE WINDOWS AZURE : PRESENTATION PLUS DETAILLEE Pour comprendre Windows Azure, il est important de connaître les bases de la plateforme, puis d'étudier des scénarios types dans lesquels ces bases peuvent s'appliquer. Toutefois, cette technologie ne se résume pas à cela. Cette section présente plus en détails certains de ses aspects les plus intéressants. 18

20 CREATION D'APPLICATIONS WINDOWS AZURE Pour les développeurs, créer une application Windows Azure ressemble plus à la création d'une application Windows traditionnelle. Comme la plateforme prend en charge à la fois les applications.net et les applications créées à l'aide de code non géré, un développeur peut utiliser celle qui correspond le mieux à son problème. Pour faciliter les choses, Visual Studio fournit des modèles de projet pour créer des applications Windows Azure. Il est également possible de télécharger directement des applications depuis Visual Studio sur Windows Azure. Une différence évidente entre le cloud et les environnements locaux est que les applications de Windows Azure ne s'exécutent pas localement. Cette différence rend potentiellement le développement plus complexe. Pour le simplifier, Microsoft propose le Development Fabric, une version de l'environnement Windows Azure s'exécutant sur une machine de développeur. Le Development Fabric s'exécute sur un poste de travail ou un serveur unique. Il émule la fonctionnalité de Windows Azure dans le cloud, avec les rôles Web, les rôles de travail, les rôles d'ordinateur virtuel et les trois options du stockage de Windows Azure. Un développeur peut créer une application Windows Azure, la déployer vers le Development Fabric et l'exécuter presque de la même manière qu'avec l'objet réel. Par exemple, il peut déterminer le nombre d'instances de chaque rôle à exécuter, utiliser des files d'attente pour communiquer entre ces instances et effectuer presque toutes les autres actions possibles avec Windows Azure. Une fois l'application développée et testée localement, le développeur peut télécharger le code et ses informations de configuration, puis l'exécuter. Peu importe la façon dont elle est conçue, une application Windows Azure est généralement mise à disposition sur le cloud par le biais d'un processus en deux étapes. Un développeur télécharge d'abord l'application vers la zone de mise en lots de la plateforme. Lorsque le développeur est prêt à faire fonctionner l'application, il utilise le portail Windows Azure pour demander sa mise en production. Cette transition entre la phase de test et la production peut être effectuée sans temps d'arrêt, ce qui permet de mettre à niveau une application exécutée sans perturber ses utilisateurs. L'application testée possède un nom DNS du formulaire <GUID>.cloudapp.net où <GUID> représente un identificateur unique global affecté par Windows Azure. Pour la phase de production, le développeur choisit un nom DNS au sein du même domaine, comme par exemple myazureservice.cloudapp.net. Pour utiliser un domaine personnalisé plutôt qu'un domaine cloudapp.net de Microsoft, le propriétaire de l'application Windows Azure peut créer un alias DNS à l'aide d'un CNAME standard. Une fois l'application accessible au monde extérieur, ses utilisateurs peuvent nécessiter un moyen de s'identifier. Pour ce faire, Windows Azure permet aux développeurs d'utiliser le mécanisme d'authentification HTTP de leur choix. Par exemple, une application ASP.NET peut utiliser un fournisseur d'appartenances pour stocker son propre identifiant utilisateur et son mot de passe. Elle peut également utiliser une autre méthode, comme le service Microsoft Windows Live ID. Les applications Windows Azure peuvent également utiliser Windows Identity Foundation (WIF) pour mettre en œuvre une identité basée sur les demandes. Le choix revient au créateur de l'application. 19

21 ÉTUDE DU SERVICE DE CALCUL Au même titre que la plupart des technologies, le service de calcul Windows Azure compute a évolué depuis sa version d'origine. Par exemple, au départ, le code des rôles Web et de travail ne pouvait s'exécuter qu'en mode utilisateur. À l'heure actuelle, ils offrent tout deux une option de privilèges élevée, ce qui permet aux applications de s'exécuter en mode administrateur. Ces possibilités peuvent être utiles pour les applications nécessitant par exemple l'installation d'un composant COM, ce qui posait des problèmes dans la première version de Windows Azure. Toutefois, chaque instance d'un rôle Web ou de travail en cours d'exécution part de zéro : le système d'exploitation sous-jacent de son ordinateur virtuel est une image standard définie par Windows Azure. Cela signifie que toute installation de logiciel effectuée par le rôle doit l'être à chaque création d'une nouvelle instance. Cela ne pose aucun problème pour les installations simples, comme l'ajout d'un composant COM unique. Mais supposons que l'instance nécessite l'installation d'une vaste gamme de logiciels pour mener à bien son objectif. Si cette opération est effectuée à chaque création d'une nouvelle instance de rôle, elle peut s'avérer trop longue. À cet égard, les rôles d'ordinateur virtuel ont pour objectif principal d'éviter ce retard. Au lieu de requérir l'installation à chaque création d'une instance, les logiciels nécessaires peuvent être transférés sur un disque dur virtuel qui sera ensuite utilisé pour créer une instance de rôle d'ordinateur virtuel. Cette méthode peut s'avérer bien plus rapide que l'utilisation de rôles Web ou de travail dotés de privilèges élevés. Il peut également s'agir d'une solution appropriée lorsque le processus d'installation nécessite une intervention manuelle, ce que n'autorise pas Windows Azure. Une autre modification apportée par rapport à la version d'origine de Windows Azure est que la plateforme prend désormais en charge l'accès par le biais du protocole RDP (Remote Desktop Protocol). Cette prise en charge est utile au débogage, par exemple. Elle offre en effet au développeur un accès direct à une instance spécifique. Cependant, ne comptez pas exploiter cette méthode pour la technologie Virtual Desktop Infrastructure (VDI). Windows Azure n'est pas conçu pour prendre en charge ce type de scénario, du moins pour le moment. D'autres aspects importants du service de calcul Windows Azure compute sont disponibles depuis la première version du logiciel. Par exemple, Windows Azure permet au développeur d'indiquer dans quel centre de données une application doit être exécutée et à quel endroit les données doivent être stockées. Il peut également préciser qu'un groupe particulier d'applications et de données (données de SQL Azure comprises) doive résider dans le même centre de données. Microsoft distribue initialement les centres de données de Windows Azure aux États-Unis, en Europe et en Asie, avant de desservir les autres régions. ÉTUDE DU SERVICE DE STOCKAGE Pour utiliser le stockage de Windows Azure, un développeur doit d'abord créer un compte de stockage. Pour contrôler l'accès aux informations de ce compte, Windows Azure fournit une clé secrète à son créateur. Chaque requête faite par une application concernant les informations dans ce compte de stockage (blobs, tables et files d'attentes) comporte une signature créée avec la clé secrète. En d'autres termes, l'autorisation se fait au niveau du compte (même si les blobs possèdent une autre option décrite ultérieurement). Le stockage de Windows Azure n'offre pas de liste de contrôle d'accès ni d'autre moyen plus précis de contrôler les autorisations d'accès aux données qu'il contient. 20

22 Blobs Les blobs (binary large objects) répondent souvent précisément aux besoins d'une application. Qu'ils contiennent des vidéos, de l'audio, des messages électroniques archivés ou autre, ils permettent aux applications de stocker des données et de pouvoir y accéder de manière très générale. Pour utiliser les blobs, un développeur doit d'abord créer un ou plusieurs conteneurs dans un compte de stockage. Ensuite, chacun de ces conteneurs peut comprendre un ou plusieurs blobs. Pour identifier un blob particulier, une application peut fournir un URI de la forme suivante : <CompteDeStockage> est un identifiant unique attribué lorsqu'un compte de stockage est créé, <Conteneur> et <NomDuBlob> sont les noms d'un conteneur spécifique et d'un blob situés dans le conteneur. Il existe deux formes de blobs : Les blobs de bloc, chacun pouvant contenir jusqu'à 200 Go de données. Pour plus d'efficacité, un blob de bloc est divisé en deux blocs. En cas de défaillance, la retransmission peut reprendre avec le bloc le plus récent plutôt que d'envoyer le blob entier une nouvelle fois. Une fois les blocs de blob téléchargés, le blob entier peut être validé immédiatement. Les blobs de page, pouvant atteindre un téraoctet chacun. Un blob de page est divisé en pages de 512 octets. Une application peut lire et écrire des pages individuelles de manière aléatoire dans le blob. Peu importe le type de blobs qu'ils contiennent, les conteneurs peuvent être marqués comme privés ou publics. Concernant les blobs d'un conteneur privé, des requêtes de lecture et d'écriture doivent être signées à l'aide de la clé du compte de stockage du blob. Concernant les blobs d'un conteneur public, seules les requêtes d'écriture doivent être signées, n'importe quelle autorisation peut lire le blob. Cela peut être utile pour la création de vidéos, de photos ou d'autres données non structurées disponibles en général sur Internet. En fait, le réseau de distribution de contenu de Windows Azure ne fonctionne qu'avec des données stockées dans des conteneurs publics de blob. Autre aspect important des blobs : ils jouent un rôle dans la prise en charge des lecteurs Windows Azure. Afin de comprendre ce qu'est un rôle, il faut d'abord savoir que les instances de rôle bénéficient d'un accès libre à leur système de fichiers local. Cependant, par défaut, ce stockage n'est pas permanent. Lorsque l'instance est arrêtée, l'ordinateur virtuel et son stockage local disparaissent. En revanche, monter un lecteur Windows Azure peut donner à un blob de page l'aspect d'un disque local, disposant d'un système de fichier NTFS complet. L'écriture dans le lecteur peut se répercuter immédiatement dans le blob sous-jacent. Lorsque l'instance n'est pas en cours d'exécution, ces données sont stockées en permanence dans le blob de page, prêtes pour un nouveau montage. Les lecteurs peuvent être utilisés des manières suivantes : Un développeur peut télécharger un disque dur virtuel (VHD) comprenant un système de fichiers NTFS, puis monter ce VHD en tant que lecteur Windows Azure. Cela permet de déplacer les données de système de fichiers immédiatement entre Windows Azure et le système Windows Server local. 21

23 Un développeur de Windows Azure peut installer et exécuter un système de base de données MySQL dans une instance de rôle Windows Azure à l'aide d'un lecteur Windows Azure en tant que stockage sous-jacent. Tables Un blob est simple à comprendre : il ne s'agit que d'une dalle d'octets. La figure 14 illustre de quelle manière les parties d'une table correspondent. Table Table Table... Entité Entité Entité... Propriété Propriété Propriété... Nom Type Valeur Figure 14 : Les tables fournissent un stockage basé sur l'entité. Comme l'illustre la figure, chaque table comprend un certain nombre d'entités. Une entité comprend zéro ou plusieurs entités, chacune ayant un nom, un type et une valeur. Plusieurs types sont pris en charge, dont Bool, DateTime, Double, GUID, Int, Int64 et String. Une propriété peut prendre en charge plusieurs types à différents moments selon la valeur stockée. Toutes les propriétés d'une entité ne doivent pas forcément être du même type (un développeur peut choisir ce qui lui semble le plus logique pour son application). Quel que soit son contenu, une entité peut atteindre un mégaoctet et son accès est toujours considéré comme une unité. La lecture d'une entité renvoie toutes ses propriétés. L'écriture d'une entité peut remplacer toutes ses propriétés. Il est également possible de mettre à jour un groupe d'entités dans une table unique automatiquement, assurant que toutes les mises à jour s'effectuent ou non. Les tables de stockage de Windows Azure diffèrent des tableaux relationnels de plusieurs façons. La différence la plus évidente est qu'elles ne sont pas des tables au sens habituel. De même, on ne peut pas y accéder à l'aide de ADO.NET. Elles ne prennent pas non plus en charge les requêtes SQL. Les tables dans le stockage de Windows Azure n'appliquent aucun schéma. Les propriétés dans une entité unique peuvent 22