Salt la conținutul principal
FromNine
Meniu

Software și cloud

Fundații cloud care fac din lansări o rutină.

Construim fundații cloud și platforme interne pentru dezvoltatori în care mediile sunt definite în cod, lansările sunt semnate și repetabile, iar fiecare cheltuială are un responsabil.

Pentru organizații din România care rulează o singură fundație cloud pentru entități aflate sub supravegherea unor autorități diferite, în țară sau în mai multe state membre.

Solicitați o discuțieVedeți arhitectura de referință
Cloud și inginerie de platformă: straturile capabilitățiiPatru straturi suprapuse în adâncime. De sus în jos: aplicațiile echipelor de produs, platforma internă pentru dezvoltatori, pipeline-urile de livrare semnate și, la bază, landing zone-ul cu identitate, rețea și politici.01Aplicațiile echipelor de produs02Platformă internă pentru dezvoltatori03Pipeline-uri de livrare semnate04Landing zone și politici
  1. 01Landing zones cu politici definite în cod și locul datelor stabilit pentru fiecare aplicație
  2. 02Golden paths care duc un serviciu nou în producție într-un mod repetabil
  3. 03SLO-uri, recuperare testată și cost pe produs, vizibile pentru cei care decid

01 Probleme

Semne că fundația vă încetinește

  1. 01

    Fiecare mediu este altfel

    Testul și producția diferă în moduri pe care nu le-a notat nimeni, iar corecturile făcute manual în consolă se pierd la următoarea reconstrucție.

  2. 02

    O lansare cere o ședință

    Implementările sunt rare, manuale și programate seara. Echipele adună modificările în pachete mari, ceea ce face fiecare lansare mai riscantă.

  3. 03

    Factura de cloud surprinde pe toată lumea

    Costurile se văd pe abonament, nu pe produs. Capacitatea GPU pentru lucrul cu IA este rezervată de cine a cerut-o primul.

  4. 04

    Nimeni nu știe dacă recuperarea funcționează

    Există copii de rezervă. Restaurările nu au fost testate, iar timpul de recuperare și pierderea de date acceptabilă nu au fost niciodată convenite cu business-ul.

02 Ce livrăm

Ce livrăm

  1. 01 Landing zones și opțiuni de suveranitate

    Structura de conturi și abonamente, identitate, rețea și limite de siguranță la marii furnizori de cloud și în ofertele europene de cloud suveran, cu politici definite în cod și locul datelor stabilit pentru fiecare aplicație.

    Ce facem

    • Proiectarea organizației, a grupurilor de management și a conturilor
    • Rețea hub, controlul traficului de ieșire și conectivitate privată
    • Politici în cod pentru locul datelor, criptare și etichetare
    • Corespondența cu atestările și cerințele de securitate pe care le cer clienții dumneavoastră

    Ce primiți

    • Landing zone definit integral în cod
    • Bibliotecă de politici, cu proces pentru excepții
    • Analiza opțiunilor de suveranitate pentru fiecare clasă de aplicații

  2. 02 Infrastructură ca cod și platforme interne pentru dezvoltatori

    Terraform sau OpenTofu și Bicep pentru infrastructură, GitOps pentru implementări, Kubernetes sau medii de rulare administrate acolo unde se potrivesc și golden paths, astfel încât o echipă să poată porni un serviciu conform fără să deschidă tichete.

    Ce facem

    • Bibliotecă de module pentru infrastructura ca cod
    • GitOps cu promovare între medii
    • Platformă Kubernetes sau alternative administrate
    • Șabloane de servicii și un portal pentru dezvoltatori

    Ce primiți

    • Platformă internă pentru dezvoltatori, cu golden paths
    • Medii disponibile în regim self-service
    • Foaia de parcurs a platformei, gestionată de o echipă de platformă

  3. 03 Pipeline-uri de livrare și securitatea lanțului de aprovizionare

    Pipeline-uri care construiesc o singură dată, semnează artefactele, înregistrează proveniența conform SLSA, gestionează corect secretele și promovează același artefact din test în producție.

    Ce facem

    • Șabloane de pipeline cu praguri de calitate și de securitate
    • Semnarea artefactelor și atestarea provenienței
    • Gestionarea secretelor și rotația cheilor
    • Reguli de promovare și înregistrări ale modificărilor

    Ce primiți

    • Șabloane de pipeline reutilizabile
    • Artefacte semnate, cu proveniență verificabilă
    • Dovezi de lansare pentru gestionarea modificărilor

  4. 04 Observabilitate și SRE

    Obiective de nivel de serviciu convenite cu business-ul, bugete de erori care ghidează ritmul lansărilor, OpenTelemetry în toată arhitectura și un proces de incidente care servește și obligațiile de raportare din OUG nr. 155/2024 și DORA, acolo unde acestea se aplică.

    Ce facem

    • Definirea SLO-urilor împreună cu responsabilii serviciilor
    • Instrumentare OpenTelemetry și dashboarduri
    • Alerte pe simptome, nu pe cauze
    • Gestionarea incidentelor și analize după incident

    Ce primiți

    • Catalog de SLO-uri
    • Stivă de observabilitate și dashboarduri
    • Ghiduri operaționale pentru incidente și raportare

  5. 05 FinOps și capacitate pentru IA

    Alocarea costurilor pe produse și echipe, indicatori unitari precum costul pe tranzacție și planificarea capacității GPU și controlul costurilor pentru aplicațiile de IA.

    Ce facem

    • Politică de etichetare și model de alocare
    • Indicatori de cost unitar pentru fiecare produs
    • Planificarea angajamentelor și a rezervărilor
    • Programarea GPU, cote și dimensionare corectă

    Ce primiți

    • Dashboarduri de cost pentru fiecare product owner
    • Listă de economii, cu responsabili
    • Plan de capacitate pentru IA

  6. 06 Recuperare și ieșire

    Copii de rezervă și recuperare în caz de dezastru, cu obiective explicite pentru timpul de recuperare și pentru punctul de recuperare, testate periodic, și o strategie de ieșire care folosește drepturile de schimbare a furnizorului din Regulamentul privind datele.

    Ce facem

    • RTO și RPO convenite pentru fiecare serviciu
    • Teste de restaurare și de failover
    • Harta dependențelor pentru serviciile critice
    • Plan de ieșire și verificarea portabilității datelor

    Ce primiți

    • Proceduri de recuperare testate
    • Rapoarte ale testelor de recuperare
    • Strategie de ieșire documentată

