Tag:

DevOps

Tecnología

CodeRabbit lanza agente Slack para equipos de ingeniería

by Editor de Tecnologia
written by Editor de Tecnologia

CodeRabbit, pionero en revisión de código con inteligencia artificial, ha anunciado el lanzamiento de su nuevo agente para Slack, diseñado para actuar como un «segundo cerebro» para equipos de ingeniería. Esta herramienta extiende el motor de contexto de alto rendimiento de CodeRabbit desde la revisión de código hasta Slack, donde los equipos ya planifican, depuran y lanzan sus proyectos.

El agente de CodeRabbit para Slack funciona como un único agente para todo el ciclo de vida del desarrollo de software (SDLC, por sus siglas en inglés), abarcando las siete fases: planificación, requisitos, diseño, codificación, prueba, despliegue y mantenimiento. Al mantener el contexto y las decisiones de una fase a otra, el agente permite que el conocimiento colectivo del equipo se acumule a lo largo del ciclo en lugar de reiniciarse en cada transición.

Según la empresa, uno de los principales problemas en el desarrollo de software actual es que, aunque la inteligencia artificial ha acelerado el trabajo individual, el proceso completo del SDLC sigue siendo lento debido a la falta de tres elementos clave: integración dentro del espacio de colaboración donde ya trabajan los equipos (como Slack), un registro explicable de las acciones realizadas por el agente y una atribución de costos alineada con la estructura organizativa de los equipos.

El agente responde a menciones de @coderabbit y comandos slash en cualquier canal, hilo o mensaje directo de Slack, sin requerir sintaxis especial. Entre sus capacidades, permite investigar el código base, rastrear características y vincular errores de Sentry con pull requests fusionados y problemas de Jira, todo mediante lenguaje natural. También puede generar planes estructurados a partir de hilos de Slack y entregarlos a agentes de programación como Claude Code, Codex o Cursor.

En la fase de ejecución, los equipos pueden discutir requisitos, hacer referencia a problemas en Linear o bocetos en Figma, y solicitar al agente que abra una pull request que incorpore todo lo discutido. Además, soporta funciones como la generación automática de pruebas unitarias, resolución de conflictos de fusión, creación de docstrings y enriquecimiento de problemas.

CodeRabbit afirma que su motor de contexto ya procesa dos millones de revisiones de código por semana en más de 15,000 equipos de ingeniería, lo que respalda la escalabilidad y el rendimiento de su nuevo agente para Slack.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Mundo

Soberanía Tecnológica: Alternativas a la Dependencia de la Nube Estadounidense

Riesgos de la Nube: Kleppmann Aboga por Multi-Cloud y Local-First

Dependencia Cloud: Hacia una Mayor Autonomía Tecnológica

QCon London: Kleppmann y el Futuro de la Soberanía Digital

Alternativas a AWS, Azure y Google Cloud: El Llamado de Kleppmann

by Editor de Mundo
written by Editor de Mundo

En el segundo día de QCon London 2026, Martin Kleppmann, disponible en LinkedIn, inició su discurso principal con un gráfico que no mostraba el rendimiento o la latencia de los sistemas, sino la cuota de mercado europea de la computación en la nube. AWS, Azure y Google Cloud controlan aproximadamente el setenta por ciento del mercado europeo, mientras que los proveedores de nube europeos más grandes apenas alcanzan el dos por ciento cada uno.

En otras palabras, Europa depende completamente de los servicios de nube estadounidenses.

Kleppmann, profesor asociado de la Universidad de Cambridge y autor de Designing Data-Intensive Applications (la segunda edición, co-escrita con Chris Riccomini, se publicará este mes), dedicó los siguientes cincuenta minutos a argumentar que esta dependencia es un riesgo que merece la pena abordar, no con pánico, sino con opciones tecnológicas prácticas que devuelvan el poder a los usuarios y lo alejen de los proveedores únicos.

Fundamentó el riesgo en acontecimientos recientes. El año pasado, las sanciones estadounidenses contra la Corte Penal Internacional en La Haya provocaron que el fiscal jefe perdiera el acceso a su correo electrónico alojado en Microsoft. Microsoft negó haber suspendido los servicios, pero confirmó que había estado en contacto con la CPI «a lo largo del proceso que resultó en la desconexión de su funcionario sancionado». La CPI migró fuera de los servicios de Microsoft poco después.

Dos semanas antes del discurso principal, Irán atacó tres centros de datos de AWS en los Emiratos Árabes Unidos con drones, dañando gravemente al menos uno. La región seguía mostrando servicios interrumpidos en el panel de control de AWS el día antes de la presentación. Kleppmann también señaló que alojar datos en regiones europeas tampoco resuelve el problema: Microsoft ha declarado que cumpliría con las solicitudes legales estadounidenses de datos de ciudadanos de la UE almacenados en la UE, independientemente de la legislación de la UE.

