Résilience du Cloud Computing: de l’illusion à la réalité

Résilience du
Cloud Computing:
de l’illusion à la réalité

Cercle du théâtre 16/01/2013

© ViFiB SA 2012 – All rights reserved

Quelques chiffres... (IWGCR)
Rank Service Yearly Unavailability (hour) Availability(%)
1 Amadeus 0.167 99.998%
2 Facebook 0.500 99.994%
3 ServerBeach 0.667 99.992%
4 Paypal 0.833 99.990%
5 Google 0.833 99.990%
6 Yahoo! 1.000 99.989%
7 Twitter 1.167 99.987%
8 Amazon 4.000 99.954%
9 Microsoft 5.167 99.941%
10 Hostway 12.000 99.863%
11 BlackBerry 12.000 99.863%
12 NaviSite 28.000 99.680%
13 OVH 28.333 99.677%

8 hours average downtime per year
Probability of data loss: > 1% every year


Rêve n°1
Les datacenters sont inviolables


Réalité: la guerre
4G Internet

Open Source ERP5

Mobile Banking
Ivory
Ubuntu Desktop
Coast


Rêve n°2
Il y a moins de bugs


Réalité : bug de réplication

● Software Engineering Institute : 40 bugs toute
les 1000 lignes de code
● 2011 : 4 jours de pannes à cause d'un bug de
synchronisation


Rêve n°3
Le stockage est plus sûr


Réalité : perte de données

● Août 2011 : Amazon perd les données de
plusieurs clients européen.
L'Elastic Block Store d'Amazon supprime
automatiquement des milliers de Snapshot
● Juin 2012 : Firtserver (filliale de Yahoo) perd
les données de milliers d'entreprises
japonaises.
Erreur dans le script d'application d'une mise à jour
de sécurité


Rêve n°4
Les générateurs électriques de secours des datacenter
garantisse la continuité de service


Réalité : pannes électriques

● Avril 2011 : panne électrique chez VMware,
indisponible pendant 10 heures
● Août 2011 : panne électrique à Dublin, les
datacenter de Amazon et de Microsoft Azure
éteints entre 24 et 48 heures
● Juillet 2012 : panne d'un commutateur de
transfert statique chez Salesforce, 13 heures
d'indisponibilité


Rêve n°5
Les catastrophes naturelles n'ont pas
d'impact sur le Cloud Computing


Réalité : bilan mitigé

● Août 2011 : éclair à Dublin
● Octobre 2012 : Sandy
– Deux datacenters déconnectés (et donc tout les services qu'ils
hébergeaient)
– Perte d'un important nœud de communication par intermittence
(avec des effet non négligeable sur le routage)
– Engorgement de la bande passante des « datacenter de secours
» (avec un doute sur la réplication effective des données)
– Globalement le bilan est bon, parce que l'alerte a été donnée 72
heures avant.


Résilience: la grande illusion
Cinq exemples de solutions qui ne fonctionnent pas


5 grandes illusions

● Laisser faire
● Sauvegarde de VM
● Réplication SAN
● Sauvegardes de données
● S… vault


Une autre approche du Cloud Computing
Décentralisation - Répartition - Tests


Hébergement résilient

http://www.slapos.org/


Réseau résilient
Data Center 1 Data Center 2

re6st Mesh Overlay
http://git.erp5.org/gitweb/re6stnet.git Network

Office 2

Home 1
Home 2 Office 1

Tests de résilience

● Principe du test
unitaire
● Rebuild du système
● Rebuild des données
● Vérification d'un use
case
● Tous les jours


Applications industrielles

● Gouvernements : cloud privé + plan de reprise
● Constructeurs automobiles : cloud décentralisé
● Société de conseil : plan de reprise de logiciel
critique sur le Cloud VIFIB
● Aéronautique : automatisation cycle de vie


Questions / Débat


Centralized vs. Decentralized

2 to 10 sites 100 to 100,000 sites
1,000 to 100,000 servers / site 1 to 10 servers / site
PuE 150% (Standard) PuE 100% (Southern Europe)
65% (Eco Efficient) 35% (Northern Europe)
Highest availability Highest resiliency

Decentralized Infrastructure


How much does it cost ?

$5,000 Effective resilience
$100,000 damage protection
+ $15 / GB

