Elasticite en Cloud Hybride

Hybrid Cloud
Computing Elasticity
We need to enhance elasticity to improve multi -cloud elasticity.
Thèse sur l’Elasticité

dans le Cloud Hybride
Le Cloud Hybride Elastique permet aux entreprises d’approvisionner de l’agilité
tout en conservant la maîtrise d’une partie des traitements, de pouvoir utiliser
dynamiquement des services de multiples clouds uniquement quand nécessaire.
Ceci passe par une orchestration complète transverse et sans couture.
Geneviève Ribot – Mastère Spécialisé « Expert Cloud Computing et SaaS » – ISEP FC – Novembre 2013
Geneviève RibotGeneGGGGGGGGGGGGGGGiève
– Mastère Spécialisé « Expert Cloud
Ribot
Computing
– MastèreetSpécialisé
SaaS » – ISEP
« Expert
FC –Cloud
Novembre
Computing
2013 et SaaS » – ISEP FC – Novembre 2013
TECH : Thèse sur l’Elasticité dans le Cloud Hybride
Remerciements Un besoin du marché
Remerciements
Tout d’abord je remercie Jean-Pierre Perdu, Claude Kuhn, Christophe Delsaux, Jean-Pierre Albert et
Nada Conan, qui m’ont permis de réaliser ma thèse dans un environnement très favorable à SOGETI,
et qui m’ont soutenue par leurs lectures et leurs avis éclairés. Je remercie mes collègues de SOGETI,
présents pour me soutenir.
Je tiens également à remercier Claude Riousset d’IBM et Sylvaine Dekeyrel qui ont pris sur leur temps
pour relire avec soin ce document et m’ont donné quelques conseils.
Je remercie également mes contacts LinkedIn et Twitter, et tous les bloggeurs, qui m’ont apportés
des liens sur des articles intéressants, en particulier Olivier D., Yann M., Eric D., Michel T., Jean-Marc
D..
Nous avons également eu des professeurs excellents et impartiaux à l’ISEP que je remercie.
Je remercie les responsables du partenariat IBM pour m’avoir invitée à toutes leurs présentations et
à des ateliers sur le cloud, ainsi qu’Oracle, Microsoft, VMWare, Cisco, HP et EMC pour leurs
invitations.
Je terminerai par mon entourage qui a eu beaucoup de patience et toujours là pour soutenir
l’étudiante.
1 Geneviève Ribot – Mastère Spécialisé « Expert Cloud Computing et SaaS » ISEP FC – Novembre 2013
Sommaire Un besoin du marché
Sommaire
REMERCIEMENTS 1
SOMMAIRE 2
SOMMAIRE DETAILLE 5
NOTE DE SYNTHESE EN FRANÇAIS 12
ENGLISH SYNTHESIS 13
INTRODUCTION 14
Un besoin du marché 14
Des enjeux d’agilité et d’efficience 16
L’objectif de ce document 17
La démarche 18
Le périmètre 19
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 20

Chapitre 1 La définition de cloud hybride et d’élasticité 20
Section 1 : Le Cloud Hybride 20
Section 2 : L’élasticité 25
Chapitre 2 : L’élasticité dans le cloud hybride 28

Section 1 : Les acteurs du cloud hybride élastique 28
Section 2 : Le Modèle de Référence du cloud hybride élastique 30
Chapitre 3 : Les cas d’usage du Cloud Hybride Elastique 36

Section 1 : Les cas d’usage 36
Section 2 : Les fonctions du cloud hybride élastique 38
Synthèse de la première partie 42
DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES 43

Chapitre 1 : Les exigences des métiers et des responsables IT 43
Section 1 : Les exigences de l’entreprise et de l’utilisateur 44
Section 2 : Les besoins de l’IT fournisseur de cloud hybride 46
Section 3 : L’analyse des écarts entre la maturité du marché et les exigences 48
Chapitre 2 : Le catalogue de service du multi-cloud 51

Section 1 : Le catalogue de service du multi-cloud 51
Section 2 : Les engagements contractuels et la conformité 56
Section 3 : La vue financière du modèle de service 58
Synthèse de la deuxième partie : Exigence et catalogue de Service 61
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE 62

Chapitre 1 Les processus 62
Section 1 : Les processus de mise à disposition 62
Section 2 : La capacité 71
Section 3 : La gestion financière 71
Section 4 : La Sécurité 72
Chapitre 2 L’outillage de l’infrastructure 76

Section 1 : L’Infrastructure devient « Software Defined » 76
Section 2 : L’automatisation est « Software Defined » 87
Section 3 : Les applications et les Business Process 97
Section 4 : Les passerelles API 99
Chapitre 3 L’outillage spécifique 100

Section 1 : Les outils basiques de gestion du cloud hybride 100
Section 2 : Les outils de facturation 101
Section 3 : L’adhérence des outils 102
Section 4 : La standardisation des outils 102
Chapitre 4 La sécurité 104

Section 1 : La gestion de la sécurité évolue 104
Section 2 : La sécurité par la gestion des accès et de l’identité 105
Section 3 : Les protocoles et la cryptographie 108
Synthèse de la troisième partie : processus et outillages 109
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE

ELASTIQUE 110
Chapitre 1 Les étapes 110
Section 1 : L’analyse de la stratégie de l’entreprise 110
Section 2 : L’étude de l’existant 112
Section 3 : La définition des priorités 116
Section 4 : La validation des choix, du périmètre et impact 118
Section 5 : La mise en œuvre 119
Section 6 : Le cycle de vie et l’amélioration continue 119
Chapitre 2 Les rôles et la gestion des compétences 121

Section 1 : Le rôle de la DSI, la gouvernance du Système d’Information 121
Section 2 : Les compétences 122
Chapitre 3 : La gestion du changement organisationnel 124

Section 1 : Impact sur les organisations 124
Section 2 : Réversibilité 126
Section 3 : Le respect de la législation et de la conformité 127
Section 4 : Analogie avec le « software defined » 128
Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride 129
CONCLUSION 130
Prospective 130
Evolution technologique 130
Un écosystème 131
Parallèle avec la finance 131
Le monde est et sera communicant 131
Comment l’automatisation permet l’élasticité 132
« Le monde qui vient » 132
Le reste à faire 134

Les challenges technologiques de l’hybride élastique 134
La maturité des entreprises 135
Les clés du succès 136
BIBLIOGRAPHIE 137
FIGURES 139
DICTIONNAIRE 141
ANNEXE A : API 142
ANNEXE B : LE DEBORDEMENT, L’EQUILIBRAGE DE CHARGE 143
Sommaire Détaillé Un besoin du marché
Sommaire Détaillé
REMERCIEMENTS 1
SOMMAIRE 2
SOMMAIRE DETAILLE 5
NOTE DE SYNTHESE EN FRANÇAIS 12
ENGLISH SYNTHESIS 13
INTRODUCTION 14
Un besoin du marché 14
Des enjeux d’agilité et d’efficience 16
L’objectif de ce document 17
La démarche 18
Le périmètre 19
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 20

Chapitre 1 La définition de cloud hybride et d’élasticité 20
Section 1 : Le Cloud Hybride 20
1) Les modèles de déploiement 20
1.1) Les modèles de déploiement du Cloud Hybride 20
1.2) Le Cloud Hybride et virtualisation 21
1.3) Les différentes formes de Cloud Hybride 22
1.4) Les challenges technologiques du Cloud Hybride 22
2) Les modèles de service 24
Section 2 : L’élasticité 25
1) La définition de l’élasticité 25
2) L’élasticité et la « Scalability » 25
2.1) Des applications conçues pour la « scalability » 26
2.2) La montée en puissance transverse 27
3) L’élasticité et gestion de la capacité 27
Chapitre 2 : L’élasticité dans le cloud hybride 28

Section 1 : Les acteurs du cloud hybride élastique 28
1) L’évolution de l’écosystème 28
2) Les acteurs 28
Section 2 : Le Modèle de Référence du cloud hybride élastique 30
1) Le management homogène 31
1.1) Exemple : L’ « Hybrid Cloud » de VMWare, 31
1.2) L’exemple: “Microsoft Hybrid” IT 32
2) Le management hétérogène 33
2.1) Exemple 1 : IBM/Openstack 34
2.2) Exemple 2 : HP/Openstack 35
Chapitre 3 : Les cas d’usage du Cloud Hybride Elastique 36

Section 1 : Les cas d’usage 36
1) Le portefeuille de service sur cloud public et privé 36
1.1) La résilience ou la reprise d’activité 36
1.2) Le projet ponctuel 36
1.3) Le traitement massif ou l’analyse Big-Data 37
1.4) Les pics de charge prévisibles sur données sensibles 37
1.5) Les pics de charge sur application SaaS 37
2) Les applications multi-niveaux en cloud public et privé 38
2.1) Les pics de charge prévisibles sur données non-sensibles 38
2.2) Les pics de charge non-prévisibles sur données temps réel 38
3) De multiples environnements en cloud public et privé 38
Section 2 : Les fonctions du cloud hybride élastique 38
1) La montée en charge 39
1.1) Deux cas de montée en charge 39
1.2) La gestion de la capacité en montée en charge 39
2) L’embarquement de charge de travail 40
3) Le débordement 41
4) L’équilibrage de charge 41
5) L’interopérabilité 41
Synthèse de la première partie 42
DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES 43

Chapitre 1 : Les exigences des métiers et des responsables IT 43
Section 1 : Les exigences de l’entreprise et de l’utilisateur 44
1) La stratégie de l’entreprise en cloud hybride 45
2) La conception des services 45
Section 2 : Les besoins de l’IT fournisseur de cloud hybride 46
1) La mise en exploitation 47
2) La production 47
3) L’amélioration continue 48
Section 3 : L’analyse des écarts entre la maturité du marché et les exigences 48
1) Des challenges technologiques 48
2) Entre les exigences et les capacités technologiques actuelles 49
Chapitre 2 : Le catalogue de service du multi-cloud 51

Section 1 : Le catalogue de service du multi-cloud 51
1) Le contexte des services 51
2) Le contenu du catalogue de services multi-cloud 51
3) La description des services spécifiques 53
2.1) L’intégration : les passerelles 53
2.2) Le design de l’automatisation 54
2.3) La configuration du réseau et des fonctions réseau inter-cloud 54
2.4) Les fonctions du cloud hybride : débordement, embarquement,… 55
2.5) L’administration de la gestion de l’identité et de l’accès 55
2.6) La gestion de la demande et de la capacité 55

a) La gestion de la demande et la proximité métier 55
b) La gestion de la capacité 56
Section 2 : Les engagements contractuels et la conformité 56
1) Les engagements contractuels dans le cloud hybride 56
1.1) La contractualisation des niveaux de services 56
a) La relation entre service et exigences métier 56
b) L’enchaînement des SLA 56
1.2) Le suivi par les métriques en cloud hybride 57
2) La conformité 57
Section 3 : La vue financière du modèle de service 58
1) Les modèles de facturation 58
1.1) Les challenges du calcul des coûts 58
a) Les challenges 58
b) La répartition des frais de structure du cloud hybride 58
c) Les charges du cloud privé spécifiques en transverse 58
1.2) Le modèle marketing et modèle coût de possession 59
1.3) Les exemples de modèle financier 59
a) Un exemple de modèle financier fonction de la capacité 59
b) Un exemple de modèle financier fonction de la sécurité 60
2) Les modèles de gestion financière en interne 60
Synthèse de la deuxième partie : Exigence et catalogue de Service 61
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE 62

Chapitre 1 Les processus 62
Section 1 : Les processus de mise à disposition 62
1) L’inventaire complet dynamique et la configuration. 62
2) Le déploiement et la mise à jour 63
2.1) Le déploiement classique 63
2.2) Le déplacement, la copie ou le redéploiement du service 63
a) Le service déplacé ou redéployé 64
b) Le Lancement du service 66
3) L’automatisation, l’orchestration 66
3.1) Le processus d’automatisation 66
3.2) Les différents niveaux d’orchestration 67
4) L’orchestration de l’hybride 69
4.1) L’Orchestration de l’hybride 70
Section 2 : La capacité 71
1) Le processus de gestion de la demande 71
2) Les processus de gestion et de supervision de la capacité 71
2.1) La mesure et le contrôle 71
2.2) L’analyse 71
Section 3 : La gestion financière 71
1) La délégation budgétaire 71
2) Le suivi de facturation centralisé 72
3) La comparaison de services 72
Section 4 : La Sécurité 72
1) La configuration de la sécurité 72
2) Les mouvements de données sécurisés 73
3) La gestion des accès et des identités 73

3.1) Un cas simple de gestion de l’identité et des accès à un service 73
1.1) L’authentification 74
a) Echange de clés publiques, Certificat 74
b) Les API échangent des Token 74
1.2) L’autorisation 74
1.3) Les challenges 75
Chapitre 2 L’outillage de l’infrastructure 76

Section 1 : L’Infrastructure devient « Software Defined » 76
1) La puissance de traitement (processeur et mémoire) 77
2) La virtualisation du réseau 77
2.1) Les différentes approches de virtualisation de réseau 79
a) Le S.D.N. 79
b) La virtualisation du réseau centrée sur le contrôleur défini par l’OpendayLight. 80
c) La superposition ou encapsulation réseau 81
d) Le Virtual Network du projet OpenContrail. 81
2.2) L’application en WAN du SDN 82
2.3) Virtualisation de fonctions 83
3) Le stockage virtualisé 84
Section 2 : L’automatisation est « Software Defined » 87
1) L’inventaire et les liaisons 87
2) L’automatisation de l’infrastructure basique 88
2.1) Provisionner et configurer 88
2.2) Exemple d’outil : OpenStack 89
3) L’automatisation des systèmes, des services, des applications 92
3.1) L’automatisation de systèmes complexes d’infrastructure 92
3.2) L’automatisation de systèmes complexes de services 93
3,3) Les standards de « Services Templates » et les outils de déploiement 94
3.4) L’intégration de l’écosystème du cloud d’accueil 96
3.5) Exemple d’outil d’orchestration 96
4) Superviser ses ressources, mesurer 97
5) DevOps 97
Section 3 : Les applications et les Business Process 97
1) SaaS et les liens entre application par API ou connecteurs 97
2) BPaaS : La Conception de Workflow 98
Section 4 : Les passerelles API 99
Chapitre 3 L’outillage spécifique 100

Section 1 : Les outils basiques de gestion du cloud hybride 100
1) Les différents outils de gestion de cloud hybride 100
2) Les qualités d’un gestionnaire de cloud hybride 101
Section 2 : Les outils de facturation 101
Section 3 : L’adhérence des outils 102
Section 4 : La standardisation des outils 102
1) Distributed Management Task Force (DMTF) 102
2) Open Grid Forum (OGF) 102
3) Storage Networking Industry Association (SNIA) 102
4) Advancing Open Standard for the Information Society OASIS 103
5) Format d’échange 103
Chapitre 4 La sécurité 104

Section 1 : La gestion de la sécurité évolue 104
1) La sécurité ciblée 104
2) La sécurité par la conformité, la classification, l’audit 104
Section 2 : La sécurité par la gestion des accès et de l’identité 105
1) La gestion des accès et des identités (IAM : Identity Access Management) 105
2) La gestion des processus 106
3) La fédération d’identité 107
Section 3 : Les protocoles et la cryptographie 108
Synthèse de la troisième partie : processus et outillages 109
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE

ELASTIQUE 110
Chapitre 1 Les étapes 110
Section 1 : L’analyse de la stratégie de l’entreprise 110
1) La stratégie Business 111
2) La stratégie sécurité 111
3) L’analyse de la demande 111
Section 2 : L’étude de l’existant 112
1) La gestion de la maturité des processus clients 112
1.1) La standardisation 112
1.2) L’automatisation 113
1.3) L’orchestration 114
1.4) L’orchestration du multi-cloud et des processus 114
2) La cartographie de l’existant 114
2.1) L’étude des contrats fournisseurs 114
2.2) La cartographie des produits existants 114
3) L’étude des écarts entre l’existant et les exigences 115
2.1) La classification de l’existant 115
2.2) Le produit sur étagère ou le développement 115
2.3) Le calcul de l’effort pour répondre aux exigences 115
Section 3 : La définition des priorités 116
1) La taille du projet 116
2) Le retour sur investissement 116
3) Le périmètre des projets sélectionnés 117
3.1) Le contexte et le catalogue de service 117
3.2) Les fonctions 117
Section 4 : La validation des choix, du périmètre et impact 118
1) La validation du périmètre, du planning et du budget 118
2) L’implication des acteurs 118
3) La validation de l’architecture 118
Section 5 : La mise en œuvre 119
1) La description complète des services du catalogue de service 119
2) La conception de l’automatisation 119
3) La gestion du changement 119
4) La mise en exploitation et le contrôle 119
Section 6 : Le cycle de vie et l’amélioration continue 119

1) Le cycle de vie 119
2) L’amélioration continue 120
Chapitre 2 Les rôles et la gestion des compétences 121

Section 1 : Le rôle de la DSI, la gouvernance du Système d’Information 121
1) La gestion des fournisseurs 121
2) La supervision des performances et l’anticipation de la demande par des tableaux de bord 121
3) La cohérence du SI en collaboration avec les métiers 121
4) La gestion du multi-cloud et du cloud privé 122
Section 2 : Les compétences 122
1) La simplification des processus 122
2) Le « software defined anything » 122
3) Le transverse 122
4) L’intégration 123
5) La sécurité 123
Chapitre 3 : La gestion du changement organisationnel 124

Section 1 : Impact sur les organisations 124
1) Les entreprises nouvelles, les TPI 124
2) Les entreprises avec une infrastructure interne importante 124
3) Les courtiers 125
4) Les fournisseurs de matériel et de logiciel cloud 125
5) Les intégrateurs 125
5.1) Les métiers 125
5.2) Le marché 125
6) Les info-géreurs 126
7) Les hébergeurs 126
8) Les éditeurs de progiciel 126
Section 2 : Réversibilité 126
Section 3 : Le respect de la législation et de la conformité 127
1) Les données personnelles 127
2) D’autres aspects 127
3) La localisation en cloud hybride 127
Section 4 : Analogie avec le « software defined » 128
Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride 129
CONCLUSION 130
Prospective 130
Evolution technologique 130
Un écosystème 131
Parallèle avec la finance 131
Le monde est et sera communicant 131
Comment l’automatisation permet l’élasticité 132
« Le monde qui vient » 132
Le reste à faire 134

Les challenges technologiques de l’hybride élastique 134
La maturité des entreprises 135
Les clés du succès 136
BIBLIOGRAPHIE 137
FIGURES 139
DICTIONNAIRE 141
ANNEXE A : API 142
ANNEXE B : LE DEBORDEMENT, L’EQUILIBRAGE DE CHARGE 143
Note de synthèse en français Un besoin du marché
Note de synthèse en français
Le cloud hybride élastique correspond à l’évolution actuelle du marché du cloud pour toutes les
entreprises qui souhaitent gagner en agilité, tout en maintenant une gouvernance sur leur choix de
solution, et en capitalisant sur leur existant. Aller vers le cloud hybride est un projet de
transformation de l’entreprise.
Ceci nécessite des compétences transverses. Cette thèse est traitée dans cet esprit, elle démontre
qu’il faut avoir une vision globale qui va de la gestion de la stratégie de l’entreprise à la mise en
œuvre, tout en passant par la maturité technologique de l’automatisation, pilier de la faisabilité du
cloud hybride élastique. Cette maturité technologique s’appuie sur la mise en place de standards à
tous les niveaux de l’infrastructure à l’applicatif. L’approche transverse ne permet pas la granularité
des approches focalisées sur un seul sujet, elle est pourtant indispensable à l’intégration des
différentes briques de l’automatisation que sont le réseau, le traitement, le stockage, le
développement, la production, les applications, les flux métiers, la supervision.
La première partie définit ce qu’est le cloud hybride élastique. Le cloud hybride élastique est le
courtier de cloud interne, il permet de répondre à des pics de charge et des projets ponctuels par des
solutions de débordement et d’embarquement de services en externe. Il gère la gouvernance du
multi-cloud, en particulier la capacité, la sécurité, la facturation, le respect des engagements, en
s’appuyant sur la gestion des règles, des politiques et des mesures.
La deuxième partie traite des exigences de l’entreprise et de l’IT et du catalogue de service du cloud
hybride élastique pour y répondre. L’analyse des exigences est affinée par une vue sous l’angle ITIL
pour l’entreprise et les services IT. L’écart entre les exigences et la maturité de l’offre de service
cloud nous donne les opportunités et les faiblesses du cloud hybride élastique et nous permet de
construire le catalogue de service.
Les processus et les mécanismes qui sont essentiels pour réaliser les services du cloud hybride
élastique, sont vus dans la troisième partie. Nous focalisons alors sur les processus d’orchestration,
de fédération, de facturation avant d’étudier l’outillage sans lesquels nous ne pourrions pas
automatiser. Nous étudions les mécanismes en partant de l’infrastructure et en remontant dans les
couches applicatives. Et nous montrons comment cet outillage évolue pour permettre
l’automatisation de l’infrastructure, l’orchestration par le « Software Defined » qui consiste à séparer
le traitement du contrôle, afin de pouvoir centraliser le contrôle et ainsi configurer les ressources à la
volée.
Enfin, connaître les exigences et la maturité technologique nécessaire ne suffisant pas pour réussir
un cloud hybride élastique. La quatrième partie, traite donc de la mise en œuvre d’un cloud
hybride élastique, sous forme d’étapes traitant entre autre de la maturité des processus, du retour
sur investissement et de la gestion du changement organisationnel.
Et nous terminons par la conclusion par une prospective, le reste à faire et les clés du succès.
English synthesis Un besoin du marché
English synthesis
The elastic hybrid cloud is the current evolution of the cloud market, for all companies wishing to
increase their agility, while strengthening governance, and capitalizing on their legacy. Going toward
the hybrid cloud is an enterprise transformation project.
This requires cross-functional management skills. This thesis is addressed to do so; it shows that it’s
necessary to have a global view of transformation from managing the business strategy to
implementation, while going through the technological maturity, which is the corner stone of elastic
hybrid cloud automation. This technological maturity relies on the establishment of standards at all
levels, from infrastructure to software. The transverse approach does not allow the granularity of
single issue focused approaches. However you need an overview to integrate the different layers that
are automating network, processing, storage, development, production, applications, business
workflows and monitoring.
The first part defines what the elastic hybrid cloud is. The elastic hybrid cloud is the internal cloud
broker. It’s an answer for peak loads and one-shot projects, with outside bursting and on-boarding
services. It manages the governance of multi-cloud like capacity, security, billing, fulfillment of
commitments driven by management rules, policies and measures.
The second part deals with business and IT requirements and with the elastic hybrid cloud service
catalog. The requirement analysis is refined by an ITIL process point of view for business and IT
services. The difference between requirements and cloud services market maturity give us the
opportunity and the weakness of the actual elastic hybrid cloud and help us to build the service
catalog.
The essential processes and mechanisms to achieve flexible hybrid cloud services are seen in the
third part. The orchestrations, the federation and the billing process are studied before looking at
tools, without which you can’t automate. The end-to-end approach goes from the infrastructure to
the application and business process mechanisms. We show how these tools evolve to enable the
automation of infrastructure orchestration by "Software Defined" which consists of separating the
data plane from the control plane, in order to centralize control and to configure resources on the
fly.
However, the requirements and the technological maturity only are not sufficient enough to deliver a
flexible hybrid cloud. The fourth section therefore addresses the successful implementation of an
elastic hybrid cloud, bringing steps to deal with other necessary processes like maturity, return on
investment, and change management.
Lastly, we conclude with prospective challenges and keys to success.
Introduction Un besoin du marché
Introduction
Un besoin du marché
Des besoins
Le contexte économique actuel ne permet pas de rester inactif. Il faut répondre vite aux demandes
du marché et à moindre coût.
Les entreprises doivent :
- capitaliser sur leur existant,

- maîtriser leurs dépenses,
- être plus réactives,
- améliorer leur Time To Market, pour des cycles de vie produit plus courts,
- répondre à des besoins nouveaux comme l’analyse Big Data, la convergence digitale,
l’internet des objets,
- être compétitives.
Elles sont soumises à des contraintes de sécurité et de conformité, légales et réglementaires.

Certaines de leurs données sont sensibles, à caractère personnel, ou stratégiques, constituent l’ADN
de la société. D’autres doivent pouvoir être auditées. Elles ne peuvent pas être externalisées sans
respecter des conditions de localisation, de sécurité, d’accessibilité, de réglementation.
 Remarque
Le cloud hybride répond donc aux besoins d’entreprises. Les TPI et PME ou des entreprises nouvelles
sans ses exigences pourront lui préférer les courtiers de cloud.
 Important
L’entreprise doit toujours pouvoir approvisionner les services qui correspondent à ses exigences, en
interne, mais aussi chez différents fournisseurs de cloud. Elle se doit de garder la liberté de choisir le
meilleur du marché pour chaque besoin et de pouvoir adapter ses fournisseurs à son évolution.
Un modèle de cloud hybride élastique permet de répondre à ses besoins.
Le cloud c’est la mise à disposition de services : en self-service, facturés ou mesurés à l’usage,

accessibles de partout, s’appuyant sur des ressources mutualisées et rapidement élastiques (d’après
les 5 caractéristiques essentielles du cloud du NIST).
Le cloud est caractérisé par ses modèles de déploiement : public, privé, communautaire et ses
modèles de service : IaaS (Infrastructure as a Service), PaaS (Plateform as a Service), SaaS (Software
as a Service), BaaS (Business as a Service) que nous reverrons dans « Les Fondamentaux ».
Introduction Un besoin du marché
 Important
Le cloud hybride permet la connexion de l’entreprise à différents clouds privés, publics ou

communautaires. Il faut qu’il soit élastique car il doit permettre d’approvisionner des ressources et
de les libérer en fonction des besoins.
Des chiffres confirment les besoins d’élasticité
L’étude du marché du Cloud Index montre que la motivation principale des entreprises, devant la
réduction de coût, est le besoin de flexibilité qui démontre bien l’importance de l’élasticité. La
flexibilité permet à l’entreprise d’adapter ses ressources en fonction de ses besoins, rapidement et à
moindre coût.
Figure 1 : Les motivations principales pour recourir au Cloud
Des évolutions portées par la dynamique de l’écosystème : mobile, données, objets.
La figure suivante : le « Hype Cycle » (Cycle de battage médiatique) de Gartner, caractérise

l’évolution dans le temps des attentes et déceptions engendrées par des nouvelles technologies.
Introduction Des enjeux d’agilité et d’efficience
Figure 2 : Cycle de battage médiatique du Cloud-Computing - Gartner 2012
Il place le « Cloud Hybride » en août 2012 dans un cycle qui devrait atteindre son plateau de
production dans 5 à 10 ans. Ceci n’est pas étonnant étant donné la complexité et la multitude des
outils, sujet que nous développerons plus loin, à mettre en place pour atteindre toutes les exigences
des entreprises, mais ce cycle pourrait être raccourci par la synergie des acteurs pour apporter des
solutions technologiques, afin de répondre aux attentes du marché, en terme de réactivité.
Des enjeux d’agilité et d’efficience

Les entreprises sont de plus en plus nombreuses à souhaiter faire du Cloud Hybride, en partie en
interne, en partie en externe. Ce cloud doit être élastique, c'est-à-dire qu’il doit répondre rapidement
à des demandes de ressources supplémentaires et à leur libération dès qu’elles ne sont plus utiles.
L’objectif de l’élasticité est de diminuer les coûts, le principe pour le réaliser est d’automatiser.
L’administration et l’automatisation doivent être le plus simple possible, et le suivi des coûts doit
permettre de suivre le retour sur investissement.
 Important
Pour améliorer l’efficacité et la disponibilité il faut réduire la complexité : automatiser, orchestrer,

de façon transversale, de l’infrastructure au logiciel, d’un métier à l’autre.
Introduction L’objectif de ce document
L’objectif de ce document
L’objectif de ce document est de décrypter les meilleurs chemins pour réaliser de l’élasticité dans le
cloud hybride pour :
 Adapter l'infrastructure aux exigences et non l'inverse.
=> nous commencerons donc, juste après les définitions, par rechercher les exigences et les
services
 Gagner du temps et de la fiabilité en automatisant des tâches répétitives et en orchestrant

globalement.
 Améliorer la sécurité et la centralisation : nous verrons ce qui participe à l’orchestration

d’un cloud hybride élastique.
=> nous verrons les mécanismes qui permettent de répondre aux exigences et leur maturité
 Réussir le changement par une démarche complète incluant la gestion du changement.
=> car bien connaître ces exigences et les technologies ne suffit pas, le dernier point abordé sera
la mise en œuvre.
Introduction La démarche
La démarche
 Important
La démarche découle de ces objectifs et de la conviction, que le cloud hybride nécessite une vue
transversale :
- au niveau technologique : de l’infrastructure à la gestion des processus,
- au niveau projet : de l’écoute des besoins à la mise en œuvre.
C’est d’ailleurs pour cela que la formation de l’ISEP FC est transversale.
Nous commençons par définir ce qu’est un cloud hybride et en quoi consiste l’élasticité, dans la
première partie. Ceci est suivi de cas d’usages de cloud hybride élastiques permettant de voir plus
concrètement la pertinence de ce modèle pour les entreprises.
Ensuite, dans la deuxième partie nous étudions quelles sont les exigences des entreprises et de l’IT
pour y répondre.
Afin de couvrir la majorité des clouds hybrides nous ne traitons pas d’un cas d’usage, mais restons
global, en nous appuyant sur des séminaires, des articles, des retours d’expérience de professionnels.
De ses besoins découleront les services considérés majeurs dans la réalisation du cloud hybride
élastique.
Puis nous étudions dans la troisième partie, les processus et les mécanismes, qui sont essentiels
pour répondre à ces exigences et réaliser les services du cloud hybride élastique.
Nous focalisons alors sur les processus d’orchestration, de fédération, de facturation avant d’étudier
l’outillage sans lequel il serait impossible ou difficile d’automatiser.
Nous étudierons les mécanismes en partant de l’infrastructure et en remontant dans les couches
applicatives. Et nous essaierons de montrer comment cet outillage évolue pour permettre
l’automatisation de l’infrastructure à l’orchestration.
Enfin, connaître les exigences et la maturité technologique nécessaire ne suffisant pas pour réussir
un cloud hybride élastique. Nous abordons donc, la quatrième partie, la mise en œuvre d’un cloud
hybride élastique, en le déroulant sous forme d’étape nous verrons : le retour sur investissement, la
maturité nécessaire, l’impact organisationnel.
Introduction Le périmètre
Nous terminons par la conclusion avec une prospective sur l’évolution potentielle de l’écosystème
du cloud hybride.
 Important
L’élasticité dans le cloud hybride demande une vue transverse qui part de la stratégie pour aboutir à
la mise en œuvre et cette élasticité s’appuie sur des « technologies » adaptées qui permettent le
transfert des informations entre chaque niveau physique et applicatif.
Le périmètre
Le domaine du cloud est tellement vaste qu’il est impossible de traiter l’ensemble des domaines. Ce
document s’adresse à un public averti et ne détaillera pas toutes les technologies sous-jacentes au
cloud computing.
Ce document ne traitera pas non plus de manière significative des vendeurs de produits, services et
technologies, que vous trouverez dans la documentation spécialisée des vendeurs, afin d’avoir une
vision indépendante de celle de fournisseurs. Nous ne pouvons pas traiter toutes les exigences, tous
les services, tous les mécanismes. Nous focaliserons donc sur ceux qui sont essentiels à l’élasticité en
multi-cloud. Nous ne traiterons pas notamment des mécanismes spécifiques de domaines
« particuliers » comme la messagerie, le big-data, la base de donnée, le développement et le PaaS, le
Master Data Management ou le Virtual Desktop Infrastructure,…
Nous traiterons par contre les fondamentaux du cloud (traitement, stockage, réseau), les spécificités
(automatisation, orchestration, mesures, règles…), la gestion, et aborderons certains aspects de la
gestion des accès.
Nous traiterons des besoins, services et mécanismes liés à la circulation des charges de travail d’un
cloud à un autre et des impacts prévisibles.
 Conseils pour une lecture transverse
Dans un monde où il faut aller vite, un document d’une centaine de page, peut être décourageant.
Des petits carrés avec marqué « important » ou « synthèse » sont là pour vous donner un aperçu de
ce document.
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 1 La définition de cloud hybride et d’élasticité
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD

HYBRIDE ELASTIQUE
Nous commençons par définir ce qu’est un cloud hybride et en quoi consiste l’élasticité. Ceci est
suivi de cas d’usage de cloud hybride élastique permettant de voir plus concrètement la pertinence
de ce modèle pour les entreprises.
Chapitre 1 La définition de cloud hybride et d’élasticité