Su argumento no era que un conflicto entre Estados Unidos y Europa sea probable. Subrayó que la probabilidad sigue siendo pequeña, pero ya no es cero, y el impacto de un bloqueo repentino sería enorme. Esto hace que sea un riesgo que vale la pena mitigar bajo lo que él llamó «soberanía tecnológica«, una palabra de moda, reconoció, que no dice nada sobre cómo lograrla realmente.

Propuso tres direcciones tecnológicas concretas.

Multi-nube y commoditización: Para los servicios de back-end, Kleppmann argumentó que la capacidad de cambiar de proveedor es lo que importa, y que la commoditización a través de estándares de facto es el mejor camino para lograrlo. Señaló la API S3 para el almacenamiento de objetos, Kubernetes para la implementación, el protocolo Kafka para la transmisión y el protocolo de cable Postgres para las bases de datos como estándares emergentes que permiten cambiar incluso sin organismos de estandarización formales. Comparó esto con la estandarización de las roscas de los tornillos por Joseph Whitworth en 1841, que desbloqueó la intercambiabilidad entre los fabricantes durante la Revolución Industrial. Las contrapartidas son reales: aumento de los costes, complejidad operativa y quedarse atascado con funciones de menor denominador común. Kleppmann argumentó que los servicios commoditizados son muy preferibles a esperar que todos se auto-alojen.

La vida es demasiado corta para ser un administrador de sistemas, a menos que realmente te guste, o a menos que sea tu trabajo.

El protocolo AT y Bluesky: Para las redes sociales, Kleppmann describió el protocolo AT subyacente a Bluesky, en el que ha asesorado desde principios de 2022. El protocolo fue diseñado en torno a la «salida creíble», el principio de que si un proveedor se comporta mal, los usuarios pueden cambiar sin perder su nombre de usuario, su grafo social o sus publicaciones. Los datos de cada usuario residen en un repositorio personal (análogo a un repositorio Git) alojado en un servidor de datos personal (PDS), y cualquiera puede ejecutar un PDS. Un relé agrega eventos de todos los repositorios en un flujo de datos, y AppViews construye índices sobre él.

Cada componente puede ser ejecutado por proveedores competidores. El directorio de usuarios (directorio PLC) sigue siendo centralizado, pero con protecciones de integridad criptográfica y la opción de bifurcaciones comunitarias si se comporta mal. Bluesky también está llevando los protocolos básicos a la IETF para su estandarización formal, renunciando al control corporativo en el proceso. Actualmente hay cuarenta y tres millones de usuarios y un ecosistema en crecimiento de aplicaciones no de microblogging, blogs, codificación social, intercambio de vídeos y reseñas de libros, todos construidos sobre el mismo protocolo. Para una inmersión técnica más profunda, Kleppmann señaló el documento de arquitectura que co-autorizó.

Software local-first: Para las herramientas de colaboración, Kleppmann describió el software local-first como la combinación de lo mejor de Google Sheets (datos ricos, colaboración en tiempo real, usabilidad) con lo mejor de Git (control de versiones, ramificación, alojamiento multi-proveedor, archivos en su propia máquina). El cambio fundamental: la copia local de datos del usuario se convierte en primaria, con los servicios en la nube reducidos a la sincronización y la copia de seguridad. Esto minimiza el papel de los servidores centralizados, hace que cambiar de proveedor sea trivial e incluso permite la sincronización entre pares.

El enfoque se deriva de la investigación sobre CRDT (tipos de datos replicados sin conflictos) y el proyecto de código abierto Automerge, que Kleppmann co-creó en 2017. El término «local-first» se acuñó en un ensayo de 2019 que desde entonces ha desencadenado un movimiento, con conferencias, startups, podcasts y un documental con la Conferencia Local-First que regresa a Berlín en julio de 2026. Kleppmann señaló que local-first funciona bien para la edición de archivos y las herramientas de productividad, pero no es adecuado para los sistemas que gestionan recursos físicos, como las cuentas bancarias, donde una fuente centralizada y autorizada sigue siendo apropiada.

El hilo conductor de los tres, dijo, es que la commoditización y la descentralización cambian el equilibrio de poder. La dependencia crea influencia, ya sea el suministro de gas de un país o el proveedor de nube de una empresa, y las elecciones de ingeniería que hacemos determinan quién tiene esa influencia.

Kleppmann concluyó:

Usar la tecnología para devolver el poder a los usuarios permite una mayor libertad y cambia el equilibrio de poder. Tal vez sea algo en lo que debas pensar en tu propio trabajo.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

AKS: Asignación Dinámica de GPU con vGPU de NVIDIA

by Editor de Tecnologia
written by Editor de Tecnologia

El equipo de Azure Kubernetes Service (AKS) ha publicado una guía detallada sobre cómo utilizar la Asignación Dinámica de Recursos (DRA) con la tecnología NVIDIA vGPU en AKS. Esta actualización mejora el control y la eficiencia para el uso compartido de GPU en tareas de IA y medios.

