Aplicații cloud-native: microservicii, service mesh, tipare în apărare

Platformele de comandă și control din apărare au fost istoric monolitice — o singură unitate implementabilă care conținea managementul pistelor, retransmisiile de comunicații, coordonarea focului și integrarea informațiilor în spatele unei baze de date partajate. Monolitul nu a fost un accident: simplifica acreditarea, minimiza suprafața de atac a rețelei și corespundea modelului de personal al unei echipe mici care întreține un singur artefact. Dar fragilitatea pe care o creează este din ce în ce mai inacceptabilă. O actualizare a unei singure componente necesită o fereastră de mentenanță a întregii platforme. O creștere a volumului de piste ISR degradează interfața de foc. O schimbare a schemei bazei de date îngheață fire de dezvoltare fără legătură pentru săptămâni.

Arhitectura cloud-native abordează aceste moduri de eșec prin descompunerea platformei în servicii independente, fiecare cu propriul nivel de persistență, operate de Kubernetes și securizate cap-coadă de un service mesh. Aceasta nu este în primul rând o poveste de cost sau agilitate — este o poveste de reziliență și suveranitate operațională. Când un serviciu de fuziune a pistelor cedează într-o platformă C2 cloud-native, el cedează izolat. Interfața de coordonare a focului rămâne sus, retransmisiile de comunicații continuă să routeze mesajele, iar operatorii văd o Imagine Operațională Comună degradată — dar nu absentă — în timp ce serviciul eșuat se auto-vindecă. O izolare echivalentă nu este realizabilă într-un monolit fără o izolare deliberată în proces (bulkheading) care introduce practic aceeași complexitate.

Acest articol acoperă întreaga stivă de tipare cloud-native pentru sarcinile de lucru C2 și ISR din apărare: descompunerea domeniilor în contexte delimitate, implementarea unui service mesh pentru mTLS și observabilitate, tipare de operator Kubernetes pentru componente cu stare, fuziunea senzorilor orientată pe evenimente cu CQRS și event sourcing, practica SRE pentru servicii critice pentru misiune și degradarea controlată în condiții de rețea contestată.

De ce cloud-native pentru aplicațiile C2/ISR din apărare

Argumentul pentru cloud-native în apărare nu este același ca în software-ul comercial. Echipele comerciale adoptă microservicii pentru viteza de dezvoltare — echipe mai mici care dețin baze de cod mai mici, livrând mai repede și independent. Aceste beneficii există și în apărare, dar sunt secundare. Argumentul principal este reziliența: modurile de eșec ale monolitului sunt incompatibile cu cerințele misiunii.

Fragilitatea monolitului în medii contestate. O platformă C2 monolitică are un singur domeniu de eșec. Presiunea asupra memoriei în firul de ingestie a pistelor degradează interfața de foc. O tranzacție de bază de date blocată blochează rutarea mesajelor. O componentă cu scurgere de memorie necesită o repornire completă a platformei — scoțând simultan din funcțiune toate funcțiile. Aceste moduri de eșec sunt tolerabile atunci când sistemul operează într-un mediu de garnizoană controlat, cu ferestre planificate de mentenanță. Nu sunt tolerabile atunci când sistemul este instrumentul principal de conștientizare a situației pentru o unitate în contact, sau când acțiunea adversarului vizează deliberat stabilitatea sistemului.

Viteză independentă de implementare a actualizărilor de capabilități. Programele de apărare se confruntă cu un paradox: trebuie să actualizeze software-ul rapid (semnături noi de amenințare, logică ROE actualizată, vulnerabilități remediate), dar trebuie să minimizeze întreruperea operațională. Într-un monolit, fiecare modificare atinge același artefact implementabil, necesitând testare de regresie completă și o fereastră completă de mentenanță a platformei. Într-o arhitectură cloud-native, serviciul de fuziune a amenințărilor poate fi actualizat — validat, implementat și readus la starea anterioară dacă este necesar — fără a atinge interfața de foc sau releul de comunicații. Fiecare serviciu are un ritm independent de lansare, potrivit frecvenței sale de modificare și profilului de risc.