Dans ce chapitre nous verrons les modèles de déploiement et de service du cloud hybride, puis la
définition de l’élasticité par rapport à la « scalability ».
Section 1 : Le Cloud Hybride
1) Les modèles de déploiement
1.1) Les modèles de déploiement du Cloud Hybride
3 modèles de déploiement sont reconnus par la plupart des acteurs du cloud : public, privé et
communautaire. Le modèle hybride est une gestion centralisée de différents modèles de
déploiement.
Le cloud hybride est la connexion de différents clouds, à différents niveaux, pour servir les besoins
d’une entreprise en permettant la portabilité des charges de travail ou données.
L’emploi de charge de travail est utilisé pour signifier qu’il peut s’agir d’une partie d’un service, ou
d’un service complet.
L’IT traditionnelle ou hors cloud n’est pas exclue de la gestion du cloud hybride car :
- le client consommateur souhaite avoir tous ses services accessibles d’un même portail,
- les services doivent pouvoir échanger des informations entre hors-cloud et dans le
cloud,
- le gestionnaire interne des services cloud a besoin de fédération de certaines
informations, d’identité, de sécurité, de monitoring,…
Les services qui ne sont pas mis dans le cloud, sont en règle générale gardés en interne pour des
raisons :
- technologiques (incompatibilité, performance, etc.),
- de conformité à la législation,
- de classification (propriété intellectuelle, confidentialité, informations stratégiques).
Ces services peuvent avoir des interfaces avec les services gérés dans le cloud. Ces interfaces se
basent en général sur les connecteurs des applications.
Figure 3 : Modèles de déploiement du Cloud
Ressources
Modèle de déploiement Emplacement multi-entreprises
L’entreprise possède sa propre infrastructure de cloud en interne pour fournir à ses
clients internes en général des services facturés à l’utilisation (ou mesurés). Son service
Privé sur site client. Non informatique gère l’infrastructure à la livraison des services.
L’entreprise possède sa propre infrastructure de cloud ou la loue en interne pour
fournir à ses clients des services facturés à l’utilisation (ou mesurés). Le service
Privé informatique est géré par un prestataire externe qui est en charge de l’infrastructure à
Privé managé. sur site client. Non la livraison des services.
L’entreprise possède sa propre infrastructure de cloud ou la loue, dans un site externe,
pour fournir à ses clients des services facturés à l’utilisation (ou mesurés). Le service
informatique est géré par un prestataire externe qui est en charge de l’infrastructure à
Privé hosté et managé.hors site Possible la livraison des services.
Plusieurs entreprises partagent une infrastructure de cloud. Elles partagent un besoin
Communautaire hors site Possible commun de service. Exemple : Amadeus.
Le fournisseur de cloud fournit des services à son entreprise cliente, facturés à
l’utilisation et/ou à la réservation, mais le client réserve des ressources pour son
organisation non-mutualisées, ainsi que des liens. Exemple : Virtual Private Cloud
d’AWS. A la limite entre du cloud privé et du cloud public car similaire au cloud privé
Virtual Private Cloud hors site Non hébergé et managé, mais hébergé dans des fournisseurs de cloud public.
Public
Le fournisseur de cloud fournit des services à ses entreprises clientes, facturés à
l’utilisation. Les ressources sont mutualisées, l’isolation est assurée par des
Public traditionnel hors site Oui mécanismes adéquats. Exemple : AWS, Goggle Engine,…
Les ressources sont publiques mais le client s'engage mensuellement ou annuellement,
Public à engagement hors site Oui ou le service souscrit l'engage par manque de possibilité de réversibilité.
Figure 4 : Tableau des Modèles de déploiement
Le mode de déploiement public du cloud hybride est le courtier de cloud, le « cloud broker ».
1.2) Le Cloud Hybride et virtualisation
La virtualisation permet de mettre une couche d’abstraction entre le matériel et le logiciel. Elle
permet de mettre plusieurs machines virtuelles sur un seul serveur ou sur un groupe de serveur,
mais surtout d’automatiser l’approvisionnement de ressource et leur configuration. La virtualisation
du réseau local et du stockage complète celle du traitement.
La virtualisation simplifie beaucoup de mécanismes de configurations et permet de migrer certaines

applications en fonctionnement dans des datacenters, sur des infrastructures compatibles.
Si la virtualisation à l’avantage d’abstraire les contraintes de compatibilité physique, certaines

applications peuvent fonctionner en bare métal, sans hyperviseur, mais automatisées de façon à
pouvoir déplacer la charge de travail d’une ressource à une autre, en contournant les problèmes
d’adhérence par le déploiement à l’aide de scénarios automatisés. Pour certaines applications,
fonctionner directement sans virtualisation permet de savoir en permanence ou se situe
l’application, sur quels composants. Cela peut permettre également d’optimiser la performance, par
l’absence de virtualisation. (Exemple : « Parallels Automation » permet de définir des modèles de
déploiement et de facturation avec ou sans l’hyperviseur « Virtuozzo Parallels Container »).
1.3) Les différentes formes de Cloud Hybride
Le terme inter-cloud est plus réservé pour définir la connexion entre cloud qui sert à la gestion
propre du cloud. Il s’agit en général d’une liaison pour la sauvegarde, le secours ou les mises à jour
internes. En ce qui concerne notre définition du cloud hybride le terme le plus souvent employé est
multi-cloud.
Le cloud hybride peut faire référence à différentes formes « d’hybridation » qui sont :
- des ressources physiques et des virtuelles,
- des clouds privés et publiques,
- du cloud et du non-cloud,
- différents fournisseurs de cloud,
- du réseau privé et public,
- du partagé et du privatif,
- du sur-site et du hors-site.
Le cloud hybride peut prendre ses différentes formes. Le principe du cloud hybride, ici étudié, est
celui qui permet à l’entreprise de pouvoir approvisionner des services dans de multiples clouds.
Dans le cloud Hybride les services peuvent passer d’un cloud à l’autre de manière horizontale. Ils
sont déployés sur chaque implémentation cloud, déplacés de l’une à l’autre, ou montent en charge
de manière horizontale entre les deux implémentations.
Le premier bénéfice de ce déploiement est la flexibilité, la gestion de la disponibilité et l’élasticité.
1.4) Les challenges technologiques du Cloud Hybride
Le cloud hybride s’ouvre nécessairement, sur l’assemblage de multiples clouds de technologies

différentes, par le biais d’interfaçage (API) (cf. Annexe API). Ce qui permet aux entreprises de rester
libres d’approvisionner les meilleurs services correspondants à leurs exigences métier.
Si un cloud n’assume pas une fonction ou l’assume différemment d’un autre, l’interface ne suffira pas
à avoir la fonction. Par exemple si le service gère quatre niveaux de rôles dans un cloud et que le
deuxième cloud n’en gère que trois, le service ne pourra pas être transféré.
L’intégration de ces interfaces et le maintien de la compatibilité, sont un challenge.
Faire intervenir de multiples éléments, multiplie le risque d’indisponibilité, surtout s’ils ne sont pas
redondés. L’outil central de gestion du cloud, l’automatisation, le réseau internet font partie des
éléments qui ne doivent pas devenir des Single Point Of Failure.
Pour gérer la capacité, il faut remonter l’information sur la capacité qui influe sur les besoins du
service. Hors la capacité comme nous l’avons vu précédemment peut concerner beaucoup
d’éléments, et donc remonter beaucoup d’information ce qui est gourmand en ressource. De plus il
faut que la donnée dont a besoin le service soit mesurée dans le cloud concerné.
La sécurité des accès, et celle des mouvements de données comme vu dans le chapitre précédent
sont un des challenges. En particulier la sécurité des APIs.
Ces challenges vont se retrouver dans tous les niveaux du physique à l’orchestration.
 Important
Qui dit cloud hybride dit hétérogénéité et multiplicité des composants matériels et logiciels.
L’automatisation et l’orchestration sont indispensables pour simplifier la complexité et réduire les
coûts. Industrialiser permet aussi de réduire les erreurs dans la répétition des tâches, de gagner en
agilité, en rapidité. Par contre il ne faut pas négliger l’investissement et les compétences nécessaires
pour automatiser la complexité.
Une automatisation modulaire s’appuyant sur des blocs de construction, des paramètres, des
standards doit permettre de gagner en productivité.
2) Les modèles de service
Ci-dessous la figure 5 présente les différents modèles de service.
En gris l’environnement sous la responsabilité de l’entreprise et en vert l’environnement sous la

responsabilité du fournisseur de service cloud.
TRADITIONNEL IAAS PAAS SAAS BPAAS
Monitoring Monitoring Monitoring Monitoring Monitoring
Gestion des Process Gestion des Process Gestion des Process Gestion des Process Gestion des Process
Application Application Application Application Application
Services Business Services Business Services Business Services Business Services Business
Services techniques Services techniques Services techniques Services techniques Services techniques
Base de données Base de données Base de données Base de données Base de données
Plateforme et Plateforme et Plateforme et

Framework Framework Plateforme et Framework Plateforme et Framework
Framework
Middleware et Runtime Middleware et Runtime Middleware et Runtime Middleware et Runtime Middleware et Runtime
Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation
Virtualisation Virtualisation Virtualisation Virtualisation Virtualisation
Serveur Serveur Serveur Serveur Serveur
Stockage Stockage Stockage Stockage Stockage
Réseau Réseau Réseau Réseau Réseau
Figure 5 : Modèles de service du cloud hybride
Dans le modèle IaaS ou Infrastructure as a Service, le traitement, le stockage, le réseau, la couche

d’abstraction et éventuellement le système d’exploitation et des logiciels sont fournis sous forme de
service. Le client consommateur peut partiellement configurer ces éléments. Il peut choisir d’y
installer les systèmes d’exploitation, les logiciels qu’il souhaite. Il est en charge de leurs mises à jour.
Le PaaS ou Plateforme as a Service : met à disposition outre l’infrastructure, des ensembles d’outils
de développement : structures, librairies, logiciels, systèmes de gestion de contenu et souvent des
outils de roll-back, de gestion de version ou pour basculer d’un environnement à l’autre
(développement, test, intégration, production). La politique de mise à jour des différents éléments
dont l’operating-system est à étudier, il devrait être à la charge du fournisseur de la plate-forme.
Celui-ci doit au moins mettre à disposition des outils facilitant la mise à jour, le patching.
Le SaaS ou Software as a Service : met à disposition une application sous forme de service,
éventuellement paramétrable, souvent multi-tenant, c'est-à-dire qu’une même application est
partagée par plusieurs organisations, isolées entre elles par l’application.
Le BPaaS ou BaaS ou Business Process as a Service : s’intègre au-dessus de l’application les processus
métiers sous forme d’ensemble de circuit de validation ou d’action, de flux de travail dans le but de
les rendre plus efficients, plus flexibles, en permettant le suivi et l’analyse de ces flux et processus
métier. Ce service est important pour l’interne également car l’automatisation et l’orchestration
nécessitent des flux d’actions et la supervision de ces flux.
Exemples de BPaaS : gestion des voyages, des délégations, des processus IT comme les tests
logiciels.
 Important
Le cloud hybride ne concerne pas que le IaaS, tous les niveaux sont importants. Dans la même lignée
que la démarche « DevOps » (voir chapitre 2) ou « Software Defined », plus on attaque haut dans les
couches, plus la démarche permet d’éviter les silos, le verrouillage et de favoriser l’automatisation.
Le cloud hybride concerne chaque niveau :
- Au niveau IaaS l’approvisionnement de ressources dans des clouds différents.

- Au niveau PaaS le déploiement ou le déplacement d’environnement applicatif sur des
clouds différents.
- Au niveau SaaS : la possibilité d’échanger des informations avec d’autres cloud, même
quand l’application interfacée change de cloud.
- Au niveau BPaaS : la possibilité d’enchaîner un flux de travail, d’un cloud à l’autre.
Section 2 : L’élasticité
1) La définition de l’élasticité
L'élasticité économique mesure la variation d'un élément en fonction d'un autre élément. Par
exemple si le prix baisse de 5% la demande augmente de 10%.
L'élasticité en science est la qualité d'un matériau à être déformable tout en reprenant sa forme
d'origine lorsque la contrainte qu'on lui applique disparaît. Il s’agit aussi de résilience.
 Important
L’élasticité dans le domaine qui nous concerne, consiste à allouer dynamiquement des capacités
(puissance de calcul, mémoire, stockage, réseau) lors d’une montée en charge ou un besoin ponctuel
assimilable à une contrainte et à libérer ces ressources dynamiquement lorsque la contrainte
disparaît.
2) L’élasticité et la « Scalability »
Le terme de « scaling » que l’on peut traduire par « montée en puissance » est couramment utilisé.
On distingue :
- « Scale up » : montée en charge sur une même ressource en mettant à jour ses
capacités internes (mémoire, disque,…).
- « Scale out » : montée en charge par mutualisation de différentes ressources (cluster,

pool,…) qui est plus souple, plus extensible.
Figure 6 : Scale-Up versus Scale-Out
Pour parler d’élasticité il faut impérativement intégrer le « Scale down » c'est-à-dire la libération des
ressources, à tous les niveaux : du physique jusqu’aux services, ce qui n’est pas toujours facile à
mettre en place techniquement.
2.1) Des applications conçues pour la « scalability »

 Important
Pour pouvoir bénéficier de scaling, les applications doivent le supporter ou mieux, avoir été conçues
dans cet objectif.
Elles doivent pouvoir le supporter, avoir un niveau d’abstraction, c'est-à-dire pouvoir accéder à de la
mémoire, de l’espace disque, de la puissance de calcul mutualisée, ne pas avoir besoin d’accès direct,
physique.
Si elles sont conçues pour la montée en puissance elles pourront par exemple être réparties sur
plusieurs ressources, grâce à :
- de la modularité,
- des processus pré-intégrés,
-de la gestion asynchrone facilitant certains processus
- des communications sans-état (stateless),
- de la sécurité adaptée,
- la possibilité de diviser les données,
- la possibilité de distribuer l’information, le service.
Dans le cas d’un modèle d’application classique sur trois niveaux : Web, Service d’application et Base
de données, les différents niveaux peuvent rester solidaires, sur un même cloud ou être distribués
sur des clouds différents. Par exemple la base et l’application sont mises en interne et les frontaux
web sont sur un cloud externe. Le challenge est alors de maintenir la connexion réseau et qu’elle ait
les performances requises.
2.2) La montée en puissance transverse
La bascule de charge est réalisable par des mécanismes de redirection de flux, qui s’appuient sur les
DNS par exemple.
Les mécanismes de montée en charge doivent être contrôlés et automatisés par des applicatifs
centralisés, des outils de gestion de cloud, pour pouvoir déplacer la charge de travail entre cloud. Le
déplacement de charge de travail pour un utilisateur précis, en cours de traitement peut se heurter à
des problèmes de compatibilité, de sécurité, de bande passante et de latence.
Pour la compatibilité il faut avancer sur la standardisation et les interfaces. Pour la sécurité, la
gestion des mécanismes d’accès, les protocoles, la cryptographie existent et seront renforcés. Pour la
bande passante et la latence des liens spécifiques (comme Direct Connect d’AWS), la compression,
les éléments réseaux et les protocoles sont clés.
3) L’élasticité et gestion de la capacité
Le terme de capacité dans le cloud inclut la puissance de traitement, la mémoire, la capacité de cycle
de lecture, d’écriture, la bande passante et la quantité de stockage. Il s’agit au final de la capacité à
effectuer le service demandé, dans le temps demandé.
L’élasticité est indispensable pour ajuster la capacité à la demande. La mutualisation des ressources
permet en effet dans la limite ou tout le monde n’a pas besoin des mêmes ressources au même
moment de baisser les charges en disposant des ressources nécessaires au moment voulu.
Figure 7 : Capacité et Niveau de Charge
La gestion de la capacité est revue dans la première section du prochain chapitre.
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 2 : L’élasticité dans le cloud hybride
Chapitre 2 : L’élasticité dans le cloud hybride

Nous avons vu ce qu’est le cloud hybride et ce qu’est l’élasticité, voyons maintenant l’ensemble : le
cloud hybride élastique : les challenges de gestion de capacité et d’interopérabilité, ces acteurs, ces
modèles de référence.
Section 1 : Les acteurs du cloud hybride élastique
1) L’évolution de l’écosystème
La classification des acteurs met en évidence la rupture d’écosystème en cours. Les acteurs
historiques : les fournisseurs de matériel et de service, de logiciel, d’accès internet, les opérateurs,
les hébergeurs sont challengés par de nouveaux entrants.
Dans les nouveaux acteurs de fournisseurs de cloud certains ont commencé par le moteur de
recherche comme Google, ou l’e-commerce et sa logistique comme Amazon. La deuxième vague de
fournisseurs de cloud est constituée principalement des hébergeurs, comme OVH ou Rackspace, ou
d’opérateurs, les transporteurs de cloud, qui deviennent aussi parfois des courtiers de cloud.
Les auditeurs de cloud et les fournisseurs de composants du cloud sont des acteurs externes dont le
rôle est important.
2) Les acteurs
Ce modèle de référence de cloud privé inspiré du « NIST Cloud Computing Reference Architecture »
(cf. Annexe Modèle d’architecture) est très orienté sur les acteurs du cloud.
Figure 8 : Modèle de référence du cloud privé
Figure 9 : Acteurs du cloud hybride
Le catalogue de service des consommateurs est créé et géré par les administrateurs de cloud, qui
eux disposent du catalogue de service du fournisseur de cloud hybride. Ils ne partagent donc pas la
même origine de création du catalogue de service, ils sont bien distincts. Les superviseurs peuvent
être les administrateurs, mais il est important d’apporter une vue différente, d’évolution dans le
temps et plus globale, il s’agit bien de deux rôles différents.
Le fournisseur de services de cloud hybride va fournir le catalogue pour les administrateurs, il

fournit aussi des services de support, les services de déploiement métier (qui servent à créer le
catalogue de service métier et le déploiement de ses services) et les services opérationnels. Les
services IaaS, PaaS, SaaS et BPaaS sont orchestrés. Quant à la conformité, la sécurité et le contrôle ils
sont transverses aux modèles de service.
Les cloud brokers ou courtiers de cloud ne sont pas des propriétaires de cloud mais vont fournir des
services correspondants à la demande en sélectionnant le meilleur cloud du marché, en apportant
des services à valeur ajoutée, en intégrant de multiples clouds.
 Important
Les courtiers de cloud sont fournisseurs de services de clouds hybrides externes en réalisant
l’agrégation, l’intermédiation et l’arbitrage.
Certains courtiers de cloud deviennent d’ailleurs éditeurs d’outil de gestion de cloud hybride comme
RightScale, Scalr, ScaleXtreme, Kaavo, Abiquo, Enstratus, Hotlink, ServiceMesh…
Les clouds carriers ou transporteurs de cloud vont gérer le WAN (Wide Area Network) et parfois
avoir des fonctions de courtiers en gérant les CDN (Content Data Network), cache de données
statiques local, ou d’autre caches, d’autres systèmes de compression, décompression et

d’optimisation des chemins…
L’auditeur de cloud est une société externe chargée de vérifier la conformité, la sécurité et la
performance. Dans notre étude nous ne le reprendrons pas car il n’est pas central.
Les vendeurs de composants cloud, sont gérés par le fournisseur de cloud ou le client en fonction du
modèle de service (IaaS, PaaS, SaaS), donc ils ne sont pas dans le modèle de référence. Il faut
pourtant les prendre en compte car ils interviennent souvent dans les contraintes du cloud
(maintenance, licence,…), ou apportent de la valeur ajoutée (en performance, en sécurité, en
fonctionnalités supplémentaires,…).
L’interconnexion et l’orchestration multi-cloud, s’appuient sur des outils d’automatisation. Les
fournisseurs en apportant des solutions interopérables (répondant à des standards), agiles et
performantes vont rendre plus rapides, plus fiables et moins coûteuses les intégrations. Leur rôle est
essentiel. Les composants sont importants.
 Important
Les acteurs du cloud hybride importants pour notre étude sont donc :
- le client, consommateur et administrateur,
- le fournisseur de cloud privé ou courtier interne,
- les fournisseurs de cloud externe,
- le transporteur.
La définition de ces acteurs va nous permettre de mieux définir le périmètre du modèle de référence
du cloud hybride élastique.
Section 2 : Le Modèle de Référence du cloud hybride élastique

Des études démontrent que le business ne se développe que quand le modèle d’architecture est
mature (cf. Annexe Modèle d’architecture). C’est pourquoi nous essaierons de trouver un modèle de
référence qui permet de présenter visuellement l’élasticité du cloud hybride. Pour cela nous nous
appuierons sur les références en architectures et des modèles connus.
1) Le management homogène
Figure 10 : Modèle de référence de cloud hybride homogène
Certains cloud hybrides sont gérés par le même outil de gestion centralisée.
Les « Pour » : Puissant, Simple, une communauté d’utilisateurs de la même solution limitant les
erreurs. Possibilité de créer un cluster qui est sur les deux infrastructures et donc d’ajouter des
éléments au cluster pour supporter la montée en charge.
Les « Contre » : Limités aux services du fournisseur (de cloud et de la solution) et en interne, donc ne
répond pas à toutes les exigences.
1.1) Exemple : L’ « Hybrid Cloud » de VMWare,
http://www.f5.com/pdf/deployment-guides/vmware-vcloud-director-dg.pdf
La gestion est centralisée par vCloud Suite, et permet d’avoir un portail d’accès pour
gérer l’approvisionnement et l’automatisation (vCloud Automation Center), la supervision (vCloud
Operation management System), la sécurité (vCloud Network & Security).
La figure suivante nous permet de voir un exemple de débordement de cloud Privé sur du cloud
Public, sur une application d’e-commerce.
La mise en cache et la réplication des bases sont gérées par VMWare vFabric SQLFire, le WAN par
Global Traffic Manager de BIG IP, le LAN par Local Traffic Manager de BIG IP, F5i gère les règles.
Le comportement de l’application est mesuré en local, et les seuils de capacité définis. Quand les
seuils de capacité sont atteints, les Templates de l’application et les composants de l’infrastructure
virtuel pré-positionnée dans l’infrastructure publique sont activés et clonés. Quand la capacité
revient à un niveau bas prédéfini, les ressources supplémentaires sont libérées.
La fonction qui contrôle les seuils est une fonction de iControl de iF5 (readytoburst()), d’autres
fonctions sont chargées de réaliser l’activation des VM et vApp, et de contrôler si elles sont
suffisantes, d’en ajouter, d’en libérer.
Pour le transfert des fonctionnalités de VMWare sont utilisées comme Distributed Ressource
Scheduling qui permet de surveiller les performances et de les comparer, et VMotion qui permet de
déplacer une VM en fonctionnement.
http://www.f5.com/pdf/deployment-guides/vmware-vcloud-director-dg.pdf
Figure 11 : Cloud hybride VMWare
1.2) L’exemple: “Microsoft Hybrid” IT
Figure 12 : Cloud Hybride Microsoft
Dans ce modèle le choix avait été fait de répliquer l’AD dans le cloud public et d’y créer une base de
fédération pour accueillir des connexions externes. Cette configuration est un support intéressant
pour la mise en place d’une reprise d’activité en cas de sinistre.
2) Le management hétérogène
Figure 13 : Modèle de référence de Cloud Hybride hétérogène
Des clouds hybrides intègrent dans des passerelles qui s’appuient souvent sur des interfaces ou
Advanced Programing Interfaces (APIs) et du scripting pour effectuer la liaison.
Les « pour » : ils sont ouverts, interopérables et permettent d’approvisionner en fonction des
exigences.
Les « contre » : une intégration très importante est nécessaire, à ce jour, qui limite les possibilités, et
apporte une charge importante de tests et de risques d’erreurs que seule une standardisation peut
améliorer.
Des outils comme DeltaCloud d’Apache (dans le cadre du projet de standardisation CIMI de DMTEF)
ou LibCloud se développent, mettant à disposition des passerelles, des librairies pour se connecter
aux API standards ou classiques telles que celles de CloudStack, OpenStack, Eucalyptus, AWS,
RackSpace,…
2.1) Exemple 1 : IBM/Openstack
Figure 14 : Gestion de Cloud Hybride IBM
ftp://public.dhe.ibm.com/software/fr/events/solutionconnect2013/pdf/SolConnect_13_TIV05.pdf
Dans cette version de SmartCloud Orchestrator IBM intègre les modules projet d’Openstack pour
approvisionner des ressources : Nova pour le traitement, Glance pour les images, Cinder pour le
stockage mode bloc et Keystone pour gérer l’identité. Les clouds compatibles OpenStack sont alors
plus facilement intégrés car similaires en fonctionnalité. Des passerelles pour faire le lien avec le
cloud Public AWS EC2 ont également été développées.
Le standard OpenStack, à partir du moment où il est largement développé permet d’intégrer plus
facilement, plus rapidement.
Les standards permettent d’avoir une large communauté pour faire des avancées technologiques et
répondre plus rapidement aux besoins du cloud.
Pour l’automatisation des approvisionnements système et applicatif, IBM s’appuie sur le standard
TOSCA d’OASIS qui permet de faire des « blueprint » de déploiement d’un système, d’une
application, d’un service, associés à leur topologie. Ceci permet de rendre les scénarios de
déploiement d’applicatif ou « pattern » indépendants de la plate-forme sur laquelle ils seront
déployés.
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE
2.2) Exemple 2 : HP/Openstack
Figure 15 : Gestion de Cloud Hybride HP
Séminaire HP du 11/10/2013 Paris « Osez passer au Cloud de nouvelle génération»
HP a également intégré OpenStack pour l’approvisionnement et la configuration de l’infrastructure et

s’appuie sur TOSCA pour l’automatisation. Ils ont développé des passerelles pour les fournisseurs de
cloud Amazon Web Service, Azure et Numergy et peuvent intégrer d’autres interfaces sur
développement.
Les services ou charges de travail peuvent être déplacés vers des clouds externes.
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE Chapitre 3 : Les cas d’usage du Cloud Hybride Elastique
Chapitre 3 : Les cas d’usage du Cloud Hybride Elastique

Après avoir bien défini le cloud hybride élastique, voyons des cas concrets d’usage.
Il y a plusieurs façons de combiner des infrastructures de cloud public et privé dans un cloud hybride,
par exemple en déployant :
- une partie du portefeuille dans le cloud publique et une autre dans le cloud privé et les
bouger en raison de changement de charge, de coûts,
- des tiers séparés, avec le tiers base de donnée sur une infrastructure privée et le tiers
web dans le public,
- l’environnement de développement dans le cloud privé et celui de production dans le
public ou l’inverse,
Figure 16 : Cas d'usage du cloud hybride élastique
Section 1 : Les cas d’usage
1) Le portefeuille de service sur cloud public et privé
1.1) La résilience ou la reprise d’activité
L’entreprise peut déposer ses applications dans un cloud, disponibles mais non activées et en cas
d’indisponibilité de ses services effectuer une reprise d’activité dans le cloud de manière partielle ou
complète. (Exemples : PRA du Virtuel Private Cloud d’AWS). L’entreprise peut également faire de la
continuité d’activité en fonctionnant en actif-actif sur un cloud interne et un cloud externe
(Exemple : PCA basé sur Site Recovery Manager et VNX VMware-EMC).
1.2) Le projet ponctuel
Un projet ou avant-projet nécessite des ressources importantes et immédiatement disponibles. Elles

sont provisionnées rapidement, en lien avec l’infrastructure interne. Ce qui réduit considérablement
les délais du projet.
Les ressources du projet peuvent être rapatriées en interne quand le projet passe un stade défini, ou
tout simplement libérées en fin de projet.
1.3) Le traitement massif ou l’analyse Big-Data
La transformation de documents d’un format à un autre, la comparaison de chaîne d’ADN, l’analyse

sémantique de données, le calcul scientifique et l’indexation, peuvent être des traitements de
volume massif de données. Actuellement les données sont parfois envoyées par transporteur quand
leur volume n’est pas réaliste par rapport aux capacités réseaux. L’élasticité de la capacité réseau est
encore un sujet d’avenir.
Les entreprises n’ont souvent pas la capacité technique de gérer un besoin ponctuel de traitement
massif de données, le cloud public leur permet alors de gérer ce traitement.
Les données issues de ce traitement sont alors reprises en interne, en cloud privé, et les ressources
en cloud public libérées.
1.4) Les pics de charge prévisibles sur données sensibles
- Une entreprise dispose en interne d’un cloud privé et anticipe un pic de charge sur son analyse
financière en fin d’année.
Elle peut choisir de déplacer des traitements vers un cloud public, en déplaçant des applications
moins stratégiques, pour libérer de la puissance en interne pour monter en charge.
- Une entreprise, comme un hôpital, ne disposant pas provisoirement de ressources suffisantes en

interne peut choisir d’affecter une partie de ses traitements, non-nominatifs, en externe, dans un
cloud publique, et de traiter les données personnelles, devant rester localisées sur le territoire
national pour des raisons légales dans son cloud privé, un cloud communautaire ou un cloud
souverain.
1.5) Les pics de charge sur application SaaS
Une entreprise délivrant un logiciel de CRM, connaît des pics de charge saisonniers.
Prenons l’exemple d’une base de données multi-tenant, conçue pour être divisée, par exemple sur
un critère de géographie client. Celle-ci va pouvoir être distribuée sur deux clouds différents et en
adéquation avec la localisation du client quand les capacités exigées pour un fonctionnement correct
sont dépassées puis centralisée à nouveau, pour des raisons de coûts, quand le pic de charge est
passé.
C’est complexe, il faut avoir mis en place des règles, des mesures et des processus de gestion du
mécanisme. La gestion du mécanisme est composée de multiples blocs qui vont gérer la coordination
de l’ensemble des actions à réaliser et se connecter aux interfaces. D’autant plus que le suivi doit
parfois pouvoir être tracé et audité.
2) Les applications multi-niveaux en cloud public et privé
2.1) Les pics de charge prévisibles sur données non-sensibles
Une entreprise de commerce en ligne a une activité saisonnière avec des pics de charge à la rentrée,
à Noël, en période de solde.
Elle peut décider de placer la partie web, d’une application à trois niveaux web, application, base de
données, pour qu’il puisse monter en charge sans limite, dans un cloud public.
2.2) Les pics de charge non-prévisibles sur données temps réel
Une entreprise gérant le trafic routier, ne peut pas toujours anticiper ses pics de charges, dus parfois
à un accident ou à une météo défavorable par exemple. Par contre en cas de pic de charge elle doit
pouvoir diffuser des informations en temps réel. Elle ne peut donc pas s’appuyer sur des caches de
type CDN (Content Data Network) car l’information en cache ne serait pas à jour. Elle doit pouvoir
étendre rapidement ses capacités de bande passante. Le besoin est ici d’élasticité. Si la plateforme
sur laquelle elle se trouve ne suffit pas, elle doit pouvoir basculer sur d’autres plateformes.
Elle peut décider de placer la tierce base de données, pour qu’il puisse monter en charge sans limite,
dans un cloud public.
3) De multiples environnements en cloud public et privé
Une banque souhaite améliorer l’efficience de son développement. Un projet de développement

nécessite plusieurs environnements : développement, test, recette, intégration, production. Le
passage d’un environnement à l’autre est automatisé pour améliorer l’agilité. Chaque
environnement est activé, stocké et désactivé, réactivé lors d’un roll-back.
Chaque environnement va avoir des exigences différentes en termes de performance, mais aussi de
sécurité et de disponibilité et peut donc dépendre d’infrastructures différentes : certaines dans le
cloud public, d’autres en cloud privé.
Section 2 : Les fonctions du cloud hybride élastique

Nous venons de voir les cas d’usage, voyons maintenant les fonctions du cloud hybride qui apportent
des solutions aux problématiques de ces cas d’usage.
Les infrastructures actuelles ne peuvent pas répondre à toutes les nouvelles demandes de possibilité
technique, les pics de demandes requièrent une infrastructure onéreuse peu utilisée et le cloud
public peut être plus économique. Donc les entreprises regardent vers le cloud hybride.
Dès le début du cloud les clients ont utilisé leur portail interne pour donner accès à des ressources
supplémentaires souvent provisoires, parfois urgentes : du stockage, du traitement, des plateformes
de développement. Au départ ces ressources sont créées à l’usage et si le besoin est récurent, un
modèle est créé, qui sert à déployer l’instance quand nécessaire plus rapidement. C’est le début du
cloud hybride élastique.
1) La montée en charge
Un besoin souvent rencontré est la montée en charge. Comme le cloud externe est souvent plus
mutualisé, il dispose plus facilement de ressources supplémentaires c’est donc sur ce cloud externe
que l’on souhaite monter en charge. Il faut donc que ces mécanismes soient prévus
1.1) Deux cas de montée en charge
La figure suivante représente deux cas d’élasticité en cloud hybride élastique.
Dans le premier cas le service est déplacé du cloud A vers le cloud B (ou plus souvent redéployé dans
le cloud B), pour un pic de charge. Le cloud B gère la montée en charge. Quand la charge est standard
le service est rapatrié en interne dans le cloud A.
Figure 17 : Scale-out en cloud hybride élastique
Dans le deuxième cas, il s’agit d’un service sur 3 niveaux, web, application, base de données, par
exemple. Le frontal Web est dans le Cloud B, l’application et la base sont dans le cloud A. Quand la
charge monte, de la puissance est ajoutée au frontal Web, qui suit à la montée et à la baisse
l’évolution de la charge.
1.2) La gestion de la capacité en montée en charge
Quand un seuil de capacité est atteint des ressources sont activées dans un cloud externe et les
utilisateurs orientés vers ses services, ces ressources sont adaptées en permanence au besoin.
Figure 18 : Montée en charge dynamique
http://iweb.com/cloud/hybrid-cloud-hosting
L’affectation de ressources supplémentaires et leurs libérations, sont des mécanismes complexes

gérés par des seuils et des algorithmes. L’approvisionnement et le dé-provisionnement requiert des
ressources systèmes et peuvent générer des latences, surtout entre deux clouds. Afin de ne pas créer
d’instabilité de l’application, le système ne doit pas être trop réactif. En fonction des besoins du
service, le système peut soit sur-provisionner légèrement, soit accepter de lèger sous-
provisionnement.
Le modèle le plus respectueux de l’expérience utilisateur, ou de la capacité du service est un modèle