$1,000,000 damage protection
+ $25 / GB

VIFIB is a technical and financial insurance for Cloud outage

SlapOS Today
1,000,000+ requests per day on SlapOS.org
100,000 contacts synchronized in 1 hour
30,000+ commercial users of SlapOS
22,000 invoices generated in 7.5 hours
4398 SlapOS test suite size
2309 virtual machines created by SlapOS.org
874 computers subsribed to SlapOS.org
61+ applications in SlapOS library
36+ IaaS supported by SlapOS
11 critical applications powered by SlapOS
5 companies which developing SlapOS
2 COTS software in SlapOS
0 price of licenses to build your own Cloud

Résilience du Cloud Computing : de l'illusion à la réalité 1

Résilience du
Cloud Computing:
de l’illusion à la réalité

Cercle du théâtre 16/01/2013


Bonjour à tous. Je vais vous parler de la résilience du Cloud Computing, de ses mythes, de ses illusions en
vous montrant ce qu'aucun vendeur ne vous dira.


Quelques chiffres... (IWGCR)
Rank Service Yearly Unavailability (hour) Availability(%)
1 Amadeus 0.167 99.998%
2 Facebook 0.500 99.994%
3 ServerBeach 0.667 99.992%
4 Paypal 0.833 99.990%
5 Google 0.833 99.990%
6 Yahoo! 1.000 99.989%
7 Twitter 1.167 99.987%
8 Amazon 4.000 99.954%
9 Microsoft 5.167 99.941%
10 Hostway 12.000 99.863%
11 BlackBerry 12.000 99.863%
12 NaviSite 28.000 99.680%
13 OVH 28.333 99.677%

8 hours average downtime per year
Probability of data loss: > 1% every year


Début 2012, l'International Working Group of Cloud Resiliency (IWGCR) à publié à partir de données
presse un classement des fournisseurs de Cloud Computing.

Ce qu'il faut retenir de ces chiffres, c'est qu'à partir de données issues de la presse, on peut calculer que le
Cloud soufre en moyenne de plus de 8 heures d’indisponibilité par an et d'une probabilité de perte de
donnée supérieure à 1% chaque année.

Si l'on parvient à un tel chiffre avec uniquement quelques rares données de presse, on peut imaginer que
la réalité est encore pire.


Rêve n°1
Les datacenters sont inviolables


Les personnes en charge du marketing du Cloud Computing ont pour métier de vous faire rêver.

Le premier point sur lequel ils voudraient vous faire rêver c'est à propos de l'inviolabilité des datacenters.

Et bien oui. Les accès sont filtrés, le bâtiment est vidéo-surveillé, les portes sont blindées, etc.


Réalité: la guerre
4G Internet

Open Source ERP5

Mobile Banking
Ivory
Ubuntu Desktop
Coast


La réalité est toute autre.

Prenons un exemple récent et grave tel que les événements liés aux élections en Côte d'Ivoire. Le
gouvernement sortant, a décidé de ne pas simplifier la tâche de son successeur. En clair, il a fait détruire
un datacenter gouvernemental, fait disparaître le matériel d'un autre et détruit les sauvegardes sur bandes.
Résultat : des données gouvernementales hautement critiques ont été perdues.

Si le cas peut vous sembler extrême, car les pays où vous mettez vos données sont a priori politiquement
stables et qu'un tel scénario ne semble pas envisageable en Europe occidentale ou aux USA, dites vous
bien qu'aucun datacenter n'est résistant à un attentat direct, par exemple par des éco-terroristes. Il n'est en
aucun cas résistant à l'intrusion par des services spéciaux, qu'ils soient d'un État ou d'une entreprise fusse-
t-elle concurrente, etc.

Bref, un datacenter n'est aucunement inviolable et pourra toujours être détruit par qui s'en donne les
moyens. Sachant que certains services de Cloud, utilisés par toutes les grandes entreprises du monde, ne
reposent que sur un ou deux datacenter, on mesure à quel point le risque est aujourd'hui élevé pour celles-
ci.


Rêve n°2
Il y a moins de bugs


Le deuxième grand rêve que veulent vous vendre les fournisseurs de Cloud Computing, c'est qu'il y a
moins de bugs dans le Cloud


Réalité : bug de réplication