Scalabilitate orizontală pentru evenimente de vârf. Operațiile ISR generează volume de date foarte variabile. Un exercițiu la nivel de teatru poate genera de zece ori încărcarea normală de piste. Un monolit se scalează ca unitate — pentru a face față încărcării de vârf, fiecare componentă trebuie alocată la capacitate maximă, risipind resurse în operațiile normale. Într-o platformă cloud-native, serviciul de fuziune a pistelor se scalează orizontal sub sarcină, în timp ce interfața de foc și releul de comunicații își mențin numărul normal de replici. Kubernetes gestionează scalarea automat ca răspuns la CPU, memorie sau metrici personalizate derivate din adâncimea cozii din conducta de ingestie a senzorilor.

Cloud-native pentru apărare nu este sinonim cu cloud-ul public. Tiparul se aplică în mod egal infrastructurii clasificate la fața locului, mediilor de cloud suveran privat și clusterelor edge din avanpost, care rulează o distribuție Kubernetes minimală. Caracteristica definitorie este că serviciile sunt containerizate, gestionate declarativ și izolate unele de altele — nu unde este amplasată infrastructura.

Descompunerea în microservicii a aplicațiilor C2

Cea mai dificilă parte a adoptării cloud-native nu este tehnologia — ci deciderea unde se trasează granițele serviciilor. Granițe greșite creează microservicii puternic cuplate prin baze de date partajate sau lanțuri de apeluri sincrone atât de lungi încât un eșec oriunde se cascadează pretutindeni. Granițele corecte creează servicii care pot fi implementate, scalate și înlocuite independent, fără coordonare cu echipele adiacente.

Proiectarea contextelor delimitate pentru domeniile C2. Proiectarea orientată pe domenii oferă cadrul: identificați domeniile distincte din cadrul platformei C2 și trasați granițe în jurul lor pe baza proprietății datelor, a populațiilor de consumatori și a semanticilor de actualizare. O platformă C2 conține de obicei cel puțin cinci domenii distincte care se mapează clar pe contexte delimitate:

• Gestionarea pistelor — deține stocul autoritativ de piste, fuzionează rapoartele senzorilor, menține istoricul pistelor și deservește Imaginea Operațională Comună (COP). Frecvența de actualizare este mare (rapoartele senzorilor sosesc continuu); consumatorii includ practic fiecare alt serviciu.
• Releul de comunicații — gestionează rutarea mesajelor, topologia rețelei radio și alocarea canalelor. Decuplat de gestionarea pistelor: comunicațiile operează independent de starea de sănătate a fuziunii pistelor.
• Coordonarea focului — gestionează misiunile de foc, deconflictarea și urmărirea angajării țintelor. Consumă date despre piste, dar își deține propria stare; interfața de foc trebuie să rămână disponibilă chiar dacă fuziunea pistelor este temporar degradată.
• Integrarea informațiilor — ingerează produse de intelligence, le corelează cu piste și publică evaluări. Sarcini de analiză de lungă durată, cu cerințe de latență diferite de fuziunea pistelor în timp real.
• Starea logisticii — urmărește nivelurile de aprovizionare ale unității, disponibilitatea echipamentelor și cererile de susținere. Ritm de actualizare și bază de consumatori diferite de funcțiile C2 operaționale.

Contracte de interfață ale serviciilor. Fiecare context delimitat publică un contract de interfață — specificație OpenAPI pentru interfețe REST sau gRPC sincrone, schemă Avro sau Protobuf pentru interfețe de evenimente asincrone. Contractele sunt principalul mecanism de cuplare între servicii și trebuie versionate și tratate ca sensibile la modificări incompatibile. Un serviciu care își schimbă schema de evenimente fără să înregistreze noua versiune într-un registru de scheme poate corupe silențios consumatorii — un mod de eșec invizibil până când un consumator procesează un eveniment malformat și produce ieșiri incorecte.

