DEV Community: Jose Luis Ariza

AI-DLC de AWS: Hacia un ciclo de vida del desarrollo de software nativo de IA.

Jose Luis Ariza — Sat, 18 Jul 2026 21:26:15 +0000

Actualmente, muchos equipos utilizan la inteligencia artificial para analizar requisitos, formular preguntas, explorar alternativas, generar código, crear pruebas, explicar errores o redactar documentación. Aunque estas herramientas aceleran actividades concretas, normalmente son las personas quienes organizan el proceso, deciden cuándo recurrir a la IA y determinan cuál será el siguiente paso.

Amazon Web Services (AWS) propone una visión diferente: AI-DLC (Artificial Intelligence–Driven Development Life Cycle; Ciclo de Vida de Desarrollo Impulsado por Inteligencia Artificial).

En AI-DLC, la inteligencia artificial no se limita a responder solicitudes. También analiza el objetivo, formula preguntas, prepara planes, propone alternativas y ejecuta las actividades después de recibir la aprobación humana. Este patrón se repite durante todo el desarrollo.

La metodología fue creada por Raja SP y su equipo en AWS. Raja es Principal Solutions Architect (arquitecto principal de soluciones) y lidera programas de transformación para desarrolladores dentro de AWS.

La IA propone el camino y ejecuta el trabajo aprobado; las personas aportan contexto, revisan los resultados y toman las decisiones importantes.

Para entender cómo funciona, aplicaremos AI-DLC a un proyecto hipotético: una aplicación web para reservar citas médicas.

El equipo del proyecto

En nuestro ejemplo participarán:

María, Product Owner o PO (responsable del producto): explica la necesidad, responde las preguntas y valida lo que se construirá.

Diego, Developer (desarrollador): revisa los diseños, el código y las pruebas.

Jose, arquitecto de soluciones: interviene cuando deben evaluarse integraciones, requisitos no funcionales o decisiones técnicas.

Un agente de IA: formula preguntas, crea planes, propone artefactos y ejecuta el trabajo aprobado.

El arquitecto de soluciones no se presenta como un participante obligatorio en todas las actividades. Lo incorporamos como especialista porque AWS menciona la participación de arquitectos y señala que, durante la construcción, el equipo debe aclarar en tiempo real las decisiones técnicas y arquitectónicas.

Fase 1: Inception

Inception (concepción) es la fase en la que el equipo comprende lo que necesita construir y organiza el trabajo.

Su principal ritual es Mob Elaboration (elaboración colaborativa). Durante esta sesión, el equipo revisa conjuntamente las preguntas y propuestas generadas por la IA. No se trata de que cada participante prepare documentos por separado para transferirlos posteriormente, sino de aclarar y decidir en tiempo real.

Aplicamos el Intent

El proyecto comienza con un Intent (intención), una declaración de alto nivel sobre lo que se desea conseguir.

María, como PO, comunica:

Crear una aplicación web que permita consultar los horarios disponibles y reservar una cita médica.

La IA no comienza generando código. Primero pregunta:

¿El paciente debe registrarse?
¿Puede cancelar o reprogramar una cita?
¿Cómo se evitarán reservas duplicadas?
¿Cómo recibirá la confirmación?

María aclara el comportamiento esperado. Diego identifica posibles restricciones de implementación y Jose señala que la aplicación deberá integrarse posteriormente con el sistema de médicos y horarios de la clínica.

Con estas respuestas, la IA genera artefactos como:

User Stories (historias de usuario).
Acceptance Criteria (criterios de aceptación).
NFR, Non-Functional Requirements (requisitos no funcionales).
Riesgos y criterios de medición.

Estos artefactos no se aceptan automáticamente. El equipo los revisa y solicita cambios hasta estar de acuerdo.

Aplicamos las Units

Después, la IA divide el proyecto en Units (unidades de trabajo). Cada Unit agrupa una parte cohesionada de la solución que puede construirse con cierta independencia.

Para nuestro proyecto propone:

Gestión de médicos y horarios.
Reserva y reprogramación de citas.
Confirmaciones y recordatorios.

María valida que las Units cubran la necesidad inicial. Diego revisa si pueden desarrollarse de manera independiente y Jose analiza sus integraciones.

La IA también propone un Workflow Plan (plan del flujo de trabajo). Como AI-DLC es adaptable, no todas las iniciativas deben pasar por las mismas actividades. Un proyecto nuevo puede necesitar requisitos, diseño y pruebas completas, mientras que una corrección sencilla podría avanzar directamente hacia la generación de código.

Nuestro ejemplo es un proyecto greenfield (desarrollado desde cero), por lo que requiere mayor elaboración antes de comenzar a programar.

Aplicamos un Bolt

Las Units se construyen mediante Bolts (iteraciones aceleradas). Un Bolt es un ciclo breve, normalmente medido en horas o días, en lugar de las varias semanas que podría durar un sprint tradicional.

Para la Unit de reservas, la IA propone el siguiente Bolt:

Implementar la consulta y selección de horarios disponibles, generar las pruebas y presentar el resultado al equipo.

El PO y los desarrolladores revisan el alcance. Si consideran que es demasiado grande, pueden dividirlo antes de aprobar su ejecución.

Fase 2: Construction

Construction (construcción) transforma las Units aprobadas en software probado.

Su ritual es Mob Construction (construcción colaborativa). Durante este proceso, la IA propone los diseños, planes de implementación, código y pruebas; mientras el equipo aclara las decisiones técnicas y arquitectónicas en tiempo real.

En nuestro proyecto, la construcción de la Unit de reservas sigue este recorrido.

Domain Design

La IA propone un Domain Design (diseño del dominio) con los conceptos y reglas principales:

Paciente.
Médico.
Horario.
Cita.
Estado de la cita.

También identifica reglas como impedir que dos pacientes reserven el mismo horario o liberar el horario cuando una cita sea cancelada.

María confirma que las reglas representan el comportamiento esperado y Diego revisa que no existan contradicciones.

Logical Design

Después, la IA genera un Logical Design (diseño lógico), donde convierte las reglas anteriores en una propuesta técnica.

Aquí Jose, como arquitecto de soluciones, adquiere mayor participación. Revisa:

Cómo se consultarán los horarios.
Cómo se evitarán reservas simultáneas.
Cómo se integrará la aplicación con otros sistemas.
Cómo se protegerá la información.
Qué ocurrirá si el servicio de notificaciones falla.

La IA puede presentar varias alternativas, pero la decisión final pertenece al equipo.

Código y pruebas

Con el diseño aprobado, la IA prepara un plan numerado para generar:

La lógica de reserva.
Las interfaces necesarias.
Las validaciones.
Las pruebas.
La documentación.
Los archivos de despliegue.

El plan debe ser revisado antes de comenzar. AI-DLC prioriza la planificación y los puntos de aprobación para evitar que una suposición incorrecta avance hasta el código.

Después de la aprobación, la IA genera el código y las pruebas. Diego revisa la implementación y valida que pueda comprenderla, mantenerla y corregirla. Jose vuelve a intervenir solamente si el resultado modifica alguna decisión de solución.

El resultado es una Deployment Unit (unidad desplegable): código, configuraciones y pruebas preparados para ser desplegados.

Fase 3: Operations

Operations (operaciones) comprende el despliegue, la observación y el mantenimiento de la solución.

La IA utiliza el contexto acumulado durante las fases anteriores para analizar infraestructura, despliegues, métricas y errores bajo la supervisión del equipo.

En nuestra aplicación podría detectar:

Aumento en los tiempos de respuesta.
Errores al consultar horarios.
Intentos frecuentes de reservar citas ocupadas.
Fallos en el envío de confirmaciones.

La IA puede analizar el problema y recomendar una acción, pero el equipo conserva el control sobre las decisiones relevantes.

Los rituales mantienen la supervisión humana

Mob Elaboration y Mob Construction no son reuniones adicionales agregadas al proceso. Son la forma en que AI-DLC organiza la colaboración entre la IA y las personas.

Ambos rituales siguen un ciclo sencillo:

Las personas proporcionan una tarea o intención.
La IA crea un plan y formula preguntas.
El equipo proporciona aclaraciones.
La IA ajusta su propuesta.
Las personas aprueban el plan.
La IA ejecuta.
El equipo verifica el resultado.

Así, la velocidad de la IA no elimina la responsabilidad humana. Cada propuesta puede ser revisada antes de ejecutarse y cada resultado debe validarse antes de continuar.

¿Qué cambia frente al desarrollo asistido?

En el desarrollo asistido, la persona podría solicitar:

Analiza estos requisitos e identifica preguntas pendientes.

Después, otra persona puede iniciar una conversación diferente para diseñar la solución y, posteriormente, solicitar pruebas o código.

En AI-DLC

El equipo comunica una intención y la IA participa en un flujo continuo:

Analiza el contexto disponible.
Propone preguntas y aclaraciones.
Prepara un plan.
Espera la revisión humana.
Genera los artefactos aprobados.
Recomienda el siguiente nivel de trabajo.
Conserva las decisiones como contexto.
Ejecuta únicamente después de recibir aprobación.

Las personas también formulan preguntas, modifican los planes y proponen alternativas.

AI-DLC no reduce su participación. Organiza la colaboración para que la IA pueda tomar mayor iniciativa sin adquirir autonomía completa.

En el desarrollo asistido, las personas conducen el proceso y recurren a la IA para determinadas actividades. En AI-DLC, la IA también ayuda a conducir el proceso, mientras el equipo controla las decisiones y valida los resultados.

Los 10 principios de AI-DLC, en breve

Reimaginar, no adaptar: no limitarse a insertar IA en un proceso antiguo.
Invertir la conversación: la IA también formula preguntas y propone cómo avanzar.
Integrar técnicas de diseño: diseñar antes de generar la implementación.
Reconocer la capacidad real de la IA: aprovecharla sin otorgarle autonomía completa.
Atender sistemas complejos: utilizarla donde existen reglas, dependencias y decisiones relevantes.
Conservar artefactos útiles: mantener aquello que aporta contexto, control y trazabilidad.
Facilitar la transición: utilizar conceptos relacionados con prácticas conocidas.
Simplificar responsabilidades: reducir divisiones y transferencias innecesarias.
Minimizar etapas: conservar únicamente las actividades que aportan valor o control.
Evitar flujos rígidos: adaptar el recorrido a la complejidad de cada trabajo.

Conclusión

AI-DLC no plantea que la inteligencia artificial reemplace al equipo ni que construya software sin control.

La propuesta es establecer una colaboración diferente: la IA pregunta, planifica, descompone, genera y analiza; mientras que el PO, los desarrolladores y los especialistas aportan experiencia, corrigen supuestos y aprueban el trabajo.

En nuestro proyecto aplicamos los principales elementos del documento:

Intent: expresa lo que se desea conseguir.
Unit: divide el proyecto en partes cohesionadas.
Bolt: permite construirlas mediante ciclos breves.
Domain Design: define conceptos y reglas.
Logical Design: convierte esas reglas en una solución técnica.
Code and Tests (código y pruebas): materializan el diseño.
Deployment Unit: reúne el resultado listo para desplegarse.
Mob Elaboration y Mob Construction: organizan la colaboración entre la IA y el equipo.

Ese es el cambio que AWS propone: dejar de utilizar la inteligencia artificial solamente como una herramienta que recibe órdenes y comenzar a integrarla como una colaboradora que ayuda a conducir el desarrollo, siempre bajo supervisión humana.

Fuentes

AWS Architecture Center: guía práctica para diseñar arquitecturas bien fundamentadas en AWS

Jose Luis Ariza — Mon, 06 Apr 2026 01:26:20 +0000

Introducción

¿Alguna vez te has preguntado cómo estructurar correctamente una arquitectura en AWS recurriendo solo a la experiencia previa sin fallar en el intento?

¿Dónde encontrar ejemplos reales, patrones validados y decisiones de diseño bien fundamentadas?

Cuando un arquitecto de soluciones comienza a trabajar en AWS, uno de los mayores retos no es aprender los servicios, sino entender cómo combinarlos correctamente para construir sistemas escalables, resilientes y eficientes.

Aquí es donde AWS proporciona una ventaja significativa:

👉 Se trata del AWS Architecture Center.

Y no, no se trata únicamente de una librería de iconos (que también nos brinda un paquete de íconos para descargar).

AWS Architecture Center: el punto de partida

El AWS Architecture Center es un portal oficial donde AWS centraliza:

