Sari la conținutul principal
Începe un proiect
RawBotics Works · Engineering Intelligent Systems SISTEM COMPACT · 6 STRATURI

Capabilități / 06

Cloud & Software Architecture

Arhitectură construită pentru schimbare, scalare și operare reală.

Proiectăm structura tehnică care susține produsul în production — de la servicii și date până la deployment, observability, securitate și scalare.

Discută arhitectura Înapoi la Capabilități
L01 EXPERIENCE L02 APPLICATION L03 SERVICES L04 DATA L05 INFRASTRUCTURE L06 OBSERVABILITY
  1. L01Experienceinterfață
  2. L02Applicationlogică de produs
  3. L03Servicesgranițe
  4. L04Datasursa de adevăr
  5. L05Infrastructureexecuție
  6. L06Observabilityînvelește tot
FIG. 00 — Un sistem, șase straturi RAWBOTICS · CLOUD & SOFTWARE ARCHITECTURE
Derulează pentru a separa straturile

01  Arhitectură înainte de scalare

Scalarea nu începe când apar mai mulți utilizatori.

Începe în deciziile de arhitectură.

Momentul în care un sistem cedează sub trafic este rareori momentul în care problema a apărut. Problema a fost luată cu mult înainte — într-o dependență care nu trebuia să existe, într-o stare ținută acolo unde nu trebuia, într-un flux care presupune că nimic nu eșuează.

  • B—01Boundaries. Unde se termină o responsabilitate și începe alta. Fără granițe explicite, orice modificare atinge tot sistemul.
  • B—02Dependencies. Cine depinde de cine, în ce direcție și cât de strâns. Dependențele circulare se plătesc la fiecare release.
  • B—03Data access. Cine citește și cine scrie fiecare set de date. Accesul difuz face imposibilă evoluția schemei.
  • B—04State. Unde stă starea și cine o deține. Starea ascunsă în proces este primul obstacol la scalare orizontală.
  • B—05Concurrency. Ce se întâmplă când două operațiuni ating aceeași resursă în același timp.
  • B—06Failure modes. Ce cedează primul, ce se întâmplă imediat după și ce rămâne funcțional.
  • B—07Deployment model. Ce se livrează împreună și ce poate fi livrat separat. Modelul de deployment este o decizie de arhitectură, nu una de infrastructură.
FIG. 01 — Descompunere pe granițe SISTEM COMPACT → RESPONSABILITĂȚI EXPLICITE
SISTEM INTERFACE entrypoints LOGIC reguli de business STATE deținător unic EFFECTS I/O, servicii externe dependențe orientate GRANIȚE EXPLICITE · O SINGURĂ DIRECȚIE DE DEPENDENȚĂ
Monolitul nu este o greșeală Arhitectura nepotrivită contextului este

02  Software Architecture

Structura codului devine structura produsului în timp.

Un produs ajunge, după doi ani, exact atât de flexibil pe cât i-au permis granițele desenate la început. Arhitectura software nu este un document — este forma pe care o ia echipa, backlog-ul și viteza de livrare.

FIG. 02 — Secvența arhitecturală DOMAIN → MODULE → SERVICE → INTERFACE → SYSTEM
DOMAIN — limbajul și regulile business-ului MODULE A cohesive MODULE B cohesive MODULE C cohesive SERVICE SERVICE SERVICE INTERFACE — contracte explicite, versionate SYSTEM structura devine produsul
Microservices nu este răspunsul implicit Alegerea este contextuală
  • 01Module și domenii. Împărțim sistemul după limbajul business-ului, nu după straturile tehnice. Un modul răspunde de o capacitate, nu de un tip de fișier.
  • 02Servicii. Un serviciu apare când o parte a sistemului are alt ciclu de viață, alt profil de scalare sau alt proprietar — nu pentru că e la modă.
  • 03Interfețe și contracte. Ce expune o componentă este mai important decât cum e construită. Contractul se versionează, implementarea se schimbă.
  • 04Dependențe. Direcția dependențelor este o decizie, nu o consecință. Business logic-ul nu depinde de infrastructură.
  • 05Granițe de stare. Fiecare set de date are un singur proprietar. Restul sistemului îl citește printr-un contract.
  • 06Business logic. Regulile stau într-un loc testabil, independent de framework, de bază de date și de transport.
  • 07Mentenabilitate. Criteriul practic: cât de mult din sistem trebuie înțeles pentru a face o schimbare mică în siguranță.

