A moins de ne pas avoir été connecté à internet ces derniers mois, un développeur travaillant sur les technologies Microsoft ne peut pas avoir évité toute mention de Windows Azure.
Cette plateforme dédiée au cloud computing (ou informatique dans le nuage) fournie par Microsoft a en effet été largement mise en avant au cours de l'année 2010, que ce soit dans les différents événements consacrés aux développeurs et autres professionnel de l'informatique, dans les blogs, ou dans des challenges divers et variés.
En parallèle, une évidence s'impose, bien que tout le monde en parle, assez peu de personnes ont effectivement utilisé la plateforme à ce jour, et un certain nombre d'interrogations subsistent au sein des équipes de développement.
Cet article (et les suivants) ont donc pour but de présenter, par petits bouts et de façon didactique, la plateforme Azure, et les différents concepts qu'elle recouvre.
Avant d'aborder Azure, on va brièvement parler de cloud (le terme anglais est utilisé à dessein, le terme français étant peu répandu).
Le concept de base du cloud computing est d'acheter, selon les besoins d'une application, du temps de calcul ou de l'espace de stockage à un tiers, et donc de déporter tout ou partie de la gestion et de la maintenance au tiers en question.
Les intérêts pour une entreprise sont les suivants :
baisse de charge de maintenance (passage des services pack, montées de version);
hausse de la scalabilité (facilité de montée et descente en charge, les serveurs et les licences étant gérés par le fournisseur);
disponibilité des ressources sur demande, sans intervention humaine nécessaire (il est possible d'augmenter ou diminuer le nombre d'instances à 3 heures du matin, en 5 minutes);
plus de nécessité d'investissement massif « a priori » (on n'achète plus un serveur physique et ses licences, mais juste du temps processeur et de l'espace disque);
service basé sur des standards au niveau de l'échange des données (permettant de faciliter la communication entre le service hébergé et des clients, quelle que soit la technologie des uns et des autres).
Une analogie que je trouve excellente (empruntée à Sriram Krishnan) pour le cloud computing serait un service tel que l'eau courante. Fournir de l'eau potable sans interruption de service nécessite une infrastructure énorme, et de très gros moyens, que ce soit pour le prélèvement, l'acheminement, le filtrage et la maintenance. Ce travail permet à l'utilisateur final de n'avoir plus qu'à ouvrir le robinet, consommer la quantité dont il a besoin, et fermer le robinet. Au final, l'utilisateur est facturé sur ce qu'il a consommé (avec le delta d'un éventuel abonnement), et a la garantie d'avoir toujours de l'eau potable. L'alternative serait le puits au fond du jardin, qui est "gratuit" à l'utilisation, mais qui demande à être creusé, nettoyé, entretenu, et qui peut éventuellement se boucher.
Dans ce type de service, le fournisseur met à disposition de ses clients un ou plusieurs serveurs. L'idée dans ce cas est de provisionner un nombre variable de machines, à la demande du client. Le client reste responsable de la maintenance logicielle des serveurs, mais n'a (en général) pas à gérer les licences du système d'exploitation, ni à acheter et maintenir le matériel.
Ce mode de fonctionnement est le descendant direct des offres de serveurs dédiés.
Un bon exemple de service IAAS est Amazon EC2, qui fournit des machines virtuelles à la demande. Il est à noter que, lors de la PDC 2010, fut annoncé un nouveau type de Role (nous en reparlerons plus tard), le VM Role, qui permettra, d'ici la fin de l'année 2010, d'utiliser Azure en mode IAAS.
Les services de type SAAS sont, eux, les descendants de ce qui s'appelait quelques années auparavant des ASP, pour Application Service Providers.
Ces services permettent aux clients d'accéder à une application à la demande, avec des coûts de mise en place, de maintenance et de développement qui sont assumés par le fournisseur, tout en permettant un temps de déploiement très court. De plus, la mutualisation des serveurs permet de diminuer le coût global pour le fournisseur, tout en augmentant la disponibilité.
Google fournit un nombre assez important d'applications en mode SAAS, au sein de Google Apps. La stratégie SAAS de Microsoft est représentée d'un côté par Office 365 (qui regroupe SharePoint, Exchange et Lync Online 2010, Office Web Apps et Office) et, de l'autre, par Microsoft Dynamics CRM.
Les services de type Platform As A Service ont comme vocation de fournir une plateforme.
Dans ce modèle, le client est uniquement responsable des applications qu'il va déployer, et le fournisseur de tout le reste. Ce modèle est le modèle d'origine d'Azure, et celui sur lequel nous allons passer le plus de temps dans cette série de tutoriels.
Azure est donc un représentant des services PAAS, tout comme Google avec Google App Engine, ou Heroku.
Suite à cette classification rapide, nous allons maintenant regarder rapidement comment Azure fonctionne.
III. Éléments constitutifs de la plateforme Azure▲
Au niveau le plus élevé, Azure peut être vu comme une simple plateforme applicative, qui va permettre d'héberger des applications dans un environnement Windows hébergé par Microsoft.
Cette plateforme est installée sur plusieurs DataCenters dans le monde, permettant de placer géographiquement les serveurs au plus proche des utilisateurs finaux.
Ceci étant dit, il est intéressant d'avoir une vue plus fine de ce qui compose la plateforme en elle-même. Lorsque l'on parle d'Azure, on englobe généralement les éléments suivants :
Windows Azure : Windows Azure est la plateforme en elle-même. On pourrait faire un parallèle entre Windows Azure et un ensemble de serveurs Windows Server
SQL Azure : SQL Azure va être le composant de gestion de données de la plateforme. De la même manière que Windows Azure serait Windows Server, on pourrait voir SQL Azure comme SQL Server
AppFabric : AppFabric est la partie de la plateforme qui va gérer les communications entre les différents éléments internes à Azure et la sécurité. Il fait office de composant de middleware (ou en français, de bus logiciel) pour la plateforme.
Dit comme cela, la présentation est un peu sèche. On va détailler les éléments de ces composants
La partie Fabric de Windows Azure permet de gérer les composants Storage et Compute.
Ce composant est constitué d'une collection de serveurs, chaque serveur faisant tourner plusieurs VMs, lesquelles vont être utilisées, selon les besoins, pour représenter une instance Compute ou Storage.
La Fabric contient un composant de contrôle (Fabric Controller), qui va se charger des opérations sur les VMs, que ce soit pour les provisionner, les libérer, ou les faire monter ou descendre de version.
La partie Compute de la plateforme est celle en charge de l'exécution du code.
Pour cela, le développeur doit créer un ou plusieurs rôles, qui vont, selon les besoins, se comporter comme un serveur IIS (Web Role), ou comme un service Windows (Worker Role).
Un troisième rôle fera son apparition d'ici la fin de l'année 2010, le VM Role, qui permettra d'obtenir une VM, basée sur un modèle choisi à la création.
Chaque Role tourne en fait dans une VM, qui peut éventuellement être répliquée, et un load balancer intégré à la plateforme permet de rediriger le trafic en interne de façon transparente pour les utilisateurs finaux.
Le but de la partie Compute est de permettre de rajouter de façon très simple des instances supplémentaires, de façon à pouvoir étaler la charge sur plusieurs Roles (Scale out)
La partie Storage, enfin, va permettre aux développeurs de stocker, dans une instance Azure, un jeu de données.
Ces données sont, par essence, non relationnelles, et peuvent se présenter sous trois formes différentes :
Blobs : les blobs sont l'équivalent, en terme de stockage, de fichiers dans le cadre d'un développement non Azure. Un blob permet de stocker un fichier et un ensemble de méta données qui se rapportent à ce fichier
Table : une table représente un ensemble d'entités, chaque entité ayant un ensemble de propriétés. Ces tables sont non relationnelles, et peuvent stocker des type hétérogènes
Queue : l'intérêt de la queue est principalement de permettre aux développeurs de gérer des communications asynchrones entre les différents composants de l'application. Par exemple, un Role va écrire dans une queue, et un autre lire les données écrites précédemment.
Drive : cette fonctionnalité permet de configurer l'équivalent d'un disque virtuel qui peut ensuite être utilisé comme un disque dur réseau par un Role Azure. Cette fonctionnalité est surtout prévue pour faciliter le portage d'une application existante sur le cloud, mais n'apporte que peu d'intérêt dans le cadre d'un développement qui vise spécifiquement Azure.
SQL Azure est un système de gestion de base de données dans le cloud, qui se base sur SQL Server 2008.
Dans les grandes lignes, utiliser SQL Azure revient à utiliser une base de données SQL Server, avec un coût de licence grandement diminué, et une couverture quasiment complète des fonctionnalités de SQL Server 2008.
Il est possible d'accéder à ces données de la même façon que l'on accéderait à une base de données SQL Server classique, que ce soit depuis des applications hébergées dans Windows Azure, ou depuis toute autre application capable de s'interfacer avec SQL Server.
En parallèle à SQL Azure, un ensemble d'outils sont en cours de développement, ou déjà disponibles, pour étendre les fonctionnalités de base d'un SGBD.
SQL Azure Data Sync permet de synchroniser les données entre plusieurs bases de données SQL Azure, à l'intérieur d'un Data Center, ou entre Data Centers (actuellement, il existe 6 Data Centers Azure dans le monde). Data Sync est actuellement en CTP1
SQL Azure Reporting devrait être disponible en fin d'année 2010, et fournir un équivalent dans le cloud à Reporting Services.
Comme dit précédemment, AppFabric, en tant que middleware de la plateforme, a principalement comme responsabilité la gestion du bus et du contrôle d'accès.
Ces composants permettent au final de gérer la communication entre les applications, qu'elles soient hébergées dans Azure ou sur site.
Le Service Bus permet d'exposer des services simplement, le bus se chargeant du routage des requêtes vers le service concerné.
Il permet, par exemple, de créer un point d'accès, exposé au travers d'Azure, à un service se trouvant dans le réseau de l'entreprise, ce qui permet un niveau d'indirection supplémentaire, les adresses locales n'étant pas visibles de l'extérieur.
Il supporte les connexions en full duplex, propose des accès au choix par REST, TCP ou HTTP, et supporte des accès aussi bien anonymes qu'authentifiés
AppFabric permet de gérer l'accès au Service Bus suivant des mécanismes standards tels que OAuth et les Simple Web Tokens (SWT) pour les services REST, ou encore des mécanismes à base de revendications de type SAML, WS-Federation et WS-Trust pour l'accès à des services SOAP.
Ce service permet d'authentifier des applications aussi bien hébergées par Azure que des applications hébergées dans les locaux d'une entreprise.
Dans ce cadre, supposons que l'on dispose d'une application nécessitant la fourniture d'un jeton d'authentification par ses clients. Cette application va fournir auparavant au contrôle d'accès les informations lui permettant de valider les identifiants du client, et de générer les jetons d'authentification
Le fonctionnement est le suivant :
L'application client envoie ses informations d'authentification sur un canal HTTPS, vers le contrôle d'accès
Le contrôle d'accès, après validation des informations d'authentification, renvoie un jeton d'authentification à l'application cliente
Finalement, l'application cliente envoie le jeton à l'application serveur, qui valide la signature du jeton
Je ne rentre volontairement pas plus dans les détails, la réalité du contrôle d'accès étant relativement complexe.
Le composant Caching fournit les mêmes capacités de cache que celles fournies par Microsoft Distributed Cache service, mais spécifique à Windows Azure. Cette fonctionnalité est disponible sans aucune configuration additionnelle.
Le Caching est encore en CTP pour le moment, et sera disponible début 2011 en production.
La partie Integration permettra d'utiliser, dans le cloud, un ensemble de fonctionnalités issues de BizTalk (pipeline, transformations, adaptateurs).
Integration inclut des fonctionnalités de monitoring des activités métier, et permet d'intégrer le Service Bus à des applications existantes.
Integration entrera en CTP dans le courant de 2011.
III-C-5. Composite App Service / Composition Model▲
Composite App Service et Composition Model fournissent un environnement de développement pour faciliter la création, la gestion et le déploiement d'applications composites.
Le Composition Model permettra aux développeurs de composer et de préparer le déploiement d'une application composite directement depuis Visual Studio
Composite App Service, de son coté, gérera les applications composites, permettant d'automatiser le déploiement, la gestion et le monitoring de ces applications de façon automatique.
Ces deux briques seront rendues disponibles en CTP courant 2011.
L'instance va déterminer l'espace disque disponible, ainsi que l'espace de stockage. Les instances sont actuellement disponibles en cinq formats :
Nom
Processeurs
Mémoire vive
Espace disque
Coût horaire
Extra small (XS)
1GHz
768 Mo
20 Go
0,05 $
Small (S)
1.6 GHz
1,75 Go
225 Go
0,12 $
Medium (M)
2 x 1.6Ghz
3,5 Go
490 Go
0,24 $
Large (L)
4 x 1.6 GHz
7 Go
1 000 Go
0,48 $
Extra large (XL)
8 x 1.6 GHz
14 Go
2 040 Go
0,96 $
Le coût horaire suit une courbe logique, l'unité de base de la plateforme étant les instances de type S, les instances suivantes sont en fait n instances de type S.
Les instances de type XS sont, elles, des instances S partagées entre deux instances XS. Il faut donc savoir que le processeur sera « équivalent » à 1 Ghz, mais que cette capacité n'est pas garantie.
En termes de stockage, le calcul se fait sur la quantité de données stockées, ainsi que sur les transferts.
La capacité est facturée à 0,15 $ par mois et par Go. Notez que l'on ne parle plus de l'espace disque de l'instance, mais de l'espace disque d'Azure Storage, qui n'a pas du tout les mêmes limitations de taille, et qui est persistant (les données stockées dans l'instance n'ont pas de garantie d'être toujours présentes ultérieurement).
Il faut ajouter à ceci les requêtes à destination du stockage. En effet, chaque requête de lecture ou d'écriture vers le storage est comptabilisée, pour une facturation s'élevant à 0,01 $ pour 10 000 requêtes.
Enfin, la bande passante est aussi comptabilisée, pour un coût de 0,10 $ par Go sortant, et 0,15 $ par Go entrant (0,30 $ et 0,45 $ pour la région asiatique). Attention, la bande passante interne à Azure n'est pas comptabilisée, tant que l'application et le storage sont sur la même localisation.
Le modèle de prix de SQL Azure est beaucoup plus simple à appréhender. En effet, il consiste en deux éditions, Web Edition, et Business Edition, basée sur la taille de la base de données.
Les bases de données Web Edition sont limitées à 5 Go, là où les bases de données Business Edition le sont à 50 Go par base.
Edition
Taille maximale
Coût mensuel
Web
1 Go
9,99 $
Web
5 Go
49,95 $
Business
10 Go
99,99 $
Business
20 Go
199,98 $
Business
30 Go
299,97 $
Business
40 Go
399,96 $
Business
50 Go
499,95 $
Les transferts de données sont facturés selon les mêmes tarifs que la bande passante pour Windows Azure (0,10 $/Go entrant, 0,15 $/Go sortant - 0,30 $/Go entrant, 0,45 $/Go sortant pour la région asiatique).
En dehors de la taille maximale, la seconde différence entre les deux éditions est que, dans le futur, des fonctionnalités supplémentaires (support de la CLR, partitionnement automatique, etc.) apparaitront dans la version Business.
La stratégie de facturation d'AppFabric est basée sur les connexions effectuées.
Le bus de service est facturé soit en pack (de 9,95 $ pour 5 connexions à 995 $ pour 500 connexions), soit au fur et à mesure de l'établissement des points de contact (3,99 $ par endpoint).
Les transactions sont facturées 1,99 $ pour 100 000 transactions, tandis que les transferts de données sont, une fois de plus, tarifés au même niveau que pour SQL Azure et Windows Azure.
En plus de ces offres de prix générales (avec paiement de la consommation au fur et à mesure), Microsoft propose aussi des offres spécifiques, qui peuvent être souscrites sous conditions.
Ces offres sont les suivantes:
Type de service inclus dans l'offre
Introductory Special (Gratuit)
Windows Azure Core (59,95 $/mois)
SQL Azure Core (74,95 $/mois)
Windows Azure and SQL Azure Extended(109,95 $/mois)
Abonnés MSDN Premium et Ultimate (inclus dans l'abonnement)
Windows Azure
Heures de petite instance
25
750
-
750
750
Stockage
500 Mo
10 Go
-
10 Go
10 Go
Transactions par mois
10 000
1 000 000
-
1 000 000
1 000 000
AppFabric
Connexions au bus
2
5
-
5
5
Transactions de contrôle par mois
100 000
1 000 000
-
1 000 000
1 000 000
Transferts de données
Europe et Amérique du Nord
500 Mo
7 Go entrant, 14 Go sortant
-
7 Go entrant, 14 Go sortant
7 Go entrant, 14 Go sortant
Asie Pacifique
500 Mo
2,5 Go entrant, 5 Go sortant
-
2,5 Go entrant, 5 Go sortant
2,5 Go entrant, 5 Go sortant
SQL AZure
Bases de données
1 Web Edition (1 Go)
-
1 Business Edition (10 Go)
1 Business Edition (10 Go)
3 Web Edition (1 Go)
Les offres Introductory Special, Windows Azure Core, SQL Azure Core et Windows Azure and SQL Azure Extended ont une durée limitée dans le temps. L'offre Introductory n'existera que jusqu'au 31 Mars 2011, tandis que les trois autres ne sont valides que pendant 6 mois après souscription (avec toutefois possibilité de renouveler une fois). Si vous êtes intéressés par ces offres, faites donc bien attention à ce que leur souscription implique.
V. Installation des outils de développement Azure▲
Les pré-requis pour développer des applications pour Azure en profitant de tous les outils de Visual Studio sont les suivants :
Système d'exploitation: Windows 7, Windows Server 2008, Windows Vista SP1
Environnement de développement: Visual Studio 2008 SP1 ou 2010 (toutes versions, dont les versions express)
IIS 7
SQL Server 2005 Express (ou plus)
La raison de la dépendance envers Windows Vista ou plus récent vient des possibilités de gestion de machines virtuelles, qui est nécessaire pour bénéficier de l'outil de gestion Local Fabric, qui permet d'émuler la Fabric Azure sur une machine de développement.
Développer des applications avec Azure et Visual Studio nécessite le téléchargement du SDK de Windows Azure.
Pour cela, on va commencer par se rendre sur le sitehttp://www.microsoft.com/windowsazure/
Ensuite, dans la rubrique « Get Started Now », on va cliquer sur « Get tools & SDK ». Ce lien va permettre le téléchargement du fichier VSCloudService, qui contient tout ce qu'il nous faut pour commencer.
Une fois le fichier téléchargé, il nous suffit de lancer son installation. L'installation en elle-même ne réserve pas de surprise.
Le processus d'installation va installer le SDK, mais aussi les outils de développements nécessaires pour produire des applications Azure. Il faut tout de même compter une dizaine de minutes pour l'installation complète.
Une fois l'installation complète, on peut voir un nouvel élément dans le menu de démarrage (en fait, trois, mais les dossiers Windows Azure Tools for Microsoft Visual Studio 2008 1.2 et Windows Azure Tools for Microsoft Visual Studio 2010 1.2 ne contiennent qu'un lien vers la documentation).
Le dossier Windows Azure SDK, lui, contient trois éléments intéressants.
Le Development storage permet d'émuler en local le composant Storage de la plateforme.
Il va donc permettre de manipuler localement des Blobs, des Queues, et des Tables Pour cela, il va se baser, par défaut, sur SQL Server Express.
Si la machine de développement ne dispose pas de SQL Server Express, il est possible de configurer le Development Storage pour accéder à une instance SQL Server, en utilisant, dans l'invite de commande de Windows Azure (Windows Azure SDK Prompt) la commande DSInit.
Cette commande est normalement appelée durant l'installation. Si on l'appelle sans arguments, elle va tenter de créer une nouvelle instance sur l'instance locale de SQLExpress, ce qui va générer une erreur. Dans le cas où mon instance locale de SQL Server s'appelle MonInstance, il faudra donc appeler la commande DSInit ainsi : Si on utilise l'instance par défaut, on remplacera le nom de l'instance par un point Et l'installation, cette fois ci, fonctionnera correctement
Le logiciel Development Fabric permet d'émuler, en local, le composant Fabric de Windows Azure.
En effet, il va permettre de gérer la génération de machines virtuelles, qui vont représenter nos Roles (Worker ou Web). Dans son état initial, il est vide, mais permettra de visualiser chaque machine virtuelle créée lors d'un déploiement local.
Nous reviendrons plus en détail sur cet outil lorsque nous aborderons le développement, vu qu'il nous permettra de visualiser les déploiements.
Cet article d'introduction vous aura permis, je l'espère, d'avoir une vue un peu plus claire sur les possibilités, à très haut niveau, de la plateforme.
Les articles suivants aborderont en détail les types de rôle, et le système de stockage. Ensuite, on verra comment déployer un service WCF dans Azure, et comment migrer une application ASP.Net existante sur la plateforme Azure.
