Ir al contenido principal
FromNine
Menú

Ingeniería

Cloud e ingeniería de plataformas para que cada despliegue sea rutina

Construimos cimientos en la nube y plataformas internas para desarrolladores en los que los entornos son código, los despliegues están firmados y son repetibles, y cada euro de gasto tiene un responsable.

Para organizaciones en España que trasladan sistemas a la nube y deben demostrar su seguridad ante el responsable del ENS, su auditor o su supervisor.

Hablemos de su proyectoConozca nuestro enfoque
Cloud e ingeniería de plataformas: capas de capacidadCuatro capas superpuestas en profundidad. De arriba abajo: las cargas de trabajo de los equipos de producto, la plataforma interna para desarrolladores, los pipelines de entrega firmados y, en la base, la landing zone con identidad, red y políticas.01Cargas de los equipos de producto02Plataforma interna para desarrolladores03Pipelines de entrega firmados04Landing zone y políticas
  1. 01Landing zones con políticas como código y residencia de datos definida por carga de trabajo
  2. 02Golden paths que llevan un nuevo servicio a producción de forma repetible
  3. 03SLO, recuperación probada y coste por producto, visibles para quienes deciden

01 Problemas

Señales de que los cimientos le frenan

  1. 01

    Cada entorno es un caso aparte

    Pruebas y producción difieren en aspectos que nadie ha documentado, y los arreglos hechos a mano en la consola se pierden en la siguiente reconstrucción.

  2. 02

    Desplegar exige una reunión

    Los despliegues son escasos, manuales y se programan por la noche. Los equipos acumulan cambios, lo que hace cada despliegue más arriesgado.

  3. 03

    La factura de la nube sorprende a todos

    Los costes se ven por suscripción, no por producto. La capacidad de GPU para la IA se la queda quien la pidió primero.

  4. 04

    Nadie sabe si la recuperación funciona

    Hay copias de seguridad. Las restauraciones no se han probado, y los objetivos de tiempo de recuperación y de pérdida de datos nunca se acordaron con el negocio.

02 Qué entregamos

Qué entregamos

  1. 01 Landing zones y opciones de soberanía

    Estructura de cuentas y suscripciones, identidad, red y salvaguardas en los principales hiperescaladores y en ofertas de nube soberana europea, con políticas como código y residencia de datos por carga de trabajo.

    Qué hacemos

    • Diseño de la organización, los grupos de administración y las cuentas
    • Red hub, control del tráfico saliente y conectividad privada
    • Políticas como código para residencia, cifrado y etiquetado
    • Correspondencia con las acreditaciones que piden sus clientes, como BSI C5 o SecNumCloud

    Qué recibe

    • Landing zone definida íntegramente en código
    • Biblioteca de políticas con proceso de excepciones
    • Documento de opciones de soberanía por tipo de carga

  2. 02 Infraestructura como código y plataformas internas para desarrolladores

    Terraform u OpenTofu y Bicep para la infraestructura, GitOps para los despliegues, Kubernetes o entornos de ejecución gestionados donde encajan, y golden paths para que un equipo pueda poner en marcha un servicio conforme sin abrir tickets.

    Qué hacemos

    • Biblioteca de módulos de infraestructura como código
    • GitOps con promoción entre entornos
    • Plataforma Kubernetes o alternativas gestionadas
    • Plantillas de servicio y un portal para desarrolladores

    Qué recibe

    • Plataforma interna para desarrolladores con golden paths
    • Entornos en autoservicio
    • Hoja de ruta de la plataforma a cargo de un equipo de plataforma

  3. 03 Pipelines de entrega y seguridad de la cadena de suministro

    Pipelines que compilan una sola vez, firman los artefactos, registran su procedencia conforme a SLSA, gestionan los secretos como es debido y promocionan el mismo artefacto de pruebas a producción.

    Qué hacemos

    • Plantillas de pipeline con controles de calidad y seguridad
    • Firma de artefactos y atestación de procedencia
    • Gestión de secretos y rotación de claves
    • Reglas de promoción y registros de cambios

    Qué recibe

    • Plantillas de pipeline reutilizables
    • Artefactos firmados con procedencia verificable
    • Evidencias de cada despliegue para la gestión de cambios

  4. 04 Observabilidad y SRE

    Objetivos de nivel de servicio acordados con el negocio, presupuestos de error que marcan el ritmo de despliegue, OpenTelemetry en toda la pila y un proceso de incidentes que también sirve para las obligaciones de notificación de NIS2 y DORA cuando le son aplicables.

    Qué hacemos

    • Definición de SLO con los responsables de cada servicio
    • Instrumentación con OpenTelemetry y cuadros de mando
    • Alertas basadas en síntomas, no en causas
    • Gestión de incidentes y revisiones posteriores

    Qué recibe

    • Catálogo de SLO
    • Pila de observabilidad y cuadros de mando
    • Runbooks de incidentes y de notificación

  5. 05 FinOps y capacidad para la IA

    Imputación de costes por producto y por equipo, economía unitaria como el coste por transacción, y planificación de capacidad y control del coste de GPU para las cargas de IA.

    Qué hacemos

    • Política de etiquetado y modelo de imputación
    • Métricas de coste unitario por producto
    • Planificación de compromisos y reservas
    • Planificación de GPU, cuotas y dimensionamiento ajustado

    Qué recibe

    • Cuadros de mando de costes por responsable de producto
    • Backlog de ahorros con responsables
    • Plan de capacidad para la IA

  6. 06 Recuperación y salida

    Copias de seguridad y recuperación ante desastres con objetivos explícitos de tiempo y punto de recuperación, probadas de forma periódica, y una estrategia de salida que aprovecha los derechos de cambio de proveedor del Reglamento de Datos de la UE.

    Qué hacemos

    • RTO y RPO acordados por servicio
    • Pruebas de restauración y de conmutación por error
    • Mapa de dependencias de los servicios críticos
    • Plan de salida y comprobaciones de portabilidad de datos

    Qué recibe

    • Procedimientos de recuperación probados
    • Informes de las pruebas de recuperación
    • Estrategia de salida documentada