dans lequel la performance du service est en permanence mesurée pour vérifier son adéquation par
rapport à la demande. L’idéal étant d’inclure des mécanismes capables : d’aller mesurer le temps de
réponse du service sur le poste client et de savoir le type de poste client.
Pour pouvoir faire ceci il faut tout d’abord modéliser :

- modéliser le déploiement des charges de travail ou services,
- définir des seuils de capacité qui déclencheront la montée en charge et ceux qui sont appropriés à
la baisse de charge,
- définir des écarts, un comportement, des durées en prenant en compte les délais de déploiement
et de transfert d’information, afin de stabiliser le comportement,
Puis automatiser, orchestrer :

- automatiser les mesures, les retours de mesure, les déclenchements,
- déployer des ressources supplémentaires, ou en libérer,
Enfin il faut pouvoir superviser, c’est à dire mesurer la capacité en fonction des besoins du service,
afin de respecter les accords de service ou Service Level Agreement (SLA), dans le cloud de départ et
celui de débordement.
L’automatisation s’appuie donc sur une modélisation, une orchestration et une supervision qui ne
seront réalisables que si les infrastructures matérielles et logicielles peuvent être déployées et
configurées par programmation.
2) L’embarquement de charge de travail
Le premier besoin est l’embarquement de charge de travail, pour un nouveau projet par exemple. Il
faut alors déployer ce service dans le cloud externe.
3) Le débordement
Certaines sociétés utilisent du cloud bursting, c'est-à-dire du débordement. En cas de pic de charge,
les ressources sont déployées et lancées sur un cloud externe afin de répondre à un manque de
capacité en interne. Le débordement ou bursting est un mécanisme automatisé d’activation de
ressources sur un cloud externe qui peut se faire directement à partir d'une valeur seuil par un flux
de travail. En dessous du seuil, les ressources crées en externe sont libérées. Le service est facturé à
l'usage. (cf. Annexe)
4) L’équilibrage de charge
L’équilibrage de charge ou la bascule de charge, c'est-à-dire le déplacement d’une charge de travail,

n’est pas évident. D’une part il se situe sur les couches 4 à 7 du modèle OSI, et il est transporté par
les couches réseaux qui sont des couches inférieures en 2 et 3. Des mécanismes permettent de
déplacer une copie de la charge de travail, de geler le fonctionnement, et de transmettre les
informations restantes avant de redémarrer. Le souci est ce temps d’arrêt lié à la charge de travail et
à la latence réseau, le temps de gel du au temps de synchronisation finale. (cf. Annexe)
=> Parenthèse
Les processus de bascule de charge peuvent être lancé en préventif, lors d’une opération de
maintenance, pour relayer le fonctionnement interne ou pour ajouter de nouveaux services. La copie
du service est alors présente mais dormante, sous forme de template. Mais cela peut demander un
temps d’arrêt de service, en fonction des applications, du service et de l’infrastructure. C’est le type
de mécanisme utilisé par Hyper-V replicat de Microsoft pour faire du plan de reprise d’activité.
5) L’interopérabilité
L’élasticité entre cloud consiste à déplacer des charges de traitement d’un cloud à l’autre, cela
demande donc une attention particulière sur l’interopérabilité, la gestion de la sécurité, la continuité.
Nous verrons plus loin l’importance de l’Open Source dans cette démarche d’interopérabilité qui
demande la création de standards et d’interfaces.
 Important
L’élasticité dans le cloud hybride c’est l’allocation dynamique de charge de travail d’un cloud vers un
autre cloud. Les fonctions actuellement utilisées pour du cloud hybride sont généralement des
fonctions de débordement, d’embarquement de service, de montée en puissance et si la latence le
permet d’équilibrage de charge.
Ces fonctionnalités sont bien celles attendues par le cloud hybride mais celui-ci doit aussi répondre à
d’autres besoins. Globalement le cloud hybride doit permettre de provisionner, de superviser,
d’anticiper les ressources et leurs capacités, de gérer la sécurité et le budget. Tout ceci de manière
centralisée, et par étape en fonction des priorités.
PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE
Synthèse de la première partie
Nous avons maintenant défini le modèle de déploiement du cloud hybride et comment tous les
modèles de service sont concernés par le cloud hybride, en particulier le BPaaS, le Business Process
as a Service, qui va gérer et superviser les flux d’actions et de validations. Ces flux sont nécessaires
pour les applications métiers et pour la gestion de l’automatisation, l’orchestration.
Nous avons vu que l’élasticité, c’est du scale-out et du scale-down, et que cela permet de répondre à
des pics de charge ou des projets ponctuels. Mais les mécanismes de gestion de l’élasticité
demandent des règles, des mesures et des algorithmes complexes, pour répondre aux besoins de
capacité qui sont des besoins de puissance, de bande passante, de lecture, d’écriture, de volume et
surtout de temps de réponse du service.
Nous avons ensuite vu les acteurs du cloud hybride parmi lesquels se trouvent le consommateur,
l’administrateur, le superviseur et le fournisseur de cloud hybride qui est le courtier interne. Nous
avons complété en présentant des modèles de références et des solutions actuelles de cloud hybride,
homogène ou hétérogène en outil de gestion.
Nous avons terminé par des cas d’usage et les solutions du cloud hybride élastique qui permettent
d’y répondre : le débordement, l’embarquement, la montée en puissance, la bascule de charge.
DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 1 : Les exigences des métiers et des responsables IT
DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES
Suite à la présentation des fondamentaux, cette partie présente, les besoins du cloud hybride
élastique, pour répondre aux exigences des entreprises. De ses besoins découleront les services
considérés majeurs dans la réalisation du cloud hybride élastique
En chapitre 1 nous verrons les exigences de l’entreprise cliente et de ses utilisateurs, des métiers et
celles des fournisseurs de service de cloud hybride, les responsables de l’I.T. (Information
Technology). Nous enchaînerons avec le catalogue de service du cloud hybride en chapitre 2.
Chapitre 1 : Les exigences des métiers et des responsables IT

Il faut toujours revenir aux « besoins » ou au « pourquoi ? ». Comme nous l’avons vu dans
l’introduction il s’agit d’apporter de la valeur, de l’agilité, de l’efficience. C’est le fil conducteur de
cette étude. Ce qui va se traduire dans le cloud-computing à obtenir rapidement et simplement des
services à un coût adapté. Pour faire le tour de la question il faut connaître les acteurs et leurs
objectifs. Nous allons voir d’abord les exigences métier qui concernent plus la stratégie et la
conception, puis celles des responsables de l’IT qui sont focalisées sur la mise en exploitation, la
production et l’amélioration continue.
Des motivations différentes pour 3 types d’acteurs
Figure 19 : Focus sur les acteurs
L’entreprise prend de la commodité sur le marché des services de cloud. Mais tous les acteurs n’ont
pas les mêmes objectifs.
Pour l’entreprise, il faut apporter de la valeur de l’innovation, de l’agilité pour accélérer le Time-To-
Market et de l’efficience pour réduire les coûts et ainsi rester concurrentielle.
Comme l’indique la figure ci-dessus, l’entreprise est centrée sur ses exigences d’innovation, de
rapidité, et d’efficience.
Les utilisateurs veulent des produits souples, simples et peu onéreux.
Beaucoup de produits performants arrivent sur le marché offerts par des fournisseurs différents. Le
fournisseur IT va chercher à se distinguer en apportant de la valeur aux entreprises tout en restant
concurrentiel.
Section 1 : Les exigences de l’entreprise et de l’utilisateur

Il ne faut jamais perdre de vue l’objectif. La solution doit toujours répondre aux exigences.
Nous allons essayer de relever les points d’attention spécifiques du cloud hybride élastique. Nous ne
pouvons pas traiter de tous les cas d’usage. Nous essaierons de rester le plus général possible. Nous
traiterons donc des points d’attention spécifique au multi-cloud pour répondre aux exigences
connues, aux cas d’usage les plus fréquemment rencontrés.
Nous avons déjà vu (dans la première partie, chapitre 2, section 0) que les principaux usages du cloud
hybride était le débordement, l’embarquement, la montée en charge, le provisionnement, la
supervision, l’anticipation capacitaire, la gestion de la sécurité et du budget. Nous allons compléter
cette vision.
Les exigences de l’entreprise viennent des métiers.
L’étude de la gestion des ressources IT doit se faire dans une perspective « métier ».
Chaque métier à des exigences particulières comme par exemple :
- Des pics d’activité prévisibles ou non (e-commerce, circulation, météo…)

- Des informations sensibles (médicales, bancaires, stratégiques, réglementaires…)
- Des temps de réponses (trading, 3s/3clics,…)
- De la continuité, disponibilité (production,…)
- Des informations largement distribuées.
L’IT doit d’abord prendre en compte le respect de la stratégie business de l’entreprise et de sa

stratégie de sécurité, qui influent sur les exigences.
L’analyse des exigences va permettre de cerner ce qui peut aller dans un cloud et dans quel cloud.
Elles sont à mettre en regard avec les garanties et possibilités apportées par les fournisseurs de
cloud. Les écarts devant être analysés et éventuellement acceptés, couverts, ou refusés.
Pour cette étude les processus ITIL ont servis de support à la réflexion, classés par étapes : la
stratégie et la conception dans cette section, qui concerne les besoins de l’entreprise et de ses
utilisateurs. Ces exigences sont donc aussi celles des métiers.
1) La stratégie de l’entreprise en cloud hybride
STRATEGIE
EXIGENCES DE
L'ENTREPRISE A DEMANDER : POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD
Les investissements cloud privés en internes sont souvent en capital

alors que les dépenses sont opérationnelles, à la demande, dans les
clouds externes. Les différents clouds ont des modèles de facturation
tous différents et difficiles à comparer, et à centraliser. . Il faut
superviser la gestion financière, mais sans enlever d’agilité.
Prévisions budgétaires, Faire attention à gérer les priorités des investissements

Gestion investissements et d’automatisation et de centralisation en fonction des gains : la
financière imputation des coûts gestion de la complexité est source de coûts.
Anticipation et compréhension des besoins de chaque métier qui

pourront déclencher une externalisation et leur éligibilité. (Besoins
ponctuels et continuité d’activité)
Schémas de la capacité
Gestion de la utilisée dans le temps, Faire attention à connaître la stratégie qui fera évoluer la demande et
demande prévisions stratégiques donc à rester interopérable.
Prévision des utilisations ponctuelles, pour choisir les automatisations

prioritaires, les interfaces (Advanced Programming Interface) avec des
fournisseurs externes. (cf. Annexe API)
Services en portefeuille
Gestion du et leurs contraintes dont Faire attention à garder un portefeuille réduit bien centré sur les
portefeuille de les délais de mise à demandes métier et à gérer le cycle de vie des services dans toutes les
services disposition localisations.
2) La conception des services
CONCEPTION
EXIGENCES DE
L'ENTREPRISE A DEMANDER : POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD
Différents niveaux d'engagement pour différents services. Suivi des

conformités dans le temps. Possibilité de gérer la conformité exigée
Gestion Exigences contractuelles et par service ou type de service pour le choix du service cloud.
fournisseur analyse des risques
Faire attention à suivre la conformité par rapport aux services quand
ils sont déplacés d’un cloud à l’autre.
La classification permet de savoir quelle donnée peut-être mise dans

quel cloud.
La conformité de l’interconnexion doit être alignée aux exigences du
La classification des service hébergé.
données/services, Le multi-cloud multiplie les connexions entre clouds que ce soit des
Gestion de la processus automatisés par l’intermédiaire d’application et d’API ou des
sécurité L’analyse des risques et personnes, la sécurité doit être adaptée à ces nouveaux
alignement avec la fonctionnements.
stratégie de sécurité La sécurité des accès et des identités entre clouds des personnes et
des processus : authentification, autorisation, traçabilité et la
compatibilité sont à contrôler.
La sécurité des mouvements de données est à vérifier.
Pour simplifier il faut prévoir un tableau de bord sécurité.
La création du catalogue de service se fait en approvisionnant les

Gestion du Exigences par service à services dans des clouds différents, le changement de cloud doit être
catalogue et relier avec la sécurité, transparent pour le consommateur. Les SLA du fournisseur de service
niveau de continuité, disponibilité, ne sont souvent pas les SLA du service car le service dépend aussi de
service capacité. la connexion réseau et de tout autre composant rentrant dans la
chaîne de livraison du service.
Possibilité d’utiliser du multi-cloud pour gérer la continuité pour les

services par des mécanismes de redémarrage automatique, ou des
Exigences de continuité services clonés en veilleuse avec multi-localisation.
Gestion de la
par service et risques
continuité
associés Faire attention à respecter les exigences de continuité d’un service lors
du choix de localisation. Multiplier les localisations peut diminuer les
risques climatiques.
Attention à l’effet de la latence de passage vers un cloud sur la

disponibilité du service
Exigences de temps de
Gestion de la Faire attention aux engagements de disponibilité, support compris, du
réponse, de disponibilité
disponibilité fournisseur de cloud par service.
et évaluation de l'impact
Faire attention en multipliant les intermédiaires à ne pas multiplier les
facteurs d’indisponibilité.
Gestion de la capacité par débordement dans le cloud sur un

fournisseur adéquat.
Exigences actuelles,
Gestion de la prédictions d'évolution et Centralisation de la supervision et de l’optimisation
capacité stratégie. Surveillance de
cette évolution et seuil. Faire attention à anticiper le comportement de la demande
capacitaire. Nécessite un retour centralisé des données pour pouvoir
les analyser.
PS : le « catalogue de service » correspond aux services « du portefeuille de service » qui sont mis à
disposition des utilisateurs, conformément à la définition ITIL de ses termes.
 Parenthèse
La conformité a une place majeure dans l’entreprise. Elle doit être aussi prise en compte dans le
choix et le suivi des fournisseurs. L’entreprise imposera de moins en moins ses exigences dans un
monde de standardisation, et qui bouge rapidement, l’entreprise devra de plus en plus contrôler
l’adéquation entre ses exigences métier en conformité et celles proposées par les fournisseurs de
cloud.
Section 2 : Les besoins de l’IT fournisseur de cloud hybride

Après avoir géré l’aspect interface client, nous allons voir les services nécessaires à l’administration.
Les deux étant extrêmement liés, puisque c’est la stratégie métier qui donne la trajectoire de ce qui
sera implémenté.
Pour cette étude nous nous appuyons à nouveau sur les processus ITIL regroupés par étapes : la mise
en exploitation, la production et l’amélioration continue pour les besoins de l’IT. Ces exigences sont
celles de la production.
1) La mise en exploitation
MISE EN
EXPLOITATION
EXIGENCES
OPERATIONNELLES A DEMANDER POINTS D'ATTENTION SPECIFIQUES MULTI-CLOUD
Exigences en termes de
validation et de self-
Centralisation des requêtes de ressources et automatisation,
Gestion des service. Exigences de
orchestration de la mise en place.
actifs et des centralisation de gestion
configurations des ressources et
configuration en
hybride.
La gestion des mises à jour ou patching sur les applications en SaaS et

en PaaS peut être gérée par le fournisseur. Le planning peut être
Exigences actuelles et en
Gestion des imposé.
hybride de centralisation
changements
des changements.
Il faut faire attention aux relations entre applications en se basant sur
la gestion des actifs et des configurations.
L’automatisation du déploiement et des mises à jour est un point

essentiel du cloud hybride élastique pour réduire la complexité et
Gestion des gagner en élasticité, en disponibilité. Elle va s’appuyer sur la gestion
des actifs de service et des configurations.
mises à jour et
Exigences actuelles et en
déploiements,
hybride Le cloud permet de pouvoir facilement faire des retours arrière en
des tests et des
facilitant la duplication d’environnement.
validations.
Attention aux mises à jour qui doivent se faire sur des services que
ceux-ci soient en interne ou transférés provisoirement.
Exigences de
Gestion de la
documentation et Traçabilité de l’emplacement
connaissance
responsables en hybride.
2) La production
PRODUCTION
EXIGENCES
Exigences en termes de
fédération des accès, de
La gestion des accès et leur cycle de vie en interne et en externe est
traçabilité, de sécurité
Gestion des un point important de la gestion de la sécurité. D’où la centralisation
de ces données, par
accès en interne au cloud hybride des identités et des autorisations
rapport aux possibilités
associées.
des fournisseurs de
cloud.
La gestion des demandes de ressources, dans un cloud externe, doit

Gestion des Exigences de validation
garder de l’agilité. La délégation budgétaire est une des solutions à
demandes des demandes
envisager.
Les technologies sont virtualisées, la plupart des services sont

automatisés et certains externalisés ce qui conduit à beaucoup de
changements à anticiper aux niveaux des rôles et des compétences.
Attention à la centralisation du support, en lien avec les exigences du

Gestion des Exigences en termes de
service et les contraintes des fournisseurs de service.
événements, gestion des incidents,
incidents et d'intégration d'outils et
Cette fonction doit être réorganisée et les rôles et responsabilités
problèmes de processus.
doivent être définis. Une gestion des changements est essentielle.
3) L’amélioration continue
AMELIORATION
CONTINUE
EXIGENCES
L’amélioration continue
passe par le suivi de
Faire attention à centraliser les retours d’informations de tous les
mesures pertinentes, il
Gestion de clouds pour pouvoir les analyser facilement et enclencher des
faut donc savoir ce qui
l’amélioration processus de résilience automatiques. Attention à bien gérer le cycle
est essentiel pour
continue de vie des données, en particulier au niveau des sauvegardes et des
l’entreprise : coûts,
archivages délocalisés.
disponibilité, sécurité,
capacité,…
Section 3 : L’analyse des écarts entre la maturité du marché et les

exigences
1) Des challenges technologiques
Il faut prendre en compte les nouveaux challenges comme la notion d’Any Time, Any Where, Any
Device. L’utilisateur doit pouvoir accéder, le plus simplement possible, n’importe quand, de partout,
avec n’importe quel terminal. De plus il peut s’agir d’un utilisateur interne à l’entreprise ou externe
(partenaire, fournisseur, client) car l’entreprise est de plus en plus collaborative.
Les services aussi sont collaboratifs, un service pouvant appeler un autre service.
D’un autre côté les menaces sur la sécurité exigent des connexions de plus en plus sécurisées.
Le CSA a classé en 2011 les menaces du cloud et il a conclu que les 3 incidents les plus fréquents
étaient :
- « Les interfaces et API non-sécurisées » avec 51 incidents représentant 29%.
- « Les pertes et fuites de données » avec 43 incidents représentant 25% des menaces.
- « Les pannes hardware » avec 18 incidents représentant 10% des menaces, mais
s’améliorant de même que la gestion des pics de charge.
Cette étude nous montre qu’il va falloir gérer les accès des personnes, des processus et des systèmes
pour éviter les pertes et fuites de données, les interfaces et API non-sécurisées (API : Advanced
Programming Interface cf. Annexe : API)
2) Entre les exigences et les capacités technologiques actuelles
De cette analyse des exigences nous avons extrait, par rapport notre connaissance de la maturité des
offres actuelles, les points à traiter plus particulièrement. Pour réaliser cette synthèse nous avons
utilisé un SWOT (Strength, Weakness, Opportunity, Threat) ci-dessous. Nous verrons plus en détail la
maturité de l’offre dans la troisième partie dans l’outillage.
Figure 20 : Forces et Faiblesses du Cloud Hybride Elastique
Pour traiter les faiblesses, il faut gérer les points suivants :
- La gestion de la complexité va nécessiter une découverte et une centralisation des

ressources, de leurs configurations et de leurs liens.
- L’automatisation, ressort comme un point essentiel de la réussite d’une infrastructure
de cloud hybride. Elle s’appuie sur la gestion des actifs et des configurations et sur la
gestion des mises à jour et des déploiements.
- La gestion de la demande et des capacités est importante pour connaître les besoins,
les budgets, définir une stratégie, afin d’assurer une continuité de fonctionnement
optimal par rapport aux exigences métier.
- Les changements doivent être pris en compte dès le début du projet pour simplifier les
processus et revoir l’organisation.
En ce qui concerne les risques externes nous verrons également le besoin de faire monter en
maturité des offres actuelles en termes de sécurité, pour le cloud hybride :
- La sécurité des accès des personnes, des processus et des systèmes, la gestion unifiée
des identités et des autorisations sont centrales dans la gestion d’un cloud hybride.
- La sécurisation des données stockées, utilisées mais surtout en mouvement entre deux
clouds sont des points sensibles. Il faut sécuriser et respecter la conformité, dans les
deux clouds et entre les deux clouds par des protocoles et des cryptages ad-hoc.
Ce besoin est porté par l’évolution rapide des menaces : traitement massif possible du cryptage, des
mots de passe, attaques distribuées comme celles de déni de service,…
Nous verrons en quoi les solutions open qui apportent l’interopérabilité et la virtualisation de
l’infrastructure sont de réelles opportunités de :
- pouvoir gagner en efficience,
- développer plus rapidement des innovations technologiques,
- pouvoir faire communiquer ensemble plus facilement des services ou solutions.
 Important
Enfin la supervision est élément essentiel car il va porter l’amélioration continue. Et n’oublions pas
l’objectif : l’agilité. Il faut éviter d’introduire de nouveaux processus qui viendraient bloquer l’agilité
obtenue par l’automatisation en créant des points de blocage, comme des processus de validation
budgétaire ou de sécurité mal conçus.
DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Chapitre 2 : Le catalogue de service du multi-cloud
Chapitre 2 : Le catalogue de service du multi-cloud

Nous allons étudier ces besoins fonctionnels sous l’angle du catalogue de service du multi-cloud ou
cloud hybride Nous allons répondre aux exigences vues ci-dessus par un catalogue de service de
gestion de cloud hybride, pour cela nous verrons le contexte et les services qui composent ce
catalogue, puis nous ferons deux focus sur les engagements contractuels et la conformité en section
2, et sur le modèle de service financier en section 3.
Section 1 : Le catalogue de service du multi-cloud
1) Le contexte des services
L’analyse du contexte par la visualisation des acteurs et des systèmes clés aide à cerner le périmètre
couvert par le catalogue de service du cloud hybride élastique.
Figure 21 : Acteurs et systèmes clés du Service de Cloud Hybride Elastique
2) Le contenu du catalogue de services multi-cloud
Il faut toujours distinguer plusieurs « types » de catalogue de service, celui que le fournisseur de
cloud hybride propose à son client et celui que le client propose aux consommateurs des services.
Le fournisseur de cloud et le client peuvent appartenir à la même entreprise dans le cas du cloud
privé.
Comme nous venons de le voir dans le chapitre précédent : il faut automatiser. Pour connecter un
cloud externe au cloud de l’entreprise, il faut développer les passerelles correspondantes au
catalogue d’APIs, c’est l’intégration. Dans les clouds connectés, il faut pouvoir déployer, administrer
et superviser des services. Pour cela il faut s’appuyer sur des modèles, des buildings blocks, des
programmes qui accepteront des paramètres afin de pouvoir réutiliser les développements et
surtout déplacer facilement des charges de travail, c’est le design de l’automatisation qui crée des
Services Templates et les utilise avec des règles, des seuils et des mesures
Figure 22 : Catalogue de Service du Cloud Hybride Elastique
Nous nous intéressons au catalogue de service du fournisseur de service cloud, pour les acteurs ou
administrateurs clients chargés :
- de l’intégration pour fournir un catalogue de passerelles, par api ou appliances, mises

à disposition (APIs AWS EC2, S3, OpenStack, Salesforce,…),
- du design de l’automatisation de la configuration, l’approvisionnement, le
déploiement, le paramétrage de ressources que ce soit des ressources matérielles ou
logicielles, de fonctions (bascule de charge, DNS, DHCP, Embarquement, Débordement
…), de services, de flux,
- de l’administration :
o de la configuration, l’approvisionnement, le déploiement, le paramétrage de
ressources, de fonctions (DNS, …), de services, de flux respectivement pour du
IaaS (Stockage, Traitement, Bases), du PaaS, du SaaS ou du BPaaS,
o du catalogue de service consommateur, et du portefeuille : la construction, la
mise à disposition,
o financière : affectation de budget,
o de la capacité,
o des accès et de la sécurité,
o des fonctions multi-cloud : débordement, embarquement,…
- la supervision et l’optimisation :
o de la facturation et des contrats,
o de l’usage des services au catalogue,
o de la capacité,
o des performances, de la disponibilité, du respect des SLA,
o de la sécurité,
o des fonctions multi-cloud : débordement, embarquement,…
- la réalisation du support ou helpdesk, la partie alerte de la supervision,
- la configuration des règles (seuil, défaillance, analyse),
La supervision du CLOUDaaS permet grâce aux remontées d’information et de mesures, de

comparer les performances des fournisseurs (capacité, disponibilité, rapidité, coût, sécurité…).
 Important
En ce qui concerne le multi-cloud ces services doivent être centralisés, avec une interface
standardisée. Les paramètres doivent être accessibles. La supervision doit permettre une vue
d’ensemble, même si l’accès à chaque portail fournisseur peut rester accessible sous forme d’onglet
dans un navigateur.
Le consommateur dispose d’un portail unique extrait du catalogue de service construit par
l’administrateur du catalogue de service consommateur, et personnalisé à partir de ses autorisations,
disponibles dans l’annuaire.
3) La description des services spécifiques
2.1) L’intégration : les passerelles
Comme nous venons de le voir dans le chapitre précédent : il faut automatiser. Pour connecter un
cloud externe au cloud de l’entreprise, il faut développer les passerelles correspondantes aux APIs.
Dans les clouds connectés, il faut pouvoir déployer, gérer et superviser des services. Pour cela il faut
s’appuyer sur des modèles, des buildings blocks, des programmes qui accepteront des paramètres
afin de pouvoir réutiliser les développements et surtout déplacer facilement des charges de travail.
Il faut intégrer des liens vers des clouds externes à l’aide de catalogue d’APIs (AWS EC2, S3,
OpenStack,…).
Les liens permettent d’accéder via un standard RESTful (cf. Dictionnaire) aux fonctionnalités offertes
par les fournisseurs de cloud. Le fournisseur de cloud hybride doit disposer d’une interface ou
passerelle lui permettant de faire le lien entre l’interface qu’il fournit à ses clients (internes ou
externes), et les différents modules de compatibilité (APIs) proposés par les fournisseurs de cloud.
Ces APIs sont de plus en plus disponibles via des « places de marché » (market place) ou des
« magasins » (store), facturées ou offertes pour promouvoir le produit. Ces APIs sont susceptibles
d’évoluer, d’où l’importance de la standardisation, de l’interopérabilité, pour simplifier le maintien.
Les API(s) sont de différents types :

- de calcul,
- de stockage,
- de réseau,
- de fonctionnalités : répartition de charge, firewall, DNS,…
- d’administration et d’orchestration, automatisation : IaaS, PaaS, SaaS, BPaaS, financière,
catalogue…,
- de supervision : permettant de récupérer des données pour analyse,
- de gestion de l’identité et des accès,
- de support.
La passerelle du cloud hybride sert à intégrer les différentes librairies d’API des clouds externes.
L’intégration consiste à faire le lien entre des fonctionnalités internes et externes. Les fonctions n’ont
pas toujours mêmes noms pour une même fonctionnalité, par exemple pour approvisionner une VM
il serait possible de trouver approVM() ou appVM(), pour une fonctionnalité identique. Il peut y avoir
un nombre de paramètres différents même entre deux versions comme par exemple le nombre de
rôles entre la version Folsom et la version Grizzly de Keystone OpenStack. Mais surtout les fonctions
peuvent être très différentes, avec des paramètres différents, des fonctionnalités différentes, des
gestions de la sécurité différentes. Elles peuvent évoluer, des fonctionnalités supplémentaires
peuvent être créées.
2.2) Le design de l’automatisation
Pour faciliter l’interopérabilité du déploiement d’un service quel que soit le cloud dans lequel il est
déployé, il faut s’appuyer sur un catalogue standardisé de « Service Template » ou « Blueprint de
service ».
Les fonctions réseaux, stockage et calcul du fournisseur (bascule de charge, mappage, tiering),
Ces fonctions existent dans le cloud, en général dans un environnement homogène au niveau des
outils de gestion.
Pour résoudre des soucis de bande passante il faut pouvoir grouper des réseaux (teaming). Pour
répondre à des besoins de performance il faut créer des clusters de stockage ou de calcul. Dans tous
les cas il faut pouvoir libérer ses ressources.
Là aussi la virtualisation, le « software defined », et la standardisation de l’automatisation, vont nous

aider à pouvoir automatiser et donc configurer « à la volée » pour réaliser toutes ces actions
dynamiquement.
2.3) La configuration du réseau et des fonctions réseau inter-cloud
Il faut réussir à faire circuler des flux entrants et sortants à partir du cloud interne et du cloud
externe, synchronisés.
L’administrateur de cloud hybride élastique doit pouvoir configurer des éléments réseaux pour
affecter des adresses, choisir des protocoles, optimiser le chemin, faire de la QoS, gérer des listes de
contrôles d’accès, configurer des sous-réseaux, des firewalls. Ceci devient possible avec la
virtualisation du réseau, le « software defined ».
Des routeurs virtuels et des outils de gestion type CNAM de CISCO installés dans une machine
virtuelle peuvent être ajoutés chez le fournisseur de cloud externe pour réaliser une continuité
opérationnelle de supervision.
(Un projet d’outillage open source du DNSaaS est envisagé par le groupe OpenStack.)
2.4) Les fonctions du cloud hybride : débordement, embarquement,…
Pour réaliser du cloud hybride élastique il faut pouvoir déplacer des services basés sur des systèmes
complexes, comme des applications « n-niveaux » (à plusieurs niveaux de type Web, Appli, Base par
exemple) entre des environnements hétérogènes en termes de technologie, de fonctionnalité. Les
fonctions du cloud hybride s’appuient sur deux autres services du cloud hybride : le design de
l’automatisation et la configuration de la connexion réseau entre clouds.
Les fonctions nécessitent de :
- Configurer des conditions (seuil, défaillance, analyse),

- Configurer des méthodes de bascule de charge (snapshot, clone, image, pattern,
runbook, mappage) et les services templates associés.
- Faire le suivi des fonctionnalités des liaisons existantes (interface, sauvegarde, etc…).
2.5) L’administration de la gestion de l’identité et de l’accès
La gestion de l’identité et des accès, pour faire une continuité entre l’interne et l’externe, est
intégrées dans les passerelles par des APIs spécifiques. L’objectif est le Single Sign On, c’est à dire que
l’utilisateur du service ne s’authentifie une seule fois sur le portail d’accès. Il est important cependant
de continuer à savoir, qui fait quoi, et donc de pouvoir tracer l’identité dans le cloud externe.
Il faut donc mettre en place un mécanisme de confiance entre les clouds, par certificat, clés
publiques, qui vont servir lors de l’authentification par token et transmettre l’identité de l’utilisateur
ou du processus automatisé.
2.6) La gestion de la demande et de la capacité
La gestion de la capacité va s’appuyer sur la connaissance des ressources. C’est une exigence et donc
un service majeur. Il entre dans la gestion du cycle de vie.
a) La gestion de la demande et la proximité métier
La capacité service et la capacité composants se déduisent des besoins de capacité business.
Sur du cloud privé, en fonction de la taille du Datacenter, des limites de variation de capacité
peuvent être nécessaires pour pouvoir répondre aux variations de charge. Tous les utilisateurs ne
peuvent pas doubler en même temps leur capacité : pour limiter le risque il faut préconiser des tarifs
heures de pointes et heures creuses, ou une gestion de règles de priorité platine, gold, silver peuvent
aider à lisser la demande en automatisé.
Il faut comprendre et anticiper les besoins de chaque métier qui pourront déclencher du
débordement, un déplacement ou une demande de continuité et leur éligibilité à l’externalisation :
les pics de charge, les projets, les analyses massives de données, les services sensibles ou critiques.
Ceci peut paraître simple mais demande une implication forte : des métiers dans l’expression de
leurs exigences, et des responsables IT pour le traduire en solutions, en services.
b) La gestion de la capacité
En cloud hybride il faut récupérer les indicateurs des divers clouds, pour les gérer, les superviser, les
améliorer.
La gestion de la capacité en phase de transition et opérationnelle c’est aussi automatiser, mesurer,

auditer, analyser, pour optimiser les ressources, améliorer la fiabilité, la rapidité, la résilience et aider
le respect des niveaux de service contractualisés (Cf. : Développement des processus dans la
troisième partie).
Section 2 : Les engagements contractuels et la conformité
1) Les engagements contractuels dans le cloud hybride
1.1) La contractualisation des niveaux de services
Les S.L.A. ou Service Level Agreement sont une contractualisation sur des niveaux de service entre le
fournisseur d’infrastructure et son client. Les O.L.A. ou Operational Level Agreement sont la
déclinaison de ces engagements, avec les acteurs internes ou sous-traitants qui contribuent au
respect du contrat. Dans le cloud public cette donnée est souvent imposée par le fournisseur de
cloud, car liée à son infrastructure. Le rôle du client est alors de comparer les exigences du service,
les S.L.R. ou Service Level Request, avec celles accessibles en externe pour savoir s’il externalise.
a) La relation entre service et exigences métier
L’outil de gouvernance doit donc associer à chaque service en fonction de la classification du service
ses caractéristiques de :
- disponibilité (temps d’indisponibilité maximum, temps de réponse, temps d’accès),

