La version de prévisualisation d'Azure permet aujourd'hui de monter jusqu'à deux instances ; dans la version finale, l'éditeur du logiciel déterminera librement le nombre d'instances dont il pensera avoir besoin - sachant que cela pourra évoluer à la hausse ou à la baisse. « Votre code sera capable de supporter la charge, quelle qu'elle soit », assure-t-on chez Microsoft. La seule contrainte sera la tarification. Celle-ci n'est pas encore finalisée, mais on sait déjà que comme toute offre de cloud, le coût grimpera en fonction des ressources utilisées. D'où l'intérêt, soulignent les architectes, de tout de même bien optimiser le code, pour qu'il consomme le moins de ressources possibles. L'application tournant dans Azure dispose de sa propre URL (avec une terminaison en cloudapp.net, qui peut être masquée à l'aide d'une redirection), et peut communiquer avec d'autres services accessibles en ligne, grâce aux protocoles Soap ou Rest. Des tables, des queues et des Blobs dans le « cloud storage » d'Azure Les données que l'application doit manipuler sont stockées dans le « cloud storage » d'Azure, qui peut prendre trois formes : des tables, des files d'attente de messages et des blobs (Binary large objects, containers pour stocker de gros fichiers binaires, comme des photos ou des vidéos). Chacun de ces formats dispose d'une URL distincte, permettant au développeur d'y accéder librement. Quelques outils, dont un est fourni en guise d'exemple dans le SDK d'Azure, donnent la possibilité de manipuler plus facilement ces données (dont le total est limité à 50 Go dans la 'preview'). Des traitements sur ces données peuvent être effectués de façon asynchrone, dans le nuage, « l'équivalent d'un traitement batch », précise Stève Sfartz. La grosse difficulté aujourd'hui concerne le débogage des applications. Certes, Azure dispose d'un mode 'préproduction', pour y faire tourner une application avant de la mettre en production, mais on ne peut y déboguer un programme. Il faut donc faire le maximum de tests en local, sachant que le SDK reproduit en local la « fabrique ». Dans ce cas, les données sont stockées dans une base SQL Express, mais il est possible de les charger dans Azure, et d'utiliser un outil tiers comme Fiddler pour examiner les flux, afin d'identifier les points de l'application posant problème. Autre limitation imposée aux développeurs : dans la mesure où Azure s'appuie sur la version 7 du serveur Web IIS de Microsoft, le travail de conception doit s'effectuer sur Vista ou Seven, XP n'étant pas compatible avec IIS 7. Au final, les choses sont donc plutôt claires, mais cela pourrait se complexifier à l'avenir, avec le support de langages natifs, et la possibilité de déployer dans Azure ses propres machines virtuelles.