Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe: Autoscaling Inteligente y Eficiencia en GPU

La Inteligencia Artificial no se detiene, y su adopción en producción tampoco, pero hay una brecha silenciosa entre entrenar un modelo y servirlo de forma eficiente, escalable y mantenible. Aquí es donde Kubernetes se convierte en el aliado perfecto, y donde herramientas como KServe (el sucesor de KFServing) brillan.

Figura 1: Cómo servir modelos de ML e IA (LLMs) en Kubernetes con KServe.

Autoscaling Inteligente y Eficiencia en GPU

En este artículo te cuento cómo puedes montar una plataforma moderna para servir modelos de IA y LLMs sobre Kubernetes, aprovechar las novedades más recientes de KServe, y hacer que tu infraestructura escale según uso real y consumo de GPU. 

Figura 2: Arquitectura de KServe

Spoiler: sí, se puede tener eficiencia, velocidad y buena arquitectura al mismo tiempo.

¿Por qué servir modelos sobre Kubernetes?

Entrenar un modelo es sólo la mitad del camino. Lo difícil viene después: ponerlo a funcionar en producción de forma fiable, segura y escalable.

• Alta disponibilidad
• Autoescalado según carga real
• Seguridad, versionado, observabilidad
• Integración con pipelines CI/CD y orquestadores como Argo Workflows o Kubeflow

Kubernetes permite todo esto. Pero no hay que reinventar la rueda, y ahí entra KServe.

Antes de continuar… ¿Qué es Kubeflow y qué ofrece?

Kubeflow es una plataforma Open Source pensada para desplegar, escalar y gestionar flujos de trabajo de Machine Learning (ML) sobre Kubernetes. Su objetivo principal es llevar el desarrollo de modelos de ML a producción de forma reproducible, escalable y portátil.

Figura 3: Componentes de Kubeflow

Kubeflow no es una herramienta única, sino un conjunto de componentes modulares que cubren distintas etapas del ciclo de vida del modelo de Machine Learning:

• Kubeflow Pipelines: Orquestación de pipelines de ML (entrenamiento, preprocesado, validación, etcétera).

• Katib: AutoML y búsqueda de hiperparámetros.

• KServe (antes KFServing): Serving de modelos con escalado automático y despliegues sin downtime.

• Notebook Servers: Entornos Jupyter en Kubernetes, listos para trabajar con datos y modelos.

• Central Dashboard y Profiles: Gestión multiusuario, RBAC, y control de recursos por equipo o proyecto.

Kubeflow se posiciona como una plataforma completa para MLops sobre Kubernetes, especialmente útil cuando necesitas estandarizar y automatizar todo el flujo de trabajo desde el desarrollo hasta el despliegue.

Figura 4: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

Aunque KServe puede funcionar por separado de Kubeflow, se integra perfectamente como pieza de serving dentro del stack Kubeflow.

KServe: servir modelos como si fueran microservicios

KServe es un componente de Kubeflow, pero puede usarse de forma independiente. Te permite desplegar modelos como recursos de Kubernetes (CRDs), exponiéndose vía REST o gRPC, con soporte para, entre otros, PyTorch, TensorFlow, XGBoost, SKLearn, ONNX etc... e incluso tus propios contenedores.

• Lo bueno: cada modelo es un InferenceService, y tú defines lo que necesita: CPU, GPU, versiones, etcétera.

• Lo brutal: KServe soporta escalado automático hasta cero réplicas, y las vuelve a levantar cuando hay tráfico. Nada de infra desperdiciada.

GPU autoscaling

• Puedes escalar vertical y horizontalmente tus modelos en GPU.
• Mediante Prometheus Adapter + HPA Custom Metrics, se puede escalar según uso de memoria GPU, uso de batch o incluso peticiones por segundo.

Raw Deployment mode

• 1.- KServe por defecto usa Knative para autoescalar.
• Escala basándose en tráfico HTTP (requests por segundo).

• Esto no es suficiente cuando usas GPUs, ya que estas no se liberan con tráfico bajo.

• Además, los workloads con GPU suelen tener procesamiento batch o tiempos largos de inferencia, donde Knative no escala de forma óptima.

• 2.- Para modelos en GPU, muchas veces no se usa Knative, sino raw deployment mode en KServe, para tener más control.
• Aquí ya no dependes de Knative, sino de un Deployment + HPA.

Figura 5: Arquitectura para servir modelos

• 3.- Prometheus Adapter + HPA con métricas personalizadas
• Prometheus Adapter permite exponer métricas personalizadas (por ejemplo: uso de memoria GPU, utilización del device, número de peticiones, etc.) como Custom Metrics API.

• Con eso puedes configurar un HPA (Horizontal Pod Autoscaler) para escalar los pods de inferencia según esas métricas.

• Esto se usa en entornos donde se necesita un autoscaling más inteligente y específico, especialmente con GPU.

Scale down a cero

¿Qué significa “scale down a cero” en KServe?

• Es la capacidad de escalar a cero réplicas un modelo cuando no está recibiendo peticiones, y volver a levantarlo automáticamente (auto-scale up) cuando llega una nueva petición.

¿Qué beneficios tiene esta solución?

• Ahorro de costes brutal: Si tienes muchos modelos desplegados pero no todos se usan constantemente, con scale-to-zero no malgastas CPU ni RAM. Ideal en entornos cloud donde pagas por uso de recursos, como en clusters gestionados (EKS, GKE, AKS…).

