XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« Les tarifs Microsoft Azure encore brumeux | Accueil | Les tarifs Microsoft Azure encore brumeux »

07 septembre 2009

Les tarifs Microsoft Azure encore brumeux

Les tarifs Microsoft Azure encore brumeux

Microsoft_azure Avec l'heure de machine virtuelle (VM) à 0,12$, le Go de bande passante à 0,10$ (entrant) et 0,15$ (sortant) et le Go stocké à 0,15$, les tarifs de la plate-forme de cloud computing de Microsoft sont dans le peloton des leaders du cloud computing.

Mais il reste deux régions brumeuses dans cette grille de tarification, toutes les deux liées au flou de la définition d'une heure de VM.

Quelle puissance de calcul ? 

Le premier coin de brume intéresse ceux qui (comme moi) voient le cloud comme un moyen super pratique de faire des calculs à outrance en calculant en 40 heures sur cent machines virtuelles pour 480$ ce qu'ils pensaient devoir obtenir en une année sur les PCs de la famille confisqués aux enfants (ou aux parents pour les jeunes geeks).  

40 heures sur cent machines, vous allez me dire, c'est beaucoup. Pas sûr : de quelle heure parle-t-on ?

S'agit-il d'une heure de vieux processeur mono-coeur à 1.2GHz, de Netbook tout juste capable de supporter Chrome comme celui sur lequel je tape ce texte, voire d'une GameBoy, ou bien au contraire d'un processeur qui traverse allègrement le plafond des 4GHz ? Sans cette précision on reste dans le brouillard, l'estimation d'un budget de calcul intensif est aussi réaliste que la pêche à la ligne dans Animal Crossing, best-seller Nintendo qui prouve formellement que les enfants peuvent se passer de PC (les jeunes geeks peuvent occuper leurs parents avec un bon bouquin sauf bien sûr s'ils ont des parents geeks).

En fait la brume se lève rapidement, et la réponse, bien qu'approximative car non contractuelle, est connue : une VM du cloud Azure équivaudrait à un processeur AuthenticAMD cadencé à 1.3-1.5GHz et équipé de 2Go de mémoire vive (1,7Go accessible à l'application). Avec ça on peu déjà estimer à la louche, et même comparer avec les concurrents. En ne prenant en compte que la fréquence du processeur -- moyennée à 1.4GHz, on montre qu'Azure a pour le calcul intensif un très léger handicap sur Google AppEngine (GAE) qui vend l'heure d'Intel 1.2GHz à 0,10$ car le coût de l'instruction Azure dépasse le coût de l'instruction GAE. En gros bien sûr, il y aurait d'autres points de comparaison à prendre en compte

Néanmoins les chiffres publiés restent du domaine du marketing, pour trancher une bonne mesure in situ s'impose. Donc cher lecteur si vous possédez vos propres benchmarks je pense qu'on serait nombreux à les apprécier, je les partagerai ici avec plaisir.

Voilà pour le calcul intensif.

Purée de pois sur les applications Web

C'est au tour des développeurs Web (comme moi) de se poser une autre question : "Combien me coûtera mon prototype en cours de développement ? Et quels frais aussi, palsembleu, pour mon petit site à faible trafic ?". Notez au passage le style geek typique de la question.

Question qui renvoie au coût de l'heure de VM à 0,12$. Mais quoi. Mon application, perdue dans l'immensité du Web et tout juste sollicitée par Googlebot et ses confrères, va-t-elle me coûter autant qu'une application qui tire sans discontinuer sur le CPU ? Est-ce qu'un serveur Web juste prêt à répondre à des requêtes http vaut aussi 0,12$ de l'heure ? Est-ce que, vu d'un processeur, être prêt à travailler, c'est déjà travailler ? 

En termes de CO2 dégagé ça serait assez injuste. 

Et au delà -- plutôt très en deçà -- des problèmes de la planète,  il y a de quoi être inquiet pour la facture si l'on calcule qu'un mois de machine virtuelle destinée à servir des pages Web à moi et à mes amis (les bots) va me coûter 0,12$/h x 24 heures x 30 jours = 86,4$ par mois. Argh, plus cher que le moins compétitif des hébergeurs .Net. Pire, le prix minimum serait en réalité le double parce qu'une application minimale met en oeuvre deux "rôles" (Web + Worker), rôles facturés 24h/24.

190$ par mois minimum !


Si c'était le cas, Azure ne serait scalable qu'en multiple de VM, pas en fraction. Techniquement on peut le comprendre en considérant qu'Azure ne prévoit pas de partager les VM sous-utilisées. C'est ce qui fait dire à certains observateurs (Cf. Azure minimum hosting price??) qu'Azure, en l'état, ne s'adresse qu'aux besoins en calcul intensif des entreprises, pas aux développeurs. 

Conséquence fâcheuse pour Microsoft, entre GAE et Azure il n'y a pas photo, les développeurs Web gagnent à développer pour GAE qui est gratuit pour les petits projets

Pour le moment car Steve Marx, de l'équipe Azure, nous promet qu'il s'agit là de tarifs temporaires :

"To everyone, we do hear the desire to have an inexpensive option for applications with small load (or for experiments). We definitely share this goal, and we'll continue working towards that in a variety of ways."


A suivre donc...

TrackBack

URL TrackBack de cette note:
http://www.typepad.com/services/trackback/6a00d8341c871f53ef0120a5a78f88970c

Listed below are links to weblogs that reference Les tarifs Microsoft Azure encore brumeux:

Commentaires

Je pense qu'il est clair que MS ne vise pas les petits sites comme les nôtres :( . Il n'y a rien à gagner. La cible c'est les gros site (pour le web) de e-commerce qui ont besoin de perf variable en fonction d'évènements comme noël. C'est assez bluffant de ce dire que il n'y aura plus a ce prendre la tête à savoir si le site va tenir pour les commandes de noël. La puissance devrait varier quasi automatiquement pour ne plus avoir de DOS. Et ça, cela un coût mais il est bien nécessaire ;)

C'est vrai que c'est un super service pour les gros sites.

Mais à chaque fois qu'un développeurs Web s'amourache de Google AppEngine durant son passe-temps du dimanche, c'est un développeur .Net en moins et un prescripteur GAE de plus au boulot.

Il y a gros à perdre pour MS : les développeurs puis les entreprises. Je ne comprendrai pas qu'ils ne réagissent pas.

L'utilisation des commentaires est désactivée pour cette note.