arquitecturas de referencia

patrones de diseño

mejores prácticas

guías para tomar decisiones

No es solo inspiración visual.
Es una forma de pensar arquitectura con criterio.

🔗 Recurso

👉 https://aws.amazon.com/architecture/

🔁 Puntos importantes del portal oficial

Después de explorar el portal oficial, armé una estructura que me permitió entender mejor cómo está organizada toda la información y cómo aprovecharla en el diseño de soluciones.

AWS Architecture Center
│
├── AWS Reference Architecture Diagrams
├── AWS Prescriptive Guidance
│  → AWS Patrones de orientación prescriptiva
│  → Patrones, arquitecturas e implementaciones de diseño en la nube
└── AWS Well-Architected Framework

🏗️ AWS Reference Architecture Diagrams

Son un conjunto de arquitecturas de referencia diseñadas y validadas por AWS que representan soluciones reales a problemas comunes, utilizando servicios cloud de forma coherente y siguiendo buenas prácticas.

Cada arquitectura de referencia incorpora:

diagramas detallados (end-to-end)
descripción del caso de uso
servicios involucrados
flujos de interacción entre componentes
consideraciones de diseño

💡 Insight clave

Las Reference Architectures no son plantillas rígidas, sino puntos de partida validados que deben adaptarse al contexto de cada solución.

🔗 Recurso

👉 https://aws.amazon.com/architecture/reference-architecture-diagrams/

Les dejo un ejemplo de un diagrama que me gusto mucho como se integran los servicios y la explicación paso a paso: Diagrama de referencia AWS

🚀 AWS Prescriptive Guidance

La AWS Prescriptive Guidance es un conjunto de recursos desarrollados por expertos de AWS que proporcionan recomendaciones prácticas, patrones y guías detalladas para ayudar a diseñar, migrar y modernizar soluciones en la nube.

Se organiza en dos grandes bloques:

AWS Prescriptive Guidance
│
├── Guides (Guías)
└── Patterns (Patrones)

📘 Guides (Guías)

Las guías están orientadas a proporcionar una visión más amplia y estratégica.

Ofrecen orientación de planificación e implementación, centrada en mejores prácticas y herramientas, dirigida a arquitectos, gerentes, líderes técnicos y ejecutivos.

🔧 Patterns (Patrones)

Los patrones están enfocados en la implementación práctica.

Incluyen pasos, arquitecturas, herramientas y código para implementar escenarios comunes de migración, optimización y modernización, dirigidos a perfiles técnicos y constructores.

🔗 Recurso

👉 https://aws.amazon.com/es/prescriptive-guidance/

💡 Como aporte adicional, si quieres profundizar en cómo aplicar patrones en AWS, te recomiendo estos recursos oficiales:

Cloud Design Patterns (conceptos de arquitectura)

Prescriptive Guidance Patterns (implementación práctica)

⚖️ AWS Well-Architected Framework

El AWS Well-Architected Framework es el conjunto de principios, buenas prácticas y criterios definidos por AWS para evaluar y mejorar la calidad de una arquitectura en la nube.

A diferencia de otros recursos como patrones o arquitecturas de referencia, su objetivo no es decirte qué construir, sino ayudarte a responder una pregunta clave:

👉 ¿Está bien diseñada mi arquitectura?

El framework se basa en seis pilares que cubren los aspectos clave de cualquier sistema:

Excelencia Operativa: Capacidad para ejecutar y monitorear sistemas, y mejorar continuamente los procesos para entregar valor.

Seguridad: Protección de datos, sistemas y activos mediante la gestión de identidades y controles de detección de amenazas.

Fiabilidad: Garantía de que el sistema se recupere de fallos y funcione correctamente ante cambios o demandas de carga.

Eficiencia del Rendimiento: Uso eficiente de los recursos informáticos para cumplir con los requisitos y adaptarse a la evolución tecnológica.

Optimización de Costos: Capacidad para evitar gastos innecesarios y optimizar el uso de los recursos para maximizar el retorno de inversión.

Sostenibilidad: Enfoque en minimizar el impacto ambiental y la huella de carbono mediante la eficiencia energética en la nube.

🔗 Recurso

👉 https://aws.amazon.com/architecture/well-architected/

🎓 Aporte: formación en AWS Well-Architected (AWS Skill Builder)

💡 Como complemento a este contenido, AWS también ofrece formación oficial a través de AWS Skill Builder, donde puedes profundizar en el uso del Well-Architected Framework y aplicarlo en escenarios reales.

👉 AWS Well-Architected Foundations

BIAN: estructurando el negocio bancario y su encaje con DDD y microservicios

Jose Luis Ariza — Thu, 02 Apr 2026 01:53:37 +0000

En los últimos años, el sector financiero ha vivido una transformación profunda: presión regulatoria, fintechs nativas digitales, APIs abiertas, banca como plataforma y una necesidad constante de modernizar core systems sin detener el negocio. En ese contexto, BIAN (Banking Industry Architecture Network) se ha convertido en una referencia clave para quienes diseñan arquitecturas bancarias modernas.

Pero BIAN no es solo “otro framework”. Es una propuesta estructurada para organizar el negocio bancario en dominios bien definidos, con un modelo de servicios estandarizado que conecta de forma natural con prácticas como Domain-Driven Design (DDD) y arquitecturas de microservicios.

¿Qué es BIAN?

BIAN es una iniciativa colaborativa creada por bancos y proveedores tecnológicos con el objetivo de definir una arquitectura de referencia estandarizada para la industria bancaria.

Su propósito es claro:

Descomponer el negocio bancario en capacidades funcionales bien definidas y estructuradas como servicios.

No define tecnología concreta, ni impone un estilo de implementación. Define una forma de estructurar el negocio y sus responsabilidades.

En esencia, BIAN proporciona un mapa funcional del banco, donde cada parte tiene límites claros y responsabilidades específicas.

La estructura de BIAN:

Para organizar los miles de procesos de un banco, BIAN utiliza un mapa llamado Service Landscape. Este se divide en tres grandes capas:

Business Areas (Áreas de Negocio): Son las divisiones estratégicas más grandes de una institución (ej. Ventas y Servicios, Operaciones de Referencia). Serían los "continentes" en nuestro mapa.