• Optimización de recursos en el cluster: En vez de mantener todos los pods activos, los que no reciben tráfico se eliminan temporalmente, dejando espacio a otros workloads que sí lo necesitan. Ayuda a evitar sobrecargas y reduce la necesidad de sobredimensionar el cluster.

• Despliegue eficiente de muchos modelos: Puedes permitir que muchos equipos o usuarios publiquen sus propios modelos sin saturar el sistema. Esto habilita patrones como “multi-tenancy” eficiente para inferencias bajo demanda.

• Escalado bajo demanda: Si un modelo recibe tráfico repentino, KServe lo activa rápidamente. Esto es perfecto para modelos que solo se usan de vez en cuando o que funcionan como microservicios ML reactivos.

Canary rollout

KServe soporta dividir tráfico entre versiones de modelo (v1, v2, etcétera). Por ejemplo puedes hacer un 90/10, observar métricas y logs, y luego promover o descartar la nueva versión. Pero… ¿qué es Canary rollout? 

Figura 6: Canary Rollout

El Canary rollout te permite probar una nueva versión de un modelo (por ejemplo v2) con una pequeña parte del tráfico real, mientras que la versión estable (v1) sigue sirviendo la mayoría del tráfico. Esto es clave para:

• Validar rendimiento y exactitud del modelo en producción.
• Detectar errores o regresiones antes de hacer el cambio completo.
• Observar métricas y logs reales sin impactar a todos los usuarios.

Ejemplo de Canary rollout en KServe

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
 name: sklearn-iris
 namespace: kserve-test
spec:
 predictor:
   model:
     modelFormat:
       name: sklearn
     storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-1"
   canaryTrafficPercent: 10
   canary:
     model:
       modelFormat:
         name: sklearn
       storageUri: "gs://kfserving-examples/models/sklearn/1.0/model-2"

• storageUri: del bloque principal. Apunta a model-1, la versión actual y estable del modelo.
• canary: Define model-2 como la nueva versión que se quiere probar.
• canaryTrafficPercent: 10: indica que el 10% del tráfico entrante será dirigido a model-2, mientras que el 90% restante seguirá siendo servido por model-1.

Novedades destacadas

Desde la versión v0.15.0, KServe ha incorporado mejoras significativas para el despliegue de modelos de lenguaje (LLMs), incluyendo soporte distribuido con vLLM, mejoras en el runtime de Hugging Face y optimizaciones para almacenamiento y readiness. Esto abre la puerta a escenarios como:

• Servir un modelo LLaMA o Falcon en múltiples nodos GPU.

• Integrar modelos de Hugging Face con pipelines existentes y autoscaling por demanda.

• Aprovechar técnicas avanzadas como RAG o agentes con herramientas directamente desde Kubernetes.

Si antes KServe era ideal para modelos tradicionales de Machine Learning, ahora también lo es para los modelos de última generación. 

Algunas otras funcionalidades adicionales:

• Soporte para descarga de archivos individuales desde GCS Google Cloud Storage), lo que mejora los tiempos de inicio.

• Readiness probes más precisas, especialmente para modelos en transformers, mejorando la confiabilidad de despliegues en producción.

• Introducción de “KServe Guru” en Gurubase.io, un espacio para encontrar y compartir soluciones de la comunidad.

Arquitectura tipo: Cómo lo montamos

Una plataforma de inferencia moderna sobre Kubernetes podría verse así:

• KServe + Istio: para gestión de modelos como microservicios.

• Knative Serving: para escalado a 0, cold start optimizado.

• Prometheus + Grafana: para métricas personalizadas de GPU o latencia.

• Cert-Manager + Ingress Gateway: TLS automático para exposición segura.

• ArgoCD o Flux: GitOps para definir modelos como código.

• GPU Operator de NVIDIA: para gestionar drivers y nodos GPU

¿Y si no quieres montar todo esto desde cero?

Aunque herramientas como KServe y Kubeflow son muy potentes, su configuración desde cero puede requerir tiempo, conocimientos avanzados de Kubernetes y una buena integración con infraestructura cloud o on-prem. Aquí es donde entran plataformas como Axebow.io, que están diseñadas para facilitar el despliegue de aplicaciones, entornos de Machine Learning e IA y plataformas completas sobre Kubernetes. Esto permite que equipos de IA y Data Science se enfoquen en desarrollar y servir modelos sin preocuparse por los detalles de infraestructura.

Figura 7: Puedes probar Axebow sin coste

Axebow.io proporciona configuraciones optimizadas para rendimiento, autoscaling con GPU y despliegues reproducibles, lo que reduce la complejidad operativa y acelera el time-to-production. Si estás interesado en saber más, contacta con nosotros.

Autores: Miguel Angel Chuecos /  Carlos García Blanco, CEO de Kumori

Contactar con Carlos García Blanco

"Login with your Phone Number" o cómo innovar a nivel de toda una industria con OpenGateway

Hoy estamos en los ensayos todo el equipo de Telefónica preparando las charlas y presentaciones. Yo aún tengo que rematar las presentaciones, que es al final el último detalle antes de llegar al momento de contarlo. Pero antes de todo esto, se han estado acelerando los trabajos, que en nuestra unidad hacemos tecnología, y son muchos meses antes lo que llevamos trabajando en proyectos. 

