Serveurs : le grand bazar de la tarification logicielle

Serveurs : le grand bazar de la tarification logicielle
 

Puces multic?"urs, mode hébergé... Il faudra bientôt une règle à calcul pour estimer sa facture logicielle, car chaque éditeur a sa façon de procéder.

Toujours plus performant, toujours moins cher. Des années que le matériel informatique baigne dans ce cercle vertueux. Les serveurs en particulier. Et tout le monde y gagne. Mais un grain de sable vient aujourd'hui gripper la mécanique. Arc-boutés sur un modèle de licence d'un autre âge, les éditeurs de logiciels d'infrastructure laissent planer de drôles d'incertitudes sur la facture logicielle. Si l'on n'y prend garde, une simple mise à jour matérielle suffira pour voir doubler, tripler, voire décupler les coûts de maintenance. Et si l'idée vient à un responsable informatique de virtualiser son infrastructure, ce sera pire : la facture pourra littéralement exploser. Des projets de consolidation jusqu'ici rentables verront donc leur économie évoluer... dans le mauvais sens.Comment en est-on arrivé là ? Tout est parti d'un malentendu sur l'évolution des processeurs. Il y a encore quelques années, un serveur n'accueillait qu'une application. Et son fournisseur la facturait selon la puissance totale de la machine. L'indice de performance retenu était alors le nombre total de processeurs, comme pour les grands systèmes. L'utilisateur pouvait changer de processeur, passer d'un modèle à 2, puis 3 GHz, sans que cela impacte sa facture de maintenance, tant qu'il conservait le même nombre total de processeurs. Et tout le monde semblait se satisfaire de cette méthode.

Les éditeurs flairent l'aubaine

Mais, comme souvent, une avancée technologique a changé la donne. Face aux problèmes de surchauffe que posait la montée en fréquence de leurs processeurs, les fabricants ont trouvé un autre moyen d'augmenter la puissance : installer plusieurs c?"urs de processeurs au sein d'une même puce. C'est si efficace que tous les processeurs pour serveurs proposent aujourd'hui au moins deux c?"urs. Sun a même lancé un Utrasparc accueillant huit c?"urs, et bientôt seize.Flairant l'aubaine, les éditeurs ont choisi de considérer cette évolution comme une multiplication du nombre de processeurs physiques. Ils ont donc rapidement adapté leur modèle de licence pour considérer chaque c?"ur comme un processeur distinct. L'argument est simple : avoir deux c?"urs double la puissance, et donc la capacité totale du serveur et le nombre d'utilisateurs potentiels. Dès lors, il semble normal de doubler aussi le prix de la licence. Pourtant, chacun sait que passer au bic?"ur ne double jamais les performances globales. Les entrées/sorties et la mémoire ont aussi leur importance. Et si les éditeurs voulaient facturer à la puissance de la machine, pourquoi n'ont-ils jamais facturé l'évolution des mégahertz ?Devant la pression de l'industrie (lobbying d'Intel et d'AMD, des grands utilisateurs et des analystes), les éditeurs ont fini par mettre un peu d'eau dans leur vin. Microsoft a montré la voie en gommant la notion de c?"ur pour ne compter que les processeurs physiques, comme avant. Il sera rejoint par Novell, Red Hat, VMware, et par BEA, qui vient d'abandonner sa ' taxe ' de 25 % sur le multic?"ur. Mais IBM et Oracle n'en démordent pas : un c?"ur reste un processeur. Tout juste ont-ils récemment consenti à indexer leur licence sur un coefficient multiplicateur, censé représenter la puissance relative dudit c?"ur (voir encadré). Problème : cette nouvelle table de correspondance s'appuie sur un indice de performance arbitraire, fixé par le fournisseur lui-même.

Une mesure universelle serait la bienvenue

Un exemple : les actuels serveurs Opteron et Xeon bic?"urs pourront bientôt troquer leurs puces contre des modèles quadric?"urs. Si l'on s'en tient à la table actuelle, il faudra multiplier le nombre total de c?"urs par 0,5 pour trouver le nombre de licences requises. Du coup, là où un serveur bic?"ur ne nécessitait qu'une licence, la mise à jour des puces en quadric?"ur oblige à se mettre en conformité en doublant le nombre de licences. Difficile à avaler pour qui veut dépoussiérer un vieux serveur !Mais il y a pire. Cette nouvelle façon d'indexer les licences a le bon goût d'empêcher toute comparaison entre les différents acteurs. Elle peut, en outre, être révisée à tout moment. IBM et Oracle la mettront ainsi à jour à chaque arrivée de nouveau processeur. A commencer par le Xeon quadric?"ur, attendu d'ici à la fin de l'année. ' Tout dépendra de ses performances, explique Patrice Poiraud, responsable des logiciels serveurs chez IBM. Rien ne dit que nous lui appliquerons le coefficient 0,5 par c?"ur, comme le suggère le tableau actuel. 'Donc, non seulement il devient difficile de prévoir le montant de sa facture logicielle quand les processeurs auront huit ou seize c?"urs, mais les fournisseurs attendront aussi le dernier moment pour annoncer les règles du jeu. L'information est pourtant essentielle, car c'est probablement le coût des licences qui départagera un monoprocesseur quadric?"ur, un biprocesseur bic?"ur et un quadriprocesseur monoc?"ur. Une unité de mesure indépendante et universelle de type Mips serait donc la bienvenue.Cette incertitude concerne aussi Microsoft. Aujourd'hui, il joue les premiers de la classe avec une politique de licence simple et avantageuse pour l'utilisateur. Mais rien ne garantit qu'il sera aussi magnanime sur les prochaines versions de SQL Server ou de Windows. On se souvient comment le challenger Windows NT avait marqué les esprits avec ses licences illimitées... puis comment Windows 2000 s'est rattrapé.

Seule solution, négocier !

L'incertitude atteint son paroxysme avec la technologie de virtualisation. Car aucun modèle de licence ne prend en compte de façon spécifique ces environnements. Du coup, c'est encore la facturation au nombre maximum de processeurs/c?"urs potentiellement utilisables qui prévaut. Résultat : si l'on découpe un gros serveur 64 processeurs en plusieurs machines virtuelles, il faudra payer plusieurs fois le système d'exploitation et les applications... pour les 64 processeurs. Même si l'on n'en utilise qu'une fraction ! De quoi anéantir toute velléité de mettre en place une infrastructure ' à la demande ' ou, pire, inciter à être moins regardant sur sa conformité en nombre de licences.Le problème est exacerbé par le manque d'outils qui aident à suivre avec précision ce qui se passe dans les machines virtuelles. HP et IBM proposent bien des solutions. Mais difficile d'accepter d'être audité par celui qui établit la facture finale. Seule façon, donc, de réduire sa note : négocier avec son fournisseur. Ce qui n'est pas toujours évident pour une PME, et même pour un grand compte qui achète peu de logiciels d'infrastructure.Ainsi devient-il urgent d'inventer de nouveaux modèles de licence qui s'alignent enfin sur l'évolution technologique, et plus seulement sur l'opportunisme ou le modèle économique des éditeurs. Car l'innovation ne ralentit pas. Un jour, des processeurs massivement multic?"urs, comme le Cell d'IBM, deviendront la norme. Les processus parcourront les réseaux à la recherche de ressources sur lesquelles s'exécuter. Des grilles de calcul seront partagées par plusieurs entreprises. Il serait dommage que ceux qui adoptent les dernières technologies se retrouvent piégés au jeu des licences.