Business Domains (Dominios de Negocio): Subdivisiones lógicas dentro de las áreas. Aquí agrupamos problemas específicos (ej. Operaciones de Tarjetas, Préstamos). Serían los "países".

Service Domains (Dominios de Servicio): ¡El corazón de BIAN! Son las capacidades de negocio elementales e indivisibles. Cada Service Domain gestiona el ciclo de vida de un activo usando un patrón específico.

BIAN y microservicios: relación estructural

BIAN no obliga a usar microservicios. Sin embargo, su forma de descomponer el negocio es especialmente compatible con arquitecturas distribuidas.

Cuando una organización decide estructurar su arquitectura en servicios independientes, necesita primero tener bien definidos los límites funcionales. Aquí es donde BIAN aporta valor:

Cada Business Domain puede convertirse en un servicio autónomo

Cada dominio puede gestionar su propio ciclo de vida

Las interacciones entre dominios pueden formalizarse mediante contratos explícitos

Lo importante no es convertir cada dominio en un microservicio de forma automática, sino usar el modelo para definir límites correctos.

Una arquitectura basada en microservicios necesita:

Autonomía funcional

Aislamiento de datos

Responsabilidad clara

Interacciones controladas

BIAN proporciona precisamente esa estructura conceptual.

La conexión entre BIAN y Domain-Driven Design (DDD)

Más que una coincidencia, la relación entre BIAN y Domain-Driven Design (DDD) es estructural. Ambos enfoques parten del mismo principio fundamental:

La arquitectura debe reflejar el dominio del negocio.

DDD es un enfoque de desarrollo de software que propone comenzar por comprender el dominio en profundidad y estructurarlo en Bounded Contexts: límites semánticos claros donde un modelo es consistente y coherente.

BIAN, por su parte, descompone el negocio bancario en Business Domains, cada uno con:

Responsabilidad funcional específica

Propiedad clara sobre su información

Servicios definidos

Límites bien establecidos

Aunque surgieron en contextos distintos, ambos enfoques convergen en varios puntos clave.

Caso Practico: Conectando BIAN con DDD y Microservicios

Según el Service Landscape de BIAN, Current Account es un Service Domain cuyo objetivo es manejar el ciclo de vida de una cuenta corriente.

En términos de DDD, este será nuestro Bounded Context (nuestro microservicio completo). Dentro de este microservicio, BIAN nos dice que el Control Record (el núcleo de información que controla este dominio) se llama Current Account Arrangement (El acuerdo de cuenta corriente).

Este Control Record se convierte automáticamente en nuestro Aggregate Root en Java. Es la entidad principal que protege las reglas de negocio (por ejemplo, que no puedas retirar más dinero del que tienes, a menos que tengas un límite de sobregiro). Para manejar las distintas funcionalidades de la cuenta, implementamos los Behavior Qualifiers (Calificadores de Comportamiento) que dicta BIAN, como Withdrawals (Retiros) y Deposits (Depósitos), exponiéndolos como casos de uso.

Conclusión

BIAN no reemplaza DDD.
Tampoco DDD sustituye a BIAN.

BIAN ofrece una estructura de descomposición sectorial específica para banca.
DDD ofrece una metodología para modelar correctamente cualquier dominio, incluido el bancario.

Cuando se combinan:

BIAN ayuda a identificar los límites macro del sistema.

DDD ayuda a modelar correctamente cada uno de esos límites.

La conexión no es tecnológica.
Es conceptual y estructural.

Y ahí radica su verdadero valor.

Modelo C4: cómo preparar tu arquitectura antes de empezar a diagramar

Jose Luis Ariza — Sun, 15 Feb 2026 18:03:09 +0000

Imagina esto: Estás en un ascensor con el CEO de tu empresa. Tienes 30 segundos para explicarle cómo funciona el nuevo sistema que estás construyendo. Sacas una servilleta y un bolígrafo.

¿Qué dibujarías?

¿Una clase de Java Public Void Main? (Demasiado detalle técnico, perderás su atención).

¿Un cilindro que diga "Base de Datos"? (Eso no explica cómo el negocio gana valor).

¿Una nube gigante que diga "Internet"? (Demasiado genérico para tomar decisiones).

La mayoría de los arquitectos fallan aquí. No por falta de conocimiento técnico, sino por falta de claridad. He aprendido que antes de dibujar el diagrama "oficial", necesito estructurar la solución. Para esto, utilizo el Modelo C4 (creado por Simon Brown). No solo como una herramienta de documentación, sino como mi herramienta de análisis y pensamiento.

C4 no es solo un modelo de diagramas

El modelo C4 es una forma simple de visualizar la arquitectura de software en niveles de detalle, desde la visión más general hasta el código. Como si fuera un mapa con zoom, diseñado por Simon Brown.

La analogía que más me ayudó a entenderlo fue esta:
Es como usar Google Maps.

Primero ves el país.
Luego la ciudad.
Luego la calle.
Luego el edificio.

Cada nivel tiene un propósito distinto. El error es intentar explicarlo todo al mismo tiempo.

C4 propone cuatro niveles principales y, lo más importante, define claramente qué tipo de elementos existen en cada uno.

Las abstracciones del Modelo C4

Algo que me cambió completamente la perspectiva fue entender las abstracciones base del modelo.

👤 Person (Persona)

Una persona es cualquier actor que interactúa con el sistema.

Puede ser:

Un cliente
Un empleado
Un administrador
Incluso otro sistema externo

Lo importante es que no forma parte del sistema que estamos modelando. Está fuera. Nos ayuda a entender quién usa el sistema y por qué existe.

🧩 Software System (Sistema de Software)

Es el sistema completo que estamos describiendo.

Por ejemplo:

Plataforma de pagos
Sistema de onboarding digital
Motor de riesgos
Portal de clientes

Aquí no hablamos de clases ni microservicios. Hablamos del sistema como una unidad, su propósito y sus interacciones con el mundo externo.

Este nivel es clave para conversar con negocio y stakeholders.

📦 Container (Contenedor)

Este es uno de los conceptos más malinterpretados.

Un contenedor en C4 no es necesariamente Docker. Es cualquier unidad ejecutable o desplegable que ejecuta código o almacena datos.

Por ejemplo:

Una API REST
Una aplicación web
Una app móvil
Una base de datos
Un servicio batch
Un microservicio