Figura 1: "Login with your Phone Number" o

cómo innovar a nivel de toda una industria

con Open Gateway

De algunos de los que voy a hablar mañana ya hemos contado información pública, como la integración de OpenGateway con Google para hacer "Login with Phone Number", o algunos otros que han salido como el lanzamiento OpenGateway en UK o el proyecto con Microsoft para acelerar la adopción de OpenGateway, y por eso os voy a dejar algo de info hoy para que no se mezcle con el ruido de mañana.

Figura 2: Lanzamiento de OpenGateway en UK

Como sabéis, OpenGateway es una iniciativa de la GSMA que esta transformando nuestra industria de telecomunicaciones. Es un proyecto maravilloso que necesita de cooperación internacional, de alineamientos de puesta en producción en múltiples operadores, y de cambios tecnológicos en las infraestructuras de todas las empresas de telecomunicaciones. Tuvimos el debate en el año 2022 y en el año 2023 anunciamos la firma de un acuerdo las primeras "Telcos", en aquel momento apenas diez, que comenzamos a trabajar no sólo en estar "ready" nosotros, sino de ir subiendo al proyecto a más países y más compañías.

Figura 3: OpenGateway en el mundo

Esta semana la GSMA ha anunciado uno de los mercados más importantes, como es el mercado de UK, pero la expansión de este proyecto por todo el mundo ha sido brutal, y ya son más de 280 empresas de telecomunicaciones las que estamos ofreciendo APIs CAMARA de la Linux Foundation estandarizadas en 28 mercados. Lo que supone más del 80 % del mercado. No os olvidéis que el tamaño de esta industria no tiene comparación con casi ningún servicio digital. Son 12 Billones de conexiones móviles las que tenemos hoy en día en nuestras redes - con identificadores únicos federados por todo el mundo - y sólo en 5G, Europa ha alcanzado a finales de 2024 la cifra de 200 Millones de conexiones. Y al mismo tiempo lo APIficamos, para que no nos aburramos.

Figura 4: Si visitas La Cabina puedes ver funcionando

la 4ª Plataforma en tiempo real en Telefónica de España.

Esta info es similar a la de Alemania, Brasil o UK, por ejemplo.

Nosotros, que comenzamos nuestro camino hace tiempo, tenemos todo en nuestro Kernel, donde servimos todas las APIs de servicios digitales, y por supuesto las de OpenGateway. El año pasado fueron 33Billones de API-Calls que se ejecutaron sobre nuestras redes y sistemas, donde - como somos "API first" y "One-Line of Code" - tenemos 184 de nuestras capacidades, así que este año hemos estado haciendo muchas cosas, con muchos clientes, que si eres de los que te informas en los canales correctos habrás podido ver ya, pero que os voy a ir contando, que son parte de mis charlas de esta semana.

Kernel como plataforma OG en Microsoft Azure

Como nuestro Kernel - antiguamente llamado 4ª Plataforma - es algo que tienen que tener todas las empresas que deseen publicar APIs de servicios digitales, con Microsoft anunciamos una co-inversión para crear un equipo de innovación con ingenieros para llevar nuestro Kernel al marketplace de Azure y que cualquier empresa lo pueda utilizar en sus sistemas. 

Figura 5: Telefónica y Microsoft amplían su colaboración para acelerar la adopción de Open Gateway en la industria a través del uso de Kernel

Para ello, vamos a migrar nuestro Kernel - que está en continua evolución - a las nuevas capacidades de Data Fabric de Microsoft, y ponerlo a disposición para que cualquier empresa lo pueda licenciar y usar en sus sistemas. Una "4P-as-a-Product". Con esto, cualquier empresa que quiera servir APIs OpenGateway lo va a poder hacer en Microsoft Azure fácilmente.

Login with Phone Number en Google Firebase

También hemos trabajo con los equipos de Google para poner las APIs de OpenGateway en sus componentes de desarrollo, y en concreto hemos puesto la capacidad de usar el API CAMARA de Number Verification en Google Firebase para que cualquier usuario pueda hacer "Login with your Phone Number" y sacar el máximo poder esa plataforma de identidad de 12 Billones por todo el mundo. Al final, en todos los servicios digitales o se usa el número de teléfono como "Login" o como forma de "Recuperar contraseña", así que el API de OpenGateway de Number Verification es para no pensárselo.

Figura 6: "Benefits for users, developers, and CSPs alike"

Al final, entre enviar un SMS/WhatsApp/Telegram/e-mail con un OTP para hacer login o para recuperar la contraseña, y no tener que enviarlo porque se usa el API de OpenGateway de Number Verification hay un salto enorme en varios aspectos. Uno de ellos, por supuesto, en seguridad, ya que no hay interacción humana que pueda ser engañado para dar el OTP a alguien, pero también en usabilidad, como dice el equipo de Google.

Cabify: O cómo hacer mejor sus servicios con OpenGateway

Por eso, los equipos de servicios digitales potentes están trabajando con nosotros desde hace tiempo para integrarlo en modo "One single line of code" en sus servicios. Uno de ellos es Cabify, que va a estar dando una charla el martes de cómo lo han integrado con el código delante, y que yo voy a contar mañana. Pero lo más importante es la experiencia. 

Figura 7: En el Talent Arena y la DevCON