La Asignación Dinámica de Recursos (DRA) es ahora el estándar para el uso de recursos de GPU en Kubernetes. En lugar de recursos estáticos como nvidia.com/gpu, las GPU se asignan dinámicamente utilizando DeviceClasses y ResourceClaims. Este cambio mejora la programación e integra mejor las tecnologías de virtualización como NVIDIA vGPU.

La razón para combinar estas tecnologías es clara: los aceleradores virtuales como NVIDIA vGPU a menudo manejan tareas más pequeñas. Permiten que una GPU física se divida entre muchos usuarios o aplicaciones. Esta configuración es útil para el desarrollo empresarial de IA/ML, el ajuste fino y el procesamiento de audio y video. VGPU ofrece un rendimiento predecible al tiempo que proporciona capacidades CUDA a las cargas de trabajo en contenedores.

En el lado de la infraestructura, esta función se basa en la serie de máquinas virtuales NVadsA10_v5 de Azure. En lugar de asignar toda la GPU a una sola VM, la tecnología vGPU la divide en múltiples segmentos de tamaño fijo en la capa del hipervisor. Desde la perspectiva de Kubernetes, cada VM muestra un dispositivo GPU claro. El hipervisor establece los límites de capacidad y memoria, no el software.

La configuración requiere Kubernetes 1.34 o superior. En este momento, los primitivos DRA como deviceclasses y resourceslices están disponibles. Los equipos aprovisionan un grupo de nodos con instancias NVadsA10_v5 y aplican una etiqueta (nvidia.com/gpu.present=true) para el plugin kubelet NVIDIA DRA como su selector de nodos. Luego, implementan el controlador NVIDIA DRA a través de Helm. La publicación destaca tres banderas importantes de Helm para escenarios vGPU. La bandera gpuResourcesEnabledOverride=true omite una verificación que impide que el controlador NVIDIA DRA se instale con el plugin de dispositivo heredado debido a diferentes nombres de GPU. FeatureGates.IMEXDaemonsWithDNSNames=false deshabilita una función IMEX que requiere una versión del controlador GRID más reciente que la compatible en la serie A10 en Azure.

Una vez que el controlador está activo, escanea cada nodo, detecta el único dispositivo vGPU de la VM de Azure y lo registra en el plano de control de Kubernetes como un dispositivo administrado por DRA. Cada nodo registra un dispositivo asignable porque eso es lo que presenta la VM. Los operadores pueden verificar la configuración buscando la gpu.nvidia.com DeviceClass y ResourceSlices. De esta manera, pueden confirmar que el plano de control ha encontrado el hardware disponible.

Además del segmento base de un sexto (Standard_NV6ads_A10_v5), la serie ofrece un perfil de un tercio con 8 GB de memoria aceleradora y un perfil de la mitad con 12 GB. Los límites se aplican en la capa del hipervisor, por lo que AKS ve un único dispositivo GPU con una capacidad predecible. Esto brinda a los equipos de plataforma la flexibilidad de dimensionar la asignación de GPU según las necesidades de la carga de trabajo sin sobreaprovisionar los nodos.

El equipo de AKS enmarca la importancia general como direccional. A medida que las GPU se convierten en recursos de primera clase en Kubernetes, combinar la GPU virtualizada con DRA ofrece una forma práctica de ejecutar cargas de trabajo compartidas y de nivel de producción. Para las implementaciones de AKS a gran escala, especialmente en industrias reguladas o sensibles a los costos, la ubicación y utilización óptimas de la GPU impactan directamente en el rendimiento del trabajo y la eficiencia de la infraestructura. El uso de DRA con vGPU ayuda a las organizaciones a pasar de la asignación a nivel de nodo gruesa a un uso de GPU controlado y basado en la carga de trabajo a escala.

Google Cloud está siguiendo un camino similar en GKE, centrándose en DRA como un primitivo de programación tanto para GPU como para TPU. El soporte de DRA de GKE permite a las cargas de trabajo utilizar expresiones CEL para filtrar dispositivos con atributos específicos. Esto permite que un único manifiesto se implemente en diferentes clústeres con varios tipos de GPU sin cambios. Específicamente para vGPU, Google recientemente presentó de forma preliminar VM G4 fraccionadas que utilizan la tecnología NVIDIA vGPU basada en la GPU RTX PRO 6000 Blackwell, administrada a través de GKE y combinada con el empaquetamiento de contenedores para una mayor utilización. Cuando se programa a través del Programador de Carga de Trabajo Dinámica de Google, las prioridades de respaldo pueden mejorar el acceso a los recursos.

