Saltar ao contido principal
FromNine
Menú

Enxeñaría

Bases na nube que fan das versións unha rutina.

Construímos bases na nube e plataformas internas de desenvolvemento nas que os contornos son código, as versións están asinadas e son repetibles, e cada euro de gasto ten un responsable.

Para organizacións que prestan servizos ás administracións ou ao sector financeiro e teñen que demostrar a súa seguridade con evidencias.

Fálenos do seu proxectoVer a arquitectura de referencia
Nube e enxeñaría de plataformas: capas de capacidadeCatro capas superpostas en profundidade. De arriba abaixo: as cargas de traballo dos equipos de produto, a plataforma interna de desenvolvemento, as cadeas de entrega asinadas e, na base, a landing zone con identidade, rede e políticas.01Cargas dos equipos de produto02Plataforma interna de desenvolvemento03Cadeas de entrega asinadas04Landing zone e políticas
  1. 01Landing zones con políticas como código e residencia dos datos fixada para cada carga de traballo
  2. 02Camiños estándar que levan un servizo novo a produción de forma repetible
  3. 03SLO, recuperación probada e custo por produto, á vista de quen decide

01 Problemas

Sinais de que a base o está a frear

  1. 01

    Cada contorno é unha peza única

    Probas e produción diferéncianse en cousas que ninguén puxo por escrito, e os arranxos feitos a man na consola pérdense na seguinte reconstrución.

  2. 02

    Unha versión necesita unha reunión

    Os despregamentos son raros, manuais e programados para a noite. Os equipos acumulan cambios, e iso fai cada versión máis arriscada.

  3. 03

    A factura da nube sorprende a todo o mundo

    Os custos vense por subscrición, non por produto. A capacidade de GPU para traballo de IA queda reservada para quen a pediu primeiro.

  4. 04

    Ninguén sabe se a recuperación funciona

    Hai copias de seguridade. As restauracións non se probaron, e os obxectivos de tempo de recuperación e de perda de datos nunca se acordaron co negocio.

02 Que entregamos

Que entregamos

  1. 01 Landing zones e opcións de soberanía

    Estrutura de contas e subscricións, identidade, rede e salvagardas nos grandes provedores de nube e nas ofertas de nube soberana da UE, con políticas como código e residencia dos datos por carga de traballo.

    Que facemos

    • Deseño da organización, dos grupos de xestión e das contas
    • Rede central, control do tráfico de saída e conectividade privada
    • Políticas como código para residencia, cifrado e etiquetaxe
    • Correspondencia cos requisitos que piden os seus clientes, como a conformidade co ENS nos contratos públicos

    Que recibe

    • Landing zone definida integramente en código
    • Biblioteca de políticas cun proceso de excepcións
    • Documento de opcións de soberanía por clase de carga de traballo

  2. 02 Infraestrutura como código e plataformas internas de desenvolvemento

    Terraform ou OpenTofu e Bicep para a infraestrutura, GitOps para os despregamentos, Kubernetes ou contornos de execución xestionados onde encaixan, e camiños estándar para que un equipo poida arrincar un servizo conforme ás normas sen abrir incidencias.

    Que facemos

    • Biblioteca de módulos de infraestrutura como código
    • GitOps con promoción entre contornos
    • Plataforma Kubernetes ou alternativas xestionadas
    • Modelos de servizo e un portal para desenvolvedores

    Que recibe

    • Plataforma interna de desenvolvemento con camiños estándar
    • Contornos en autoservizo
    • Folla de ruta da plataforma a cargo dun equipo de plataforma

  3. 03 Cadeas de entrega e seguridade da cadea de subministración

    Cadeas que compilan unha soa vez, asinan os artefactos, rexistran a súa procedencia segundo SLSA, xestionan ben os segredos e promoven o mesmo artefacto de probas a produción.

    Que facemos

    • Modelos de cadea con controis de calidade e de seguridade
    • Sinatura de artefactos e atestación da procedencia
    • Xestión de segredos e rotación de claves
    • Regras de promoción e rexistros de cambios

    Que recibe

    • Modelos de cadea reutilizables
    • Artefactos asinados con procedencia verificable
    • Evidencia das versións para a xestión de cambios

  4. 04 Observabilidade e SRE

    Obxectivos de nivel de servizo acordados co negocio, orzamentos de erro que marcan o ritmo das versións, OpenTelemetry en toda a pila e un proceso de incidentes que serve tamén para as obrigas de notificación da NIS2 e de DORA cando se apliquen.

    Que facemos

    • Definición dos SLO coas persoas responsables de cada servizo
    • Instrumentación con OpenTelemetry e paneis
    • Alertas sobre os síntomas, non sobre as causas
    • Xestión de incidentes e revisións posteriores

    Que recibe

    • Catálogo de SLO
    • Pila de observabilidade e paneis
    • Manuais de incidentes e de notificación

  5. 05 FinOps e capacidade para IA

    Asignación de custos por produto e por equipo, custos unitarios como o custo por transacción, e planificación da capacidade de GPU e control do seu custo para as cargas de traballo de IA.

    Que facemos

    • Política de etiquetaxe e modelo de asignación
    • Métricas de custo unitario por produto
    • Planificación de compromisos de uso e reservas
    • Planificación de GPU, cotas e axuste do dimensionamento

    Que recibe

    • Paneis de custos para cada responsable de produto
    • Lista de aforros con responsables
    • Plan de capacidade para IA

  6. 06 Recuperación e saída

    Copias de seguridade e recuperación ante desastres con obxectivos explícitos de tempo e de punto de recuperación, probadas segundo un calendario, e unha estratexia de saída que usa os dereitos de cambio de provedor do Regulamento de datos da UE.

    Que facemos

    • RTO e RPO acordados para cada servizo
    • Probas de restauración e de conmutación
    • Mapa de dependencias dos servizos críticos
    • Plan de saída e comprobacións de portabilidade dos datos

    Que recibe

    • Procedementos de recuperación probados
    • Informes das probas de recuperación
    • Estratexia de saída documentada