Fijaos cómo cambia entre usar un SMS-OTP o con OpenGateway, en el vídeo siguiente. Hemos hecho la comparativa con SMS-OTP, pero es lo mismo con WhatsAPP-OTP o Telegram-OTP o e-mail OTP. Con el API de OpenGateway de Number Verification la experiencia es más segura, y más suave, o como se suele decir, más "Seamless". 

Figura 8: Experiencia Cabify con y sin OpenGateway

De todo esto, y de algunos anuncios más os voy a hablar mañana, que son muchos ya los clientes de OpenGateway que están en producción, y muchas más cosas que tenemos en innovación para el futuro - que es nuestro trabajo -. 

Conclusión

Es increible todo lo que hay que hacer en el mundo digital para conseguir algo tan mágico como "Login with your Phone Number". Hay que coordinar una industria entera para que en todo el mundo haya una única identidad federada. Hay que coordinar una industria entera para decidir estándares de interconexión y llamadas de APIs. Y hay que hacer mucha tecnología en tu empresa para poder servirlo con "One-Line of Code". Y estar en esto desde el principio es de lo más feliz que puede hacer a alguien como yo que ama la tecnología.  Si volviera a nacer, me dedicaría a lo mismo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Infra as Code vs. Platform Engineering: Una Mirada Técnica a la Tendencia Actual

En los últimos años, la gestión y automatización de infraestructuras tecnológicas ha experimentado un cambio significativo. Dos enfoques han surgido como protagonistas: el uso de herramientas de Infra as Code (IaC), y el movimiento hacia la ingeniería de plataformas (Platform Engineering) respaldado por soluciones como Axebow, de la que ya os habló nuestro compañero José Bernabéu-Auban en su artículo: "Platform Engineering as a Service: La encrucijada de la Nube y la ilusión del progreso."

Figura 1: Infra as Code vs. Platform Engineering.

Una Mirada Técnica a la Tendencia Actual

Este artículo explora ambas tendencias, haciendo especial énfasis en la complejidad y el nivel de conocimiento necesario para implementar IaC en entornos multicloud.

Infra as Code: Automatización Granular y Flexible

Infra as Code (IaC) ha sido una revolución para los equipos de DevOps y operaciones. Herramientas como Terraform, Ansible y Pulumi permiten definir y gestionar la infraestructura utilizando código, lo que garantiza consistencia, auditabilidad y capacidad de replicación. 

Figura 2: Docker: SecDevOps 2ª Edición de Fran Ramírez, Elias Grande

y Rafael Troncoso en 0xWord.

Sin embargo, trabajar con ib en entornos multicloud, como AWS, Google Cloud y Azure, agrega capas de complejidad que exigen un nivel avanzado de conocimiento técnico y organización.

Ventajas del Enfoque IaC

1. Granularidad y Control: Las herramientas IaC ofrecen control detallado sobre los recursos. Por ejemplo, con Terraform, se puede definir cada componente de una infraestructura cloud, desde redes hasta bases de datos.

2. Compatibilidad multicloud: Aunque IaC puede implementarse en entornos multicloud, utilizar distribuciones de Kubernetes nativas de los proveedores cloud tipo (EKS, GKE, AKS) puede limitar la portabilidad y la interoperabilidad entre plataformas, lo que puede generar dependencias que dificultan una verdadera estrategia multicloud. 

 

3. Madurez Tecnológica: Muchas herramientas IaC están bien documentadas y cuentan con una comunidad activa, lo que facilita su adopción.

Desafíos del Enfoque IaC

• Complejidad en Entornos Multicloud: Gestionar IaC en una nube ya es complejo; al incorporar múltiples proveedores como AWS, Google Cloud y Azure, se deben manejar diferencias en APIs, servicios y configuraciones. Esto incrementa los riesgos de errores y la necesidad de conocimientos especializados para unificar estrategias.

• Curva de Aprendizaje Pronunciada: Configurar y mantener IaC en un entorno multicloud requiere habilidades avanzadas, lo que implica un costo significativo en términos de formación y tiempo. Los equipos deben dominar lenguajes de configuración, comprender arquitecturas de cada proveedor y desarrollar experiencia en integración. 

 

Esta curva de aprendizaje puede traducirse en retrasos en la implementación y mayores gastos operativos, ya que el tiempo necesario para alcanzar la plena competencia puede ser considerable. Además, los errores derivados de una capacitación insuficiente pueden aumentar los costos asociados al re-trabajo y a la resolución de problemas.

• Escalabilidad Limitada sin Buenas Prácticas: Sin una estrategia bien definida, las configuraciones de IaC pueden volverse inmanejables a medida que crecen las implementaciones.

• Fragmentación Operativa: La falta de estandarización entre nubes puede resultar en implementaciones inconsistentes y más difíciles de mantener.

Platform Engineering: Abstracción y Estandarización

La Ingeniería de Plataformas o Platform Engineering  se posiciona como un enfoque holístico para gestionar infraestructuras y herramientas de desarrollo. Soluciones conocidas como plataformas de ingeniería, entre las que se encuentra Axebow, buscan crear una capa unificada que abstraiga la complejidad técnica y proporcione a los equipos de desarrollo y operaciones una experiencia optimizada.

Figura 3: Puedes probar Axebow sin coste

Beneficios del Enfoque de Platform Engineering

