Cloud hybride : on-bou + cloud

1) Pourquoi l'hybride et quand il est justifié

Pilotes : exigences des régulateurs (data residency/PII), investissements en ligne existants, latitude des systèmes « natifs », contrôle des coûts, accès aux services cloud gérés.
Compromis : complexité des réseaux et de la sécurité, duplication des compétences, synchronisation des données et des configues, risques opérationnels.

Motto : portable là où critique ; cloud-native là où c'est rentable.

2) Modèles hybrides

Extension on-bou : nuage comme extension de centre de données (nouveaux microservices/analystes, fronts).
Cloud-first avec des ancres locales : noyau dans le cloud, on-bou - systèmes de comptabilité/passerelles de paiement/stockage PII.
Cloud-bursting : les pics élastiques de charge dans le nuage (batch, promo-pics), le volume de base est local.
DR to Cloud : une réserve chaude/chaude dans le nuage pour l'on-bou (RTO/RPO gérable).
Edge + Core : Les nœuds PoP/edge sont plus proches de l'utilisateur, les données racine/ML dans le nuage.

3) Réseau et connectivité

3. 1 canaux

Site-to-Site VPN (IPsec/SSL) - démarrage rapide, latence supérieure, jitter.
Les lignes droites (DC/ER/IC, MPLS) sont les SLA prévisibles, en dessous du retard, plus chères.
Dual-link + BGP - tolérance aux pannes et contrôle de routage.

3. 2 Adressage et itinéraires

Un circuit RFC1918 unique sans intersections ; Plan du CIDR pour les années à venir.
NAT-domes uniquement aux frontières ; est-ouest sans NAT.
Segment/VRF pour isoler les environnements (dev/stage/prod), tenants, fournisseurs.

3. 3 Politiques temporelles et DNS

NTP unique (horloge = destin pour la cryptographie/signatures).
Split-horizon DNS : zones internes (svc. cluster. local, corp.local), externe - public.
GSLB basé sur la santé pour le trafic entrant.

4) Identité et accès

Fédération SSO : OIDC/SAML, IdP on-bou ↔ IdP cloud ; SCIM-improving.
Rôles selon le principe du least privilège ; comptes break-glass avec MFA.
Identité machine : SPIFFE/SPIRE ou mesh-PKI pour mTLS.
RBAC « de bout en bout » : Git/CI/CD → cluster/mesh → courtiers/OBD → logs.

5) Plateforme : Kubernetes + GitOps

5. 1 Une seule couche d'exécution

Clusters on-bou et cloud avec les mêmes versions/CRD.
GitOps (Argo CD/Flux) : charts uniques/survols, contrôle de dérive, flux promotionnels.

5. 2 Service-mesh

Istio/Linkerd : mTLS par défaut, équilibrage locality-aware, failover inter-cluster.
Les politiques L7 (JWT, headers, rate limits, retry/circuit/timeout) sont dans le code manifeste.

5. 3 Exemple (K8s topology & mesh)

yaml anti-affinity and distribution by zones on-prem cluster spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }
Istio DestinationRule: local cluster priority, then trafficPolicy cloud:
outlierDetection: { consecutive5xx: 5, interval: 5s, baseEjectionTime: 30s }

6) Données et entrepôts

6. 1 Bases

Maître en ligne, cloud read-replica (analytique/catalogues).
Cloud master + on-bou cache (faible latence pour les intégrations locales).
Distributed SQL/NoSQL (Cockroach/Cassandra) avec quorum local.
La réplication CDC/log (Debezium) entre les boucles ; l'idempotence des manipulateurs.

6. 2 Objet/fichier/bloc

Stores compatibles S3 (MinIO + cloud S3/GCS) avec réplication/inversion ; WORM pour l'audit.
Backaps : 3-2-1 (3 copies, 2 supports, 1 - hors site), vérification régulière de la récupération.

6. 3 Cache et files d'attente

Redis/KeyDB du cluster per-site ; cache global - uniquement via les événements/TTL.
Kafka/Pulsar: MirrorMaker 2/replicator; la clé est la déduplication/idempotence des consumers.

7) Sécurité et conformité (Zero Trust)

mTLS partout (mesh), TLS 1. 2 + sur le périmètre ; interdiction des canaux non cryptés.
Secrets : HashiCorp Vault/ESO ; Des jetons à courte durée de vie ; auto-rotation.
KMS/HSM : clés segmentées par juridiction/tenante ; Crypto-rotation programmée.
Segmentation : NetworkPolicy, micro-segmentation (NSX/Calico), ZTNA pour l'accès admin.
Journaux : Invariable (Object Lock), "trace _ id'de bout en bout, masque PII/PAN.

8) Observation, SLO et gestion des incidents

OpenTelemetry SDK partout ; Collector sur on-bou et dans le nuage.
Tail-sampling: 100% ошибок и p99, labels `site=onprem|cloud`, `region`, `tenant`.
SLO et Error Budgets par tranches (itinéraire/tenant/fournisseur/site) ; alertes par burn-rate.
Dashboards de bout en bout : RED/USE, cartes de dépendance, comparaisons canaries (avant/après les migrations).

9) CI/CD et configs

