E185 - Arquitectura de Software 101

Resumen

El episodio 185 de enCoders introduce la arquitectura de software desde la perspectiva de la ciencia de datos y la ingeniería. Los conductores sostienen que la arquitectura no es un campo reservado a expertos con certificados, sino un proceso de tomar decisiones haciendo las preguntas correctas. La experiencia solo reduce el tiempo y los errores, y la IA puede ayudar a escribir código, pero no reemplaza la decisión de cómo organizar el sistema. Se apoyan en tres "leyes" de los libros de O'Reilly (todo es un tradeoff, el porqué importa más que el cómo, las decisiones son un espectro) y recomiendan documentar las decisiones (ADR, knowledge base). Discuten microservicios vs. monolito, monorepo, latencia vs. throughput y sincronía vs. asincronía. Cierran con un ejemplo ficticio (Street Collect) y el mensaje final: preguntar "por qué" constantemente y entender el contexto de negocio.

Capítulos

• 00:00
  IntroPresentación del episodio 185 sobre arquitectura de software 101: importancia, buenas prácticas y antipatrones. Uno de los conductores menciona que usa ADR en su trabajo actual y los encuentra muy útiles.
• 00:43
  Arquitectura para datosPara sacar provecho de un modelo hay que ponerlo en un ambiente ordenado, que no se caiga, se conecte a las herramientas, maneje la cantidad de usuarios y no agote la memoria, sea en vivo o batch.
• 01:48
  Rompiendo el mitoSe busca derribar la idea de que se necesita ser experto o tener años de estudio para hacer arquitectura. Los años de experiencia solo permiten decidir más rápido y con menos errores; un novato tarda más pero puede llegar a una solución cercana al 80%. Saber arquitectura permite ordenar el código generado con IA.
• 04:26
  Certificados y experienciaComentan que salen certificados de cloud architect y pronto de "IA architect", y que esto crea de nuevo un bloqueo mental. Uno de ellos dice que no le gustan los certificados porque solo prueban que se pasó un curso; la arquitectura es cómo se toman decisiones, no código.
• 05:39
  Cuando la arquitectura fallaHistoria (contada por Moisés en el capítulo 79) de una lambda disparada por un archivo en S3 que creaba otro archivo en el mismo S3, generando un loop infinito y un gasto enorme en pocas horas. El código era correcto, el sistema no.
• 06:32
  AgendaTemas: por qué importa la arquitectura, tres leyes, pensar como arquitecto, tradeoffs, un caso hipotético y componentes en AWS. Se basan en dos libros de O'Reilly (Fundamentals of Software Architecture y Software Architecture: The Hard Parts) y en el capítulo con Moisés, architect en una multinacional.
• 09:02
  Lo que la IA resuelve versus lo que noLas decisiones de arquitectura dependen del contexto y no tienen una respuesta única como una búsqueda binaria. La IA es un complemento que agiliza, pero uno debe guiarla. Cita del libro: cada problema de arquitectura es un "copo de nieve" único.
• 10:54
  Diferencia entre entrenamiento y educaciónEl entrenamiento es repetir pasos (configurar una lambda); la educación es definir qué, cuándo y por qué, adaptándose al entorno cambiante. No hay que adoptar tecnologías de moda (microservicios, agentes) sin entender si mejoran la solución. Mencionan los "harnesses" para agentes como arquitectura reciente.
• 12:32
  Buenas prácticasLa arquitectura no es un framework único sino las decisiones que uno toma; se compara con Agile vs. Scrum/Kanban, que serían implementaciones y no obligaciones. Cada equipo puede definir su propia estructura y metodología e iterarla con retrospectivas. Lo clave es preguntarse por qué; no hay que memorizar los libros sino reflexionar cómo se habría decidido en ese contexto.
• 19:35
  Decisiones técnicas que explotanMomento interactivo. Ejemplos: adoptar el framework de Black Rock/McKinsey para ML, que tuvo poca adopción por ser sobredimensionado; y usar lambdas de AWS que luego hubo que migrar a DAGs de Airflow porque el equipo de operación usaba Airflow, sin haber consultado sus restricciones.
• 23:24
  Tradeoffs y ADRsLey 1: toda la arquitectura es un tradeoff; si no se ve el costo es que no se está analizando. Hay que dejar por escrito la decisión, el contexto y el costo aceptado. Describen su knowledge base (carpetas de diseños de arquitectura, decisiones, ejemplos y guías) que ayudó en el onboarding y es aún más útil con IA.