Amazon EKS adopta un enfoque diferente, utilizando DRA principalmente para simplificar la complejidad de su hardware GPU de alta gama en lugar de compartirlo fraccionadamente. Amazon EKS hizo que DRA estuviera disponible de forma general a partir de la versión de Kubernetes 1.33. Esta tecnología es esencial para las instancias P6e-GB200 UltraServer, donde la programación estática tradicional de GPU no puede modelar la interconexión NVLink e IMEX necesaria para las cargas de trabajo de varios nodos. Para los equipos que ejecutan cargas de trabajo más pequeñas que desean compartir GPU en EKS, DRA ahora admite solicitudes basadas en atributos estructuradas. Esto permite a los programadores responder a solicitudes como «una partición MIG de 10 GB con al menos 1/7 de capacidad de cómputo» en lugar de tratar las GPU como simples recuentos. En todos los tres proveedores de la nube, el cambio de los plugins de dispositivos estáticos a DRA se está acelerando, impulsado por la necesidad de una programación de GPU más expresiva y consciente de la topología a medida que la infraestructura de IA crece en complejidad y costo.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

Ray en AKS: Escala IA/ML con Azure, Anyscale y GPUs

by Editor de Tecnologia
written by Editor de Tecnologia

El equipo de Azure Kubernetes Service (AKS) de Microsoft ha compartido recomendaciones para ejecutar el servicio gestionado Ray de Anyscale a escala. Se centran en tres problemas clave: los límites de capacidad de las GPU, el almacenamiento de ML disperso y los problemas con la caducidad de las credenciales.

Esta publicación amplía una visión general anterior de KubeRay en AKS de código abierto. Ahora, destaca el runtime mejorado de Anyscale, anteriormente conocido como RayTurbo. Este runtime ofrece escalado automático inteligente, monitorización mejorada y funciones de entrenamiento tolerante a fallos, todo ello basado en el framework Ray de código abierto.

Ray es un framework de computación distribuida nativo de Python diseñado para escalar cargas de trabajo de IA y ML desde un único portátil hasta clústeres que abarcan miles de nodos. La plataforma gestionada de Anyscale mejora Ray con funciones para su uso en producción. La nueva guía muestra una colaboración entre Microsoft y Anyscale para mejorar la integración con Azure.

La escasez de GPU es uno de los mayores desafíos operativos en el ML a gran escala. Los aceleradores de alta demanda, como las GPU NVIDIA, a menudo tienen problemas de cuota y disponibilidad en las regiones de Azure, lo que puede retrasar la configuración del clúster y la programación de trabajos.

La solución propuesta por Microsoft utiliza una configuración multi-clúster y multi-región. Distribuir los clústeres Ray en diferentes instancias de AKS en varias regiones de Azure permite a los equipos: agregar cuota de GPU más allá de los límites regionales, redirigir automáticamente las cargas de trabajo durante las interrupciones o los problemas de capacidad y extender el grupo de computación a sistemas locales u otros proveedores de la nube utilizando Azure Arc con AKS.

La consola de Anyscale muestra estos clústeres registrados en una sola vista. Anyscale Workspaces gestiona la programación de cargas de trabajo utilizando la capacidad disponible, ya sea manualmente o automáticamente. Puede agregar nuevas regiones creando un manifiesto cloud_resource.yaml y luego aplicándolo mediante la CLI de Anyscale. Este enfoque basado en la configuración facilita la gestión de la expansión multi-región.

Un problema común en las operaciones de ML es la transferencia de datos de entrenamiento, puntos de control y artefactos entre las etapas de la canalización, incluyendo su movimiento desde el pre-entrenamiento hasta el ajuste fino y luego a la inferencia. La guía aborda esto con Azure BlobFuse2, que monta Azure Blob Storage en los pods de trabajador de Ray como un sistema de archivos compatible con POSIX.

Desde la perspectiva de Ray, el punto de montaje es simplemente un directorio local. Las tareas y los actores leen conjuntos de datos y escriben puntos de control utilizando la E/S de archivos estándar. BlobFuse2 luego guarda los datos en Azure Blob Storage, lo que los hace disponibles en todos los pods y grupos de nodos. El almacenamiento en caché local evita los bloqueos de la GPU durante las ejecuciones de entrenamiento a gran escala y, dado que los datos están desacoplados de la computación, los clústeres Ray pueden escalar hacia arriba y hacia abajo sin pérdida de datos.

Para configurar, habilite el controlador CSI de blob al crear el clúster. Luego, defina una StorageClass que utilice la identidad de carga de trabajo para la autenticación. Finalmente, cree una PersistentVolumeClaim con acceso ReadWriteMany. Esto permite que varios trabajadores de Ray en diferentes nodos accedan a los datos compartidos al mismo tiempo. Este enfoque hace que el código de Ray sea portátil y agrega la durabilidad y la escalabilidad del almacenamiento nativo de Azure a la capa de infraestructura.

Otro tema importante es la fiabilidad de la autenticación. Anteriormente, Anyscale y Azure se integraban con tokens de CLI o claves de API que caducaban cada 30 días. Esto significaba que era necesaria una rotación manual, lo que corría el riesgo de interrumpir el servicio.

