Quand le Cloud n'est pas suffisant (triple redondance modulaire)

Vous utilisez une seule source pour vos applications, et vous avez tort.

Très cher administrateur, c'est avec humilité que je te fais cet appel, après un nouvel échec de notre équipe à assurer la disponibilité de notre application. Je reviens vers mes cours d'ingénieur, j'en profite pour optimiser, diminuer les coûts et harmoniser.

Cet article s'adresse à toutes les applications qui ont besoin d'un fort taux de disponibilité ou dont les données sont sensibles.

Triple redondance modulaire, cursus ingénieur

https://en.wikipedia.org/wiki/Triple_modular_redundancy

Durant vos cours d'ingénieur, vous avez forcément étudié des procédés pour renforcer votre produit: arrêts d'urgence, détrompeurs, outils surveillance. Aujourd'hui, rappelez-vous de la triple redondance modulaire: un service critique doit être disponible par au moins 3 sources.

Pour votre application, cela signifie que vous devez penser à:

• fournir un service par 3 sources,
• dupliquer la données en 3 sources,
• permettre une balance de l'un à l'autre.

Normes, ISO-27001

https://en.wikipedia.org/wiki/ISO/IEC_27001

Lorsque vous travaillez avec de grandes entités ou à l'international, vous devez assurer à vos clients la capacité à suivre des normes comme l'ISO-27001, qui vous permettra notamment de travailler avec les industries. Ce sont des normes qui sont apparues en 2005 et révisées régulièrement.

L'ISO-27001 repose sur 3 pilliers:

• La confidentialité de l'information,
• L'intégrité de l'information,
• La disponibilité de l'information.

Pour obtenir cette certification, avoir une seule source de donnée et une seule source applicative ne sera pas suffisante, vous allez devoir appliquer la triple redondance modulaire. Vous ne pouvez pas dépendre que du serveur qui tourne dans vos locaux, vous ne pouvez pas non plus dépendre que d'un cloud.

Les apports des Clouds et des Serveurs internes

Les avantages d'un cloud:

✅ démarrage plus rapide,
✅ pas de gestion matérielle,
✅ compétences techniques matérielles sous-traitées (moins de salariés),
✅ des normes déjà appliquées (ex: redondance),
✅ flexibilité et dimensions à la demande,
✅ service au plus près du client.

Les avantages d'un serveur interne:

✅ gestion entière supervisée soi-même,
✅ coûts fixes,
✅ sécurité de l'information assurée,
✅ migrations faciles,
✅ pannes gérées soi-même,
✅ responsabilité maîtrisée,
✅ évolutions au besoin,
✅ serveurs développé pour correspondre au client, sans superflus.

Dans cet enchevêtrement d'avantages, il faut comprendre:

1. qu'un cloud vous aidera à démarrer et prendre des bonnes pratiques tôt dans le développement de votre application ⭐,
2. que (dès que possible) vous avez intérêt à favoriser un service interne de l'application et des données ⭐⭐,
3. que vous aurez besoin de cloud en cas de problème en interne et programmer une balance ⭐⭐⭐,
4. que vous devrez permettre une redondance du service sur le cloud ⭐⭐⭐⭐.

En choisissant une triple redondance de votre service (en ayant au moins 3 serveurs internes et clouds), vous allez même pouvoir déterminer la donnée qualitative en cas de conflit entre deux services: les deux serveurs qui donnent la même réponse ont raison, le serveur qui répond différemment doit corriger sa donnée corrompue ⭐⭐⭐⭐⭐.

Réussir la balance

Favorisez l'utilisation de l'application en interne: son coût fixe vous permet de prévoir un budget correctement, tandis que le cloud peut prendre le relais en cas de surcharge ou de panne. Le coût d'un cloud est plus difficile à prévoir. Lorsque seul votre serveur interne tourne, vous faites de grosses économies sur le cloud.

Quand vous aurez choisi comment disperser vos services (combien de serveurs internes et serveurs clouds) et quand vous aurez défini le type de service nécessaire (FaaS, SaaS, PaaS, IaaS, On-Premise), alors vous pourrez déterminer le cloud le plus proche de vos besoins, démarrer le développement avec lui, tenter d'obtenir le même niveau de service en interne, et enfin chercher un autre cloud avec le même niveau de service pour obtenir la triple redondance.

Pensez à travailler avec au moins un cloud qui peut mettre à disposition des services au plus proche du client, notamment pour éviter les surcoûts liés au téléchargement.

Les outils disponibles

Conteneur et gestion

Dans le cadre d'un développement simple, je recommande plutôt des couples comme Kubernetes et Docker, qui peuvent facilement exporter une configuration similaire entre l'environnement de travail local, le serveur interne et tous les clouds qui permettent ce genre de IaaS.

Développer avec Kubernetes permet d'assurer que tous les serveurs sont les mêmes, et diminue les risques d'obtenir des résultats différents (comme une corruption).

Software-as-a-Service

Dans le cadre d'une application web simple et peu coûteuse, vous avez besoin d'un nom de domaine, d'un serveur HTTP, d'un serveur de fichiers et d'une base de donnée, choisissez:

• Un registar qui permet la balance sur ses CNAME (OVH, Gandi, ...).
• AWS: lambda, S3, RDS
• Azure: Functions, Blob Storage, Database
• Google: Cloud Run, Cloud CDN, Cloud SQL
• Une multitude d'équivalents pour les services internes.

Développer des SaaS compatibles est plus difficile, mais ça permet de diminuer les coûts sur l'exécution.

Nettoyage, synchronisation et sécurité

Cette redondance impose une rigueur exceptionnelle et avec un management coûteux. Vous allez aussi vous assurer que les périmètres sont sécurisés les uns par rapport aux autres et que les synchronisations ne propagent pas d'attaque. Vous devrez vous assurer de 4 services obligatoires:

• déterminer le serveur le plus proche du client pour favoriser les téléchargements proches,
• toujours copier toutes les données dans les autres serveurs cloud et internes,
• s'assurer de l'intégrité régulièrement (ex: tous les jours à minuit UTC avec des clefs de hash) et régler les corruptions de données,
• produire des rapports de synchronisation.

Block-chain

Dans l'esprit de la redondance et de l'intégrité des données, la block-chain propose une approche systémique pour déterminer une source sûre et décentralisée. En réalité, on n'est pas loin d'une block-chain.

Selon votre format de donnée, vous pouvez faire appel à la block-chain. J'estime que la plupart des applications auront besoin de services qui gèrent des données dont les formats seront très différents les uns des autres (user, file, checkout, auth), et vos serveurs CDN ou PostgreSQL méritent des services de synchronisation à leur échelle.

Conclusion

Assurez-vous rapidement que vous n'êtes pas dépendant d'une seule source de données. Un serveur interne et un cloud peuvent travailler de façon complémentaire. Vous obtiendrez une application sécurisée, robuste et prête pour travailler avec les entreprises internationales.