03  Topologii

Nu există o singură arhitectură corectă. Există arhitectura potrivită contextului.

Aceleași componente pot fi organizate în patru feluri diferite. Fiecare variantă rezolvă o problemă și introduce alta. Alegerea se face din constrângeri reale: mărimea echipei, profilul de scalare, cerințele de consistență și cât de repede trebuie să livrezi.

FIG. 03 — Aceleași componente, patru topologii MODULAR MONOLITH
DEPLOYMENT UNIT — 1 MOD A MOD B MOD C MOD D DATA — schema partajată
Complexitate

Cea mai mică. Un singur runtime, un singur set de logs.

Deployment

Totul se livrează împreună. Simplu, dar cuplat.

Echipă

Funcționează bine pentru una–două echipe pe același cod.

Scalare

Se scalează întregul, nu partea care are nevoie.

SERVICE — CORE capacitate de business SERVICE — OPS SERVICE — EDGE contracte stabile între servicii DATA DATA DATA
Complexitate

Moderată. Puține granițe de rețea, dar reale.

Deployment

Independent per serviciu, dacă contractele rămân stabile.

Echipă

Se aliniază natural cu echipe pe capacități de business.

Consistență

Trebuie decisă explicit între servicii.

GATEWAY S1 S2 S3 S4 S5 S6 OBSERVABILITY — obligatorie, nu opțională
Complexitate

Cea mai mare. Rețeaua devine parte din logica sistemului.

Deployment

Complet independent, cu preț operațional pe măsură.

Scalare

Fiecare serviciu se scalează după propriul profil.

Observability

Fără tracing distribuit, sistemul devine opac.

PRODUCER A PRODUCER B PRODUCER C EVENT BUS — ordonare, retenție, replay CONSUMER CONSUMER PROJECTION
Cuplare

Minimă în timp de execuție. Maximă pe schema evenimentelor.

Consistență

Eventuală. Trebuie explicată în produs, nu doar în cod.

Scalare

Absoarbe vârfuri fără să propage presiunea în amonte.

Debugging

Necesită corelare între evenimente pentru a urmări un flux.

04  Environments

Production nu ar trebui să fie primul loc în care descoperim cum funcționează sistemul.

Environment-urile nu sunt copii ale aceluiași server. Sunt puncte de control: fiecare răspunde la o întrebare diferită înainte ca o schimbare să ajungă la utilizatori reali.

FIG. 04 — Traseul unei schimbări DEVELOPMENT → TEST → STAGING → PRODUCTION
DEVELOPMENT funcționează local? config izolată date sintetice TEST se comportă corect? suite automate contracte verificate STAGING seamănă cu production? paritate acolo unde contează secrets separate PRODUCTION utilizatori reali deployment controlat observability activă GATE GATE GATE O SINGURĂ SCHIMBARE, PATRU RĂSPUNSURI DIFERITE CONFIGURAȚIE ȘI SECRETS PER ENVIRONMENT · NICIODATĂ ÎN COD ÎNCREDEREA ÎN RELEASE SE CONSTRUIEȘTE ÎNAINTE DE DEPLOY
Paritate acolo unde schimbă rezultatul Nu clone identice cu orice preț
  • E—01Paritate selectivă. Staging nu trebuie să fie identic cu production. Trebuie să fie identic în lucrurile care pot invalida un test: versiuni, configurație, forma datelor, limite.
  • E—02Configurație externalizată. Același artefact rulează în toate environment-urile. Se schimbă doar configurația, nu build-ul.
  • E—03Secrets. Separate per environment, rotibile, niciodată în repository și niciodată în imagini.
  • E—04Testare. Unit, integrare, contract și end-to-end — fiecare răspunde la altceva. Nu se înlocuiesc reciproc.
  • E—05Deployment controlat. Progressive rollout, feature flags și posibilitatea de a opri o schimbare fără a opri sistemul.

05  CI/CD & Delivery

Livrarea trebuie să fie repetabilă, nu eroică.