- sauvegarde (rétention, fraîcheur, point de restauration, planification),
- capacité et performance de ces capacités (puissance, stockage, bande passante),
- sécurité et conformité (traçabilité, auditabilité, localisation, logging, rapports),
- facturation (historique, fréquence).
Un service ne peut migrer d’un cloud à l’autre que si le service fourni reste conforme aux exigences.
Nous avons donc un ensemble de règles par service à contrôler.
b) L’enchaînement des SLA
Le SLA de disponibilité de 99,9… du fournisseur de cloud n’est souvent pas celui du service, car il faut
le multiplier par le SLA de la connexion internet. Il en est de même avec le cloud hybride, où les
éléments de connexion et de gestion centralisée doivent être pris en compte dans la chaîne complète
de la disponibilité. D’où l’importance de bien étudier la redondance et la résilience de TOUS les
éléments de la chaîne, et ceci pour TOUS les engagements de service.
Les engagements internes ou sous-traités
Dans un cloud hybride élastique, quand l’entreprise s’engage sur des SLA avec ses clients métiers,
elle doit porter une attention particulière aux engagements opérationnels OLA, afin de vérifier la
faisabilité de ses engagements.
 Important
Ceci se traduit concrètement par l’enregistrement dans les règles, du niveau de conformité souhaité
par service. Il faut ensuite superviser les mesures ou métriques associés, afin de vérifier la continuité
lors du déplacement du service d’un cloud à l’autre, et l’évolution de la qualité de service dans le
temps.
1.2) Le suivi par les métriques en cloud hybride
Le suivi de cette contractualisation se fait par les Service Level Operationnal (S.L.O.), les mesures
(métriques) et l’évolution (Key Product Information).
Le choix de métriques ou d’indicateurs de performance clés sont fonction des possibilités offertes par
le fournisseur de cloud.
 Important
Ces indicateurs sont calqués sur les exigences du service de l’entreprise.
Leur ajouter des contrôles internes est essentiel : les indicateurs clés de disponibilité et de temps de
réponse pour un service peuvent être mesurés par l’ajout d’applets au niveau du poste client, par
exemple.
Dans un cloud hybride le client doit pouvoir suivre le respect des exigences de service en
disponibilité, continuité, sécurité, performance, par une fédération des remontées de métriques
standardisés et par des mesures internes.
Des outils sont donc indispensables, au niveau de l’hyper-orchestration, pour assurer le suivi.
2) La conformité
Le fournisseur de service peut être conforme à des recommandations, des réglementations, des lois,
des normes, des standards.
Cette conformité va s’appliquer à l’ensemble du cloud hybride, y compris par exemple le cloud sur
lequel un fournisseur de cloud va transférer des sauvegardes, mais plus particulièrement pour un
cloud hybride il faut assurer la conformité des fournisseurs de cloud et de la liaison qui nous relie à
eux. Par exemple une connexion conforme PCI-DSS 3.0 de paiement carte bleue, doit respecter les
prérequis y compris pour le transfert.
Ceci nous oblige à engager nos fournisseurs à être transparents sur leur fonctionnement pour
s’assurer que les services confiés respectent bien les niveaux de conformités requis, les exigences du
service. Et faire un suivi de l’évolution des conformités
Exemples de conformités : CNIL, ISO- 27001, SSAE 16, SOC_2, ISO 270017, ISO 27002, PCI DSS, SOX,
Bâle, Cobit, SAS170, EAL4+ et (FISMA=0S).
Section 3 : La vue financière du modèle de service
1) Les modèles de facturation
1.1) Les challenges du calcul des coûts
a) Les challenges
Les modèles de facturation se heurtent à plusieurs challenges :

- le calcul des coûts en interne, leur répartition,
- le suivi de la consommation en interne par des outils de charge back,
- le suivi et l’agrégation des coûts externes renvoyés par les outils de charge back externes,
- les choix de facturation interne et de répartition.
b) La répartition des frais de structure du cloud hybride
Les charges du cloud hybride : hébergement, sauvegarde, réplication, infrastructure et logiciel,

consommation, maintenance, support, sont à répartir logiquement sur le cloud privé et sur
l’approvisionnement externe.
c) Les charges du cloud privé spécifiques en transverse
Nous sommes sur le même modèle que la répartition des charges dans une copropriété ou une
colocation. Les charges transverses doivent être réparties au prorata de l’utilisation, et le
copropriétaire ou colocataire, pour nous le service, doit pouvoir anticiper ses charges.
Si vous voulez rajouter une prestation sur votre environnement, porte blindée, serrure 3 points, c’est
à la charge de l’intéressé. De même pour le service si on doit ajouter de l’isolation.
Par contre l’entretien de l’ascenseur et des parties communes sont partagées. A ce niveau-là par
contre sur les services, il peut y avoir une différence de facturation sur les flux entrants et/ou
sortants, mais ce n’est pas systématique.
Il existe des immeubles de standing différents avec déjà différents niveaux de sécurisation : caméras,
interphones avec des horaires de concierge différents qui influent sur le prix de location de
l’appartement et sur les charges. De même dans le cloud il faut trouver une répartition équitable des
charges communes, qui est par contre inclus dans le prix de base de la location du service cloud. Les
services cloud sont de différents niveaux : support, isolation, disponibilité et ceci se répercute sur le
prix de mise à disposition d’internet.
L’agrégation des informations servant à la facturation
La tarification peut se comparer à celle du téléphone ou du parking : l’instance peut être facturée dès
que le mois, l’heure est entamée ou sur le temps réellement utilisé, mais il ne faut pas oublier que
plus l’outil de mesure est précis, plus le flux d’information prend des ressources. De plus il faut
agréger pour en faire un tableau de bord simple et fonctionnel.
Les difficultés techniques
Nous sommes sur les problématiques habituelles, comme par exemple la difficulté à répartir le coût
d’une vCPU, sachant qu’il y a plusieurs vCPU pour une CPU, que beaucoup sont sous utilisées et que
généralement c’est la réservation de vCPU que l’on facture et non son utilisation.
Les charges élastiques
Les charges élastiques externes sont facturées à l’usage par le fournisseur de cloud. La mise à
disposition des outils de gestion d’alignement de la capacité sur les besoins, est également facturée
(cf. CloudWatch d’AWS, …).
Les charges élastiques internes
En général un moteur est intégré dans les instances pour mesurer tous les éléments qui serviront à
l’application de facturation qui dispose des paramètres des engagements financiers.
1.2) Le modèle marketing et modèle coût de possession
Il existe globalement deux approches : marketing ou marché et TCO
Le client a besoin d’un retour sur investissement en valeur pour le métier ou par une baisse de coûts.
Le fournisseur doit couvrir ses coûts. Il existe des produits d’appels et des produits de forte
consommation.
La maîtrise des coûts pour le client est un aspect essentiel du cloud hybride élastique ouvert, elle va
permettre au client de changer de fournisseur de service ou de type de service facilement en
fonction de l’évolution des prix, des performances, de la qualité de service de son fournisseur, de ses
concurrents, de l’évolution de sa consommation, de ses besoins. Elle lui permet aussi beaucoup plus
d’agilité et de ne payer que ce qu’il consomme.
Le modèle marketing va prendre en compte ses différents aspects.
1.3) Les exemples de modèle financier
Le modèle financier va s’adapter aux exigences. Dans un modèle de cloud hybride élastique les
services sont approvisionnés en rapport d’abord avec les exigences et ensuite au meilleur coût.
Les exigences peuvent être de disponibilité, de sécurité, de capacité…
a) Un exemple de modèle financier fonction de la capacité
La capacité peut-être de traitement, de stockage ou de réseau. Il est possible donc d’implémenter un

modèle de mesure pour paiement basé sur la consommation, de type CPU/heure, utilisateur/web
conférence/heure, Transaction de base de données/Go/mois.
Le système de paiement peut aussi être basé, de façon complémentaire ou non, sur la prédictibilité
de la demande ou l’engagement. Ce qui permet de pouvoir mieux anticiper la capacité, il y a alors
moins besoin de surcapacité prévisionnelle, ce qui baisse les coûts. C’est moins vrai sur des clouds
s’appuyant sur des datacenters massifs.
Par exemple pour répondre aux besoins de capacités et à des montées en puissance :
- Paiement à la demande : les ressources allouées à la demande sans pré allocation. Pour
les besoins provisoires de ressources, utilisées ponctuellement, pour une courte durée,
et jetées.
- Réservé : 100 % des ressources sont réservées et garanties. Pour des applications à
consommation stable et prévisible. Le tarif peut être moindre mais avec engagement.
- Alloué : un pourcentage des ressources est réservé avec un engagement pour une sur-
demande.
Pour des services avec une consommation de ressource qui monte en puissance et qui
libère dynamiquement.
 Important
Dans le cloud hybride ces règles doivent être écrites pour allouer dynamiquement les services.
b) Un exemple de modèle financier fonction de la sécurité
Pour faire de la sécurité des données ou des services : de l’isolation, du cryptage, des sauvegardes,
du stockage, augmenter la disponibilité, suivre les logs, prévoir la continuité de service… il faut des
outils et ses outils ont un coût. Le modèle financier doit donc les intégrer.
Ces caractéristiques seront en fonction des clouds choisis soit de base, soit en option, soit non-
fournies.
2) Les modèles de gestion financière en interne
En interne le catalogue de service doit prendre en compte l’administrateur financier. En effet après
avoir créé de l’agilité il ne faudrait pas la reperdre par des processus de validation fastidieux. De
même qu’il sera intéressant de déléguer des plages IP pour l’attribution automatique, il est
important de déléguer des budgets pour laisser de la souplesse d’action aux métiers pour ne pas
courir le risque de voir se développer de la « shadow IT ».
Le catalogue de service du cloud hybride doit donc inclure des services qui permettent au financier
de déléguer, mais aussi de superviser, en liaison avec l’usage, d’analyser, de planifier.
DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES Synthèse de la deuxième partie : Exigence et catalogue de Service
Synthèse de la deuxième partie : Exigence et catalogue de Service
Pour résumer cette partie, nous vous proposerons deux schémas :
- Le premier bâti suite à une analyse basée sur les étapes ITIL : stratégie, conception, mise en
exploitation, production, amélioration, résume les exigences essentielles du cloud hybride élastique.
Le deuxième résume le catalogue de service du cloud hybride élastique :
L’importance de l’automatisation/orchestration, de l’intégration des APIs et de la sécurité sont

ressortis comme centraux en ce qui concerne les mécanismes.
La nécessité de gérer le changement en amont du projet est un élément capital de la mise en œuvre.
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE Chapitre 1 Les processus
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE
Nous étudions les processus en chapitre 1 et l’outillage en chapitre 2. Nous nous intéressons à ceux
qui sont essentiels pour réaliser les services du cloud hybride élastique, qui sont ressortis de notre
analyse des exigences et des services du cloud hybride élastique.
Chapitre 1 Les processus

Nous focalisons sur les processus d’automatisation et d’orchestration. Puis nous aborderons les
processus d’accès, de supervision de la capacité et de centralisation de la facturation sans lesquels il
serait impossible ou difficile d’automatiser.
 Parenthèse
Dans la définition ITIL un processus est un ensemble d’activité structuré, conçu pour accomplir un
objectif spécifique. Un processus à une ou plusieurs entrées définies, qu’il transforme en une ou
plusieurs sorties définies. Donc pour chaque processus nous regarderons les entrées, les sorties et les
activités.
Sans maturité des processus, impossible de faire du cloud efficient. Le cloud hybride élastique est
encore plus exigent en terme de maturité.
Nous avons vu dans la partie précédente que les processus importants pour la gestion du cloud
hybride étaient :
- la gestion des actifs de service et de leur déploiement, leur configuration, leur mise à jour,
- la gestion de la capacité qui inclut la supervision, l’analyse et l’amélioration des performances,
- la gestion financière,
- la gestion de la sécurité.
Section 1 : Les processus de mise à disposition

Dans les processus de mise à disposition nous allons retrouver l’inventaire, la configuration, le
déploiement, le changement mais pour le cloud hybride élastique l’important est l’orchestration de
l’automatisation.
1) L’inventaire complet dynamique et la configuration.
Entrées /Sorties
La complexité des systèmes ne permet plus de les gérer artisanalement. Ceci implique une mise à
jour automatique par des moteurs des configurations et donc une normalisation, standardisation,
des remontées de données :
- Pour le matériel, par des mécanismes de plug and play avec des puces qui permettent de remonter
les caractéristiques de la ressource.
- Pour tous les logiciels, dans les formats standards.
Certaines des données sont alors stockées dans les bases du fournisseur de cloud qui doit pouvoir
échanger des données avec celles du cloud hybride. Il est important de pouvoir échanger non-
seulement les données, mais aussi leurs typologies, leurs schémas. La standardisation est
importante pour simplifier l’intégration.
Certaines données sont remontées directement par les mécanismes de découvertes dans les bases
du cloud hybride.
Les données ainsi stockées dans des bases feront partie des entrées des processus d’automatisation.
Les activités du processus de découverte sont de :

- répertorier les ressources,
- historiser les configurations,
- connaître les relations entre les composants,
- mettre à jour.
Les capacités et les possibilités de ses ressources sont les bases de l’automatisation.
2) Le déploiement et la mise à jour
2.1) Le déploiement classique

Entrées/Sorties
Les ressources de traitement, de stockage, de réseau et applicatives une fois découvertes et placées
dans des bases, doivent être configurées. Par exemple pour l’infrastructure :
- La puissance de traitement est groupée en cluster, pool, accueille un hyperviseur, un
OS, outils,
- Le stockage est groupé en cluster, le type de file system est choisi et appliqué au
formatage, le stockage est attaché et partagé, des mécanismes de duplication,
réplication, tiering, zonage sont mis en place,
- Le réseau est groupé en teaming, le firewall est configuré par VM ou par groupe de VM
pour isoler des multi-tenants, des sous-réseaux ou des VLAN sont créés,
Et également pour la partie plateforme applicative et celle des business process :
- L’application ou l’operating système sont installés et paramétrés,
- Les flux d’actions sont paramétrés,
Donc le processus de déploiement consiste à :

- configurer, regrouper et relier les ressources,
- mettre à jour les versions.
2.2) Le déplacement, la copie ou le redéploiement du service
Dans le cloud hybride élastique les charges de travail se déplacent et les copies sont reconfigurées à
la volée.
Déplacer Pour Contre
Rigide + Soucis de
Clone de VM Temps de déploiement Compatibilité
Blueprint,
composants,
topologie Souple Temps de déploiement
Ce processus a donc en entrée un service qui doit être déplacé pour fonctionner dans un autre cloud.
a) Le service déplacé ou redéployé
La question qui se pose pour le déplacement est de savoir si on déplace un template, un clone, un
snapshot, ou un blueprint de la machine virtuelle, ou du volume de stockage.
 Parenthèse
Le template, ou exemple, de VM correspond à un master, une image qui va pouvoir servir à déployer
plusieurs instances.
Le clone, ou copie, de VM est une copie d’une machine virtuelle existante déployée et paramétrée, il
sert plus à sauvegarder un environnement, de développement par exemple, que l’on est susceptible
de reprendre.
Le snapshot, ou instantané, de VM est plus utilisé pour faire une sauvegarde à un instant T, avant
d’effectuer des modifications, pour pouvoir faire un retour arrière si la modification ne convenait
pas.
Le blueprint de VM est une image à l’état brut et d’un ensemble composé d’informations qui vont
nous permettre de déployer une machine virtuelle.
Le Service Template est composé de l’ensemble des composants permettant de redéployer un
service : comportement, topologie,…
Le service est un ensemble, il est souvent très complexe.

Les services sont généralement composés d’un ensemble de système et d’un ensemble applicatif. Il
s’agit souvent d’applications multi-niveaux (n-tiers).
La figure ci-dessous est un exemple de ce que nous trouvons en entrée sous forme de composants,
de topologie, de comportement et en sortie, sous forme d’implémentation spécifique, d’un
processus de déploiement.
Figure 23 : Exemple de complexité de service multi-niveaux
Déplacer un service c’est donc déplacer et reconfigurer un ensemble constitué de machines

virtuelles, de stockage (qui contiennent des données, des fichiers des bases de données, des
applications), de réseau et de liens internes et externes, avec une topologie et ses contraintes, ses
règles, ses politiques, ses conformités. Il est possible de déplacer un service en changeant ses
paramètres, en fonction du cloud sur lequel il va se situer. Il est possible de déplacer un service en
changeant sa topologie, par exemple si l’on a un environnement de développement et que l’on
souhaite un environnement de production : le nombre de VM, l’isolation,… peuvent changer.
 Parenthèse : l’interopérabilité
Il faut transformer les images pour les rendre compatibles : enlever les outils propres à chaque cloud
(moteur, outil de mesure, de facturation, …).
Pour être compatible avec des clouds hétérogènes on utilise ce qu’on appelle des images à l’état brut
de services, interopérables, les blueprints, sans les outils. Les outils propres à chaque fournisseur de
cloud comme ceux de facturation, ou de lancement de tâches, sont souvent non-compatibles d’un
cloud à l’autre ou d’un standard différent.
Des standards de Topologie…type TOSCA, se développent et vont permettre de déployer des
applications complexes quel que soit le cloud.
Le service doit pouvoir se déplacer avec son environnement : sa politique de sauvegarde et de

restauration, de sécurité, de configuration, … et s’adapter à son environnement d’accueil : ses outils
de sauvegarde, de facturation, d’automatisation,…
C’est en général plus long qu’une copie, puisqu’il faut redéployer. La technologie ne fera sans doute
pas du temps réel de redéploiement pour la plupart des services.
Les activités pour redéployer sont globalement :

- d’établir la liaison après choix du service cloud,
- de faire la copie, et le rassemblement des composants dont la structure du service et son scénario
de déploiement,
- de copier ou déplacer tous les éléments, de dérouler le scénario (configuration, déploiement),
b) Le Lancement du service
Nous séparons les deux processus : copie/déploiement et lancement.

La copie est réalisée en amont du besoin et prête à être lancée.
Ce processus de lancement de service est déclenché soit à la fin du déploiement, soit par un seuil sur
la capacité ou à un moment planifié. Des critères doivent être établis pour libérer la ressource, soit
sur la capacité, soit sur une durée de vie ou autre.
Les activités de ce processus sont :

- de vérifier les seuils ou demande,
- de lancer le service.
3) L’automatisation, l’orchestration
Le nombre exponentiel d’opérations de service, la fréquence des changements et l’augmentation du

nombre de service externes démarrant à la demande requièrent une approche d’automatisation /
orchestration.
3.1) Le processus d’automatisation
Figure 24 : Exemple de processus d’approvisionnement de service en hybride
La principale entrée du service d’automatisation est la demande d’action : déploiement d’un service,
déplacement d’un service d’un cloud à l’autre, libération de service…
Pour automatiser il faut d’abord mettre par écrit les scénarios qui vont nous servir à définir la
topologie du service et approvisionner tous les composants matériels et applicatifs.
Ses scénarios sont contrôlés par :
- des règles (what if),

- des profils ou rôles,
- des seuils, des déclencheurs,

- des exigences de disponibilité, conformité, sécurité, coût, SLA, …,
- des mesures,
- des flux d’approbations.
L’automatisation va enchaîner des instructions de travail, qui vont permettre de configurer et relier
des composants des services.
Les activités de l’automatisation dépassent celles du déploiement et de la configuration :

- configurer les ressources,
- enchaîner les processus de configuration,
- mettre à jour la base de ressources intégrées,
- de superviser, analyser, corriger à partir des données de supervision remontées…
3.2) Les différents niveaux d’orchestration
Figure 25 : Les niveaux d'orchestration du CLOUDaaS

 Important
L’orchestration va enchaîner des briques d’automatisation. La nuance entre orchestration et

automatisation n’est pas toujours claire. Le mot « orchestration » est utilisé pour le niveau au-dessus
qui permet un aspect transverse et intègre des règles complexes, des buts et objectifs plus larges,
même s’il s’agit toujours bien d’automatiser.
En IaaS des scénarios de déploiement et de configuration d’infrastructure (du matériel aux

fonctions), en PaaS des scénarios de déploiement et de paramétrage d’applications (middleware,
application, base de données, framework, SDK…), en SaaS des scénarios de paramétrage logiciel
couplés au profil utilisateur, en BPaaS des scénarios de paramétrage de flux de travail, d’approbation.
Figure 26 : Orchestrer, automatiser, gérer en hybride
L’orchestration technique ou système :

- flux d’actions techniques,
- modifier un firewall,
- ajouter un middleware,
- créer un serveur scripts,…
L’orchestration les environnements :

- déploiement d’application (vApp),
- déploiement de systèmes complexes (vSys),
- déploiement de VApplication…
- gestion capacité, placement, élasticité
L’orchestration des applications, des services :

- supervision,
- interactions entre équipes,
- approbations,
- réservations & quotas,
- mise en exploitation,
- facturation,
- mise à jour des bases CMDB, CMS,…
- intégration systèmes tiers.
L’orchestration de flux métier, de business processus :

- flux d’action,
- flux d’approbation
- supervision des flux et amélioration.
Pour les applications plus complexes les scénarios de déploiement et de configuration enchaînent les
scénarios simples, et peuvent lier des scénarios de déploiement et de configuration d’infrastructure
et d’application par exemple pour des applications n-tiers.
1-Charge
Consommateur Firewall Agent de service de Serveur virtuel

montée en charge Instances
de service cloud
2-Réplication
Figure 27 : Exemple de processus de montée en charge
Pour des fonctions de type équilibrage de charge, ou de montée en puissance n-niveaux, les
scénarios enchaînent les actions de provisioning, de configuration, de paramétrage de ressources.
Des outils de mesures remontent les données et des règles fixent les seuils de déclenchement des
actions. Les scénarios peuvent être couplés à des flux d’approbations, d’actions ou d’informations.
Les scénarios d’orchestration enchaînent des scénarios, IaaS, PaaS, SaaS et BPaaS, en dépassant les
frontières des modèles de service.
Les services d’orchestration cloud sont composés d’architecture (topologie, schémas, scénarios),
d’outils et de processus définis par des personnes, s’appuient sur du matériel et du logiciel,
connectent et automatisent des flux d’actions technique, application, service, métier pour délivrer un
service défini.
C’est eux qui permettent l’élasticité du cloud hybride
4) L’orchestration de l’hybride
 Important
Pour le « Cloud as a service » il s’agit d’abstraire la notion de cloud. Le consommateur de service doit
approvisionner un service sans se soucier du cloud sur lequel ce service tourne. Pour les
administrateurs c’est un peu différent, ils ont besoin de visibilité.
Avant de pouvoir administrer simplement il faut pouvoir automatiser à partir d’une interface unifiée
le déploiement de service sur de multiples cloud. C’est une fonction essentielle de l’outil de gestion
de clouds.
4.1) L’Orchestration de l’hybride
Figure 28 : Orchestration du déploiement en hybride
Il s’agit d’orchestrer un service de bout en bout, quel que soit son modèle de service et à travers des
modèles de déploiement multiples : public, privé, communautaire et des modèles de services
multiples : IaaS, PaaS, SaaS et BPaaS.
L’orchestration de l’hybride doit être en mesure pour le provisionnement :

- de transmettre des scénarios à l’orchestrateur d’un cloud externe,
- de fournir des informations de démarrage, de déploiement ou de
décommissionnement à de multiples clouds par des interfaces (API, matrice de
compatibilité,…),
- d’assurer le déplacement de tous les composants des modèles de déploiement
(Services Templates), des charges de travail, et d’informations, en fonction de critères
techniques ou métiers,
- d’assurer la sécurité des services et des informations déplacés,
- de pouvoir maintenir les interfaçages des services déplacés,
- de rendre « transverse-cloud » des flux d’actions.
Pour le contrôle :
- de mesurer, superviser techniquement,
- de mesurer, superviser la facturation et la consommation,
Pour ceci il faut des interfaces, de la normalisation…et une faisabilité technique.
Section 2 : La capacité
1) Le processus de gestion de la demande
L’entrée principale est le schéma dans le temps de la demande, et les prérequis des services, qui
permettent d’analyser la saisonnalité de la demande et de savoir la continuité, la capacité et la
disponibilité exigées par le service. Il va servir à planifier la capacité, à anticiper les pics de charge qui
peuvent conduire à une externalisation de service.
2) Les processus de gestion et de supervision de la capacité
Les activités de supervision, de suivi des performances vont nous permettre d’enclencher du support
mais aussi de suivre les performances et les capacités.
Dans le cloud hybride c’est la supervision capacitaire qui permet d’enclencher le débordement,
l’embarquement d’une charge de travail dans un cloud externe.
2.1) La mesure et le contrôle
Le suivi est indispensable pour l’optimisation de la capacité utilisée, la performance, la continuité de

service, et permet de gérer l’efficacité, la base de connaissance, l’amélioration continue…
Dans le processus d’automatisation les valeurs mesurées sont comparées à des seuils et déclenchent
des actions prévues dans un scénario. Dans le cloud hybride élastique c’est un élément central de
déclenchement de déploiement et de décommissionnement de ressources.
2.2) L’analyse
L’historique des mesures et des déclenchements peuvent alimenter une base de connaissance pour
améliorer le fonctionnement global.
Dans le cloud hybride de Sogeti SkySight, des tableaux de bord sont disponibles pour les différents
responsables : technique, exécutif, financier.
Section 3 : La gestion financière

Dans un esprit de service, détacher l’administrateur financier des rôles d’administrateur technique
permet de mieux gérer son budget.
L’administrateur budgétaire client va pouvoir gérer des délégations budgétaires, effectuer le suivi de
la facturation multi-cloud, comparer les prestations de services des différents fournisseurs cloud.
1) La délégation budgétaire
Les utilisateurs doivent souvent recevoir une approbation pour utiliser un service. Parfois cette
approbation est par type de service. Quand il s’agit d’approvisionner des ressources en externe le
suivi financier est capital et le risque est grand de bloquer l’agilité acquise par l’automatisation par
des processus de validation budgétaire trop lourds.
Il est intéressant de pouvoir affecter des budgets, par un mécanisme de délégation budgétaire. C’est
alors au portail du cloud hybride de fournir un tableau de bord au consommateur de service pour
qu’il puisse à la fois gérer ses demandes de budget, leur validation, l’évolution de sa consommation
et de son budget. C’est une fonctionnalité intéressante que l’on retrouve par exemple dans
Enstratus, outil de gestion centralisé de cloud.
2) Le suivi de facturation centralisé
La centralisation du suivi va permettre de gérer plus simplement la complexité. Elle permet de suivre
en temps réel la facturation et de pouvoir mettre des seuils d’alerte. Ce processus dispose en entrée
des remontées de facturation des différents clouds, par un système d’interfaçage, soit en temps réel
soit sur abonnement en fonction du mode de facturation choisi.
3) La comparaison de services
Il est possible de vouloir un processus de comparaison de tarifs de fournisseurs de services cloud, par
simulation, pour des services standards de stockage ou de traitement, par exemple. Pour affichage
sur un tableau de bord ou afin de pouvoir automatiser le choix du cloud le moins cher pour le même
service.
Il est intéressant de pouvoir analyser sa consommation dans le temps pour l’optimiser, mais aussi de
pouvoir vérifier l’utilisation des ressources réservées.
Section 4 : La Sécurité
Nous ne traiterons pas de tous les aspects sécurité, qui comporte beaucoup d’éléments pour nous
concentrer sur les éléments vu dans l’analyse des exigences et la définition du catalogue de service
du multi-cloud :
- la configuration de la sécurité,
- les mouvements de donnée sécurisés,
- la gestion des accès et des identités.
1) La configuration de la sécurité
Pour pouvoir configurer la sécurité par : Access Control List, sous-réseaux, firewall, il faut le
paramétrage en soit possible à la volée. C’est le cas pour les composants réseaux virtuels grâce aux
networks overlays ou superposition réseau, par exemple, comme nous le verrons dans le chapitre
suivant.
Le processus de configuration réseau peut alors être centralisé.
Le processus de configuration réseau doit permettre également de travailler avec des protocoles
sécurisés : https, SSL, IPSec.
2) Les mouvements de données sécurisés
L’établissement de liaison sécurisée se fait par des mécanismes de tunnel et de cryptage.
Les algorithmes de hachage pour la cryptographie, peuvent crypter les données. Pour le stockage les
données sont sauvegardées cryptées. Pour effectuer des traitements sur les données il faut aussi
pouvoir les décrypter dans le cloud externe.
L’autre point essentiel pour sécuriser les données est l’authentification des accès, la vérification des
autorisations et la traçabilité.
3) La gestion des accès et des identités
Dans le cloud hybride les processus automatisés ont un rôle capital, nous allons étudier l’aspect
authentification d’un processus automatisé et d’un utilisateur. Nous étudierons également l’aspect
autorisation.
3.1) Un cas simple de gestion de l’identité et des accès à un service
Figure 29 : Modélisation du processus de gestion des accès et de l'identité
Dans le cloud hybride l’entreprise peut décider de conserver la base d’authentification et

d’autorisation de ses utilisateurs. Elle n’aura sans doute pas envie de dupliquer ces bases dans de
multiple cloud ce qui l’obligerait à en gérer la synchronisation et serait un peu difficile en terme de
sécurité, tous les clouds étant différents dans leur niveau de sécurité.
C’est donc le cloud hybride de l’entreprise qui s’authentifie auprès du fournisseur de cloud, et cette
connexion doit être sécurisée par des envois de clé et du cryptage. Par contre pour des raisons de
traçabilité, l’identité de l’utilisateur doit parfois être transmise ainsi que ses autorisations dans le
service. Une synchronisation régulière des autorisations de l’utilisateur sur le service suffit à gérer
toute modification des droits de l’utilisateur.
La figure ci-dessus représente une modélisation simplifiée du processus, sans décrire tous les
échanges nécessaires à l’établissement des clés, ni le processus d’initialisation de l’authentification
entre cloud.
Ce modèle simplifié ne prétend pas correspondre à tous les cas d’usage. Chaque cas nécessite une
mise en place de sécurité adéquate. Cependant la gestion de l’accès et de l’identité est un réel
challenge pour le cloud hybride élastique.
D’autres challenges accompagnent l’évolution vers le cloud. Les services sont utilisés par des
identités externes obligeant à séparer les ensembles d’identités, tout en les fédérant. Tandis que les
applications font de plus en plus souvent appel à d’autres applications dans une structure différente
il faut alors partager l’identité entre différentes applications.
1.1) L’authentification
a) Echange de clés publiques, Certificat
L’entreprise s’authentifie, c’est elle qui s’inscrit de manière automatisée.
Quand un utilisateur de l’entreprise s’authentifie, il ne souhaite souvent pas s’authentifier à

nouveau, il s’est déjà connecté sur son réseau d’entreprise, c’est le Singl Sign On, l’authentification
unique. C’est un mécanisme conforme au SSO qui fait le lien et va transmettre qu’il s’agit d’un acteur
de confiance.
Le cloud interne et le cloud externe s’authentifient comme acteurs de confiance pour pouvoir
échanger plus tard les Token.
b) Les API échangent des Token
Chaque API met à disposition des actions appelées par les programmes de la passerelle avec des
paramètres de configuration et de sécurité. Les actions demandées dans le cloud hybride sont
traduites dans le langage du fournisseur externe de cloud.
Exemple: API AWS EC2, API AWS S3, API AWS Load-Balancing, API AWS CloudWatch.
Les APIs sont sécurisées par des protocoles HTTPS, SSL, par des standards comme GSS-PCI de l’IETF,
le W3C pour les API-Web, par les signatures niveau 2 et 4 d’AWS, par la gestion d’identité Keystone
et des Token pour les API OpenStack.
 Important
Pour récupérer un jeton ou Token, qui permette de faire fonctionner les processus automatisés,
l’utilisateur dispose en général d’une clé et d’un code ou secret. Il est fortement conseillé que l’envoi
de ses informations soit sécurisé par des protocoles type SSL, du cryptage, que le jeton ait une durée
limitée dans le temps et que ses droits soient délimités, pour éviter par exemple qu’un processus soit
détourné avec un jeton piraté.
1.2) L’autorisation
Par contre pour des raisons de traçabilité, il faut pouvoir savoir qui fait quoi dans un cloud donc son
identité doit être transférée, de manière unique, il peut s’agir d’un numéro d’identification, unique
dans l’entreprise, si la réglementation et la législation l’autorisent, puisque la base faisant le lien sera
disponible dans l’entreprise cliente. Donc c’est l’entreprise cliente qui s’authentifie et fournit
l’identification de l’utilisateur, par des mécanismes automatisés, donc par le biais d’API.
Il est important de fournir une identification pour la gestion des autorisations.
Les API peuvent inclure un nombre de rôles différents. Par exemple entre la version Folsom de
Keystone et la version Grizzly, le nombre de rôle est passé de 3 (user, tenant, project) à 4 niveaux de
rôles. C’est loin de permettre des sécurités très fines. La normalisation de rôle et leur transfert en
paramètre, peuvent être une solution. Une autre solution est de partager une base d’autorisations et
d’affecter à chaque processus une identité et des autorisations.
De nouveaux challenges pour des mécanismes comme oAuth et XACML, SDDL, les référentiels et les
répertoires d’identité de type LDAP (Lightweigth Directory Access Protocol) ou Active Directory.
1.3) Les challenges
Dans le monde du cloud, voici trois challenges importants :
- Authentifier et donner des autorisations à un utilisateur dans un service externe sans