1. Abstracción de Complejidad: Estas plataformas permiten a los equipos trabajar en un entorno preconfigurado que automatiza las configuraciones comunes, reduciendo la necesidad de conocimientos especializados.

Figura 4: Con Axebow, los Developers no necesitan preocuparse

de la infraestructura, y los equipos de operaciones crean

infraestructura como servicio independiente de Cloud Provider.    

2. Control y Optimización de Costes: La ingeniería de plataformas facilita la supervisión y gestión eficiente de los recursos, permitiendo identificar y eliminar ineficiencias en el uso de la infraestructura. Esto es particularmente relevante en entornos multicloud, donde los costos pueden escalar rápidamente si no se controlan adecuadamente. Poder optimizar el coste es un factor fundamental.

Figura 5: Los equipos de DevSecOps pueden proveer infraestructura

como servicio a los developers independiente de Cloud Provider,

reduciendo complejidad y ahorrando costes en la gestión de entornos

de desarrollos, pruebas y producción, usando Axebow.

3. Productividad Mejorada: Con una plataforma estandarizada, los desarrolladores pueden enfocarse en construir aplicaciones en lugar de preocuparse por los detalles de la infraestructura.

Figura 6: Axebow permite que los developers se focalicen

en el código y no en la infraestructura.

4. Escalabilidad Organizacional: La ingeniería de plataformas promueve la coherencia y facilita la escalabilidad al ofrecer una base uniforme para todas las aplicaciones.

5. Seguridad y Gobernanza: La centralización de la gestión reduce los riesgos de configuraciones inseguras o incoherentes.

Figura 7: "Amazon Web Services (AWS):  Hardening deInfraestructuras Cloud Computing"de Abraham Romero en 0xWord.

Desafíos del Platform Engineering

• Costos Iniciales: Implementar este tipo de plataformas requiere una inversión significativa en tiempo y recursos.

• Menor Flexibilidad Inicial: Aunque la abstracción reduce la complejidad, también puede limitar la capacidad de personalización para casos excepcionales.

• Resistencia al Cambio: Los equipos acostumbrados a trabajar con IaC y scripting pueden ser reticentes a adoptar un enfoque centralizado.

Ambos enfoques tienen su lugar en las estrategias modernas de infraestructura. En muchas organizaciones, la convergencia entre ambas filosofías está generando híbridos donde IaC establece las bases de la infraestructura, mientras que la ingeniería de plataformas ofrece una experiencia optimizada para los desarrolladores.

Consideraciones Finales

La elección entre Infra as Code & Scripting vs. Platform Engineering no es excluyente. Las organizaciones deben evaluar sus necesidades específicas, madurez técnica y objetivos a largo plazo. Mientras que IaC es ideal para entornos donde se requiere un control fino y personalización, la ingeniería de plataformas sobresale en contextos donde la escalabilidad y la eficiencia del equipo son prioritarias.

Figura 8: Comparación y Convergencia

En última instancia, herramientas como Axebow representan una evolución hacia un enfoque más colaborativo y orientado a la experiencia del usuario, marcando el camino hacia el futuro de la automatización de infraestructuras. Si quieres probar un servicio líder como el de Axebow solo entra en nuestra web.

Un saludo,

Autor: Carlos García Blanco, CEO de Kumori

Contactar con Carlos García Blanco

Platform Engineering as a Service con Axebow: La encrucijada de la Nube y la ilusión del progreso.

Desde hace más de una década la industria tecnológica ha estado experimentado una evolución constante hacia la computación en la nube, impulsada por las promesas de escalabilidad, flexibilidad y eficiencia en costes. Evolución que ha ido acompañada por el surgimiento de una plétora de herramientas y plataformas, intencionalmente diseñadas para simplificar el desarrollo y la gestión de recursos en la nube. Pero... ¿hemos avanzado lo suficiente en la última década?.

Figura 1: Platform Engineering as a Service con Axebow.

La encrucijada de la Nube y la ilusión del progreso.

Si nos paramos a analizar la situuación actual, a pesar de estos avances, la complejidad fundamental de aprovisionar y gestionar recursos virtualizados sigue siendo prácticamente la misma. Hemos pasado de escribir scripts personalizados para orquestar nuestra infraestructura a utilizar herramientas más sofisticadas, como por ejemplo Terraform.

Paralelamente, y a un nivel superior, hemos introducido un mayor grado de automatizaciones con orquestadores de contenedores como Kubernetes. Sin duda hemos ido progresando, pero, ¿estamos significativamente mejor que hace diez años a la hora de simplificar la puesta a punto de servicios basados en software?

La Evolución de las Herramientas de Desarrollo Cloud

En los primeros días de la computación en la nube, desarrolladores y administradores de sistemas dependían en gran medida de scripts manuales para gestionar máquinas virtuales y otros recursos. Scripts de shell, Python y otras soluciones ad hoc fueron la norma (aún lo son en algunos casos). Estos scripts a menudo son específicos de la plataforma, carecen de estandarización y son difíciles de mantener. Lo que es peor, en muchos casos son scripts específicos para la puesta en producción de servicios concretos, por lo tanto no generalizables.