Regula cardinală: serviciile își dețin datele. Serviciul de gestionare a pistelor deține stocul de piste. Serviciul de foc deține starea misiunilor de foc. Niciun serviciu nu citește direct baza de date a altui serviciu. Tot accesul la date între servicii trece prin interfața publicată. Aceasta este constrângerea care face reală implementarea independentă — fără ea, o modificare a schemei bazei de date în gestionarea pistelor rupe serviciul de foc, indiferent de independența lor nominală.

Pentru o tratare mai profundă a modului în care aceste servicii sunt întărite la nivel de infrastructură, consultați Întărirea Kubernetes pentru apărare pentru configurația de securitate a pod-urilor, politica de rețea și controlul admiterii care completează descompunerea serviciilor.

Service mesh: mTLS și observabilitate

Un service mesh inserează un proxy sidecar (Envoy în cazul Istio; un proxy Rust ușor în Linkerd) în fiecare pod, preluând tot traficul de rețea intrant și ieșant. Aplicația comunică cu localhost; sidecar-ul gestionează criptarea, autentificarea, reîncercările, întreruperea circuitului și colectarea telemetriei. Din perspectiva aplicației, rețeaua este abstractizată; din perspectiva operatorului, fiecare apel prin mesh este vizibil și controlat de politici.

mTLS pentru traficul est-vest în rețele C2 zero-trust. Arhitectura zero-trust cere ca niciun apel de rețea să nu fie de încredere pe baza locației în rețea — un serviciu din interiorul graniței clusterului trebuie să se autentifice la fel de riguros ca un serviciu din exteriorul său. Într-un service mesh configurat pentru mTLS strict, fiecare apel est-vest (serviciu către serviciu în interiorul clusterului) este autentificat cu certificate de workload emise de autoritatea de certificare a mesh-ului. Un serviciu care nu poate prezenta un certificat valid — fie pentru că este un workload neautorizat, o implementare greșit configurată sau un container compromis — este respins la proxy-ul sidecar înainte ca solicitarea să ajungă la aplicație.

În mediile clasificate, autoritatea de certificare a mesh-ului trebuie să se integreze cu PKI-ul intern al enclavei, nu cu o autoritate de certificare accesibilă din internet. Istio suportă backend-uri de CA interschimbabile — CA-ul Istio poate fi înlocuit cu o CA personalizată care emite certificate dintr-un lanț de încredere înrădăcinat în infrastructura PKI acreditată a programului. Rotația certificatelor trebuie automatizată: gestionarea manuală a certificatelor este operațional fragilă și a cauzat întreruperi în sisteme clasificate atunci când certificatele au expirat în timpul exercițiilor.

Istio versus Linkerd în medii clasificate. Istio oferă un set de funcții mai bogat — AuthorizationPolicy la nivel de metodă și cale HTTP, oglindirea traficului pentru analiza canary, cârlige de extensie Lua — dar cu prețul unei complexități mai mari și a unei amprente mai mari a planului de control. Linkerd are o suprafață de atac semnificativ mai mică și un model operațional mai simplu, ceea ce îl face atractiv pentru programele în care minimizarea bazei de calcul de încredere este o prioritate. Alegerea depinde de cerințele de funcții ale programului specific: dacă sunt necesare autorizare pe cale și oglindirea traficului, complexitatea Istio este justificată; dacă cerințele principale sunt mTLS și observabilitatea de bază, simplitatea Linkerd este preferabilă.

Trasare distribuită pentru analiza latenței. Într-o platformă C2 cu șapte sau mai multe servicii într-un lanț de apeluri, problemele de latență sunt aproape imposibil de diagnosticat fără trasare distribuită. O solicitare care durează 800 ms de la un capăt la altul poate fi petrecut 600 ms așteptând o interogare de bază de date în serviciul de gestionare a pistelor și doar 200 ms în tranzit și procesare în celelalte șase servicii. Fără trasare, singurul semnal disponibil este latența totală — contribuțiile individuale ale serviciilor sunt invizibile. Cu trasare, cascada este vizibilă în Jaeger sau Tempo: fiecare span al serviciului, durata sa și relația sa cu solicitarea globală sunt imediat evidente.