03 Arhitectură

O arhitectură de referință ilustrativă

Codul intră în stânga, iar aplicațiile care rulează ies în dreapta. Între ele, pipeline-ul semnează ce construiește, registrul stochează doar artefacte semnate, iar un controller GitOps le promovează între medii, sub controlul politicilor.

Dedesubt se află landing zone-ul: structura organizației, identitate, rețea, chei, recuperare și controlul costurilor, definite o singură dată în cod și folosite în comun de toate echipele de produs.

Straturile din diagramă

Livrare
Depozite de cod, pipeline-uri, artefacte semnate și promovare GitOps.
Platformă
Platforma pentru dezvoltatori, politicile definite în cod și mediul de rulare în care implementează echipele de produs.
Landing zone
Organizație, identitate, rețea, chei, recuperare și controale FinOps.
Operare
Telemetrie, SLO-uri, bugete de erori și răspuns la incidente pentru întreaga platformă.
Exemplu ilustrativ

  1. Livrare

    • Depozite de cod și IaC
    • Build, semnare, atestare
    • Registru de artefacte semnate
    • Promovare GitOps

  2. Platformă

    • Platformă pentru dezvoltatori și golden paths
    • Politici în cod
    • Kubernetes și servicii administrate
    • Aplicațiile echipelor de produs

  3. Landing zone

    • Structura de management
    • Identitate și acces
    • Hub de rețea și trafic de ieșire
    • Chei și secrete
    • Copii de rezervă și recuperare
    • Alocarea costurilor

  4. Operare

    • OpenTelemetry, SLO-uri și bugete de erori, răspuns la incidente
Livrare semnată pe un landing zone guvernat de politici

Arhitectură ilustrativă, nu sistemul unui client.

Citiți diagrama ca text

Traseul principal pornește de la depozitele de cod și de infrastructură, trece prin pipeline-uri care construiesc, semnează și atestă, ajunge într-un registru de artefacte, apoi la un controller GitOps și, în final, la spațiile de lucru ale echipelor de produs.

O platformă internă pentru dezvoltatori oferă golden paths către pipeline-uri. Politicile definite în cod limitează controllerul GitOps. O platformă de rulare cu Kubernetes și servicii administrate găzduiește aplicațiile. Cheile gestionate de client alimentează stratul de politici.

Landing zone-ul de dedesubt conține structura de management, identitatea și accesul, un hub de rețea, cheile, copiile de rezervă și recuperarea și controalele FinOps. Observabilitatea, cu SLO-uri și răspuns la incidente, acoperă întreaga platformă.

04 Aspecte și limite