03 Arquitectura

Unha arquitectura de referencia ilustrativa

O código entra pola esquerda e as cargas de traballo en funcionamento saen pola dereita. No medio, a cadea asina o que compila, o rexistro só garda artefactos asinados e un controlador GitOps promóveos entre contornos baixo as políticas.

Por debaixo está a landing zone: estrutura da organización, identidade, rede, claves, recuperación e control de custos, definidos unha vez en código e compartidos por todos os equipos de produto.

Capas do debuxo

Entrega
Repositorios, cadeas, artefactos asinados e promoción con GitOps.
Plataforma
A plataforma interna de desenvolvemento, as políticas como código e o contorno de execución no que despregan os equipos de produto.
Landing zone
Organización, identidade, rede, claves, recuperación e controis de FinOps.
Operación
Telemetría, SLO, orzamentos de erro e resposta a incidentes en todo o conxunto.
Exemplo ilustrativo

  1. Entrega

    • Repositorios de código e IaC
    • Compilar, asinar, atestar
    • Rexistro de artefactos asinados
    • Promoción con GitOps

  2. Plataforma

    • Plataforma interna e camiños estándar
    • Políticas como código
    • Kubernetes e servizos xestionados
    • Cargas dos equipos de produto

  3. Landing zone

    • Estrutura de xestión
    • Identidade e acceso
    • Rede central e saída
    • Claves e segredos
    • Copias e recuperación
    • Asignación de custos

  4. Operación

    • OpenTelemetry, SLO e orzamentos de erro, resposta a incidentes
Entrega asinada sobre unha landing zone gobernada por políticas

Arquitectura ilustrativa, non é o sistema dun cliente.

Ler o diagrama como texto

A ruta principal vai dos repositorios de código e de infraestrutura ás cadeas que compilan, asinan e atestan, a un rexistro de artefactos, despois a un controlador GitOps e, finalmente, aos espazos de cargas de traballo dos equipos de produto.

Unha plataforma interna de desenvolvemento ofrece camiños estándar cara ás cadeas. As políticas como código limitan o controlador GitOps. Unha plataforma de execución con Kubernetes e servizos xestionados aloxa as cargas de traballo. As claves xestionadas polo cliente alimentan a capa de políticas.

A landing zone, por debaixo, contén a estrutura de xestión, a identidade e o acceso, un nodo central de rede, as claves, as copias de seguridade e a recuperación, e os controis de FinOps. A observabilidade con SLO e a resposta a incidentes abranguen toda a plataforma.

04 Consideracións e límites