Service mesh-ul generează automat span-uri de trasare pentru fiecare apel pe care îl proxy-ează, fără a necesita instrumentare în codul aplicației. Span-urile la nivel de aplicație (interogări de bază de date, apeluri la API-uri externe în interiorul unui serviciu) necesită instrumentare explicită cu SDK-ul OpenTelemetry, dar scheletul dintre servicii este oferit gratuit de mesh. În mediile clasificate, backend-ul de trasare (Jaeger, Tempo sau Zipkin) trebuie să ruleze în interiorul graniței acreditate — datele de trasare conțin nume de servicii, căi de endpoint-uri și informații de timing care pot fi sensibile pentru un sistem C2 clasificat.

Tipare de operator Kubernetes pentru sarcini de lucru cu stare din apărare

Kubernetes gestionează bine sarcinile de lucru fără stare, din fabrică — dacă un pod eșuează, controlerul ReplicaSet creează un înlocuitor. Sarcinile de lucru cu stare necesită o gestionare mai sofisticată: ordinea în care replicile pornesc și se oprește contează, datele trebuie migrate între volumele de stocare în timpul upgrade-urilor, iar secvența de upgrade trebuie să păstreze garanțiile de consistență a datelor. Tiparul de operator codifică această cunoaștere operațională ca un controler care rulează în cluster.

Definiții de resurse personalizate pentru starea C2. Un operator este construit în jurul unei Definiții de Resursă Personalizată (CRD) care exprimă starea dorită a componentei gestionate în termeni semnificativi pentru domeniul aplicației. Pentru un stoc de piste C2, CRD-ul ar putea specifica numărul de replici, clasa de stocare, politica de retenție, factorul de replicare și numărul minim de replici sincronizate necesar înainte ca operatorul să permită un upgrade. Operatorii expun o interfață declarativă echipelor de infrastructură: acestea declară ce își doresc, iar operatorul determină cum să ajungă acolo. Cum-ul este codificat o singură dată în operator, nu re-derivat pentru fiecare implementare.

Bucla de reconciliere a operatorului pentru auto-vindecare. Bucla de reconciliere este nucleul unui operator: citește starea curentă a resursei gestionate, o compară cu starea dorită din CRD și ia setul minim de acțiuni necesar pentru a conduce convergența. Dacă o replică a stocului de piste este în CrashLoopBackOff, operatorul detectează divergența și inițiază recuperarea — declanșând potențial înlocuirea unei replicate, preluarea către o replică secundară sau o alertă care necesită intervenție umană, în funcție de calea de recuperare pe care operatorul a fost proiectat să o urmeze. Operatorul rulează continuu, astfel că recuperarea începe în câteva secunde de la detectarea eșecului, în loc să necesite ca un om să observe și să răspundă.

Upgrade continuu fără întreruperea misiunii. Upgrade-ul unei componente C2 cu stare într-un sistem viu, fără întreruperea misiunii, necesită o secvență specifică: verificați că ținta upgrade-ului este sănătoasă înainte de a începe, evacuați o replică pe rând, așteptați ca înlocuitorul să atingă o stare cunoscută ca sănătoasă înainte de a evacua următoarea și renunțați dacă verificările de sănătate eșuează în orice punct. Un operator Kubernetes codifică această secvență ca o mașină de stări în bucla de reconciliere. Operatorul impune numărul minim de replicate sănătoase la fiecare pas — nu va trece la pasul următor de upgrade dacă sistemul ar scădea sub minimul configurat. Acesta este avantajul critic față de upgrade-urile manuale: constrângerea este impusă de cod care rulează la viteza clusterului, nu de un om care urmează o listă de verificare sub presiune operațională.

Conducta CI/CD pentru medii izolate din apărare care construiește și semnează imaginile operatorului este la fel de importantă ca operatorul însuși — un operator implementat dintr-o imagine nesemnată, neverificată este un risc de lanț de aprovizionare într-un mediu clasificat.

Arhitectură orientată pe evenimente pentru fuziunea senzorilor