● Software Engineering Institute : 40 bugs toute
les 1000 lignes de code
● 2011 : 4 jours de pannes à cause d'un bug de
synchronisation


C'est faux !

Le Software Engineering Institute, qui est une organisation reconnue mondialement pour son expertise,
indique qu'il y a 40 bugs toutes les 1000 lignes de code en production. D'autres organisations évaluent ce
nombre à 5 pour 1000 lignes, notamment dans le cas de certains logiciels militaires. Nous ne connaissons
pas un seul logiciel de gestion de Cloud Computing qui fasse moins de 1000 lignes code… On peut donc
imaginer le nombre de bugs présents chez les principaux fournisseurs de Cloud, dont les codes sont plus
souvent proches du million de lignes que du millier.

Un des exemples de panne du Cloud lié à un bug que nous pouvons citer est celui qui a mis hors ligne
Amazon Web Service pendant 4 jours en 2011 suite à un bug de synchronisation. Si cela arrive à
Amazon, qui est le leader mondial de ce marché, cela peut aussi arriver à ses concurrents.


Rêve n°3
Le stockage est plus sûr


Le 3ème des rêves que vous vendent les gens du marketing, c'est que dans le Cloud, vos données sont
mieux préservées.


Réalité : perte de données

● Août 2011 : Amazon perd les données de
plusieurs clients européen.
L'Elastic Block Store d'Amazon supprime
automatiquement des milliers de Snapshot
● Juin 2012 : Firtserver (filliale de Yahoo) perd
les données de milliers d'entreprises
japonaises.
Erreur dans le script d'application d'une mise à jour
de sécurité


Là aussi c'est faux.

Il existe une réelle omerta sur la perte de données. Cependant, quand elles impactent trop d'entreprises ou
sont issues de fournisseurs d'infrastructure de Cloud publique, ces informations arrivent tôt ou tard dans la
presse.

Ça a été par exemple le cas d'Amazon Web Service qui, en Août 2011, a perdu des données de clients
européen. En effet, leur système de stockage s'est mis à supprimer des milliers de snapshots de clients car
il pensait qu'elles n'avaient plus lieu d'être là.

En juin 2012, c'est Firstserver, une filiale de Yahoo qui est un équivalent japonais d'OVH, qui a perdu
des données des milliers de ses clients suite à une erreur dans un script d'application d'un patch de
sécurité.

Les dommages qu'ont subis les entreprises concernées sont désastreux, et nous pouvons vous assurer
qu'en aucun cas Amazon ou Firstserver n'ont couvert ces dommages. Ils ont uniquement remboursés les
clients qui se plaignaient le plus. Les contrats d'Amazon et de Firstserver sont en effet rédigé de façon à
ne pas à avoir à indemniser ce type de perte de données.


Rêve n°4
Les générateurs électriques de secours des datacenter
garantisse la continuité de service


On vous a fait également croire que les datacenters sont résistant aux pannes électrique car ils disposent
de générateurs de secours


Réalité : pannes électriques

● Avril 2011 : panne électrique chez VMware,
indisponible pendant 10 heures
● Août 2011 : panne électrique à Dublin, les
datacenter de Amazon et de Microsoft Azure
éteints entre 24 et 48 heures
● Juillet 2012 : panne d'un commutateur de
transfert statique chez Salesforce, 13 heures
d'indisponibilité


Et pourtant… En avril 2011, une panne électrique chez Vmware a rendu leur Cloud indisponible pendant
10 heures. En Août 2011, suite à un orage à Dublin, les datacenter d'Amazon et de Microsoft Azure ont
été éteints entre 24 et 48 heures avec des remises en ligne erratiques. En juillet 2012, c'est un
commutateur de transfert statique, un petit appareil électrique, qui a rendu Salesforce indisponible
pendant 13 heures. Imaginez-vous 13 heures sans pouvoir accéder à votre fichier client…


Rêve n°5
Les catastrophes naturelles n'ont pas
d'impact sur le Cloud Computing


Enfin, vu que l'on parle de nuages, on vous fait croire que les catastrophes naturelles n'ont pas d'impact
sur le Cloud.


Réalité : bilan mitigé