Consideracións técnicas e límites

  • A soberanía ten graos

    Como o abordamos

    Clasificamos as cargas de traballo segundo a súa sensibilidade e asignamos a cada clase unha opción: rexións da UE dun gran provedor, unha oferta de nube soberana ou infraestrutura privada. As contrapartidas en funcións, custo e operación quedan por escrito.

    Límites e dependencias

    As ofertas soberanas adoitan ir por detrás en servizos xestionados, tamén nos de IA. Algunhas cargas de traballo custarán máis ou farán menos alí, e iso é unha decisión de negocio.

  • Unha plataforma necesita unha persoa responsable de produto

    Como o abordamos

    Tratamos a plataforma interna como un produto con persoas usuarias, folla de ruta e ciclos de valoración, e axudámoslle a formar o equipo que a opera.

    Límites e dependencias

    Unha plataforma sen equipo convértese nun pescozo de botella. Se non pode dotala de persoal, recomendaremos servizos xestionados e menos abstraccións.

  • A normativa condiciona a operación

    Como o abordamos

    A clasificación de incidentes, os prazos de notificación e a recollida de evidencias intégranse no proceso de incidentes cando a súa organización está suxeita ao ENS, á NIS2 ou a DORA.

    Límites e dependencias

    Determinar se a súa organización entra no ámbito, e como lle afectará a norma española de transposición da NIS2 cando se aprobe, corresponde aos seus equipos de cumprimento e xurídico.

  • O control de custos é compartido

    Como o abordamos

    Facemos visible o custo por produto e engadimos salvagardas como orzamentos, cotas e o apagado programado dos contornos inactivos.

    Límites e dependencias

    Os maiores aforros adoitan vir das decisións de arquitectura e de uso que toman as persoas responsables de produto, non só da plataforma.

05 Como traballamos

Como traballamos

Primeiro a base, despois un equipo no camiño estándar e despois todos os demais.

  1. 01

    Avaliar e clasificar

    Cargas de traballo, sensibilidade dos datos, custos actuais e os controis que esperan as súas auditorías e, se presta servizos ao sector público, o ENS.

    ResultadoClasificación das cargas de traballo e opcións de destino

  2. 02

    Construír a landing zone

    Todo como código, revisado con seguridade, cun proceso para as excepcións.

    ResultadoLanding zone en produción

  3. 03

    Incorporar un equipo piloto

    Un equipo de produto pasa ao camiño estándar; as súas dificultades dan forma á plataforma.

    ResultadoPrimeiro servizo na plataforma

  4. 04

    Escalar e traspasar

    Incorpóranse máis equipos, o equipo de plataforma asume a responsabilidade e a recuperación próbase segundo un calendario.

    ResultadoFolla de ruta da plataforma e informes das probas de recuperación

06 Control humano

Onde as persoas manteñen o control

A automatización fai funcionar a plataforma. As persoas son responsables das decisións que levan risco ou custo.

  • Os cambios en produción son trazables

    Cada cambio en produción vén dun commit revisado, así que sempre consta quen cambiou que e quen o aprobou.

  • O acceso de emerxencia é raro e queda rexistrado

    O acceso de emerxencia ten un tempo limitado, necesita unha xustificación e revísase despois.

  • As excepcións ás políticas teñen responsable

    Cando unha carga de traballo necesita unha excepción a unha salvagarda, apróbaa unha persoa responsable do risco designada, cunha data de caducidade.

  • Os responsables do servizo fixan os obxectivos

    Os obxectivos de recuperación e os niveis de servizo acórdanse coa persoa responsable de negocio de cada servizo, non os fixa só o equipo de plataforma.

07 Tecnoloxías

Tecnoloxías coas que traballamos

Nube
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Ofertas de nube soberana da UE
Infraestrutura e entrega
  • Terraform e OpenTofu
  • Bicep
  • Argo CD e Flux
  • GitHub Actions, GitLab CI e Azure DevOps
Execución
  • Kubernetes e as súas variantes xestionadas
  • Plataformas serverless e de contedores
  • Service mesh onde compensa
  • Grupos de nodos con GPU para cargas de IA
Operación
  • OpenTelemetry
  • Prometheus e Grafana
  • Monitorización nativa da nube
  • Motores de políticas como OPA

Mencionar unha tecnoloxía describe a nosa experiencia técnica. Non implica unha asociación co seu fabricante nin o seu respaldo.