Es el nivel donde la arquitectura empieza a volverse tangible. Aquí ya hablamos de tecnología, responsabilidades y comunicación entre piezas.

🧱 Component (Componente)

Un componente es una agrupación lógica dentro de un contenedor. Representa una parte del sistema con una responsabilidad clara y bien definida.

Por ejemplo, dentro de una API podríamos tener:

Un componente de validación
Un componente de orquestación
Un adaptador a un sistema legacy
Un motor de reglas

No son clases individuales. Son bloques cohesivos que organizan la lógica interna. Este nivel me ayudó mucho a explicar arquitectura a desarrolladores sin entrar aún al código.

💻 Code (Código)

Es el nivel más detallado: clases, interfaces, estructuras reales. No siempre es necesario documentarlo, porque el código ya existe. Pero en sistemas críticos o complejos puede ayudar a alinear criterios de diseño.

Los 4 niveles de zoom

Entender las abstracciones es clave, pero el verdadero poder está en cómo se organizan en niveles:

1️⃣ Nivel Contexto

Muestra el sistema como una caja negra y sus interacciones con personas y otros sistemas.

Es perfecto para:

Presentaciones ejecutivas
Kick-offs
Alinear propósito y límites

2️⃣ Nivel Contenedores

Aquí vemos cómo se estructura internamente el sistema:

Frontend
Backend
Base de datos
Servicios externos

Este nivel me ayudó a explicar decisiones tecnológicas sin perder claridad.

3️⃣ Nivel Componentes

Profundiza dentro de un contenedor.

Es ideal para:

Equipos técnicos
Revisión de arquitectura
Onboarding

Aquí es donde la arquitectura deja de ser abstracta y empieza a ser operativa.

4️⃣ Nivel Código

Solo cuando es necesario.

He aprendido que no siempre hay que bajar hasta aquí.
Depende del público y del objetivo.

De la Teoría a la Práctica: El Caso "CloudCoffee" ☕

Ahora que conocemos las abstracciones, vamos a aplicarlas. Imagina que somos los arquitectos de "CloudCoffee", una nueva cadena de cafeterías digitales. Vamos a aplicar los niveles de zoom usando las abstracciones que acabamos de definir.

Nivel 1: Contexto (System Context)
La Vista de Negocio. Aquí conectamos a las Personas con el Sistema de Software.

Este diagrama responde: ¿Quién usa el sistema y con qué se integra?

Nivel 2: Contenedores (Containers)
La Vista de Tecnología. Abrimos la caja del sistema. ¿Qué Contenedores necesitamos para que CloudCoffee funcione?

Este diagrama responde: ¿Qué tecnología usamos y cómo se comunican las piezas desplegables?

Nivel 3: Componentes (Components)
La Vista de Ingeniería. Hacemos Zoom dentro del contenedor "API Backend". ¿Qué Componentes lógicos tiene?

Este diagrama responde: ¿Cómo está organizado el código internamente?

Nivel 4: Código (Code)
El Detalle Extremo. Aquí mostraríamos las clases UML (PricingStrategy.java, DiscountRule.java).

Consejo: Simon Brown recomienda bajar a este nivel solo para lógicas muy complejas. Si haces esto para todo tu sistema, el diagrama quedará obsoleto en cuanto alguien escriba una nueva línea de código. Úsalo con precaución.

Mi conclusión personal

El Modelo C4 no me enseñó a dibujar mejor. Me enseñó a pensar mejor.

Me obligó a:

Respetar las abstracciones.
No mezclar niveles.
Comunicar con intención.
Y simplificar sin perder rigor.

Hoy lo veo más como una herramienta de pensamiento que como un estándar de diagramación. Y eso, en entornos complejos, marca una diferencia enorme.

AWS Glue vs AWS Lambda: Comparativa Serverless para Ingeniería de Datos en AWS

Jose Luis Ariza — Sun, 16 Feb 2025 13:13:00 +0000

Si trabajas en ingeniería de datos en AWS, seguro te has enfrentado a la clásica pregunta: ¿Uso una función Lambda rápida o mejor un job de Glue?

He visto a muchos equipos (y yo mismo lo hice al principio) intentar forzar todo dentro de Lambda para ahorrar costos, solo para terminar lidiando con timeouts y problemas de memoria semanas después. Por otro lado, usar Glue para mover un archivo pequeño de 1KB puede sentirse como matar una mosca con un cañón.

En este artículo, no solo te voy a dar conceptos, sino que te compartiré mi criterio personal sobre cuándo uso cada uno basándome en los dolores de cabeza y éxitos que he tenido en proyectos.

¿Que es AWS Glue?

AWS Glue es un servicio administrado de integración de datos que facilita la preparación, transformación y carga de datos (ETL). Su función principal es conectar diversas fuentes de datos, organizarlas y prepararlas para su posterior análisis. AWS Glue es especialmente útil en escenarios donde se manejan grandes volúmenes de información y se necesita automatizar procesos repetitivos.

Principales componentes de AWS Glue

Catálogo de Datos: Repositorio centralizado que almacena los metadatos y define la estructura de las fuentes de datos.

Crawlers: Programas que examinan las fuentes de datos, detectan su estructura y actualizan automáticamente el catálogo.

Jobs ETL: Procesos que ejecutan las transformaciones de datos, programados en Python o Scala.

Triggers: Reglas que activan la ejecución de trabajos según un cronograma o la ocurrencia de ciertos eventos.

Endpoints de Desarrollo: Entornos interactivos para escribir y probar el código ETL.

Ventajas de AWS Glue

Automatización del Proceso ETL: Reduce significativamente el tiempo necesario para preparar datos gracias a la detección automática de esquemas.

Integración Nativa: Se conecta de manera sencilla con otros servicios de AWS, como Amazon S3, Amazon Redshift y AWS Athena.

Escalabilidad Dinámica: Ajusta la capacidad de procesamiento según el volumen de datos.

Sin Servidores: Elimina la necesidad de gestionar infraestructura.

Desafíos y Limitaciones

Tiempo de Arranque: Al trabajar con un entorno distribuido basado en Apache Spark, el inicio de los trabajos puede tardar algunos minutos.

Soporte de Lenguajes Limitado: Solo admite Python y Scala, lo que puede ser un inconveniente si se utilizan otros lenguajes en el ecosistema.