● Août 2011 : éclair à Dublin
● Octobre 2012 : Sandy
– Deux datacenters déconnectés (et donc tout les services qu'ils
hébergeaient)
– Perte d'un important nœud de communication par intermittence
(avec des effet non négligeable sur le routage)
– Engorgement de la bande passante des « datacenter de secours
» (avec un doute sur la réplication effective des données)
– Globalement le bilan est bon, parce que l'alerte a été donnée 72
heures avant.


Là également, ce n'est pas tout à fait vrai.

Comme on l'a vu, la panne de Dublin en Août 2011 est due à un éclair qui a eu pour effet de couper
l'alimentation électrique dans le réseau sur lequel étaient branchés les datacenters d'Amazon et d'Azure.

En Octobre 2012, vous vous souvenez probablement de l'ouragan Sandy. Il a eu quelques effets tels que la
déconnexion de deux datacenters et donc de tous les services qu'ils hébergeaient. Un des datacenters a été
totalement inondé. Un nœud de communication tenu par Google à été perdu. Mais comme les ingénieurs
ont cherché à tout prix à le remettre en ligne, un phénomène d'oscillation instable est survenu et a pris la
forme d'une succession de connexions et de déconnexions du nœud sur le réseau. Ces oscillations se sont
traduites par une instabilité sur les tables de routage et par conséquent sur le réseau lui-même.

Comme tout le monde a cherché en même temps à sauvegarder ses données dans des datacenter de
sauvegarde de l'autre côté du continent, leur bande passante entrante a été saturée. On n'est donc pas
certain que les sauvegardes ont été effectivement faites.

Globalement, dans le cas de Sandy, l'infrastructure américaine du Cloud Computing à bien tenu. L'une des
explications à retenir c'est le préavis de 72 heures qui a permis à tous les responsables de mettre en œuvre
des mesures pour se protéger.

En conclusion, on peut dire que si l'on est prévenu suffisamment à l'avance, le Cloud peut résister à une
catastrophe naturelle. Inversement, pour une catastrophe naturelle imprévisible telle que la foudre, un
tremblement de terre ou une météorite, l'expérience prouve pour l'instant le contraire.


Résilience: la grande illusion
Cinq exemples de solutions qui ne fonctionnent pas


Maintenant abordons les illusions de résilience et les grandes solutions qui ne fonctionnent pas.


5 grandes illusions

● Laisser faire
● Sauvegarde de VM
● Réplication SAN
● Sauvegardes de données
● S… vault


La première des grande illusions, c'est de laisser faire, c'est-à-dire de penser que les opérateurs de Cloud
feront bien leur travail et que l'on est protégé par le contrat que l'on a signé avec eux. On leur laisse donc
décider de ce qu'il va advenir de nos logiciels en ligne et de nos données, et de mettre en œuvre les
moyens qu'ils souhaitent pour les protéger. Pourtant, on sait comme on l'a vu précédemment que des
données critiques d'entreprises ont été déjà été perdues par les opérateurs de Cloud avec des conséquences
irréparables sur l'activité des entreprises utilisatrices. Le laisser faire n'est donc pas une option
raisonnable.

La sauvegarde de machines virtuelles (VM) est vue par certains comme le Saint Graal surtout si cela se
fait entre deux datacenter géographiquement éloignés. On pourrait objecter à cela que l'approche du Cloud
à base de machines virtuelles n'a pas d'avenir à moyen terme, comme l'affirme Forrester Researcher qui
prévoit son remplacement par des approches dites « dynamiques » similaires à celle de SlapOS. A plus
court terme, la sauvegarde de VM ne permettent pas de faire face à une corruption du système
d'exploitation ou du fichier, soit en raison d'un bug soit un raison d'un outil d'intrusion du type de ceux
utilisés par les gouvernements. On risque donc de sauvegarder, avec la VM, ce qui conduit à sa corruption
et donc impossible de pouvoir garantir une reprise en cas de désastre lié à un bug ou à une intrusion.

La réplication sur Storage Area Network (SAN) est une pratique très courante. Pourtant les pertes de
données y sont légion, malgré du matériel toujours plus onéreux et des logiciels les pilotant plus
performants. Une omerta sur la perte de données sur SAN s'est généralisée. Pratiquement tous nos clients
ont subis des pertes de données sur leur SAN, cependant aucun n'est prêt à communiquer sur leur
mésaventure afin que d'autres bénéficient de ce retour d'expérience.

Heureusement, on peut toujours compter sur ses sauvegardes… À condition de vérifier qu'elles