Un seul registre d'artefacts (pull-through cache sur on-bou).
Flux promotionnel : dev → stage (on-bou) → canary (cloud) → prod ; ou inversement - selon le but.
Vérifications : Tests contractuels (OpenAPI/gRPC/CDC), analyse statique, lissage IaC, scan d'image, gates SLO.

10) DR/BCP (plan de continuité)

• Catalogues/annuaires : RTO 5-15 min, RPO ≤ 5 min ;
• paiements/portefeuilles : RTO ≤ 5 min, RPO ≈ 0-1 min (quorum/synchrone à l'intérieur du site).
• Runbook : bascule GSLB/weights, soulève standby dans le cluster, feature-flags « mode léger ».
• GameDays : tous les trimestres - coupure du site/canal, vérification des vrais RTO/RPO.

11) Coût et FinOps

L'egress entre le nuage et le nuage est le principal débit « caché » ; basculez et réduisez les randonnées au minimum (SWR, edge).
Balise : 'service', 'bou', 'site', 'tenant', 'cost _ center'.
Règle 80/20 : nous transférons/maintenons transférables 20 % du « noyau critique », le reste est là où c'est moins cher.
Downsampling métriques, retences de logs « chaud/froid », budget-aware sampling tracing.

12) Modèles de placement workload's

13) Exemples de configues

13. 1 IPsec S2S (idée)

onprem ↔ cloud: IKEv2, AES-GCM, PFS group 14, rekey ≤ 1h, DPD 15s, SLA monitoring jitter/packet-loss

13. 2 Terraform (fragment de tags/labels)

hcl resource "kubernetes_namespace" "payments" {
metadata {
name = "payments"
labels = {
"site"    = var. site    # onprem    cloud
"tenant"   = var. tenant
"cost_center" = var. cc
}
}
}

13. 3 Vault + ESO (un secret à partir d'un cluster de nuage)

yaml apiVersion: external-secrets. io/v1beta1 kind: ExternalSecret spec:
refreshInterval: 1h secretStoreRef: { kind: ClusterSecretStore, name: vault-store }
target: { name: psp-hmac, creationPolicy: Owner }
data:
- secretKey: hmac remoteRef: { key: kv/data/payments, property: HMAC_SECRET }

14) Anti-modèles

Intersection CIDR → chaos NAT ; d'abord un plan d'adresse, puis des canaux.
Un cache global « partagé » avec une forte consistance → latence et split-brain.
Retrai sans idempotence → doubles charges/commandes.
Un VPN « nu » sans mTLS/Zero Trust à l'intérieur - un mouvement lateral en cas de compromission.
L'absence d'exercices DR : les plans ne fonctionnent pas dans la réalité.
La diversité des versions K8s/CRD/opérateurs → l'impossibilité d'avoir des charts uniques.
Logs au format libre sans 'trace _ id' et masquage - Forenzy impossible.

15) Spécificités iGaming/Finance

Data Residency : PII/Payment Events - en ligne/régional ; dans le nuage - agrégats/anonymes.
PSP/KYC : fournisseurs multiples ; Le routage intelligent à partir du nuage vers les passerelles locales, fallback vers la sauvegarde ; Webhooks par l'intermédiaire d'un courtier avec un grand-père.
« Chemins de l'argent » : les SLO individuels sont supérieurs au total ; HMAC/mTLS, « Retry-After », « Idempotency-Key » sont obligatoires.
Audit : stockage WORM (Object Lock), journaux de transaction immuables, enregistrement bidirectionnel (on-bou + cloud) pour les événements critiques.
Juridictions : segmentation des clés KMS/Vault par pays/marque ; géo-blocs sur le périmètre.

16) Chèque-liste prod-prêt

• Plan d'adresse, DNS, NTP - un ; canaux de S2S + lignes directes avec réserve (BGP).
• Identité unique (SSO/OIDC/SAML), MFA, least privilège ; SPIFFE/SPIRE pour les services.
• K8s dans tous les sites, GitOps, les mêmes opérateurs/CRD ; service mesh с mTLS и locality-aware LB.
• Données : CDC, tests de cohérence, politiques RPO/RTO, backup 3-2-1 et restore-drides réguliers.
• Sécurité : Vault/ESO, rotation, Politiques de réseau, ZTNA ; les journaux sont immuables.
• Observabilité : OTel, tail-sampling, SLO/budgets par site/région/tenant ; les dashboards canariens.
• CI/CD : contrats-tests, lingerie IaC, scan d'images ; release-gates par SLO.
• DR-runbooks, GameDays, mesurés par les RTO/RPO réels ; boutons cutover/roll-back.
• FinOps : limites d'egress, tags et rapports, politique de rétention des métriques/logs/trajets.
• Spécificité iGaming : data residency, multi-PSP, audit WORM, SLO séparé pour les paiements.

17) TL; DR

Hybride = plate-forme d'exécution partagée (K8s + GitOps + mesh + OTel + Vault) sur deux mondes : on-bou et cloud. Planifiez le réseau et l'identité, transférez les données via CDC/idempotence, délimitez la sécurité par Zero Trust, mesurez la fiabilité des budgets SLO/Error et entraînez-vous régulièrement à DR.Pour iGaming, gardez les données et les paiements dans la juridiction, utilisez le routage intelligent multi-PSP et un audit inchangé.