Dacă un deployment cere o persoană anume, o seară anume și o secvență ținută minte, nu este un proces — este un risc programat. Pipeline-ul transformă livrarea într-o operațiune obișnuită, care poate fi repetată și, la nevoie, întoarsă.

FIG. 05 — Pipeline de livrare COMMIT → BUILD → TEST → VALIDATE → DEPLOY → OBSERVE
COMMIT sursa adevărului BUILD artefact imutabil TEST automat, blocant VALIDATE securitate, contracte DEPLOY progresiv OBSERVE semnalul de după release APROBARE UNDE E NECESAR ROLLBACK — o operațiune normală, nu o excepție FIECARE ETAPĂ PRODUCE UN ARTEFACT VERIFICABIL · NIMIC NU SE CONSTRUIEȘTE DE DOUĂ ORI
Release stages: canary · progresiv · complet Automatizare cu puncte de control umane
  • D—01Build reproductibil. Același commit produce același artefact. Artefactul se promovează între environment-uri, nu se reconstruiește.
  • D—02Test ca poartă. Suitele automate blochează pipeline-ul. Un test care nu poate bloca nimic nu protejează nimic.
  • D—03Validare. Dependențe, licențe, configurație, contracte de API și verificări de securitate — înainte de deployment, nu după.
  • D—04Deployment progresiv. Schimbarea ajunge la o parte din trafic, se observă, apoi se extinde.
  • D—05Rollback. Traseul de întoarcere se testează la fel de serios ca traseul de livrare.
  • D—06Aprobări. Acolo unde contextul o cere — reglementare, ferestre de mentenanță, sisteme critice — pipeline-ul se oprește și așteaptă o decizie explicită.

06  Cloud Infrastructure

Infrastructura trebuie să susțină produsul, nu să-l dicteze.

Componentele de infrastructură sunt aceleași aproape peste tot: compute, rețea, storage, baze de date, cozi, cache, secrets, load balancing, scaling. Diferența o face felul în care sunt compuse — și cât din produs rămâne independent de ele.

FIG. 06 — Compoziție de infrastructură COMPONENTE ABSTRACTE · FĂRĂ DEPENDENȚĂ DE FURNIZOR
NETWORK — segmentare, rute private, egress controlat EDGE TLS · cache static · WAF LOAD BALANCING health checks · distribuție AUTOSCALING politici pe semnal real SECRETS & CONFIG rotire · acces minim necesar COMPUTE — containere, runtime, workers SERVICE SERVICE SERVICE WORKER WORKER SCALE ↑ DATABASE tranzacțional sursa de adevăr CACHE citiri fierbinți invalidare explicită QUEUE decuplare în timp absorbție de vârf OBJECT STORAGE fișiere, artefacte acces semnat BACKUP + restore verificat DECIZIILE DE INFRASTRUCTURĂ RĂMÂN ÎN AFARA LOGICII DE BUSINESS
Componentele sunt abstracte intenționat Alegerea furnizorului este o decizie de proiect, nu o dependență de arhitectură

Folosim tehnologiile potrivite fiecărui proiect. Utilizarea unui furnizor de cloud sau a unui serviciu gestionat nu implică un parteneriat formal cu producătorul acestuia.

07  Scalabilitate

Scalarea înseamnă mai mult decât resurse suplimentare.

Un sistem care nu poate distribui munca nu devine mai rapid dacă primește mai multă infrastructură. Scalarea reală înseamnă a înțelege unde se strânge fluxul și a schimba forma sistemului, nu doar dimensiunea lui.

  • S—01Horizontal scaling. Mai multe instanțe identice în spatele unui load balancer. Funcționează doar dacă serviciul nu ține stare locală.
  • S—02Vertical scaling. Resurse mai mari pentru aceeași instanță. Rapid de aplicat, limitat ca orizont, uneori exact ce trebuie.
  • S—03Caching. Rezultatele scumpe se calculează o dată. Partea grea nu este cache-ul, ci invalidarea lui.
  • S—04Partitioning. Datele și traficul se împart după o cheie cu sens de business, ca să nu existe o partiție fierbinte.
  • S—05Queueing. Vârfurile intră într-o coadă, nu direct în baza de date. Sistemul încetinește elegant în loc să cedeze.
  • S—06Async workloads. Ce nu trebuie livrat sincron se scoate din calea utilizatorului.
  • S—07Stateless design. Acolo unde este posibil. Starea se mută explicit în componente proiectate pentru ea.
  • S—08Bottlenecks. Într-un sistem există aproape întotdeauna un singur punct care limitează totul. Se măsoară înainte de a fi optimizat.