La llegada de la aproximación de Infraestructura como Código (IaC, en sus siglas en inglés) y sus herramientas (Terraform, CloudFormation, Ansible, ...), prometió poner orden en el caos. Estas herramientas permiten a los ingenieros definir configuraciones de infraestructura en código, versionarlas y desplegarlas de manera confiable en diferentes entornos. A primera vista, esto parece un avance significativo.

También hemos visto una proliferación de marcos y herramientas que intentan simplificar el desarrollo en la nube, introduciendo nuevas abstracciones que, por desgracia, conllevan curvas de aprendizaje importantes y muchas oportunidades para errar en su uso.

Figura 2: Docker: SecDevOps 2ª Edición de Fran Ramírez, Elias Grande

y Rafael Troncoso en 0xWord.

Kubernetes es un excelente ejemplo. Nació de la necesidad de facilitar la orquestación de contenedores, y ha tenido éxito hasta cierto punto. Pero para muchos desarrolladores, la transición a Kubernetes a menudo se siente como intercambiar un conjunto de complejidades (p.e., gestión de servidores) por otro (gestión de manifiestos, clústeres, políticas de red, etc...). El viejo dolor de cabeza de gestionar recursos ha sido reemplazado por nuevas complejidades en la gestión de objetos de Kubernetes.

La Persistencia de la Complejidad

Por lo tanto, a pesar de la adopción de herramientas como las ya expuestas, la complejidad asociada con el desarrollo en la nube no ha disminuido sustancialmente. Podemos enumerar algunas de sus razones:

1. Curvas de Aprendizaje nada despreciables: Herramientas como Terraform (o incluso Kubernetes) introducen sus propios lenguajes específicos de dominio (DSL) (interno, en el caso de Kubernetes, basado en YAML), y conceptos que sus usuarios deben aprender. Comprender las sutilezas de estos lenguajes puede ser tan desafiante como dominar un nuevo lenguaje de programación.

2. Características Específicas de la Plataforma: Aunque las herramientas de IaC intentan ser independientes de la plataforma, la realidad es que proveedores cloud como AWS, Azure, Google Cloud, etc... tienen servicios, configuraciones y peculiaridades únicas. Esto requiere un profundo conocimiento específico del proveedor cloud, lo que va en contra del objetivo de simplificación de las herramientas. Plataformas como Kubernetes tampoco se salvan de tratar con esta especificidad.

3. Servicios en la Nube en Evolución Constante: Los proveedores Cloud lanzan continuamente nuevos servicios y características. Mantenerse al día con estos cambios requiere aprendizaje constante y actualizaciones al código de infraestructura existente, añadiendo una carga adicional de mantenimiento.

4. Complejidad de los Sistemas Distribuidos: Los servicios basados en software son inherentemente aplicaciones distribuidas. Utilizan microservicios (posiblemente basados en contenedores), arquitecturas sin servidor o una combinación de ambas. Gestionar su ciclo de vida en la nube introduce capas adicionales de complejidad que las herramientas de IaC por sí solas no pueden abstraer (ni es su objetivo).

5. Gestión de Estado y Depuración: Manejar el estado de los recursos en la nube es una tarea no trivial. Herramientas como Terraform mantienen archivos de estado que pueden convertirse en fuentes de conflictos, llevando a problemas de despliegue difíciles de depurar.

Caso concreto I: Scripts de Terraform vs. Scripts Tradicionales

Consideremos la transición de scripts tradicionales a scripts de Terraform. Si bien Terraform proporciona una forma estructurada de definir recursos, los scripts pueden volverse extremadamente complejos en infraestructuras grandes. Módulos, variables y gráficos de dependencias intrincados pueden hacer que las configuraciones de Terraform sean tan difíciles de leer y mantener como los scripts que reemplazaron.

Además, errores en las configuraciones de Terraform pueden conducir a despliegues parciales o modificaciones no intencionadas de recursos, requiriendo una planificación cuidadosa y pruebas exhaustivas, prácticas que eran igualmente necesarias con los scripts tradicionales.

Caso concreto II: Kubernetes vs. Métodos de Implementación Tradicionales

Consideremos el auge de Kubernetes como la solución de facto para la orquestación de contenedores. Kubernetes promete simplificar la implementación, escalado y gestión de aplicaciones en contenedores. Sin embargo, esta simplificación aparente viene con su propio conjunto de complejidades.

• Configuraciones Complejas: Kubernetes utiliza archivos YAML para definir recursos como Pods, Servicios y Deployments. Estos archivos pueden volverse extremadamente detallados y difíciles de gestionar, especialmente en aplicaciones grandes con múltiples microservicios.

• Curva de Aprendizaje Pronunciada: Dominar Kubernetes requiere una comprensión profunda de conceptos como namespaces, ingress controllers, volúmenes persistentes y políticas de red. Esto puede ser abrumador para equipos que migran desde entornos tradicionales.

• Infraestructura Adicional: Para ejecutar Kubernetes, a menudo se necesita infraestructura adicional, como sistemas de almacenamiento distribuidos y soluciones de red avanzadas. Esto añade más capas que deben configurarse y mantenerse.

• Herramientas Complementarias Necesarias: La gestión efectiva de un clúster de Kubernetes a menudo requiere herramientas adicionales como Helm para la gestión de paquetes, Prometheus para monitorización y Grafana para visualización, cada una con sus propias complejidades. No sólo esto, configurar un clúster Kubernetes para dotarlo de funciones básicas (ie. ingress, networking, ...) requiere tener que elegir de entre un nutrido elenco de soluciones, cada una con sus pros y sus cons, así como sus propias complejidades de configuración y gestión.

