Radar Tecnoic #2026.36

Hola,

Hay tecnologías que notamos constantemente porque tenemos que abrirlas, pulsarlas o configurarlas. Y hay otras que solo recordamos que existen cuando dejan de funcionar.

Esta semana hemos tenido un buen ejemplo. ChatGPT, Claude y Grok sufrieron el 3 de septiembre varias interrupciones que coincidieron durante unas horas. No hubo una gran avería común que explicara todo: los incidentes conocidos apuntan a problemas diferentes. Pero esa coincidencia permitió ver algo bastante más interesante que una simple caída de servicio.

Durante mucho tiempo podíamos considerar un asistente de IA una herramienta más. Si no funcionaba, esperábamos un rato. Eso empieza a cambiar. Como hemos analizado al explicar qué ocurrió cuando ChatGPT, Claude y Grok se cayeron casi al mismo tiempo, estos sistemas ya están entrando en programación, documentación, atención al cliente, análisis de información y automatizaciones conectadas mediante API. Cuando eso ocurre, la disponibilidad deja de ser una característica secundaria.

Y ahí aparece precisamente el hilo que ha recorrido buena parte de Tecnoic esta semana.

Debajo de una aplicación aparentemente sencilla existe una pila enorme de infraestructura. Redes, balanceadores, bases de datos, almacenamiento, sistemas de autenticación, servidores, aceleradores, contenedores y servicios distribuidos tienen que funcionar correctamente para que al otro lado aparezca una respuesta en unos segundos.

Por eso hemos dedicado estos días a bajar varios niveles dentro de esa pila. Al repasar cómo funcionan la computación distribuida y los modelos IaaS, PaaS y SaaS, la distinción importante no está solo en dónde se ejecutan las cosas, sino en quién controla cada capa y quién asume la responsabilidad cuando algo falla. Cuanto más avanzamos hacia servicios completamente gestionados, menos infraestructura tenemos que operar, pero también dependemos más de decisiones y sistemas que están fuera de nuestro control.

Eso no convierte al cloud en una mala elección. Todo lo contrario. La elasticidad, automatización y capacidad de desplegar servicios sin construir un centro de datos propio explican buena parte del software que utilizamos actualmente. Pero externalizar una capa tecnológica no significa externalizar también nuestra responsabilidad sobre disponibilidad, seguridad, datos o continuidad de negocio.

La misma lógica aparece al observar la evolución desde los servidores y las máquinas virtuales hasta los contenedores, microservicios y serverless. Cada salto introduce nuevas abstracciones. Las VM separan el software del hardware físico; los contenedores aíslan aplicaciones compartiendo el kernel; los microservicios dividen sistemas complejos; y serverless permite ejecutar funciones sin administrar directamente los servidores.

Abstraer simplifica unas cosas, pero inevitablemente hace más complejas otras. Un microservicio puede escalar de forma independiente, por ejemplo, pero obliga a pensar en comunicaciones, observabilidad, consistencia y fallos parciales. Precisamente por eso no siempre la arquitectura técnicamente más sofisticada es la mejor.

También lo hemos visto desde el lado del desarrollo. El recorrido por .NET como plataforma para aplicaciones empresariales muestra cómo hoy lenguaje, runtime, APIs, acceso a datos, contenedores, cloud, telemetría y despliegue forman parte de un mismo ciclo de vida. Incluso aquí aparece una advertencia útil: utilizar microservicios por defecto no hace automáticamente mejor una aplicación; a veces un buen monolito modular es más fácil de desarrollar, desplegar y mantener.

Pero la infraestructura no sirve únicamente para ejecutar aplicaciones. También puede convertirse en una línea de defensa.

España empezará a demostrarlo el 15 de septiembre. Desde ese día, los operadores deberán comprobar los alias utilizados como remitentes en SMS, MMS y RCS y bloquear determinados mensajes cuando el nombre empleado no esté correctamente registrado o autorizado. Es decir, en lugar de pedir únicamente al usuario que aprenda a reconocer cada fraude, el nuevo sistema contra la suplantación de bancos, empresas y administraciones introduce el control dentro de la propia infraestructura de telecomunicaciones.

No acabará con el smishing. Los delincuentes pueden cambiar de números, dominios, canales o técnicas. Pero el enfoque resulta interesante: eliminar en la red una posibilidad de engaño antes de que el mensaje llegue siquiera al teléfono.

Y quizá esa sea la mejor forma de resumir la semana.

Cuanto más invisible se vuelve la tecnología, más importantes son las decisiones que hay debajo. Qué ocurre si un proveedor no responde. Qué capas controlamos. Dónde colocamos la seguridad. Cómo recuperamos un servicio. Qué dependencias hemos introducido sin darnos cuenta.

La próxima gran diferencia entre dos sistemas tecnológicos quizá no esté en cuál tiene más funciones, sino en cuál sigue funcionando razonablemente bien cuando inevitablemente algo sale mal.

Hasta la próxima semana.