FIG. 07 — Răspunsul la sarcină DISTRIBUIRE, NU DOAR AMPLIFICARE
SARCINĂ LOAD BALANCER INSTANCE INSTANCE INSTANCE SCALE ↑ CACHE citirile repetate nu ating baza de date QUEUE vârful devine lucru programat PARTITION 01 PARTITION 02 PARTITION 03
Comportamentul sub sarcină se proiectează Nu se promite

08  Performanță

Performanța este o proprietate a întregului sistem.

Utilizatorul nu simte performanța unei componente. Simte suma tuturor pașilor prin care trece o singură acțiune. De aceea optimizarea începe cu o urmărire completă a cererii, nu cu o presupunere despre unde este problema.

FIG. 08 — Unde se acumulează latența O CERERE, DE LA INTERFAȚĂ PÂNĂ LA STOCARE ȘI ÎNAPOI
TIMP RESIMȚIT DE UTILIZATOR → FRONTEND — randare, payload, blocare pe main thread NETWORK — distanță, TLS, dimensiunea răspunsului API — autentificare, validare, serializare SERVICE — lucru sincron care ar putea fi asincron DATABASE — query design, indexuri, volum returnat RĂSPUNS COMPLET ACUMULARE PRINCIPALĂ SEGMENTELE SUNT RELATIVE · MĂSURAREA SE FACE PE SISTEMUL REAL
Fără benchmark-uri generice Fiecare sistem își are propriul profil
  • P—01Frontend. Cât se descarcă, cât se execută, cât blochează interacțiunea. Adesea aici se câștigă primul salt vizibil.
  • P—02API response. Numărul de apeluri necesare pentru un singur ecran contează mai mult decât viteza fiecărui apel.
  • P—03Database access. Interogări scrise pentru volumul real, indexuri care corespund modelelor de acces, absența cererilor în buclă.
  • P—04Caching. Pe nivelul potrivit: edge, aplicație sau date — cu o regulă clară de invalidare.
  • P—05Payloads. Se transmite ce este folosit. Nu tot ce există în model.
  • P—06Background processing. Ce nu trebuie așteptat de utilizator iese din cererea sincronă.

09  Reziliență

Sistemele reziliente sunt proiectate presupunând că unele componente vor eșua.

Într-un sistem distribuit, eșecul nu este un eveniment excepțional — este o stare normală, cu o frecvență. Întrebarea nu este dacă o componentă cedează, ci ce face restul sistemului în minutul următor.

FIG. 09 — Izolarea unui eșec TIMEOUT → RETRY → CIRCUIT BREAKER → FALLBACK
REQUEST trafic normal SERVICE disponibil DEPENDENCY indisponibilă TIMEOUT limită fermă RETRY limitat, cu backoff CIRCUIT BREAKER se deschide, oprește presiunea FALLBACK rezultat degradat QUEUE reluare mai târziu SISTEM DISPONIBIL — funcționalitatea afectată este izolată, restul continuă GRACEFUL DEGRADATION · REDUNDANȚĂ PE COMPONENTELE CRITICE · RECUPERARE AUTOMATĂ LA REVENIRE
Nu promitem uptime absolut Proiectăm comportamentul din momentul în care ceva cedează

10  Observability

Dacă sistemul este complex, trebuie să poată explica ce i se întâmplă.

Monitorizarea îți spune că ceva nu este în regulă. Observability îți spune de ce. Diferența se vede în minutul cinci al unui incident, când trebuie să știi exact care componentă a schimbat comportamentul și de la ce deployment.