Une autre approche du Cloud Computing
Décentralisation - Répartition - Tests


Nous avons donc choisi de faire autrement, de revenir aux fondamentaux de la gestion des risques et de le
faire très simplement. Cela tient en 3 mots : décentralisation, répartition et tests préventifs.


Hébergement résilient

http://www.slapos.org/


Décentraliser et répartir constitue le fondement même de notre approche. En plaçant nos serveurs partout
dans le monde et à tous les endroits possibles, tels que des maisons et appartements de particuliers, des
entreprises ou même des locaux commun d'immeubles tel que les cages d’ascenseurs et éventuellement
quelques datacenters, nous obtenons une répartition géographique très large de nos serveurs qu'aucune
entreprise ne peut obtenir avec une approche classique.

Une telle approche présente l'avantage d'être résiliente aux cas de force majeure, tels que les événements
naturels, les événements du fait de l'homme ou les pannes d'infrastructure.

Afin de gérer ce genre d'infrastructure aussi répartie et aussi hétérogène, il nous à fallu être innovants.


Réseau résilient
Data Center 1 Data Center 2

re6st Mesh Overlay
http://git.erp5.org/gitweb/re6stnet.git Network

Office 2

Home 1
Home 2 Office 1

Bien évidement une telle répartition des serveurs apporte son lot de problèmes d'interconnexion. Nous
avons dès le début fait le choix d'IPv6 dans notre technologie. Nous nous sommes cependant rendus
compte qu'IPv6 n'était pas toujours bien mis en œuvre chez certains opérateurs. Nous nous sommes
également rendus compte qu'IPv4 connaît de plus en plus souvent des pannes de transit en raison des
interventions gouvernementales encore mal maîtrisées sur les infrastructures, que ce soit pour bloquer des
contenus criminels ou pour mettre en œuvre des outils de surveillance dans le cadre de la lutte contre le
terrorisme ou le téléchargement illégal.

Nous avons avons donc développé ce que l'on appelle un « réseau overlay » pour fournir en tout point du
globe un accès IPv6 résilient. Notre technologie, appelée re6st, fonctionne un peu comme Skype, en
mettant en relation les participants par le meilleur chemin et en changeant si besoin de chemin chaque fois
que c'est nécessaire. Tout comme Skype, re6st fonctionne pratiquement partout dans le monde, sur
n'importe quel réseau d'entreprise, en assurant une quasi qualité de service entre ses points, quel que soit
le protocole utilisé : web, bases de données, transferts de fichiers, etc.


Tests de résilience

● Principe du test
unitaire
● Rebuild du système
● Rebuild des données
● Vérification d'un use
case
● Tous les jours


La répartition des serveurs et un protocole les reliant entre-eux de manière fiable sont suffisants pour faire
fonctionner une infrastructure de très grande échelle mais insuffisants pour garantir une réelle résilience.
C'est pourquoi nous avons mis en œuvre une approche de prévention et de vérification issue du principe
du test unitaire en programmation ou des concepts de prévention des risques industriels.

La résilience de chaque application hébergée sur le Cloud de VIFIB est testée chaque jour de façon
totalement automatique. Nous reconstruisons automatiquement l'application de notre client à partir des
données sauvegardées et du codes source ou binaire. Nous lançons ensuite des tests d'usage automatiques
consistant par exemple, dans le cadre d'une comptabilité, à produire un bilan et à le comparer à un bilan
déjà produit. Grâce à cette approche, nos clients ont la garantie chaque jour que le Cloud de VIFIB est en
mesure de fournir une solution de reprise technique, y compris en cas de force majeure.

Nous appliquons d'ailleurs à nous mêmes les principes du test. SlapOS, notre propre logiciel, dispose de
plusieurs milliers de tests unitaires lancés chaque jour sur une dizaines de points différents sur terre.


Applications industrielles

● Gouvernements : cloud privé + plan de reprise
● Constructeurs automobiles : cloud décentralisé
● Société de conseil : plan de reprise de logiciel
critique sur le Cloud VIFIB
● Aéronautique : automatisation cycle de vie


Pour vous donner une idées des cas d'usage types en voilà 5 issus de nos clients :