Aspecte de inginerie și limite

  • Suveranitatea are mai multe trepte

    Cum procedăm

    Clasificăm aplicațiile după sensibilitate și potrivim fiecare clasă cu o opțiune: regiunile din UE ale unui furnizor mare de cloud, o ofertă de cloud suveran sau infrastructură privată. Compromisurile privind funcționalitățile, costul și operarea sunt consemnate în scris.

    Limite și dependențe

    Ofertele suverane rămân adesea în urmă la serviciile administrate, inclusiv la cele de IA. Unele aplicații vor costa mai mult sau vor putea face mai puțin acolo, iar aceasta este o decizie de business.

  • O platformă are nevoie de un product owner

    Cum procedăm

    Tratăm platforma internă ca pe un produs, cu utilizatori, foaie de parcurs și bucle de feedback, și vă ajutăm să formați echipa care o operează.

    Limite și dependențe

    O platformă fără echipă devine un blocaj. Dacă nu o puteți dota cu oameni, vă vom recomanda servicii administrate și mai puține abstracțiuni.

  • Reglementarea modelează operarea

    Cum procedăm

    Clasificarea incidentelor, termenele de raportare și colectarea dovezilor sunt integrate în procesul de incidente acolo unde vi se aplică OUG nr. 155/2024 sau DORA.

    Limite și dependențe

    Stabilirea faptului că intrați sau nu în domeniul de aplicare și a modului în care se aplică legislația națională rămâne la echipele dumneavoastră de conformitate și juridice.

  • Controlul costurilor este o responsabili­tate comună

    Cum procedăm

    Facem costurile vizibile pe produs și adăugăm limite precum bugete, cote și oprirea programată a mediilor nefolosite.

    Limite și dependențe

    Cele mai mari economii vin de obicei din deciziile de arhitectură și de utilizare pe care le iau product ownerii, nu doar din platformă.

05 Cum lucrăm

Cum lucrăm

Întâi fundațiile, apoi o echipă pe golden path, apoi toate celelalte.

  1. 01

    Evaluăm și clasificăm

    Aplicațiile, sensibilitatea datelor, costurile actuale și controalele pe care le așteaptă auditorii dumneavoastră.

    RezultatClasificarea aplicațiilor și opțiunile-țintă

  2. 02

    Construim landing zone-ul

    Totul în cod, revizuit împreună cu echipa de securitate, cu un proces pentru excepții.

    RezultatLanding zone în producție

  3. 03

    Începem cu o echipă pilot

    O echipă de produs trece pe golden path; dificultățile pe care le întâmpină modelează platforma.

    RezultatPrimul serviciu pe platformă

  4. 04

    Extindem și predăm

    Se alătură mai multe echipe, echipa de platformă preia responsabilitatea, iar recuperarea este testată periodic.

    RezultatFoaia de parcurs a platformei și rapoartele testelor de recuperare

06 Control uman

Unde controlul rămâne la oameni

Automatizarea operează platforma. Oamenii răspund de deciziile care implică risc sau cost.

  • Modificările din producție sunt trasabile

    Fiecare modificare în producție provine dintr-un commit revizuit, așa că se știe mereu cine a schimbat ce și cine a aprobat.

  • Accesul de urgență este rar și înregistrat

    Accesul de urgență este limitat în timp, trebuie justificat și este revizuit ulterior.

  • Excepțiile de la politici au un responsabil

    Când o aplicație are nevoie de o excepție de la o regulă de siguranță, un responsabil de risc numit o aprobă, cu o dată de expirare.

  • Responsabilii serviciilor stabilesc țintele

    Obiectivele de recuperare și nivelurile de serviciu se convin cu responsabilul de business al fiecărui serviciu, nu sunt stabilite doar de echipa de platformă.

07 Tehnologii

Tehnologii cu care lucrăm

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Oferte europene de cloud suveran
Infrastructură și livrare
  • Terraform și OpenTofu
  • Bicep
  • Argo CD și Flux
  • GitHub Actions, GitLab CI și Azure DevOps
Rulare
  • Kubernetes și variantele administrate
  • Platforme serverless și de containere
  • Service mesh acolo unde se justifică
  • Noduri GPU pentru aplicațiile de IA
Operare
  • OpenTelemetry
  • Prometheus și Grafana
  • Monitorizare nativă în cloud
  • Motoare de politici precum OPA

Mențiunea unei tehnologii descrie experiența noastră de inginerie. Nu implică un parteneriat cu producătorul ei și nici o recomandare din partea acestuia.

08 Exemplu

Un exemplu ilustrativ

Exemplu ilustrativ

Un landing zone comun pentru o rețea privată de clinici aflată sub incidența OUG nr. 155/2024