Fuziunea senzorilor — integrarea rapoartelor din mai multe tipuri de senzori într-o imagine coerentă a mediului operațional — este una dintre cele mai solicitante sarcini de lucru dintr-o platformă C2. Este în mod inerent orientată pe evenimente: rapoartele senzorilor sosesc asincron, la rate variabile, din mai multe surse simultan. Arhitectura sincronă de tip solicitare-răspuns este structural nepotrivită pentru această sarcină de lucru. O arhitectură orientată pe evenimente, cu un jurnal durabil ca coloană vertebrală, este potrivirea corectă.

Fluxuri de evenimente bazate pe Kafka pentru datele de la senzori. Apache Kafka (sau Apache Pulsar pentru capacitățile sale de multi-tenancy și stocare ierarhizată) oferă jurnalul durabil, partiționat, care susține conducta de fuziune a senzorilor. Fiecare tip de senzor publică în propriul subiect — rapoartele radar într-un subiect, informațiile electronice în altul, indiciile de imagistică într-al treilea. Serviciul de fuziune a pistelor se abonează la toate subiectele relevante și procesează rapoartele pe măsură ce sosesc. Mecanismul de grupuri de consumatori Kafka permite scalarea orizontală a serviciului de fuziune: fiecare replică preia o partiție, astfel încât debitul se scalează cu numărul de replici. Jurnalul durabil Kafka înseamnă că, dacă serviciul de fuziune este temporar indisponibil — în timpul unui upgrade sau al unei defecțiuni de nod — rapoartele se acumulează în jurnal și sunt procesate în ordine când serviciul își revine, fără pierderi.

Tiparul CQRS pentru gestionarea stării pistelor. Tiparul Command Query Responsibility Segregation separă calea de scriere (comenzile care modifică starea) de calea de citire (interogările care returnează starea). În serviciul de gestionare a pistelor, calea de scriere procesează rapoartele de senzori sosite și comenzile operatorilor, actualizând stocul autoritativ de piste și adăugând evenimente în jurnalul de evenimente. Calea de citire deservește Imaginea Operațională Comună și interfețele analiștilor dintr-o proiecție optimizată pentru citire — o vedere materializată a stării pistelor, optimizată pentru tiparele de acces ale consumatorilor COP, care diferă de tiparele de scriere ale fuziunii senzorilor.

CQRS permite scalarea căii de citire independent de calea de scriere. În timpul unui eveniment de vârf, când volumul rapoartelor de senzori este mare, calea de scriere se scalează pentru a gestiona ingestia, în timp ce calea de citire menține o latență stabilă a COP pentru operatori. Calea de citire poate, de asemenea, servi proiecții diferite către consumatori diferiți, fără a adăuga complexitate căii de scriere — consumatorul COP primește o vedere filtrată, cu cele mai recente prime; instrumentul analistului primește o vedere cu fereastră de timp și istoric complet.

Event sourcing pentru jurnalul de audit. Event sourcing extinde tiparul orientat pe evenimente la persistență: în loc să stocheze starea curentă a unei înregistrări de pistă și să o suprascrie la fiecare actualizare, sistemul stochează secvența de evenimente care a produs starea curentă. Îregistrarea autoritativă a pistei este derivată prin redarea jurnalului de evenimente. Această abordare produce mai multe proprietăți valoroase în contextele de acreditare din apărare: istoricul complet al fiecărei tranziții de stare este păstrat și imuabil; starea sistemului la orice moment din trecut poate fi reconstruită prin redarea evenimentelor până în acel punct; iar jurnalul de audit cerut de standardele de acreditare este o ieșire directă a arhitecturii, nu un jurnal întreținut separat.

SRE pentru servicii de apărare critice pentru misiune

Practicile de Inginerie a Fiabilității Site-ului — SLO-uri, bugete de erori, management structurat al incidentelor — se aplică platformelor C2 din apărare, dar implementarea trebuie adaptată la mediul operațional clasificat, la constrângerile de tempo operațional și la modelul de consecințe ale aplicațiilor implicate.

