Ruben Civeira

En los últimos meses el ecosistema de agentes de IA se ha disparado: frameworks, herramientas, RAGs, memorias… y cada proyecto acaba resolviendo el mismo problema: ¿cómo organizo todas estas piezas de forma coherente? En este artículo propongo una arquitectura modular para gestionar agentes en Python, apoyándonos en LangChain, wrappers de MCP (Model Context Protocol) y un manager común que facilite tanto a programadores como a perfiles de negocio trabajar con agentes de distinta complejidad       En este artículo vamos a profundizar en un manager de agentes escrito en Python, que organiza de forma modular los distintos elementos que necesitamos para crear y ejecutar agentes: Agentes (instancias) → Son configuraciones concretas que indican qué tipo de agente se usará, con qué propiedades iniciales (ej. temperatura, límites de tokens, idioma) y qué herramientas estarán disponibles. Estas instancias se ejecutan siempre dentro de un contexto , que se encarga de...

Construyendo un sistema de suscripciones multi-tenant con OIDC y pagos integrados En los últimos meses he estado explorando cómo diseñar un microservicio de suscripciones capaz de cubrir dos escenarios habituales: Aplicaciones SaaS multi-tenant que quieren ofrecer planes de acceso a sus clientes (los tenants ). Tenants individuales que, a su vez, desean revender su aplicación a sus propios usuarios finales bajo diferentes niveles de servicio ( tiers ). Esto plantea varios retos de arquitectura: ¿dónde modelar los tiers y entitlements ?, ¿cómo coordinar identidades con pagos?, ¿cómo automatizar (o semi-automatizar) la creación de tenants?, ¿qué experiencia de usuario debe seguir alguien que quiere suscribirse? Modelado de base En el dominio de Suscripciones aparecen varias entidades clave: Catalog : representa la oferta de planes de una aplicación o de un tenant. Tier : cada plan con su precio y limitaciones (ej. nú...

¿Cómo mantener el control de acceso bajo control cuando tu arquitectura crece en microservicios, roles y recursos? Este enfoque declarativo te ayuda a definir reglas legibles, seguras y escalables, sin caer en la complejidad ni perder el gobierno. En el desarrollo de sistemas distribuidos basados en microservicios, uno de los mayores retos técnicos y de gobernanza es establecer un modelo de control de acceso que sea: Centralizado , pero no invasivo Flexible , pero seguro por defecto Expresivo , pero fácil de mantener Y sobre todo, escalable , sin volverse una pesadilla al crecer el número de recursos, roles y reglas En este artículo te presento un enfoque declarativo para la definición de permisos en un ecosistema de microservicios, inspirado en ideas de RBAC , pero diseñado para ser portable, semántico y extrapolable. 🎯 Objetivo Construir un sistema de autorización que permita: Definir permisos a nivel de acciones y atributos por recurso Asociarlos a ro...

Despliegue ordenado de microservicios PHP y Angular sobre Apache En mi artículo anterior expliqué cómo estructurar un servidor Apache para servir distintos proyectos web mediante subdominios locales, combinando una configuración de DNS flexible con VirtualHosts. Ese entorno se ha convertido en la base sobre la que he construido una herramienta que facilita la gestión y despliegue de proyectos: swarm-dashboard. ¿Qué es swarm-dashboard? swarm-dashboard es una pequeña aplicación que permite organizar y desplegar múltiples proyectos basados en PHP y Angular directamente desde repositorios Git. Está diseñado para entornos de desarrollo y también para despliegues de producción ligera, donde no se justifica la complejidad de un sistema de orquestación, pero se quiere mantener orden, trazabilidad y acceso rápido a herramientas complementarias. El panel detecta automáticamente los proyectos presentes en el servidor y ofrece una interfaz para: Actualizar código desde el repositor...

Muchos de los conceptos detras de los microservicios son excepcionales: el aislamiento de dependencias externas, y la capacidad de desplegar de forma autónoma permiten una enorme flexibilidad a cualquier proyecto empresarial en el que conviben diferentes lineas de negocio, con requisitos cambiantes y en ocasiones contradictorios. Las implementaciones existentes de micro servicios actuales funcionan en base a imagenes docker que en muchos casos ejecutan un springboot, y que son desplegados en openshift o kubernetes... Lo que resultan en unas necesidades de RAM extraordinarias: montar un entorno de desarollo capaz de ejecutar seis microservicios con springboot (acceso, notificaciones, inventario, tarifas, pagos, y transportes) va a consumir unos 5Gb de RAM. Con quarkus el consumo podría bajar a unos 2Gb, pero sigue siendo un consumo enormemente elevado. Hay que tener en cuenta que a mayores en muchos casos se va a necesitar al menos un servidor de base de datos, y otros servicio...

Cuando en 1805 la francia imperial de Napoleon se enfrentó a Austria y Rusia en Austerliz, Rusos y Austríacos confiaban en su superioridad númerica. El ejercito de Napoleon estaba dividido, y su núcleo principal de 65.000 soldados estaba en desventaja frente a los 70.000 soldados ruso y 15.000 austriacos. La caballería de Napoleón estaba dispersa, pero confiaba en que sus unidades supieran interpretar los ruidos de la batalla.   La ventaja que Napoleón supo aprovechar en Austerliz fue la confianza en sus hombres. Los ejércitos austríaco y ruso eran dos ejércitos prácticamente medievales, dirigidos por la nobleza y en los que se formaban enormes cuadros de tropas que debían responder con fe ciega a las órdenes de un único noble que los dirigía. El ejercito francés estaba formado en gran medida por ciudadanos, a los que se les confiaba una responsabilidad. Las unidades de combate francesas eran mucho más pequeñas porque no necesitaban de un noble de alta cuna para ...

REST es un conjunto de principios arquitectónicos que define cómo las aplicaciones se comunican a través de la web. Se basa en un sistema sin estado, donde las solicitudes y respuestas son independientes y se comunica mediante estándares como HTTP. En REST, los datos y la funcionalidad son considerados recursos, y estos recursos son identificados y accedidos mediante URI (Uniform Resource Identifiers). Las características más aceptadas que definene un api REST, son: Interfaz Uniforme : Para simplificar y desacoplar la arquitectura, REST impone una interfaz uniforme que desacopla al cliente de los detalles del servidor. Sin estado : Cada petición de un cliente contiene toda la información que el servidor necesita para procesarla. El servidor no retiene ninguna información de estado del cliente entre solicitudes. Esto hace que las aplicaciones REST sean más escalables y simplifica el diseño del servidor. Cacheable : Las respuestas deben definir claramente si son cacheables...