FIG. 10 — O cerere devine un trace distribuit SPANS · LOGS · METRICS · DEPLOYMENT EVENTS
TRACE ID — un identificator care leagă toți pașii EDGE GATEWAY SERVICE — orders SERVICE — pricing CACHE DATABASE SPAN CU LATENȚA CEA MAI MARE LOGS METRICS DEPLOY RELEASE — corelat cu schimbarea de comportament
Semnalul se proiectează odată cu sistemul Nu se adaugă după primul incident
  • O—01Logs. Structurate, corelate cu trace-ul, cu suficient context pentru a reconstitui o cerere fără a expune date sensibile.
  • O—02Metrics. Latență, throughput, rată de eroare și saturarea resurselor — pe componentă și pe flux de business.
  • O—03Traces. Un identificator care traversează toate serviciile și arată unde s-a consumat timpul.
  • O—04Errors. Grupate, deduplicate, cu versiunea și environment-ul atașate.
  • O—05Service health. Starea fiecărei componente și a dependențelor ei, nu doar a serverului pe care rulează.
  • O—06Deployment events. Fiecare release apare pe aceeași axă de timp cu metricile. Cele mai multe incidente încep cu o schimbare.

11  Securitate

Securitatea nu este un strat adăugat la final.

Cele mai multe decizii care contează pentru securitate sunt decizii de arhitectură: cine are identitate, cine are dreptul să ceară ceva, ce trece granița rețelei, unde stau secretele și ce rămâne scris în urmă.

FIG. 11 — Granițe, nu perimetru IDENTITATE → AUTORIZARE → SERVICIU → DATE
NETWORK BOUNDARY — acces privat implicit, expunere explicită IDENTITY — utilizatori, servicii, joburi AUTHORIZATION — cine are voie să ceară ce SERVICE BOUNDARY — validare la intrare DATA criptare în tranzit și la repaus acces minim necesar AUDIT — cine, ce, când, din ce context SECRETS VAULT
Fără certificări revendicate Fără garanții absolute de securitate
  • SEC—01Identitate. Nu doar utilizatorii au identitate. Serviciile și joburile de fundal au și ele — altfel nu poate exista autorizare reală între componente.
  • SEC—02Autorizare. Decizia se ia într-un singur loc, pe baza unui model explicit de roluri și resurse, nu împrăștiată prin controlere.
  • SEC—03Granițe de rețea. Implicit nimic nu este public. Expunerea este o decizie luată component cu component.
  • SEC—04Secrets. Stocate într-un seif, injectate la runtime, rotibile fără redeploy manual.
  • SEC—05Least privilege. Fiecare componentă primește exact drepturile de care are nevoie, pe durata în care are nevoie de ele.
  • SEC—06Criptare. În tranzit și la repaus, cu chei gestionate separat de aplicație.
  • SEC—07Validare. Datele care intră în sistem sunt verificate la granița serviciului, nu în adâncimea logicii.
  • SEC—08Auditabilitate. Acțiunile importante rămân înregistrate într-o formă care poate fi citită și verificată ulterior.

12  Date & Storage

Arhitectura aplicației și arhitectura datelor trebuie proiectate împreună.

Un model de date ales pentru primul ecran devine, în doi ani, limita produsului. Fiecare tip de acces are nevoie de un tip de stocare — dar există o singură sursă de adevăr, iar restul sunt derivate din ea.

FIG. 12 — Sursa de adevăr și derivatele ei TRANSACTIONAL · SEARCH · CACHE · FILES · EVENTS · ANALYTICS
SOURCE OF TRUTH stocare tranzacțională · consistență garantată SEARCH index derivat reconstruibil CACHE copie temporară invalidare explicită EVENT DATA istoric append-only replay posibil ANALYTICS model dimensional separat de operațional FILES & OBJECTS — documente, media, artefacte acces semnat · ciclu de viață definit BACKUP & RECOVERY un backup nerestaurat niciodată nu este un backup
Derivatele se pot reconstrui Sursa de adevăr, nu
Explorează Data & Intelligence

13  Queues & Async

Nu fiecare operațiune trebuie să se termine în aceeași secundă.

