Aneu al contingut principal
FromNine
Menú

Programari i núvol

Bases al núvol que fan rutinàries les publicacions.

Construïm bases al núvol i plataformes internes per a desenvolupadors en què els entorns són codi, les publicacions estan signades i són repetibles, i cada euro de despesa té una persona responsable.

Per a organitzacions que fan servir una sola base al núvol per a entitats de diversos estats membres, cadascuna amb el seu regulador.

Parlem del vostre projecteVegeu l’arquitectura de referència
Núvol i enginyeria de plataformes: capes de capacitatsQuatre capes apilades en profunditat. De dalt a baix: les càrregues de treball dels equips de producte, la plataforma interna per a desenvolupadors, les cadenes de lliurament signades i, a la base, la landing zone amb identitat, xarxa i polítiques.01Càrregues dels equips de producte02Plataforma interna per a desenvolupadors03Cadenes de lliurament signades04Landing zone i polítiques
  1. 01Landing zones amb polítiques com a codi i residència de les dades fixada per a cada càrrega de treball
  2. 02Camins estàndard que porten un servei nou a producció de manera repetible
  3. 03SLO, recuperació provada i cost per producte, visibles per a qui decideix

01 Problemes

Senyals que la base us frena

  1. 01

    Cada entorn és un cas únic

    Prova i producció difereixen en coses que ningú no ha escrit, i les correccions fetes a mà a la consola es perden a la reconstrucció següent.

  2. 02

    Una publicació necessita una reunió

    Els desplegaments són escassos, manuals i programats al vespre. Els equips acumulen canvis, i això fa cada publicació més arriscada.

  3. 03

    La factura del núvol sorprèn tothom

    Els costos es veuen per subscripció, no per producte. La capacitat de GPU per a la IA la reserva qui la demana primer.

  4. 04

    Ningú no sap si la recuperació funciona

    Hi ha còpies de seguretat. Les restauracions no s’han provat, i els objectius de temps de recuperació i de pèrdua de dades no s’han acordat mai amb el negoci.

02 Què lliurem

Què lliurem

  1. 01 Landing zones i opcions de sobirania

    Estructura de comptes i subscripcions, identitat, xarxa i salvaguardes en els grans proveïdors de núvol i en ofertes de núvol sobirà de la UE, amb polítiques com a codi i residència de les dades per a cada càrrega de treball.

    Què fem

    • Disseny de l’organització, dels grups de gestió i dels comptes
    • Xarxa central, control del trànsit de sortida i connectivitat privada
    • Polítiques com a codi per a residència, xifratge i etiquetatge
    • Correspondència dels controls amb el que demanen els vostres clients, com la conformitat amb l’Esquema Nacional de Seguretat (ENS) que exigeixen els plecs del sector públic

    Què rebeu

    • Landing zone definida íntegrament com a codi
    • Biblioteca de polítiques amb procés d’excepcions
    • Document d’opcions de sobirania per a cada classe de càrrega

  2. 02 Infraestructura com a codi i plataformes internes per a desenvolupadors

    Terraform o OpenTofu i Bicep per a la infraestructura, GitOps per als desplegaments, Kubernetes o entorns d’execució gestionats on encaixen, i camins estàndard perquè un equip pugui crear un servei conforme a les normes internes sense obrir tiquets.

    Què fem

    • Biblioteca de mòduls d’infraestructura com a codi
    • GitOps amb promoció entre entorns
    • Plataforma Kubernetes o alternatives gestionades
    • Plantilles de servei i un portal per a desenvolupadors

    Què rebeu

    • Plataforma interna per a desenvolupadors amb camins estàndard
    • Entorns en autoservei
    • Full de ruta de la plataforma a càrrec d’un equip de plataforma

  3. 03 Cadenes de lliurament i seguretat de la cadena de subministrament

    Cadenes que compilen una sola vegada, signen els artefactes, registren la procedència d’acord amb SLSA, gestionen bé els secrets i promouen el mateix artefacte de prova a producció.

    Què fem

    • Plantilles de cadena amb controls de qualitat i de seguretat
    • Signatura d’artefactes i certificació de la procedència
    • Gestió de secrets i rotació de claus
    • Regles de promoció i registres de canvis

    Què rebeu

    • Plantilles de cadena reutilitzables
    • Artefactes signats amb procedència verificable
    • Evidència de publicació per a la gestió de canvis

  4. 04 Observabilitat i SRE

    Objectius de nivell de servei acordats amb el negoci, pressupostos d’error que marquen el ritme de publicació, OpenTelemetry a tota la pila i un procés d’incidents que també serveix per a les obligacions de notificació de la Directiva NIS2 i de DORA quan s’apliquen.

    Què fem

    • Definició dels SLO amb les persones responsables dels serveis
    • Instrumentació amb OpenTelemetry i quadres de comandament
    • Alertes sobre símptomes, no sobre causes
    • Gestió d’incidents i revisions posteriors

    Què rebeu

    • Catàleg de SLO
    • Pila d’observabilitat i quadres de comandament
    • Procediments d’incidents i de notificació

  5. 05 FinOps i capacitat per a la IA

    Assignació de costos per producte i equip, economia unitària com el cost per transacció, i planificació de la capacitat de GPU i control del cost de les càrregues d’IA.

    Què fem

    • Política d’etiquetatge i model d’assignació
    • Mètriques de cost unitari per producte
    • Planificació de compromisos i reserves
    • Planificació de GPU, quotes i dimensionament ajustat

    Què rebeu

    • Quadres de comandament de costos per persona responsable de producte
    • Llista d’estalvis amb responsables
    • Pla de capacitat per a la IA

  6. 06 Recuperació i sortida

    Còpies de seguretat i recuperació davant desastres amb objectius explícits de temps i de punt de recuperació, provades periòdicament, i una estratègia de sortida que aprofita els drets de canvi de proveïdor del Reglament de dades de la UE.

    Què fem

    • RTO i RPO acordats per a cada servei
    • Proves de restauració i de commutació
    • Mapa de dependències dels serveis crítics
    • Pla de sortida i comprovacions de portabilitat de les dades

    Què rebeu

    • Procediments de recuperació provats
    • Informes de les proves de recuperació
    • Estratègia de sortida documentada