03 Arquitectura

Una arquitectura de referencia ilustrativa

El código entra por la izquierda y las cargas de trabajo en ejecución salen por la derecha. Entre medias, el pipeline firma lo que compila, el registro solo almacena artefactos firmados y un controlador GitOps los promociona de un entorno a otro conforme a las políticas.

Por debajo está la landing zone: estructura organizativa, identidad, red, claves, recuperación y control de costes, definidos una sola vez en código y compartidos por todos los equipos de producto.

Capas del diagrama

Entrega
Repositorios, pipelines, artefactos firmados y promoción mediante GitOps.
Plataforma
La plataforma para desarrolladores, las políticas como código y el entorno de ejecución en el que despliegan los equipos de producto.
Landing zone
Organización, identidad, red, claves, recuperación y controles de FinOps.
Operación
Telemetría, SLO, presupuestos de error y respuesta a incidentes sobre todo el conjunto.
Ejemplo ilustrativo

  1. Entrega

    • Repositorios de código e IaC
    • Compilar, firmar, atestar
    • Registro de artefactos firmados
    • Promoción mediante GitOps

  2. Plataforma

    • Plataforma para desarrolladores y golden paths
    • Políticas como código
    • Kubernetes y servicios gestionados
    • Cargas de los equipos de producto

  3. Landing zone

    • Estructura de administración
    • Identidad y acceso
    • Red hub y tráfico saliente
    • Claves y secretos
    • Copias de seguridad y recuperación
    • Imputación de costes

  4. Operación

    • OpenTelemetry, SLO y presupuestos de error, respuesta a incidentes
Entrega firmada sobre una landing zone gobernada por políticas

Arquitectura ilustrativa, no corresponde a ningún sistema de cliente.

Leer el diagrama como texto

El recorrido principal va desde los repositorios de código e infraestructura, a través de pipelines que compilan, firman y atestan, hasta un registro de artefactos; de ahí a un controlador GitOps y, por último, a los espacios de carga de trabajo de los equipos de producto.

Una plataforma interna para desarrolladores ofrece golden paths hacia los pipelines. Las políticas como código acotan el controlador GitOps. Una plataforma de ejecución con Kubernetes y servicios gestionados aloja las cargas de trabajo. Las claves gestionadas por el cliente alimentan la capa de políticas.