Cea mai simplă formă de scalare este să nu faci lucrul acum. O coadă separă momentul în care ceva este cerut de momentul în care este executat — și transformă un vârf de trafic într-o listă de lucru care poate fi procesată în ritm controlat.

  • Q—01Queues. Cererea este acceptată, confirmată și pusă la rând. Utilizatorul primește un răspuns imediat despre stare, nu despre rezultat.
  • Q—02Background jobs. Rapoarte, export, notificări, procesare de documente, sincronizări — tot ce nu trebuie să blocheze un ecran.
  • Q—03Retries. Cu backoff și cu o limită. Operațiunile sunt idempotente, altfel o reîncercare devine o a doua comandă.
  • Q—04Dead letters. Ce nu se poate procesa nu se pierde. Ajunge într-un loc vizibil, cu contextul eșecului.
  • Q—05Event-driven processing. O acțiune produce un eveniment, iar componentele interesate reacționează independent.
  • Q—06Load smoothing. Consumatorii lucrează la o rată stabilă. Baza de date vede o linie, nu un vârf.
FIG. 13 — Distribuirea lucrului ACCEPT → QUEUE → CONSUMERS → RESULT
REQUEST acceptat, nu executat ACK stare, nu rezultat QUEUE ordonare · retenție · vizibilitate CONSUMER rată stabilă CONSUMER rată stabilă CONSUMER + adăugat la nevoie RETRY backoff · idempotent DEAD LETTER vizibil, cu context
Sistemul încetinește În loc să cedeze
Explorează Automation & Orchestration

14  Granițe de integrare

Arhitectura bună controlează și modul în care sistemul se conectează în exterior.

Fiecare integrare este o dependență pe care nu o controlezi. Granița de integrare există ca sistemul tău să rămână al tău: formatele externe se traduc la intrare, iar indisponibilitatea unui furnizor nu devine indisponibilitatea produsului.

FIG. 14 — Granița dintre sistem și exterior GATEWAY · CONTRACTE · TRANSFORMARE · EVENIMENTE
CONSUMATOR — web / mobil SISTEM PARTENER ERP / CRM GATEWAY AUTENTIFICARE RATE LIMIT · QUOTA VALIDARE TRANSFORMARE format extern → model intern WEBHOOKS & EVENTS livrare cu confirmare reluare la eșec SISTEMUL PROPRIU DOMAIN MODEL SERVICES independent de formatele externe CONTRACTELE SE VERSIONEAZĂ · SCHIMBĂRILE EXTERNE NU AJUNG NEFILTRATE ÎN LOGICA DE BUSINESS
O integrare este o dependență Granița este ce o face suportabilă
Explorează Systems Integration

15  AI Infrastructure

AI adaugă un nou tip de workload în arhitectura produsului.

Un apel către un model nu se comportă ca un apel către o bază de date: durează mai mult, costă per utilizare, poate eșua parțial și returnează un rezultat care trebuie verificat. Din perspectiva arhitecturii, acesta este un tip de dependență nouă — cu propriile reguli de latență, cost, cache și observability.

FIG. 15 — Workload AI în sistem RETRIEVAL → MODEL → TOOLS → VERIFICARE
CERERE RETRIEVAL vector search · filtre de acces context din datele reale MODEL CALL latență variabilă · cost per apel timeout și fallback obligatorii TOOL EXECUTION acțiuni cu permisiuni explicite asupra sistemelor existente CACHE context și rezultate reutilizabile control direct asupra costului GUARDRAILS & VERIFICARE limite de acțiune · validare a rezultatului · escaladare către om unde contează OBSERVABILITY — latență, cost, rată de eșec, calitatea răspunsului
Aici tratăm doar partea de infrastructură Sistemele AI au pagina lor
  • AI—01Model calls. Dependență externă cu latență variabilă. Are nevoie de timeout, retry limitat și o cale alternativă când nu răspunde.
  • AI—02Retrieval. Contextul se construiește din datele organizației, cu aceleași reguli de acces ca restul sistemului.
  • AI—03Vector storage. Un tip nou de stocare, cu propriul ciclu de indexare, reindexare și invalidare.
  • AI—04Tool execution. Când modelul poate declanșa acțiuni, permisiunile devin parte din arhitectura de securitate.
  • AI—05Latență și cost. Două constrângeri noi care influențează direct designul fluxului — ce se face sincron și ce se face în fundal.
  • AI—06Caching. Pe context, pe rezultate și pe embeddings. Cea mai directă pârghie asupra costului.
  • AI—07Guardrails. Limite explicite de acțiune și verificare a rezultatului înainte de a intra în sistem.
