kokou Agbedanou

Cas d’utilisation

1. Cas d’une PME/PMI

Dans le premier cas, une entreprise utilisatrice classique souhaite créer son cloud privé pour héberger ses
applications (messagerie, ERP, comptabilité et CRM) et ne dispose pas d’équipe IT ; il lui faudra acheter les
infrastructures matérielles (serveurs, routeurs, firewalls...) et les amortir généralement sur cinq ans. Il lui
faudra également acheter des licences logicielles (hyperviseur, orchestrateur pour la partie IaaS et
applicatif pour la partie métier) si ces licences ne sont pas assimilées à des souscriptions annuelles. Côté
frais de fonctionnement, l’entreprise devra imputer les actifs suivants : licences logicielles en cas de
souscription, maintenance des licences achetées en investissement et maintenance matérielle.

Cela représente des coûts importants en one-shot ainsi que du délai d’approvisionnement et il faudra
ensuite demander à un intégrateur d’installer la solution et à un mainteneur de la maintenir.

Sans compétences IT, il n’y a aucune raison (et c’est probablement pour cela que le cloud privé ne
s’impose pas en France dans les entreprises utilisatrices car il n’y a tout simplement pas de use cases)
que cette entreprise se lance dans ce processus fastidieux.

Le cloud privé à base de IaaS n’apporte rien dans ce cas et il est plus sage de recourir à deux autres types
de solutions :

ˇ
Le cloud public,
ˇ
L’installation traditionnelle sous forme de virtualisation.

Dans cet exemple qui est très fréquent, il s’agit de solutions de type "legacy" (solution héritée du passé
mais toujours en vigueur), qui ont besoin de disponibilité mais pas vraiment de scalabilité ni de paiement à
l’usage... Il faut donc exclure de l’éligibilité au cloud privé les applications legacy qui seront réservées à
une infrastructure traditionnelle.

2. Cas des grands comptes

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -1-
 kokou Agbedanou

Les grands comptes (plus de 1000 personnes) disposent d’un parc applicatif riche et d’une DSI très
souvent organisée en deux départements :

ˇ
La production (hébergement, système, réseau, télécommunication, téléphonie IP, sécurité,
messagerie...),
ˇ
Les études et développements (développement d’applications "maison", paramétrage et
maintenance des progiciels métier).

Il est tout à fait envisageable de bâtir un cloud privé à base de IaaS avec un catalogue de services
applicatifs qui sera mis à disposition des clients internes (les collaborateurs) et des clients externes.

En cas de débordement pour des machines de test ou de développement, il est préférable de prendre une
location sur un cloud public.

Exemple de solution sur un cloud public (OVH, tarif janvier 2015)

ˇ
Location d’un serveur dédié : 142 euros/mois

ˇ
CPU : Intel Xeon E5-1650 6 cœurs/12t 3,2 GHz+/3,8 GHz+

ˇ
RAM : 64 Go DDR3 ECC 1333 MHz

ˇ
Disques : 2*3 To en SATA3

ˇ
IP : 256 IP

ˇ
Carte réseau publique : 1 Gbps

ˇ
Carte réseau vRack : 1 Gbps

ˇ
Disponibilité : 120 s

ˇ
Frais d’installation : offerts
ˇ
Souscription Red Hat Virtualisation (RHEV) : environ 1500 euros

Avec ce dispositif qui coûte 3204 euros par an, il est possible de créer et de paramétrer en une journée une
dizaine de machines virtuelles, soit 26,7 euros HT/mois/VM.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -2-
 kokou Agbedanou

3. Cas des hébergeurs

Tous les types de clouds sont possibles et souhaitables. Bien évidemment, le cloud privé de l’hébergeur
permet de créer des offres packagées qui seront vues comme étant disponibles dans un cloud public pour
le client final.

Les hébergeurs se contentent souvent de cloud privé à base de IaaS et laissent l’infogérance applicative
au client. Ce dernier pouvant très bien créer sa propre offre de service vis-à-vis de ses clients qui feront
alors du SaaS.

Le cloud permet l’élasticité des services applicatifs. Par exemple, dans le cas d’une application de type
site de vente en ligne : lors de la mise en production, aucune donnée précise sur la volumétrie du nombre
d’accès n’est disponible. Le cloud privé, par exemple, à base d’OpenStack va permettre de rendre élastique
la solution et de provisionner/déprovisionner automatiquement le besoin en ressources (VM, CPU/RAM) à
l’aide de mécanismes de monitoring et d’orchestration, sans aucune intervention humaine. C’est une des
forces des technologies de cloud.

4. Cas des éditeurs de logiciels

Les éditeurs de logiciels disposent d’équipes de développement dont les processus de développement
imposent bien souvent le recours à de nombreuses VM jetables (phase d’intégration, phase de tests...) et
non jetables (phase de préproduction et parfois phase de production en cas de livraison continue).

Le recours à une plate-forme de cloud computing avec orchestration et catalogue de services permet de
mettre à disposition des environnements d’intégration et de QA (Quality Assurance) dans un temps record
(mois de cinq minutes pour provisionner une VM de test d’un logiciel). Les équipes sont ainsi
monopolisées totalement sur leur cœur de métier : le développement pour les développeurs, les tests
métier pour les équipes de QA...

Les cinq minutes correspondent à du temps pris par l’automate pour fabriquer la VM.

Chaque plate-forme de cloud dispose désormais d’API (Application Programming Interface) permettant
d’utiliser des services à partir d’un programme externe, par exemple des services comme createVM(),
cloud-init().

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -3-
 kokou Agbedanou

Il en est ainsi terminé du temps où l’expert fonctionnel métier, donc non spécialiste technique, passait
80 % de son temps à installer et paramétrer son VirtualBox sur son portable et à se demander pourquoi le
service Oracle ne répondait pas, ou à se demander comment vérifier que le service NTP était bien lancé.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -4-