La landing zone, en la parte inferior, contiene la estructura de administración, la identidad y el acceso, una red hub, las claves, las copias de seguridad y la recuperación, y los controles de FinOps. La observabilidad, con SLO y respuesta a incidentes, abarca toda la plataforma.

04 Consideraciones y límites

Consideraciones de ingeniería y límites

  • La soberanía es una escala de grises

    Cómo lo abordamos

    Clasificamos las cargas de trabajo por sensibilidad y asignamos a cada tipo una opción: regiones europeas de un hiperescalador, una oferta de nube soberana o infraestructura privada. Las contrapartidas en funcionalidades, coste y operación quedan por escrito.

    Límites y dependencias

    Las ofertas soberanas suelen ir por detrás en servicios gestionados, incluidos los de IA. Algunas cargas costarán más o harán menos allí, y esa es una decisión de negocio.

  • Una plataforma necesita un product owner

    Cómo lo abordamos

    Tratamos la plataforma interna como un producto con usuarios, hoja de ruta y ciclos de retroalimentación, y le ayudamos a formar el equipo que la gestiona.

    Límites y dependencias

    Una plataforma sin equipo se convierte en un cuello de botella. Si no puede dotarla de personal, le recomendaremos servicios gestionados y menos capas de abstracción.

  • La normativa condiciona la operación

    Cómo lo abordamos

    La clasificación de incidentes, los plazos de notificación y la recopilación de evidencias se integran en el proceso de incidentes cuando NIS2 o DORA le son aplicables.

    Límites y dependencias

    Determinar si su organización está dentro del ámbito, y cómo se aplica la transposición nacional, corresponde a sus equipos de cumplimiento y jurídico.

  • El control de costes es compartido

    Cómo lo abordamos

    Hacemos visible el coste por producto y añadimos salvaguardas como presupuestos, cuotas y el apagado programado de los entornos inactivos.

    Límites y dependencias

    Los mayores ahorros suelen venir de decisiones de arquitectura y de uso que toman los responsables de producto, no solo de la plataforma.

05 Cómo trabajamos

Cómo trabajamos

Primero los cimientos, después un equipo en el golden path y, a continuación, todos los demás.

  1. 01

    Evaluar y clasificar

    Cargas de trabajo, sensibilidad de los datos, costes actuales y los controles que esperan sus auditores.

    ResultadoClasificación de cargas y opciones de destino

  2. 02

    Construir la landing zone

    Todo como código, revisado con seguridad y con un proceso para las excepciones.

    ResultadoLanding zone en producción

  3. 03

    Incorporar un equipo piloto

    Un equipo de producto pasa al golden path; sus fricciones dan forma a la plataforma.

    ResultadoPrimer servicio en la plataforma

  4. 04

    Escalar y traspasar

    Se incorporan más equipos, el equipo de plataforma asume la responsabilidad y la recuperación se prueba de forma periódica.

    ResultadoHoja de ruta de la plataforma e informes de las pruebas de recuperación

06 Control humano

Dónde mantienen el control las personas

La automatización hace funcionar la plataforma. Las decisiones que implican riesgo o coste corresponden a las personas.

  • Los cambios en producción son trazables

    Todo cambio en producción procede de un commit revisado, de modo que siempre consta quién cambió qué y quién lo aprobó.

  • El acceso de emergencia es excepcional y queda registrado

    El acceso de emergencia tiene una duración limitada, requiere justificación y se revisa a posteriori.

  • Las excepciones a las políticas tienen un responsable

    Cuando una carga necesita una excepción a una salvaguarda, la aprueba un responsable de riesgos designado, con fecha de caducidad.

  • Los responsables de cada servicio fijan los objetivos

    Los objetivos de recuperación y los niveles de servicio se acuerdan con el responsable de negocio de cada servicio; no los fija el equipo de plataforma por su cuenta.

07 Tecnologías

Tecnologías con las que trabajamos

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Ofertas de nube soberana europea
Infraestructura y entrega
  • Terraform y OpenTofu
  • Bicep
  • Argo CD y Flux
  • GitHub Actions, GitLab CI y Azure DevOps