• 27:06
  Microservicios vs monolitoMicroservicios: escalabilidad independiente, tolerancia a fallos, equipos autónomos. Monolito: simplicidad operacional y más facilidad con transacciones ACID. Explican ACID con el ejemplo de pagos bancarios, y discuten la consistencia entre bases de datos de distintos servicios. Ley 2: el porqué importa más que el cómo ("si solo tienes un martillo todo parece un clavo"); conviene empezar simple. Mencionan el uso de deep learning o grafos solo por currículum, y comentarios del chat sobre CQRS, circuit breaker y patrón saga.
• 37:51
  Monorepo vs monolitoMonorepo y monolito son cosas distintas. Un monorepo sirve en proyectos pequeños; en proyectos grandes puede convenir separar el repo de infraestructura como código. Ejemplo de un videojuego en Godot con una librería en Rust que pasó de dos repos a un monorepo por la iteración constante. No hay que ser "fan" de una arquitectura; todo depende del contexto, también con Python vs. R. Insisten en entender al cliente final y las habilidades blandas.
• 44:06
  MemesPausa de memes: el compromiso de la librería LiteLLM por envenenamiento del repositorio, el pato de goma (rubber duck debugging) y su relación con usar la IA para depurar, la filtración del código de Claude Code en npm, el hackeo de Axios y la ley de Conway aplicada a los managers.
• 52:17
  Decisiones en espectroLey 3: las decisiones no son binarias, hay un espectro (monolito, monolito modular, service-based, microservicios). Cita del libro sobre desarrolladores atraídos por la complejidad como polillas a la llama.
• 55:06
  Pensar con el negocioEs tan crítico elegir qué no soportar como qué sí; se ilustra con el barco Vasa. Se sugiere priorizar las tres características más críticas de máximo siete. Traducen frases del negocio a conceptos técnicos: escalabilidad, elasticidad, disponibilidad, tolerancia a fallos, desempeño, agilidad y simplicidad.
• 56:26
  Latencia vs throughputPregunta interactiva: si el cliente pide "que sea rápido" hay que averiguar qué significa. Latencia es cuánto tarda en responder; throughput es la capacidad de procesar carga. Ejemplo con un LLM de 7B parámetros en una GPU, donde la VRAM limita la concurrencia.
• 01:01:12
  Arquitectura como procesoLa arquitectura es un proceso iterativo: entender el problema, traducirlo a características, proponer estructura, descubrir tradeoffs, ajustar y repetir. Una frase del libro: muchas soluciones resolvieron correctamente el problema equivocado. Hay que entender el problema de negocio antes de abrir pandas.
• 01:07:27
  Amplitud sobre profundidadRecomiendan al arquitecto tener amplitud (concepto de la T) para reconocer rápidamente por dónde va la solución.
• 01:08:50
  Ejemplo con app ficticiaStreet Collect: app donde se suben fotos de objetos de la calle o de viajes, una IA los clasifica y genera un tótem 3D coleccionable, con componente social. Las características prioritarias son escalabilidad global, disponibilidad y control de costos. Componentes: autenticación, subida y almacenamiento, reconocimiento, catálogo, mapa, feed y notificaciones. Se decide que el reconocimiento puede ser diferido por costo y experiencia de usuario.
• 01:14:22
  Monolito vs microserviciosUn monolito es simple y barato, pero un microservicio permite que si falla un componente (por ejemplo, la IA o lo social) la app siga funcionando y escalar la GPU por separado. Se opta por service-based más serverless como "la combinación menos mala". Bases de datos por componente (SQL relacional, DynamoDB). Cita: si los microservicios deben desplegarse juntos en un orden específico, hay que volver a un monolito. Analogía de los vasos de agua.
• 01:22:04
  Servicios cloud y asincroníaSe aterriza en servicios: CloudFront, lambdas, Bedrock, DynamoDB, SNS, S3. Explican comunicación sincrónica vs. asincrónica y usan una cola para procesar imágenes con una sola GPU. Estiman costos bajos salvo por la IA, y retoman el bucle infinito de lambda/S3. Queda pendiente la frase sobre el acoplamiento semántico para otro capítulo.
• 01:27:53
  CierreMensaje final: preguntar siempre "por qué", alinearse con lo que se espera en el trabajo y entender el contexto de negocio. Anuncian el próximo episodio con tema por confirmar.

Palabras clave