El tema central que se fue perfilando a lo largo del día fue el siguiente:
¿Cómo estandarizar y automatizar las arquitecturas para que sean resilientes, escalables y gestionables a gran escala?
Numerosas presentaciones abordaron, cada una desde un ángulo diferente, esta problemática global: desde Kubernetes a gran escala, la industrialización de CI/CD y el enfoque SRE, las plataformas internas para desarrolladores, la refactorización técnica de las aplicaciones, la resiliencia y la seguridad «by design». Para cada tema, destacaremos las soluciones presentadas, las lecciones aprendidas, las buenas prácticas recomendadas, así como las limitaciones o retos identificados.
Implementar clústeres de Kubernetes estandarizados a gran escala
La jornada comenzó con una ponencia sobre la experiencia adquirida en la implementación de Kubernetes a gran escala, presentada por Rachid Zarouali (un experto en Cloud Native muy conocido en la comunidad). Su observación inicial fue:«Hoy en día, implementar un clúster de Kubernetes es fácil, existen numerosas soluciones… tenemos donde elegir. ¿Qué hacer cuando se quiere implementar y gestionar un gran número de clústeres? ¿Qué soluciones utilizar?»
De hecho, si bien crear un clúster K8s se ha convertido en algo trivial (ya sea a través de una nube pública gestionada o en los propios servidores), gestionar decenas o cientos de clústeres de forma coherente y eficaz plantea otros retos. Rachid compartió varios proyectos llevados a cabo para hacer frente a este reto, comparando las herramientas y enfoques posibles, con sus respectivas ventajas e inconvenientes. El objetivo declarado era claro: demostrar que, con la estrategia adecuada, administrar dos clústeresnoes«más complicado»que administrar un centenar.
En concreto, destaca especialmente una solución para estandarizar el ciclo de vida de múltiples clústeres: ClusterAPI (CAPI). Este proyecto de código abierto, que forma parte del ecosistema de Kubernetes, permite definir de forma declarativa «Cluster Specifications» (especificaciones) que se envían a un proveedor de Cluster API encargado de crear o modificar los clústeres basándose en dichas especificaciones. Es, en cierto modo, la «Infraestructura como Código» aplicada a los clústeres. Rachid ilustró la arquitectura básica de este enfoque: un ingeniero de DevOps formula la especificación del clúster deseado (número y tamaño de los nodos, requisitos de alta disponibilidad, etc.) y, a continuación, a través de la API ClusterAPI, un clúster de gestión instanciará el clúster de destino en la infraestructura elegida (nube pública, máquinas virtuales locales, etc.).
Esquema extraído de la presentación de Rachid Zarouali, que ilustra la arquitectura básica para la gestión automatizada de clústeres de Kubernetes a gran escala mediante ClusterAPI. Un ingeniero define la «Cluster Spec» deseada y ClusterAPI se encarga de crearla para generar un clúster de Kubernetes de destino, ya sea en máquinas virtuales o en cualquier otro proveedor.
Este enfoque permite estandarizar la creación y la configuración de los clústeres (cada nuevo clúster se crea a partir de una plantilla común), al tiempo que se delega en las herramientas nativas de la nube la realización de las operaciones repetitivas. Al combinar ClusterAPI con pipelines de GitOps (por ejemplo, ArgoCD) para mantener actualizadas las especificaciones, se obtiene una auténtica fábrica de clústeres que se puede gestionar mediante el control de versiones de Git.
Conclusiones de esta charla: la gestión de un gran número de clústeres de Kubernetes resulta viable siempre que se adopte un alto grado de automatización y modelos estándar. Entre las ventajas se incluyen una mayor coherencia (todos los clústeres se crean siguiendo el mismo patrón), la reducción de los errores manuales y la posibilidad de administrar una flota de clústeres como si fuera una sola entidad. Sin embargo, la automatización a esta escala requiere una inversión inicial considerable: elegir e implementar las herramientas (ClusterAPI u otras), formar a los equipos en estos nuevos flujos de trabajo e implementar una supervisión centralizada para anticipar los problemas (ya que con 100 clústeres, incluso unos pocos errores aislados pueden acabar surgiendo). Precisamente, el ponente insistió en la importancia de no anticiparlo todo de antemano, sino de avanzar «poco a poco», iterando, para ajustar las herramientas y los procesos sobre la marcha, en lugar de intentar preverlo todo teóricamente.
Extracto de la diapositiva de conclusión de un informe de experiencia sobre la renovación de una plataforma (véase la sección más adelante). En él se muestran, a modo de analogía, buenas prácticas aplicables a cualquier proyecto de transformación técnica: avanzar por pequeños pasos sin intentar preverlo todo, dotarse de herramientas y realizar un seguimiento para detectar los problemas sobre la marcha, y eliminar progresivamente los elementos «legados» una vez que el nuevo sistema esté en funcionamiento.
En resumen, gracias a herramientas como ClusterAPI, es posible industrializar el despliegue de Kubernetes para adaptarse a la escalabilidad de las plataformas nativas de la nube. Esto aporta una mayor resiliencia (clústeres reconstruidos sobre la marcha en caso de fallo) y una mejor gobernanza (control centralizado de las versiones de Kubernetes, las configuraciones básicas, etc.), ventajas muy valiosas para un director de sistemas de información que debe gestionar un rápido crecimiento de los servicios.
Industrialización de CI/CD y enfoque SRE a gran escala
Pasemos ahora a la industrialización de los procesos de CI/CD y a la adopción de prácticas de SRE (ingeniería de fiabilidad del sitio) a gran escala.
¿Cómo se pueden coordinar cientos de proyectos de aplicaciones en torno a procesos unificados de integración continua y despliegue continuo, mejorando al mismo tiempo la fiabilidad general?
En este ámbito, el ejemplo más destacado es el de una gran empresa francesa del sector energético que ha desarrollado su propio «forge» de software denominado «Placide». Presentado por Sébastien Longo, este caso práctico describe cómo, en un grupo industrial que presta servicios esenciales, han promovido la metodología DevOps y han implantado un enfoque SRE a escala de toda la empresa. Placide tiene como objetivo «unificar más de 400 proyectos en una CI/CD estandarizada» de acuerdo con los principios SRE. La iniciativa requirió definir una visión común, materializarla a través de una plataforma equipada y, sobre todo, afrontar el reto de incorporar a cientos de equipos a esta nueva cadena de herramientas. Esta estandarización aporta grandes beneficios (compartición de herramientas, buenas prácticas comunes, indicadores de fiabilidad consolidados), pero también implica un acompañamiento del cambio a nivel interno.
El ponente describe los requisitos arquitectónicos: base GitLab, separación de los ejecutores de CI y CD, plantillas de pipelines e integración de servicios de fábrica (secretos, registro, calidad y seguridad del código, etc.). La plataforma Placide, como fábrica de CI/CD, agrupa modelos de pipelines, ejecutores segmentados, integraciones automatizadas y vistas multiproyecto para gestionar más de 400 aplicaciones.
Desde el punto de vista técnico, Placide se asemeja a una cadena de CI/CD «como servicio» interna: repositorio de código, herramientas de CI, orquestación de implementaciones, gestión de artefactos, supervisión, etc.; todo ello proporcionado a los equipos de desarrollo a través de un conjunto de herramientas y reglas comunes. Aunque los detalles de la implementación no se han revelado por completo (por tratarse de una solución propia), se entiende que se hace hincapié en el «Everything as Code», la integración de la seguridad en el pipeline (pruebas de vulnerabilidades, reglas de calidad, etc.) y la recopilación de indicadores SRE (errores, disponibilidad, rendimiento) para cada servicio. Lección aprendida: para integrar más de 400 proyectos en una plataforma uniforme, la técnica no basta. Se necesita una visión compartida (en este caso, «DevOps en todas partes, SRE en todas partes»), patrocinadores para que se adopte la solución y un equipo dedicado a las herramientas que trate a sus «clientes internos» (equipos de desarrollo) con la misma atención que un proveedor de SaaS prestaría a sus clientes externos. Los retos han sido numerosos, en particular gestionar la heterogeneidad inicial de las prácticas, migrar los proyectos existentes sin bloquear las entregas y formar a los desarrolladores en el uso de nuevas herramientas. Pero el resultado empieza a dar sus frutos: una base técnica coherente (la forja Placide) que facilita la gobernanza (por ejemplo, las auditorías de conformidad o de seguridad se simplifican cuando todo pasa por un pipeline central) y que mejora la resiliencia, ya que, una vez integradas las buenas prácticas de SRE en todas partes, la organización afronta mejor los incidentes (detección más temprana, implementaciones más seguras, etc.).
Paralelamente, otra sesión titulada «Go Go Go (por ArgoCD, Golang, Golive)» mostró un enfoque de código abierto para industrializar los despliegues de entornos a gran escala mediante GitOps. Thomas Boullier, François Tritz y Damien Gérard presentaron cómo aprovechan el potencial de ArgoCD (herramienta de GitOps), los operadores de Kubernetes en Go y la CI de Tekton para automatizar y mantener actualizados los entornos de desarrollo en OpenShift. Se hace hincapié en un enfoque «centrado en OpenShift» on-premise, con el diseño de un operador personalizado en Golang para simplificar el despliegue repetido de entornos de desarrollo y pruebas. En la práctica, esto significa que la creación de un nuevo entorno (por ejemplo, un namespace aislado con toda la pila necesaria) se activa a través de Git (definición declarativa), gestionada por ArgoCD, y las tareas específicas (creación de recursos de OpenShift, configuraciones) son gestionadas por un controlador de operador desarrollado a medida. Esta cadena automatizada permite replicar entornos de forma coherente y fiable, y ponerlos en producción de manera fluida.
Buena práctica a tener en cuenta: el uso de GitOps junto con operadores personalizados es una herramienta muy eficaz para escalar las operaciones sin sobrecargar a los equipos; se codifica el conocimiento técnico (patrón de entorno) en el operador de una vez por todas, y cada nuevo despliegue sigue este modelo automáticamente. La contrapartida es la complejidad técnica: hay que dominar el desarrollo de operadores de Kubernetes en Go y el mantenimiento de una cadena de CI/CD avanzada (Tekton, ArgoCD). No obstante, para quien disponga de los medios, este enfoque ofrece una gran flexibilidad y reduce drásticamente los errores humanos en el despliegue de entornos, un punto crucial para la fiabilidad (SRE).
Por último, un aspecto común que se ha destacado tanto en la experiencia de Placide como en esta sesión sobre GitOps es la importancia de integrar la seguridad lo antes posible en el proceso. Tener un WAF en producción o escaneos de vulnerabilidades de contenedores está bien, pero detectar las fallas en una fase anterior de la cadena de CI/CD es mejor. En este sentido, una herramienta como Dependency-Track (presentada por Elisa Degobert) puede ayudar a priorizar las correcciones de dependencias vulnerables en función de su gravedad explotable. Un enfoque pragmático para no verse desbordado por decenas de alertas de seguridad y concentrar los esfuerzos donde es necesario.
En resumen, la industrialización de CI/CD pasa por la implementación de pipelines uniformes, integrados y «seguros por diseño». Ya sea a través de una plataforma interna personalizada como Placide o mediante la combinación de herramientas de código abierto (ArgoCD, Tekton, operadores…), el objetivo es lograr implementaciones fiables, reproducibles y gestionables a gran escala. Para los directores de sistemas de información, esto supone menos riesgos operativos (gracias a los controles automatizados) y una mayor visibilidad sobre la producción. Para los desarrolladores, ofrece un marco equipado que acelera las entregas al tiempo que garantiza una calidad constante.
Plataformas internas y una experiencia de desarrollo homogénea
Otro tema recurrente fue el de la Developer eXperience (DevX) y las plataformas internas (Internal Developer Platforms). En muchas organizaciones, la estandarización de las arquitecturas no se limita a la producción: también es necesario dotar a los desarrolladores de las herramientas necesarias para que trabajen en entornos coherentes, eficaces y seguros, independientemente del tamaño del equipo o del código base. Engin Diri y Alexandre Nedelec propusieron así una sesión de fondo titulada «Internal Developer Platforms: elegir el camino adecuado para su organización». En primer lugar, recordaron que, más allá de la moda, las IDP se han convertido en un elemento esencial de las prácticas DevOps modernas, con el objetivo de racionalizar los flujos de trabajo de los desarrolladores y acelerar las entregas. Sin embargo, ante la plétora de soluciones posibles, desde el código abierto (Backstage) hasta las ofertas SaaS (Port, Pulumi Cloud, etc.), las empresas deben tomar decisiones complejas para elaborar su estrategia de IDP.
Su presentación proporcionó un marco de evaluación práctico: ¿cuáles son los componentes esenciales de una plataforma de desarrollo moderna? ¿Es mejor desarrollar la plataforma internamente o recurrir a un producto del mercado? ¿Cuáles son los patrones de implementación que funcionan y los antipatrones que hay que evitar? Son preguntas que se plantean hoy en día los directores de sistemas de información, ya que la promesa es muy atractiva (una experiencia de desarrollador «de 5 estrellas» que mejora la productividad y reduce el tiempo de comercialización), pero el camino está plagado de obstáculos (coste de desarrollo de una plataforma propia, integración con lo ya existente, riesgo de dependencia de una solución SaaS, etc.).
Una plataforma de desarrollo de aplicaciones (IDP) eficaz debe ofrecer «las funcionalidades esenciales para los desarrolladores» (entornos de desarrollo listos para usar, implementación de autoservicio, catálogos de servicios, herramientas de seguridad, etc.) y, al mismo tiempo, ajustarse a los objetivos empresariales. Por ejemplo, un banco exigirá sólidas capacidades integradas de gobernanza y cumplimiento normativo, mientras que una startup buscará ante todo la rapidez de implementación. No existe una solución única que se adapte a todos, de ahí la importancia de evaluar bien las opciones. Engin y Alexandre compararon soluciones de código abierto como Backstage (muy flexible y extensible, pero que requiere una inversión para su funcionamiento) y soluciones SaaS como Port o Pulumi Cloud (listas para usar, pero menos personalizables). También hicieron hincapié en la cuestión «Build vs Buy»: desarrollar una plataforma propia puede ofrecer una ventaja a medida, pero es un proyecto a largo plazo que requiere un equipo dedicado a la plataforma, lo cual solo es viable si el tamaño de la organización lo justifica. Por el contrario, una solución existente puede implementarse más rápidamente, a costa de posibles concesiones en cuanto a funcionalidades o independencia.
En definitiva, la elección de la IDP «adecuada» depende del grado de madurez DevOps de la empresa, de sus limitaciones (seguridad, normativa…) y de su ecosistema tecnológico (nube híbrida, multinube, on-premise, etc.). Sea como sea, las IDP están a punto de convertirse en un estándar en los grandes departamentos de TI: las mejoras en eficiencia y fiabilidad que aportan han quedado ampliamente demostradas (especialmente en los gigantes de Internet pioneros en ingeniería de plataformas), y las herramientas se están generalizando.
Para ilustrar de forma concreta la implementación de una plataforma de desarrollo, otra charla nos llevó al terreno de los entornos de desarrollo en la nube. «Desarrolla en una tostadora gracias a Coder», el divertido título de la presentación de Melissa Pinon y Paul Vulliemin, parte de un problema que sufren muchas empresas: «¿Tus desarrolladores se quejan de que su PC es una tostadora? ¿De que los entornos no son homogéneos y de que la puesta a disposición de los puestos lleva mucho tiempo?». La solución propuesta: los Cloud Development Environments (CDE), es decir, entornos de desarrollo remotos, estandarizados y accesibles bajo demanda. En este caso, han implementado la plataforma de código abierto Coder para orquestar entornos de desarrollo alojados en Kubernetes, ofreciendo a cada desarrollador un IDE accesible a través de un navegador pero que se ejecuta en un contenedor en la nube. De este modo, se puede trabajar desde cualquier máquina, incluso una poco potente (de ahí lo de «tostadora»: basta con un PC lento para mostrar el IDE, ya que el grueso del trabajo se realiza en el lado del servidor). La charla presentó cómo crear un entorno de desarrollo en un clúster de Kubernetes utilizando Terraform y, a continuación, cómo utilizarlo desde la perspectiva del desarrollador. Se destacó la integración con IDE populares (JetBrains, VS Code), así como el hecho de que Coder es de código abierto y gratuito, lo que reduce la barrera de entrada para la experimentación.
¿Qué ventajas se han observado? : entornos homogéneos para todos los desarrolladores (se acabó el «a mí me funciona en mi máquina»), una puesta en marcha en pocos minutos en lugar de varios días para instalar y configurar un nuevo puesto, y la posibilidad de que los desarrolladores cambien de dispositivo sin interrumpir su flujo de trabajo. En términos de gobernanza, esto también permite al departamento de TI controlar el catálogo de imágenes utilizadas (versiones de entornos de ejecución, herramientas preinstaladas, etc.) y reforzar la seguridad (el código fuente permanece en la infraestructura centralizada, no en los portátiles). Pero… este modelo requiere una infraestructura en la nube potente y fiable (en este caso, un clúster K8s que puede ejecutar potencialmente decenas de entornos en paralelo), así como una adaptación de los usos (pérdida del modo sin conexión, necesidad de una buena conectividad). No obstante, para organizaciones distribuidas o en fuerte crecimiento, los CDE resultan una herramienta valiosa para estandarizar el puesto de trabajo del desarrollador y ganar en agilidad.
En resumen, ya se trate de una plataforma interna para desarrolladores completa o de un servicio específico, como los entornos de desarrollo remotos, la idea es proporcionar a los equipos un marco unificado y bien equipado que automatice las tareas repetitivas y les permita centrarse en el valor empresarial. Para un responsable de la toma de decisiones, invertir en este tipo de plataformas internas es invertir en productividad y calidad a largo plazo. Los desarrolladores satisfechos (con buenas herramientas) producen un código más fiable; los procesos estandarizados reducen los errores humanos y facilitan la incorporación de los recién llegados. La contrapartida es que hay que destinar recursos a la ingeniería de la plataforma (un equipo de herramientas, formación); un esfuerzo que se puede modular adoptando progresivamente soluciones externas listas para usar según las prioridades.
Llevar a cabo una renovación técnica sin que nos cueste (demasiado)
Cuando se habla de arquitectura resiliente y escalable, a menudo se hace referencia a una reestructuración de la aplicación en algún momento. La experiencia de Mickael Wegerich, titulada «Reestructuración técnica: la fórmula mágica para dejar de sufrir», lo demuestra. Mickael compartió la historia de la profunda reestructuración de una aplicación crítica, llevada a cabo con su equipo, y las lecciones que extrajeron para romper el ciclo infernal de las reestructuraciones repetidas. Comenzó por sentar las bases: identificar cuándo y cómo justificar una reestructuración ante las partes interesadas (responsables de la toma de decisiones, usuarios finales); un punto a menudo delicado, ya que una refactorización es costosa y no aporta nuevas funcionalidades visibles. En su caso, lograron convencer de la necesidad del proyecto demostrando que la arquitectura existente había llegado a sus límites (deuda técnica demasiado pesada, incapacidad para evolucionar) y que, a la larga, no hacer nada costaría más que refactorizar.
La «fórmula mágica» a la que se refiere el título no es una herramienta milagrosa, sino una combinación de buenos enfoques: organización, por supuesto (contar con un equipo dedicado, un plan iterativo y el apoyo de la dirección), pero también el dominio de las herramientas adecuadas y las buenas prácticas técnicas. Durante la remodelación, su equipo adoptó una filosofía ágil: dividir el proyecto en lotes sucesivos entregables en producción, con el fin de aportar valor de forma continua en lugar de un «big bang» arriesgado al final del proyecto. Por ejemplo, pudieron implementar en paralelo la nueva API mientras mantenían la antigua en funcionamiento, para luego migrar progresivamente a los usuarios a la nueva. Este patrón de estrangulamiento evitó una interrupción del servicio y permitió probar la nueva arquitectura en condiciones reales poco a poco. «Irá poco a poco» fue, de hecho, uno de los puntos destacados en la conclusión, al igual que la importancia de la monitorización a lo largo de todo el proceso para detectar regresiones o problemas de rendimiento sobre la marcha.
Hablemos de los resultados: Mickael señala que al principio «nunca estimaron realmente» la totalidad del proyecto (algo difícil en una remodelación compleja), pero al avanzar de forma incremental lograron mantener un ritmo sostenible y entregar un backend completamente nuevo en poco más de dos años. Durante este periodo, cabe destacar que tuvieron muy pocos errores en producción con el nuevo código, gracias directamente a las pruebas y a una supervisión atenta de cada componente implementado. El código heredado se pudo retirar progresivamente y, en el momento de la charla, «el código rediseñado sigue utilizándose» en producción, prueba de que la reestructuración ha alcanzado su objetivo de sostenibilidad. Por supuesto, no todo fue fácil: «es difícil tenerlo todo en cuenta», señala, reconociendo que resulta arduo conseguir que absolutamente todos los desarrolladores y partes interesadas se impliquen en el proceso con el mismo nivel de compromiso.
Además, aunque la renovación del backend haya sido un éxito, ahora le toca el turno al frontend, lo que nos recuerda que la transformación nunca termina.
Conclusiones clave: para que una refactorización tenga éxito, se necesita (1) una división inteligente de tareas y un enfoque incremental, (2) una inversión en herramientas (pruebas automatizadas, CI/CD fiable, monitorización en tiempo real) para garantizar la seguridad de cada etapa, (3) implicar a los equipos de desarrollo para que se sumen al cambio (formarles en las nuevas tecnologías, mostrarles los éxitos intermedios), y (4) aceptar que la refactorización perfecta no existe. Hay que hacer concesiones y aspirar a la mejora continua en lugar de a la perfección. La intervención de Mickael termina con una nota de optimismo: aplicando estas recetas, se puede «construir una base técnica sólida y duradera, capaz de evolucionar sin ponerlo todo en tela de juicio». En otras palabras, prevenir la próxima refactorización diseñando desde ahora arquitecturas modulares y evolutivas, e institucionalizando las buenas prácticas que evitan la acumulación de deuda técnica (revisión de código, limpieza periódica, documentación, etc.).
Para los directores de sistemas de información (DSI) y directores técnicos (CTO), esta experiencia ofrece una perspectiva valiosa: es posible abordar una remodelación ambiciosa sin contratiempos, siempre y cuando se creen las condiciones adecuadas (tiempo, herramientas, talento) y se gestione en función del valor. En lugar de esperar a que un sistema se vuelva inmanejable y luego desecharlo todo para empezar de cero, es mejor anticiparse e invertir regularmente en el mantenimiento evolutivo de la aplicación. Esto puede adoptar la forma de rediseños parciales o continuos, lo que se ajusta a la idea de la modernización continua que se promueve hoy en día. En resumen, construir la resiliencia a largo plazo de un sistema de información pasa por tomar decisiones arquitectónicas acertadas y por la capacidad de cuestionarlas periódicamente sin romperlo todo: un equilibrio delicado, pero alcanzable con método.
Resiliencia cibernética y seguridad «integrada desde el diseño» a gran escala
La resiliencia no es solo una cuestión de arquitectura de software o de infraestructura, sino también la capacidad de hacer frente a las crisis en materia de ciberseguridad. Varias ponencias han abordado la seguridad a gran escala, ya sea para hacer frente a un ataque o para gestionar la seguridad en el día a día de múltiples proyectos.
La charla de Jean-Pierre Gil y Cyril Bouissou llamó especialmente la atención al repasar un escenario de crisis muy real: «De la emergencia a la resiliencia: cómo proteger un sitio de comercio electrónico tras un ataque DDoS». Contaron cómo uno de sus clientes, un sitio de comercio electrónico, quedó repentinamente paralizado por un ataque DDoS masivo que interrumpió su actividad en línea. Caos total, imposibilidad de realizar pedidos: la pesadilla de cualquier RSSI. Entonces ayudaron a este cliente a restablecer el servicio de forma urgente mediante el despliegue de una solución anti-DDoS en la nube combinada con un WAF de alto rendimiento, capaz de analizar el tráfico en tiempo real y bloquear automáticamente las amenazas. Algunas de las tecnologías empleadas incorporan algoritmos para distinguir el tráfico legítimo del ataque (por ejemplo, a través de huellas específicas de botnets). En una diapositiva reveladora, se podía ver la composición del tráfico durante el ataque: más de 40 millones de solicitudes maliciosas recibidas en 7 minutos, de las cuales casi la totalidad fue bloqueada por el WAF, 0,7 millones atendidas por la caché CDN (Cloudflare) y solo unas 35 000 llegaron a los servidores de origen (servidores de aplicaciones), frente a los pocos miles habituales, lo que demuestra la eficacia del escudo implementado.
Extracto de la presentación de Jean-Pierre Gil y Cyril Bouissou en la que se cuantifica el impacto de un ataque DDoS a gran escala sufrido por un cliente. En 7 minutos se emitieron más de 41 millones de solicitudes, procedentes de varias redes de bots. Gracias a la rápida implementación de un WAF en la nube (acoplado a una CDN), la casi totalidad del tráfico hostil se bloqueó automáticamente (zonas naranja y gris), y solo una ínfima parte llegó a los servidores de aplicaciones (en verde).
Para que una arquitectura sea resiliente, debe integrar desde su diseño medidas de defensa en profundidad capaces de activarse rápidamente. En este caso, la presencia de un CDN/WAF marcó la diferencia entre una avería prolongada y una interrupción limitada. Los ponentes destacaron que, más allá de la respuesta técnica, también fue necesario gestionar la crisis en términos de comunicación, y que es indispensable contar con un plan de continuidad de la actividad claro (a quién alertar, qué decisiones tomar y en cuánto tiempo). A posteriori, el cliente extrajo de este incidente la importancia de probar regularmente sus mecanismos de defensa y de plantearse el «chaos engineering» (simular ataques para poner a prueba el sistema y al equipo).
La seguridad a gran escala implica también ser capaz de gestionar la multitud de vulnerabilidades potenciales presentes en decenas de programas y sus dependencias. En este sentido, la solución Dependency-Track presentada anteriormente ofrece una ayuda inestimable. Elisa Degobert recordó que «hay dos tipos de empresas: las que han sido hackeadas y las que aún no saben que lo han sido», una famosa cita de John T. Chambers. La idea es que más vale prevenir que curar: implementar un enfoque DevSecOps en el que se realice un seguimiento de cada dependencia de software conocida y se evalúe y trate cada CVE. Pero en la práctica, ante cientos de bibliotecas y una avalancha de vulnerabilidades publicadas cada mes, «es difícil saber por dónde empezar». ¿Hay que corregir prioritariamente una vulnerabilidad crítica teórica pero difícilmente explotable, o una falla menos grave pero abierta como una puerta de par en par? Es precisamente a este dilema al que Dependency-Track intenta dar respuesta. Al agregar la información sobre vulnerabilidades y cruzarla con el contexto de explotación de la aplicación, la herramienta ayuda a priorizar los esfuerzos allí donde tendrán mayor efecto. Para un responsable de seguridad de la información (RSSI), este tipo de plataforma es un aliado para gestionar la seguridad de las aplicaciones a gran escala: se pasa de una gestión artesanal de las alertas a un enfoque sistemático y mesurado, integrado además en el proceso de CI/CD.
Cabe destacar también la experiencia de Paul Pinault, quien, aunque se centró en el desarrollo en entornos blockchain, puso de relieve la presión en materia de seguridad que existe en estos ecosistemas. En dos años de desarrollo de una solución DeFi, su equipo tuvo que gestionar una base de datos de más de 10 TB, un flujo de 100 000 eventos por minuto y hacer frente a ataques habituales motivados por la codicia (incluso por unos pocos céntimos). Esto les obligó a escribir código más robusto y a implementar una vigilancia proactiva para detectar los ataques en curso y contrarrestarlos. La moraleja aquí es que, cuando la superficie de ataque se amplía (muchos datos, tráfico, servicios), hay que dotar a la infraestructura de las herramientas adecuadas (monitorización en tiempo real, alertas inteligentes, etc.) y adoptar una cultura de seguridad compartida por los desarrolladores. Aquí vuelve a aparecer el concepto de DevSecOps ya mencionado, que se vuelve imprescindible a gran escala.
Por último, más allá de las herramientas técnicas, la WAX CONF dedicó una sesión completa a la dimensión organizativa de la tecnología. Renaud Decondé, en una charla con un tono deliberadamente provocador ( «¿Sois capaces de organizar correctamente los equipos tecnológicos?» ), recordó que no hay soluciones milagrosas en materia de organización. Por mucho que se apliquen los métodos ágiles de moda, se copie el modelo «Spotify» o se acumulen los marcos de trabajo (SAFe, LeSS…), «al final nunca es sencillo», ya que la organización debe, ante todo, responder a las limitaciones propias de cada contexto. Su experiencia, forjada en grandes grupos, empresas de servicios digitales y scale-ups, sugiere algunos principios: en primer lugar, aceptar que no existe una «organización perfecta» inmutable y que «la organización también debe cambiar» tan pronto como cambien las limitaciones (crecimiento, nuevo producto, nuevas regulaciones, etc.). A continuación, dejar de creer en la pirámide ideal: por el contrario, hay que distribuir al máximo tanto la arquitectura como la organización, dejar que los «componentes» (equipos) decidan y se autoorganicen tan pronto como sea posible, ya que eso es «lo mejor». En definitiva, favorecer la autonomía y la adaptación local en lugar de imponer un organigrama rígido de arriba abajo. El mensaje para los directores de sistemas de información (DSI) y directores técnicos (CTO) es, por tanto, centrarse en el establecimiento de un marco (visión del producto, principios de arquitectura, funciones básicas) al tiempo que se mantiene la flexibilidad suficiente para que la organización se calibre por sí misma. Este concepto de equipo modulable se asemeja a la analogía con las arquitecturas modulares: al igual que una arquitectura gobernable se compone de bloques independientes bien definidos, una organización eficaz se articula en torno a equipos independientes, alineados con el producto, capaces de reconfigurar sus interacciones sin desmontarlo todo. Para la resiliencia global de la empresa, este es un factor clave: una organización demasiado rígida resistirá mal los grandes cambios (de mercado, tecnológicos), mientras que una organización ágil (en el sentido estricto del término) los soportará mejor reorganizándose rápidamente.
Hacia una arquitectura sostenible y responsable
Diseñar una arquitectura «gobernable a gran escala» implica, cada vez más, tener en cuenta indicadores medioambientales y éticos, además de los clásicos indicadores técnicos o financieros.
Así, Arthur Kuehn presentó un método sencillo en tres pasos para reducir el consumo energético de un parque de aplicaciones ya existente, aunque no se haya diseñado desde el principio siguiendo los principios de la informática ecológica. El enfoque propuesto, «Medir / Priorizar / Reducir», pretende ser «sencillo (realizable por tres desarrolladores), rápido (menos de 6 meses) y eficaz (con resultados concretos medibles)». En la práctica, consiste en primer lugar en medir la huella de sus aplicaciones (herramientas de medición del consumo de CPU, de consultas, etc., posiblemente basándose en estimadores de coste de carbono por uso de recursos en la nube). A continuación, priorizar las aplicaciones o componentes que hay que optimizar en función de su impacto y del coste/esfuerzo de corrección. Por último, reducir efectivamente este impacto mediante optimizaciones específicas (algoritmos más eficientes, infraestructura adaptada a la carga, limpieza de datos innecesarios, etc.). Esta experiencia ha demostrado que, con unos pocos desarrolladores motivados, se pueden obtener beneficios tangibles en las aplicaciones existentes sin alterar todo el sistema de información. Por ejemplo, al reducir la frecuencia de ciertas tareas que consumen mucho tiempo, se ahorra un X % de CPU, lo que al final del año se traduce en un ahorro de kWh y una reducción de la factura de la nube, al tiempo que se mejora potencialmente el rendimiento percibido.
En lo que respecta a las infraestructuras en la nube, Elise Auvray, de Scaleway, compartió los retos a los que se enfrentan a la hora de medir la huella ambiental de la nube. Recopilar datos fiables, agregar fuentes heterogéneas (consumo energético, emisiones de la fabricación de equipos, consumo de agua de los centros de datos…), elegir metodologías de análisis del ciclo de vida (ACV) adecuadas… todo ello resultó ser una tarea nada trivial. Su equipo ha desarrollado una calculadora de huella ambiental para sus infraestructuras, y uno de los mensajes fue que la medición es un requisito previo crucial para poder mejorar: solo se puede reducir lo que se consigue cuantificar. Sin embargo, hay que tener cuidado con los datos que faltan o que son engañosos: el impacto total de lo digital incluye el Alcance 3 (fabricación de equipos, fin de vida útil), que a menudo está mal documentado. Por lo tanto, su experiencia anima a los directores de sistemas de información a dotarse de herramientas de medición adecuadas y a contribuir a mejorar la calidad de los datos medioambientales.
Yendo un paso más allá en la automatización, Guillaume Michalag presentó CloudAssess, una solución de código abierto desarrollada junto con varios socios, cuyo objetivo es automatizar de principio a fin el análisis del ciclo de vida (ACV) de los servicios en la nube. En lugar de realizar estos análisis manualmente (un procedimiento lento y puntual poco adecuado para la dinámica de la nube), CloudAssess propone un enfoque «LCA as Code» en el que se modelan los cálculos de impacto y se integran directamente en los flujos de trabajo. Se basan en normas (ISO 14000) y prestan especial atención a la calidad de los datos medioambientales, utilizando, por ejemplo, ResilioDB para reconstruir datos coherentes «desde los primeros principios» cuando faltan los datos de los proveedores. Aunque se trata de un tema especializado, se vislumbran las herramientas del futuro para los responsables de RSE y los arquitectos de la nube preocupados por el cumplimiento normativo (la directiva europea CSRD exigirá a partir de 2025 informes extrafinancieros precisos). El mensaje estratégico es que la gobernanza a gran escala incluirá cada vez más estas métricas de sostenibilidad: habrá que equipar nuestras plataformas para hacer un seguimiento de la huella de carbono, del mismo modo que ya se hace con los costes y el rendimiento.
Por último, más allá de la ecología, la dimensión ética y de responsabilidad integra al ser humano en la tecnología. En este sentido, el dúo formado por Magali de Labareyre y Laurent Grangeau aportó una perspectiva sobre el uso de la IA en la contratación en el sector tecnológico, analizando tanto la «combinación perfecta» como el «juego del escondite» con los sesgos. Si bien la IA promete una contratación más eficaz (análisis rápido de CV, entrevistas en vídeo automatizadas), también conlleva el riesgo de reproducir o incluso amplificar los sesgos discriminatorios. Para los directores de sistemas de información y de recursos humanos, el reto consistirá en conciliar la aportación de estas nuevas tecnologías con una gobernanza que garantice la equidad y la transparencia. Este tema, aunque periférico a las arquitecturas de TI, nos recuerda que la automatización a gran escala no es solo un reto técnico, sino también social.
Recomendaciones estratégicas
Esta jornada, centrada en experiencias prácticas, nos ofrece una visión general de las buenas prácticas para crear y desarrollar arquitecturas estandarizadas, automatizadas, resilientes y gestionables a gran escala. Dirigida a los responsables de la toma de decisiones (directores de sistemas de información, directores técnicos y responsables de seguridad de la información), estos son los principales ejes que se desprenden de la WAX CONF 2025:
Industrialice y unifique sus bases tecnológicas: ya se trate del despliegue de infraestructuras (clústeres de Kubernetes, entornos en la nube) o de los pipelines de CI/CD, invierta en «Infrastructure as Code» y en enfoques declarativos (GitOps, operadores) para gestionar su sistema de información como un conjunto coherente en lugar de como una colección dispar. Iniciativas como la plataforma Placide en una gran empresa demuestran que una forja de software común puede dar soporte a cientos de proyectos al tiempo que mejora la fiabilidad global. Esta estandarización facilitará la gobernanza (métricas uniformes, cumplimiento centralizado) y la resiliencia (capacidad para replicar o reconstruir rápidamente en caso de necesidad).
- Apueste por las plataformas internas y la automatización del ciclo de desarrollo: la competencia por atraer y retener el talento informático también se decide en función de la calidad de las herramientas que se proporcionan internamente. Una plataforma de desarrollo interna bien diseñada, o incluso servicios específicos como entornos de desarrollo en la nube, proporcionarán a sus equipos los medios para ser más eficaces y coherentes. Esto reduce el tiempo de incorporación de los nuevos desarrolladores, estandariza las prácticas de implementación y limita los errores humanos. Como han demostrado varias experiencias, es posible apoyarse en soluciones de código abierto maduras (Backstage, ArgoCD, Terraform, etc.) para construir progresivamente esta capa de plataforma en lugar de codificarlo todo desde cero. Lo importante es empezar por las necesidades más acuciantes de los desarrolladores (tiempo de configuración, disparidades entre entornos) y aportarles una respuesta automatizada.
- Adopta una cultura de DevSecOps y SRE a gran escala: la seguridad y la fiabilidad deben tratarse como cuestiones prioritarias desde el diseño y a lo largo de todo el ciclo de vida. Esto implica integrar herramientas como Dependency-Track en tus procesos para dar prioridad al tratamiento de las vulnerabilidades, automatizar las pruebas de seguridad y sensibilizar continuamente a los equipos. Del mismo modo, adopte las prácticas de SRE (medición de SLO, formación en gestión de incidentes, implementaciones automatizadas y progresivas) no solo en uno o dos proyectos piloto, sino haciéndolas sistémicas. Como ponía de relieve la experiencia de Placide, difundir esta cultura a escala de cientos de equipos es un reto tanto humano como técnico. Para ello se necesita liderazgo (evangelistas internos, formadores) y retroalimentación concreta que demuestre el valor (tiempo de resolución de incidentes reducido gracias a SRE, incidentes de seguridad evitados gracias a DevSecOps, etc.).
- Prepárate para las crisis fomentando la resiliencia: como han puesto de manifiesto los testimonios sobre el ataque DDoS, una arquitectura solo es resiliente si está preparada para hacer frente a los peores escenarios. En la práctica, esto implica integrar soluciones robustas desde el principio (WAF, CDN, planes de recuperación automatizados) y probar regularmente estos mecanismos (pruebas de carga, simulaciones de ataques) para asegurarse de que funcionen cuando llegue el momento. Invertir en resiliencia es evitar pérdidas colosales más adelante; un mensaje que también debe entenderse a nivel de la dirección general, ya que está en juego la continuidad del negocio.
- Fomenta la evolución continua en lugar de las reestructuraciones forzadas: la experiencia con las reestructuraciones exitosas nos enseña que es mejor adoptar una lógica de mejora continua de la arquitectura que esperar a que se acumule una deuda técnica inmanejable. En la práctica, reserva tiempo en tus hojas de ruta para proyectos técnicos periódicos, aunque sean de pequeña envergadura. Fomente una arquitectura modular que permita sustituir un componente sin tener que reescribirlo todo. Y si una reestructuración masiva es inevitable, aplique los principios mencionados anteriormente (iteración, herramientas avanzadas, monitorización, etc.) para reducir los riesgos. El objetivo es minimizar el impacto del cambio tanto para los equipos como para los usuarios finales, haciendo que el sistema evolucione en pequeños incrementos.
- Incorpore consideraciones sostenibles y éticas en sus decisiones: la gobernanza a gran escala implica ahora rendir cuentas sobre el impacto ambiental y social del sistema de información. Empiece a medir algunos indicadores (consumo energético de las aplicaciones, huella de carbono de la nube, diversidad en los equipos…) y fíjese objetivos de mejora. Están surgiendo herramientas para automatizar estos seguimientos, y la normativa se va a endurecer (taxonomía verde de la UE, CSRD, etc.). El director de sistemas de información del futuro deberá ser tan capaz de hablar de eficiencia de carbono como de SLA. Del mismo modo, manténgase atento al uso ético de las nuevas tecnologías (como la IA) en sus procesos: ofrecen ganancias de productividad (revisión de código automatizada con IA, asistentes de codificación a medida), pero plantean cuestiones de gobernanza (sesgos, confidencialidad) que deben abordarse mediante normas claras y transparencia.
- Por último, preste tanta atención a la organización humana como a la arquitectura técnica: como hemos visto, no hay una fórmula mágica, pero sí se perfilan algunos principios rectores. Descentralice las decisiones lo antes posible, acercándolas a los equipos, y asigne a estos la responsabilidad sobre sus productos (modo «product team»), al tiempo que se establece una visión y unas restricciones claras a nivel central (seguridad, cumplimiento normativo, objetivos empresariales). Una organización capaz de reorganizarse rápidamente estará más capacitada para aprovechar la automatización y hacer evolucionar sus arquitecturas. Por el contrario, las estructuras demasiado rígidas corren el riesgo de frenar o anular las ventajas que podrían aportar sus nuevas plataformas o herramientas. En resumen, arquitectura modular + organización ágil = dúo ganador para escalar con tranquilidad.
Para concluir, la WAX CONF 2025 ha demostrado que la comunidad tecnológica está repleta de soluciones ingeniosas para hacer frente a los retos de la escalabilidad y la resiliencia. Estandarizar y automatizar no significa deshumanizar ni frenar la creatividad; al contrario, libera tiempo y energía para innovar allí donde el ser humano aporta mayor valor añadido, dejando que las máquinas y el código se encarguen del resto. Corresponde a los directores de sistemas de información (DSI) y a los responsables de seguridad de los sistemas de información (RSSI) aprovechar estas experiencias, adaptarlas a su contexto y tomar desde hoy mismo las decisiones estructurales (herramientas, organización, cultura) que prepararán sus sistemas de información para los retos del mañana.
En resumen: «Automatiza todo lo que se pueda automatizar, estandariza todo lo que se deba estandarizar, y estarás listo para evolucionar con total control».
Lionel GAIROARD
Responsable de la práctica de DevSecOps