El nuevo método utiliza Microsoft Entra service principals y AKS workload identity. Emite tokens de corta duración automáticamente. El pod del operador de Kubernetes de Anyscale utiliza una identidad administrada asignada por el usuario. Esta identidad solicita un token de acceso para el principal de servicio de Anyscale desde Entra ID. Azure gestiona la actualización de los tokens de forma transparente, lo que significa que no se almacenan credenciales de larga duración en el clúster y no se requiere una rotación manual.

Los autores señalan que esto es especialmente importante en entornos multi-clúster. Aquí, la gestión manual de las credenciales en muchos clústeres aumenta la carga operativa. El modelo de identidad de carga de trabajo proporciona RBAC granular para el acceso a los recursos de Azure y produce pistas de auditoría completas a través de los registros de actividad de Azure como subproducto.

La integración de Anyscale en AKS está actualmente en vista previa privada. Los equipos que deseen acceder deben comunicarse con su equipo de cuenta de Microsoft. También pueden presentar una solicitud en el repositorio de GitHub de AKS. Incluya detalles sobre las cargas de trabajo de Ray y las regiones objetivo. Puede consultar configuraciones de ejemplo y cargas de trabajo para el ajuste fino con DeepSpeed y LLaMA-Factory en el repositorio Azure-Samples/aks-anyscale en GitHub. Esto también incluye puntos finales de inferencia LLM.

Microsoft no es la única entidad que apuesta por esto. AWS anunció su asociación con Anyscale en Ray Summit 2024. Esto conecta los clústeres de EKS con el runtime RayTurbo. Destaca la flexibilidad del hardware al combinar las GPU NVIDIA con los aceleradores Trainium e Inferentia de AWS. Además, SageMaker HyperPod es ahora un destino de implementación para trabajos de entrenamiento de larga duración que necesitan resistencia a nivel de nodo. Google Cloud lidera las contribuciones de código abierto.

El equipo de GKE trabajó con ingenieros de Anyscale para integrar la programación basada en etiquetas en Ray v2.49. También crearon una capa ray.util.tpu para reducir la fragmentación de recursos en configuraciones de TPU multi-chip. Además, agregaron la asignación dinámica de recursos para las nuevas instancias respaldadas por GB200.

Los tres hiperescaladores han elegido el mismo operador gestionado de Ray y cada uno ha agregado su infraestructura. Esto demuestra que la industria prefiere Kubernetes más Ray para las cargas de trabajo de IA. Ahora, la competencia es menos sobre el runtime y más sobre qué nube puede optimizar mejor la infraestructura circundante.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

Cloudflare: Fallo DNS por orden incorrecto de registros CNAME

by Editor de Tecnologia
written by Editor de Tecnologia

Cloudflare, en un reciente artículo titulado «What came first- the CNAME or the A record?» (¿Qué vino primero, el CNAME o el registro A?), explica cómo una especificación RFC poco clara provocó una interrupción en el popular servicio 1.1.1.1 de Cloudflare. Tras identificar el fallo y la ambigüedad en las normas DNS más antiguas con respecto al orden de los registros, Cloudflare propone una especificación clarificada.

El 8 de enero, una actualización rutinaria del servicio DNS cambió el orden en que aparecían los registros CNAME en las respuestas, lo que provocó que algunos clientes DNS fallaran al resolver nombres porque esperaban que los registros alias aparecieran primero. Si bien la mayoría del software moderno trata el orden de los registros en las respuestas DNS como irrelevante, el equipo de Cloudflare descubrió que algunas implementaciones esperan que los registros CNAME aparezcan antes que cualquier otro tipo de registro.

Cuando ese orden cambió, la resolución DNS comenzó a fallar, lo que desencadenó una interrupción significativa del popular servicio DNS público 1.1.1.1. Sebastiaan Neuteboom, ingeniero de sistemas de Cloudflare, explica por qué y cuándo se introdujo el cambio:

Mientras realizábamos algunas mejoras para reducir el uso de memoria de nuestra implementación de caché, introdujimos un cambio sutil en el orden de los registros CNAME. El cambio se introdujo el 2 de diciembre de 2025, se lanzó a nuestro entorno de pruebas el 10 de diciembre y comenzó a implementarse el 7 de enero de 2026.

Cuando un resolvedor DNS busca un nombre con un registro CNAME, puede ver una serie de registros alias que vinculan el nombre original a una dirección final, y almacena en caché cada paso con su propio tiempo de expiración. Cloudflare señala que si una parte de esta cadena ha expirado en la caché, el resolvedor solo vuelve a buscar la parte expirada y la combina con las partes válidas para formar la respuesta completa.

Cloudflare destaca que cuando un resolvedor DNS busca un nombre con un CNAME, puede ver una serie de registros alias que vinculan el nombre original a una dirección final, y el resolvedor almacena en caché cada paso con su propio tiempo de expiración. Si una parte de esta cadena ha expirado en la caché, el resolvedor solo vuelve a buscar la parte expirada y luego la combina con las partes aún válidas para formar la respuesta completa. Neuteboom añade:

Anteriormente, el código crearía una nueva lista, insertaría la cadena CNAME existente y luego agregaría los nuevos registros (…) Sin embargo, para ahorrar algunas asignaciones y copias de memoria, el código se cambió para agregar en su lugar los CNAME a la lista de respuestas existente. Como resultado, las respuestas que 1.1.1.1 devolvió ahora a veces tenían los registros CNAME que aparecían en la parte inferior, después de la respuesta resuelta final.

;; QUESTION SECTION:
;; www.example.com.	       IN    A

;; ANSWER SECTION:
cdn.example.com.    300    IN    A      198.51.100.1
www.example.com.    3600   IN    CNAME  cdn.example.com.

Si bien muchas implementaciones de clientes DNS no dependen del orden, por ejemplo, systemd-resolved, otras, incluida la función getaddrinfo en glibc, manejan la cadena en la resolución realizando un seguimiento del nombre esperado para los registros e iterando secuencialmente, esperando encontrar los registros CNAME antes que cualquier respuesta. En Reddit, un usuario comenta:

Por un lado, realmente respeto los detalles en sus análisis post-mortem y el alto nivel de ingeniería. Por otro lado, no puedo evitar pensar que no tienen pruebas adecuadas en su lugar (y una cultura de ello) para comprender el impacto que tienen a nivel mundial.

En un popular hilo de Hacker News, muchos usuarios discuten si el RFC es realmente poco claro, con la sutil distinción entre RRsets y RRs en las secciones de mensajes, o si los desarrolladores de Cloudflare lo malinterpretaron. Patrick May comenta en cambio:

Un gran ejemplo de la Ley de Hyrum: «Con un número suficiente de usuarios de una API, no importa lo que prometas en el contrato: todos los comportamientos observables de tu sistema serán dependidos por alguien», combinado con el fracaso de seguir la Ley de Postel: «Sé conservador en lo que envías, sé liberal en lo que aceptas».

En un Internet-Draft que se discutirá en la IETF, Cloudflare propone un RFC que define explícitamente cómo manejar correctamente los registros CNAME en las respuestas DNS.

Según la cronología publicada, Cloudflare comenzó el despliegue global el 7 de enero y alcanzó el 90% de los servidores el 8 de enero a las 17:40 UTC. La compañía declaró el incidente poco después, comenzó a revertir el cambio a las 18:27 UTC del 8 de enero y completó la reversión a las 19:55 UTC.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

NVIDIA Dynamo en Azure AKS: Optimización IA con Escalado Automático

by Editor de Tecnologia
written by Editor de Tecnologia

Microsoft y NVIDIA han lanzado la Parte 2 de su colaboración para ejecutar NVIDIA Dynamo para la inferencia de modelos de lenguaje grandes en Azure Kubernetes Service (AKS). El primer anuncio apuntaba a un rendimiento bruto de 1.2 millones de tokens por segundo en sistemas de GPU distribuidos. Esta última versión se centra ahora en ayudar a los desarrolladores a trabajar más rápido y mejorar la eficiencia operativa, a través de la planificación automatizada de recursos y funciones de escalado dinámico.

Las nuevas capacidades se centran en dos componentes integrados: el Dynamo Planner Profiler y el Dynamo Planner basado en SLO (Service Level Objective). Estas herramientas trabajan juntas para resolver el desafío de la «igualación de tasas» en el servicio desagregado. Los equipos utilizan este término cuando dividen las cargas de trabajo de inferencia, separando las operaciones de prellenado, que procesan el contexto de entrada, de las operaciones de decodificación que generan tokens de salida. Estas tareas se ejecutan en diferentes grupos de GPU. Sin las herramientas adecuadas, los equipos dedican mucho tiempo a determinar la asignación óptima de GPU para estas fases.

El Dynamo Planner Profiler es una herramienta de simulación previa al despliegue que automatiza la búsqueda de las mejores configuraciones. Los desarrolladores pueden omitir las pruebas manuales de diversas estrategias de paralelización y recuentos de GPU, ahorrando horas de utilización de GPU. En su lugar, definen sus necesidades en un manifiesto DynamoGraphDeploymentRequest (DGDR). El profiler ejecuta un barrido automatizado del espacio de configuración, probando diferentes tamaños de paralelismo de tensores tanto para las etapas de prellenado como de decodificación. Esto ayuda a encontrar configuraciones que aumenten el rendimiento sin superar los límites de latencia.

El profiler incluye un modo AI Configurator que puede simular el rendimiento en aproximadamente 20 a 30 segundos basándose en datos de rendimiento premedidos. Esta capacidad permite a los equipos iterar rápidamente en las configuraciones antes de asignar recursos de GPU físicos. El resultado proporciona una configuración optimizada para aumentar lo que los equipos denominan «Goodput«, que es el mayor rendimiento posible manteniendo los límites establecidos para el Tiempo hasta el Primer Token y la Latencia Inter-Token.