Costo Variable: Para trabajos esporádicos o de poca carga, el costo puede resultar elevado en comparación con otras alternativas.

💡 Nota: Algo que aprendí a las malas es el impacto del Cold Start (tiempo de arranque). Aunque Glue es "Serverless", levantar los workers de Spark toma tiempo (a veces minutos).

Mi consejo: Si tu negocio exige ingesta en "casi" tiempo real (por ejemplo, un archivo cae en S3 y debe estar disponible para consulta en Athena o Redshift en menos de 30 segundos), Glue no es la opción porque pasará más tiempo "arrancando" que procesando.

Glue es ideal cuando el SLA (acuerdo de nivel de servicio) es holgado: reportes diarios, procesos nocturnos o batchs donde no importa si el dato llega a las 8:00 o a las 8:05.

Ejemplo Diagrama de Arquitectura - Pipeline Glue

¿Qué es AWS Lambda?

AWS Lambda es un servicio serverless que permite ejecutar código en respuesta a eventos específicos sin la necesidad de aprovisionar ni gestionar servidores. Su uso es ideal para aplicaciones que requieren respuestas rápidas a eventos en tiempo real, como la carga de archivos en S3 o el procesamiento de mensajes de una cola.

Principales componentes de AWS Lambda

Funciones Lambda: Fragmentos de código que se ejecutan al activarse un evento.

Triggers: Eventos que inician la ejecución de las funciones, como cambios en bases de datos, flujos de eventos o solicitudes a través de API Gateway.

Layers: Elementos reutilizables que permiten compartir bibliotecas y configuraciones entre funciones.

Gestión de Eventos: Recibe y procesa eventos desde diversas fuentes, facilitando la construcción de arquitecturas basadas en eventos.

Ventajas de AWS Lambda

Ejecución Basada en Eventos: Se activa automáticamente al detectarse un evento relevante, eliminando la necesidad de supervisión constante.
Soporte para Múltiples Lenguajes: Compatible con Python, Node.js, Java, Go, Ruby y otros.
Escalabilidad Inmediata: Escala horizontalmente para manejar picos de demanda sin intervención manual.
Modelo de Pago por Uso: Se paga únicamente por el tiempo de ejecución y el número de invocaciones.

Desafíos y Limitaciones

Tiempo Máximo de Ejecución: Las funciones no pueden superar los 15 minutos de ejecución, lo que limita su aplicación en procesos extensos.

Recursos Limitados: La memoria y el tiempo de procesamiento tienen límites que podrían afectar cargas intensivas.

Persistencia de Estado: Al tratarse de un servicio sin estado, se necesita recurrir a otras herramientas, como DynamoDB, para almacenar información entre invocaciones.

💡 La trampa de los 15 minutos: La limitación más famosa de Lambda son los 15 minutos de timeout. Muchos piensan "mi proceso solo tarda 2 minutos, estoy sobrado".

Pero, cuidado: ¿Qué pasa cuando el volumen de datos se duplica el próximo mes? Ese proceso de 2 minutos se convierte en 10, y luego en 16... y ahí tu pipeline se rompe.

Mi regla de oro: Si estimo que una tarea tardará más de 5 minutos hoy, prefiero no usar Lambda. Me gusta dejar ese margen de seguridad para el crecimiento futuro de los datos.

Ejemplo Diagrama de Arquitectura - Pipeline Lambda

Comparativa entre AWS Glue y AWS Lambda

Aunque ambos servicios pertenecen al ecosistema serverless de AWS, tienen aplicaciones distintas. La siguiente tabla resume las diferencias más relevantes:

¿Cuándo Usar AWS Glue?

AWS Glue es la mejor opción cuando se necesita:

Realizar transformaciones complejas y procesamiento por lotes.
Gestionar y organizar metadatos para análisis posteriores.
Automatizar tareas de integración de datos en proyectos de Big Data.
Trabajar con datos almacenados en Amazon S3, Redshift o Data Lakes.

Ejemplo de Caso de Uso:
Una empresa que procesa información de ventas históricas para generar reportes mensuales podría usar AWS Glue para consolidar, limpiar y transformar estos datos de manera eficiente.

¿Cuándo Usar AWS Lambda?

AWS Lambda es más adecuado cuando:

Se requieren respuestas inmediatas a eventos en tiempo real.
Se necesita construir microservicios ligeros y altamente escalables.
Se desea automatizar tareas basadas en eventos sin preocuparse por la infraestructura.
Se implementan flujos de trabajo orquestados con Step Functions.

Ejemplo de Caso de Uso:
Una aplicación que notifica en tiempo real a los clientes cada vez que se realiza una compra puede usar Lambda para procesar los eventos generados por las transacciones.

Conclusión

AWS Glue y Lambda son herramientas increíbles, pero sirven a procesos distintos.

En mi día a día, sigo esta filosofía simple:

Uso Lambda para la "Tareas Operativas": mover archivos, disparar alertas, transformaciones ligeras json-a-json o APIs en tiempo real.

Uso Glue para el "trabajo pesado": cuando necesito cruzar tablas, limpiar datos masivos o cuando no tengo idea de cuánto va a crecer el volumen de información mañana.

No tengas miedo de empezar con Lambda y migrar a Glue después, pero ten siempre presente los límites de la arquitectura serverless. ¡Espero que esta comparativa te ahorre los errores que yo cometí al principio!"

Patrón Circuit Breaker en Microservicios: Diseño Resiliente para Sistemas Distribuidos

Jose Luis Ariza — Wed, 05 Feb 2025 05:42:08 +0000

¿Te ha pasado que cuando compras con tu tarjeta de débito en un POS, el pago genera un error, pero aun así se debita el dinero de tu cuenta? O tal vez intentaste hacer una transferencia bancaria y la app del banco se quedó colgada, sin darte una respuesta clara sobre si la operación se realizó o no.

Estos problemas ocurren porque los sistemas no siempre responden de manera predecible. A veces, un servicio tarda demasiado en responder, se congestiona o incluso falla, causando inconsistencias y afectando la experiencia del usuario. Aquí es donde entra en acción el patrón Circuit Breaker.

Así como los fusibles en una instalación eléctrica protegen el sistema cortando la corriente cuando detectan sobrecarga, el patrón Circuit Breaker protege los sistemas distribuidos evitando que se realicen llamadas innecesarias a servicios que están fallando.