Definirea SLO și SLI pentru serviciile C2. SLO-urile comerciale sunt de obicei formulate ca metrici de experiență a utilizatorului. SLO-urile C2 trebuie formulate ca metrici de efect operațional, definite în colaborare cu operatori și planificatori de misiune care înțeleg ce comportamente ale sistemului afectează cu adevărat rezultatele misiunii. SLO-uri reprezentative pentru o platformă C2:

• Latența actualizării pistei: vârsta pistelor pe COP, la percentila 95, nu trebuie să depășească 15 secunde. Măsurată ca diferența dintre marcajul de timp al raportului de senzor și momentul în care actualizarea pistei este vizibilă pe COP.
• Rata de livrare a mesajelor: mesajele de comandă trebuie livrate cu mai puțin de 1% pierdere pe orice fereastră de 30 de minute. Măsurată ca raportul dintre livrările confirmate și mesajele trimise la granița serviciului de releu.
• Disponibilitatea interfeței de foc: interfața de coordonare a focului trebuie să fie disponibilă 99,9% din ferestrele ponderate în timp, în perioadele operaționale declarate. Măsurată prin sonde sintetice, nu prin rata de succes pasivă a solicitărilor.
• Latența ingestiei senzorilor: rapoartele de senzori trebuie ingerate și angajate în jurnalul de evenimente în maximum 5 secunde de la primire, la percentila 99. Măsurată de la marcajul de timp de primire în rețea la gateway-ul de ingestie până la marcajul de timp al angajării offset-ului Kafka.

Măsurarea SLI ar trebui să folosească telemetria service mesh-ului ori de câte ori este posibil — metricile de nivel mesh sunt independente de codul aplicației și nu pot fi umflate de erori la nivel de aplicație care sub-numără erorile. Acolo unde metricile mesh sunt insuficiente (de exemplu, măsurarea învechirii necesită marcaje de timp la nivel de aplicație, indisponibile la nivelul proxy-ului), instrumentați aplicația cu OpenTelemetry și exportați către un backend compatibil Prometheus din interiorul enclavei.

Politica bugetului de erori. Bugetul de erori este complementul SLO: dacă SLO-ul de prospețime a pistelor este 99,5% conformitate pe 30 de zile, bugetul de erori este 0,5% — aproximativ 2 ore și 10 minute de ferestre neconforme pe lună. Când bugetul este sănătos, echipele de inginerie pot implementa modificări și accepta risc calculat. Când bugetul se apropie de epuizare, politica se schimbă către stabilitate: nicio implementare non-urgență, resurse de inginerie redirecționate către îmbunătățirea fiabilității și o revizuire obligatorie după epuizarea bugetului. Programele de apărare trebuie să suprapună ferestrele operaționale peste politica bugetului de erori: unele perioade sunt declarate operaționale, iar consumul bugetului în acele perioade poartă un cost ridicat, indiferent de soldul cumulat.

Runbook-uri de gardă. Runbook-urile pentru sistemele C2 clasificate trebuie să îndeplinească un standard mai ridicat decât runbook-urile comerciale. Trebuie să fie executabile de personalul de gardă, care poate să nu fie arhitecții originali ai serviciului, la orice oră, sub presiune operațională, folosind doar instrumentele disponibile în interiorul graniței acreditate. Fiecare runbook ar trebui să includă: maparea simptom-diagnostic (ce alerte corespund căror moduri de eșec), comenzile exacte de executat (cu ieșirea așteptată pentru cazul sănătos și ieșirea de eroare pentru cazurile de eșec comune), contacte de escaladare cu nivelurile de acces notate și timpii de recuperare așteptați pentru fiecare procedură.

Degradare controlată în condiții contestate

Mediile contestate impun condiții de eșec care nu apar în garnizoană: bruiaj deliberat al legăturilor de comunicații, negarea GPS care afectează sincronizarea în timp, deteriorarea fizică a infrastructurii de rețea și sarcina indusă de adversar prin rapoarte de senzori falsificate. O platformă C2 cloud-native trebuie să degradeze controlat în toate aceste condiții — menținând capabilitățile de cea mai mare prioritate cât mai mult timp posibil, cu un comportament definit și testat la fiecare nivel de degradare.