03 Arquitectura

Una arquitectura de referència il·lustrativa

El codi entra per l’esquerra i les càrregues de treball en funcionament surten per la dreta. Entremig, la cadena signa el que compila, el registre només desa artefactes signats i un controlador GitOps els promou d’un entorn a l’altre sota polítiques.

A sota hi ha la landing zone: estructura organitzativa, identitat, xarxa, claus, recuperació i control de costos, definits una sola vegada com a codi i compartits per tots els equips de producte.

Capes del dibuix

Lliurament
Repositoris, cadenes, artefactes signats i promoció amb GitOps.
Plataforma
La plataforma per a desenvolupadors, les polítiques com a codi i l’entorn d’execució on despleguen els equips de producte.
Landing zone
Organització, identitat, xarxa, claus, recuperació i controls de FinOps.
Operació
Telemetria, SLO, pressupostos d’error i resposta a incidents per a tot el conjunt.
Exemple il·lustratiu

  1. Lliurament

    • Repositoris de codi i d’IaC
    • Compilar, signar, certificar
    • Registre d’artefactes signats
    • Promoció amb GitOps

  2. Plataforma

    • Plataforma i camins estàndard
    • Polítiques com a codi
    • Kubernetes i serveis gestionats
    • Càrregues dels equips de producte

  3. Landing zone

    • Estructura de gestió
    • Identitat i accés
    • Xarxa central i sortida
    • Claus i secrets
    • Còpies i recuperació
    • Assignació de costos

  4. Operació

    • OpenTelemetry, SLO i pressupostos d’error, resposta a incidents
Lliurament signat sobre una landing zone governada per polítiques

Arquitectura il·lustrativa, no el sistema d’un client.

Llegiu el diagrama en format de text

El recorregut principal va dels repositoris de codi i d’infraestructura a les cadenes que compilen, signen i certifiquen, cap a un registre d’artefactes, després a un controlador GitOps i, finalment, als espais de càrrega dels equips de producte.

Una plataforma interna per a desenvolupadors ofereix camins estàndard cap a les cadenes. Les polítiques com a codi limiten el controlador GitOps. Una plataforma d’execució amb Kubernetes i serveis gestionats allotja les càrregues de treball. Les claus gestionades pel client alimenten la capa de polítiques.

La landing zone de sota conté l’estructura de gestió, la identitat i l’accés, una xarxa central, les claus, les còpies de seguretat i la recuperació, i els controls de FinOps. L’observabilitat amb SLO i la resposta a incidents cobreixen tota la plataforma.

04 Consideracions i límits

