Nor hibrid: on-prem + cloud

1) De ce un hibrid și când este justificat

Drivere: cerințe de reglementare (rezidență de date/PII), investiții on-prem existente, latență la sistemele „proprietare”, control al costurilor, acces la serviciile cloud gestionate.
Compromisuri: complexitatea rețelelor și a securității, duplicarea competențelor, sincronizarea datelor și a configurațiilor, riscurile operaționale.

Motto: portabil acolo unde este critic; nor-nativ în cazul în care este profitabil.

2) Modele hibride

Extensie on-prem: cloud ca extensie a centrului de date (microservicii noi/analiză, fronturi).
Cloud-first cu ancore locale: core în cloud, on-prem - sisteme de contabilitate/gateway-uri de plată/stocare PII.
Cloud-spargere: vârfuri elastice de sarcină în nor (lot, promo-vârfuri), volum de bază - local.
DR to Cloud: Rezervă de cloud cald/cald pentru on-prem (gestionat de RTO/RPO).
Edge + Core: PoP/noduri de margine sunt mai aproape de utilizator, rădăcină de date/ML este în nor.

3) Rețea și conectivitate

3. 1 Canale

Site-to-Site VPN (IPsec/SSL) - porniți rapid, latență mai mare, jitter.
Linii directe (DC/ER/IC, MPLS) - SLA previzibile, sub întârziere, mai scumpe.
Dual-link + BGP - toleranță la erori și control de rutare.

3. 2 Adresarea și rutele

Diagrama RFC1918 unică fără intersecții; Planul CIDR pentru anii următori.
NAT-domuri numai la frontiere; est-vest fără NAT.
Segment/VRF pentru izolarea mediilor (dev/stage/prod), chiriași, furnizori.

3. 3 Politici de timp și DNS

Single NTP (ceas = soarta pentru criptografie/semnături).
Split-orizont DNS: zone interne (svc. cluster. local, corp.local), extern - public.
GSLB bazat pe sănătate pentru traficul de intrare.

4) Identitate și acces

Federația SSO: OIDC/SAML, IdP on-prem ↔ cloud IdP; Provizionare SCIM.
Roluri în conformitate cu principiul celui mai mic privilegiu; conturi de sticlă spartă cu MAE.
Identitatea mașinii: SPIFFE/SPIRE sau mesh-PKI pentru mTLS.
RBAC "end-to-end': Git/CI/CD → cluster/mesh → brokeri/DB → busteni.

5) Platformă: Kubernetes + GitOps

5. 1 Singur strat de execuție

Clustere on-prem și nor cu aceleași versiuni/CRD.
GitOps (Argo CD/Flux): diagrame/suprapuneri unice, control în derivă, fluxuri promoționale.

5. 2 Plasă de serviciu

Istio/Linkerd: mTLS implicit, echilibrare conștientă de localitate, failover inter-cluster.
Politicile L7 (JWT, anteturi, limite de rată, încercați din nou/circuit/timeout) - în cod manifest.

5. 3 Exemplu (topologie K8s și plasă)

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) Date și stocare

6. 1 Baze

On-prem master, cloud read-replica (analytics/directories).
Cloud master + memorie cache on-prem (latență scăzută pentru integrări locale).
Distribuit SQL/NoSQL (gandac/Cassandra) cu cvorumuri locale.
Replicarea CDC/jurnal (Debezium) între bucle; idempotența manipulatorilor.

6. 2 Obiect/fișier/bloc

S3-compatible storuri (on-prem MinIO + cloud S3/GCS) cu replicare/versionare; WORM pentru audit.
Copii de rezervă: 3-2-1 (3 copii, 2 medii, 1 - offsite), verificare periodică de recuperare.

6. 3 Cache și cozi

Redis/KeyDB cluster per site; cache global - numai prin evenimente/TTL.
Kafka/Pulsar: MirrorMaker 2/replicator; cheie - deadup/idempotenta consumatorilor.

7) Securitate și conformitate (Zero Trust)

mTLS peste tot (plasă), TLS 1. 2 + pe perimetru; dezactivarea canalelor necriptate.
Secrete: HashiCorp Vault/ESO; jetoane de scurtă durată; auto-rotire.
KMS/HSM: chei segmentate pe jurisdicție/chiriaș; rotații cripto programate.
Segmentare: NetworkPolicies, micro-segmentare (NSX/Calico), ZTNA pentru acces admin.
Busteni: imuabil (Object Lock), end-to-end 'trace _ id', PII/PAN mascare.

8) Observabilitate, SLO și gestionarea incidentelor

OpenTelemetry SDK peste tot; Colector pe-prem și în nor.
Prelevarea de probe: 100% ошибок и p99, etichete „site = onprem 'cloud”, „regiune”, „chiriaș”.
SLO și bugete de eroare pe felii (traseu/chiriaș/furnizor/site); alerte de arde-rata.
Tablouri de bord end-to-end: RED/USE, hărți de dependență, comparații canare (înainte/după migrații).