dupliquer les bases (XACML).
- Créer des ensembles d’identités : externes et internes. (SAML, OpenID, WS-FS)
Pour gérer ce point des bases de fédération, d’identité interne et externe, et la possibilité de
s’authentifier grâce à des acteurs externes connus (adresse de messagerie orange, gmail,
outlook… ou un fournisseur d’identité OpenID) sont en cours de standardisation.
- Partager des identités entre application (oAuth).
OAuth est un standard qui a pour but de standardiser un mécanisme d’authentification qui
permet à une application de s’authentifier auprès d’une autre application, sans avoir à
demander à l’utilisateur de s’authentifier à nouveau.
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE Chapitre 2 L’outillage de l’infrastructure
Chapitre 2 L’outillage de l’infrastructure

Nous avons vu dans les processus, que le cœur du cloud hybride est l’automatisation, l’orchestration.
Pour la réaliser il faut que les composants soient conçus dans cette optique. Nous allons voir
comment l’outillage évolue pour permettre cette automatisation.
Nous commencerons par l’étude des composants physiques de base de l’infrastructure que sont les
réseaux, les serveurs et le stockage dans la section 1. Nous verrons comment il faut extraire des
fonctionnalités de ces éléments pour pouvoir automatiser, comment l’infrastructure devient
« software defined », c’est à dire contrôlée par du logiciel centralisé.
Puis dans la section 2 nous verrons les éléments logiciels de l’automatisation et de l’orchestration,
des plus basiques, qui vont parler avec les interfaces matérielles, aux plus complexes, qui vont
orchestrer des comportements de multiples composants et applicatifs. Nous verrons comment
l’automatisation est « software defined », c’est à dire contrôlée par du logiciel centralisé.
Section 1 : L’Infrastructure devient « Software Defined »
Figure 30 : L'infrastructure Stockage, Traitement et Réseau

 Important
L’infrastructure de traitement, de réseau et de stockage est de plus en plus configurable,

« virtualisable » par logiciel, ce qui apporte de la visibilité et permet un meilleur contrôle.
De plus en plus de fonctions liées à l’infrastructure, sont réalisées dans la partie logique et de moins
en moins dans la partie physique.
Cela participe grandement à augmenter les possibilités d’élasticité, puisque plus personne ne doit
intervenir pour reconfigurer. Il devient possible d’automatiser et de mettre des règles et des outils
de mesure qui reconfigurent « à la volée ».
Cela contribue également à faciliter le cloud hybride, pour les mêmes raisons.
Dans le « Software Defined Environment » ou « Software Defined DataCenter » l’élément clé est la
séparation du plan de contrôle et du plan de données.
Figure 31 : L'Objectif est de centraliser l'administration
La gestion centralisée du contrôle communique avec les fonctions de gestion centralisées

d’automatisation et de configuration de la sécurité, la capacité, la performance afin d’appliquer les
Fonctions Virtuelles de :
- Réseau : firewall, bascule de charge, sous-réseau, réseau privé virtuel,

- Stockage : compression ou déduplication, isolation de sécurité, réplication pour reprise
après désastre,
- Traitement : déplacement de charge de travail (clone, image, blueprint).
1) La puissance de traitement (processeur et mémoire)
L’outil principal de la virtualisation de traitement est l’hyperviseur, qui permet une première
virtualisation du processeur et de la mémoire. L’hyperviseur placé sur une ressource ou un cluster de
ressources permet de mutualiser de la puissance processeur ou mémoire et d’optimiser l’affectation
en fonction des besoins par des techniques comme celle du ballooning pour la mémoire.
2) La virtualisation du réseau
Le premier outil de la virtualisation réseau est aussi l’hyperviseur. Les cartes réseaux virtuelles
appelées parfois VNICs (Virtual Network Interface Component), et les commutateurs virtuels
VSwitchs (Virtual Switchs) sont émulés, gérés, configurés et contrôlés, par l’hyperviseur et reliés aux
interfaces réseaux physiques.
Pour pouvoir déplacer des charges de travail dynamiquement et automatiquement, il faut pouvoir
automatiser tout l’approvisionnement de ressources. Hors si la partie puissance est largement
automatisée par des couches d’abstraction, de virtualisation, beaucoup de processus de
configuration réseau et stockage restent propriétaires ou manuels. C’est le cas des interfaces réseaux
physiques des ressources matérielles et de beaucoup de routeurs d’entrée et de sortie des
Datacenters, mais c’est en évolution. Chaque ressource physique nécessitait une programmation
manuelle, personnalisée et propriétaire. Ceci se traduisait par des processus d’approvisionnement
très longs et des automatisations impossibles.
Figure 32 : L'existant en réseau et l'objectif (Inspiré par source Cisco)
Face à ce souci des groupes de travail se sont créés, pour définir des mécanismes plus souples en
créant une couche d’abstraction pour des processus gérés jusque-là physiquement dans le matériel.
Afin de pouvoir programmer l’approvisionnement et le décommissionnement, placer une charge de
travail et pouvoir la déplacer en appliquant des règles, gagner en efficience, pouvoir mutualiser ces
ressources.
Les différents objectifs
Afin de relier l’émulation réseau de chaque VM à la sortie physique et entre elles, sont apparus les
premiers switchs ou commutateurs virtuels.
Le cloud étant multi-tenant, pour isoler les clients entre eux il faut créer des sous-réseaux. Pour cela
le VLAN a permis de gérer jusqu’à 4096 adresses IP, basé sur un identifiant de 12 bits, qui ne suffit
plus toujours.
De plus des besoins apparaissent pour :
- pouvoir gérer plus facilement les modifications de réseau, par exemple pour le load-
balancing,
- pouvoir isoler les utilisateurs d’une même organisation,
- assurer la continuité des IP avec celles du client,
- faire de la qualité de service (QoS), gérer des priorités,
- administrer de la sécurité, des listes de contrôle d’accès (ACL),
- suivre et améliorer à la volée les performances réseaux,
- étendre la plupart de ces fonctionnalités en WAN, pour le cloud hybride par exemple,
- pouvoir automatiser les fonctions réseaux et gagner en élasticité ou agilité.
2.1) Les différentes approches de virtualisation de réseau
Plusieurs approches de « virtualisation », « softwarisation » du réseau sont actuellement en cours

d’évolution :
 Important
- Le Software Defined Network (S.D.N.) type OpenFlow basé sur un protocole et un contrôleur.
- La virtualisation du réseau centrée sur l’application d’OpenDayLight.
- Le Network Virtual Overlay ou la superposition virtuelle réseau basée sur l’encapsulation.
- Le Virtual Network.
- Le composant réseau traditionnel géré par API.
Nous allons les voir plus en détails.
a) Le S.D.N.
L’architecture du SDN est globalement composée :

- d’un switch compatible OpenFlow, c'est-à-dire permettant le contrôle externe,
- des interfaces permettant l’accès aux composants (API Nord)
- des interfaces permettant l’accès au contrôle (API Sud)
- du protocole OpenFlow de l’ONF,
- du contrôleur centralisé.
Figure 33 : Du routeur classique au S.D.N.
« … dans l’architecture SDN les plans de contrôle et des données sont découplés, l’intelligence et
l’état du réseau sont logiquement centralisés, …” Source:www.opennetworking.org
C’est ce que nous montre la figure ci-dessus. La couche de contrôle (Control Plane) et la couche de
traitement ou de donnée (Data Plane) sont à l’origine toutes les deux dans l’élément réseau. Il faut
donc communiquer avec le composant pour le configurer.
Figure 34 : OpenFlow
"L'OpenFlow permet l'accès direct et la manipulation du plan d'acheminement des périphériques

réseaux tels que les commutateurs et les routeurs, qu'ils soient physiques ou virtuels (basés sur un
hyperviseur)." Source : Open Networking Foundation ONF
Une nouvelle architecture avec des switchs programmables et un contrôleur centralisé qui maintient
la topologie réseau comme OpenFlow.
Cette technologie permet de gérer les chemins réseau, mais elle ne permet pas la configuration du
réseau nécessaire pour l’élasticité, comme nous en avons besoin. C’est à dire pouvoir contrôler de
l’extérieur le composant réseau pour lui donner sa configuration IP par exemple, mais aussi le
grouper avec d’autres cartes pour de la résilience ou de l’augmentation de bande passante, ou
encore lui appliquer des règles de firewalling en acceptant tel ou tel protocole sur tel ou tel port.
De plus chaque fournisseur arrivait avec son contrôleur central, les interfaces ou API n’étaient pas
standardisées.
b) La virtualisation du réseau centrée sur le contrôleur défini par l’OpendayLight.
Figure 35 : OpendayLight d'opendaylight.org
L’Opendaylight sous l’égide de Linux Foundation travaille actuellement sur le contrôleur commun à
tous les acteurs et des APIs compatibles pour simplifier l’intégration, tout en autorisant chaque
fournisseur à intégrer des éléments additionnels sans enlever de compatibilité. Il vient de sortir la
première version de se contrôleur centralisé, en novembre. Il reste centré sur la gestion du
cheminement des flux.
Remarque : Cisco, qui est acteur du projet OpenDaylight sort en parallèle du contrôleur et
gestionnaire centralisé open d’OpenDaylight, sa version à valeur ajouté l’ACI (Application Centric
Infrastructure) qui va gérer des SLA, de la sécurité, de la QoS et de l’affectation de largeur de bande,
de la montée en charge et le suivi et la réduction de la latence en s’appuyant sur l’overlay.
c) La superposition ou encapsulation réseau
Elle s’appuie sur l’encapsulation, la « tunnelisation », la superposition de réseau.
Les réseaux superposés ou « Networks Overlays » sont des tunnels entre les switchs virtuels des
hyperviseurs. Cette configuration doit permettre de minimiser les changements et les mises à jour
des éléments physiques des réseaux.
Cette technologie permet la configuration à la volée des éléments réseaux.
L’ajout d’un identifiant en superposition à l’adresse IP permet de créer des sous-réseaux, par
exemple. Un sous-réseau peut-être dans le cloud interne et en continuité dans le cloud externe. Des
contrôleurs gèrent le chemin, l’encapsulation.
Les protocoles s’appellent entre autre VXLAN, GRE, NVGRE, DOVE,…. VXLAN et NVGRE utilisent 24
bits dans le datagramme pour identifier le destinataire, ce qui permet 16 million de réseaux virtuels
au lieu de 4096 en VLAN.
d) Le Virtual Network du projet OpenContrail.
Son objectif est de :

• Faire fonctionner du réseau bas-niveau sur des serveurs de commodité,
• Optimiser l’usage des serveurs,
• Simplifier la gestion réseau.
Le projet est basé sur des protocoles standards et doit apporter tous les éléments nécessaires à la
virtualisation réseau : contrôleur, routeur virtuel, moteur analytique et APIs (northbound).
Le contrôle d’accès et la connectivité sont définis par des règles. Les chemins inter-réseaux sont
définis au niveau de l’hôte pour diminuer la latence du trafic traversant les réseaux virtuels. Il faut
simplifier les passerelles pour améliorer la résilience.
Il utilise un modèle de données clair et complet pour définir la configuration réseau ce qui facilite
l’automatisation et donc l’élasticité.
Le moteur analytique permet de gérer une grande quantité de données de format structuré ou non
et un outil de requête permettant d’accéder aux données temps réel et historique.
Juniper contribue avec OpenContrail à OpenDaylight.
D’autre produits comme NSX de VMWare, Nuage d’Alcatel, PLUMGrid ou Midokura sont basés sur du
virtual Network.
Le composant traditionnel géré par API : permet de gérer la transition, en intégrant les éléments de
réseau existants non-SDN.
 Important
La flexibilité du réseau est essentielle pour rendre élastique le cloud hybride. Différentes approches
sont encore en cours : l’OpenFlow qui permet de définir le chemin, l’Overlay qui s’attache à la
configuration à la volée et le virtual network qui cherche à optimiser l’usage des serveurs. Des
solutions vont émerger rassemblant sans doute le meilleur de chaque proposition, pour permettre
l’automatisation globale transverse cloud.
2.2) L’application en WAN du SDN
Notre sujet d’étude est le cloud hybride, et celui-ci ne s’arrête pas au LAN.
Afin de gérer l’élasticité du cloud hybride il faut pouvoir optimiser et contrôler le réseau WAN,
pour gérer de la qualité de service de bout en bout.
Etant plus facile de modifier des commutateurs virtuels que physiques, des switchs internes que ceux
de multiples opérateurs, la virtualisation réseau était d’abord LAN. C’est en cours d’évolution pour
pouvoir superviser le MAN, le WAN.
BIG-IP F5 propose trois éléments pour connecter deux clouds : le pont, le courtier, la passerelle.
- Le pont symétrique si même technologie aux points d’accès, asymétrique sinon avec dans ce cas un
manque de contrôle sur le point d’accès du cloud accédé. Des possibilités de superposition réseaux
(network overlay) permettent d’encapsuler dans un tunnel les couches de niveau 2 et 3. L’identifiant
client étant intégré dans la trame Ethernet.
Figure 36 : Connecter deux clouds par tunnel
- le courtier d’identité, va maintenir la synchronisation entre le cloud externe et interne. Le

fournisseur de cloud externe maintenant souvent sa propre base non à jour au niveau des
autorisations par manque d’intégration. S’il s’agit d’authentification par Token, ou s’il s’agit de
mettre à jour les identités le broker est alors authentifié comme « de confiance ». Dans le cas du
cloud hybride le but est d’être à terme le courtier d’identité.
Le courtier d’accès gère plus les règles « corporate » d’accès. Le fournisseur établi un tunnel de type
VPN (full-proxy), ou autorise et établi une autre liaison direct cloud-consommateur (half-proxy). De
même le cloud hybride doit établir le lien par le catalogue de service.
Le cloud hybride doit également remplir les fonctions du courtier, en choisissant les clouds externes
en fonction des exigences métier par rapport au service en performance, disponibilité, localisation,
sécurité, coût.
- la passerelle du cloud hybride doit permettre de connecter le cloud interne au cloud externe en
réalisant l’intégration des API au niveau exigé : stockage, traitement, IaaS, PaaS, SaaS ou BPaaS… Elle
doit comprendre ou être complétée par toutes les fonctionnalités actuellement couvertes par des
courtiers, en fonction des besoins, et sans inclure des dysfonctionnements ou des adhérences
supplémentaires.
Comme vu dans le chapitre 2, management homogène, le cloud hybrid de VMware est composé de
trois modules de gestion pour le WAN par Global Traffic Manager de BIG IP, le LAN par Local Traffic
Manager de BIG IP et les règles par F5i software installé dans une machine virtuelle.
Exemple d’utilisation : le VXLAN permet une continuité de sous-réseau entre l’interne et l’externe, le
virtual network permet de pouvoir installer des routeurs virtuels qui couplés à des outils de gestion
installés dans une autre machine permettent de gérer la supervision, l’opérationnel, l’expérience
client, et l’OpenFlow aide pour la gestion du flux de cheminement.
(Google a déjà réalisé un WAN entre ses clouds pour la gestion interne en développant ses propres
interfaces SDN/MPLS, à priori).
 Important
Une solution de plus en plus employée pour le WAN est gérée par les techniques de network overlay
pour la gestion de la sécurité et de QoS, par des techniques de type OpenFlow pour la gestion du
chemin, sur du SSL ou du VPN et par du virtual network pour la création en live de composants
réseaux additionnels.
2.3) Virtualisation de fonctions
Les fonctions deviennent virtualisables grâce à la possibilité de configuration des composants

matériels : Voice, Vidéo, Wireless, LAN networking, IP Addressing, Public Key Infrastructure (PKI),
Firewall, VLANs, Access Control Lists (ACLs) peuvent être automatisés.
 Important
En plus du SDN (Software Defined Network), beaucoup d’articles font référence au NFV (Network
Function Virtualization), la virtualisation des fonctions réseaux dans lesquelles se trouvent par
exemple le firewall, le NAT, le VLAN, les ACLs, le load-balancing, etc… et qui sont possibles grâce à la
virtualisation réseau. Il est peut-être plus simple de parler de virtualisation de fonction ou Function
Virtualization, car si le Firewall est une fonction à l’origine dans les équipements réseaux, le
débordement, le déplacement de charge de travail ou la répartition de charge ne concernent pas que
le réseau. Les besoins du cloud hybride élastique sont donc plus larges.
Il s’agit donc plutôt de xFV (Anything Function Virtualization) ou Fonction de Virtualisation qui vont
intégrer le réseau, le stockage et le traitement, mais aussi des couches logicielles.
3) Le stockage virtualisé
Figure 37 : Deux circuits dans la virtualisation du stockage
Toujours le même objectif : rendre élastique et pour cela virtualiser, séparer la partie donnée de la
partie contrôle. Dans les configurations « out-band », les chemins aussi sont séparés, pour optimiser
les performances.
 Important
Le but est de déplacer le contrôle, en dehors des baies, dans des contrôleurs externes. Pour cela les
fournisseurs de stockage doivent standardiser le contrôleur et les APIs, pour sortir la couche de
contrôle des baies, comme pour le réseau, afin qu’elles puissent intégrer facilement des baies
hétérogènes de multiples constructeurs.
Les systèmes RAID, le stockage en mode objet sont déjà des éléments qui mettent une couche
d’abstraction entre les données et le support physique. Cependant pour pouvoir configurer à la
volée, libérer des ressources de stockage, mesurer des performances, détecter des éléments de
blocages dans une baie, isoler, répliquer après désastre, exige que toutes les formes de stockage soit
contrôlées, supervisées.
Le stockage doit être vu comme un service de stockage dynamique, mutualisé, ouvert pour pouvoir
gérer de manière centralisée de l’hétérogène.
Il existe beaucoup de formes de stockage : en mémoire ou flash (SSD), en bloc dans un SAN (Storage
Area Network), en NAS (Network Access Server).
Il existe différents mode de gestion : objet ou blob (binary large object), en mode bloc, ou en mode
fichier (cf. Annexe OpenStack).
On peut gérer des bases de données structurées ou attaquer directement les données en clé-valeur.
Le stockage est souvent valorisé au kilo Octet ou au giga Octet, mais il doit aussi être vu en termes de
rapidité de lecture, ou d’écriture qui constituent les principaux points de blocage des performances.
En stockage la rapidité est classée par les Tiers ou niveaux. L’arrivée de mémoire Flash (Tiers 0)
permet d’évacuer des goulets d’étranglements au niveau des I/O. Le tiering permet de classer les
éléments accédés moins souvent sur des stockages moins rapides, de Tiers supérieurs. La
compression permet de libérer de l’espace en collaboration avec des bases en mode colonne plus
facilement compressées.
Figure 38 : Les fonctions internes du stockage
Tout ceci existe mais surtout au niveau de baies homogènes.
Dynamique
Les éléments de stockage et leurs connexions réseaux doivent être reconnus en plug & play par les
systèmes de gestion pour pouvoir être affectés.
Ils sont alors visibles comme des services avec leurs exigences, les règles : rapidité de lecture,
d’écriture, de bande passante, de coût, de surface.
Mutualisé
Ils peuvent être mutualisés sous forme de pool ou de cluster, sécurisés (réplication, sauvegarde,
miroir). Pour cela il faut une couche d’abstraction qui sépare la partie contrôle de la partie donnée.
La partie contrôle est alors logicielle et fait la liaison avec le physique, permettant de créer des
volumes virtuels dynamiques au-dessus de ressources physiques qui peuvent être mutualisées.
Ouverte
En interne, l’architecture est hétérogène, mais surtout le cloud hybride élastique doit permettre
d’approvisionner du stockage en externe dans des clouds publics ou privés par les interfaces
standardisées (API REST : AWS, OpenStack), reliées à une puissance de traitement interne, du cloud
de l’entreprise, ou externe.
Des données hybrides
Permettre de gérer des données de format multiples : vidéo, audio, … et pouvoir laisser le traitement
sur le système de stockage pour les gros volumes comme avec des systèmes de fichiers HDFS
(Hadoop Distributed File System), adresser directement les données par un nom unique, ou les
ranger en système clé-valeur sont des nouvelles possibilités.
Pouvoir se connecter à des services spécialisés dans le traitement ou la sauvegarde des données, de
basculer dynamiquement son niveau de données (ou Tier) dans un niveau moins rapide si peu
d’accès en appliquant une supervision centralisée qui s’appuie sur des politiques pour répondre aux
exigences du service, c’est l’évolution dont a besoin le cloud hybride élastique.
Automatisé : par des règles, des mesures, des scénarios.
Cet ensemble de caractéristiques permet d’optimiser le placement des données à partir de mesures
pour respecter les règles de performance, de capacité, de sécurité, au coût approprié aux exigences
du service.
 Parenthèse
Pouvoir changer dynamiquement les configurations et libérer des ressources sont des points
essentiels pour une architecture agile et efficiente, et donc pour le cloud hybride élastique.
Par contre ce sont des points qui ne sont pas encore techniquement complétement matures au
niveau des composants : traitement, stockage, réseau, et donc sur lesquels les efforts sont en cours,
comme nous le verrons dans l’étude des composants de l’agilité.
Section 2 : L’automatisation est « Software Defined »
Figure 39 : Les niveaux applicatifs du "Software Defined"
 Important
Le deuxième élément essentiel au cloud Hybride Elastique est le développement de briques

d’automatisation qui effectuent toutes les actions nécessaires au déploiement de l’ensemble
traitement/stockage/réseau, mais aussi des composants logiciels et applications.
Cette automatisation est facilitée par le « Software Defined » de l’infrastructure, vu précédemment.
Ceci nécessite la maîtrise des ressources, des liaisons, de règles, de profil, de mesures, de planning,
de structure, de comportement…
Il s’agit à nouveau de « Software Defined » car tout est rendu modulaire et « paramétrable » afin de
pouvoir être déployé et configuré à la volée.
1) L’inventaire et les liaisons
Les bases principales :
- CMDB (Change Management DataBase)

- CMS (Change Management System)
- DCIM (Datacenter Infrastructure Management)
Les bases de ressources (infrastructure, application et service opérationnels du cloud), leurs

configurations, leurs relations, leurs changements et l’interdépendance entre les éléments sont
importants pour la rapidité de résolution d’incident, l’anticipation de changement, de maintenance,
l’optimisation des coûts.
Les éléments sont de plus en plus souvent auto-découverts par les outils de management, grâce à
des mécanismes et des informations au niveau des éléments au format standardisé. Ce qui évite les
oublis de mise à jour. A terme cela pourrait rendre optionnel l’utilisation de base. Les éléments et
leurs dépendances seront détectables à la volée, logiciel et services compris.
Dans du multi-clouds ses données peuvent être remontées par les outils de gestion aux outils de
multi-orchestration, en fonction de la granularité nécessaire au bon fonctionnement.
Dans le cloud hybride élastique, différentes bases :
- Le cloud privé : inventaire complet.

- Le cloud public :
o interfaces possibles ou non des composants.
o choix du niveau des composants à gérer, du niveau d’interfaçage, pour pouvoir
mener à bien les tâches de déploiement multi-cloud et le support,… .
Tout scénario de déploiement à besoin de connaître les ressources disponibles et d’avoir des
scénarios capables de faire des choix pour optimiser et rationaliser l’affectation de ressources. Dans
le cloud hybride cette connaissance doit être transverse.
Il est important de connaître la localisation d’un service ou d’une charge de travail et son historique
de fonctionnement, pour des raisons de conformité, traçabilité mais surtout de support, de
maintenance et d’optimisation du fonctionnement.
Entre le cloud public et le cloud privé le niveau de gestion n’est pas le même. Une partie de la gestion
est confiée au fournisseur de l’infrastructure, de la plateforme, de l’application. Le support et
l’optimisation s’arrête-t-il alors au niveau de responsabilité ? Le cloud hybride doit chasser toutes les
zones grises dans lesquelles la responsabilité n’est pas limpide et des cas d’orchestration peuvent
nécessiter une connaissance complémentaire des ressources sous la responsabilité du fournisseur. Si
un besoin existe, le fournisseur peut être amené à fournir une interface avec sa base de ressources,
afin que le cloud hybride puisse fonctionner correctement, en fonction du cas d’usage.
Un blueprint est un “template” qui décrit les composants logiciels de l’application et l’environnement
cible, pour pouvoir aller sur tout type d’infrastructure.
2) L’automatisation de l’infrastructure basique
2.1) Provisionner et configurer
Ces briques d’automatisation sont gérées par des moteurs, qui sont alimentés par des règles, des
informations et des retours de mesures.
Lors d’une demande « self-service », le service est déployé automatiquement, pour cela il faut :
- des topologies décrivant les besoins des applications en ressources,
- des scénarios de déploiement et de configuration des ressources,
- les paramètres,
- les composants applicatifs.
Déclenchés par des seuils de mesure et des règles, les runbooks de workflows orchestrent les
patterns pour déployer de bas en haut, l’architecture nécessaire.
Des outils permettent ainsi de déployer des architectures multi-niveaux (n-tiers) ou de modifier le
nombre des ressources utilisées par un des tiers comme la base de données, le service application,
ou les frontaux web tout en orientant les utilisateurs vers chacun des frontaux.
C’est la même démarche qui sert à déployer de l’élasticité dans le cloud hybride, avec un choix de
fournisseur de cloud externe à faire en plus et la configuration du lien à établir.
2.2) Exemple d’outil : OpenStack
OpenStack est à l’origine un outil d’approvisionnement de ressources d’infrastructure de base, initié

par Rackspace et la NASA en 2010. Avec les nouvelles versions ses fonctionnalités s’élargissent vers
l’orchestration. (Cf. Annexe OpenStack)
L’approvisionnement de base des composants d’infrastructure dont la configuration peut-être

maintenant contrôlée par logiciel, va ouvrir des possibilités supérieures, indispensables pour les
montées en charge et pour le cloud hybride élastique.
Afin de pouvoir être plus concret prenons en exemple OpenStack version Havana :
Figure 40 : Les projets OpenStack
Un ensemble de modules logiciels viennent s’appuyer sur les couches d’abstraction pour gérer les
composants d’infrastructure afin de faciliter l’approvisionnement et la libération de ressources à la
volée.
Le module Nova gère la partie approvisionnement de puissance de traitement, il va aider à choisir

l’hyperviseur suivant des règles préétablies (nova-scheduler) : le moins chargé, au hasard ou dans
une zone donnée,…mais aussi lui affecter une adresse réseau (nova-network), et le lier à du stockage
(nova-volume) qui peut être interne ou externe sur AWS S3 par exemple. Notons que la passerelle ou
l’intégration ce fait dans ce cas, à ce niveau entre des APIs OpenStack Nova et des APIs AWS S3, mais
elle doit être complétée par d’autres APIs pour gérer la mesure, la facturation,…
La figure suivante nous montre que les composants logiciels de gestion de l’approvisionnement de
ressource de traitement, Nova, vont se situer différemment dans la pile logicielle en fonction de
l’hyperviseur, soit comme un agent au-dessus de l’OS, soit comme agent dans une VM, soit comme
un agent s’adressant à l’outil de gestion centralisé dans le cas d’un cluster.
Figure 41 : Place d'un agent OpenStack en fonction de l'hyperviseur
http://en.community.dell.com/cfs-file.ashx/__key/communityserver-blogs-components-
weblogfiles/00-00-00-37-45/2744.openstack1.png
 Parenthèse
EGO d’IBM est un outil de gestion centralisé de cloud hybride qui envoie des règles, politiques,
contraintes à l’outil OpenStack Nova Control, pour provisionner les VM.
On peut imaginer que s’il existait un hyperviseur pour cluster de cloud on pourrait faire dialoguer
l’agent Nova avec l’outil d’administration centralisé du cluster de cloud.
Figure 42 : Outil de management de politique d'approvisionnement Multi-cloud
La figure suivante explicite le fonctionnement : les modules discutent entre eux par des ensembles
logiciels, des ensembles d’API en s’appuyant sur des files d’attente ou AMQ (Queue) et des bases.
C’est cette modularité qui permet de s’adapter à moindre coût à des infrastructures hétérogènes ou
nouvelles.
Figure 43 : Extrait d'architecture OpenStack
http://tkdi.ie/Weigh-in/Media/openstack-keystone-architecture
Les modules Swift et Cinder permettent spécifiquement d’approvisionner le stockage, en mode

objet ou block respectivement. Il est plus complet que nova-volume.
Le module Neutron va permettre de configurer, d’approvisionner du réseau, les dernières versions

sont adaptées pour gérer du Software Defined Network. Il est plus complet que nova-network.
Le module Glance va permettre de gérer une base de données d’image.
Le module Keystone permet de gérer l’identité sur plusieurs niveaux : user, projet, …. avec un
système de gestion de Token.
Horizon sert d’interface homme-machine, de tableau de bord.
Avec la version Havana d’OpenStack sont arrivés des outils Heat et Ceilometer, qui sont
respectivement des outils d’orchestration et de mesure. OpenStack passe de l’automatisation des
composants basiques de l’approvisionnement d’infrastructure pour apporter de la supervision et de
l’automatisation plus complète mais aussi plus complexe.
L’outil d’orchestration s’appuie sur des Services Template compatibles CloudFormation d’Amazon
Web Services (AWS). L’outil de mesure est la base de la supervision mais aussi de la facturation.
Ce fonctionnement est similaire globalement au fonctionnement d’autres outils comme CloudStack

ou ceux utilisés par AWS ou d’autres acteurs du marché. L’avantage avec l’OpenSource est la
transparence de l’information, le nombre de documentations partagées, plus techniques et moins
marketing, qui permettent de mieux comprendre le fonctionnement.
Cette base d’outillage permet de créer au-dessus des outils supplémentaires gérant les processus
basés sur ITIL, le cycle de vie des processus. De nouveaux projets pour l’automatisation et la gestion
de la base de données sont en cours pour la prochaine version IceHouse, dans six mois. L’intégration
de modules OpenStack est complexe. Les versions changent tous les six mois, et seuls des outils de
montée d’une version sont fournis. Pour éviter différentes intégrations d’OpenStack entraînant des
modifications sur la compatibilité, les responsables d’OpenStack réfléchissent à la mise en place de
certification.
3) L’automatisation des systèmes, des services, des applications
3.1) L’automatisation de systèmes complexes d’infrastructure
Les systèmes complexes sont mis en place pour répondre à la mise en place d’un service complexe.
Figure 44 : Scénario de déploiement n-niveaux
Les applications n-niveaux doivent pouvoir se déplacer d’un cloud à l’autre.
Plusieurs scénarios de migration
Par exemple pour une application 3 niveaux classique : Web, Appli, Base qui a besoin de conserver
ses liens, mais peut être déployée différemment suivant s’il s’agit d’un environnement de
développement, de test ou de production, il existe plusieurs scénarios de migration, comme par
exemple :
- la migration complète,
- la migration d’un niveau ou tiers : c'est-à-dire la copie d’une instance ou la mise en service du
template du tiers, le déploiement, le paramétrage. L’établissement des liaisons clients par le
DNS, et la continuité des liaisons entre tiers sont pris en compte.
- la multiplication d’un niveau
-> base de données
On peut ne vouloir migrer qu’une partie de la base multi-tenant en la séparant par tenant, par
exemple, ou la cloner plus simplement. Il faut adresser des opérations de gestion de la base de
données, s’occuper de la mise à jour par des mécanismes de standby pour la mise à jour de la
base supplémentaire.
-> web
Si on fait le choix d’une redirection d’une partie des clients vers un deuxième cloud, comme avec
un CDN (Content Data Network) vers une autre adresse de serveur frontal, pour certaine
adresses web.
Le gestionnaire système affecte des nouvelles ressources et les configure, ces actions sont
automatisées. Il ne s’agit jamais de créer de la complexité sans raison, ce type de fonctionnement
doit trouver sa source dans les exigences et être itératif pour justifier son design et son intégration.
3.2) L’automatisation de systèmes complexes de services
Figure 45 : Les drivers de l'élasticité
La mise en place de cette plateforme technique et de sa configuration stockage et réseau compris, ne

serai pas complète sans la partie applicative. Les scénarios de déploiement d’infrastructure ou
système, s’accompagnent du déploiement des logiciels associés et de leurs configurations. Une fois
que la plateforme serveur web, serveur d’application et base de données est installée et configurée,
le service doit être déployé et configuré également.
La mise en place d’une automatisation nécessite la création d'un « blueprint », ou «service

template ». Le service template est idéal car il permet d’être indépendant de l’écosystème cloud
sur lequel est déployée l’application. Le scénario étant modulaire son paramétrage, son intégration,
ses modifications sont facilités.
Des outils de déploiement comme Puppet, Chef permettent de déployer les scénarios avec leur
paramétrage.
 Important
Nous sommes toujours dans la démarche de « Software Defined Anything » ou SDx, la couche de
données est séparée de la couche de contrôle. En l’occurrence les composants qui font fonctionner
l’application sont séparés des composants servant au déploiement et à la montée en charge de
l’application.
Les scénarios d’automatisation des fonctions virtualisées : load-balancing, configuration de sous-

réseau, de firewall, de sauvegarde, de réplication… peuvent répondre au même schéma.
3,3) Les standards de « Services Templates » et les outils de déploiement
Le standard OVF de DMTF permet une standardisation des images et leur déplacement pour de
l’embarquement, mais reste compliqué pour la mise à jour des patchs.
L’orientation technique semble aller vers des outils permettant de capturer les opérations de
déploiement, l’environnement d’exécution, et le comportement ce qui permet l’autonomie et la
portabilité.
Les modélisations de service template les plus connus sont entre autres : CloudFormation (AWS),
TOSCA (OASIS), IMOD (Kaavo).
Figure 46 : Service Template Tosca
TOSCA Topology and Orchestration Specification for Cloud Applications basé sur du XML, capture le
déploiement et les infos de gestion. TOSCA utilise le Business Process Execution Langage pour définir
le comportement.
Avec Tosca un service est décrit par un « service template» qui correspond à :
- une topologie (structure)
- une orchestration (comportement de gestion et invocation).
Ceci aide à la création et la gestion automatique de service, indépendamment du fournisseur de