Le premier cas concerne des gouvernements qui ont créés leurs propres infrastructures de Cloud
Computing décentralisée avec notre technologie en mixant des micro-serveurs et des serveurs lame
classiques. Comme ils jugeaient, au vu la sensibilité des données à préserver, que le niveau de résilience
qu'ils disposaient déjà n'était pas suffisant, ils ont également souhaités nous confier la préservation de
certains de leurs fichiers. Ces fichiers sont chiffrés sur leur propre infrastructure puis confiés à notre
infrastructure résiliente par un flux sécurisé. Les données qui nous sont envoyées relevant probablement
du secret, seul nos clients disposent de la clé de déchiffrement et nous ne recevons qu'un message
totalement incompréhensible. Une reconstruction après déchiffrement est effectuée et testée sur
l'infrastructure de notre client chaque jour. Une comparaison des fichiers chiffrés entre l'infrastructure du
gouvernement et celle de VIFIB est également effectuée chaque jour. La combinaison de ces deux tests
permet d'obtenir la résilience et le secret. On notera d'ailleurs qu'une partie de l'infrastructure utilisée
repose sur la version Windows de SlapOS, qui permet de transformer les postes de travail peu utilisés en
serveurs de Cloud.

Un autre cas est issu d'un grand constructeur automobile qui souhaite également se créer sa propre
infrastructure de Cloud Computing en la répartissant dans 250 concessions de sa marque sur du matériel
dédié qui joue également la fonction de routeur résilient grâce à re6st. Ce constructeur n'envisage donc
plus de construire ou de louer de datacenter centralisé.

Nous pouvons également citer une grande société de service qui édite un logiciel de gestion de plan de
reprise d'activité opéré en ASP. Ce logiciel contient toutes les informations nécessaires et toutes les
directives à appliquer lors d'un plan de reprise d'activité et ils ont souhaité rendre leur logiciel résilient en


Questions / Débat


Merci de votre attention. N'hésitez pas à poser des questions ou à nous écrire à contact@vifib.com pour
en savoir plus sur la façon de protéger vos applications ou de rendre un Cloud résilient.


Centralized vs. Decentralized

2 to 10 sites 100 to 100,000 sites
1,000 to 100,000 servers / site 1 to 10 servers / site
PuE 150% (Standard) PuE 100% (Southern Europe)
65% (Eco Efficient) 35% (Northern Europe)
Highest availability Highest resiliency

Cette planche montre la différence entre Cloud centralisé et décentralisé, notamment la différence du
nombre de sites et de serveurs par site.


Decentralized Infrastructure


Cette planche montre à quoi ressemble un serveur confié à un particulier. L'exemple de droite montre une
configuration « stable », à côté du téléphone qui est un objet qu'un particulier souhaite voir fonctionner à
tout moment. L'exemple de gauche montre ce qu'il ne faut pas faire : placer un serveur à coté d'une plante
que l'on arrose. Ce « mauvais » exemple montre cependant que les particuliers font attention au matériel
confié : en 1 an, le serveur de gauche n'a jamais été éteint ou arrosé par erreur.


How much does it cost ?

$100,000 damage protection
+ $15 / GB

$1,000,000 damage protection
+ $25 / GB

VIFIB is a technical and financial insurance for Cloud outage

Cette planche donne une idée du tarif d'une protection VIFIB. Ce tarif évolue en fonction des contraintes
de localisation imposée. Pour plus de renseignement: contact@vifib.com


SlapOS Today
1,000,000+ requests per day on SlapOS.org
100,000 contacts synchronized in 1 hour
30,000+ commercial users of SlapOS
22,000 invoices generated in 7.5 hours
4398 SlapOS test suite size
2309 virtual machines created by SlapOS.org
874 computers subsribed to SlapOS.org
61+ applications in SlapOS library
36+ IaaS supported by SlapOS
11 critical applications powered by SlapOS
5 companies which developing SlapOS
2 COTS software in SlapOS
0 price of licenses to build your own Cloud

Cette planche donne une idée de la taille en 2012 de l'infrastructure de VIFIB. Cette infrastructure a
doublé en 2013.

Résilience du Cloud Computing: de l’illusion à la réalité

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Résilience du Cloud Computing: de l’illusion à la réalité

Ähnlich wie Résilience du Cloud Computing: de l’illusion à la réalité (20)

Résilience du Cloud Computing: de l’illusion à la réalité