Desplegando.cloud

Marcia Villalba

Podcast y newsletter semanal de noticias sobre AWS y serverless en Español Hosted by Marcia Villalba desplegando.substack.com

  1. hace 1 día

    Construyó un agente para procesar pedidos. Costó 100 veces más de lo necesario.

    Ana es desarrolladora en un e-commerce. Tenía un proceso que se repetía miles de veces al día: llega un pedido, hay que validar el pago, verificar el stock, reservar el producto, actualizar el inventario y notificar al cliente. Todo el mundo hablaba de agentes, así que construyó uno. Tres semanas después: costos disparados, comportamiento impredecible, debugging imposible. El problema no era el código, era que había usado un agente donde necesitaba un workflow. 👉🏽 Mira el video de youtube 💡 La señal estaba escrita en su propio prompt El prompt del agente de Ana decía, literalmente: “Primero validá el pago. Después verificá el stock. Después reservá el producto. Después notificá al cliente.” Eso no es un agente. Es un workflow escrito en lenguaje natural. Cuando el prompt le dice al modelo exactamente qué hacer y en qué orden, el modelo no está tomando decisiones, está siguiendo instrucciones. Y para seguir instrucciones no necesitás un LLM, necesitás un motor de estados. La diferencia que importa ⚙️ Un workflow ejecuta pasos. Sabés de antemano qué va a pasar, en qué orden, y qué hacer si algo falla. Step Functions es el ejemplo perfecto: definís los estados y las transiciones, y AWS ejecuta eso con reintentos automáticos, timeouts e historial completo. 🤖 Un agente toma decisiones. No sabés de antemano qué va a hacer, evalúa la situación, elige herramientas, ajusta su comportamiento según los resultados. Y acá está la clave: el poder de un agente es su capacidad de razonar, y razonar tiene costo. Cada decisión llama a un LLM. Eso cuesta tokens, tarda, y puede comportarse distinto en cada ejecución. Si el proceso no necesita razonamiento, estás pagando ese costo sin ningún beneficio. 3 señales de que tenés un workflow disfrazado de agente 1️⃣ Siempre ejecuta los mismos pasos en el mismo orden. Si corrés el sistema diez veces con inputs similares y la secuencia nunca cambia, el modelo no está decidiendo nada. 2️⃣ El único trabajo del LLM es clasificar o extraer información en un paso. Eso es una función de Lambda que llama a Bedrock para una clasificación puntual, no un agente a cargo del flujo. 3️⃣ Podés escribir todos los pasos en un papel antes de ejecutar. Si el proceso ya está definido, no necesitás que el modelo lo descubra en tiempo de ejecución. El error contrario también existe Andrés tenía un chatbot de soporte técnico y armó un workflow con doce ramas de condiciones y los clientes seguían encontrando casos que no estaban mapeados. Estaba intentando resolver ambigüedad con un árbol de decisión, y la ambigüedad es exactamente el problema que resuelven los agentes. El patrón que uso en producción Los mejores sistemas no eligen entre uno u otro, usan los dos. Workflow como esqueleto, agente solo donde hay juicio real. En el caso de Ana bien resuelto: Step Functions sigue controlando todo el proceso: validar pago, verificar stock, reservar, notificar. Pero hay un paso específico, detectar fraude, que sí requiere interpretación y contexto. Ahí, y solo ahí, entra un agente. El workflow garantiza ejecución. El agente aporta inteligencia donde hace falta, no en todos lados. Resultado: costos -95%, 99.9% de ejecuciones exitosas, y trazabilidad completa de qué pasó en cada paso. 🚀 ¿Querés aprender a diseñar esto en AWS? Tengo un mini-curso gratuito de Agentes IA donde explico exactamente cuándo usar Bedrock Agents, cuándo usar Step Functions, y cómo combinar ambos con arquitecturas y código reales. 🎯 ACCEDER AL MINI-CURSO GRATUITO This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

    Construyó un agente para procesar pedidos. Costó 100 veces más de lo necesario.

  2. hace 5 días

    Las funciones de Lambda ahora tienen un timeout de 90 minutos*

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. Esta semana les traigo algunas noticias interesantes de Lambda y API Gateway. Entre ellas, que ahora Lambda cuenta con timeouts de 90 minutos para las instancias gestionadas. Además, quiero hacerles una pregunta… 📰 Noticias Relevantes ⏳ AWS Lambda amplía el tiempo de ejecución a 90 minutos para instancias gestionadas AWS Lambda Managed Instances ahora permite un tiempo de ejecución de hasta 90 minutos para invocaciones asíncronas y de mapeo de fuentes de eventos (ESM), superando el límite anterior de 15 minutos por seis veces. Esta actualización facilita la gestión de cargas de trabajo como procesamiento de datos, transcodificación de medios, inferencia de inteligencia artificial y trabajos por lotes que requieren ventanas de ejecución más largas sin necesidad de rediseñar las aplicaciones. Es importante destacar que este tiempo de espera más largo se aplica únicamente a Lambda Managed Instances y solo para casos de uso asíncrono y ESM; las invocaciones sincrónicas siguen restringidas a los 15 minutos. AWS también aclara que no hay cargo adicional por el tiempo de espera de 90 minutos, manteniéndose las tarifas estándar de instancias gestionadas. 🔗 Para más información, visita el blog de AWS. 🔒 Amazon API Gateway ahora soporta mTLS para integraciones en backend AWS anunció que Amazon API Gateway ahora puede presentar un certificado ACM a los servicios de backend durante el apretón de manos TLS, habilitando así mutual TLS (mTLS) para integraciones en backend. Anteriormente, API Gateway solo podía presentar un certificado autofirmado. Ahora, puedes usar un certificado firmado por una autoridad de certificación confiable, lo que permite a los backends verificar que las solicitudes provienen verdaderamente de API Gateway. 🔗 Para más información, visita el anuncio de AWS. ⚡ AWS Lambda ahora soporta lectura directa de archivos en Amazon S3 AWS Lambda ha lanzado una nueva función que permite elegir entre leer archivos desde la capa de almacenamiento de alto rendimiento S3 Files o directamente desde el bucket de Amazon S3. Esta nueva configuración de lectura directa está diseñada para optimizar el acceso a archivos de acuerdo a las necesidades de carga de trabajo: las lecturas directas priorizan el máximo rendimiento, mientras que las lecturas del sistema de archivos se centran en la menor latencia. De manera predeterminada, Lambda habilita lecturas directas solo para funciones configuradas con 512 MB de memoria o más. Cuando se activa la lectura directa, los archivos de 1 MB o más se leen directamente desde el bucket de S3, mientras que los archivos más pequeños se sirven a través de la capa de almacenamiento de alto rendimiento. Si se desactiva la lectura directa, todas las lecturas pasan por el almacenamiento de alto rendimiento, lo que es óptimo para un acceso de baja latencia. Esta actualización brinda a los equipos más control sobre la optimización del rendimiento para cargas de trabajo serverless que dependen del acceso a archivos respaldados por S3. 🔗 Para más información, visita el anuncio oficial de AWS 📦 Personaliza los destinos de Amazon API Gateway para logs de ejecución Amazon API Gateway ha mejorado su sistema de logs de ejecución, permitiendo a los equipos gestionar los registros de las solicitudes de una manera más flexible. Ahora es posible redirigir los logs a destinos que tú controles, como Amazon CloudWatch Logs, Amazon S3 y Amazon Data Firehose, en lugar de depender únicamente del grupo de logs manejado por API Gateway. Esta nueva funcionalidad permite definir fuentes de entrega específicas para ciertas etapas de tu API Gateway, lo que otorga una mayor flexibilidad operativa. Además, los logs ahora pueden manejar eventos de mayor tamaño, mejorando la utilidad del pipeline de logs para diagnósticos más detallados. 🔗 Para más detalles, visita el blog de AWS. 🤖 Presentamos Pizza Bot: la bandeja de entrada para agentes de IA de código abierto AWS ha lanzado Pizza Bot, una aplicación de código abierto que transforma la forma en que interactuamos con agentes de IA que operan en segundo plano. En lugar de forzar a los usuarios a observar el trabajo del agente en una ventana de chat o terminal, Pizza Bot ofrece una interfaz estilo bandeja de entrada, donde los resultados y decisiones humanas se presentan solo cuando son necesarios. Diseñada para el trabajo asíncrono, la aplicación permite iniciar tareas manualmente, programarlas o activarlas mediante webhooks. De este modo, los usuarios pueden concentrarse en otras tareas mientras las acciones se ejecutan independientemente. Los resultados se agrupan en una cola de No leídos y los elementos que requieren intervención humana se encuentran en Acciones, facilitando una gestión más fluida de las tareas. Pizza Bot es flexible y permite al usuario tener el control total. Se ejecuta localmente o en infraestructura gestionada por el usuario, admite múltiples proveedores de modelos y almacena datos en archivos locales y SQLite. Esta herramienta se posiciona como una base de código abierto para crear flujos de trabajo de agentes de IA duraderos que requieren persistencia, aprobaciones y puntos de transición claros. 🔗 Para más información, visita el artículo en el blog de AWS sobre Pizza Bot. 🔗 Otras noticias que te pueden interesar 🔧 AWS Lambda durable functions integrates with Pydantic AI → Leer más 🐧 Amazon Linux 2027 is now available in public preview → Leer más 🤖 OpenAI GPT-6 Astra is now generally available on Amazon Bedrock → Leer más 📊 Amazon CloudFront announces API support for flat-rate pricing plans → Leer más 🖥️ AWS MCP Server adds a serverless capability for AWS Lambda functions → Leer más 📚 Amazon Bedrock Managed Knowledge Base now supports automatic sync scheduling for data source connectors → Leer más 🔗 Amazon Bedrock Managed Knowledge Base now supports ServiceNow as a native data source connector → Leer más 🔒 Amazon S3 Object Lock now supports variable retention with event holds → Leer más 🖼️ Dynamic Image Transformation for Amazon CloudFront adds four new features → Leer más 🧠 Amazon Bedrock AgentCore Memory now supports direct ingestion to long-term memory → Leer más 🗄️ Amazon Bedrock Managed Knowledge Base now supports Confluence Data Center as a native data source connector → Leer más 🛠️ Amazon Bedrock Managed Knowledge Base adds APIs and console support for debugging document-level access control → Leer más ⚙️ AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances → Leer más 📚 Artículos Interesantes 💡 Arquitectura de 10 Agentes, 1k Usuarios: Presupuesto de Dos Pizzas al Mes Este artículo detalla cómo diseñar un sistema de IA basado en AWS que maneje alrededor de 1,000 usuarios, manteniendo los costos mensuales de infraestructura extremadamente bajos—equivalentes a ‘dos pizzas’. Se habla de cómo una ingeniería cuidadosa puede reducir drásticamente los costes sin sacrificar la capacidad, sugiriendo una optimización intencionada en lugar de depender de servicios predeterminados o del modelo más pesado para cada paso. Puntos clave: * Costos de infraestructura fijos son la mayor fuga presupuestaria, especialmente servicios como NAT, ALB y componentes siempre activos. * Usar la herramienta más económica y efectiva para cada tarea, como embeddings para recuperación y modelos más fuertes solo donde se necesiten. * Una buena arquitectura consiste en adecuar el patrón a la carga de trabajo, sin recurrir a la configuración más costosa o genérica por defecto. 🎯 Reflexión: La inteligencia en la orquestación y una arquitectura ligera son clave para que un sistema de 10 agentes sea viable a presupuestos de startups, demostrando que la eficiencia no está reñida con la capacidad. 📖 Leer el artículo completo 🚀 Análisis de DuckDB en Amazon DynamoDB sin ETL Este artículo detalla cómo realizar análisis SQL ad hoc en datos de Amazon DynamoDB utilizando DuckDB, sin necesidad de construir o gestionar una tubería ETL tradicional. Puntos clave: * AWS Glue zero-ETL puede replicar datos de DynamoDB en tablas de Apache Iceberg en Amazon S3 sin necesidad de una tubería ETL personalizada. * DuckDB en AWS Lambda puede servir consultas SQL sobre esos datos replicados a través de una URL de función asegurada por IAM. * Este patrón permite análisis ad hoc en datos de DynamoDB mientras minimiza la complejidad operativa y mantiene la tabla fuente centrada en cargas de trabajo transaccionales. 🎯 Reflexión: La integración de DuckDB con DynamoDB a través de AWS Glue presenta una solución ingeniosa para realizar análisis rápidos y ligeros sin comprometer la operatividad cercana de la base de datos en vivo. 📖 Leer el artículo completo 🚀 Cómo Construir una App de Colaboración en Tiempo Real con AWS AppSync y GraphQL Este artículo explica cómo utilizar AWS AppSync como un servicio GraphQL administrado para construir aplicaciones en tiempo real, utilizando una aplicación de colaboración o estilo chat como ejemplo. Puntos clave: * AWS AppSync proporciona una capa GraphQL administrada para la sincronización y actualizaciones de datos en tiempo real. * Las suscripciones de GraphQL son la característica central que habilita experiencias en vivo y basadas en notificaciones. * AWS Amplify ayuda a conectar un frontend en React a AppSync de manera rápida, reduciendo la complejidad de implementación. 🎯 Reflexión: La implementación de AppSync simplifica enormemente la construcción de aplicaciones en tiempo real, permitiendo a los desarrolladores enfocarse en la experiencia

  3. 7 sep

    🎓 Las microcredenciales de AWS ahora son gratis

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. La semana pasada estuvo re tranquila de lanzamientos pero ya esta se vino muy interesante. Hay varias cosas a destacar. La primera es algo que no es tan nuevo que son las microcertificaciones, pero ahora son gratis y me parecen genial y además están en español. Las probaste? Yo a ver si tengo dos horas seguidas en la cual me puedo sentar y hacer la de serverless. Ya les contaré. 📢 Si te gusta esta newsletter, compártela con tus colegas para que más personas puedan estar al día con el mundo serverless. Si tienes comentarios o sugerencias, escríbeme en LinkedIn, X, o Instagram. ¡A desplegar! 🚀 📰 Noticias Relevantes 🎓 Microcredenciales de AWS ahora son gratuitas: ¿por qué es importante? AWS ha anunciado que sus microcredenciales, evaluaciones prácticas que permiten a los desarrolladores demostrar habilidades en la nube, ahora están disponibles de forma gratuita y sin necesidad de una suscripción a AWS Skill Builder. Esto las hace más accesibles para una audiencia global. Estas evaluaciones prácticas validan la capacidad de resolver tareas del mundo real, como la configuración, optimización y solución de problemas en los servicios de AWS, todo en un entorno realista. Se subraya que las microcredenciales no reemplazan a las certificaciones de AWS; más bien, las complementan al validar habilidades prácticas. La primera serie de microcredenciales incluye áreas como Serverless, Inteligencia Artificial, Redes de Aplicaciones y Respuesta a Incidentes, con más planeadas para el 2026. 🔗 Para más información, visita el blog de AWS sobre microcredenciales. 📦 Amazon Kinesis Data Streams ahora entrega datos directamente a los buckets de S3 Amazon Kinesis Data Streams ha lanzado una nueva funcionalidad que permite la entrega de datos de streaming directamente a los buckets de Amazon S3 de propósito general. Esta mejora elimina la necesidad de gestionar streams de entrega separadas para enviar los datos a S3, optimizando el proceso considerablemente. Los datos se almacenan en su formato original, haciéndolos adecuados para archivado, respaldo, reprocesamiento y análisis por lotes. AWS describe esta opción como completamente gestionada y serverless, lo que permite a los usuarios pagar solo por los datos entregados satisfactoriamente. 🔗 Para más información, visita la página oficial de Amazon Kinesis Data Streams 🚀 AWS Lambda ahora admite SnapStart para funciones de imágenes de contenedor AWS Lambda ha dado un gran paso al anunciar que SnapStart ahora es compatible con funciones empaquetadas como imágenes de contenedor. Esta innovadora función promete reducir los tiempos de inicio de varios segundos a niveles de menos de un segundo, lo que representa una mejora significativa en el rendimiento para las cargas de trabajo serverless que utilizan imágenes de contenedor. 🔗 Para obtener más información, visita la página oficial de AWS Lambda. 🚀 AWS adquiere DuckLabs para revolucionar el futuro de la analítica AWS ha anunciado un acuerdo definitivo para adquirir DuckLabs, la compañía con sede en Ámsterdam detrás de DuckDB, una base de datos analítica de código abierto. Este movimiento busca fusionar la rapidez de DuckDB en el análisis de datos pequeños con el ecosistema de analítica a gran escala de AWS. 🔗 Para más información, visita el blog de AWS. 🔗 Aurora DSQL ahora soporta restricciones de clave foránea AWS ha anunciado que Aurora DSQL ahora admite restricciones de clave foránea, un avance significativo en la compatibilidad con PostgreSQL para su base de datos SQL distribuida. Esta actualización permite a los equipos definir relaciones directamente en la base de datos, en lugar de imponer la integridad referencial solo en el código de la aplicación. La nueva capacidad soporta comportamientos de restricciones comunes como NO ACTION, RESTRICT, CASCADE, SET NULL y SET DEFAULT, además de MATCH FULL, MATCH SIMPLE y restricciones de clave foránea diferibles. AWS también destaca que Aurora DSQL mantiene la integridad referencial a través de la verificación de instantáneas durante la transacción y la resolución de conflictos en el momento de la confirmación, asegurando que las transacciones confirmadas no violen las reglas de clave foránea. 🔗 Para más información, visita el artículo de AWS 🔗 Otras noticias que te pueden interesar 🔒 AWS Lambda ahora soporta políticas basadas en recursos IAM completas → Leer más 🛠️ AWS Lambda introduce runtimes gestionados en vista pública para Node.js 26 y Python 3.15 → Leer más 🔗 AWS Lambda MicroVMs ahora soporta AWS PrivateLink → Leer más ☕ IAM Roles Anywhere ahora proporciona un plugin de Java para el AWS SDK → Leer más 📦 Mountpoint para Amazon S3 añade controles de uso de memoria → Leer más 🔍 Amazon Bedrock Managed Knowledge Base introduce configuración administrada por el usuario para fuentes de datos de SharePoint, OneDrive y Confluence → Leer más 🔗 Amazon Bedrock Managed Knowledge Base ahora soporta ServiceNow como conector nativo de fuente de datos → Leer más 🔄 Amazon Bedrock Managed Knowledge Base ahora soporta programación de sincronización automática para conectores de fuentes de datos → Leer más 🛡️ Amazon Bedrock AgentCore Identity ahora ofrece un portal de consentimiento gestionado → Leer más 🔗 Amazon Bedrock AgentCore Memory ahora soporta variables de espacio de nombres flexibles → Leer más 🔒 Amazon Bedrock AgentCore Memory ahora soporta control de acceso detallado → Leer más ☁️ AWS MCP Server añade una capacidad sin servidor para funciones de AWS Lambda → Leer más ✉️ Amazon SES ahora soporta la firma de correos S/MIME → Leer más 🔄 Amazon Kinesis Data Streams ahora soporta una función de prueba en seco para validar solicitudes de API → Leer más 🧠 Claude Fable 5.1, el nuevo modelo de frontera de Anthropic, ahora está disponible en AWS → Leer más ⏱️ Amazon CloudWatch ahora soporta períodos de calentamiento para alarmas → Leer más 🤖 Amazon Cognito ahora soporta autorización máquina a máquina sin un dominio de usuario → Leer más 🔍 Amazon OpenSearch Service añade nuevos Cluster Insights para un diagnóstico más rápido del estado del clúster → Leer más 📊 Amazon Kinesis Data Streams anuncia tablas de streaming, entregando datos a tablas Apache Iceberg en Amazon S3 → Leer más 🎬 Video de la Semana Un agente de soporte le inventó una política de reembolsos a un cliente. Se la dijo como si fuera un hecho. El desarrollador la buscó línea por línea en el código y no encontró ningún bug — porque el problema no estaba ahí. Estaba en el system prompt. Esta semana te como escribir un system prompt que funciona. 📚 Artículos Interesantes 📧 Programando Campañas de Email a Gran Escala con Amazon EventBridge Scheduler El artículo detalla cómo Amazon EventBridge Scheduler puede usarse para enviar campañas de email personalizadas a nivel de cada destinatario. Puntos clave: * EventBridge Scheduler puede actuar como el despachador de tiempo de envío por destinatario para campañas de email. * AWS Step Functions Distributed Map ayuda a crear millones de horarios en paralelo. * Amazon SES entrega los emails personalizados cuando EventBridge Scheduler activa cada horario. 🎯 Reflexión: La combinación de EventBridge Scheduler y Step Functions demuestra cómo es posible escalar campañas de email sin necesidad de mantener infraestructura infrautilizada, optimizando la entrega y personalización de los mensajes. 📖 Leer el artículo completo 🚀 AWS Lambda Managed Instances Este artículo analiza las instancias gestionadas de AWS Lambda, centrándose en las compensaciones prácticas de esta nueva opción híbrida de computación. Puntos clave: * Reducción del dolor por tiempos de espera: Las instancias gestionadas pueden eliminar prácticamente los tiempos de espera para cargas de trabajo constantes, mejorando el rendimiento de aplicaciones sensibles a la latencia. * Modelo de precios similar al de EC2: Incluye un cargo por solicitudes y una tarifa de gestión del 15%. Los beneficios de costo dependen de la consistencia del tráfico. * Complejidad operativa y velocidad de escalado: Introducen consideraciones sobre la velocidad de escalado, siendo más adecuadas para tráfico predecible. 🎯 Reflexión: Las instancias gestionadas de Lambda ofrecen una alternativa viable para cargas de trabajo predecibles que requieren menor latencia y mejor rendimiento, aunque a expensas de la simplicidad y escalado elástico rápido de Lambda. 📖 Leer el artículo completo 📦 DynamoDB Streams: No Es Un Outbox Este artículo argumenta que, aunque los DynamoDB Streams son útiles para reaccionar a los cambios a nivel de ítems, no son un verdadero outbox transaccional, ya que se generan después de la escritura en la base de datos, y no como parte de la misma transacción atómica. Puntos clave: * DynamoDB Streams captura cambios en la tabla, pero no proporciona garantías atómicas de ‘escribir datos + escribir evento’. * El patrón de outbox transaccional sigue siendo la opción más segura cuando la fiabilidad del evento debe estar atada a la transacción de datos. * Utiliza DynamoDB Streams como un mecanismo de captura de datos, no como un sustituto de la semántica del outbox. 🎯 Reflexión: La comprensión clara de las diferencias entre DynamoDB Streams y el patrón de outbox es fundamental para diseñar sistemas robustos en arquitecturas centradas en eventos. Es vital seleccionar la herramienta adecuada que se alinee con nuestras necesidades de transacciones y fiabilidad de eventos. 📖 Leer el artículo com

  4. 4 sep

    SQS, SNS, EventBridge o Kinesis: ¿cuál usás?

    Los cuatro mueven mensajes. Los cuatro son serverless. Los cuatro aparecen en casi todos los diagramas de arquitectura que vas a ver de AWS. Y la pregunta que más me hacen es siempre la misma: ¿cuál elijo para mi proyecto? La respuesta corta es “depende”. La respuesta larga es este post — con un árbol de decisión al final que resuelve la duda en menos de 30 segundos. 💡 No compiten entre sí, resuelven problemas distintos Antes de entrar en cada uno, sacate una idea de la cabeza: SNS no es la versión vieja de EventBridge, y Kinesis no es “SQS pero más caro”. Cada uno existe para un problema diferente. Cuatro analogías simples y te queda clarísimo: * SQS es una fila del banco — dejás un mensaje y el cajero (un solo consumidor) lo atiende cuando puede. * SNS es un grupo de WhatsApp — mandás un mensaje y todos los que están en el grupo lo reciben al mismo tiempo. Si alguien no está mirando el teléfono, se lo pierde. * EventBridge es un operador telefónico inteligente — recibe la llamada y la conecta con el departamento correcto según lo que decís, no solo según a quién iba dirigida. * Kinesis es una cinta transportadora — los datos fluyen sin parar, en orden, y varias estaciones de trabajo pueden leer de la misma cinta al mismo tiempo, incluso volver atrás si hace falta. Con eso en la cabeza, vamos servicio por servicio: SQS Tu opción cuando necesitás desacoplar dos servicios y absorber picos de tráfico sin perder nada: los mensajes quedan guardados hasta 14 días. Tiene dos sabores: Standard (rapidísimo, orden no garantizado) y FIFO (orden sagrado, con límite de velocidad). No lo uses si el mismo mensaje tiene que llegar a varios consumidores a la vez. SNS El rey del fan-out: publicás una vez y disparás varias acciones en simultáneo (un email, una alerta, un log). El dato que a casi todos les agarra de sorpresa: SNS no tiene memoria. Si el suscriptor no está disponible en ese momento, el mensaje se pierde. Por eso el combo más clásico en arquitecturas serverless es SNS + SQS: fan-out inmediato con la resiliencia de la cola detrás. EventBridge Como SNS pero con cerebro: puede leer el contenido del evento y rutearlo con reglas (”si el pedido es de más de $500, mandalo a auditoría”). Es también el que trae conectores nativos para Stripe, Shopify, Auth0 y otros SaaS, si estás arrancando una arquitectura event-driven desde cero, probablemente sea tu punto de partida. Kinesis Honestamente, la mayoría de los proyectos no lo necesitan. Es para flujo masivo y continuo de datos: logs de miles de servidores, clicks de millones de usuarios, sensores IoT. La diferencia clave con SQS es que los datos no desaparecen al leerlos, podés hacer replay si algo sale mal. Si estás dudando si lo necesitás, probablemente todavía no. 🧭 El árbol de decisión de 30 segundos ¿Necesitás que varios servicios reciban el mismo evento? * Sin lógica de ruteo → SNS * Con lógica de ruteo según el contenido → EventBridge ¿Necesitás absorber picos y que el consumidor procese a su ritmo? → SQS ¿Tenés un flujo continuo y masivo de datos que necesitás poder re-leer? → Kinesis ¿Tu caso es simple y no necesitás nada sofisticado? → Empezá con SNS + SQS y evolucioná si hace falta. No hay un servicio “mejor”. Hay uno mejor para tu caso y la complejidad que no necesitás hoy es complejidad que vas a tener que mantener mañana. 🚀 ¿Y cómo se orquestan estos servicios en un flujo real? Estos cuatro suelen aparecer combinados dentro de un proceso más grande, coordinados por Step Functions. Tengo un mini-curso gratuito donde construimos esa orquestación paso a paso — el mismo patrón que uso para automatizar procesos completos sin escribir la lógica de negocio en el código. 🎯 ACCEDER AL MINI-CURSO GRATUITO 💬 Tu turno ¿Cuál de estos cuatro usás más seguido, y cuál te genera más dudas todavía? Contame en los comentarios 👇 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  5. 28 ago

    Tus proyectos no te consiguen trabajo

    Estoy segura que escuchaste mil veces este consejo: “hacé proyectos para demostrar tu experiencia”. Y como buen alumno, hiciste varios. Ahí seguís, esperando que te llamen para ese trabajo. Es un buen consejo. Pero es un consejo a medias — porque nadie te dice lo que realmente significa construir estos proyectos. Después de 20 años en tech, y de haber contratado a decenas de personas en empresas como AWS, te puedo decir exactamente qué miramos en un portfolio. Y no es código. Son señales de vida. 💡 Proyecto muerto vs. proyecto vivo Un proyecto muerto es el que solo existe como código: un repo que nadie clona, y lo reconocés por estas señales. * No está desplegado en ningún lado — para verlo funcionar habría que clonarlo, instalar dependencias, configurar credenciales de AWS y cruzar los dedos. * Nadie lo usó nunca. Ni siquiera vos, después de programarlo. * El README es una lista de instalación (npm install, npm run dev) y no cuenta qué problema resuelve ni para quién. * No hay una decisión de arquitectura explicada — usaste DynamoDB, Step Functions, Lambda, pero en ningún lado dice por qué esos y no otros. Un proyecto vivo es completamente distinto: * Se puede probar sin fricción: un link, una URL, un bot al que le podés escribir ahora mismo. * Alguien lo usa o lo usó de verdad — una ONG, el negocio de un conocido, una comunidad de algún hobby. No sos vos simulando ser el usuario. * Tiene un diagrama de arquitectura que explica las decisiones, no solo un dibujo bonito: por qué DynamoDB y no Postgres, por qué Step Functions y no una sola Lambda. * El README cuenta una historia — el problema de negocio, quién lo usa, qué resultado concreto generó (”le ahorré 10 horas por semana”, “procesa 200 pedidos por día sin intervención manual”). * Tiene señales de haber pasado por producción real: observabilidad, pipeline de despliegue, algo que se rompió y cómo lo arreglaste. La diferencia no es cuánto código escribiste. Es cuánta evidencia dejaste de que ese código sostiene algo real. ¿De dónde saco un problema real si nadie me está pagando por resolver nada? No hace falta que te contraten para esto. Hace falta encontrar a alguien que ya tiene el problema y ofrecerte a resolvérselo con lo que sabés: una causa que te importe, la fricción de tu propio trabajo, el negocio de un conocido, o crear tu propio producto. 🚀 Las inscripciones a Desplegando.cloud están abiertas Si ninguno de esos caminos te cierra — si no sabés qué proyecto construir, o sabés qué construir pero te falta guía para hacerlo bien — te puedo ayudar. Es la razón número uno por la que la gente se une a la comunidad: el plan de estudio te da un proyecto real y guiado, semana a semana (Agentes de IA, WebApps o Step Functions). En la comunidad vas a encontrar pares y acompañamiento para construir tus proyectos! Abrimos cupos limitados y las inscripciones cierran el 31 de agosto. 👉 VER LOS DETALLES E INSCRIBIRME 🗣️ Lo que dicen los que ya lo están haciendo “Cada semana tenía algo concreto que aprender y aplicar. No te quedás solo en la teoría, vas construyendo poco a poco hasta terminar con algo propio que podés mostrar con orgullo.” — Oscar Darío Florez Diaz, Software Developer 💬 Tu turno Volvé a tu GitHub ahora mismo: ¿cuántos proyectos tenés, y de esos, cuántos alguna vez usó alguien que no fueras vos? Contame en los comentarios 👇 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  6. 24 ago

    Grok 4.6 ya está disponible en Amazon Bedrock 🚀

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. Esta semana fue otra semana de construcción: me enfoqué en terminar el plan de estudio de agentes que abre pronto. Para ayudar a los que están por arrancar, lancé un video con 5 ideas de proyectos de agentes — si estás estudiando esto, seguro te sirvan también. Te cuento más en la sección del video de la semana. Y si querés que te avise apenas abran las inscripciones a la comunidad, anotate en la lista de espera. ¡A desplegar! 🚀 📰 Noticias Relevantes 🔐 Amazon DynamoDB Streams ahora admite control de acceso basado en atributos Amazon ha anunciado que DynamoDB Streams ahora admite control de acceso basado en atributos (ABAC), permitiendo que los equipos utilicen condiciones basadas en etiquetas en las políticas IAM para un control de acceso más flexible a los streams, con menos políticas necesarias. Esta función es especialmente beneficiosa para las organizaciones que gestionan múltiples aplicaciones o entornos. La característica permite hasta 50 etiquetas por stream, las cuales pueden utilizarse en condiciones de políticas IAM para permitir o denegar acciones específicas. AWS ilustra ejemplos como otorgar acceso solo a streams etiquetados como producción, bloqueando los que no lo están, lo que ayuda en la segmentación de entornos y en el cumplimiento normativo. 🔗 Para más información, visita la página de novedades de AWS 📝 AWS CloudShell presenta un editor de archivos visual integrado AWS ha anunciado que CloudShell ahora incluye un editor de archivos visual que se lanza directamente desde una sesión de terminal con un solo comando edit, sin necesidad de configuración. Esta mejora elimina la dependencia de editores basados en terminal para realizar cambios rápidos en archivos dentro del entorno basado en navegador de CloudShell. 🔗 Para más información, visita el blog de AWS sobre el editor visual de CloudShell 🌐 Amazon Bedrock amplía su búsqueda en la web con acceso externo AWS ha anunciado una nueva característica para Amazon Bedrock Web Search que permite la recuperación de contenido directamente desde la web pública. Con la incorporación del parámetro external_web_access, ahora es posible fundamentar las respuestas del modelo en la información más actualizada, siendo especialmente útil para casos como resultados deportivos en vivo, precios y documentación recién publicada. Este nuevo recurso permite que los equipos mantengan un control de los datos. Si es necesario limitar la búsqueda a los límites de AWS, se puede configurar external_web_access: false, restringiendo los resultados al índice web interno de AWS y al grafo del conocimiento, asegurando que la información no salga de sus fronteras. Para utilizar el acceso web externo, se debe otorgar el permiso IAM correspondiente y dejar el parámetro en su configuración predeterminada true. 🔗 Para más información, visita el anuncio oficial de AWS. 🚀 Amazon Bedrock ahora soporta SpaceXAI Grok 4.6 con inferencia interregional Amazon Bedrock ha lanzado el soporte para SpaceXAI Grok 4.6, un modelo de vanguardia diseñado para tareas de codificación, trabajo basado en agentes y conocimiento. Esta actualización permite a los clientes acceder al modelo a gran escala mediante la inferencia interregional, optimizando el enrutamiento de solicitudes a través de múltiples regiones de AWS para mejorar el rendimiento y reducir costos. 🔗 Para más información, visita el artículo oficial de Amazon: 🔐 Actualizaciones en la experiencia de inicio de sesión de AWS AWS ha comenzado a implementar actualizaciones en la experiencia de inicio de sesión y registro, con el objetivo de hacer el acceso a las cuentas de AWS más consistente y fácil de usar. Estas mejoras incluyen nuevas opciones para crear y acceder a cuentas, además de una página de inicio de sesión rediseñada y una selección de sesiones actualizada para soportar el nuevo flujo. El principal objetivo de este rediseño es simplificar cómo diferentes tipos de usuarios inician sesión, asegurando una experiencia consistente en todos los dispositivos y tipos de cuentas. Este flujo actualizado busca mejorar tanto la creación de cuentas como la autenticación, y AWS lo está introduciendo gradualmente a los clientes. 🔗 Para más información, visita el blog de AWS sobre la experiencia de inicio de sesión. 🔗 Otras noticias que te pueden interesar 💳 AgentCore payments ya está disponible en Amazon Bedrock → Leer más 🔑 AWS IAM ahora soporta 20 políticas gestionadas por rol por defecto → Leer más 📊 Amazon CloudWatch Pipelines añade procesadores GeoIP, RDS y XML → Leer más 🔍 Amazon Aurora DSQL ahora soporta Amazon CloudWatch Database Insights → Leer más 🌐 Amazon CloudFront ahora soporta Control de Acceso de Orígenes (OAC) para Puntos de Acceso Multi-Región de Amazon S3 → Leer más 🔑 Amazon Timestream para InfluxDB ahora soporta claves gestionadas por el cliente → Leer más 📧 Amazon SES ahora soporta parámetros de anulación para el seguimiento de aperturas y clics → Leer más 🗺️ Amazon Location Service ahora soporta filtrado por categoría y densidad de POI en estilos de mapas → Leer más ☁️ Amazon MWAA Serverless ahora soporta PythonOperator y BashOperator → Leer más 🎬 Video de la Semana En el video de esta semana te dejo 5 ideas de proyectos de agentes en AWS, de principiante a avanzado. No importa cuál elijas — todos siguen el mismo estándar: propósito real, arquitectura pensada y desplegada con infraestructura como código, nada de tutorial copiado paso a paso. 📚 Artículos Interesantes Les dejo varios artículos donde se usan DynamoDB Vectors Search que salió hace poco. 🔍 Amazon DynamoDB Vector Search sin Vector Store Separado Amazon DynamoDB ha dado un gran paso al permitir la búsqueda vectorial nativa directamente sobre sus datos operativos. Esto significa que ya no es necesario mantener un vector store separado, lo que simplifica la arquitectura de búsqueda semántica. Puntos clave: * Embeddings almacenados junto a los datos: Ahora puedes almacenar embeddings junto con los datos de negocio en la misma tabla de DynamoDB. * No más bases vectoriales externas: Eliminación de la necesidad de una base vectorial externa o una pipeline de sincronización. * Reducción de la complejidad operativa: Ajuste perfecto para arquitecturas serverless, facilitando la escalabilidad. 🎯 Reflexión: Con la búsqueda vectorial nativa, DynamoDB se convierte en una herramienta más poderosa para los desarrolladores, permitiendo crear experiencias de búsqueda más rápidas y eficientes, mientras se minimiza la complejidad operativa. 📖 Leer el artículo completo 🤖 Arquitectura Unificada para Agentes de IA con DynamoDB y Bedrock En este artículo, se explora cómo construir una arquitectura de agentes de IA en AWS que utiliza una única tabla de DynamoDB para datos operativos y búsqueda semántica, eliminando la necesidad de depender de una base de datos vectorial separada. Se integran agentes de Amazon Bedrock con la búsqueda vectorial nativa de DynamoDB para que el agente maneje consultas estructuradas y recuperaciones basadas en similitud en un solo lugar. Puntos clave: * DynamoDB como base de datos operativa y tienda vectorial: DynamoDB puede actuar como la base de datos operativa y el almacén vectorial para agentes de IA. * Actualizaciones automáticas de incrustaciones con DynamoDB Streams: DynamoDB Streams puede automatizar actualizaciones de incrustaciones, manteniendo frescos los resultados de búsqueda semántica. * Uso de grupos de acción Lambda con agentes de Bedrock: Los agentes de Bedrock pueden utilizar grupos de acción Lambda para realizar operaciones de búsqueda y datos sin necesidad de una base de datos vectorial separada. 🎯 Reflexión: La combinación de DynamoDB y Bedrock permite crear sistemas de IA más simples y mantenibles, optimizando la eficiencia operativa y reduciendo la complejidad arquitectónica. 📖 Leer el artículo completo 🧭 Mejorando la Búsqueda Semántica en DynamoDB El artículo explica cómo añadir búsqueda semántica a una tabla de DynamoDB existente sin necesidad de trasladar los datos a una base de datos vectorial separada. La idea central es almacenar incrustaciones (embeddings) directamente en los elementos existentes, crear un índice vectorial nativo sobre ese atributo de incrustación y luego consultar la tabla mediante búsqueda de similitud. Esto simplifica la arquitectura al mantener juntos los datos de búsqueda y operativos en DynamoDB. Puntos clave: * Soporte para índices vectoriales nativos: DynamoDB permite la búsqueda semántica directamente sobre los datos existentes en la tabla. * Actualización sin migración completa: Se puede utilizar un flujo de UpdateTable para mejorar tablas existentes sin necesidad de recrearlas. * Proceso de retroalimentación: Se necesita un proceso único de retroalimentación para generar y almacenar incrustaciones de los registros existentes. 🎯 Reflexión: Este enfoque simplificado para añadir búsqueda semántica a tables de DynamoDB no solo mejora la eficiencia, sino que también permite a las organizaciones aprovechar los datos existentes con mayor facilidad y ofrece una arquitectura más cohesiva. 📖 Leer el artículo completo 🖥️ Tres Maneras de Gestionar Archivos en CloudShell Este artículo se centra en tres formas prácticas de gestionar archivos desde CloudShell. Puntos clave: * CloudShell soporta editores de terminal comunes como vim y nano para la edición directa de archivos. * El comando edit abre archivos en el editor integrado de CloudShell para una experiencia más visual. * La carga y descarga de archivos a

  7. 21 ago

    6 errores de AWS que te pueden costar una fortuna

    Pedro estaba aprendiendo AWS. Quiso probar un servicio para procesar un video de cinco segundos. Le costó ochenta y cinco dólares. Ochenta y cinco dólares por procesar un video de cinco segundos. Eligió el servicio equivocado, no puso límites, y cuando se dio cuenta ya era tarde. Ese miedo — “¿cuánto me va a costar esto?” cada vez que querés probar algo en AWS — es lo que más me frenan de la gente que empieza. Y la buena noticia es que AWS no tiene por qué ser caro: yo tengo múltiples apps en producción y pago menos de cinco euros por mes. Pero para llegar ahí tuve que aprender a evitar seis errores. 💡 Los 6 errores que te hacen pagar de más 1. No tener alarmas de billing AWS te deja poner alarmas de costo gratuitas (Budget Alerts). Una al 50% de tu presupuesto, otra al 80%, otra al 100%. La mayoría no las configura hasta que llega la primera factura que duele — no seas esa persona. Son dos alertas de presupuesto gratis, no hay excusa. 2. No usar serverless para tráfico bajo o impredecible Un EC2 corriendo 24/7 te cobra las 24 horas, incluso a las 3 de la mañana cuando nadie lo usa. Con serverless pagás por ejecución: si nadie usa tu servicio, pagás cero. Lambda te da un millón de requests gratis por mes — para siempre, no por 12 meses. Para proyectos personales o de tráfico variable, serverless gana casi siempre. 3. No aprovechar el Free Tier permanente Además de los créditos iniciales de cuenta nueva, muchos servicios tienen capa gratuita para siempre: Lambda (1M requests/mes), DynamoDB (25GB), SNS, SQS, Step Functions y más. Con eso podés construir una aplicación completa sin gastar un centavo. Mi factura de 4. Elegir servicios por comodidad, no por costo Usar RDS cuando DynamoDB alcanza: la instancia más chica de RDS te cuesta ~$15/mes corriendo 24/7, contra un DynamoDB que puede costarte cero con poco tráfico. O meter tus funciones de Lambda en una VPC “por las dudas” y terminar pagando un NAT Gateway que cuesta ~$32/mes solo por existir, más el costo por dato procesado. La calculadora de AWS es tu amiga — usala antes de desplegar, no después. 5. No entender el modelo de pricing de cada servicio Lambda cobra por invocaciones y duración. S3 por almacenamiento y requests. DynamoDB por lecturas y escrituras. API Gateway por llamada. CloudFront por transferencia de datos. Son modelos completamente distintos, y si no los entendés terminás como Pedro. Regla simple: si no sabés cuánto te va a costar, no lo despliegues. 6. Olvidarte del almacenamiento El error silencioso. CloudWatch Logs cobra por giga ingerido, y por defecto guarda los logs para siempre. Vi cuentas donde CloudWatch terminó siendo el servicio más caro — más que Lambda, más que DynamoDB — solo porque nadie le puso retención a los logs. Mismo problema con buckets de S3 que creás para probar algo y te olvidás. El storage es como la humedad: no lo ves, pero se acumula. 🚀 ¿Querés construir en AWS sin gastar de más? Tengo un mini-curso gratuito donde diseñamos una WebApp serverless completa — el tipo de arquitectura que, bien elegida, te cuesta centavos por mes. 🎯 ACCEDER AL MINI-CURSO GRATUITO This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com

  8. 17 ago

    AWS Agent Plugins: empaquetá tu agente una vez, usalo en todos lados

    ¡Bienvenidos a Desplegando.cloud! 🚀 Desplegando.cloud es tu fuente semanal en español para mantenerte al día con lo más relevante de AWS y Serverless. Esta semana me la pasé armando el próximo plan de estudio que va a tener la comunidad, viendo cómo estructurar las tareas para que puedan construir su primer agente de IA sin agobiarse. Hay tantas preguntas que responder en este mundo nuevo, más allá de la tecnología: ¿es realmente necesario un agente acá? ¿Cómo defino las instrucciones de este agente? ¿Cómo manejo el contexto? ¿Qué herramientas le agrego? Estas primeras semanas del plan de estudio van a estar cargadas de preguntas de diseño — las mismas que son fundamentales para cualquier proyecto de software, no solo para agentes. Si querés enterarte primero, antes de que abran los cupos, anotate en la lista de espera. ¡A desplegar! 🚀 📰 Noticias Relevantes 🔌 AWS apoya los Agent Plugins: un estándar abierto para extensiones portátiles de agentes Esta semana, AWS anunció su apoyo a los Agent Plugins 1.0.0, un estándar abierto y neutral para empaquetar extensiones de agentes de inteligencia artificial en un formato portátil. El objetivo es permitir que los desarrolladores empaqueten habilidades de agentes y configuraciones de servidores MCP una vez y las reutilicen en clientes compatibles, evitando la necesidad de reconstruir extensiones para cada herramienta o plataforma. 🔗 Para más información, visita el blog de AWS 💡 AWS Billing y Cost Management lanza Dashboards Gestionados para Visibilidad Financiera Instantánea AWS ha presentado los Dashboards Gestionados en AWS Billing y Cost Management, una herramienta que proporciona a los equipos visibilidad instantánea sobre el gasto en la nube sin necesidad de configuraciones previas. Estos dashboards están preconfigurados, son de solo lectura y se llenan automáticamente con los datos de tu cuenta, permitiendo a los usuarios observar rápidamente las tendencias de costos, los principales impulsores de servicio y el rendimiento de los compromisos. La funcionalidad incluye cinco dashboards curados que abarcan tres capas de visibilidad: un dashboard general de costos y tendencias, dos dashboards por categoría de servicio para Computación y Base de Datos, y dos dashboards de compromisos para Reservas y Planes de Ahorro. Un pestaña dedicada de Gestionados y los íconos de candado permiten distinguir estos dashboards de los personalizados, aunque los usuarios pueden duplicar un dashboard gestionado para crear su propia versión. 🔗 Para más información, visita el blog de AWS sobre la gestión de costos y facturación. 🌐 Amazon Bedrock lanza búsqueda web para una respuesta fundamentada en modelos Amazon anunció la disponibilidad general de la Búsqueda Web en Amazon Bedrock, una capacidad incorporada en el servidor que ayuda a los modelos fundamentales a fundamentar sus respuestas en conocimientos web actuales. La proposición de valor principal es la simplicidad: los desarrolladores pueden agregar respuestas basadas en la web sin necesidad de integrar proveedores de búsqueda externos o manejar revisiones de seguridad adicionales. Cuando se habilita la Búsqueda Web, Bedrock gestiona todo el ciclo de vida de la búsqueda en el servidor. El modelo determina si una consulta necesita información actualizada, Bedrock formula la búsqueda, recupera el contenido relevante de su índice web y grafo de conocimiento, y devuelve fragmentos de origen, URLs y títulos para que la respuesta final pueda ser citada y fundamentada. 🔗 Para más información, visita el artículo de Amazon Bedrock 🔧 AWS IAM presenta el administrador de roles para configurar roles IAM en servicios de AWS AWS ha anunciado la disponibilidad general del administrador de roles en AWS Identity and Access Management (IAM), una herramienta que configura automáticamente los roles IAM necesarios para los servicios de AWS compatibles. Cuando un usuario configura un servicio compatible en la consola, el administrador de roles puede crear un rol predeterminado automáticamente o reutilizar un rol existente que ya cumpla con los permisos requeridos. Esta función está diseñada para facilitar el inicio con los servicios de AWS al eliminar gran parte del trabajo manual de configuración de roles IAM. Además, AWS afirma que los usuarios pueden activar o desactivar el administrador de roles en cualquier momento y revisar las plantillas gestionadas por AWS que despliega en su nombre. 🔗 Para más información, visita el anuncio oficial de AWS IAM 🔗 Otras noticias que te pueden interesar 🔒 AWS Identity and Access Management mejora la asignación de roles IAM a usuarios de la fuerza laboral con el administrador de acceso a cuentas → Leer más 🐍 Presentamos los entornos de prueba pública en AWS Lambda, comenzando con Node.js 26 y Python 3.15 → Leer más 📦 Amazon SES ahora admite seguimiento de clics con rutas de URL personalizadas para el enlace profundo de aplicaciones móviles → Leer más 🏗️ Amazon Bedrock expande la asignación de costos de IAM principal al endpoint bedrock-mantle → Leer más 🔑 AWS Secrets Manager añade soporte para secretos externos gestionados para Jenkins y SonarQube → Leer más 🔍 Amazon OpenSearch Serverless ahora soporta hasta 10,000 colecciones por grupo de colecciones → Leer más 🌍 El Centro de Identidad de AWS IAM admite la opción de múltiples regiones con un solo clic para nuevas instancias de organización → Leer más 💡 Amazon Cognito ahora disponible como habilidad en el Kit de Herramientas para Agentes de AWS → Leer más ⏰ Amazon CloudWatch Alarms ahora soporta ventanas de evaluación de reloj calendario → Leer más 🎬 Video de la Semana ¿Trabajo full-time, quizás hijos, una casa que mantener — y aun así sentís que tenés que seguir aprendiendo para no quedarte atrás? El problema no es que te falte disciplina. En el video de esta semana te muestro los sistemas concretos que uso (y que le funcionan a la gente de la comunidad) para sostener el estudio semana tras semana, sin madrugar ni sacrificar el fin de semana con tu familia. 📚 Artículos Interesantes 🤖 Orquestación de Arquitecturas de IA Multi-Agente con Amazon S3 Files El artículo detalla cómo Amazon S3 Files puede funcionar como un sistema de archivos compartido para sistemas de IA multi-agente, permitiendo a los agentes acceder a un espacio de trabajo común con acceso a archivos al estilo POSIX. Esto simplifica las operaciones de colaboración entre múltiples agentes en servicios como EC2, Lambda, EKS, ECS en Fargate y Amazon Bedrock AgentCore Runtime. Puntos clave: * Sistema de archivos compartido al estilo POSIX: Permite la colaboración eficiente mediante archivos y directorios. * Uso de archivos como memoria de trabajo: Reduce la inflación de prompts y mejora el manejo de resultados intermedios. * Flujos de trabajo multi-agente simplificados: La orquestación es más sencilla si se configura correctamente el bucket, VPC y los permisos. 🎯 Reflexión: Amazon S3 Files ofrece una solución práctica para la colaboración entre agentes, permitiendo una arquitectura más simple y escalable en el trabajo con IA. 📖 Leer el artículo completo ⏳ Procesando Eventos de Larga Duración en AWS API Gateway AWS API Gateway se destaca en la gestión de solicitudes API, pero enfrenta retos al manejar eventos prolongados debido a sus limitaciones de tiempo de espera y su naturaleza sincrónica. Este artículo explora estrategias para abordar estas operaciones extendidas de manera efectiva, integrando patrones asíncronos que evitan bloquear a los clientes y garantizan una manipulación confiable de eventos. Puntos clave: * Integración Asíncrona es Clave: Utiliza respuestas 202 Aceptadas y servicios como EventBridge o SQS para desacoplar tareas largas de los límites sincrónicos de API Gateway (ej. timeout de 29 segundos). * Polling y Webhooks para Estado: Implementa polling del cliente o webhooks de retorno para rastrear el progreso de los procesos de backend sin bloquear la llamada inicial a la API. * Monitoreo y Manejo de Errores: Aprovecha CloudWatch para la observabilidad y los reintentos incorporados para asegurar un procesamiento confiable de eventos prolongados en arquitecturas sin servidor. 🎯 Reflexión: Aplicar patrones asíncronos y herramientas como EventBridge/SQS transforma la manera en que manejas eventos extensos en API Gateway, permitiendo construir sistemas más escalables y resilientes. 📖 Leer el artículo completo 🤖 La IA Cambia el Trabajo del Ingeniero: Cómo Adaptarse La IA está transformando el rol del ingeniero, pasando de una función centrada en la codificación a una de orquestador de IA. Las habilidades de juicio, entendimiento del producto, especificación clara y revisión son cada vez más valiosas. 🔑 Puntos Clave: * La codificación ya no es el diferenciador clave: Las habilidades de juicio y revisión cobran más relevancia en la ingeniería asistida por IA. * El desarrollo basado en especificaciones se vuelve esencial: Las especificaciones estructuradas guían mejor a los agentes de IA que los mensajes vagos. * Las herramientas de desarrollo deben evolucionar: Es necesario apoyar flujos de trabajo que incluyan revisión de especificaciones, verificación de código y colaboración más sencilla. 🎯 Reflexión: Adaptar las habilidades y herramientas en este nuevo entorno de desarrollo es crucial para que los ingenieros tomen decisiones más informadas y se conviertan en líderes en la integración de la IA. 📖 Leer el artículo completo 🤖 7 Consejos para Hacer tu Agente de IA Más Predecible Este artículo ofrece una guía práctica para hacer que los agentes de inteligencia artificial se comporten de manera más consistente y confiable en flujos de trabajo del mundo real. Se enfa

Ver todo (94)

Acerca de

Podcast y newsletter semanal de noticias sobre AWS y serverless en Español Hosted by Marcia Villalba desplegando.substack.com

Información

  • Creador
    Marcia Villalba
  • Años de actividad
    2025 - 2026
  • Episodios
    94
  • Clasificación
    Apto
  • Copyright
    © Marcia Villalba
  • Mostrar sitio web
    Desplegando.cloud