Il ne vous aura pas échappé que la majorité des clouds n’est pas issue de l’Union Européenne. De Google à Microsoft, en passant par Amazon, aujourd’hui 80% des services sur Internet passent par une filiale d’une entreprise Américaine.
Il n’y a qu’a regarder le top 5 des fournisseurs en France, on ne retrouve qu’un seul français : OVH. Et en Allemagne, il n’y a pas d’européen.
Ce “statu quo” me semblait incompréhensible et peu logique il y a 5 ans. Aujourd’hui, il a pour moi une explication simple : il n’y a pas de bon cloud public européen.
C’est à dire un cloud qui vous fait gagner du temps, est transparent et assure de-facto la sécurité de vos données et systèmes. Actuellement, si vous voulez le même niveau d’exigence, vous devez le faire vous-même ou avec vos équipes. Ce que nous avons fait.
Est-ce que c’est en train de changer ?
Oui, heureusement ! Mais bon nombre de services n’étaient soit pas là en 2021, soit sont toujours en bêta avec un risque de perte de données.
Pourquoi avons nous choisi des clouds public français ?
Cette section peut vous sembler contre-intuitive. En effet, je viens de vous dire qu’il n’y a pas de bon cloud public européen.
Il y a néanmoins un aspect que je n’ai pas mentionné et qui est à l’avantage de ceux-ci. Il s’agit du respect de vie privée et de la confidentialité des données. Deux points critiques si l’on veut éviter l’extradition et préserver le secret industriel.
Bon nombre d’entreprises gardent justement leur infrastructure chez elles pour s’en assurer.
Mais revenons à notre vision chez Fenritec, celle qui nous a poussé à aller à contre courant : Quand vous utilisez nos services, vous restez propriétaires de vos données et nous ne les utilisons pas. C’est ce caractère éthique qui oblige a trouver des solutions alternatives pragmatiques.
Un démarrage difficile
Pour vos donner quelques dates : fin 2020, je partais de mon emploi de consultant en cyber sécurité, en février Fenritec était créée et en mars l’incendie d’OVH arrive. Oups…
Avons nous perdu des données ?
Non, nous n’avons eu que quelques serveurs bloqués.
Aurions nous pu en perdre avec des clients ?
Oui, et c’est là tout le problème ! Heureusement nous n’en avions pas encore.
Nous avions deux conteneurs de fichiers en test chez OVH à Strasbourg : Un conteneur d’archivage et un standard qui sont tous deux vendus comme répliqués 3 fois.
Youpi !!! vous me direz, il n’y a pas de risque.
Le conteneur d’archive a brûlé et les données ont donc disparues ! Aïe!!
Palier les vulnérabilités
Dans l’introduction j’ai mentionné le souci de la transparence du fournisseur. C’est ici un facteur essentiel pour comprendre les risques associés à vos données.
Ici la triple réplication était dans le même bâtiment. Quand vous souscriviez le service vous ne le saviez pas.
Dommage pour les entreprises qui pensaient avoir une bonne sécurité physique et qui avaient des clients.
Les experts me diront que chez AWS, Microsoft et Google vous avez la notion de “Multi Availability Zones” qui permet d’éviter ces désagréments. C’est à dire qu’un centre de données est séparé en plusieurs bâtiments qui sont suffisamment loin pour éviter que le feu ne se propage. Et les données sont répliquées entre ces bâtiments.
Hors, en 2021 ça n’existait pas dans un cloud public européen : i.e. le premier “Multi AZ” français est arrivé cette année en 2022 chez Scaleway.
Nous pensions initialement rester sur un seul centre de données pour les clients particuliers. Après cet événement, nous avons donc mis en place une réplication double comme pour les professionnels. Là aussi avec nos solutions.
Notre approche du multi-cloud “zero-trust”
Face à l’adversité de notre aventure, nous avions donc deux choix :
- Faire du OVH sur plusieurs centres de données,
- Prendre 3 fournisseurs en considérant que l’un d’eux est faillible.
Notre choix s’est fait en fonction des services fournis et bien sûr des risques. Et là ça s’est gâté…
Pour vous donner une liste :
- Chez OVH pas de solution managée, multi centre de données ( Kubernetes sur un seul site ), pas de base de données managée MongoDB,
- Chez 1&1, les serveurs sont en “Europe” mais on ne sait pas où précisément,
- Chez Ikoula, presque pas de managé de haut niveau, juste des serveurs et des machines virtuelles,
- Chez Scaleway, des droits d’accès non réglables ( vous donniez tous les droits, même de détruire des machines virtuelles à votre application qui utilisait un autre service ),
- Chez Scaleway/Dedibox juste du serveur dédié, bref pas trop de choix.
Face à ce tableau resplendissant… Nous avons fait le choix de faire du multi-cloud sur des serveurs dédiés car tout restait à notre charge, quelque soit le scénario.
Notre avantage est clair si OVH, Scaleway ou Ikoula à un souci, nous ne sommes pas impactés. Et, nous ne prenons pas de risque de sécurité inconsidéré.
En contrepartie, cela nous a pris du temps, beaucoup trop de temps.
15 ans de retard
Comme vous pouvez le voir les clouds public européens c’est pas trop mal pour des serveurs dédiés et des machines virtuelles. C’est limite nul comparé à ce qu’offrent les autres quand on parle de gestion d’accès et d’identités, etc.
Oui, on a l’impression d’être dans les années 2000, en 2022.
Bref, je pense que je n’aurai pas assez d’un article de blog pour énumérer toutes les galères que nous avons traversées. Notamment faire reconnaître certaines vulnérabilités IpV6 propres aux fournisseurs.
Néanmoins, en ayant persévéré nous y sommes arrivés et c’est ici l’essentiel.
Comment c’est chez les autres startupers
L’adage chez les autres entrepreneurs que j’ai rencontré c’est bien souvent:
Vu que le temps c’est de l’argent. Et que bien souvent, l’argent on n’en a pas vraiment, on va au plus vite. On y réfléchira après !
Donc c’est souvent du AWS ou du Azure.
À raison, où à tord ?
Seriez-vous prêt à doubler / tripler le temps nécessaire pour avoir une solution française / européenne ?
Merci de m’avoir lu
Si vous avez une question, une remarque, etc. vous pouvez laisser un commentaire.