9) CI/CD și configurații

Un singur registru de artefacte (pull-through cache on-prem).
Promo stream: dev → stage (on-prem) → canare (nor) → prod; sau invers - în funcție de obiectiv.
Verificări: teste de contract (OpenAPI/gRPC/CDC), analiză statică, conectare IaC, scanare imagine, porți SLO.

10) DR/BCP (plan de continuitate)

• cataloage/aterizări: RTO 5-15 min, RPO ≤ 5 min;
• plăți/portofele: RTO ≤ 5 min, RPO ≈ 0-1 min (cvorum/sincron în cadrul site-ului).
• Runbook: comutarea GSLB/greutăți, ridicarea standby-ului într-un grup, feature-steaguri „modul ușor”.
• GameDays: trimestrial - deconectarea site-ului/canalului, verificarea RTO/RPO real.

11) Cost și FinOps

Ieșirea dintre on-prem și nor este principala cheltuială „ascunsă”; cache și să păstreze drumeții la un nivel minim (SWR, margine).
Tagging: 'serviciu', 'env', 'site', 'chiriaş', 'cost _ center'.
Regula 80/20: transferăm/păstrăm portabil 20% din „nucleul critic”, restul - unde este mai ieftin.
Downsampling metrics, referințe de busteni „fierbinte/rece”, buget conștient de urmărirea eșantionării.

12) Modele de plasare a volumelor de lucru

13) Exemple de configurații

13. 1 S2S IPsec (idee)

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

13. 2 Terraform (etichetă/etichetă fragment)

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 (secret de la cluster on-prem la cloud)

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) Antipattern

intersectarea haosului CIDR → NAT; mai întâi planul de adrese, apoi canalele.
O memorie cache globală „partajată” cu o consistență puternică → latență și creier divizat.
Retrogradează fără idempotență → dublu write-off/comenzi.
VPN „gol” fără mTLS/Zero Trust în interior - mișcare laterală atunci când este compromisă.
Lipsa exercițiilor DR: planurile nu funcționează în realitate.
Discrepanța dintre versiunile K8s/CRD/operators → imposibilitatea diagramelor uniforme.
Jurnalele în format gratuit fără 'trace _ id' și mascarea sunt imposibile.

15) Specificul iGaming/Finanțe

Rezidenta date: PII/evenimente de plata - circuit on-prem/regional; în cloud - agregate/anonime.
PSP/KYC: multi-furnizori; rutare inteligentă de la cloud la gateway-uri locale, rezervă la backup; webhooks printr-un broker cu deduplicare.
„Căi bănești”: SLO-uri individuale peste total; Sunt necesare HMAC/mTLS, „Retry-After”, „Idempotency-Key”.
Audit: stocare WORM (Object Lock), jurnale de tranzacții imuabile, înregistrare bidirecțională (on-prem + cloud) pentru evenimente critice.
Jurisdicții: KMS/segmentare cheie Vault pe țară/marcă; geo-blocuri pe perimetru.

16) Lista de verificare Prod Readiness

• Planul de adrese, DNS, NTP - unul; link-uri S2S + link-uri protejate înainte (BGP).
• Identitate unică (SSO/OIDC/SAML), MFA, cel mai puțin privilegiu; SPIFFE/SPIRE pentru servicii.
• K8s în toate site-urile, GitOps, aceiași operatori/CRD; plasă de serviciu с mTLS и LB conștient de localitate.
• Date: CDC, teste de consistență, politici RPO/RTO, 3-2-1 de backup și unități regulate de restaurare.
• Securitate: Vault/ESO, Rotație, NetworkPolicies, ZTNA; jurnalele sunt imuabile.
• Observabilitate: OTel, coadă-eșantionare, SLO/bugete pe site/regiune/chiriaș; tablouri de bord canare.
• CI/CD: teste de contract, lame IaC, scanare imagine; release-gates de SLO.
• DR-runbooks, GameDays, măsurat efectiv RTO/RPO; butoane cutover/roll-back.
• FinOps: limite de ieșire, etichete și rapoarte, metrici/busteni/politica de păstrare a traseelor.
• Specificul iGaming: rezidență de date, multi-PSP, audit WORM, SLO-uri individuale pentru plăți.

17) TL; DR

Hibrid = platformă comună de execuție (K8s + GitOps + mesh + OTel + Vault) pe două lumi: on-prem și cloud. Planificați rețeaua și identitatea, faceți datele portabile prin CDC/idempotency, diferențiați securitatea în Zero Trust, măsurați fiabilitatea bugetelor SLO/Error și instruiți DR. pentru iGaming, păstrați datele și plățile în jurisdicție, utilizați multi-PSP smart-routing și auditing neschimbabil.