08 Exemplo

Un exemplo ilustrativo

Exemplo ilustrativo

Unha landing zone para un provedor que debe cumprir o ENS nun contrato público

01Situación
Unha empresa de software presta un servizo a unha deputación baixo un contrato cuxos pregos esixen a conformidade co ENS. Os seus contornos na nube creceron sen unha estrutura común, con controis distintos en cada un, e ninguén pode mostrar nunha soa vista que sistemas entran no contrato.
02Que construiriamos
Unha landing zone en código cos sistemas do contrato separados do resto, políticas aliñadas coa categoría do ENS que fixa o prego, rexistros compartidos e un proceso de incidentes que informa ao organismo contratante nos prazos acordados.
03Onde deciden as persoas
A persoa responsable de seguridade do provedor aproba as excepcións ás políticas e a evidencia de conformidade antes de presentala; o organismo contratante decide se a acepta.
04Que mediriamos
Tempo desde a detección dun incidente ata a súa clasificación, proporción de cargas de traballo baixo política e probas de recuperación superadas por trimestre.

09 Por sector

No seu sector

  • Sector público

    Opcións de soberanía por clase de datos, os requisitos do ENS que fixan os pregos e plans de saída que resisten a seguinte licitación.

  • Servizos financeiros

    Resiliencia operativa segundo DORA: recuperación probada, supervisión dos provedores TIC e notificación de incidentes integradas na operación.

España

A evidencia, preparada para cada esixencia

A transposición da NIS2 en España segue pendente: o anteproxecto aprobouse en xaneiro de 2025 e, en novembro de 2026, aínda non chegou ás Cortes. Mentres tanto segue en vigor o Real decreto-lei 12/2018. As entidades financeiras engaden DORA, que supervisan o Banco de España, a CNMV ou a DGSFP segundo o tipo de entidade.

O Esquema nacional de seguridade (Real decreto 311/2022) aplícase a todo o sector público e tamén aos sistemas dos provedores privados que, por contrato, prestan servizos ou solucións ás entidades públicas. Os pregos deben esixir a conformidade co ENS, que se estende á cadea de subministración do contratista na medida en que o require a análise de riscos.

Deseñamos landing zones nas que a residencia, os rexistros e a clasificación de incidentes son políticas e non proxectos. Cando un contrato público esixe o ENS, documentamos na propia plataforma os controis e as evidencias que a súa organización presenta para acreditar a conformidade. Os plans de saída apóianse nos dereitos de cambio de provedor do Regulamento de datos da UE e próbanse, non só se escriben.

Preguntas sobre nube e enxeñaría de plataformas

Que provedor de nube nos recomendan?

O que mellor encaixa coas súas cargas de traballo, cos seus contratos actuais e cos seus requisitos de soberanía. Traballamos cos grandes provedores de nube e coas ofertas soberanas da UE, e documentamos as contrapartidas para que a elección se poida defender nunha licitación e revisar máis adiante.

Necesitamos Kubernetes?

Non sempre. Kubernetes compensa cando se executan moitos servizos e hai un equipo para operar a plataforma. Para uns poucos servizos, as plataformas xestionadas de contedores ou serverless adoitan ser máis sinxelas e máis baratas de operar.

Como abordan a seguridade?

A seguridade intégrase na landing zone e nas cadeas: identidades co mínimo privilexio, políticas como código, artefactos asinados e segredos que nunca están no código. FromNine ten a certificación ISO/IEC 27001 de xestión da seguridade da información. Cando un contrato público esixe o ENS, documentamos o cumprimento que pide o contrato nos sistemas que construímos e operamos.

Poden reducir os nosos custos de nube?

Normalmente si, pero non prometemos unha porcentaxe antes de ver os datos. Comezamos por facer visible o custo por produto e despois traballamos unha lista de aforros coas persoas responsables que poden actuar sobre eles.

Como evitamos a dependencia dun provedor?

Escollendo con criterio onde depender de servizos propios dun provedor, mantendo a infraestrutura en código e cun plan de saída documentado e probado. O Regulamento de datos da UE reforza os seus dereitos a cambiar de provedor; un plan de saída fai que se poidan exercer.

Mostre as súas tres próximas versións

Dirémoslle que as faría rutineiras e canto custaría construír e operar esa base.

Fálenos do seu proxectoVer arquitectura e consultoría