E188 - Arquitectura de Software - Las -ilities

Resumen

El episodio 188 de enCoders es la segunda sesión sobre arquitectura de software. Cris repasa la sesión anterior: cada problema de arquitectura es un "copo de nieve" que depende del contexto, y las tres leyes son que todo es un tradeoff, que hay que documentar el porqué (ADR) y que monolito y microservicios son un espectro. Aplica esas ideas al caso práctico de "Street Collect", una app de fotos de objetos curiosos con arquitectura basada en servicios. Después recorre las "-ilities", que son propiedades de una arquitectura y no features. Las agrupa en familias: operacionales (availability, performance/throughput, scalability/elasticity, reliability, fault tolerance, recoverability) y estructurales (maintainability, testability, deployability, modularity, extensibility, configurability, portability). Las conclusiones principales son que no se puede optimizar todo a la vez, que cada decisión depende del contexto y de las restricciones del negocio, y que ir rápido sin pensar en las propiedades estructurales se paga después. Cierra con la idea de documentar bien los repositorios para que también una IA los entienda. Quedan pendientes las familias de nube y transversales.

Capítulos

• 00:00
  IntroBienvenida al episodio 188 y presentación de la segunda parte de arquitectura de software, centrada en las "-ilities". También se anuncia un resumen de la primera sesión.
• 00:21
  Ser arquitecto sin barrerasCris quiere derribar las "murallas" (diplomas, certificados, experiencia) que hacen sentir que no se puede ser arquitecto. Si uno se hace las preguntas correctas, puede diseñar la arquitectura de su aplicación. Un experto toma decisiones más certeras en menos tiempo, mientras que un junior se demora más pero igual es arquitecto.
• 02:37
  Hacerlo y aprenderCris se compara con un diseñador de videojuegos que no necesita certificado para serlo. Se debate el "háganlo y lo serán": se parte siendo malo y se mejora de a poco, equivocándose.
• 03:47
  Resumen de la sesión anteriorEl plan es resumir lo anterior, entender las unas 26 propiedades de una arquitectura y derivar su significado con preguntas lógicas. Para el caso práctico usará GCP porque sigue teniendo créditos (crea cuentas nuevas cada tres meses). Se basa en dos libros de O'Reilly (fundamentos de arquitectura y "hard parts"). Cada problema es un copo de nieve que depende del contexto (equipo, organización, público). Ejemplo: no usar SageMaker porque el equipo es técnico, y el gran problema del machine learning es tener algo útil, no pasarlo a producción. La arquitectura son decisiones, no código.
• 08:16
  Tradeoffs y ADRLas tres leyes: todo es un tradeoff, hay que documentar el porqué y no hay una única arquitectura mejor. Si no hay tradeoff, no es una decisión relevante. En el trabajo de uno de los participantes usan ADR (Architecture Decision Records) en markdown dentro de un repositorio como base de conocimiento.
• 11:05
  Monolito vs microserviciosHay siete estilos de arquitectura y es un espectro: entre un monolito y muchos microservicios hay opciones intermedias como pocos servicios. Se compara con dividir un análisis de datos en 20 scripts o en 2. Se menciona una empresa que migró de la nube a on-premise y bajó de 4 millones de dólares anuales a 1 millón. También se discute elegir entre Claude Code y GPT con argumentos y no por moda, el riesgo de "si tengo un martillo todo es un clavo" y la parálisis por análisis. Se cita una definición de arquitecto: quien toma las decisiones más difíciles y costosas de revertir.
• 20:23
  Ejemplo prácticoPresenta Street Collect, una app/red social para compartir fotos de cosas raras halladas en viajes, con reconocimiento del objeto y conversión a 3D. Se elige arquitectura basada en servicios (subida de imagen, guía y notificación) porque cada servicio escala distinto. Si se cae uno, la app sigue funcionando parcialmente.
• 22:21
  Qué son las ilitiesUna "-ility" es una propiedad y no una feature. Los participantes conocen algunas, sobre todo scalability y similares.
• 23:38
  Preguntas para derivarlasCris no quiere memorizar y usa preguntas para derivar las propiedades: dónde se aloja la aplicación (un videojuego corre en el PC del usuario, en la nube se pagan los recursos), cuántos usuarios hay y si son de uso intensivo.
• 25:21
  Herramientas y Cloud DesignLa presentación se hizo con Claude Design, que tiene tokens separados y se consumieron. Se puede descargar a PowerPoint y editar. También se menciona el complemento de Claude para Excel y PowerPoint y que se le pasó un markdown con todo el contenido. Se comenta que la portabilidad es clave para un videojuego, y que las familias son operacionales, estructurales, de la nube y transversales (las resaltadas en celeste son las elegidas para su app).
• 29:42
  AvailabilityEs el porcentaje de tiempo que el sistema está arriba. Las nubes ofrecen cerca de 99,99% y pueden fallar. En sistemas de pago, unos minutos caídos pueden costar millones. Es contextual (una prueba de concepto no lo necesita) e incluye si la organización está disponible fuera de horario. En medio hay anécdotas sobre cómo Claude responde cuando se le trata mal.
