résilience du cloud computing: de l’illusion à la réalité

© ViFiB SA 2012 – All rights reserved

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

Cercle du théâtre 16/01/2013


Quelques chiffres... (IWGCR)

1 Amadeus2 Facebook345 Google6 Yahoo!7 Twitter89 Microsoft

10111213 OVH

Rank Service Yearly Unavailability (hour) Availability(%) 0.167 99.998% 0.500 99.994%

ServerBeach 0.667 99.992%Paypal 0.833 99.990%

0.833 99.990% 1.000 99.989% 1.167 99.987%

Amazon 4.000 99.954% 5.167 99.941%

Hostway 12.000 99.863%BlackBerry 12.000 99.863%NaviSite 28.000 99.680%

28.333 99.677%

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


Rêve n°1 Les datacenters sont inviolables


Réalité: la guerre4G Internet

Open Source ERP5

Mobile Banking

Ubuntu Desktop

IvoryCoast


Rêve n°2Il 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

http://www.sei.cmu.edu/library/abstracts/news-at-sei/wattsmar99.cfm


Rêve n°3Le 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°4Les 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°5Les 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 illusionCinq 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 ComputingDécentralisation - Répartition - Tests


Hébergement résilient

http://www.slapos.org/




Réseau résilientData Center 1 Data Center 2

Home 1

Office 1Home 2

Office 2

Mesh Overlay Network

re6sthttp://git.erp5.org/gitweb/re6stnet.git

http://git.erp5.org/gitweb/re6stnet.git

http://git.erp5.org/gitweb/re6stnet.git

http://fr.wikipedia.org/wiki/R%C3%A9seau_overlay


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

mailto:[email protected]


Centralized vs. Decentralized

1,000 to 100,000 servers / site

PuE 150% (Standard)65% (Eco Efficient)

2 to 10 sites

1 to 10 servers / site

PuE 100% (Southern Europe)35% (Northern Europe)

100 to 100,000 sites

Highest resiliencyHighest availability


Decentralized Infrastructure


How much does it cost ?

$5,000+ $15 / GB

Effective resilience$100,000 damage protection

$30,000+ $25 / GB

Effective resilience $1,000,000 damage protection

VIFIB is a technical and financial insurance for Cloud outage

mailto:[email protected]


SlapOS Todayrequests per day on SlapOS.orgcontacts synchronized in 1 hourcommercial users of SlapOSinvoices generated in 7.5 hoursSlapOS test suite sizevirtual machines created by SlapOS.orgcomputers subsribed to SlapOS.orgapplications in SlapOS libraryIaaS supported by SlapOScritical applications powered by SlapOScompanies which developing SlapOSCOTS software in SlapOSprice of licenses to build your own Cloud

1,000,000+100,00030,000+

22,0004398230987461+36+

11520

1Ré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

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)

1 Amadeus2 Facebook345 Google6 Yahoo!7 Twitter89 Microsoft

10111213 OVH

Rank Service Yearly Unavailability (hour) Availability(%) 0.167 99.998% 0.500 99.994%

ServerBeach 0.667 99.992%Paypal 0.833 99.990%

0.833 99.990% 1.000 99.989% 1.167 99.987%

Amazon 4.000 99.954% 5.167 99.941%

Hostway 12.000 99.863%BlackBerry 12.000 99.863%NaviSite 28.000 99.680%

28.333 99.677%

8 hours average downtime per yearProbability 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 guerre4G Internet

Open Source ERP5

Mobile Banking

Ubuntu Desktop

IvoryCoast

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°2Il 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°3Le 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°4Les 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°5Les 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 illusionCinq 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

fonctionnent. Mais combien parmi nous vérifient leurs sauvegardes ? Et à quelle fréquence ? Et vérifie-t-

on juste que le robot de sauvegarde a indiqué avoir sauvegardé ou qu'il a vraiment sauvegardé ? Vérifie-t-

on que l'on peut reconstruire l'application à partir des sauvegardes, l'utiliser et produire les mêmes

rapports avec les mêmes résultats ? Imaginez les conséquences sur une entreprise d'une sauvegarde qui ne

produirait plus les mêmes bilans financiers ou – plus simplement – d'une sauvegarde récente mais du

mauvais répertoire.

Enfin, des sociétés spécialistes du plan de continuité vont vous vendre les fameux coffres fort numériques

dits inviolables où rien n’est testé non plus et qui ne sont même pas « monitorés ». En effet il ne s'agit que

de vous vendre des mètres carrés, pas forcément le service dont vous avez réellement besoin.

On comprend donc pourquoi toutes ces solutions ne fonctionnent pas.



Une autre approche du Cloud ComputingDé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


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ésilientData Center 1 Data Center 2

Home 1

Office 1Home 2

Office 2

Mesh Overlay Network

re6sthttp://git.erp5.org/gitweb/re6stnet.git

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

hébergeant leur solution de secours chez nous.

Enfin, une entreprise d’aéronautique et une banque centrale utilisent notre technologie pour du

déploiement et de l'installation complexe de logiciels critiques sur leurs infrastructures.



Questions / Débat

Merci de votre attention. N'hésitez pas à poser des questions ou à nous écrire à [email protected] pour

en savoir plus sur la façon de protéger vos applications ou de rendre un Cloud résilient.



Centralized vs. Decentralized

1,000 to 100,000 servers / site

PuE 150% (Standard)65% (Eco Efficient)

2 to 10 sites

1 to 10 servers / site

PuE 100% (Southern Europe)35% (Northern Europe)

100 to 100,000 sites

Highest resiliencyHighest availability

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 ?

$5,000+ $15 / GB

Effective resilience$100,000 damage protection

$30,000+ $25 / GB

Effective resilience $1,000,000 damage protection

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: [email protected]



SlapOS Todayrequests per day on SlapOS.orgcontacts synchronized in 1 hourcommercial users of SlapOSinvoices generated in 7.5 hoursSlapOS test suite sizevirtual machines created by SlapOS.orgcomputers subsribed to SlapOS.orgapplications in SlapOS libraryIaaS supported by SlapOScritical applications powered by SlapOScompanies which developing SlapOSCOTS software in SlapOSprice of licenses to build your own Cloud

1,000,000+100,00030,000+

22,00043982309

87461+36+

11520

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é

Technology