Consideracions d’enginyeria i límits

  • La sobirania és una gradació

    Com ho abordem

    Classifiquem les càrregues de treball per sensibilitat i assignem a cada classe una opció: regions de la UE d’un gran proveïdor de núvol, una oferta de núvol sobirà o infraestructura privada. Els compromisos en funcionalitats, cost i operació queden per escrit.

    Límits i dependències

    Les ofertes sobiranes sovint van endarrerides en serveis gestionats, també en serveis d’IA. Algunes càrregues hi costaran més o hi faran menys coses, i això és una decisió de negoci.

  • Una plataforma necessita una persona responsable de producte

    Com ho abordem

    Tractem la plataforma interna com un producte amb persones usuàries, full de ruta i cicles de retroacció, i us ajudem a formar l’equip que la gestiona.

    Límits i dependències

    Una plataforma sense equip es converteix en un coll d’ampolla. Si no hi podeu dedicar persones, us recomanarem serveis gestionats i menys abstraccions.

  • La normativa condiciona l’operació

    Com ho abordem

    La classificació d’incidents, els terminis de notificació i la recollida d’evidència s’integren al procés d’incidents quan us afecten la Directiva NIS2, DORA o l’ENS.

    Límits i dependències

    Determinar si entreu en l’àmbit d’aplicació, i com hi afecta la normativa espanyola, correspon als vostres equips de compliment normatiu i jurídic.

  • El control del cost és compartit

    Com ho abordem

    Fem visible el cost per producte i hi afegim salvaguardes com pressupostos, quotes i l’aturada programada dels entorns inactius.

    Límits i dependències

    Els estalvis més grans solen venir de decisions d’arquitectura i d’ús que prenen les persones responsables de producte, no només de la plataforma.

05 Com treballem

Com treballem

Primer les bases, després un equip pel camí estàndard i després tots els altres.

  1. 01

    Avaluar i classificar

    Càrregues de treball, sensibilitat de les dades, costos actuals i els controls que esperen els vostres auditors.

    ResultatClassificació de les càrregues i opcions de destinació

  2. 02

    Construir la landing zone

    Tot com a codi, revisat amb seguretat, amb un procés per a les excepcions.

    ResultatLanding zone en producció

  3. 03

    Incorporar un equip pioner

    Un equip de producte passa al camí estàndard; les seves dificultats donen forma a la plataforma.

    ResultatPrimer servei a la plataforma

  4. 04

    Escalar i fer el traspàs

    S’hi incorporen més equips, l’equip de plataforma n’assumeix la responsabilitat i la recuperació es prova periòdicament.

    ResultatFull de ruta de la plataforma i informes de proves de recuperació

06 Control humà

On les persones mantenen el control

L’automatització fa funcionar la plataforma. Les persones són responsables de les decisions que comporten risc o cost.

  • Els canvis a producció són traçables

    Cada canvi a producció surt d’un commit revisat, de manera que sempre consta qui ha canviat què i qui ho ha aprovat.

  • L’accés d’emergència és excepcional i queda registrat

    L’accés d’emergència té un temps limitat, s’ha de justificar i es revisa després.

  • Les excepcions a les polítiques tenen una persona responsable

    Quan una càrrega necessita una excepció a una salvaguarda, l’aprova una persona responsable del risc designada, amb una data de caducitat.

  • Les persones responsables dels serveis fixen els objectius

    Els objectius de recuperació i els nivells de servei s’acorden amb la persona responsable de negoci de cada servei; no els fixa només l’equip de plataforma.

07 Tecnologies

Tecnologies amb què treballem

Núvol
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Ofertes de núvol sobirà de la UE
Infraestructura i lliurament
  • Terraform i OpenTofu
  • Bicep
  • Argo CD i Flux
  • GitHub Actions, GitLab CI i Azure DevOps
Execució
  • Kubernetes i variants gestionades
  • Plataformes sense servidor i de contenidors
  • Service mesh on surt a compte
  • Grups de nodes amb GPU per a càrregues d’IA
Operació
  • OpenTelemetry
  • Prometheus i Grafana
  • Monitoratge natiu del núvol
  • Motors de polítiques com OPA

Esmentar una tecnologia descriu la nostra experiència d’enginyeria. No implica cap acord de col·laboració amb el fabricant ni cap aval per part seva.

08 Exemple

Un exemple il·lustratiu

Exemple il·lustratiu

Una landing zone per a una empresa de programari que dona servei a organismes públics