Explorează AI Systems & Agents

16  Production readiness

Production-ready este o stare a sistemului, nu un buton de deploy.

Un sistem este pregătit pentru production când fiecare dimensiune de mai jos are un răspuns explicit — luat înainte, verificat în timpul livrării și urmărit după. Absența răspunsului nu înseamnă că riscul nu există; înseamnă că nu este al nimănui.

R—01

Deployment

decizieCe se livrează împreună, cu ce frecvență și prin ce mecanism progresiv.

operareFiecare release este identificabil și legat de un commit.

R—02

Rollback

decizieCum se întoarce o schimbare, inclusiv una care a atins schema de date.

operareTraseul de întoarcere este testat, nu presupus.

R—03

Monitoring

decizieCe semnale spun că sistemul își face treaba, în termeni de business.

operareAlerte care corespund unei acțiuni, nu zgomotului.

R—04

Errors

decizieCum se propagă, unde se opresc și ce vede utilizatorul.

operareGrupare, versiune, environment și context atașate.

R—05

Backup

decizieCe se salvează, cât de des și cât timp se păstrează.

operareSalvarea este verificată automat, nu doar programată.

R—06

Recovery

decizieCât timp și cât din date sunt acceptabile de pierdut, stabilit cu business-ul.

operareRestaurarea a fost exersată cel puțin o dată.

R—07

Security

decizieIdentitate, autorizare, granițe de rețea, secrets și criptare.

operareDependențele sunt urmărite și actualizate.

R—08

Scalability

decizieCe componentă se scalează prima și ce o limitează.

operareComportamentul sub sarcină este cunoscut, nu descoperit.

R—09

Configuration

decizieCe este configurabil, de către cine și cu ce efect.

operareConfigurația este versionată și trasabilă.

R—10

Auditability

decizieCe acțiuni trebuie să rămână înregistrate și pentru cât timp.

operareJurnalul poate fi citit de cineva din afara echipei tehnice.

R—11

Ownership

decizieCine răspunde de fiecare componentă după livrare.

operareExistă o cale clară de escaladare, cunoscută dinainte.

17  Evoluție

Arhitectura trebuie să poată evolua fără reconstrucție permanentă.

Rescrierea totală este cea mai scumpă formă de modernizare și cea mai riscantă. Alternativa este o arhitectură în care componentele pot fi înlocuite una câte una, în spatele unor contracte care rămân stabile.

FIG. 17 — Modernizare incrementală CONTRACT STABIL · IMPLEMENTARE ÎNLOCUITĂ
INTERFACE CONTRACT — stabil, versionat, compatibil înapoi IMPLEMENTARE V1 componentă existentă MODUL EXTRAS graniță nouă, comportament identic IMPLEMENTARE V2 rulează în paralel TRAFIC MIGRAT gradual, reversibil MIGRAȚII DE DATE COMPATIBILE ÎN AMBELE SENSURI PE DURATA TRANZIȚIEI DATORIA TEHNICĂ SE GESTIONEAZĂ CA BACKLOG, NU CA EVENIMENT
Componente înlocuibile Nu sisteme rescrise
Explorează Product Modernization

18  Transformare

Din infrastructură reactivă în sistem proiectat pentru production.

Transformarea nu se vede în interfață. Se vede în felul în care echipa livrează, în ce se întâmplă la ora trei dimineața și în cât durează să adaugi o funcționalitate care atinge trei componente.

FIG. 18 — Aceeași organizație, altă arhitectură STARE INIȚIALĂ
ÎNAINTE — dependențe implicite DUPĂ — granițe explicite OBSERVABILITY SERVICE SERVICE SERVICE INFRASTRUCTURĂ · LIVRARE REPETABILĂ · ROLLBACK TRANZIȚIE

Înainte

  • 01Deploy-uri manuale, făcute de o singură persoană
  • 02Dependențe ascunse, descoperite la prima schimbare
  • 03Environment-uri inconsistente între ele
  • 04Monitorizare limitată la „serverul este pornit"
  • 05Scalare fragilă, dependentă de o singură componentă
  • 06Căi de eșec necunoscute până în momentul eșecului
  • 07Componente strâns cuplate, imposibil de livrat separat

