Aller au contenu principal

Stratégies – Les contrats élastiques

9 août 2014

Arnaud Alcabez

Stratégies – Les contrats élastiques

elastique1Au moment où Microsoft annonce par la voie de son PDG1 l’alignement de ses centres de données afin de connecter massivement des objets intelligents en présentant en beta limitée « Azure Intelligent Systems Service » pour s’ouvrir au marché prometteur de l’intelligence ambiante dont nous aurons l’occasion de reparler, il convient de comprendre de la grande difficulté qu’auront les entreprises à s’abonner à ce type d’environnement.

Le problème que les entreprises rencontreront n’est pas tant lié à la technologie, mais aux formalités nécessaires pour modéliser un service basé sur les propositions de consommation « as a service » par les éditeurs du Cloud Computing. Nous allons ensemble essayer de comprendre pourquoi dans cet article.

Le monde de demain dessiné par Satya Nadella, CEO de Microsoft

elastique2

Comprendre les types de location d’instances

Dans le Cloud Computing, au niveau des services d’infrastructure à la demande, les fournisseurs proposent plusieurs modèles de facturation :

  • L’utilisation ponctuelle de ressources (appelée généralement « on demand ») couverte par un niveau de service (ou « Service Level Agreement » en anglais), mais sans engagement contractuel, ce qui veut dire que vous êtes libre de mettre fin à l’utilisation des ressources sans accord de réciprocité,
  • L’utilisation prévisionnelle de ressources, généralement sur un engagement contractuel d’une année ou de trois années,
  • L’utilisation en appel d’offres (ou « BID » en anglais). Ce modèle est proposé par de très rares fournisseurs, mais peut s’avérer fort pratique à l’usage. Pour ceux qui ne sont pas familier avec ce terme, le prix bid (ou BID) est le prix le plus élevé qu’un acheteur (ou le soumissionnaire, autrement dit vous) est prêt à payer pour un bien (http://en.wikipedia.org/wiki/Bid_price). Ainsi, basé sur un système proche des échanges boursiers, le BID est le prix maximum que vous souhaitez payer pour des ressources. Le fournisseur quant à lui calcule dynamiquement un prix de vente « déstocké » des ressources physiques non utilisées sur son centre de données. Si le prix de vente descend en dessous de votre BID, les instances vous seront automatiquement allouées. Si le prix de vente remonte au-dessus de votre BID, les instances vous seront automatiquement reprises dans les secondes qui suivent.

Par exemple, partons du principe que vous avez besoin d’une instance pendant un an pour faire un traitement :

  • Première option : Vous initialisez une instance « ponctuelle ». Bénéfices : pas de contrat, pas d’engagement, si votre traitement se termine plus tôt, stoppez l’instance pour arrêter toute facturation. Le problème : Ce genre de consommation étant imprédictible pour votre fournisseur, l’instance vous sera facturée au tarif horaire le plus fort. Dans notre cas, imaginons que ce soit de 100€ HT de l’heure,
  • Deuxième option : Vous savez estimer à l’avance la puissance de la machine qu’il vous faut. Dans ce cas, réservez-là pour une période maximale donnée. Ainsi, en ayant la maîtrise de la capacité de charge planifiée (ou « Capacity Planning » en anglais), vous aurez alors la possibilité de bénéficier de tarifs négociés. Ceux-ci peuvent s’avérer très avantageux sur le coût de votre traitement selon le scénario, vous permettant d’obtenir des remises pouvant atteindre ou dépasser 40%. Ainsi, pour le même traitement, notre instance à 100€ HT ne nous coûtera plus que 60€ HT de l’heure,
  • L’appel d’offre permet encore d’aller plus loin : Introduisez une option d’achat pour la même ressource que vous désirez à un montant de 10€ HT de l’heure. Dès que le fournisseur atteint cette valeur, vos instances vous seront allouées à ce coût. Bien sûr, vous devez partir du principe de faire une offre réaliste, faute de quoi, les instances ne vous seront jamais allouées, et votre traitement ne sera jamais lancé. Ainsi, la demande d’instances en appel d’offre doit être réalisée en renfort d’un traitement instancié sur des instances ponctuelles ou des instances réservées.

Vous me direz, à quoi cela peut servir ? Si vous n’êtes pas familier avec le Cloud Computing, il est nécessaire de comprendre un autre concept : celui qui fait que vous ne payez que ce que vous consommez : Par exemple, si un traitement dure 4 heures et qu’il est possible de le paralléliser, que vous exécutiez la même instance pendant 4 heures ou que vous exécutiez 4 instances pendant 1 heure, cela vous sera facturé au même prix. Imaginons que pour ce même traitement, vous puissiez l’accélérer en rapidité d’exécution grâce au renfort de petites instances très économiques et facturées que 10% de votre instance par défaut : Non seulement votre traitement sera fini beaucoup plus tôt que prévu, mais en considérant que vous pourrez utiliser ces instances négociées pendant une heure, votre traitement vous sera facturé 100€ HT + 3 x 10€ HT, soit 130€ HT, au lieu de 400€ HT (le coût de 4 instances ponctuelles d’une heure).

Pour les instances réservées, comprendre le temps d’usage moyen sur la période

Ne concernant que la réservation d’instances, un deuxième élément est à prendre en considération : le temps d’utilisation pendant la période contractée (soit d’un an, soit de trois ans). Ainsi, ce paramètre est un élément important de gains sur la facturation. Généralement, le fournisseur vous proposera un modèle adapté en fonction du temps moyen d’utilisation sur l’année :

  • Si vous pensez que vous utiliserez votre instance entre 0 et 30% (le reste du temps, l’instance est arrêtée), le fournisseur vous orientera vers une instance ponctuelle ou une instance BID,
  • Si vous pensez que vous utiliserez votre instance entre 30% et 50% (le reste du temps, l’instance est arrêtée), le fournisseur vous orientera vers une instance réservée, avec un usage léger,
  • Si vous pensez que vous utiliserez votre instance entre 50% et 85% du temps, le fournisseur vous orientera vers une instance réservée, avec un usage moyen,
  • Enfin, si vous pensez que vous utiliserez votre instance entre 85% et 100% du temps (en fait, l’instance est active toute l’année, 24/7/365), le fournisseur vous orientera vers une instance réservée, avec un usage élevé.

Cette compréhension de l’usage moyen (qui n’a rien n’à voir avec la notion de performances ou de puissance de l’instance), est cruciale pour la maîtrise de votre facturation :

  • En cas de surcapacité, les heures supplémentaires vous seront systématiquement facturées au tarif horaire des instances ponctuelles,
  • En cas de sous-capacité, vous payerez votre loyer selon le temps moyen négocié, et les heures non consommées ne pourront être reportées au crédit lors du renouvellement de contrat,
  • Si une baisse tarifaire était appliquée au coût horaire de l’instance, vous ne pourriez en bénéficier sur la base du contrat que vous avez engagé,
  • Vous ne pouvez changer de puissance pendant la durée du contrat. Comprenez que si vous avez besoin de plus de puissance, vous devrez rajouter à votre traitement des instances supplémentaires pour absorber la charge (soit avec une nouvelle réservation, soit sans contrat avec des instances ponctuelles).

elastique3Ainsi, le bon équilibre économique entre ce que vous consommez, ce sur quoi vous vous engagez, et ce qui vous sera facturé est parfois subtil, et demande d’y réfléchir à deux fois avant de s’engager : c’est-à-dire de passer dans un mode contractuel de réservation. Pour éclairer mes propos, voici un petit exemple des bénéfices ou des inconvénients sur un engagement contractuel :

Le tableau « Reserved instance cost savings over on-demand » montre clairement la différence entre chaque modèle (ponctuel, réservation légère, moyenne et élevée). Selon le scénario, le choix que vous ferez peut s’avérer très économique (en vert) ou très cher (en rouge) à la facturation.

D’ailleurs, généralement, un bon fournisseur de Cloud Computing vous suggéra systématiquement de commencer votre architecture sans engagement, avec des instances ponctuelles, pour vous laisser le temps de réfléchir à l’optimisation financière de votre ligne de service.

Internet des objets et contrats élastiques du Cloud Computing : Soyez le patient médiateur entre votre DAF et votre service juridique

Si vous avez tenu bon jusque-là, et que vous n’avez pas eu, à un moment de votre lecture, une envie pressante de passer à l’excellent article de mon confrère de la page suivante, nous allons pouvoir passer à un exemple concret.

Commençons pour changer par présenter le graphique d’une journée type reproductible sur une année entière, en bref, une application que je qualifierai de non complexe :

elastique4Comme vous le savez, de nouveaux objets connectés sont créés tous les jours : Par exemple, depuis le 1er Avril 2014, les tickets restaurant utilisés dans certaines entreprises seront progressivement remplacés par des cartes à puce numérique (http://lentreprise.lexpress.fr/remuneration/ticket-restaurant-numerique-ce-qui-va-changer_42251.html). En bref, en avril 2019, les tickets « papier » ne seront plus valables sur notre territoire et auront disparu.

Voici donc le pic représentatif d’une journée : l’activité maximale étant réalisée dans une fenêtre de temps très réduite, et principalement entre 11h et 15 heures, soit l’heure du déjeuner pour la majorité des salariés.

L’architecture utilise un concept important du Cloud Computing : l’adaptation à la charge : De manière simplifiée, plus on a de charge, plus on ajoute des instances pour l’absorber. Quand la charge diminue, on supprime des instances pour réduire les coûts.

  • Pour des questions de continuité du service et de redondance, j’ai considéré que je devrais laisser au moins deux instances fonctionner en 24/7. Ces deux instances feront partie d’un contrat d’engagement sur la période sur la base d’une réservation à usage élevé (elles fonctionnent entre 85% et 100% du temps maximum du contrat) – en gris dans le schéma,
  • L’activité devient plus importante au cours de la journée. A partir de 6 heures du matin, et jusqu’à 19 heures le soir, je démarre deux autres instances de renfort. Considérant qu’elles ne fonctionnent qu’une partie de la journée, je regarde le temps de non utilisation : au moins 25%. J’en conclus donc que ces deux instances feront partie d’un autre contrat d’engagement sur la même période sur la base d’une réservation à usage moyen – en orange dans le schéma,
  • L’activité devient beaucoup plus intense plus la journée défile. Je démarre encore une autre tranche de deux instances entre 9 heures et 17 heures. Considérant le temps où elles ne sont pas actives, j’en conclus que ces deux nouvelles instances me reviendront au meilleur tarif si je les intègre à un troisième contrat : réservation à usage léger – en rouge dans le schéma
  • Enfin, comme on dit en cuisine, voici venue l’heure du coup de feu. Je vais appel à des instances ponctuelles pour absorber le surplus d’activité. Pourquoi ponctuelles ? Parce que leur usage sur la journée sera inférieur à 6 heures, et me reviendront moins chères que de les prendre en réservation.

Au final, par rapport aux 13 instances que j’aurais dû engager pour absorber la totalité de ma charge, je ne paierai en fin de mois que pour les heures où j’ai besoin de ressources. Si vous regardez maintenant l’espace libre de mon graphe où je ne paierai rien, car je ne consomme pas, j’aurais allégé ma facture globale de presque…. 80%.

Allez, avec des chiffres c’est mieux : En ne jouant pas avec les contrats d’engagement, imaginez que mon architecture me revienne à 25.000€/an. En jouant avec les contrats, et en optimisant financièrement la consommation de mon environnement, la même solution ne me coûtera plus que 5.000€/an. Une sacrée différence, non ?

Le contrat élastique (les contrats) – Un passage obligé vers le monde de l’Internet des objets et du Big Data

Le modèle informatique (non transactionnel) duquel nous venons ne nous a pas préparé à considérer le contrat comme un élément fondamental pouvant influer sur l’architecture et le design de l’application. Toutefois, celui de demain, composé d’applications tirant parti de l’analyse massive de données ou de l’échange numérique d’objets de formes et de fonction diverses, risque de bouleverser vos fondamentaux, et faire de vous un architecte devant prendre en compte des nouveaux facteurs structurants, tels que la dimension économique et contractuelle de votre application.

Vous vous ferez alors un nouvel ami : votre directeur administratif et financier. En espérant qu’il vous aidera lorsque vous devrez aller expliquer votre modèle contractuel à la direction juridique de votre entreprise, qui certainement, sera beaucoup moins élastique que vous.

1 Annonce de Microsoft sur le support des objets intelligents dans Windows Azure : http://blogs.technet.com/b/microsoft_blog/archive/2014/04/15/a-data-culture-for-everyone.aspx

Pour IT Pro Magazine, 2014

Les commentaires sont fermés.

%d blogueurs aiment cette page :