cloud et des technologies sous-jacentes. Le service est créé une fois et sert à de multiples utilisations,
pour de multiples environnements.
Les services sont provisionnés dans une infrastructure IT et leur comportement de gestion est
orchestré en accord avec les contraintes et règles qui pèsent dessus, pour respecter les niveaux de
services, par exemple
L’automatisation devient complexe. Pour la simplifier il faut la gérer par plan. Chaque niveau fournit
des « blocs élémentaires » (building bloc), enchaînés dans le plan supérieur.
C’est dans cet esprit que se situe Tosca, standard d’OASIS. Avec Tosca un service est décrit par un
« service template» qui correspond à une topologie (structure) et une orchestration (comportement
de gestion et invocation). Ceci aide à la création et la gestion automatique de service,
indépendamment du fournisseur de cloud et des technologies sous-jacentes. Le service est créé une
fois et sert à de multiples utilisations, pour de multiples environnements.
Les services sont provisionnés dans une infrastructure IT et leur comportement de gestion est
orchestré en accord avec les contraintes et règles qui pèsent dessus, pour respecter les niveaux de
services, par exemple.
Figure 47 : Service Template= Structure, propriété et comportement
La description de services afin de s'assurer de leur échange. Les aspects « runtime » sont pris en
considération en fournissant un conteneur pour des modèles de plans à l'appui de la gestion des
instances de services. La bibliothèque fournit des mécanismes d'extension qui peuvent être utilisés
pour étendre les définitions : à des ajouts supplémentaires spécifiques au fournisseur ou à un
domaine d’informations spécifiques.
Les services sont des entités modélisables (TOSCA)
Standardiser les modèles de service permet de créer un marché de services IT hébergés. Un standard
qui spécifie la modélisation des typologies (ensemble des composants et dépendances mutuelles) et
permet la définition de l’interopérabilité de la structure des services.
Le modèle de service ou Service Template peut-être publié dans les catalogues de fournisseurs de
service qui fera le lien avec son infrastructure pour supporter des instances réelles de service et les
adapter à ses plans de gestion.
Plan de gestion de l’instanciation (build plan)
Faire une instance concrète d’un «modèle de topologie» peut se faire en lançant le « Build Plan »
correspondant. Le “Build Plan” peut-être adapté à un environnement réel d’un service de
fournisseur.
D’autres « Plans » utiles pour des actions de tout le cycle de vie du service peuvent être spécifiés
comme élément du « Modèle de Service ».
Similaires aux « Plans de gestion » ces « Plans » peuvent être adaptés à l’environnement réel du
fournisseur de service.
Ces Plans décrivent comment les instances d’un service sont créées et gérées. Définir un set de
« Plan de gestion » pour un service réduit significativement le coût d’hébergement d’un service en
produisant une connaissance réutilisable de bonnes pratiques pour gérer chaque service.
Le constructeur des «modèles de service ou de plan» cache la complexité du comportement à

l’utilisateur qui doit simplement l’invoquer.
 Parenthèse
Un artefact représente le contenu nécessaire pour réaliser un déploiement :
- exécutable (script, image)
- fichier de données pour configuration (paramètre)
- bibliothèque (d’autres exécutables)
Il est fourni avec des métadonnées descriptives de l’environnement… et est généralement en Python
ou EJB.
Exemple pour une opération REST de stockage d’image : le WAR est l’artefact d’implémentation et
l’image est l’artefact de déploiement. Le WAR est un fichier archive servant au déploiement par un
serveur d’application et contenant des JavaServer Pages, des servlets, des classes Java, des fichiers
XML, des pages web statiques (HTML, JavaScript…), le tout constituant une application web.
Kavoo utilise des Workflows d’actions séquencés en réponse à un événement ce qui facilite les
intégrations d’actions en ligne de commande.
Des outils de déploiement comme Puppet, Chef, Crowbar(Dell), RightScript (RightScale) permettent
de déployer les scénarios avec leur paramétrage. Ils peuvent déployer les « Services Templates », les
scripts.
3.4) L’intégration de l’écosystème du cloud d’accueil
La dernière étape du déploiement avant test est l’intégration des outils du cloud d’accueil : outils de
facturation, de mesures, de librairies…qui doivent s’installer dans les virtuelles machines qui
composent le service pour permettre de mesurer les performances, de lancer des runtime, de
mesurer les consommations pour facturation.
3.5) Exemple d’outil d’orchestration
Les éditeurs de logiciel d’Orchestration proposent soit des outils basés sur tout ou partie des
modules OpenStack, soit développés entièrement en interne ou par intégration de rachat.
Système Center Orchestrator de Microsoft et VCloud Suite, sont des outils développés par
respectivement Microsoft et VMWare. SmartCloud Orchestrator et HP Operation Orchestration sont
des outils basés sur des modules OpenStack d’IBM et de HP.
Les outils d’orchestration d’HP et d’IBM sont basés sur la modélisation de Services Templates TOSCA.
SmartCloud Orchestrator prend en charge l'importation, le déploiement et l'exportation des modèles

de service conformément à la spécification OASIS TOSCA. Cela permet de consommer un contenu
tiers fourni dans un format normalisé.
L’outil d’automatisation de Microsoft se base sur le déploiement de script PowerShell.
Heat, l’outil d’orchestration d’OpenStack utilise les « Services Templates », CloudFormation dans la
version Havana.
Les outils de gestion de cloud sont vus chapitre 3.
4) Superviser ses ressources, mesurer
Le cycle de vie d’une ressource consiste notamment à abstraire, modéliser, intégrer, authentifier,
donner les autorisations, provisionner, déployer, lancer, configurer, mesurer, superviser, historiser,
supprimer.
Pour superviser les ressources il faut :

- mesurer
- définir des seuils de déclenchement d’alerte, ou de bascule automatique…
5) DevOps
La démarche de DevOps au-delà de rapprocher les équipes de développement, des équipes de mise
en production et d’exploitation, a pour objectif également une intégration des processus de
déploiement dès le développement. Les processus de déploiement d’infrastructure sont modélisés
(typologie, configuration) et scriptés pour pouvoir être lancés par les applications. La résolution des
incidents est anticipée dans cette démarche. Cela implique un dialogue important entre les
développeurs et les responsables des opérations. Le but est d’éviter les tâches répétitives, les erreurs
humaines, de pouvoir accélérer les mises en production et ainsi de pouvoir améliorer la disponibilité.
Section 3 : Les applications et les Business Process
1) SaaS et les liens entre application par API ou connecteurs
La synergie multi-cloud consiste globalement à fournir un portail qui va fédérer la gestion des
identités et rassembler l’accès aux applications, simplifier la facturation pour chacune des
applications accédées.
Une application SaaS ne va pas nécessiter de passage d’un cloud à l’autre puisque la problématique
de montée en charge est généralement gérée par le fournisseur de l’application.
Sauf si notre client est fournisseur d’application SaaS pour les métiers de son entreprise, nous ne
verrons pas ce cas dans cette étude. Nous ne traiterons pas non plus le cas du référentiel et du
Master Data Management, qui pourtant sont des questions qu’il faudra étudier.
2) BPaaS : La Conception de Workflow
Figure 48 : Exemple de Workflow d'automatisation
La virtualisation des flux d’action et d’approbation : un défi pour la migration des applications de
développement et de tests entre autre, mais surtout pour l’élasticité du cloud hybride. Les librairies
d’outils pour la virtualisation fournissent la couche d’abstraction pour se relier à l’hyperviseur.
 Important
La gestion d’un cloud hybride élastique nécessite des actions multiples, interdépendantes,
ordonnées : provisionner des serveurs en multi-niveaux, lancer des instances, connecter des bascules
de charge, attacher du stockage, installer des applications, configurer des services, mettre en place la
supervision, maintenir, contrôler la conformité.
La conception et la gestion de Workflows complexes et automatisés font partie du cloud hybride

élastique.
Section 4 : Les passerelles API
Figure 49 : Les Passerelles ou librairies d’APIs
Les principales API du marché sont OpenStack, CloudStack, Eucalyptus, AWS,…

La bourse d’échange de cloud allemande : Deutsche Börse Cloud Exchange devrait s’appuyer sur des
APIs ouvertes de Zimory.
Des fournisseurs de librairies d’API Cloud existent : DeltaCloud, Apache LibCloud.

Les fonctionnalités de ce service sont fonction des actions et paramètres mis à disposition par le
fournisseur de cloud. Similaire à la démarche d’API Cross-Platform, comme SimpleCloud pour les
programmes PHP, ils intègrent les API de multiples Cloud avec des fonctionnalités identiques pour
fournir une même interface au cloud interne. C’est un produit sur étagère qui peut simplifier des
démarches d’intégration classiques du marché, simplifiant l’intégration et les mises à jour
éventuelles.
Cette partie intégration s’appuie sur des API, des SDK.
Les APIs peuvent se standardiser sur des fonctions basiques comme l’approvisionnement d’une VM,
mais elles continueront d’évoluer de proposer des fonctions additionnelles. C’est pourquoi il faut
rester sur des démarches centrées sur le déploiement applicatif modulaire, qui permet de gérer les
évolutions.
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE Chapitre 3 L’outillage spécifique
Chapitre 3 L’outillage spécifique
Section 1 : Les outils basiques de gestion du cloud hybride
1) Les différents outils de gestion de cloud hybride
En plus des outils de gestion de cloud d’HP, IBM, Microsoft, Oracle, VMWare, Citrix, BMC, CA,
émergent des nouveaux éditeurs d’outils de gestion de cloud. En général développés à la base pour
un usage interne tel que Scalr, RightScale, ScaleXtreme, Enstratus, Kaavo, Abiquo, ServiceMesh,
Hotlink, EcManaged sont des outils de gestion de cloud permettant de faire du multi-cloud et de
déployer leur outil sur site.
Gestion de cloud Hybride Automatisation

Hybrid Cloud
vCloud Director
VMWare vCloud Suite vCAC & vCOps
SmartCloud Orchestrator &
IBM Cast Iron Cloud Automation
Microsoft System Center Orchestrator SCCM & DataCenter Automation
Operation Orchestrator &
HP Converged Cloud CSA
Cisco Intelligent Automation
Cisco for Cloud
Automation Suite &
CA CloudMinder
BMC Atrium Orchestrator Blade Logic
Cloud Portal Business
Citrix Manager Cloud Service Automation
Entreprise Manager Ops Center
Entreprise Manager Cloud Entreprise Deployement
Oracle Control Blueprint
DELL Enstratus Crowbar
SCS ServiceMesh
RighScale RightScale
ScaleXtreme ScaleXtreme
Kaavo Kaavo IMOD
OpenStack Heat, Horizon, Nova TripleO
Capgemini SkySight
Figure 50 : Outils de gestion de cloud hybride
Les principales caractéristiques des outils de déploiement de cloud sont ceux vus dans le catalogue
de service (cf. figure 22, page 52) :
- une console d’administration centralisée pour l’approvisionnement de ressources et leurs

configurations, dans de multiple clouds, mais aussi pour la gestion de la capacité, de la facturation,
de la sécurité et des accès, du catalogue de service, des fonctions multi-clouds(embarquement,

débordement,…)
- une passerelle qui intègre les APIs de fournisseurs de clouds majeurs du marché (parmi Amazon
Web Service, Google Compute Engine, Windows Azure, Rackspace, TerreMark,…) et des standards
(OpenStack, CloudStack,…).
- des outils facilitant l’intégration d’autres clouds, d’autres fonctions, par APIs et scripting, avec un
catalogue d’APIs, de package, de librairies.
- des outils de conception de l’automatisation et des catalogues de Service Template.
- de la supervision centralisée : des performances et des engagements de niveaux de service, des
budgets et de la facturation, de l’usage des services, de la sécurité et des accès, des fonctions multi-
cloud (embarquement, débordement, mesure de l’expérience utilisateur...).
- des outils de gestion des règles, politiques.
- des outils pour le support et la gestion du cycle de vie des services.
2) Les qualités d’un gestionnaire de cloud hybride
L’outil de gestion de cloud hybride est le chef d’orchestre.
- Il possède une interface unifiée pour l’approvisionnement, la configuration, la supervision des

ressources de l’infrastructure aux business process.
- Il permet de suivre la conformité, les engagements contractuels, la sécurité, les budgets, les
performances.
- Il dispose d’atelier de conception de l’automatisation visuels et clairs, permettant la collaboration,

disposants de bibliothèques de composants, facilitant les tests par du pas à pas et les retours arrière
et d’un magasin de packages d’automatisation modifiables.
- Il permet d’intégrer facilement de nouvelles API et propose un magasin fourni de packages

d’intégration déjà testées.
- Il a des outils de gestion de politiques, de règles, de circuit d’approbation ou d’action, d’alerte et de

notifications.
- Il peut s’intégrer facilement avec des outils externes de supervision, de sécurité, de support.
Section 2 : Les outils de facturation

Comme nous l’avons vu précédemment pour facturer à l’utilisation il faut d’abord mesurer.
L’administrateur des budgets dans l’application Enstratus est différent de l’administrateur de

ressources. Il va pouvoir déléguer des budgets, ce qui donne de l’agilité dans le processus
d’approvisionnement.
RightScale quand à lui intègre un nouvel outil analytique pour gérer le suivi financier et de l’usage.
Section 3 : L’adhérence des outils

Afin de pouvoir gérer certains outils, des agents ou moteurs sont parfois installés dans les VMs. Ces
agents sont importants à prendre en compte si les VM se déplacent d’environnement (élasticité,
réversibilité).
Il faut pouvoir les installer, il faut pouvoir les intégrer pour agréger des informations de facturation,
de performance,…
Si on veut déplacer l’image ou le clone d’une instance il faut pouvoir les désinstaller proprement afin
d’éviter les erreurs, les lourdeurs, les conflits.
Le redéploiement à partir de template ou blueprint, et des modèles de déploiement permet une

indépendance plus grande, mais demande un temps plus long, en général.
Section 4 : La standardisation des outils
Nous nous intéressons essentiellement aux outils et nous retrouvons souvent des standards pour
développer ses outils issus de différentes communautés. Pour la définition du cloud il y a le NIST,
pour la sécurité le Cloud Security Alliance et l’ENISA, l’Object Management Group(OMG), l’Internet
Engineering Task Force (IETF),…
1) Distributed Management Task Force (DMTF)
Un groupe du DMTF sur l’Open Software Defined Data Center (OSDDC) travaille pour développer une
architecture et des définitions standardisées pour décrire les technologies émergentes de
l’infrastructure IT.
DMTF CIMI : Cloud Infrastructure Management Interface définit un standard qui permet par exemple
de passer des instances au format standard OVF d’un cloud à un autre.
DMTF CIM : Common Information Model
DMTF OVF : Format de package d’image virtuelle pour les déployer sur des hyperviseurs.
2) Open Grid Forum (OGF)
L’Open Cloud Computing Interface (OCCI) développe des spécifications et des API open pour les
offres cloud pour le IaaS extensible au PaaS.
3) Storage Networking Industry Association (SNIA)
Le Cloud Data Management Interface (CDMI) est un standard SNIA qui spécifie un protocole de self-
provisioning, d’administration et d’accès au stockage cloud.
CDMI définit des opérations HTTP RESTful pour permettre au stockage cloud d’allouer et d’accéder à
des conteneurs et des objets, gérer des utilisateurs et des groupes, implémenter des contrôles
d’accès, attacher des métadonnées, faire des arbitrages, utiliser des files d’action, spécifier des
intervalles de rétention en accord avec les règles de conformité, en utilisant des fonctionnalités de
connexion, facturation, déplacement de données entre cloud, et de l’exportation de données via
d’autres protocoles tel que l’iSCSI et NFS. La sécurité du transport est obtenue par TLS.
4) Advancing Open Standard for the Information Society OASIS
OASIS TOSCA permet l’assemblage et l’orchestration d’images virtuelles et d’entités physiques dans
des structures plus larges : service ou application. Tosca supporte les opérations du cycle de vie mais
aussi de montée en charge, de patch. TOSCA a un haut niveau d’abstraction pour décrire les
composants applicatifs et d’infrastructure, pour l’orchestration. TOSCA supporte un haut niveau de
relation pour décrire les topologies des applications cloud, comme "deployed on", "licensed by" et
«data locality constraint". TOSCA orchestre le comportement des opérations de cycle de vie qui
peuvent intelligemment conduire et aligner la gestion premier-niveau de l’infrastructure de service
cloud par des interfaces telles que celles définies par CIMI (DMTF) et OCCI(OGF).
OASIS SCA : Service Component Architecte est un ensemble de spécifications qui décrivent un
modèle pour construire des applications et service SOA (Service-Oriented Architecture). SCA
complète les approches précédentes d’implémentation de services.
TOSCA étends les capacités de SCA en fournissant topologies et services d’orchestration qui lie les
applications SCA et l’infrastructure cloud.
REST : Représentation State Transfert, ensemble de principes alternative au protocole de service web
basé SOAP. SOAP : protocole d’accès basé sur le protocole RPC et XML.
RESTful : respectant les principes REST.
5) Format d’échange
Les bus de traitement facilitent les échanges asynchrones et « sans état » diminuant l’adhérence et
créant des zones d’échange. Exemple : AMQ (Rabbit MQ).
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE Chapitre 4 La sécurité
Chapitre 4 La sécurité
Figure 51 : Architecture Sécurité Cloud Security Alliance
Section 1 : La gestion de la sécurité évolue
1) La sécurité ciblée
Les efforts de sécurité dépassent les frontières du data center, car élastique et transitoire, la
sécurité doit être repensée. La sécurité en lisière ne suffit plus, elle doit être à chaque point d’accès
et doit être prise en compte dès l’amorce du projet.
La sécurité péri métrique, n’est plus le modèle d’actualité. L’accès devant être mobile, les points
d’accès de plus en plus divers, et l’entreprise de plus en plus ouverte vers les clients, les partenaires,
cette sécurité répond de moins en moins aux exigences. Pour répondre à ces challenges la gestion de
la sécurité change. Elle s’appuie aussi sur de la confiance et de l’analyse comportementale, facilitée
par l’analyse de données non-structurées. Elle exige des sécurités ciblées et adaptées et donc des
classifications, des services internes, des données, des services externes.
La sécurité est souvent liée aux comportements et les utilisateurs doivent être formés, l’outil
principal est donc la formation. Des analyses comportementales en ligne, viennent de plus en plus
renforcer la sécurité, les outils sont alors des bases et des algorithmes d’analyse.
2) La sécurité par la conformité, la classification, l’audit
Sécurité des données, sécurité des services, sécurité des accès physiques, sécurité des accès
numériques, la sécurité doit garantir la confidentialité, l’intégrité, la disponibilité et la traçabilité en
fonction des besoins et comme la sécurité a un coût non-négligeable, elle doit être ciblée.
Elle passe dans le cloud hybride par les garanties fournies par les fournisseurs de cloud dans les
engagements contractuels. Un des outils de la sécurité est lié au contrat, à la conformité de
l’entreprise aux standards de sécurité….et à la validité des audits effectués par des tiers habilités.
Chaque service peut aller dans un cloud qui respecte le niveau d’exigence du service et le transfert
entre les clouds doit respecter ce niveau d’exigence.
Section 2 : La sécurité par la gestion des accès et de l’identité
1) La gestion des accès et des identités (IAM : Identity Access Management)
Accès de l’intérieur, de l’extérieur de l’entreprise, accès par un employé, par un fournisseur, accès
sur site, accès au cloud public… de multiples types d’accès existent.
"Qui accède ?", "qui a le droit d’accéder à », « qui peut gérer quoi ?", "qui a donné le droit à qui ?".
Le suivi d'une identité, de son authentification, de ses habilitations, de sa révocation est un élément
essentiel de la sécurité.
En environnement de cloud hybride élastique se posent plusieurs défis :

- La protection des identités et de leur authentification : Quelle serait la protection et la fraîcheur
d’information de multiples copies d’un annuaire dans des clouds divers ?
- Quelle est la protection du login lors du passage sur internet ?
- La protection des accès en multi-cloud : Comment contrôler les habilitations et
l’authentification dans chaque cloud ?
- La simplification des accès : Peut-on s’authentifier une seule fois pour toutes les applications (Single
Sign On) ?
- La fourniture de rapports d'audit de traçabilité pour la conformité légale et réglementaire :
Sarbanes-Oxley, Bâle III, Solvency II, LSF...
- L’hétérogénéité des technologies d’authentification acceptées par chaque fournisseur de cloud.
Plusieurs standards se développent pour répondre aux nouveaux défis comme :

- OpenID : single sign-on des consommateurs.
- SAML : single sign-on des utilisateurs des entreprises.
- OAuth : API autorisation entre applications.
Typiquement dans la gestion de l’identité nous allons considérer qu’il faut pouvoir répondre aux
AAA : Authentification, Autorisation, Accountable (traçabilité).
Les mots de passe et certains cryptages sont de moins en moins sécurisés en raison notamment des
puissances de calcul actuellement disponibles. Il faut donc pouvoir gérer des authentifications fortes
à plusieurs niveaux, pour l’interne (exemple : identifiant, mot de passe et badge) comme pour
l’externe (identifiant de type adresse de messagerie, mot de passe et SMS). Ces niveaux doivent être
adaptés aux exigences.
Pour l’authentification :
Nous partons du principe que l’utilisateur : consommateur ou administrateur s’authentifie au niveau

du portail d’accès du cloud hybride. C’est le cloud hybride qui gère l’authentification aux clouds
externes.
Pour des raisons de sécurité la duplication de l’annuaire d’authentification au niveau de tous les
fournisseurs de service, n’est pas envisagée dans cette étude, la synchronisation et la dispersion des
bases d’authentification ne sont pas souhaitables.
Pour des raisons de traçabilité, parfois pour la gestion de rôles dans l’application, il est important de
pouvoir disposer de l’identité dans un cloud hybride. Pour des raisons de simplicité et de sécurité, il
est intéressant que l’utilisateur ne s’authentifie qu’une seule fois, le Single Sign On, au niveau du
premier portail d’accès, celui fournit par le cloud hybride.
 Important
Le cloud interne est authentifié par le cloud externe par des mécanismes de certificat, de clé public
(Public Key Infrastructure).
Un processus automatisé transfert des Token par les API pour prouver son identité, pour sécuriser les
API, des standards sont développés.
Basée sur l’annuaire, LDAP ou l’Active Directory, qui envoie des demandes sous forme de Token ou
de Cookies.
L’autorisation : Le contrôle d’accès basé sur les rôles (Role Base Access Control)
L’administrateur et ses droits d’approvisionnement ou de décommissionnement de ressource, de

déploiement, de paramétrage, d’interconnexion, de gestion de flux sont gérés par le cloud hybride
qui transmet au cloud accédé par les API mises à disposition pour la gestion de l’identité par le
fournisseur de cloud externe.
La gestion du cycle de vie des rôles étant plus facile à gérer si elle n’est pas dispatchée dans les
applications, beaucoup d’applications s’appuient sur des autorisations données par des bases. Des
bases d’autorisation peuvent devenir nécessaires, en fonction de la complexité des autorisations. Il
faut donc pouvoir associer à une identité un ou plusieurs rôles, ses rôles étant associés à des droits
dans les applications. Il faut donc pouvoir authentifier un utilisateur mais aussi transmettre ses
autorisations pour l’application concernées.
XACML: eXtensible Access Control Markup Language is a declarative access control policy language
implemented in XML.
2) La gestion des processus
L’authentification Token de l’API
Qu’il s’agisse d’un utilisateur ou d’un processus le mécanisme d’authentification est similaire, le
cloud interne peut échanger des clés publiques avec le cloud externe.
Des identités sont associées aux systèmes, aux processus automatisés qui peuvent être identifiés,
tracés et historisés. Cette authentification passe par les API.
Ils s’appuient sur des standards et travaux existants sur internet comme : REST, WAM (Web
Authentication Management).
Autorisation de runtime
Le lancement de processus doit être autorisé sur le cloud externe.
Les processus automatisés vont aussi devoir bénéficier de droits pour automatiser un
approvisionnement ou un décommissionnement de ressource, un déploiement, une
interconnexion,… Ce processus doit d’abord transmettre par l’interface ses accréditations.
Exemple 1 : Processus d’accès de Keystone
Figure 52 : Processus de gestion d'identité Keystone
Exemple 2 : La signature d’API d’AWS
La requête de signature AWS niveau 4 est composée des éléments suivants :

- Le point d’entrée du service : une adresse URL, le nom DNS.
- Le nom de l’API qui correspond à l’action
- Les paramètres de l’action.
- La date et l’heure de requête : pour protéger l’API.
- Les paramètres d’autorisation :
- l’algorithme de hachage. (Exemple SHA-256)
- le « credential » c'est-à-dire l’identifiant de la clé d’accès composé du périmètre des
composants (date, région AWS, nom du service, chaîne spéciale de caractère donnée par
AWS). (cf. Annexe API)
3) La fédération d’identité
Les outils du cloud hybride viennent fédérer les clouds comme on fédère des Datacenters lors d’une
fusion d’entreprise, quand les outils de gestion sont hétérogènes.
Définir des structures (frameworks) c’est définir un ensemble de composants réutilisables lors de la
création d’applications.
L’authentification s’appuie sur des bases comme l’Active Directory, ou l’annuaire LDAP, qui peuvent
être complétées par des bases de Fédération d’Identité comme AD FS, ….
Les patterns de design sécurité sont des blueprints et des instructions pour résoudre les challenges
techniques usuels : authentification, autorisation, supervision des logs, single sign-on, etc.
Section 3 : Les protocoles et la cryptographie

L’hétérogénéité des technologies d’authentification acceptées par chaque fournisseur de cloud,
peuvent poser problèmes. Les fournisseurs de cloud externe doivent fournir des protocoles sécurisés
de type SSL/TLS. Ils doivent aussi supporter des mécanismes de cryptographie standards.
Exemple : KMIP d’OASIS.
Figure 53 : Exemple KMIP


https://blogs.rsa.com/what-matters-in-a-standard-rsa-dpm-support-for-oasis-kmip/
OASIS travaille sur le Key Management Interoperability Protocol (KMIP) qui standardise la
communication entre les clients de cryptographie qui ont besoin de clés et le système de gestion de
clés chargé de créer et de gérer les clés. En utilisant un protocole bas niveau qui peut demander et
fournir les clés entre n’importe quel gestionnaire de clé et n’importe quel client de cryptographie,
KMIP est un gestionnaire de clé complétement interopérable.
A travers cette interopérabilité les entreprises seront capables de déployer une seule infrastructure
de gestion de clés pour toutes les applications, composants et systèmes pour une entreprise qui
requiert des clés symétriques, des paires de clés asymétriques, des certificats numériques, ou
d’autres composants de cryptographie.
KMIP respecte le cycle de vie des clés spécifié dans la publication 800-57 du NIST pour définir les
attributs reliés aux états. KMIP s’appuie sur les mécanismes de sécurité du réseau comme SSL/TLS et
HTTPS pour établir une communication authentifiée entre le gestionnaire et le client.
KMIP s’appuie sur les standards existants d’algorithmes d’encryptions, la clé de dérivation et
beaucoup d’autres aspects de solution de cryptographie centré sur l’ interopérabilité entre client et
gestionnaire de cryptographie.
TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE Synthèse de la troisième partie : processus et outillages
Synthèse de la troisième partie : processus et outillages
Les principaux processus d’approvisionnement et de configuration de ressources matérielles et

applicatives sont à automatiser.
Tout devient « Software Defined » ou « Application Centric » pour permettre l’orchestration, la

supervision financière et capacitaire, la mise en place de sécurité, et ainsi améliorer l’efficience, la
résilience, l’agilité. Des niveaux infrastructure jusqu’au niveau de supervision des processus, les blocs
de construction s’améliorent pour pouvoir fournir l’agilité qui conduit à l’industrialisation de
l’informatique.
Les standards sont essentiels pour gagner en interopérabilité, nous avons ainsi vu des
développements Open-Source comme OpenStack, pour l’approvisionnement de ressource et des
standards comme Tosca d’Oasis, pour l’interopérabilité des déploiements. Les projets Open,
permettent de mutualiser les connaissances et d’avancer plus vite au niveau de l’automatisation, et
de la sécurité. Des standards de fait s’imposent également.
La sécurité de cette automatisation est clé. Elle passe par des mécanismes classiques de clé publique
et de certificat, puis par des mécanismes de Token, transmis par les fonctions définies par les APIs.
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 1 Les étapes
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET

DE CLOUD HYBRIDE ELASTIQUE
Ceux qui auront choisi des technologies interopérables pour leur cloud privé pourront plus
facilement évoluer vers l’intégration, le cloud hybride.
La mise en œuvre d’un cloud hybride : les étapes, les rôles et la gestion des compétences et les
changements organisationnels.
Chapitre 1 Les étapes

Dès maintenant beaucoup de projet se heurtent à des difficultés. Il ne s’agit pas de livrer des projets
d’intégration complexe de cloud comme on livre de la « commodité ». Les projets qui incluent du
cloud computing hybride et élastique sont en général des vrais projets de transformation de
l’entreprise. Ils s’anticipent, se structurent, se planifient par phase ou en itératif pour pas à pas
augmenter l’efficience des services.
Section 1 : L’analyse de la stratégie de l’entreprise

Pas de démarrage de projet sans prise en compte de la Stratégie Business et de la Stratégie Sécurité
de l’entreprise.
1) La stratégie Business
Connaître la stratégie de l’entreprise
Le domaine dans lequel elle évolue comme :

- la rapidité et l’importance de l’innovation,
- ses objectifs : fusion, acquisition, entrée en bourse, synergie, communauté,
- ses compétiteurs, ses clients,
- ses partenaires et les contrats existants,
- les segments du marché ciblés et leurs prérequis,
- ses compétences internes, sa culture d’entreprise,
- sa valeur ajoutée, son ADN, ses valeurs sociales, environnementales.
Afin de pouvoir en déduire les facteurs clés de succès, sur lesquels le système d’information va avoir
un rôle clé. Ainsi il sera plus facile de savoir quelle valeur ajoutée et quel budget, sur quelle
échéance. Les facteurs clés du succès nous aideront à définir les métriques et le KPI, que les outils de
supervision remonteront dans les tableaux de bord de la gouvernance.
Pour suivre la règle émise par le Pareto 20% des fonctionnalités vont recouvrir 80% des besoins. Il
faut cerner les priorités conduites par le business. Elles nous aideront à voir si l’externalisation de
services peut apporter des bénéfices, mais aussi quels services et comment cette externalisation
devra être faite pour couvrir le besoin, dans quels délais.
2) La stratégie sécurité
Cette fois-ci on s’intéresse à la valeur des informations et des traitements de la société. A ce qui se
passerait si les données étaient corrompues ou perdues, perdaient leur confidentialité, n’étaient
momentanément pas accessibles. De la même façon, quel serait l’impact d’un arrêt des traitements,
d’un dysfonctionnement, d’une non-conformité ?
En face sont alignés les coûts et les risques pénaux, juridiques, ou de perte d’image.
Et comme la sécurité à un coût et qu’il faut gérer des priorités, il faut pondérer par la probabilité de
survenu du dysfonctionnement.
Ensuite dans un cloud hybride il faudra savoir si les aspects sécurité sont mieux gérés en interne ou
en externe, et à quel coût dans chacun des cas. Et si le passage d’un cloud à l’autre respecte la
stratégie de sécurité et toujours à quel coût (VPN, lien privé, redondance).
Les problèmes de l’IT traditionnelle se retrouvent dans le cloud hybride élastique, et loin de les
résoudre, s’ils ne sont pas traités correctement, le risque est grand d’amplifier leur impact.
Une classification des données, des services et une analyse des risques sont impératives, pour savoir
quelles données peuvent basculer sur le cloud, sur quel cloud et comment.
3) L’analyse de la demande
Une gestion de la demande doit permettre d’anticiper, quand et combien de capacité doivent être
approvisionnées en externe et pour combien de temps.
Cette stratégie de la demande est particulièrement importante car suite à son analyse on prévoit les
montées en charge et donc on anticipe l’externalisation, le scale out, le scale down.
Section 2 : L’étude de l’existant
1) La gestion de la maturité des processus clients
Niveau de Maturité Maturité "Cloud" Description
- orientation métier
- orientation service
- process opérationnels basiques adaptés
1- Géré Standardisé
- process manuels
- business process manuels
- réactif
- proximité métier
- catalogue de service
- process complexes en cours de standardisation, règles manuelles
2-Défini Automatisé
- process opérationnels automatisés, orchestration manuelle
- business process manuels
- actif
- piloté avec les métiers, mesuré, controlé
- portefeuille de service
- process complexes standardisés, règles écrites
3-Piloté Orchestré
- process opérationnels automatisés, complexes orchestrés
- business process manuels ou en cours d'orchestration
- proactif
- anticipé et piloté avec les métiers
- portefeuille de service maintenu
- gestion centralisée des services en cloud hybride
4-Gouverné Hyper-Orchestré
- process opérationnels orchestrés par des règles dynamiquement
- business process hyper-orchestrés
- innovant
Figure 54 : Maturité « Cloud » des processus
Nous n’avons pas détaillé la phase 0, le chaos, celle ou rien n’était géré, car il est difficile d’y
automatiser.
1.1) La standardisation
Standardiser les processus
Standardiser c’est aussi simplifier les processus, ou pourvoir réutiliser des morceaux de processus
pour un autre processus, en travaillant toujours de la même façon, avec les mêmes bibliothèques, les
mêmes versions, de même produit et de manière modulaire, à chaque fois que c’est possible et que
l’effort est justifié.
Il faut étudier les processus et mesurer les écarts avec l’objectif. Par exemple pour le cloud hybride, il
faut étudier comment sont gérer les approvisionnements des clouds externes, pour étudier une mise
en place de cloud hybride…afin de voir ce qui peut être automatisé.
Ne pas négliger les résistances aux changements
La standardisation passe souvent par la mise en place de « Best Practice ». La mise en place d’outil
n’a jamais résolu seule des soucis d’efficience ou de délais, l’automatisation ne peut que venir
accompagner des changements structurels.
Par exemple s’il faut dix jours pour obtenir une adresse IP et que le processus reste manuel sans
délégation de plage IP disponible, cela constituera un goulet d’étranglement. L’automatisation va
s’accompagner de délégation de pouvoir et de transfert de compétence.
Standardiser la technique
Une entreprise ne peut pas aller vers l’automatisation et encore moins vers l’orchestration d’un
cloud hybride si elle n’a pas passé le premier stade de la standardisation. Ce n’est pas évident, les
fusions, acquisitions sont des challenges réguliers de standardisation. Après une première
standardisation les entreprises se retrouvent souvent avec beaucoup d’applications en double
incompatibles entre elles et des difficultés à consolider les chiffres, la collaboration, les échanges.
 Important