După

  • 01Arhitectură clară, cu responsabilități explicite
  • 02Environment-uri controlate, cu configurație separată
  • 03Livrare repetabilă, cu rollback testat
  • 04Observability pe cerere, pe serviciu și pe release
  • 05Reziliență proiectată: timeout, retry, fallback, degradare
  • 06Granițe definite între module, servicii și integrări
  • 07Infrastructură scalabilă, aliniată cu profilul real de sarcină

19  Momentul

Când Cloud & Software Architecture devine critică.

Rareori există un moment anunțat. Există opt semnale care apar, de obicei, cu câteva luni înainte ca problema să devină vizibilă în business.

W—01

Produsul crește și apar bottlenecks

Aceleași ecrane încep să răspundă mai încet, iar creșterea de resurse nu mai produce efectul de anul trecut.

W—02

Deployment-ul devine riscant

Livrările se amână, se grupează și se fac în afara programului. Frecvența scade exact când produsul are nevoie de ea.

W—03

Prea multe componente greu de schimbat

O modificare mică cere modificări în alte trei locuri, iar nimeni nu poate estima cu încredere.

W—04

Observability insuficientă

Incidentele se investighează prin reconstituire, nu prin citirea unui semnal. Cauza se află după ce s-a rezolvat.

W—05

Sistemul trebuie integrat cu mai multe servicii

Numărul de integrări crește, iar fiecare aduce cu sine un mod nou de a eșua.

W—06

Workload-urile asincrone cresc

Procesări, sincronizări și joburi de fundal devin o parte importantă din sistem, fără o structură care să le susțină.

W—07

AI introduce cerințe operaționale noi

Latență variabilă, cost per utilizare, stocare vectorială și verificarea rezultatelor — toate ating arhitectura.

W—08

Modernizarea trebuie făcută incremental

Sistemul nu poate fi oprit, dar nici lăsat așa. Este nevoie de o cale de evoluție care funcționează în paralel cu operarea.

20  Capabilități conectate

Arhitectura este fundația pe care celelalte capabilități pot evolua.

Nicio capabilitate nu lucrează singură. Arhitectura este cea care decide cât de departe pot merge celelalte — și cât de scump costă fiecare pas următor.

DIGITAL PRODUCT ENGINEERING AI SYSTEMS & AGENTS AUTOMATION & ORCHESTRATION SYSTEMS INTEGRATION DATA & INTELLIGENCE DIGITAL EXPERIENCES

CONEXIUNE

Șase capabilități pe aceeași fundație

Treci cu mouse-ul sau cu tastatura peste o capabilitate pentru a vedea ce anume depinde, concret, de deciziile de arhitectură.

C—01 Digital Product Engineering Produsul se sprijină pe granițele, contractele și modelul de deployment stabilite aici. C—02 AI Systems & Agents Workload-urile AI au nevoie de latență, cost, cache și observability tratate ca infrastructură. C—03 Automation & Orchestration Fluxurile automate rulează pe cozi, workers și reluări proiectate în arhitectură. C—04 Systems Integration Granițele de integrare, gateway-ul și contractele decid cât de mult te afectează un sistem extern. C—05 Data & Intelligence Sursa de adevăr, derivatele și separarea operațional/analitic sunt decizii de arhitectură. C—06 Digital Experiences Performanța resimțită de utilizator vine din payload, cache și structura API-urilor.

21  Soluții

De la arhitectură la capacitate de evoluție.

S—01

Enterprise Platforms

Platforme operaționale care trebuie să suporte utilizare zilnică, integrări multiple și creștere previzibilă.

 S—02

Product Modernization

Produse existente, mutate incremental pe o arhitectură care suportă anii următori.

 S—03

AI Transformation

AI integrat în infrastructura care există deja, cu cerințele operaționale tratate de la început.

22  Convergență

ONE PRODUCTION SYSTEM

Production system

Opt decizii care, luate separat, produc opt soluții parțiale. Luate împreună, produc un sistem care poate fi operat, scalat și schimbat fără să devină mai fragil.

Contact

Ai un produs care trebuie să crească fără să devină mai fragil?

Putem proiecta sau reconfigura arhitectura software și infrastructura care îi permit să evolueze controlat, de la development până în production.

Discută arhitectura Vezi proiectele