Circuit breakere pentru conectivitate degradată. Circuit breakerele împiedică o dependință lentă sau eșuată să cascadeze eșecul prin lanțul de apeluri. În mesh-ul Istio, circuit breakerele sunt configurate prin resursa OutlierDetection pe o DestinationRule: specificați pragul de erori consecutive care declanșează circuitul, intervalul de ejecție și timpul de ejecție de bază. Când rata de erori a unui serviciu depășește pragul, mesh-ul oprește rutarea apelurilor către acesta și returnează erori imediat, în loc să colecteze apeluri care vor expira. Aceasta protejează bugetul de latență al apelantului — serviciul de foc nu așteaptă 30 de secunde ca o interogare de pistă să expire, primește o eroare imediată și revine la starea din cache.

Tipare de revenire la citirea din cache. Când un serviciu din amonte este indisponibil, serviciile care deservesc sarcini de lucru cu multă citire pot reveni la un cache local sau distribuit care conține ultima stare cunoscută ca bună. Revenirea la cache este acceptabilă doar când învechirea datelor este limitată și comunicată operatorilor — un COP care servește silențios piste de acum 10 minute fără a indica vârsta lor este mai rău decât un COP care marchează explicit piste ca învechite. Implementați revenirea cu un antet de răspuns sau un câmp de payload explicit care indică vârsta și sursa datelor (live versus cache), astfel încât interfețele operatorilor să poată evidenția starea de degradare, nu să o mascheze.

Degradare progresivă a serviciului, capabilă offline. Izolarea completă — fără conectivitate la niciun serviciu din amonte — necesită date pre-poziționate și logică de aplicație capabilă offline. Proiectați o matrice de degradare pentru platformă, care specifică ce capabilități operează în fiecare stare de conectivitate: complet conectat (toate serviciile accesibile), parțial conectat (unele servicii accesibile, altele nu) și complet izolat (fără conectivitate externă). Fiecare capabilitate din matrice trebuie să aibă o implementare testată a comportamentului său degradat — nu o notă într-un document de proiectare, ci o cale de cod testată, care a fost exercitată în testarea prin injectare de defecte înainte de implementarea operațională.

Cazul parțial conectat este cel mai dificil de proiectat, deoarece setul de servicii disponibile este imprevizibil — stocul de piste poate fi accesibil, dar serviciul de integrare a informațiilor poate să nu fie, sau invers. Serviciile trebuie proiectate să opereze cu orice subset de dependențe disponibil, degradând lin pe măsură ce dependențele individuale eșuează, în loc să necesite conectivitate totul-sau-nimic. Aceasta necesită clasificarea explicită a dependențelor la nivel de serviciu: obligatorie (serviciul nu poate funcționa fără ea), preferată (serviciul funcționează mai bine cu ea, dar poate degrada controlat fără ea) și opțională (serviciul ignoră complet indisponibilitatea ei).

Pentru fundamentele de securitate a containerelor care susțin întreaga această arhitectură — semnarea imaginilor, verificarea vulnerabilităților și aplicarea politicii la timp de execuție — consultați securitatea imaginilor de container pentru apărare. O arhitectură cloud-native este la fel de sigură ca imaginile care rulează în ea; descompunerea în microservicii înmulțește suprafața de atac a containerelor dacă imaginile nu sunt întărite și verificate continuu.

Arhitectura cloud-native pentru platformele C2 și ISR din apărare este o investiție semnificativă de inginerie: analiza contextelor delimitate, implementarea și operarea service mesh-ului, dezvoltarea de operatori, proiectarea conductelor orientate pe evenimente, definirea SLO-urilor cu factorii interesați operaționali și testarea degradării controlate toate necesită efort de inginerie deliberat, pe care o platformă monolitică nu îl cere. Returnarea acestei investiții este o platformă în care eșecul este local, actualizările sunt independente, scara este elastică, iar degradarea este proiectată, nu accidentală — proprietăți care devin negociabile pentru software-ul de apărare care operează în medii contestate.