Il faut donc standardiser car en diminuant le nombre de composants, (comme le nombre d’OS et
leurs versions, le nombre de version d’applicatif métier ou de développement, de test)
l’automatisation se simplifie, les efforts sont moins importants, les buildings blocs sont plus
facilement réutilisables. Cette étape n’est pas facile car elle engendre souvent des pertes de
fonctionnalités existantes et une partie des équipes doit abandonner ses compétences sur un produit
pour en acquérir de nouvelles. Mais cela permet de renforcer l’agilité intellectuelle, indispensable.
La standardisation n’est pas évidente. Certaines standardisations n’aboutissent pas pour de multiples
raisons. Le cloud hybride est un réel besoin du marché et nécessite de la standardisation.
Dans le cloud hybride, il faut standardiser la connexion : protocoles, cryptage,…
1.2) L’automatisation
Le « Software Defined Anything » qui est en cours va aider à automatiser les déploiements et les
mises à jour systèmes et applicatifs. L’automatisation actuelle demande encore beaucoup
d’intégration, les buildings blocks standardisés de cette automatisation modulaires seront de plus en
plus faciles à trouver sur le marché.
Le rôle de standard comme Tosca pour la définition des « templates de service » ou Eucalyptus,
CloudStack, OpenStack pour l’approvisionnement de ressource, vont aider. A fonctionnalité
équivalente le produit le plus standard sera favorisé, car plus rapide à intégrer et donc à moindre
coût.
1.3) L’orchestration
Le niveau au-dessus l’orchestration permet d’intégrer la complexité mais aussi des fonctions
supplémentaires de montée en charge ou de réduction de charge, de résilience, de sécurité,
d’application de règles…
1.4) L’orchestration du multi-cloud et des processus
Dans un niveau non-géré, beaucoup d’entreprises utilisent déjà du cloud hybride : des services dans
son data-center et des services en externe, mais sans véritable gouvernance. Tant que l’utilisation est
faible cela peut sembler gérable. Sachant qu’il faut appliquer à ces services les politiques de sécurité,
la conformité aux règles et législation, la maîtrise de coûts,…. La multiplicité des réponses externes à
des besoins internes risque de devenir vite ingouvernable.
Un autre challenge du multi-cloud est la compatibilité des architectures. Ce n’est pas parce que nous
aurons deux API-compatibles qui transmettront des fonctionnalités, des paramètres, que ces
fonctionnalités seront gérées de la même façon, avec les mêmes paramètres… dans chaque cloud.
2) La cartographie de l’existant
L’existant doit être pris en compte sauf pour une entreprise nouvelle, les aspects coûts, risque et
temps, ne permettent pas en général de faire un « big-bang » cloud
2.1) L’étude des contrats fournisseurs
Les fournisseurs de tierce maintenance, de licence ou de maintenance sont des points potentiels de
blocage ou de surcoûts projets. Ils ont été abordés dans l’étude de stratégie et peuvent influer sur la
priorité d’un projet. Dans cette phase ils peuvent être étudiés dans un niveau granulaire plus précis
pour en estimer l’impact.
2.2) La cartographie des produits existants
L’étude peut se faire par niveau : réseau, stockage, traitement, gestion des applications
Figure 55 : Cartographie de l'existant
3) L’étude des écarts entre l’existant et les exigences
2.1) La classification de l’existant
Les exigences ont été classifiées dans l’étude de la stratégie business, sécurité et demande.
Par rapport à ses exigences, il est possible de classer l’existant : obsolète, conforme sans plus ou
entièrement satisfaisant, ou inutile. Il faut étudier en isolé mais aussi dans l’écosystème si leur
intégration est judicieuse ou si un remplacement peut-être moins coûteux sur le long ou court terme.
L’objectif est aussi de simplifier, de diminuer le nombre de composants pour simplifier l’intégration,
l’automatisation, les montées en charge, les déplacements de service.
2.2) Le produit sur étagère ou le développement
Pour gagner en efficience informatique chaque cas d’usage client doit être traité en favorisant la
standardisation.
Pour les cas d’usage où les produits standards ne semblent pas être le plus efficace au niveau métier,
un calcul des gains sur les gains métier (efficience, impact du risque potentiel) mis en parallèle avec
le coût informatique de développement et de maintien d’un développement spécifique doit être
effectué.
Il faut connaître et intégrer, interfacer des solutions existantes en connaissant les risques pris, les
coûts et économies générés. Le multi-cloud en est un exemple.
L’intégrateur
Dans un marché en pleine évolution il faut savoir s’appuyer sur ses forces pour garder et gagner des
parts de marché.
Le rôle de l’intégrateur est de connaître les solutions du marché et d’aider le client à trouver la
solution qui lui convient et les compétences pour l’intégrer. Sa force c’est de pouvoir approvisionner
sans a priori technique, sur tous les catalogues du marché.
La construction d’une infrastructure de cloud hybride gouverné est hautement complexe à intégrer
et à maintenir et requiert des compétences importantes… Les étapes à franchir sont importantes…
Dans sa démarche il ne faut jamais perdre de vue que le cloud évoluera dans un esprit d’amélioration
continue. Il faut donc dans le cadre d’une vision long terme, le garder ouvert, modulaire,
interopérable.
2.3) Le calcul de l’effort pour répondre aux exigences
Réussir à faire correspondre l’existant, les exigences et les solutions potentielles, est un nouveau
challenge.
Que faut-il faire pour répondre aux exigences et quel serai l’effort : changements, délais, coûts ?
Section 3 : La définition des priorités
1) La taille du projet
Préférer des projets courts et des pilotes
Dans une démarche agile, il est démontré que de favoriser des projets rapidement mis en place, de 3
à 6 mois, et avec un retour rapide sur investissement est un facteur favorisant la réussite. De même il
vaut mieux favoriser un pilote qui aura une utilité immédiate avec une capacité opérationnelle, qu’un
Proof Of Concept ne servant que de démo et manquant souvent de pertinence.
La mise en place d’un cloud hybride demande encore beaucoup d’intégration en raison de la
maturité du marché. Il faut donc focaliser sur des intégrations simples, mais indispensables.
Analyse du risque
L’analyse des risques : impacts et probabilité est indispensable. Elle doit prendre en compte l’analyse
financière des fournisseurs de cloud, la répartition géographique des clouds internes et externes,…
2) Le retour sur investissement
Le vrai ROI n’est pas simple à calculer car il comprend : le coût, la qualité, les délais, la compétitivité.
Le ROI est souvent calculé à partir des coûts du TCO :
- Matériel, Licences, Middleware, Plateforme, Maintenance Editeur, Maintenance

Matériel,
- TMA et support client et administration.
Auxquels viennent s’ajouter : coût de la surface et annexes (électricité, climatisation, sécurité…),

migrations.
Hors la qualité va influer directement les coûts de l’IT, mais surtout la productivité métier, la relation
client, l’image. Le temps ou délais de mise en place d’un projet, d’une solution logicielle vont
directement jouer sur la capacité d’innovation, le Time-To-Market, l’image de l’entreprise.
Les coûts internes du temps passé par les métiers à effectuer des relances et le manque de
compétitivité liés aux délais, ne sont pas faciles à appréhender et ne sont donc souvent pas pris en
compte dans le retour sur investissement.
 Important
Le vrai ROI doit prendre en compte l’agilité apportée par la possibilité d’approvisionner rapidement
en externe la bonne ressource : améliorer l’efficience métier.
Il faut aussi pour cela bien connaître les besoins métier, et se prendre en main l’alignement entre l’IT
et les lignes métier et surtout le client.
Un retour sur investissement se calcule au niveau financier mais également au niveau compétitivité.
Le cloud hybride élastique offre des possibilités de réduction des coûts
Dans le cloud hybride il est possible de mettre des règles sur le coût, la sécurité, la disponibilité, la
performance, … mais également de n’approvisionner que la ressource nécessaire, pour la durée
nécessaire, au meilleur coût.
3) Le périmètre des projets sélectionnés
Une analyse granulaire permet de mieux estimer le périmètre
3.1) Le contexte et le catalogue de service
Les études du contexte (les acteurs, les systèmes et leurs actions) du processus impacté et du
catalogue de service associé vont permettre d’affiner un périmètre réaliste. Il ne faut pas vouloir
décrocher le produit de ses rêves. Mais travailler par phase, pour atteindre rapidement un premier
objectif exploitable, une valeur ajoutée business.
3.2) Les fonctions
L’étude du fonctionnement du processus et de ses relations avec d’autres processus permettent

aussi de mieux cerner le périmètre.
Section 4 : La validation des choix, du périmètre et impact
1) La validation du périmètre, du planning et du budget
La validation du périmètre permet d’affiner le planning.
2) L’implication des acteurs
Le choix des priorités est clairement défini, toute décision doit être systématiquement validée.
Les rôles des acteurs du projet, leur implication dans le projet et l’organisation de la communication
sont des éléments essentiels.
Les acteurs du projet doivent remplir deux rôles complémentaires à la gestion projet, certains
doivent avoir suffisamment de pouvoir pour aider à passer les obstacles qui peuvent se présenter
budgétaires ou humains, d’autres directement impactés par les changements apportent leur vision
pragmatique et préparent le changement.
Le choix des fournisseurs externes de cloud est un élément important à valider dans un projet de
cloud hybride élastique
3) La validation de l’architecture
Figure 56 : Modèle de référence
Par rapport aux étapes précédentes qui recherchait la granularité cette étape est une étape de prise
de recul, pour vérifier la cohérence des choix, les valider.
Il s’agit alors de regarder, au-dessus du modèle de référence qui définit les services, les produits qui
viennent remplir ces fonctions dans un modèle d’architecture.
Section 5 : La mise en œuvre

A chaque étape la correspondance avec les exigences business est validée. Si les exigences n’ont pas
changé au point de remettre en cause le projet, alors nous passons à la réalisation des objectifs. Dans
le respect du planning les commandes sont passées, les compétences sont réservées, la
communication planifiée,…
1) La description complète des services du catalogue de service
La conformité de chaque service par rapport aux exigences est respectée. Les SLA et les métriques
correspondants, sont validés, en accord avec ce qu’il est possible de faire avec les fournisseurs de
cloud et les outils disponibles. Les métriques du cloud hybride élastique doivent mesurer la
satisfaction client, et permettre de distinguer les responsabilités entre opérateur, fournisseur de
cloud et cloud interne hybride.
2) La conception de l’automatisation
L’automatisation va permettre les gains, si les processus sont corrects. Elle doit être modulaire et
standardisée… pour pouvoir intégrer les évolutions sans tout remettre en cause.
3) La gestion du changement
Anticipée depuis le départ la gestion des changements s’inscrit dans le processus de transformation
de l’entreprise et s’élabore en collaboration avec les équipes concernées de façon à rationaliser les
processus, standardiser les outils mais surtout anticiper les changements organisationnels, les
formations. Les pertes de pouvoir sont compensées par un travail plus valorisant, car apportant plus
de valeurs à l’entreprise.
4) La mise en exploitation et le contrôle
Dans une démarche de DevOps, l’automatisation et la mise en exploitation sont intégrés dans le
développement. Les retours se font donc toujours en collaboration avec l’amont : les développeurs
et l’aval, la production. Les métriques sont mises en place et leur pertinence est remise en cause
régulièrement.
Section 6 : Le cycle de vie et l’amélioration continue
1) Le cycle de vie
La gestion du cycle de vie des composants du cloud hybride va concerner les composants internes, la
passerelle, les composants externes. La gestion du cycle de vie sans outil est difficile. Sur une petite
infrastructure il peut s’agir de fichier Excel. Quand les architectures se complexifient et se massifient,
il devient indispensable d’outiller, pour gagner en clarté, en sécurité, en suivi financier, en
conformité.
Certaines données dont les données à caractère personnel doivent être effacées pour respecter la
législation, par exemple.
Des serveurs physique ou virtuels, des stockages sous utilisés ou non-utilisés coûtent cher.
L’archivage est moins cher que la sauvegarde. Certains logiciels de stockage, le font
automatiquement, il s’agit du tiering, dans le cloud hybride il faut pouvoir centraliser l’information
ou le gérer différemment.
2) L’amélioration continue
En s’appuyant sur la roue de Demming (Plan/Do/Check/Act) ou le DMAIC (Define, Mesure, Analyze,

Improve, Control) un processus d’amélioration des automatisations doit être
mis en place. D’autre part la mise en œuvre d’un projet de transformation
incluant du cloud hybride élastique doit s’effectuer par phase, en repartant des
exigences qui évoluent sans cesse il faut dérouler régulièrement toutes ses
étapes pour intégrer de nouveaux processus ou services.
L’amélioration continue nécessite la gestion des retours d’expérience et des

connaissances.
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 2 Les rôles et la gestion des
compétences
Chapitre 2 Les rôles et la gestion des compétences
Section 1 : Le rôle de la DSI, la gouvernance du Système d’Information

Pour gérer le cloud hybride, la DSI devra œuvrer sur plusieurs axes, pour lesquels elle disposera
d’outils.
1) La gestion des fournisseurs
Comme auparavant avec la Tierce Maintenance Applicative, l’hébergement, les services managés, ou
la sous-traitance, le DSI devra gérer le partenariat avec les métiers et le juridique pour contribuer :
- à la validation de contrat avec des fournisseurs de service,

- à la vérification et au suivi de leur conformité par rapport aux exigences du service
fourni.
2) La supervision des performances et l’anticipation de la demande par des

tableaux de bord
L’anticipation de la capacité nécessaire aux services métier est un élément essentiel pour éviter les
dysfonctionnements. Cela passe par une analyse des données existantes et une prévision en lien
étroit avec les métiers, avec l’aide d’outils de supervision et d’analyse prédictive.
Exemple VMWare vCops
Par exemple le monitoring de capacité intégré à vCops de VMWare, basé sur un outil analytique
d’auto-apprentissage comportemental, permet de gérer les capacités. Après une première étude du
comportement pendant trois mois du service, et grâce à des algorithmes prenant en compte
l’expérience précédente de multiples clients, il peut donner des axes d’amélioration et des prévisions
de besoin de capacité.
3) La cohérence du SI en collaboration avec les métiers
Les métiers seront de plus en plus utilisateurs de numérique et sont souvent les mieux placés pour
choisir une solution qui correspond à leurs besoins : achat, logistique, finance, comptabilité, gestion
des talents, communication, maintenance, marketing, cœur métier (édition, fabrication, inspection,
conseil,…).
La DSI peut être force de proposition, mais surtout elle doit toujours assurer la cohérence du
système d’information de l’entreprise, définir les interfaces surtout entre les métiers, les
référentiels, le respect de la stratégie, de la conformité.
A quoi sert une base fournisseur à la comptabilité si elle n’est pas cohérente avec celle des achats ?
La base CRM mise à jour par les commerciaux doit être accessible par le marketing. Toutes les
dépenses : achats, paies doivent entrer dans le système financier.
compétences
4) La gestion du multi-cloud et du cloud privé
Pour gérer plus de complexité et gagner en agilité, il faut automatiser et pour cela il faut :
- faire progresser la maturité et l’agilité des processus,
- définir les automatisations à mettre en priorité, en accord avec la valeur apportée au
business, la stratégie de l’entreprise,
- intégrer des clouds externes,
- veiller à la disponibilité, la sécurité, la conformité.
Section 2 : Les compétences

La complexité des infrastructures de cloud hybride et l’automatisation font apparaître des
changements de rôles, voire de nouveaux rôles.
1) La simplification des processus
Un mauvais processus automatisé reste un mauvais processus. Le passage aux nouveaux

écosystèmes ne peut se faire sans d’abord rationaliser le fonctionnement, déléguer des pouvoirs,
faire évoluer les compétences. Les compétences en rationalisation, simplification des processus sont
alors nécessaires. L’approche reste orientée service mais cherche un peu d’agilité.
2) Le « software defined anything »
Les vocabulaires à la mode (« Buzz words ») sont « Software Defined » ou « Application Centric ».
Que l’on préfère le premier ou le deuxième, tout tourne bien autour du logiciel ou de l’applicatif.
Les objets matériel ou applicatif sont de plus en plus modulaires et paramétrables, donc l’intégration
change : les tâches répétitives sont automatisées, l’intégration demande plus de compétences
« software ». Naturellement sur des logiciels récents : Java, Phyton, Ruby,…
C’est particulièrement disruptif pour le réseau et le stockage.
Pour réaliser ses automatisations il faut savoir modéliser et scripter. Pour gérer un projet il faut en
comprendre le vocabulaire, le fonctionnement, les composants.
Il faut savoir modéliser pour réaliser le design des Services Templates, mais aussi pour programmer
ou scripter en modulaire afin de pouvoir capitaliser, réutiliser des « buildings blocks », ou pour
modéliser les applications, le cycle de vie des applications, le déploiement, les services, les
workflows, les architectures. Il faut savoir scripter pour faire le liant, intégrer.
Les compétences en virtualisation et en consolidation sont complémentaires de ces compétences de

modélisation et de programmation.
3) Le transverse
Les frontières entre le réseau, le stockage, le traitement mais aussi avec le développement et
l’exploitation sont de moins en moins franches. D’ailleurs, la démarche de DevOps vise à rapprocher
compétences
les équipes de développement des équipes opérationnelles et à leur faire effectuer des tâches
autrefois attribuées à leurs collègues. Les fonctions de débordement, de montée en charge font
appel à différents éléments réseau, stockage, traitement, applicatif, ce qui demande une
connaissance des différents « silos ». De plus il faut gérer des fonctions complexes qui font appel à de
multiples compétences.
Il faut donc des compétences transversales, qui s’appuient sur de la modélisation.
4) L’intégration
Comme toujours une bonne connaissance des produits existants du marché et de leur capacité
d’intégration est nécessaire. Suite à cette étude nous focaliserons sur les logiciels d’automatisation et
d’orchestration mais aussi de virtualisation, d’administration, de supervision, de la sécurité.
5) La sécurité
La gestion du risque est essentielle. Elle demande une vue globale : de la formation des personnes,
en passant par la gestion de la conformité et jusqu’à la mise en place de systèmes adaptés. Elle
complète le péri métrique standard : classification, cryptage, tunnel, détection d’intrusion, analyse
comportementale.
La connaissance des produits du marché comme ceux : de la gestion de l’identité et des accès, des
API, de protocoles et de cryptages est importante pour la gestion du cloud hybride.
 Important
En conclusion de cette section sur les compétences nous pourrons conclure que la compétence
principale à avoir est la capacité d’apprentissage, d’évolution qui va permettre une souplesse
d’adaptation. Il ne faudra pas l’oublier dans les matrices de compétences.
De plus il faudra multiplier les sources de connaissance et donc utiliser tous les nouveaux canaux
d’apprentissage, en particulier le partage collaboratif interne et externe.
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Chapitre 3 : La gestion du changement
organisationnel
Chapitre 3 : La gestion du changement organisationnel

L’évolution de l’écosystème est une rupture qui rend obsolète les modèles économiques et
organisationnels précédents, et amène l’émergence de nouvelles organisations, de nouveaux
acteurs, de nouvelles technologies.
- Il faut devenir plus agile, plus innovant en maîtrisant le risque.

- Il faut passer du sur mesure à la sélection de services adéquats : conseil pour
l’intégration, prise en compte du réglementaire.
- Les données deviennent une partie du business, leur valorisation, et protection sont
capitales.
Mais il faut garder la gouvernance, et sans centralisation c’est un travail d’équilibriste.
Pour garder la gouvernance des organisations doivent équilibrer les pouvoirs, simplifier et clarifier les
processus de validation et savoir garder les compétences.
Section 1 : Impact sur les organisations

Les frontières s’étant déplacées, beaucoup d’acteurs du marché : hébergeurs, opérateurs,
intégrateurs sont devenus, en plus de leurs compétences traditionnelles, fournisseurs de services
cloud. Cette transformation n’est pas évidente, car elle demande la création d’une offre compétitive
correspondant aux exigences sur un marché cloud plutôt saturé entre l’offre et la demande. De plus
elles se heurtent à des sociétés qui par des mécanismes d’optimisation fiscales ont des capacités
d’investissement nettement supérieures.
1) Les entreprises nouvelles, les TPI
Plus d’infrastructure interne à mettre en place, elles sont cloud à 100% et si elles centralisent leurs
services ce sera chez un broker de cloud. Des fournisseurs de cloud donnent de plus en plus de
garanties sur la sécurité et des possibilités de liaisons sécurisées et de cryptage, mais cela a un coût.
La gestion de l’informatique consiste à comprendre les métiers, gérer le budget, l’aspect contractuel,
les conformités et le juridique, la sécurité, l’anticipation, en s’appuyant sur des experts externes.
2) Les entreprises avec une infrastructure interne importante
Débordées par la Shadow It, souvent moins cher et plus agile car moins sécurisée, moins maîtrisée,
elles s’organisent en rédigeant des chartes pour leurs employés et en offrants des services
équivalents, agiles, en interne plus sécurisés.
Elles ont de plus en plus d’hybride, mais quand les cloud externes se multiplient il faut soit faire appel
à un courtier de cloud, soit réaliser des solutions d’intégration internes.
La gestion de l’informatique consiste à comprendre les métiers, gérer le budget, l’aspect contractuel,
les conformités et le juridique, la sécurité, l’anticipation, en s’appuyant sur des experts internes et
externes. Mais surtout elle est le centre de rationalisation et de standardisation. Elle doit avoir un
organisationnel
appui fort de la direction, par rapport à tous les métiers, y compris la finance, le marketing, qui
perdent en budget, en personnalisation des outils, pour anticiper l’avenir en apportant de l’agilité et
des baisses de coûts. Elle est au cœur de la stratégie, comme le marketing.
3) Les courtiers
Ce sont déjà les principaux intégrateurs de clouds hybrides. Ils ont besoin de connecter leurs clients à
différents fournisseurs de cloud hybride. Pas étonnant de retrouver des prémices de solutions de
cloud hybride chez certains Ils deviennent alors éditeurs, mais ce n’est pas facile car c’est un autre
métier, il faut gérer les contrats de maintenance, l’ajout de fonctionnalité, les nouvelles versions, les
relations avec les éditeurs et fournisseurs de matériel, pour les compatibilités…
4) Les fournisseurs de matériel et de logiciel cloud
Les fournisseurs de matériel et de logiciel changent de client, le marché se déplace de plus en plus
vers l’intégrateur de cloud privé mais surtout vers les fournisseurs de cloud qui parfois conçoivent
eux-mêmes leurs infrastructures ou leurs logiciels de gestion.
Les grands acteurs du logiciel intégreront de plus en plus de fonctionnalités dans leurs produits et
seront certainement les principales places de marchés des « Service Template » ou Pattern, des API,
des passerelles.
Avec les clouds privés, ils ont encore un marché devant eux et seul l’avenir nous dira si l’informatique
deviendra finalement une commodité comme l’électricité.
5) Les intégrateurs
5.1) Les métiers
Les intégrateurs doivent toujours connaître les outils du marché, qui évoluent. Les applications SaaS
ne demanderont plus beaucoup d’intégration. Au début l’intégration est basique comme avec
OpenStack, puis les packages, les outils se mettent en place, il faut intégrer le niveau supérieur. Ce
qui limite les possibilités de capitalisation interne en IP, la propriété interne étant plus sur le vivier de
compétences, ses capacités à s’adapter. Par contre celui qui a intégrer OpenStack à la main, maîtrise
parfaitement le système et sera plus à même d’intégrer le niveau supérieur.
Il est possible de distribuer ses travaux modulaires sur des stores, mais rapidement avec une date de
« fraîcheur ».
5.2) Le marché
Même soucis que les fournisseurs de matériels et de logiciels, si le marché devient commodité et que
le nombre d’acheteurs se réduit la pression risque d’être encore plus forte sur les prix. En attendant
un intégrateur qui a les compétences demandées par le marché devrait avoir beaucoup de travail, a
lui de favoriser les bonnes formations.
organisationnel
L’intégration actuelle ne sera pas forcément réutilisable, les fournisseurs de logiciel étant déjà sur ce
type de problématique avec la gestion de drivers et de firmwares.
6) Les info-géreurs
Les métiers changent surtout pour l’infogérance de tâches basiques et répétitives, les plus faciles à
automatiser. Si le nombre d’acheteurs se réduit la pression risque d’être encore plus forte sur les
prix. Ils doivent être des professionnels de l’intégration de passerelles, de l’automatisation pour en
gérer le support. Ils doivent rendre plus convivial la supervision et proposer les tableaux de bord.
7) Les hébergeurs
Ils se mettent au cloud progressivement. Ils doivent proposer de la valeur par rapport aux
mastodontes du marché : de la localisation, de la transparence, de la visibilité, de l’hébergement de
fournisseur SaaS, des services de sécurité, de courtiers,... tout en sachant que s’il le peut le
mastodonte le proposera également.
8) Les éditeurs de progiciel
Pour des éditeurs de progiciels d’administration ou de comptabilité française avec des spécificités
très nationales, il reste encore un créneau de passage dans des solutions progressivement hébergées
puis SaaS. Pour la majorité la concurrence sera rude et le virage doit être pris.
Des partenariats se développent entre les majeurs du marché pour proposer des solutions
optimisées, infrastructure et logiciel.
Il éditeurs doivent développer des nouveaux logiciels, ceux-ci devant être adaptés au nouveaux
fonctionnement : asynchrone, sans état, gestion de files, multi-locataire, modulaires,… Par exemple
SAP qui a créé HANA.
Section 2 : Réversibilité
Comme pour la sécurité il faut comparer avec la situation actuelle pour voir si l’évolution permet de
gagner ou non en liberté de choix. Les projets de migration d’un ERP à un autre, d’une Tierce-
Maintenance à une autre, peuvent être longs et coûteux.
La différence entre une migration sur site et une hors site est essentiellement sur le coût et les
formalités de la récupération des données par internet, et l’accessibilité en cas de défaillance du
fournisseur. Le cas s’est déjà produit en Angleterre avec une société qui demandait de l’argent pour
restituer les données suite à une faillite, elles peuvent aussi devenir inaccessibles.
En ce qui concerne le format des données et les procédures de réversibilité, il n’y a pas de grandes
différences avec un engagement sur site.
Il est tentant pour un prix séduisant, des fonctionnalités tentantes, de s’engager sur des offres
contractuellement ou technologiquement moins intéressantes sur du long terme. Pour une bonne
organisationnel
gouvernance, les processus internes doivent être mis en place sur ce sujet avant que le problème ne
se pose, en collaboration avec les services juridiques. Une analyse des risques doit être faite.
 Important
Comme nous l’avons vu précédemment, si les processus d’automatisation sont basés sur des
produits standards du marché, en briques modulaires et avec une bonne interopérabilité, la
migration et l’intégration seront simplifiées.
Section 3 : Le respect de la législation et de la conformité

Le « shadow IT » conduit à des risques internes en fonction de la sensibilité des données mais aussi à
des risques légaux et de non-conformité aux réglementations.
1) Les données personnelles
Les données personnelles médicales ne doivent pas sortir de territoire français. Les données
personnelles permettant d’identifier une personne, nom, prénom et date de naissance par exemple,
ne doivent pas quitter l’Europe à l’exception des zones ayant signé un accord de « Safe Harbor ».
(Loi 78-17 du 6 janvier 1978 modifiée, chapitre 12, article 68, 69,70)
Le Safe Harbor permet à une entreprise de certifier qu'elle respecte la législation de l’Espace
Européen Economique. Le pays doit également avoir signé des accords avec l’EEE. Le transfert des
données personnelles de l'EEE est alors autorisé par l’EEE conformément à la directive 95/46/CE. Il
s’agit d’une obligation de moyen. C’est donc un engagement très limité.
Les données ne doivent être gardées que si elles sont nécessaires et ne doivent pas être conservées
quand elles ne sont plus utiles. (Loi 78-17 du 6 janvier 1978 modifiée, chapitre 2, article 6,7 …)
Les risques encourus sont des peines de prison et des amendes. (Exemple Loi 78-17 du 6 janvier 1978
modifiée, section 5, article 226-16 à 24 : 5 ans d’emprisonnement et 300 000 €)
Ce sont les lois françaises, les lois allemandes sont plus restrictives au niveau des données
personnelles. Plus largement la législation de chaque pays est différente ce qui complexifie le
fonctionnement multinational du cloud computing.
2) D’autres aspects
Pour des règles comme le PCI-DSS sur les paiements bancaires, par exemple, il faut également
assurer la conformité du transfert des données.
3) La localisation en cloud hybride
En cloud hybride, il faut savoir où seront localisées les données, mais surtout où elles seront
sauvegardées pour le Plan de Reprise d’Activité ou de Continuité d’Activité du fournisseur de cloud
par exemple, et quelle est la politique d’effacement ou de résilience des données.
organisationnel
Ensuite il faut vérifier les risques légaux et réglementaires, en fonction du pays et des données.
Les responsables de l’IT doivent donc travailler avec le juridique. Et en ce qui concerne les métiers ils
doivent travailler en collaboration avec les responsables de l’IT et le juridique pour mieux maîtriser
les risques. Des métiers de responsable du suivi de la conformité et de la légalité sont parfois
nécessaires dans la continuité des Correspondants Informatique et Liberté.
Section 4 : Analogie avec le « software defined »

Reprenons notre exercice de la 3ème partie « Les processus et l’outillage », transportons-nous dans
une société « multi-sites » et essayons l’exercice de style de faire du « software defined »
organisationnel.
Nous avons les silos infrastructure, applications et production. Nous leur appliquons déjà la
philosophie de DevOps, c'est-à-dire que les développeurs intègrent les notions de mise en
exploitation et de production. Ce qui conduit par exemple un développeur à préparer des scénarios
de recette, afin qu’il intègre les notions de déploiement et de support.
Si nous suivons le schéma « Software Defined », nous faisons une abstraction entre la partie
traitement et la partie contrôle, pour centraliser le contrôle qui doit gérer la configuration et
l’approvisionnement des ressources. Les ressources sont les composants matériels. Les experts des
domaines infrastructure (réseaux, stockage, traitement), applicatif (développement, production) et
métier les contrôle de manière centralisée à un niveau transverse, central et collaboratif. Ils
permettent la mise en musique, l’orchestration.
Ce qui va nous permettre d’effectuer des fonctions multi-domaines d’expertises : de l’équilibrage de

charge, du débordement, de l’embarquement… en respectant des politiques, des règles,…
financières, de sécurité, de conformité. La supervision de l’automatisation, la définition des
politiques et des règles reste l’humain.
Naturellement grâce à des outils de mesure et de l’analytique qui s’appuie sur les données massives,
la supervision gérée par logiciel crée les tableaux de bord ciblés métier, technique, exécutif ou
financier.
Nous sommes aussi ne l’oublions pas sur de « l’Application Centric », nous gérons le déploiement des
ressources à l’aide d’outils qui intègrent des scénarios complexes. Le niveau transverse, central et
collaboratif est aussi géré par logiciel.
QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE ELASTIQUE Synthèse de la quatrième partie : La mise en
œuvre de projet de Cloud hybride
Synthèse de la quatrième partie : La mise en œuvre de projet