• 37:05
  Performance y throughputLa performance se mide con latencia (cuánto tarda en responder) y throughput (cuántas personas aguanta por segundo). Para algunas tareas, como un análisis completo en Claude, media hora es aceptable. Ejemplos de colapso: Black Friday y lanzamientos de juegos populares.
• 38:44
  Escalabilidad vs elasticidadEscalar es aumentar gradualmente la carga sin degradar el rendimiento. La elasticidad es aguantar picos (concierto, Black Friday) y luego liberar recursos para no pagar. Se responde una pregunta del chat sobre cómo postular a analista de datos junior: negocio, métricas, dashboards, test de hipótesis, estadística básica, Power BI o Looker, Python y motivación. Después se discute si sobredimensionar es costoso y el caso de un `int` de 32 bits que se desbordó en IDs de transacción. También se habla de optimizar pronto frente a pagar el costo cuando haya usuarios, y del "cold start" de los servicios elásticos.
• 49:30
  Reliability y ejemplosEs que el sistema haga lo prometido sin errores silenciosos, algo en lo que uno puede "apoyarse" (rely). Ejemplos: pagos y tarjetas en el extranjero. Falla generalmente por mal diseño y configuración, no por falta de recursos.
• 52:21
  Momento hate con el bancoAnécdota sobre un banco (sin nombrarlo, "rojo con una llama") cuya app se cae a las 2 de la tarde y obliga a ingresar la clave muchas veces. Se concluye que hoy los usuarios no tienen paciencia.
• 54:20
  Fault toleranceSeguir funcionando, quizás degradado, cuando falla un componente (por ejemplo, si cae el servicio de IA la parte core sigue). Se menciona Chaos Monkey de Netflix, que apaga servicios al azar.
• 55:59
  Microservicios vs monolito distribuidoSi un servicio se cae y todo se cae, no era microservicios sino un monolito distribuido.
• 56:25
  Recoverability y auto healingMide cuánto tarda el sistema en funcionar de nuevo tras una falla. Idealmente es automático, por ejemplo con pods en Kubernetes. Los rollbacks se complican con varios sistemas y bases de datos.
• 58:52
  Resumen de propiedades operacionalesLas siete propiedades operacionales mantienen la aplicación funcionando 24/7 sin que el usuario note nada, ni en picos ni en cambios.
• 01:00:30
  MemesSe revisan memes y comentarios del chat: Chaos Monkey frente a una hipotética "operación Daisy", posts de LinkedIn, el autocompletado de Cursor sugiriendo tokens, y un enlace bloqueado por el antivirus.
• 01:06:00
  Opus y el costo de tokensSe comenta el nuevo Opus: da mejores respuestas, pero los tokens se acaban más rápido porque se trabaja en varios proyectos en paralelo. Hay que revisar lo que genera porque puede romper el diseño global o sobrecomplicar.
• 01:09:18
  Propiedades estructuralesIntroducción a la segunda familia: cómo sobrevive el código al paso del tiempo.
• 01:09:37
  Maintainability y testabilityMaintainability es qué tan fácil es cambiar el sistema sin romper cosas, y se recomienda partir con la solución más simple. Testability es qué tan fácil es verificar que funciona: tests unitarios, de integración, de estrés. Se debate que un buen sistema de tests agiliza el desarrollo.
• 01:15:13
  Velocidad vs calidad y tradeoffsHay que ir rápido porque de diez ideas solo una sirve, pero si funciona hay que arreglar lo crítico. Se bromea con la "antiability" y el "retard maxxing". Se discute una pausa para refactorizar, decir que no con transparencia y una decisión consciente.
• 01:18:00
  Deployments y modularidadDeployability es poner en producción; los ambientes de desarrollo, staging y producción suelen estar configurados distinto y hay quienes despliegan los viernes. Modularidad es separar el sistema en partes, como Lego.
• 01:20:36
  Extensibility y configurabilityExtensibility es cuánto se pueden extender las funcionalidades. Configurability es cambiar el comportamiento por configuración sin tocar el código, por ejemplo en software de simulación de fluidos. Se sugiere tener archivos de configuración por ambiente. La presión por ir rápido hace que estas propiedades se omitan, y se discute cuándo negociar tiempo para arreglarlas.
• 01:29:08
  Portabilidad y cloud lock inPortabilidad es poder cambiarse de entorno: ser agnóstico a la nube o comprometerse con una sola.
• 01:29:50
  Documentación para humanos y IAUn comentario del chat propone una propiedad más: que la IA entienda el código. Cris lo plantea como documentar bien el repositorio en markdown y texto plano (estructura, carpetas, propósito) para que una IA pueda modificarlo, algo distinto de un archivo skill. Surgen frameworks para trabajar con Claude Code.
• 01:34:33
  CierreReflexión final: muchos conceptos se conocían de forma intuitiva sin su nombre. La próxima sesión cubrirá las otras dos familias, y la siguiente semana habrá un episodio sobre un algoritmo de clustering desde cero.

Palabras clave