Jordi Costa Mur

Jordi Costa Mur

Ingeniero Informático por la Universidad Politécnica de Catalunya y MBA por ESADE.

Mi trayectoria profesional está ligada al desarrollo de productos y servicios Cloud, combinando tecnología y negocio para ayudar a empresas y administraciones públicas a adoptar la nube de forma segura, eficiente y sostenible. Me interesan especialmente la soberanía digital y la innovación alrededor de las tecnologías cloud-native.

Y cuando el mundo cloud lo permite, me gusta disfrutar de varias aficiones como el motociclismo, el running o el buceo.

Cloud
Los tres cerditos y la adopción de Cloud pública: del simple uso de un portal a la infraestructura como código
El cuento de los tres cerditos relata cómo tres hermanos construyen sus viviendas utilizando materiales diferentes. El primero levanta rápidamente una casa de paja; el segundo elige la madera, algo más resistente; y el tercero dedica más tiempo y esfuerzo a construir una casa de ladrillo. Cuando aparece el lobo, sopla con fuerza y derriba las dos primeras viviendas. La casa de ladrillo, en cambio, resiste y ofrece refugio frente a la amenaza. Esta conocida fábula permite ilustrar, de forma sencilla, tres maneras de abordar la adopción de servicios de Cloud pública. Las organizaciones pueden desplegar recursos directamente desde el portal del hiperescalar, incorporar automatizaciones mediante las API o avanzar hacia un modelo de infraestructura como código. Las tres alternativas permiten construir, pero no ofrecen el mismo grado de consistencia, agilidad y capacidad de recuperación cuando el entorno se enfrenta a una situación adversa. En Cloud pública, la rapidez con la que se construye un entorno no determina por sí sola su capacidad para resistir, recuperarse y evolucionar. La casa de paja: adopción básica mediante el portal El primer cerdito representa el modelo de adopción más inmediato y básico: la creación y configuración de recursos a través del portal web del proveedor de Cloud pública. Esta aproximación permite comenzar rápidamente, facilita el aprendizaje y resulta útil para pruebas de concepto, laboratorios o necesidades puntuales. En pocos minutos es posible desplegar capacidad de cómputo, almacenamiento, redes o bases de datos sin desarrollar previamente procesos de automatización. En este escenario, el valor de la Cloud pública puede quedar limitado si no existe una estrategia de gobierno, automatización y control de costes, e incluso pueden aparecer entornos que generan más coste que una solución on-premise bien dimensionada. Sin embargo, cuando el número de recursos, equipos o entornos aumenta, la operación manual comienza a mostrar sus limitaciones. Las configuraciones pueden variar entre desarrollo, pruebas y producción; resulta más difícil reconstruir exactamente un entorno; y parte del conocimiento queda asociado a las personas que realizaron cada cambio. La ausencia de un proceso versionado también complica la revisión, la aprobación y la trazabilidad de las modificaciones. ■ Como la casa de paja, este modelo puede cumplir adecuadamente una finalidad concreta, pero ofrece una protección limitada cuando debe soportar escala, presión operativa o una recuperación urgente. La casa de madera: portal y automatizaciones mediante las API El segundo cerdito representa una adopción más avanzada. La empresa continúa utilizando el portal para determinadas tareas, pero incorpora scripts, APIs y otras automatizaciones para ejecutar operaciones frecuentes. El aprovisionamiento gana velocidad y parte de los procedimientos comienza a ser repetible. También disminuye la intervención manual en tareas rutinarias y se reducen algunos errores asociados a la ejecución individual. En este punto, empezamos a obtener un valor más significativo del proveedor Cloud. La casa de madera es más sólida, aunque conserva puntos débiles. Las automatizaciones pueden haberse creado en momentos diferentes y con criterios distintos, o depender de conocimientos que no están suficientemente documentados. Además, un conjunto de scripts que ejecuta acciones no siempre describe de forma completa el estado que debería tener la infraestructura. Esto puede generar divergencias entre lo previsto y lo realmente desplegado. ■ Este modelo constituye una evolución relevante y, en muchas organizaciones, una etapa necesaria. No obstante, la automatización parcial no equivale todavía a disponer de un sistema integral para diseñar, desplegar, validar y recuperar la infraestructura de manera consistente. La casa de ladrillo: infraestructura como código El tercer cerdito representa la adopción basada en infraestructura como código, o Infrastructure as Code (IaC). En este modelo, los componentes de infraestructura se definen mediante archivos declarativos o plantillas que pueden almacenarse en repositorios, someterse a control de versiones y desplegarse a través de procesos automatizados. Este enfoque permite conocer qué configuración se ha aprobado, revisar los cambios antes de aplicarlos y reproducir entornos con mayor consistencia. También facilita la integración con pipelines, controles de seguridad, políticas corporativas y mecanismos de validación. Ante la necesidad de reconstruir un entorno o desplegarlo en otra región, la empresa dispone de una definición reutilizable, en lugar de depender exclusivamente de una secuencia manual difícil de repetir. ■ La casa de ladrillo requiere más planificación y más esfuerzos iniciales, pero permite capturar de forma mucho más completa las ventajas de la Cloud pública. Es necesario definir estándares, estructurar repositorios, diseñar módulos reutilizables y establecer responsabilidades. Además, la infraestructura como código no garantiza por sí sola una arquitectura segura: una configuración incorrecta también puede automatizarse y propagarse con gran rapidez. La solidez procede de combinar código, arquitectura, gobierno, seguridad y disciplina operativa. El lobo: las amenazas que ponen a prueba la construcción En el entorno empresarial, el lobo no representa una única amenaza. Puede ser un atacante que compromete credenciales o cifra información; un desastre natural que afecta a una ubicación; un error humano que elimina o modifica un recurso crítico; una avería generalizada; una actualización defectuosa; o un incremento inesperado de la demanda. También puede adoptar formas menos evidentes, como una auditoría, un nuevo requisito regulatorio o la salida de una persona que concentraba conocimiento esencial. Cuando se produce cualquiera de estas situaciones, la diferencia entre los modelos se hace visible. No basta con disponer de copias de seguridad: es necesario conocer cómo estaba construido el entorno, reproducir su configuración, aplicar controles y recuperar el servicio dentro de los objetivos definidos. Cuanto mayor es la dependencia de acciones manuales y conocimiento no documentado, mayor puede ser la incertidumbre durante la respuesta. La verdadera madurez Cloud se observa cuando la organización puede responder a un incidente con procesos conocidos, configuraciones trazables y entornos reproducibles. Construir una adopción resiliente pensando en el día que puede llegar el lobo Evolucionar desde el consumo de Cloud pública utilizando solamente sus portales hacia la infraestructura como código no consiste únicamente en implantar una herramienta. Requiere analizar las necesidades del negocio, diseñar la arquitectura objetivo y establecer una base común para identidad, conectividad, seguridad, observabilidad, gobierno y control de costes. También implica integrar la automatización en el ciclo de vida operativo y formar a los equipos que mantendrán el entorno. Los diferentes modelos de adopción Cloud no son opciones necesariamente excluyentes. Pueden convivir y responder a necesidades diferentes. La clave está en comprender qué función cumple cada modelo y qué nivel de exposición puede asumir la empresa. Porque el objetivo no es construir siempre la casa más sofisticada, sino asegurarse de que los servicios importantes continúen en pie cuando aparezcan un ciberataque, un desastre, un error humano o cualquier otro lobo inesperado. La facilidad de acceso es una de las grandes ventajas de la Cloud pública, pero también puede generar una falsa sensación de solidez. Crear recursos es sencillo; construir una plataforma gobernada, segura, repetible y preparada para recuperarse exige un enfoque más amplio. Ahí es donde un buen partner, con capacidades de Servicios Profesionales de adopción cloud, puede ayudar a transformar el uso puntual de servicios Cloud en una plataforma robusta y sostenible. ■ Los Servicios Profesionales de Cloud aportan experiencia especializada para acompañar esta evolución: desde el diseño de landing zones, la definición de patrones y módulos reutilizables y la implantación de pipelines, hasta la incorporación de seguridad y cumplimiento desde el diseño y la preparación de mecanismos de continuidad y recuperación. ______ Telefónica Tech Ciberseguridad Cloud Evaluación de proveedores Cloud 'quantum-readiness': marco de auditoría y cuestionario técnico 30 de abril de 2026
8 de septiembre de 2026