Una vez que un sistema entra en producción, el Dynamo Planner basado en SLO se encarga de la orquestación en tiempo de ejecución. Este componente es «consciente de LLM», lo que significa que, a diferencia de los balanceadores de carga tradicionales, supervisa el estado del clúster. Realiza un seguimiento de elementos como la carga de la caché clave-valor en el grupo de decodificación y la profundidad de la cola de prellenado. El Planner utiliza los límites de rendimiento del profiler para escalar los trabajadores de prellenado y decodificación, ayudando a cumplir los objetivos de nivel de servicio a medida que cambian los patrones de tráfico.

El anuncio ilustra estas capacidades a través de un escenario detallado de asistente de aerolíneas. En este caso, un modelo Qwen3-32B-FP8 soporta una aplicación móvil de una aerolínea, cumpliendo estrictos acuerdos de nivel de servicio: 500 milisegundos para el Tiempo hasta el Primer Token y 30 milisegundos para la Latencia Inter-Token. Durante las operaciones normales con consultas cortas de los pasajeros, el sistema funciona con un trabajador de prellenado y un trabajador de decodificación. Cuando una interrupción meteorológica provoca que 200 usuarios envíen solicitudes complejas de cambio de ruta, el Planner detecta el aumento y escala a dos trabajadores de prellenado, manteniendo uno de decodificación. Los equipos informan que el nuevo trabajador se pone en línea en cuestión de minutos, lo que permite al sistema mantener los objetivos de latencia durante el aumento del tráfico.

Este lanzamiento se basa en el marco introducido en el anuncio original de Dynamo, que InfoQ cubrió en diciembre de 2024. En ese artículo, Azure y NVIDIA explicaron cómo el diseño de Dynamo divide las tareas que consumen muchos recursos computacionales y las tareas que consumen mucha memoria en varias GPU, lo que permite a los equipos optimizar cada fase de forma independiente, adaptando los recursos a las necesidades de la carga de trabajo. Por ejemplo, la tarea de prellenado de una aplicación de comercio electrónico puede procesar miles de tokens, mientras que su tarea de decodificación solo genera descripciones cortas.

La transición de la configuración manual a la gestión automatizada de recursos basada en SLO demuestra cómo los equipos pueden manejar mejor el despliegue de modelos de lenguaje grandes en Kubernetes. Los componentes del Planner proporcionan herramientas que transforman las necesidades de latencia en opciones de asignación y escalado de GPU, con el objetivo de reducir la carga operativa de ejecutar arquitecturas de inferencia desagregadas. Las herramientas de automatización pueden ayudar a las organizaciones con modelos LLM que requieren mucho razonamiento o un contexto largo, facilitando la gestión de configuraciones complejas de GPU multinodo y apoyando el cumplimiento de los objetivos de nivel de servicio durante los cambios en los patrones de tráfico.

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

Capture The Bug: Expansión en EEUU y Nombramientos Clave

by Editor de Tecnologia
written by Editor de Tecnologia

Capture The Bug ha incorporado a tres líderes tecnológicos sénior con base en Estados Unidos a su Consejo Asesor Ejecutivo, en preparación para una mayor expansión en Norteamérica.

La compañía de ciberseguridad, fundada en Hamilton, señaló que estos nombramientos reflejan la evolución de las prácticas de seguridad entre las organizaciones de software. Muchas empresas están abandonando los ciclos anuales de pruebas de penetración y adoptando enfoques de pruebas continuas, alineados con los frecuentes lanzamientos de software.

Los nuevos asesores se encuentran en San Francisco, Silicon Valley y el área metropolitana de Filadelfia. Capture The Bug indicó que aportan experiencia de organizaciones y productos como Reddit, Microsoft, GitHub, Azure, Copilot y Visa.

Capture The Bug fue fundada por Ankita Dhakar. La empresa ofrece Pruebas de Penetración como Servicio (PTaaS). PTaaS se posiciona como una alternativa a las pruebas de penetración puntuales, ofreciendo un modelo de pruebas de seguridad continuas, lideradas por expertos e integradas en los flujos de trabajo de ingeniería.

Dhakar vinculó este modelo con el ritmo de cambio del software en muchas organizaciones.

«La mayoría de los modelos de pruebas de seguridad fueron diseñados para un mundo donde el software cambiaba unas pocas veces al año», afirmó Dhakar, Co-Fundadora y CEO de Capture The Bug. «Hoy en día, los equipos de ingeniería lanzan código semanalmente o incluso diariamente. El riesgo cambia constantemente, pero las pruebas no han seguido el ritmo. PTaaS existe para cerrar esa brecha, integrando la experiencia en seguridad directamente en la forma en que los equipos construyen y lanzan software.»

Lanzamiento comercial