En este artículo, exploraremos cómo funciona este patrón, sus estados y cuándo aplicarlo en arquitecturas basadas en microservicios.

¿Qué es el Patrón Circuit Breaker?

El patrón Circuit Breaker es un mecanismo de protección en arquitecturas distribuidas que evita que un servicio haga repetidas llamadas a otro servicio que está fallando o que tiene tiempos de respuesta muy altos. Su objetivo es mejorar la resiliencia del sistema, reduciendo el impacto de fallos y evitando la sobrecarga de componentes.

El nombre "Circuit Breaker" proviene de los fusibles eléctricos, que cortan el flujo de corriente cuando detectan una sobrecarga para evitar daños mayores. En software, este patrón actúa de manera similar, interrumpiendo solicitudes a servicios problemáticos y permitiendo la recuperación gradual cuando la situación mejora.

¿Por qué usar el Patrón Circuit Breaker?

En arquitecturas distribuidas, los servicios dependen de múltiples componentes. Un fallo en un solo servicio puede generar un efecto dominó, afectando el rendimiento de toda la aplicación. Algunos problemas que pueden ocurrir si no se implementa el Circuit Breaker son:

Latencia extrema: Si un servicio tarda demasiado en responder, otros servicios pueden quedarse esperando y agotar sus recursos.

Fallo en cascada: Un servicio sobrecargado puede hacer que otros también fallen, generando un colapso total del sistema.

Peticiones innecesarias: Sin un control, un servicio en mal estado podría seguir recibiendo miles de solicitudes, empeorando su rendimiento.

El Circuit Breaker ayuda a mitigar estos problemas al bloquear las solicitudes a un servicio que está fallando y permitir su recuperación antes de volver a enviar peticiones.

Estados del Circuit Breaker

Supongamos que tenemos un microservicio de pagos encargado de procesar transacciones con tarjetas de crédito y débito. Este microservicio se comunica con un proveedor externo de pagos, como Visa, Mastercard o PayPal. Veamos como actúa el patrón Circuit Breaker en el microservicio.

El Circuit Breaker funciona con tres estados principales:

1️⃣ Estado Inicial: Closed (Cerrado)

📌 El microservicio de pagos funciona normalmente. Todas las solicitudes se envían al proveedor de pagos sin restricciones.

Ejemplo:
Un cliente intenta pagar con su tarjeta de crédito. El microservicio de pagos envía la solicitud al proveedor externo. Si la respuesta es exitosa, la transacción se completa.

2️⃣ Estado Open (Abierto)

📌 Si la cantidad de errores supera un umbral (por ejemplo, 5 fallos consecutivos en menos de 1 minuto), el Circuit Breaker cambia a Open.

Consecuencias:

Se bloquean las nuevas solicitudes de pago.
Se evita que un servicio sobrecargado o inactivo reciba más peticiones.
Se inicia un temporizador (por ejemplo, 30 segundos) antes de volver a intentar.

Ejemplo:
Si Visa tiene un problema y no responde en 5 intentos seguidos, el Circuit Breaker entra en estado Open.
Un cliente intenta hacer una compra con su tarjeta, pero el sistema le muestra un mensaje como: "El servicio de pagos no está disponible en este momento. Inténtelo más tarde."

3️⃣ Estado Half-Open (Semiabierto)

📌 Cuando el temporizador expira, el Circuit Breaker cambia a Half-Open y permite una única solicitud de prueba.

Caso 1: Si el pago es exitoso → Volvemos a Closed
El problema con el proveedor se ha solucionado. Se restablece el contador de errores a cero. Se reanudan todas las transacciones normalmente.

Caso 2: Si el pago falla de nuevo → Volvemos a Open
Se reinicia el temporizador. El servicio de pagos sigue inestable, por lo que se bloquean nuevamente las solicitudes.

Cuándo Usar Circuit Breaker

El Circuit Breaker es útil cuando:

Interacción con servicios externos: Evita depender de servicios que pueden estar fuera de nuestro control.
Servicios con alta latencia: Previene tiempos de espera largos y bloqueos en la aplicación.
Prevención de fallos en cascada: Protege al sistema de colapsos masivos.
Optimización de recursos: Evita desperdiciar CPU y memoria en solicitudes a servicios caídos.

Conclusión

El patrón Circuit Breaker es una estrategia clave en arquitecturas resilientes, especialmente en microservicios y sistemas distribuidos. Actúa como un "fusible", protegiendo el sistema de fallos en cascada, mejorando la estabilidad y asegurando una mejor experiencia para los usuarios. Implementarlo correctamente permite manejar fallos de manera eficiente y evitar problemas graves en aplicaciones críticas.

Introducción al Patrón Saga con AWS: Un Diseño para Manejar Transacciones Distribuidas

Jose Luis Ariza — Sun, 26 Jan 2025 13:56:52 +0000

En sistemas distribuidos, garantizar la consistencia de datos puede ser un gran desafío, especialmente cuando varios microservicios o componentes están involucrados. Aquí es donde entra en juego el Patrón Saga, una solución para manejar transacciones distribuidas de manera robusta y escalable. En este artículo, exploramos qué es el patrón Saga y como puede implementarse en AWS utilizando sus servicios.

¿Qué es Patrón Saga?

El Patrón Saga es un patrón de diseño utilizado para gestionar transacciones distribuidas en sistemas basados en microservicios. A diferencia de las transacciones tradicionales, que buscan consistencia a través de enfoques monolíticos, el Patrón Saga permite manejar la consistencia mediante una secuencia de transacciones independientes y coordinadas.

En el curso de AWS Skill Builder que lleve AWS: Diseño de Arquitecturas Basadas en Eventos, define al Patrón Saga de la siguiente manera:

Se utiliza para gestionar errores donde cada paso dentro de la transacción empresarial más grande incluye transacciones de compensación
que deshacen los cambios realizados por los predecesores.

Entonces podríamos definir que el Patrón Saga divide una transacción empresarial compleja en una serie de pasos más pequeños y autónomos, llamados transacciones locales. Si uno de estos pasos falla, se desencadenan eventos compensatorios.

Tipos de Sagas

Existen dos formas principales de implementar el Patrón Saga:

