Now Reading
Rédiger un appel d’offre Cloud – 1 : Les critères de choix d’un modèle de déploiement de Cloud.
0

Rédiger un appel d’offre Cloud – 1 : Les critères de choix d’un modèle de déploiement de Cloud.

by Cloud Guru27 janvier 2013

Ca y est ! Vous êtes prêt. Votre DG vous l’a demandé, les directions métiers aussi : il faut aller sur le Cloud ! Même votre directeur financier vous en a parlé : il veut de l’Opex. Cela tombe bien, car votre contrat d’hébergement arrive à échéance, vous êtes en renouvellement de parc, une nouvelle application vient de tomber, et il faut trouver un support de déploiement. Vous allez devoir rédiger un premier appel d’offre comme consommateur de services Cloud.

Question Mark Key on Computer KeyboardMais quelles sont les bonnes questions à se poser ? Et vers quel modèle de déploiement souhaitez vous vous diriger ? Voici quelques tentatives de réponses, qui vous donneront les bases pour lancer votre appel d’offre.

Première question : la taille.

Dans l’arbre de décision, quelle est la taille de votre Cloud ? 10, 100, 500, 1000 machines virtuelles ? En général, le point d’inflexion se trouve autour de 200 à 300 machines virtuelles, fonctionnant en permanence. En effet, en dessous de 200 machines virtuelles, la pertinence d’un Cloud privé (au sens d’une infrastructure dédiée) est difficile à démontrer. Le coût de mise en œuvre plombe alors le ROI du projet. Au dessus de 300 machines virtuelles, le coût de mise en œuvre est couvert par le nombre de machines virtuelles.

Deuxième question : la variabilité.

Quel est mon besoin de variabilité ? Sur un Cloud privé, c’est à dire avec une infrastructure dédiée, vous ne disposez pas d’une grande variabilité.  C’est vous qui devrez payer les machines, même si l’ingénierie financière de montée en charge, voire d’activation de core à la demande vous permet une certaine variabilité.

Si vous envisagez un besoin de 500 VMs dans l’heure, orientez vous d’entrée vers le Cloud public. Et dans ce dernier cas, il faut savoir que le choix se réduit à quelques acteurs ayant des infrastructures suffisantes pour encaisser ce genre de demande.

Troisième question : la standardisation

Quel niveau de standardisation suis-je prêt à accepter ? Le mouton à cinq pattes est difficile à trouver dans le Cloud public. Par définition, le Cloud public est mutualisé et le catalogue de service n’est pas extensible à l’infini. A l’inverse, en Cloud privé, il est possible de demander au prestataire toutes sortes de personnalisations. En contrepartie les économies seront minimes. De même, en PaaS, si un composant MySQL peut être disponible chez un grand nombre de prestataire, une base de données DB2 le sera beaucoup moins.

Quatrième question : le type de Cloud

MP900438585De quelle couche de Cloud ai-je besoin ? Du pur IaaS, machine virtuelle, stockage et bande passante Internet ? Du PaaS avec des composants base de données ou serveur applicatif sur lesquels je pose mon code ? Du SaaS avec un paiement de mon ERP à l’utilisateur ? Ou bien encore du BPaaS, avec la  délégation  d’un processus métier (par exemple la formation de mes collaborateurs) ?

Cinquième question : le service.

De quel niveau de gestion du service ai-je besoin ? Il faut le noter, plus on monte dans les couches hautes (IaaS, PaaS, SaaS, BPaaS) et plus on délègue une partie du service au prestataire. Pour une prestation SaaS, l’aspect gestion de VM est complètement masqué.

Est-ce que je veux rester seul maître à bord ? Dans ce cas j’utiliserai le Cloud en mode self service, et je continuerai à assurer l’administration de mes machines virtuelles. Ou au contraire, est-ce que je veux me concentrer sur ma valeur ajoutée et laisser les tâches ingrates de mise à jour de l’OS Windows à un prestataire pour un service IaaS ? Attention, dans ce cas, c’est probablement le prestataire qui sera administrateur de mes VMs. Dans le cadre d’un PaaS, est ce que je veux continuer à faire les updates de composants SAP ? Ou au contraire confier cela à mon prestataire car je n’ai pas les compétences et que mon prestataire le fera mieux que moi ?

De même, il faut se poser la question de la gouvernance du service externalisé : gouvernance minimum voire inexistante, ou besoin d’un responsable de compte disponible 24H sur 24 au téléphone ?

Sixième question : la proximité

Quel est le niveau de proximité avec le SI dont j’ai besoin ? On tombe là sur un problème classique de réseau. La vitesse de la lumière est finie : un éloignement de ressources entraîne des temps de latence réseau incompressibles. Donc, si vous avez actuellement des baies de stockage directement attachées à vos serveurs, il est illusoire d’espérer les externaliser dans le Cloud. Vous n’aurez jamais les mêmes performances. Le Cloud privé s’impose.

Conclusion

Dans ce premier article, nous avons traité quelques points basiques : taille du Cloud, variabilité (faible,… importante), standardisation, couche d’abstraction ( IaaS, PaaS, SaaS, BPaaS), services associés (Cloud managé, non managé, niveau de gouvernance), éloignement du SI.

S’interroger sur ces points, et tenter d’y apporter des réponses, c’est déjà orienter votre réflexion au milieu d’une offre Cloud pléthorique, qui couvre aujourd’hui le IaaS, le public, le  privé, les infrastructures hébergées dans vos locaux ou externalisées.

Nicolas Berzin
Nicolas, fort d’une expérience de 10 ans dans l’IT développe actuellement les offres Cloud chez IBM. Au sein de l’entité offering des services IBM, Nicolas déploie les offres Cloud au sein d’IBM, chez les partenaires, chez les clients. Nicolas assure également le support aux ventes, le support à l’engagement, le business développement chez les clients. Nicolas assure la présence d’IBM dans différents événements public. Nicolas écrit et partage sur le thème du Cloud, les problématiques pratiques rencontrées en proposition client.

{lang: 'fr'}
About The Author
Cloud Guru

Vous souhaitez réagir sur cet article ?