01Situația
Rețeaua a crescut prin achiziții, iar fiecare clinică rulează aplicațiile în propriul tenant cloud, cu alte controale. Rețeaua trebuie să efectueze auditul de securitate cibernetică după regulile DNSC și să depună autoevaluarea anuală, dar nimeni nu poate arăta postura de securitate a întregii rețele într-o singură imagine.
02Ce am construi
Un singur landing zone definit în cod, cu seturi de politici pentru fiecare clinică, jurnalizare comună și un proces de incidente care clasifică evenimentele și pregătește raportarea către DNSC.
03Unde decid oamenii
Responsabilul de securitate al fiecărei clinici aprobă excepțiile de la politici pentru aplicațiile proprii; responsabilul de securitate al rețelei răspunde de configurația de bază comună.
04Ce am măsura
Timpul de la detectarea unui incident până la clasificarea lui, ponderea aplicațiilor aflate sub politici și testele de recuperare reușite în fiecare trimestru.

09 Pe sectoare

În sectorul dumneavoastră

  • Sector public și administrație

    Opțiuni de suveranitate pentru fiecare clasă de date, cerințele naționale de securitate și planuri de ieșire care rezistă la următoarea procedură de atribuire.

  • Servicii financiare

    Reziliență operațională conform DORA, sub supravegherea BNR sau a ASF: recuperare testată, supravegherea furnizorilor terți de servicii TIC și raportarea incidentelor integrate în operare.

România

Dovezi produse o singură dată, pentru fiecare autoritate

În România, Directiva NIS2 este transpusă prin OUG nr. 155/2024, în vigoare din 31 decembrie 2024 și aprobată, cu modificări, prin Legea nr. 124/2025. Entitățile esențiale și importante se înregistrează la Directoratul Național de Securitate Cibernetică (DNSC), efectuează un audit de securitate cibernetică după regulile DNSC și depun anual o autoevaluare a nivelului de maturitate a gestionării riscurilor, iar organele de conducere pot fi trase la răspundere.

Entitățile financiare au în plus DORA, pus în aplicare în România prin OUG nr. 14/2026: Banca Națională a României (BNR) este autoritate competentă pentru instituțiile de credit, instituțiile de plată și instituțiile emitente de monedă electronică, iar Autoritatea de Supraveghere Financiară (ASF) pentru societățile de servicii de investiții financiare, societățile de asigurare și reasigurare, intermediarii de asigurări și administratorii de fonduri de pensii ocupaționale. Un grup care activează în mai multe țări are nevoie de o singură platformă care să producă dovezile cerute de fiecare autoritate.

Proiectăm landing zones în care locul datelor, jurnalizarea și clasificarea incidentelor sunt politici, nu proiecte, astfel încât o entitate sau o țară nouă se adaugă prin configurare. Planurile de ieșire se bazează pe drepturile de schimbare a furnizorului din Regulamentul privind datele și sunt testate, nu doar scrise.

Întrebări despre cloud și ingineria de platformă

Ce furnizor de cloud recomandați?

Pe cel care se potrivește aplicațiilor, contractelor existente și cerințelor dumneavoastră de suveranitate. Lucrăm cu marii furnizori de cloud și cu ofertele europene de cloud suveran și documentăm compromisurile, astfel încât alegerea să poată fi susținută într-o procedură de achiziție și revizuită mai târziu.

Avem nevoie de Kubernetes?

Nu întotdeauna. Kubernetes se justifică atunci când rulați multe servicii și aveți o echipă care să opereze platforma. Pentru câteva servicii, platformele administrate de containere sau serverless sunt adesea mai simple și mai ieftin de operat.

Cum abordați securitatea?

Securitatea este integrată în landing zone și în pipeline-uri: identități cu privilegii minime, politici definite în cod, artefacte semnate și secrete care nu stau niciodată în cod. FromNine deține certificarea ISO/IEC 27001 pentru sistemul de management al securității informației.

Puteți reduce costurile noastre de cloud?

De obicei, da, dar nu promitem un procent înainte de a vedea datele. Începem prin a face costurile vizibile pe produs, apoi parcurgem o listă de economii împreună cu responsabilii care pot acționa.

Cum evităm dependența de un furnizor?

Alegând deliberat unde depindeți de serviciile specifice unui furnizor, păstrând infrastructura în cod și menținând un plan de ieșire documentat și testat. Regulamentul privind datele vă întărește dreptul de a schimba furnizorul; un plan de ieșire face acest drept utilizabil.

Arătați-ne următoarele trei lansări

Vă spunem ce le-ar transforma în rutină și cât ar costa construirea și operarea acestei fundații.

Solicitați o discuțieArhitectură și consultanță