Sagas Coreografiadas
Aquí, los microservicios se comunican entre sí mediante eventos. Cada servicio escucha los eventos relevantes y realiza su tarea de forma autónoma. Este enfoque es altamente descentralizado, lo que reduce la dependencia de un coordinador central.
Sagas Orquestadas
En este enfoque, un servicio central llamado "Orquestador" gestiona el flujo de las transacciones. Este orquestador se encarga de invocar a los microservicios en el orden adecuado y maneja los errores que puedan surgir.

Implementación del Patrón Saga con AWS

AWS ofrece diversas herramientas que facilitan la implementación del Patrón Saga en arquitecturas de microservicios. A continuación, exploraremos cómo puedes utilizar los servicios de AWS para implementar este patrón de manera efectiva:

AWS Step Functions (Orquestación)

AWS Step Functions permite diseñar flujos de trabajo serverless que se adaptan perfectamente al modelo de orquestación del Patrón Saga. Con este servicio, puedes definir cada paso como una transacción local y gestionar tanto las acciones compensatorias como las excepciones en caso de errores.

Amazon EventBridge (Coreografía)

Para este tipo de enfoque, Amazon EventBridge es ideal. Este servicio permite crear buses de eventos que conectan microservicios de forma descentralizada. Los eventos pueden activar acciones específicas en otros servicios sin necesidad de un orquestador central.

Amazon SQS y SNS (Mensajería y Comunicación)

La mensajería entre microservicios es esencial para implementar Sagas. Amazon SQS y SNS son servicios de mensajería fiables que permiten que los microservicios se comuniquen de manera asíncrona, manteniendo el flujo de eventos necesario para las transacciones distribuidas.

DynamoDB con Streams (Gestión de Estados)

Para registrar el estado de cada transacción dentro de una Saga, DynamoDB con Streams puede ser utilizado. Esto asegura que los datos de cada paso estén disponibles en tiempo real y listos para desencadenar acciones compensatorias en caso de fallos.

Caso de Uso: Orquestación

Diagrama: Patón saga para Transacciones Distribuidas en Orquestación de Orden de Pago

1. API Create Order
El usuario interactúa con una API para crear una orden. Esta API es el punto de entrada del sistema y captura los detalles iniciales de la solicitud.

2. Step Functions: Order Orchestration
La orquestación de la orden comienza con AWS Step Functions, que controla el flujo del proceso y asegura que cada paso se ejecute en el orden correcto.

3. Microservicio Order: Place Order
El primer paso en el flujo orquestado es invocar el microservicio de órdenes para procesar la solicitud inicial de creación de la orden. Aquí se puede validar información inicial o asignar un identificador único a la orden.

4. Lambda: Check Customer Credit Status
Se invoca una función Lambda para verificar el estado de crédito del cliente. Esta función interactúa con una base de datos (Credit Status DB) que contiene el historial o estado crediticio del cliente.

5. Credit Status DB: Check Status
La base de datos devuelve el estado del crédito del cliente. Dependiendo de la respuesta: Si el crédito es insuficiente, el flujo sigue la ruta de fallo. Si el crédito es válido, el flujo continúa para completar la orden.

6. DynamoDB Orden: Complete Order
Si el estado de crédito es satisfactorio, los detalles finales de la orden se registran en DynamoDB como orden completada.

7. Amazon SNS: Order Succeeded
Una notificación de éxito se envía a través de Amazon SNS para informar que la orden fue procesada correctamente.

8. Amazon SNS: Order Failed
Si la verificación de crédito falla, Step Functions emite un evento de fallo a través de Amazon SNS para notificar que la orden no pudo completarse.

Caso de Uso: Coreografía

Diagrama: Patón saga para Transacciones Distribuidas en Coreografía de Orden de Pago

1. Usuario interactúa con la API Create Order
El usuario realiza una solicitud para crear una orden a través de una API expuesta. Esta API recibe los detalles de la orden y actúa como el punto de inicio del flujo de eventos.

2. Order Service recibe la solicitud
El servicio de órdenes (Order Service) procesa la solicitud inicial y genera un evento llamado Event OrderCreated, indicando que la orden ha sido creada exitosamente. Este evento es publicado en EventBridge para que otros servicios interesados lo consuman.

3. Evento OrderCreated es procesado por RouteOrderCreatedToPayment
EventBridge enruta el evento OrderCreated hacia el servicio de pagos (Payment Service) a través de la regla RouteOrderCreatedToPayment. Este servicio se activa automáticamente al recibir el evento.

4. Payment Service procesa el pago
El servicio de pagos valida y procesa el pago asociado con la orden. Una vez completado, genera un nuevo evento llamado PaymentProcessed, indicando el estado del pago.

5. Evento PaymentProcessed es enrutado
EventBridge enruta el evento PaymentProcessed hacia la regla RouteOrderCreatedToPayment, activando la siguiente etapa del flujo de eventos.

6. Notificación de éxito de pago
Si el pago es exitoso, se genera un evento PaymentSuccessNotification que notifica el estado exitoso al sistema o a otros servicios interesados. Este evento podría enviar una confirmación al usuario o actualizar el estado en un sistema de seguimiento.

7. Manejo de fallos en el pago
En caso de que el pago falle, se genera un evento llamado PaymentFailedEvent. Este evento puede ser utilizado para iniciar procesos compensatorios, como reembolsos, reversión de inventarios o notificaciones de error al usuario.

8. Notificación de fallo en la orden
Si el fallo del pago afecta toda la orden, se genera el evento Order Failed Event. Este evento centraliza el estado fallido de la orden, actualiza su estado en DynamoDB como "fallida" y notifica a los servicios interesados para realizar acciones compensatorias o informar al usuario.

Ventajas del Patrón Saga con AWS

Escalabilidad: Gracias a los servicios serverless de AWS, se puede realizar una arquitectura altamente escalable.
Alta disponibilidad: AWS garantiza disponibilidad en todos los componentes clave de la implementación.
Costos controlados: Con un modelo Pay-as-you-go, puedes optimizar el costo de tu infraestructura.

Conclusión

El Patrón Saga es una herramienta poderosa para resolver los desafíos de consistencia en transacciones distribuidas, especialmente en arquitecturas de microservicios. Con los servicios de AWS, puedes implementar este patrón de manera eficiente y asegurar la resiliencia y escalabilidad del sistema.