de Cloud hybride
Les mises en œuvre de projet de cloud hybride nécessitent de connaître la stratégie de l’entreprise
et des métiers, de connaître les écarts entre l’existant et les exigences pour mettre en place des
solutions avec un retour rapide sur investissement. Il faut également mesurer la maturité des
processus de l’entreprise, pour passer au stade supérieur et gérer les priorités en fonction des
budgets. Ensuite en fonction des outils existants il faut valider le périmètre, l’architecture et les
plannings, et s’assurer de l’implication des acteurs. Après avoir fait des choix d’intégration en
privilégiant les produits sur étagère interopérables, il faut mettre en œuvre.
Les nouvelles compétences doivent permettre à la fois de travailler en modulaire pour gérer la
complexité et en transverse pour intégrer les exigences métier. Les différents composants de
l’infrastructure à la supervision des business process, prennent en charge les aspects de conformités
légales et réglementaires, sans oublier la sécurité et l’interopérabilité.
Mais il n’y aura pas de bénéfice si le projet n’est pas pris dans son ensemble, il s’agit de projets de
transformation qui nécessitent une gestion du changement. Nous avons regardé globalement les
changements organisationnels en fonction du rôle de l’entreprise dans le marché de l’IT, qui vont
nécessiter une maîtrise de l’automatisation et de l’intégration mais surtout plus de transverse, de
collaboratif.
CONCLUSION Prospective
CONCLUSION
Vers une hyper-orchestration sans-couture entre clouds….
Prospective
Evolution technologique
Figure 57 : L'évolution d'infrastructure vue par Intel
La figure ci-dessus montre une agrégation de la mémoire et du traitement, des ensembles mémoire,
cache, stockage. Le rassemblement de composants dans une infrastructure pour gagner en
performance est intéressant si l’on ne perd pas en évolutivité, compatibilité, interopérabilité,
souplesse, agilité. Pour les configurations matérielles et logicielles les plus fréquentes des blocs
optimisés sont créés. Il ne faut pas d’opposition entre pré-intégrer, optimisé et évolutivité. Les
solutions doivent rester interopérables simplement pour s’adapter à moindre coûts à la forte
évolution en cours.
Les évolutions réseau, stockage, mémoire vont être accompagnées d’évolutions applicatives,
fonctionnelles, chacun tirant l’autre vers le haut. La concentration appelle une densification des
composants qui se réorganisent. La modularité est importante pour l’évolution.
La démarche actuelle qui diminue l’adhérence et assouplit l’automatisation va vers une

externalisation du contrôle. Pour limiter les effets sur la bande passante, ce contrôle est hiérarchisé.
Grâce aux interfaces standardisées les environnements hétérogènes seront plus faciles à intégrer, à
centraliser.
D’un autre côté les tâches qui n’ont pas besoin de configuration centrale seront traitées au niveau du
composant pour améliorer les rapidités de traitement et ne pas occuper de bande passante.
CONCLUSION Prospective
Un écosystème
Les innovations fonctionnelles, comme l’i-Tunes, le smart-phone, l’internet ont du succès quand elles
répondent à un besoin, et qu’elles sont simples et agréables et abordable. L’intégration et
l’automatisation en s’appuyant sur du modulaire doit donc être simple, agréable et si pas chère. Il
faut essayer, progressivement, d’arriver aux «3 clics » de l’e-commerce. La créativité peut-être dans
la simplification.
Les écosystèmes en cours qui évoluent beaucoup sont : l’analyse big data, l’internet des objets, la
réalité augmentée, la convergence numérique, le multi-devices, l’impression 3D. L’innovation est
dans l’intégration de ces nouveautés entre elles ou avec de l’existant comme par exemple le Near
Field Communication ou le RFID pour répondre à un besoin spécifique.
La biotechnologie, les robots… devraient aussi apporter un champ d’innovation. Comment savoir à
l’époque des voitures à cheval que celles-ci seraient un jour tractées par des moteurs à essence ?
On peut imaginer facilement des datacenters entièrement gérés par des robots plongés dans des
fluides bio Tech pour le refroidissement, c’est déjà réalisable. Il ne faut pas oublier que les clouds
vont devoir réduire leur consommation d’énergie, car le prix de l’énergie devrait monter
drastiquement.
Il ne faut pas tout réinventer, il faut assembler des produits sur étagères, des buildings blocks et
donc travailler à plusieurs entreprises sur les projets.
Parallèle avec la finance

Le vocabulaire du cloud fait parfois référence à la finance, comme pour ces trois étapes de maturité
du cloud :
- le courtier de cloud ou cloud broker,

- la place de marché ou market place : des magasins d’API et de package d’intégration, de
- la bourse d’échange de cloud : le surplus de puissance est proposé sur le marché à un prix qui
varie en fonction de l’offre et de la demande.
Ce changement n’arrive pas avec un modèle unique. Dans l’entreprise déjà des entités sont courtiers
de cloud pour d’autres entités.
Le monde est et sera communicant

Les services font appel à d’autres services, pour donner de la valeur ajoutée. Les services sont donc
inter-facturables, ou trouvent un modèle de rémunération en récupérant de l’information
monnayable.
L’internet des objets, avec toutes ses capteurs, va transformer peu à peu notre vie, avec la possibilité
de récupérer des informations à distance, et de les sélectionner à l’aide d’algorithmes reliés au big
data. L’analytique est vraiment un accélérateur d’innovation, elle va aider d’ailleurs à gouverner le
cloud hybride élastique.
CONCLUSION « Le monde qui vient »
Des formations en ligne comme les MOOCs se multiplient. Les outils de collaboration se simplifient et
deviennent de plus en plus intuitifs.
Comment l’automatisation permet l’élasticité

Le « Software Defined Anything », concept qui sépare la couche de contrôle de la couche de
traitement est l’élément central qui permet l’orchestration de l’élasticité en cloud hybride.
L’automatisation d’abord possible au niveau d’une baie, d’un cluster de serveur, devient possible au
niveau d’un datacenter puis de multiples clouds. Pour ceci il faut extraire la couche de contrôle de
chaque composant pour la centraliser grâce au « software ». Pour la centraliser sans effort il faut que
les APIs soient standardisées, mais modulaires pour pouvoir continuer à ajouter de la valeur, par des
modules, sans compromettre la compatibilité. A terme les contrôleurs centraux doivent aussi
répondre à des standards.
Ces contrôleurs centraux, hiérarchisés, permettent de gérer les Fonctions Virtualisées ou xFV
(Anything Fonction Virtualization), qui sont des fonctions faisant appel à différents composants du
cloud : réseau, stockage, traitement, applicatif et flux pour gérer le débordement, la sécurité, les
priorités du service...
Les outils d’approvisionnement de ressource comme OpenStack, les outils d’automatisation,

d’orchestration ou de gestion de cloud, les « Services Templates » comme TOSCA, permettent
d’intégrer et de rendre interopérables le multi-cloud.
La virtualisation du réseau permet de configurer des éléments physiques : il devient plus facile de
leur faire accepter de nouveaux flux en entrée et en sortie de cloud par exemple et d’optimiser, de
contrôler le chemin. La virtualisation du réseau permet d’ajouter des éléments réseaux dans une
machine virtuelle. La virtualisation permet de gérer de la sécurité (VxLAN, Firewall,…). Il s’agit d’un
élément essentiel pour faire de l’élasticité.
« Le monde qui vient »

Pour faire référence à Michel Serres “Le Monde qui vient” est différent. Comme l’arrivée de
l’imprimerie a révolutionné l’acquisition et l’utilisation des connaissances, la profusion d’information,
amenée par les capacités de stockage, sa diffusion instantanée portée par la bande passante, les
contacts « numériques» aidés par les réseaux sociaux, les capacités d’analyse massive, la géo
localisation, la réalité augmentée, l’internet des objets,… vont changer notre monde.
De « DevOps» à l’« Holacratie» (cf. Bibliographie : Holacratie), le management en sera impacté. Le

cadre qui améliore l’efficacité et la qualité montre ses limites. Le monde va vite, le récurent ne se
traite pas comme l’innovation, il faut inventer des systèmes simples, souples, collaboratifs et
créatifs.
L’élasticité du cloud hybride est un focus, sur une évolution technique parmi d’autres qui permet
d’améliorer la collaboration, tout en favorisant la liberté source d’agilité. Les outils pour gérer de
CONCLUSION « Le monde qui vient »
façon simple ces environnements complexes vont se multiplier, certains disparaîtront d’autres
deviendront des standards de facto.
Globalement ces outils s’appuient sur la capacité de traiter des informations en masse et de les
analyser, apportant ainsi des capacités d’auto-apprentissage, afin d’améliorer une automatisation
conduite par des règles, des mesures, des profils. Ils sont basés sur des scénarios qui vont masquer la
complexité. Tout est basé sur des éléments modulaires, qui
s’imbriquent, se paramètrent.
John McCarthy a écrit en 1955 pour une conférence sur l’Intelligence

Artificielle :
"L’étude se base sur l’hypothèse selon laquelle chaque aspect de l’apprentissage ou de tout autre
caractéristique de l’intelligence peut en principe être si précisément décrit qu’une machine peut être
construite pour le simuler» (1).
(1) http://news.stanford.edu/news/2011/october/john-mccarthy-obit-102511.html "The study is to proceed on the basis of the conjecture that every aspect of
learning or any other feature of intelligence can in principle be so precisely described that a machine can be made to simulate it."
C’est ce que fait l’automatisation, l’orchestration mais aussi l’analyse du big-data. La machine vient
aider l’homme. Les changements semblent révolutionnaires pour certains, lents pour d’autres. Ils
s’inscrivent dans une transformation, de la technique, des services, de l’entreprise, de notre monde.
Il ne s’agit pas de savoir s’il faut avancer, mais plutôt de comment nous allons le faire.
CONCLUSION Le reste à faire
Le reste à faire
Les challenges technologiques de l’hybride élastique
Figure 58 : Challenges de l'hybride élastique
Dans l’hybride élastique beaucoup de services existent mais il reste du travail pour simplifier
l’interopérabilité et l’intégration afin de fournir des solutions répondants à toutes les exigences
métier.
Tout n’est pas encore complétement« Software Defined », qu’il s’agisse de l’infrastructure dont le
stockage, de l’applicatif ou des flux.
La centralisation et l’externalisation du contrôle des composants du cloud doit être maîtrisée : elle ne
doit pas apporter des points de faiblesses de type S.P.O.F. (Single Point Of Failure) ou des failles de
sécurité.
Le cloud hybride élastique est là, maintenant il faut le gérer. Des solutions existent déjà de
débordement sur des capacités de traitement ou de stockage (comme celles d’AWS EC2 ou S3). Elles
montent progressivement en fonctionnalités. Ce n’est pas évident car :
- c’est un marché qui bouge vite, il faut s’adapter, cela demande une transformation interne,
- les produits intégrés sont rares, il faut beaucoup d’investissements, et quand la maturité avance, il
faut savoir se débarrasser de ses premières intégrations pour s’approvisionner dans les nouveaux
standards, les nouveaux produits sur étagères, les nouveaux fournisseurs de cloud. Mais cela permet
une montée progressive en maturité des processus et en compétences.
CONCLUSION Le reste à faire
- l’interopérabilité est nécessaire pour gérer la complexité. Plus les couches basses de
fonctionnement sont standardisées plus il est facile d’apporter une vraie valeur sur les couches
hautes.
La maturité des entreprises

Il ne s’agit plus de savoir si on va vers le cloud et l’ensemble des nouvelles technologies mais plutôt
de comment on y va. Le manque de motivation et de combativité seront fatals, il faut évoluer et
s’adapter à son époques malgré la crise et pour cela il faut gérer ses priorités mais en s’ouvrant et en
avançant. Les enjeux sont importants, il faut rationaliser les fonctionnements internes, mutualiser les
compétences, gérer la connaissance, rendre les entreprises plus compétitives en gardant la maîtrise
de ses informations sensibles, de son ADN.
Il faut aussi favoriser et valoriser l’auto-formation, la culture de l’apprentissage, les méthodes, le

partage de connaissance, car le monde bouge vite et il faut rapidement acquérir les changements.
CONCLUSION Les clés du succès
Les clés du succès
La standardisation pour l’interopérabilité
Deux choix pour les majors du marché :

- s’imposer en tant que standard (le monétiser par des places de marché d’API, de SDK, de package),
- travailler en synergie avec d’autres acteurs, en open (« monétisable » par la distribution de
formation ou de certification).
La modularité
La modularité aide à gérer la complexité : en travaillant sur des ensembles plus petits avec des
interfaces en entrée et en sortie.
La modularité aide à simplifier la complexité : car on crée des composants réutilisables. C’est un
élément de la standardisation.
L’objectif : l’agilité, le moyen : la communication
Pour gagner en agilité il faut bien entendu automatiser mais il faut surtout communiquer : les
composants communiquent mais surtout les personnes communiquent pour échanger les
connaissances, et les entreprises développent des solutions communes. Comme dans un projet
OpenSource cela permet d’aller plus vite.
Bibliographie Les clés du succès
Bibliographie
OUVRAGES PROFESSIONNELS
- Scalability Rules M.L. ABBOTT, M.T.FISHER Edition ADDISON WESLEY, 2011

- The Art of Scalability M.L. ABBOTT, M.T.FISHER Edition ADDISON WESLEY, 2010.
- ITIL V3 Edition TSO, 2011
- Cloud Computing Concepts, Technology & Architecture, Thomas Erl with Zaigham Mahmood and Ricardo
Puttini Edition Prentice Hall, 2013
- Cloud Computing : Décider, concevoir, piloter, améliorer, Hennion R., Tournier H., Bourgeois E., Editions
Eyrolles, septembre 2012
- Le Cloud Computing avec Amazon Web Services, Jeff Bar, Edition Pearson ,2011.
ARTICLES DE REVUE DE PRESSE, SITES INTERNET
DMAIC
http://www.lss-academy.com/what-we-do/
http://www.rightscale.com/blog/cloud-management-best-practices/cloud-foundry-architecture-and-auto-
scaling
http://www.kaavo.com/blog/-/blogs/17909
http://blog.octo.com/passer-du-shell-a-puppet/?utm_source=rss&utm_medium=rss&utm_campaign=passer-
du-shell-a-puppet
http://newswire.telecomramblings.com/2011/10/top-cloud-computing-enablers-gaining-mind-share-in-3q-
2011/
Identity in the Cloud Use Cases Version 1.0. 08 May 2012. OASIS Committee Note 01. http://docs.oasis-
open.org/id-cloud/IDCloud-usecases/v1.0/cn01/IDCloud-usecases-v1.0-cn01.html.
http://docs.oasis-open.org/tosca/TOSCA/v1.0/cos01/TOSCA-v1.0-cos01.html
https://wiki.openstack.org/w/images/a/a1/TOSCA_in_Heat_-_20130415.pdf
HYBRIDE
http://maceablog.wordpress.com/2013/04/13/togaf-and-cloud-enterprise-architecture/
http://www.thoughtfeast.co.uk/cloud/cloud-reference-architecture/#more-449
http://www.redhat.com/open-hybrid-cloud/reasons-why/
http://www.rightscale.com/info_center/white-papers/rightscale-white-paper-designing-private-hybrid-
clouds.pdf
http://www.f5.com/pdf/white-papers/f5-vmware-integrating-cloud-white-paper.pdf
http://www.ucstrategies.com/unified-communications-newsroom/f5s-updated-big-ip-aimed-at-sdn-and-
hybrid-cloud-environments.aspx
http://www.crn.com/news/networking/240158395/f5s-latest-big-ip-updates-target-sdn-hybrid-cloud-
environments.htm
http://fr.slideshare.net/randybias/open-cloud-system-networking-vision
TOSCA
https://www.oasis-open.org/committees/tosca/faq.php
GESTION de l’identité dans OpenStack par KEYSTONE

https://www.ibm.com/developerworks/community/blogs/e93514d3-c4f0-4aa0-8844-497f370090f5/?lang=en
Architecture
http://www.dmtf.org/sites/default/files/standards/documents/DSP-IS0102_1.0.0.pdf
https://www.opengroup.org/cloudcomputing/uploads/40/23840/CCRA.IBMSubmission.02282011.doc
http://www.nist.gov/manuscript-publication-search.cfm?pub_id=909505
http://www.crunchbase.com/company/elasticbox
http://en.wikipedia.org/wiki/Cloudsoft_Monterey
Bibliographie Les clés du succès
http://en.wikipedia.org/wiki/Abiquo_Enterprise_Edition
http://www.scalextreme.com/products/workflow-graphical-editor
SAML
http://www.journaldunet.com/developpeur/xml/analyse/la-federation-d-identite-au-travers-de-saml.shtml
Offre en infrastructure cloud

http://jobs.talentburst.com/private/myjobs/openjob_outside.jsp?a=yt6auf6cvmtsdsunxf4laflrqu8kekjj8f3voqs
4jusewuttcz00lpucgthowx6p&SearchString=&StatesString=&source=simplyhired.com&id=3476878
HOLACRATIE
http://integralvision.fr/conscience-integrale/gouvernance-alternative/holacratie/holacratie.html
FIGURES Les clés du succès
FIGURES
Figure 1 : Les motivations principales pour recourir au Cloud.............................................................. 15
Figure 2 : Cycle de battage médiatique du Cloud-Computing - Gartner 2012 ...................................... 16
Figure 3 : Modèles de déploiement du Cloud ....................................................................................... 21
Figure 4 : Tableau des Modèles de déploiement .................................................................................. 21
Figure 5 : Modèles de service du cloud hybride.................................................................................... 24
Figure 6 : Scale-Up versus Scale-Out ..................................................................................................... 26
Figure 7 : Capacité et Niveau de Charge ............................................................................................... 27
Figure 8 : Modèle de référence du cloud privé ..................................................................................... 28
Figure 9 : Acteurs du cloud hybride ...................................................................................................... 29
Figure 10 : Modèle de référence de cloud hybride homogène............................................................. 31
Figure 11 : Cloud hybride VMWare ....................................................................................................... 32
Figure 12 : Cloud Hybride Microsoft ..................................................................................................... 32
Figure 13 : Modèle de référence de Cloud Hybride hétérogène .......................................................... 33
Figure 14 : Gestion de Cloud Hybride IBM ............................................................................................ 34
Figure 15 : Gestion de Cloud Hybride HP .............................................................................................. 35
Figure 16 : Cas d'usage du cloud hybride élastique .............................................................................. 36
Figure 17 : Scale-out en cloud hybride élastique .................................................................................. 39
Figure 18 : Montée en charge dynamique ............................................................................................ 40
Figure 19 : Focus sur les acteurs............................................................................................................ 43
Figure 20 : Forces et Faiblesses du Cloud Hybride Elastique ................................................................ 49
Figure 21 : Acteurs et systèmes clés du Service de Cloud Hybride Elastique ....................................... 51
Figure 22 : Catalogue de Service du Cloud Hybride Elastique ............................................................... 52
Figure 23 : Exemple de complexité de service multi-niveaux ............................................................... 65
Figure 24 : Exemple de processus d’approvisionnement de service en hybride .................................. 66
Figure 25 : Les niveaux d'orchestration du CLOUDaaS ......................................................................... 67
Figure 26 : Orchestrer, automatiser, gérer en hybride ......................................................................... 68
Figure 27 : Exemple de processus de montée en charge ...................................................................... 69
Figure 28 : Orchestration du déploiement en hybride .......................................................................... 70
FIGURES Les clés du succès
Figure 29 : Modélisation du processus de gestion des accès et de l'identité ....................................... 73
Figure 30 : L'infrastructure Stockage, Traitement et Réseau ................................................................ 76
Figure 31 : L'Objectif est de centraliser l'administration ...................................................................... 77
Figure 32 : L'existant en réseau et l'objectif (Inspiré par source Cisco) ................................................ 78
Figure 33 : Du routeur classique au S.D.N. ............................................................................................ 79
Figure 34 : OpenFlow ............................................................................................................................ 80
Figure 35 : OpendayLight d'opendaylight.org ....................................................................................... 80
Figure 36 : Connecter deux clouds par tunnel ...................................................................................... 82
Figure 37 : Deux circuits dans la virtualisation du stockage .................................................................. 84
Figure 38 : Les fonctions internes du stockage ..................................................................................... 85
Figure 39 : Les niveaux applicatifs du "Software Defined" ................................................................... 87
Figure 40 : Les projets OpenStack ......................................................................................................... 89
Figure 41 : Place d'un agent OpenStack en fonction de l'hyperviseur .................................................. 90
Figure 42 : Outil de management de politique d'approvisionnement Multi-cloud .............................. 90
Figure 43 : Extrait d'architecture OpenStack ........................................................................................ 91
Figure 44 : Scénario de déploiement n-niveaux .................................................................................... 92
Figure 45 : Les drivers de l'élasticité...................................................................................................... 93
Figure 46 : Service Template Tosca ....................................................................................................... 94
Figure 47 : Service Template= Structure, propriété et comportement ................................................ 95
Figure 48 : Exemple de Workflow d'automatisation ............................................................................. 98
Figure 49 : Les Passerelles ou librairies d’APIs ...................................................................................... 99
Figure 50 : Outils de gestion de cloud hybride .................................................................................... 100
Figure 51 : Architecture Sécurité Cloud Security Alliance ................................................................... 104
Figure 52 : Processus de gestion d'identité Keystone ......................................................................... 107
Figure 53 : Exemple KMIP .................................................................................................................... 108
Figure 54 : Maturité « Cloud » des processus ..................................................................................... 112
Figure 55 : Cartographie de l'existant ................................................................................................. 114
Figure 56 : Modèle de référence ......................................................................................................... 118
Figure 57 : L'évolution d'infrastructure vue par Intel ......................................................................... 130
Figure 58 : Challenges de l'hybride élastique ...................................................................................... 134
DICTIONNAIRE Les clés du succès
DICTIONNAIRE
Blueprint : dans le contexte du cloud hybride c'est l'image d'une machine virtuelle, sans les applications du fournisseur de cloud.
DCIM (DataCenter Information Management) permet de visualiser graphiquement les emplacements des équipements (électriques,
onduleurs, climatisation) dans un Data-Center avec les informations de câblage électrique, de mesures de l'environnement pour la
maintenance. Ils font partie des ressources à découvrir automatiquement dans une approche "agile" pour rentrer dans l'inventaire, l'outil
de gestion centralisé, l'automatisation. L'interopérabilité entre DCIM, BIM et d’autres outils de gestion comme la CMDB, a un sens pour
fournir une vue réelle et complète de ce qui existe dans le CMS centre de données de changement.
HDFS Data Service : la prise en charge d’Hadoop Distributed File System (HDFS) permet d’appliquer la compatibilité multi site aux
applications traitant un grand volume de données à l’aide de services de données basés sur les objets et les fichiers. Le traitement est
effectué sur le nœud de calcul où résident les données sans nécessairement traverser le réseau, réduisant ainsi le trafic backbone.
Mashup Il s’agit d’applications qui font appel à d’autres applications pour fonctionner. Exemple l’appel à google map dans une application.
Cette fonction est amenée à se développer.
Multi-tenant : Dans le cloud il faut distinguer le multi-tenant applicatif, dans lequel plusieurs clients partagent une même application
développée dans cet objectif, du multi-tenant infrastructure dans lequel les clients partagent une infrastructure commune, par exemple les
serveurs ou un cluster de serveurs ou une unité de stockage. La comparaison la plus courante pour faire une analogie est celle d’un
immeuble dans lequel les différents locataires partagent des parties communes et chacun dispose de ses clés pour accéder à ses parties
privatives. Le muli-tenant exige la gestion de l’isolation des différents « tenants » ou clients. Un client ne devant pas pouvoir monopoliser
les ressources aux dépens d’autres tenants, ne pouvant pas accéder aux données des autres clients ou nuire de quelque façon que ce soit.
REST (REpresentational State Transfer) : Style d’architecture pour les systèmes hypermédia distribués,
Les contraintes sont les suivantes :
• Les responsabilités sont séparées entre le client et le serveur. L'interface utilisateur est séparée de celle du stockage des
données. Cela permet aux deux d'évoluer indépendamment.
• Sans état : Chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur
de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela baisse les interactions entre le
client et le serveur.
• Mise en cache : Le serveur envoie une réponse qui donne l'information sur la propension de cette réponse à être mise en cache,
comme la fraîcheur, sa date de création, si elle doit être conservée dans le futur. Cela permet à des serveurs mandataires de
décharger les contraintes sur le serveur et aux clients de ne pas faire de requêtes inutiles. Cela permet également d'améliorer
l'extensibilité des serveurs.
Une interface uniforme : Cette contrainte est sous-définie en 4 règles essentielles.
• Chaque ressource est identifiée uniquement
• La manipulation des ressources à travers des représentations définies.
• Les messages auto-descriptifs expliquent leur nature. (exemple : une représentation en HTML est codée en UTF-8, le
message contient l'information).
• Hypermédia comme le moteur de l'état de l'application : Chaque accès aux états suivants de l'application est décrit
dans le message courant.
Un système hiérarchisé par couche :
• Les états de l'application sont identifiés par des ressources individuelles.
• Toute l'information n'est pas envoyée dans une seule ressource unique.
RESTful : conforme aux spécifications REST.
Runbook : dans le contexte du cloud hybride c’est le scénario de déploiement unitaire d'une ressource.
SOAP : protocole d’encapsulation standard des messages XML, utilisé principalement par les Web services.
XML Signature est le protocole standard de signature des messages XML. Tout comme XML Encryption il permet de cibler l’élément à
signer. Cela permet à plusieurs intervenants de signer une partie différente du document XML
XML Encryption : protocole standard de chiffrement des messages XML. Il a la particularité de pourvoir chiffrer la globalité du message ou
simplement un sous-ensemble précis. Cela permet d’avoir, par exemple, un document XML en clair avec des valeurs d’attributs chiffrées.
W3C standard définissant les platformes Web pour le développement des applications.
ANNEXE A : API Les clés du succès
ANNEXE A : API
API (Application Programming Interface)

L'API spécifie comment des composants applicatifs doivent interagir entre eux. L'API permet aussi d’accéder à
une base ou à un élément contrôleur inclus dans du matériel, comme un contrôleur de disque dur ou de carte
vidéo. Souvent l'API est une librairie qui spécifie les routines, les structures de données, les classes d'objet et
les variables. Les spécifications d'API peuvent prendre de multiples formes. Elle est basée sur du code source,
contrairement à l'ABI (Application binary interface) qui est basée sur du binaire.
En informatique une interface de programmation (abr. API pour Application Programming Interface) est un
ensemble normalisé de classes, des méthodes ou des fonctions qui sert de façade par laquelle un logiciel offre
des services à d'autres logiciels. Elle est offerte par une bibliothèque logicielle ou un service web, le plus
souvent accompagnée d'une description qui spécifie comment des programmes consommateurs peuvent se
servir des fonctionnalités du programme fournisseur.
Dans l'industrie du logiciel contemporaine, les applications informatiques se servent de nombreuses interfaces
de programmation, la programmation se fait en réutilisant des briques de fonctionnalités fournies par des
logiciels tiers. Cette construction par assemblage nécessite pour le programmeur de connaître la manière
d’interagir avec les autres logiciels, qui dépend de leur interface de programmation. Le programmeur n'a pas
besoin de connaître les détails de la logique interne du logiciel tiers, et celle-ci n'est généralement pas
documentée par le fournisseur.
Des logiciels tels que les systèmes d'exploitation, les systèmes de gestion de base de données, les langages de
programmation, ou les serveurs d'applications comportent une interface de programmation.
Une interface de programmation est une façade clairement délimitée par laquelle un logiciel offre des services
à d'autres logiciels1. L'objectif est de fournir une porte d'accès à une fonctionnalité en cachant les détails de la
mise en œuvre1. Une interface de programmation comporte typiquement des classes, des méthodes ou des
fonctions, des types de données et des constantes1. Une interface de programmation est typiquement mise en
œuvre par une bibliothèque logicielle qui fournit une solution à un problème informatique en faisant
abstraction de son fonctionnement1.
La description de l'interface de programmation spécifie comment des clients peuvent interagir avec un logiciel1
en mettant l'accent sur les fonctionnalités offertes par le logiciel et en cachant les détails de son
fonctionnement1. Une interface de programmation peut être utilisée dans de nombreux programmes et sert
alors de jeu de construction, offrant des pièces de fonctionnalités qui peuvent être incorporées dans des
applications1. Les programmeurs créent des interfaces de programmation pour les autres programmeurs, pour
l'industrie informatique, mais Fonctions des interfaces de programmation en Java[modifier | modifier le code]
Exemples de fonctions gérées à travers des API :

GESTION
Instance Lance Arrête Décrit Liste Suspend Reprend Obtient IP
Image Crée Efface Décrit
Volume Crée Efface Liste Attache Détache Obtient Statut
Securité(KeyPair) Crée Efface Decrit
Backup (Snapshot) Crée Efface Decrit
IP Address Alloue Libére Associe Dissocie
Firewall Setups (Security Group) Crée Efface Decrit
EXEMPLE API AWS: http://docs.aws.amazon.com/general/latest/gr/signature-version-2.htm
ANNEXE B : Le Débordement, l’Equilibrage de charge Les clés du succès
ANNEXE B : Le Débordement, l’Equilibrage de charge
CLOUD Bursting
Le cloud bursting c'est la pratique de " débordement " dans un cloud lorsque la capacité a été atteinte dans le
centre de cloud ou de données de l'entreprise. Le cloud bursting profite de l'équilibrage de charge globale
(load-balancing) - ou d'un point de contrôle stratégique qui agit sensiblement pareil - comme moyen pour
fournir la redirection presque immédiate des demandes vers un cloud externe, dans le cas o des ressources
d'entreprise sont épuisées.
Lorsqu'une demande est reçue, l’équilibrage de charge globale décide si le centre de données (entreprise ou
cloud) doit gérer la demande en fonction de sa compréhension de la capacité. D'autres variables peuvent bien
entendu être mis en place, mais de fonder la décision d'externalisation d'une demande sur d'autres critères
métier ou mesures technique place l'architecture dans un processus de load-balancing et plus des bursting.
Donc, fondamentalement, il y a une règle qui dit que le load-balancing redirige les requêtes vers un cloud A ou
cloud B lorsque le cloud interne est à pleine capacité. C'est un peu plus complexe à mettre en œuvre, mais c'est
au simple que cela pour les opérations de base.
Cloud Load-Balancing
L'équilibrage de Cloud est le routage des demandes vers des applications ou des charges de travail qui se
trouvent dans plusieurs clouds. Il suppose que toutes les instances de l'application déployées dans les
différents clouds sont accessibles en tout temps, ce qui le rend différent du cloud bursting car le débordement
peut effectivement nécessiter le déploiement et/ou le lancement de l'application dans un cloud à distance.
L'équilibrage de cloud n'est pas simplement charger d'équilibrer à travers les clouds.
L'équilibrage Cloud nécessite un décideur sensible au contexte qui peut collaborer avec le reste de
l'infrastructure et des solutions fournissant des mesures et de l'information au niveau des entreprises afin de
prendre une décision, en temps réel , à propos duquel " cloud » doit répondre à toute demande donnée.
Accords de niveau de service, les paramètres d’activité, temps de réponse, la capacité, le coût, puissance, etc...
Une seule ou une combinaison de ces variables peuvent servir de base pour décider comment acheminer une
demande.

Elasticite en Cloud Hybride

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Elasticite en Cloud Hybride

Enviado por

Direitos autorais:

Formatos disponíveis

Hybrid Cloud

Thèse sur l’Elasticité

Remerciements Un besoin du marché

Sommaire Un besoin du marché

NOTE DE SYNTHESE EN FRANÇAIS 12

Des enjeux d’agilité et d’efficience 16

PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 20

Chapitre 2 : L’élasticité dans le cloud hybride 28

Chapitre 3 : Les cas d’usage du Cloud Hybride Elastique 36

Synthèse de la première partie 42

DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES 43

Sommaire Un besoin du marché

Chapitre 2 : Le catalogue de service du multi-cloud 51

Synthèse de la deuxième partie : Exigence et catalogue de Service 61

TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE 62

Chapitre 2 L’outillage de l’infrastructure 76

Chapitre 3 L’outillage spécifique 100

Chapitre 4 La sécurité 104

Synthèse de la troisième partie : processus et outillages 109

QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE

Chapitre 2 Les rôles et la gestion des compétences 121

Sommaire Un besoin du marché

Chapitre 3 : La gestion du changement organisationnel 124

Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride 129

« Le monde qui vient » 132

Le reste à faire 134

Les clés du succès 136

ANNEXE A : API 142

ANNEXE B : LE DEBORDEMENT, L’EQUILIBRAGE DE CHARGE 143

Sommaire Détaillé Un besoin du marché

NOTE DE SYNTHESE EN FRANÇAIS 12

Des enjeux d’agilité et d’efficience 16

PREMIERE PARTIE : LES FONDAMENTAUX DU CLOUD HYBRIDE ELASTIQUE 20

Chapitre 2 : L’élasticité dans le cloud hybride 28

Sommaire Détaillé Un besoin du marché

Chapitre 3 : Les cas d’usage du Cloud Hybride Elastique 36

Synthèse de la première partie 42

DEUXIEME PARTIE : LES EXIGENCES & LES SERVICES 43

Chapitre 2 : Le catalogue de service du multi-cloud 51

Sommaire Détaillé Un besoin du marché

2.6) La gestion de la demande et de la capacité 55

Synthèse de la deuxième partie : Exigence et catalogue de Service 61

TROISIEME PARTIE : LES PROCESSUS & L’OUTILLAGE 62

Sommaire Détaillé Un besoin du marché

3) La gestion des accès et des identités 73

Chapitre 2 L’outillage de l’infrastructure 76

Chapitre 3 L’outillage spécifique 100

Sommaire Détaillé Un besoin du marché

Chapitre 4 La sécurité 104

Synthèse de la troisième partie : processus et outillages 109

QUATRIEME PARTIE : LA MISE EN ŒUVRE DE PROJET DE CLOUD HYBRIDE

Sommaire Détaillé Un besoin du marché

Section 6 : Le cycle de vie et l’amélioration continue 119

Chapitre 2 Les rôles et la gestion des compétences 121

Chapitre 3 : La gestion du changement organisationnel 124

Synthèse de la quatrième partie : La mise en œuvre de projet de Cloud hybride 129

« Le monde qui vient » 132

Sommaire Détaillé Un besoin du marché

Le reste à faire 134

Les clés du succès 136

ANNEXE A : API 142

ANNEXE B : LE DEBORDEMENT, L’EQUILIBRAGE DE CHARGE 143

Note de synthèse en français Un besoin du marché

Note de synthèse en français