• Depuración y Resolución de Problemas: Cuando algo sale mal en Kubernetes, identificar y resolver el problema puede ser significativamente más difícil debido a la naturaleza distribuida y dinámica del sistema.

En comparación con los métodos de implementación tradicionales, donde las aplicaciones se despliegan en servidores físicos o máquinas virtuales con configuraciones más estáticas, Kubernetes introduce un nivel de abstracción que, si bien es poderoso, también puede ser difícil de manejar sin la experiencia adecuada.

El Problema Subyacente

En el fondo, el problema es la complejidad inherente de los entornos en la nube. Las herramientas sólo pueden abstraer la complejidad hasta cierto punto. Mientras los servicios en la nube sigan siendo tan diversos y complejos como lo son, gestionarlos requerirá un esfuerzo y conocimiento significativos.

La consecuencia es que es necesario un buen grado de especialización para gestionar buena parte de las tareas de gestión de recursos que es preciso tener en cuenta no sólo a la hora de poner servicios en producción, sino también durante el proceso de desarrollo del software, creando un buen número de ineficiencias.

¿Qué Necesitamos Cambiar?

Para responder a esta pregunta, debemos clarificar cuales son (o deberían ser) nuestros objetivos. La IaC y sus herramientas tienen como objetivos simplificar (¿?) el proceso de aprovisionamiento de recursos y servicios en la nube. Sin embargo, podemos argumentar que esto no es realmente el objetivo último. El objetivo último debería ser doble:

1. Por una parte habilitar a los equipos de desarrollo el acceso transparente a aquellos recursos virtualizados que necesitan para apoyar su proceso de desarrollo.

2. Por otra parte, permitir la gestión ágil del ciclo de vida de los servicios basados en el software producido por esos equipos de desarrollo.

Es nuestro punto de vista que atender dichos objetivos sólo va a ser posible elevando el nivel de las abstracciones manejadas por desarrolladores y gestores de servicios de modo que la gestión de los recursos virtualizados se transparente gracias a la automatización que esos niveles de abstracción permiten.

Figura 3: Axebow permite que los developers se focalicen

en el código y no en la infraestructura.

Esta aproximación no es novedosa. Baste ver la evolución de los sistemas operativos modernos: el desarrollador no se preocupa de la gestión de los recursos existentes en el ordenador. Confía en el sistema operativo subyacente, y todos los actores que operan por encima del sistema operativo manejan un conjunto de abstracciones simples y a la vez potentes que les permiten ignorar totalmente la gestión de los recursos necesarios para las tareas de cómputo soportadas.

Figura 4: Con Axebow, los Developers no necesitan preocuparse

de la infraestructura, y los equipos de operaciones crean

infraestructura como servicio independiente de Cloud Provider.

Esta es también la dirección tomada por sistemas que, como Kubernetes, introducen un alto grado de automatización, aunque en este caso a un precio de complejidad que, en nuestra opinión, genera sus propios problemas.

Figura 5: Los equipos de DevSecOps pueden proveer infraestructura

como servicio a los developers independiente de Cloud Provider,

reduciendo complejidad y ahorrando costes en la gestión de entornos

de desarrollos, pruebas y producción, usando Axebow.

En conclusión, para lograr un progreso significativo, debemos poner el foco en la simplificación de las plataformas que ponemos a disposición de los equipos de desarrollo. La complejidad debe residir en la implementación de la plataforma, no en su uso, como frecuentemente sucede hoy en día. Solo cuando logremos que el acceso a la tecnología de la nube sea tan transparente como el acceso a la electricidad podremos constatar la dimensión de un auténtico progreso.

Figura 6: Prueba sin coste Axebow durante Octubre y Noviembre

Es lo que se ha pretendido con Axebow simplificar el proceso de despliegue reduciendo la complejidad existente y descrita. Podéis probar el servicio SIN COSTE durante ellos meses de octubre y noviembre.

Saludos,

Autor: José Bernabeu-Auban

Contactar con José Bernabeu-Auban

(Tu) Quantum Drop: Almacena en Cloud y Comparte ficheros con algoritmos de Criptografía Post Cuántica (PQC)

A finales del mes de Julio, sabiendo que venían las versiones finales de los algoritmos del NIST de Criptografía Post Cuántica (Post-Quantum Cryptography), sacamos la beta privada de otro de los proyectos de innovación que llevamos en Tu.Com y que tiene que ver con la Computación Cuántica, llamado Quantum Drop.

Figura 1: Quantum Drop: Almacena en Cloud y Comparte

ficheros con algoritmos de Criptografía Post Cuántica (PQC)

Quantum Drop es un servicio que pretende sacar el máximo de los algoritmos de PQC para el almacenamiento de documentos en entornos Cloud Computing y la compartición de los archivos de manera segura... incluso ante la posible llegada de los Ordenadores Cuánticos.

Figura 2: NIST PQC Time-Line

Como sabéis, el gobierno de los Estados Unidos, a finales del año 2022 lanzó el Quantum Computing Cybersecurity Preparedness Act, para que se haga un plan de seguridad que proteja los sistemas del gobierno de los Estados Unidos ante la eventual llegada de los Ordenadores Cuánticos, que destrozarán los algoritmos de cifrado actuales. 