01Situació
Una empresa ofereix una aplicació en mode SaaS a ajuntaments i altres organismes públics. Els plecs nous demanen la conformitat amb l’Esquema Nacional de Seguretat per als sistemes que presten el servei, i els seus entorns al núvol han crescut sense un criteri comú.
02Què construiríem
Una sola landing zone com a codi, amb els controls relacionats amb les mesures de l’ENS, registres centralitzats, un procés d’incidents que classifica i deriva les notificacions, i evidència generada per la mateixa plataforma.
03On decideix una persona
La persona responsable de seguretat de l’empresa aprova les excepcions a les polítiques. L’avaluació de la conformitat no la fem nosaltres: l’empresa la porta a terme pel procediment que correspongui, amb l’evidència que genera la plataforma.
04Què mesuraríem
Proporció de càrregues de treball sota polítiques, controls amb evidència automàtica, temps entre la detecció i la classificació d’un incident i proves de recuperació superades cada trimestre.

09 Per sectors

En el vostre sector

  • Sector públic

    Opcions de sobirania per a cada classe de dades, sistemes dissenyats perquè es pugui complir l’Esquema Nacional de Seguretat i plans de sortida que resisteixen la licitació següent.

  • Serveis financers

    Resiliència operativa d’acord amb DORA: recuperació provada, supervisió dels proveïdors de serveis TIC i notificació d’incidents integrada a l’operació.

Espanya

L’evidència, una sola vegada i per a cada supervisor

La Directiva NIS2 és una sola directiva amb transposicions nacionals que difereixen en l’àmbit, el registre i el detall de les notificacions. Les entitats financeres hi sumen DORA, amb la seva pròpia notificació d’incidents i supervisió de tercers. Un grup que opera en diversos països necessita una sola plataforma capaç de generar l’evidència que demana cada autoritat.

A Espanya, la transposició de la Directiva NIS2 és encara un avantprojecte de llei (situació a 6 de novembre del 2026); avui són vigents el Reial decret llei 12/2018, de seguretat de les xarxes i sistemes d’informació, i el Reial decret 43/2021. L’Esquema Nacional de Seguretat (ENS) s’aplica a tot el sector públic i també als sistemes de les empreses privades que li presten serveis o li proporcionen solucions per contracte: els plecs n’han d’exigir la conformitat, i l’exigència arriba a la cadena de subministrament en la mesura que ho requereixi l’anàlisi de riscos. Per a DORA, l’autoritat competent depèn del tipus d’entitat: el Banc d’Espanya, la CNMV o la DGSFP.

Dissenyem landing zones en què la residència, els registres i la classificació d’incidents són polítiques, no projectes, de manera que una entitat o un país nou s’incorpora per configuració. Els plans de sortida es basen en els drets de canvi de proveïdor del Reglament de dades de la UE, i es proven, no només s’escriuen.

Preguntes sobre el núvol i l’enginyeria de plataformes

Quin proveïdor de núvol ens recomaneu?

El que s’adapti a les vostres càrregues de treball, als vostres contractes actuals i als vostres requisits de sobirania. Treballem amb els grans proveïdors de núvol i amb ofertes sobiranes de la UE, i documentem els compromisos perquè l’elecció es pugui defensar en una licitació i revisar més endavant.

Necessitem Kubernetes?

No sempre. Kubernetes surt a compte quan teniu molts serveis i un equip per operar la plataforma. Per a uns quants serveis, les plataformes gestionades de contenidors o sense servidor solen ser més senzilles i més barates de mantenir.

Com enfoqueu la seguretat?

La seguretat és dins de la landing zone i de les cadenes: identitats amb el mínim privilegi, polítiques com a codi, artefactes signats i secrets que no són mai al codi. FromNine té la certificació ISO/IEC 27001 per a la gestió de la seguretat de la informació. Si presteu serveis a organismes públics, dissenyem la plataforma perquè pugueu complir l’Esquema Nacional de Seguretat i en generi l’evidència tècnica. L’avaluació de la conformitat dels vostres sistemes la feu vosaltres pel procediment que correspongui.

Ens podeu reduir el cost del núvol?

Normalment sí, però no us prometrem cap percentatge abans d’haver vist les dades. Comencem fent visible el cost per producte i després avancem en una llista d’estalvis amb les persones responsables que hi poden actuar.

Com evitem dependre d’un sol proveïdor?

Triant de manera deliberada on depeneu de serveis propis d’un proveïdor, mantenint la infraestructura com a codi i tenint un pla de sortida documentat i provat. El Reglament de dades de la UE reforça els vostres drets de canvi de proveïdor; un pla de sortida fa que els pugueu exercir.

Mostreu-nos les vostres tres publicacions següents

Us direm què les faria rutinàries, i quant costaria construir i mantenir aquesta base.

Parlem del vostre projecteArquitectura i consultoria