Capture The Bug lanzó comercialmente su plataforma en 2024. Anteriormente, operó durante varios años como una consultora de ciberseguridad. Durante ese período, la compañía trabajó con CTOs y CISOs en Nueva Zelanda y Australia, lo que influyó en el diseño de su plataforma y la validación de su enfoque en términos de requisitos de ingeniería y cumplimiento.

La empresa explicó que los nuevos asesores se centrarán en la escalabilidad de la plataforma, la preparación para empresas, la gobernanza y la entrada en el mercado estadounidense. Estos nombramientos coinciden con la continua construcción de la plataforma y el equipo de Capture The Bug desde Nueva Zelanda.

Nuevos asesores

Ninad Narkhede se ha unido como Socio Estratégico del Consejo. Capture The Bug señaló que anteriormente fue Global Head of Cloud Engineering en Visa y actualmente trabaja como CTO en Apoddo. Se espera que asesore sobre la preparación para empresas, la madurez de la gobernanza y las expectativas de seguridad de las grandes organizaciones.

Ellen K. Pao se ha unido como asesora enfocada en liderazgo, gobernanza y resiliencia organizacional. Capture The Bug indicó que Pao es la ex CEO de Reddit, una inversora en tecnología y autora de Reset. Su nombramiento está vinculado a los planes de la empresa para escalar a nivel internacional.

James Tramel se ha unido como Asesor Estratégico y Líder Comercial en Estados Unidos. Capture The Bug señaló que es un ex líder de productos de Microsoft en GitHub, Azure y Copilot. Su función incluye la adopción empresarial, las asociaciones y el crecimiento comercial en Norteamérica.

Dhakar afirmó que estas incorporaciones reflejan el enfoque de la empresa al ingresar a un mercado más amplio.

«Estos asesores han construido plataformas a escala global y comprenden lo que los clientes empresariales esperan en términos de seguridad, confiabilidad y gobernanza», dijo Dhakar. «Su participación nos ayuda a crecer de manera responsable en el mercado estadounidense, manteniendo al mismo tiempo el enfoque en los resultados que importan a los equipos de ingeniería y seguridad.»

Consejo existente

Estos nuevos nombramientos se suman a los miembros existentes del consejo asesor. Capture The Bug indicó que su consejo asesor ya incluye al Dr. Vimal Kumar, Profesor Titular y Jefe del Laboratorio de Ciberseguridad de la Universidad de Waikato, y a Sarah (Forbes) Webb, ex líder de Amazon y actual COO de la empresa de tecnología legal LawVu.

Capture The Bug ha trabajado con empresas SaaS de rápido crecimiento y organizaciones que cotizan en bolsa en Nueva Zelanda y Australia desde el lanzamiento de la plataforma. Entre sus clientes se encuentran LawVu, Paysauce, EROAD, Parkable, Yabble, Whip Around, Cotiss y Blackpearl Group.

La compañía afirmó que su plataforma ha respaldado más de 200 compromisos de seguridad en Nueva Zelanda y en el extranjero.

Resultados para los clientes

Capture The Bug citó comentarios de los clientes sobre los plazos de remediación. Según la empresa, los clientes que utilizan la plataforma informan que las vulnerabilidades se resuelven alrededor de un 40% más rápido en comparación con los enfoques tradicionales de pruebas de penetración.

La compañía atribuyó este cambio a la colaboración en tiempo real entre ingenieros y expertos en seguridad, en lugar de los informes de auditoría retrasados. También señaló que el modelo reduce los hallazgos repetidos durante las auditorías y reduce los costos de seguridad a largo plazo.

Capture The Bug indicó que ya cuenta con clientes en Australia, Estados Unidos e India, y continúa desarrollando su plataforma en Nueva Zelanda.

Dhakar afirmó que la compañía planea desafiar las suposiciones sobre dónde se construyen las plataformas globales de ciberseguridad.

«Existe la percepción de que las plataformas globales de ciberseguridad deben construirse en Silicon Valley con grandes equipos y amplios recursos de capital», dijo Dhakar. «Estamos demostrando que se puede construir una empresa de seguridad de clase mundial desde Nueva Zelanda con un equipo pequeño y enfocado, manteniéndose cerca de los problemas de los clientes y resolviéndolos lo suficientemente bien como para competir a nivel mundial.»

0 comments
0 FacebookTwitterPinterestLinkedinEmail
Tecnología

Hosting Docker Gestionado: Fácil Inicio y Escalabilidad

by Editor de Tecnologia
written by Editor de Tecnologia

Comienza rápidamente con un hosting gestionado basado en Docker y, a medida que crezcas, expande tu infraestructura de forma natural a AWS y GCP.

Este Managed Docker Hosting, centrado en la automatización, está diseñado para startups y pequeñas y medianas empresas. Olvídate de la complejidad de la nube y concéntrate en lo que realmente importa: tu servicio.

Comenzar

0 comments
0 FacebookTwitterPinterestLinkedinEmail