Figura 3: Quantum Computing Cybersecurity Preparedness Act

Esto, no sólo lo está haciendo el gobierno de Estados Unidos, y las empresas también estamos trabajando en ello. Llevamos años con la aplicación del cifrado cuántico a las comunicaciones, y con proyectos de detección de software y protocolos inseguros a los ordenadores cuánticos, para tener información sobre qué hay que cambiar a algoritmos Post-Quantum Encryption (PQC), a sistemas de Quantum Key Distribution (QKD), o dónde empezar a aplicar los Quantum Random Number Generator (QRNG).

Figura 5: PoC de cifrado cuántico con QKD de Telefónica

De hecho, los compañeros de Telefónica Tech están haciendo este tipo de proyectos ya para muchas empresas en todo el mundo que no quieren esperar a que les alcance la ola de una eventual llegada de Ordenadores Cuánticos sin una estrategia clara de qué está en riesgo, y cuál es el plan para cambiar todo. 

Figura 6: Áreas de investigación en Quantum

Technology en Telefónica Innovación Digital

Y por supuesto, desde el área de innovación de Telefónica Innovación Digital llevamos tiempo trabajando en herramientas y soluciones, una de ellas Qunatum Drop. Que además nosotros tenemos la suerte de tener cerca a Ignacio Cirac, uno de los grandes en este mundo.

Figura 7: Ignacio Cirac dando un conferencia sobre Quantum Technology

Internamente para nosotros tenía otros nombres código, y eran varios proyectos en paralelo que se han convertido en Quantum Drop, donde un fichero se sincroniza con la nube utilizando comunicaciones con algoritmos PQE, se almacena cifrado con PQE, y se comparte con destinatario utilizando intercambio de claves de cifrado.

Figura 8: Beta de Quantum Drop

Ahora el proyecto esta en beta privada, y buscamos Beta Testers que quieran ser parte del equipo que dé feedback de mejora sobre la solución, así que si quieres apuntarte puedes hacerlo desde ya en la web de Quantum Drop en la web de Tu.com.

Figura 9: Ser beta tester de Quantum Drop

Sabemos que le queda un poco a los Ordenadores Cuánticos, pero de ahora en adelante verás como todos los productos que lancemos en Tu.Com y en Telefónica, van a llevar la revisión cuántica, para asegurarnos de que estamos construyendo tecnología que poco a poco esté preparada para convivir con un mundo de computación cuántica que llevamos esperando un tiempo, pero para la que aún no nos hemos preparado del todo.

Figura 10: Ser beta tester de Quantum Drop

Si quieres comenzar a conocer estas tecnologías y cómo se aplican al mundo digital que tenemos, apúntate a la beta privada de Quantum Drop... y a las próximas que vayamos lanzando, que verás que habrá muchas más.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Todo sobre Telefónica Open Gateway en la nueva newsletter mensual: APIs, Casos de Uso, Trainings, Docs, Events.

Como todos los años, Septiembre llega cargado con muchas novedades, y una de ellas, es que el equipo de Telefónica Open Gateway ha lanzado una nueva newsletter mensual sobre todas las novedades del proyecto Open Gateway. del que ya os he hablado en muchas ocasiones. Se enviará en inglés, será para todos los públicos y llevará todas las novedades sobre la iniciativa: lo último de nuestras APIs, las soluciones creadas, casos de uso, las noticias del sector más relevantes y las citas de los eventos en los que puedes encontrarnos. Para empezar a recibirla, suscríbete aquí. 

Figura 1: Todo sobre Telefónica Open Gateway en la nueva newsletter mensual.

APIs, Casos de Uso, Trainings, Docs, Events.

La newsletter abrirá con la sección API Shots. Este espacio está dedicado a contar las novedades de producto y los últimos lanzamientos de Telefónica Open Gateway. Todo sobre nuestro repositorio de APIs, casos de uso integrando nuestras soluciones, casos de estudio con nuestros partners, acuerdos estratégicos, etcétera.

Figura 2: Entrevista sobre Open Gateway en El Español

La siguiente sección la hemos llamado API Learning, donde presentaremos nuestro portfolio de APIs con un enfoque más técnico: documentación general, y también especializada a través de whitepapers o datasheets, y con demos de producto, entre otras.

Figura 3: APIs "Developer-Ready"

La siguiente sección, Trend News, la hemos diseñado para mantenerte al día de las publicaciones sobre Open Gateway, CAMARA, la GSMA o las novedades en el sector. Aquí podrás encontrar los temas tendencia, investigaciones de profesionales o informes lanzados por la industria.

Figura 4: Casos de uso con APIs CAMARA

Cerramos la newsletter con la Agenda de los próximos eventos, en los que vamos a participar con los expertos de Telefónica Open Gateway, a los que puedes asistir. Destacaremos siempre el evento principal en el que puedes encontrarnos para que, si te interesa, hagas un hueco en tu agenda; y nos veamos por allí.  Por ejemplo, ya puedo contarte que este mes estaremos en la Open Gateway DevCon del MWC23 Las Vegas el próximo 27 de septiembre.

Figura 5: Suscríbete a la newsletter de Telefónica Open Gateway

Apúntate a la newsletter de Telefónica Open Gateway suscribiéndote directamente aquí https://opengateway.telefonica.com/newsletter

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)