Ejecución
  • Kubernetes y sus variantes gestionadas
  • Plataformas serverless y de contenedores
  • Service mesh cuando compensa
  • Grupos de nodos con GPU para cargas de IA
Operación
  • OpenTelemetry
  • Prometheus y Grafana
  • Supervisión nativa de la nube
  • Motores de políticas como OPA

La mención de una tecnología refleja nuestra experiencia de ingeniería. No implica ninguna asociación con su fabricante ni su respaldo.

08 Ejemplo

Un ejemplo ilustrativo

Ejemplo ilustrativo

Una plataforma SaaS para ayuntamientos, con el ENS en el pliego

01Situación
Un fabricante de software de gestión tributaria para ayuntamientos ofrece su producto como servicio, y cada vez más pliegos le exigen la conformidad con el ENS en categoría media.
02Qué construiríamos
Una plataforma cloud común para todos sus clientes, con entornos aislados por ayuntamiento, despliegues automatizados y controles vinculados a las medidas del ENS que generan evidencia para la auditoría.
03Dónde deciden las personas
El responsable de seguridad del fabricante aprueba cada excepción; los cambios en producción requieren revisión y quedan registrados.
04Qué mediríamos
Tiempo para dar de alta un nuevo ayuntamiento, medidas del ENS con evidencia automática e incidencias por versión.

09 Por sectores

En su sector

  • Sector público y Administración

    Opciones de soberanía por categoría de datos, acreditaciones nacionales de seguridad y planes de salida que sobreviven a la siguiente licitación.

  • Servicios financieros

    Resiliencia operativa conforme a DORA: recuperación probada, supervisión de los proveedores TIC y notificación de incidentes integrada en la operación.

España

Cloud con el Esquema Nacional de Seguridad como referencia

En España, el Esquema Nacional de Seguridad es la referencia de seguridad para los sistemas del sector público y para los proveedores que les prestan servicio, también en la nube. El CCN publica las guías CCN-STIC que concretan sus medidas, y la transposición española de NIS2 extenderá exigencias parecidas a muchas más empresas privadas.

Diseñamos plataformas en las que las medidas del ENS se aplican como código y generan evidencia automática, para que una auditoría no dependa de reconstruir lo que se hizo meses atrás. La certificación sigue correspondiendo a su organización y a sus proveedores cloud.

Preguntas sobre cloud e ingeniería de plataformas

¿Qué proveedor cloud nos recomiendan?

El que mejor se adapte a sus cargas de trabajo, a sus contratos vigentes y a sus requisitos de soberanía. Trabajamos con los principales hiperescaladores y con ofertas soberanas europeas, y documentamos las contrapartidas para que la elección pueda defenderse en la contratación y revisarse más adelante.

¿Necesitamos Kubernetes?

No siempre. Kubernetes compensa cuando se ejecutan muchos servicios y se cuenta con un equipo para operar la plataforma. Para unos pocos servicios, las plataformas gestionadas de contenedores o serverless suelen ser más sencillas y económicas de operar.

¿Cómo abordan la seguridad?

La seguridad está integrada en la landing zone y en los pipelines: identidades con el mínimo privilegio, políticas como código, artefactos firmados y secretos que nunca residen en el código. FromNine cuenta con la certificación ISO/IEC 27001 de gestión de la seguridad de la información.

¿Pueden reducir nuestros costes en la nube?

Por lo general, sí, pero no prometeremos un porcentaje antes de haber visto los datos. Empezamos por hacer visible el coste por producto y, después, trabajamos un backlog de ahorros con los responsables que pueden actuar sobre ellos.

¿Cómo evitamos la dependencia de un proveedor?

Decidiendo de forma deliberada dónde depender de servicios específicos del proveedor, manteniendo la infraestructura en código y disponiendo de un plan de salida documentado y probado. El Reglamento de Datos de la UE refuerza sus derechos de cambio de proveedor; un plan de salida permite ejercerlos.

Muéstrenos sus próximas tres versiones

Veremos qué frena hoy cada despliegue y qué cambiaría una plataforma común, empezando por una landing zone acotada.

Hablemos de su proyectoConozca nuestro enfoque