Virtualización y Containerización

En la Unidad 1 vimos qué es "la nube" como modelo. En esta unidad bajamos un nivel: ¿cómo hace técnicamente un proveedor para que muchos clientes compartan un mismo servidor físico sin pisarse? La respuesta tiene dos capas, una sobre la otra: virtualización y containerización.

1. La idea de fondo

Una computadora física es cara, ocupa espacio y consume energía. Si en cada servidor corre una sola aplicación, la mayoría del tiempo está al 10 % de uso: pagamos por capacidad que no usamos. Las dos tecnologías de esta unidad resuelven el mismo problema desde ángulos distintos: aislar varias cargas dentro de un mismo hardware para aprovecharlo bien.

2. Virtualización

La idea de virtualización es vieja: ya estaba en los mainframes de IBM de los años 60-70 (CP/CMS, VM/370), donde se usaba para tiempo compartido entre usuarios. Lo que apareció en los 2000 fue la virtualización x86 mainstream (VMware ESX en 2001, Xen en 2003, KVM en 2007), que llevó esa idea al hardware de commodity y fue la primera respuesta seria al problema del desperdicio en servidores comunes. Permite ejecutar varios sistemas operativos completos sobre un mismo hardware, cada uno dentro de una "máquina virtual" (VM).

3. Containerización

Las VMs resuelven el problema del aislamiento, pero arrastran un costo: cada una lleva un sistema operativo entero adentro. Si necesitás 50 VMs para 50 microservicios, tenés 50 kernels corriendo en paralelo. Mucho desperdicio de RAM y disco. La containerización es la siguiente vuelta de tuerca: aprovecha que el sistema operativo ya está corriendo y aísla solamente los procesos.

Container contenedor

Un proceso (o grupo de procesos) que corre sobre el kernel del sistema operativo del host, pero con su propio sistema de archivos, su propia red y sus propios límites de recursos. No tiene sistema operativo propio: comparte el del host.

Metáfora

Como un local en un shopping: usás la estructura, electricidad y aire acondicionado del edificio (kernel del host), pero adentro decorás y vendés lo que vos quieras, sin ver a los locales vecinos.

Tecnologías populares

Docker Podman containerd LXC / LXD

Ventajas frente a una VM

• Arranque en milisegundos (vs minutos de una VM).
• Imagen liviana: decenas de MB vs gigabytes.
• Reproducible: la misma imagen corre igual en tu laptop, en CI y en producción.

4. VM vs Contenedor

La pregunta "VM o contenedor" no tiene una respuesta única: depende del aislamiento, la portabilidad y la velocidad que necesites.

Máquina virtual vs Contenedor

Máquina virtual

• Aislamiento fuerte (kernel propio).
• Puede correr cualquier SO.
• Arranque en minutos.
• Pesada (GB de disco, mucha RAM).

Contenedor

• Liviano (MB de disco, poca RAM).
• Arranque en milisegundos.
• Comparte kernel con el host (menor aislamiento).
• Atado al SO del host (un contenedor Linux no corre en Windows nativo).

5. Docker, el estándar de facto

Docker no inventó los contenedores —la tecnología venía desde los 2000 con cgroups y namespaces en Linux— pero los hizo accesibles a todo el mundo en 2013 con un CLI simple, un formato de imagen estándar y un registry público. Hoy es prácticamente sinónimo de "contenedor" en el día a día. Para el panorama completo de productos gestionados por proveedor (ECS, GKE, Cloud Run, Container Apps, Fly.io y el resto) y cuándo conviene cada uno, ver el recurso containers.

Docker es un conjunto de herramientas para construir, distribuir y ejecutar contenedores. Tiene tres componentes principales: el daemon (servicio en segundo plano que ejecuta los contenedores), el CLI (el cliente que usás vos para darle órdenes) y el registry (Docker Hub u otros, donde se publican las imágenes). La pieza más importante para el desarrollador es el Dockerfile: un archivo de texto que describe paso a paso cómo construir una imagen. A partir de él, docker build produce la imagen, docker run levanta un contenedor desde ella, y docker push / pull la sube o baja de un registry.

# Ver contenedores corriendo
docker ps

# Ver TODOS los contenedores (incluso los detenidos)
docker ps -a

# Entrar a un contenedor con shell
docker exec -it <container_id> sh

# Ver logs en vivo
docker logs -f <container_id>

# Detener y eliminar un contenedor
docker stop <container_id> && docker rm <container_id>

# Limpiar imágenes, contenedores y volúmenes sin usar
docker system prune -a --volumes

6. Persistencia y red

Por defecto, los contenedores son efímeros: cuando se eliminan, sus datos se pierden. Y están aislados de la red del host. Para apps reales necesitamos dos cosas: una forma de persistir datos y una forma de comunicar contenedores entre sí.

Para resolver la persistencia, Docker provee volúmenes: espacios de almacenamiento gestionados por el motor que sobreviven al ciclo de vida del contenedor. Se montan dentro de uno o varios contenedores y los datos escritos ahí persisten aunque el contenedor se elimine. Hay tres tipos: named volumes, gestionados por Docker y recomendados para datos de aplicaciones; bind mounts, que mapean un directorio del host directamente al contenedor (útil en desarrollo); y tmpfs, almacenamiento en RAM que se pierde al reiniciar. Un ejemplo típico: docker run -v miapp_datos:/var/lib/postgresql/data postgres:16.

Para resolver la comunicación entre contenedores, Docker crea redes virtuales. Dentro de una misma red, cada contenedor "ve" a los demás por su nombre de servicio en vez de por IP. Las redes típicas son: bridge (default, red privada entre contenedores del mismo host), host (sin aislamiento, comparte la red del host), overlay (distribuida entre múltiples hosts, usada por Swarm y Kubernetes) y none (aislamiento total sin red). Así, si tu aplicación se llama web y la base se llama db, podés conectarte desde la app a postgres://db:5432 y Docker resuelve el nombre internamente.

7. Orquestación: cuando un solo host no alcanza

Con Docker corriendo en una máquina solucionás el "desarrollo local" y los despliegues simples. Pero en producción real necesitás varios hosts, balanceo de carga, reinicios automáticos, despliegues sin interrupción y escalado horizontal. Esa capa se llama orquestación. Una alternativa para evitar parte de esa complejidad cuando el caso de uso es event-driven y la carga es esporádica es ir directo a serverless: el proveedor decide dónde y cuándo correr tu código y vos no operás cluster.

Para escenarios más simples existe Docker Compose, una herramienta de Docker para definir aplicaciones multi-contenedor en un solo archivo YAML (compose.yaml) y levantarlas con un comando. No reemplaza a Kubernetes, pero es el "punto dulce" para desarrollo local, demos y producciones chicas. Un compose.yaml típico define un servicio web (tu app), un servicio db (Postgres) y un volumen para la base; con docker compose up -d levanta todo configurado y conectado. Es exactamente lo que usa este mismo proyecto Sidecar.

8. Errores comunes

Usar la etiqueta :latest en producción

Qué suele pasar

El despliegue funciona hoy con nginx:latest; mañana sale una versión major nueva, :latest apunta a ella y tu producción se rompe sin que hayas tocado nada.

Por qué

:latest es una etiqueta mutable: lo que apunta hoy puede ser distinto mañana. Rompe la promesa de reproducibilidad de los contenedores.

Cómo evitarlo

Usá etiquetas específicas (nginx:1.27.3) o, todavía mejor, digests inmutables (nginx@sha256:abc...) en los manifiestos de producción.

9. Tips y buenas prácticas

10. Glosario rápido

11. Para profundizar

12. Cierre

Arquitectura básica en la nube

En la Unidad 2 vimos las dos capas técnicas que sostienen la nube (virtualización y containerización). En esta unidad subimos un nivel: ¿qué principios guían las decisiones de arquitectura cuando diseñamos para la nube? Vamos a ver tres leyes empíricas que, una y otra vez, predicen por qué los sistemas distribuidos funcionan o fracasan: la Ley de Conway, la Ley de Gall y el Principio CAP.

1. ¿Por qué leyes y no recetas?

A diferencia de la Unidad 2, acá no hay comandos para copiar. Las leyes que siguen son observaciones sobre cómo se comportan los sistemas distribuidos y las organizaciones que los construyen. Conocerlas no te dice qué elegir, te dice por qué tu elección va a salir bien o mal. Diseñar arquitectura cloud sin estas leyes es como diseñar un puente sin entender de física: a veces se aguanta, pero no sabés por qué.

2. Ley de Conway

Enunciada por Melvin Conway en 1967, antes de que existiera "la nube". Conway era programador y notó un patrón inquietante: la arquitectura del software refleja la arquitectura social del equipo que lo construye.

Concepto clave

"Las organizaciones que diseñan sistemas están condenadas a producir diseños que copian la estructura de comunicación de dichas organizaciones." — Melvin Conway, 1967

Por qué importa en la nube

La nube favorece sistemas distribuidos: microservicios, serverless, contenedores orquestados. Cada uno de esos componentes tiene un dueño humano. Si los humanos no se comunican de forma desacoplada, los componentes tampoco lo harán. Es por eso que dos empresas con la misma stack pueden terminar con arquitecturas radicalmente distintas.

Las consecuencias en cloud

Equipos aisladosArquitectura desacoplada, microservicios bien definidos.

Equipo único y grandeMonolito o sistema con acoplamiento fuerte.

Comunicación rígidaIntegraciones pesadas, contratos fijos, APIs poco evolutivas.

Para tener en cuenta

• La "Inverse Conway Maneuver": si querés cierta arquitectura, primero diseñá los equipos que la producirán.
• Conway aplica también a la cultura: un equipo que no confía entre sí va a construir contratos defensivos.

Ejemplos de Conway en la nube

Los patrones más comunes que se ven en la práctica son cuatro. Cuando una empresa tiene equipos independientes para pagos, catálogo y usuarios, cada uno termina desplegando su propio servicio con la tecnología que mejor le sienta: pagos con AWS Lambda + API Gateway, catálogo con contenedores en EKS, usuarios con Firebase. El resultado es una arquitectura multi-cloud desacoplada, con escalado y despliegues independientes por servicio. En el otro extremo, un equipo único y grande que gestiona toda la aplicación produce un monolito en una VM. Tiene sentido organizacional —una sola reunión, una sola release— pero arrastra cuellos de botella en los deploys, escalado horizontal limitado y la fragilidad de que un bug en cualquier módulo tumba todo.

Cuando dos equipos necesitan integrarse pero la comunicación es rígida, la solución típica es una cola de mensajes (SNS/SQS, Pub/Sub) con un contrato fijo. Parece desacoplar, pero solo cambia el lugar del acoplamiento: ahora vive en el contrato del mensaje, y si un equipo lo cambia, el otro se rompe igual. Por último, cuando hay DevOps por producto —cada equipo construye, opera y monitorea su propio servicio de punta a punta— la tendencia natural es elegir servicios serverless (Lambda + DynamoDB) por equipo, con la mínima dependencia cruzada posible.

3. Ley de Gall

Enunciada por John Gall en 1975 (en Systemantics), es la ley que más arquitectos cloud ignoran y más caro pagan cuando lo hacen. Tiene tres formulaciones complementarias:

Concepto clave

"Un sistema complejo que funciona invariablemente ha evolucionado a partir de un sistema simple que funcionaba." — John Gall, 1975

Los dos corolarios

Corolario AUn sistema complejo diseñado desde cero nunca funciona y no puede repararse para hacerlo funcionar: hay que empezar de nuevo desde un sistema simple.

Corolario BLos sistemas tienden a crecer en complejidad hasta superar la capacidad de sus diseñadores para manejarlos.

Por qué importa en la nube

La nube ofrece tantas piezas que es muy tentador armar la arquitectura "perfecta" desde el día 1: Kubernetes multi-región, service mesh, observabilidad completa, GitOps, etc. Gall predice qué va a pasar: el equipo se va a hundir operando esa complejidad antes de tener clientes que la justifiquen.

Para tener en cuenta

• "Simple primero" no significa "para siempre simple": es el punto de partida desde donde evolucionar.
• La complejidad debe responder a un problema real ya observado, no a uno anticipado.

Caso: evolución natural de monolito a serverless

Anti-patrón: la arquitectura "perfecta" del día 1

Caso: una API que creció bien

Caso real ilustrativo: Netflix empezó con un monolito en sus propios data centers. Migró a AWS de a poco, no de un día para el otro, y construyó sus herramientas famosas (Chaos Monkey, Hystrix) para aprender a operar la complejidad emergente, no para evitarla por diseño previo.

4. Principio CAP

Formulado por Eric Brewer en 2000 (conjetura) y demostrado formalmente por Gilbert y Lynch en 2002, el teorema CAP es la ley física de los sistemas distribuidos. No describe una preferencia: describe un límite que no se puede superar.

Concepto clave

En un sistema distribuido solo podés garantizar dos de tres: Consistencia, Disponibilidad y Tolerancia a particiones.

Las tres propiedades

C — ConsistenciaTodos los nodos ven los mismos datos al mismo tiempo.

A — DisponibilidadEl sistema responde siempre, incluso si hay fallos.

P — Partition toleranceEl sistema sigue funcionando aunque se pierda la comunicación entre nodos.

El verdadero dilema en la nube

En cloud, las particiones de red son inevitables: zonas de disponibilidad caídas, latencia variable, cables submarinos cortados. Por eso P no es opcional. El verdadero dilema se reduce a: ¿Consistencia (C) o Disponibilidad (A)?

Para tener en cuenta

• El trade-off no es siempre el mismo dentro de una misma app: la facturación pide CP, el feed social pide AP.
• "Consistencia eventual" no es ausencia de consistencia: es consistencia diferida en el tiempo.

¿Por qué CA es imposible en la nube?

CP vs AP: cuándo elegir cada uno

Perfil CAP de algunos servicios cloud comunes

En el bando CP están servicios que prefieren bloquear escrituras antes que devolver datos inconsistentes: Amazon RDS con réplica síncrona, y Google Cloud Spanner, que garantiza consistencia global usando relojes atómicos al precio de rechazar escrituras en particiones graves. Del lado AP, Amazon DynamoDB ofrece consistencia eventual por defecto (con lecturas fuertemente consistentes opcionales a mayor costo), y Redis Cluster permite que los datos diverjan temporalmente entre shards. Azure Cosmos DB es un caso aparte: expone cinco niveles de consistencia configurables, dejando que el desarrollador elija dónde sentarse entre CP estricto y AP puro según el caso.

Ejemplo de uso mixto bien hecho: Netflix usa DynamoDB (AP) para su catálogo —donde lo que importa es responder rápido aunque un título tarde en propagarse— y Aurora (CP) para su facturación, donde una inconsistencia es inaceptable.

PACELC: la extensión moderna de CAP

Una crítica frecuente a CAP es que solo describe qué pasa cuando hay partición. PACELC, formulado por Daniel Abadi en 2010, completa la imagen: si hay partición (P), elegí entre A y C —ese es el caso original de CAP—; else (en operación normal, sin partición), elegí entre L (latencia) y C (consistencia). La idea es que incluso cuando la red anda bien, mantener consistencia entre nodos cuesta tiempo: sincronizar réplicas suma latencia, y muchos sistemas aceptan consistencia eventual también en estado normal para responder más rápido. DynamoDB, por ejemplo, es PA/EL: ante partición prioriza disponibilidad, y en operación normal prioriza latencia sobre consistencia estricta. Spanner es PC/EC: consistencia estricta en ambos casos, al precio de mayor latencia.

Si querés el espectro completo de productos por proveedor —tanto del lado relacional como NoSQL— y cuándo conviene cada perfil, ver el recurso database. Para los almacenes en memoria que aparecen del lado AP cuando hace falta velocidad sobre consistencia, ver el recurso cache. Y para desacoplar productores y consumidores aceptando consistencia eventual a propósito —la herramienta clave para construir sistemas AP sin perder operaciones—, ver el recurso colas de mensajes.

5. Cómo se conectan las tres leyes

6. Errores comunes derivados

7. Tips y buenas prácticas

8. Glosario rápido

9. Para profundizar

10. Cierre

Metodologías Ágiles y Ciclo de Vida del Software

Las tres unidades anteriores describieron qué es la nube, cómo se construye por debajo y qué leyes la gobiernan. Esta unidad cambia el foco: en vez de hablar de la tecnología, hablamos del proceso con el que los equipos producen software para correr en esa tecnología. Vamos a recorrer los modelos clásicos del ciclo de vida del software, entender por qué la industria los abandonó casi en masa a favor del enfoque ágil, y ver cómo esa transición prácticamente coincide con la adopción de la nube.

1. ¿Por qué hablar de metodologías en un curso de nube?

Podría parecer que el ciclo de vida del software es un tema aparte, pertenece a una materia distinta. Pero en la Unidad 3 vimos la Ley de Conway: la arquitectura del sistema refleja la estructura de comunicación del equipo que lo construye. Esa ley tiene un corolario directo y poco discutido: la arquitectura también refleja el proceso con el que el equipo trabaja. Un equipo que despliega una vez por trimestre no produce microservicios independientes; los necesita acoplados para poder coordinarlos. Un equipo que despliega varias veces por día casi inevitablemente termina con componentes pequeños y autónomos.

La nube y las metodologías ágiles crecieron juntas durante las últimas dos décadas porque resuelven, en planos distintos, el mismo problema: cómo construir y operar software complejo sin colapsar bajo su propio peso. La nube aporta la infraestructura elástica; el agilismo aporta la forma de trabajo capaz de aprovecharla. Sin una metodología iterativa, una arquitectura cloud-native termina desperdiciada; sin nube, una metodología ágil choca contra los tiempos de aprovisionamiento de hardware.

2. El ciclo de vida del software, brevemente

Construir software no es una actividad puntual sino un proceso continuo que arranca antes de la primera línea de código y termina (si es que termina) bastante después de la última. La industria llama ciclo de vida del software (SDLC, Software Development Life Cycle) al conjunto de fases que recorre una pieza de software desde su concepción hasta su retiro: definición de requisitos, análisis, diseño, implementación, prueba, despliegue, operación y mantenimiento, y eventualmente decomisado.

Lo que varía entre metodologías no son las fases en sí —cualquier proyecto real las atraviesa todas, le guste o no— sino cómo se ordenan y cuán rígida es la frontera entre ellas. Las metodologías tradicionales tratan al ciclo como una secuencia: terminada una fase, se pasa a la siguiente y no se vuelve atrás. Las metodologías modernas tratan al ciclo como un bucle: cada fase informa a las demás, y se atraviesan todas muchas veces en pequeñas iteraciones.

3. Los modelos clásicos

Cascada

El modelo cascada (waterfall) fue formalizado por Winston Royce en 1970, aunque, dato curioso, su paper original lo presentaba como un anti-patrón, no como una recomendación. Royce describía el modelo lineal —requisitos, diseño, implementación, prueba, despliegue— y explicaba inmediatamente por qué casi nunca funciona en proyectos reales. La industria, sin embargo, leyó la primera mitad del paper y adoptó la cascada como buena práctica durante las siguientes tres décadas.

La promesa de la cascada es seductora: si planificamos todo bien al principio, la ejecución se vuelve previsible. La realidad demostró que los requisitos del software cambian constantemente, que el diseño no se puede pensar completamente sin codificar, y que los errores detectados al final cuestan exponencialmente más que los detectados al principio. La cascada sigue siendo razonable en proyectos donde los requisitos son verdaderamente estables y conocidos —construir un compilador para un estándar publicado, por ejemplo, o software embebido con certificación regulatoria— pero esos casos son la excepción, no la regla.

Modelo V

El modelo V es esencialmente una cascada plegada por la mitad. A cada fase de desarrollo (requisitos, diseño de sistema, diseño detallado, código) le corresponde una fase de validación simétrica (pruebas de aceptación, integración, unitarias). Su mérito fue institucionalizar la idea de que cada decisión de diseño implica un nivel correspondiente de pruebas. Sigue siendo común en industrias con requisitos de certificación estricta —aeroespacial, médica, ferroviaria— donde la trazabilidad entre requisito y prueba es un requerimiento legal.

Modelo iterativo e incremental

Los modelos iterativo e incremental ya rompen con la linealidad: en lugar de construir todo el sistema de una vez, se construyen versiones sucesivas, cada una más completa o más refinada que la anterior. Boehm propuso en 1986 el modelo espiral, que combina iteraciones con análisis de riesgo: cada vuelta de la espiral identifica y mitiga los riesgos más graves antes de avanzar. Estas ideas fueron la base intelectual del movimiento ágil, aunque tomaron veinte años en volverse mainstream.

4. El cambio: el Manifiesto Ágil

En febrero de 2001, diecisiete profesionales del desarrollo de software se reunieron en una estación de esquí en Snowbird, Utah. Venían de metodologías distintas —algunos de Extreme Programming, otros de Scrum, otros de Crystal o DSDM— pero compartían el diagnóstico: las metodologías pesadas y documentadas heredadas de los 80 estaban produciendo software malo, tarde y caro. Tres días después salieron de ahí con un texto breve que cambió la industria: el Manifiesto por el Desarrollo Ágil de Software.

Concepto clave

Los cuatro valores del Manifiesto Ágil (Snowbird, 2001).

El Manifiesto declara que, aunque hay valor en los elementos de la derecha, los firmantes valoran más los de la izquierda:

Valor 1Individuos e interacciones sobre procesos y herramientas.

Valor 2Software funcionando sobre documentación extensiva.

Valor 3Colaboración con el cliente sobre negociación contractual.

Valor 4Respuesta ante el cambio sobre seguir un plan.

Para tener en cuenta

• La frase "aunque hay valor en los elementos de la derecha" suele olvidarse: el manifiesto no dice que la documentación o los contratos sean malos, sino que cuando haya conflicto, gana lo de la izquierda.

El Manifiesto va acompañado de doce principios que lo explicitan. Sin enumerarlos todos, los más influyentes para el desarrollo en la nube son: la satisfacción del cliente mediante entregas tempranas y continuas; la bienvenida a cambios en los requisitos, incluso tarde en el desarrollo; la entrega frecuente de software funcionando en escalas de semanas, no meses; y la simplicidad —entendida como el arte de maximizar la cantidad de trabajo no hecho— como esencial. Si esa última frase suena a la Ley de Gall de la unidad anterior, no es coincidencia: el agilismo bebe directamente de esa tradición.

Es importante separar el agilismo como filosofía de los frameworks concretos que se inspiran en él. El Manifiesto no menciona Sprints, ni standups, ni Product Owners, ni story points. Esos son artefactos de Scrum, no del agilismo. Muchos equipos "hacen Scrum" sin entender el Manifiesto, lo que produce un teatro ceremonial sin ganancia real.

5. Scrum

Scrum es, por amplio margen, el framework ágil más adoptado de la historia. Fue formalizado a comienzos de los 90 por Ken Schwaber y Jeff Sutherland, inspirado en un paper de Takeuchi y Nonaka de 1986 ("The New New Product Development Game") que comparaba a los equipos de producto eficientes con un equipo de rugby avanzando en formación —de ahí el nombre, que significa "melé". La Scrum Guide oficial, mantenida por Schwaber y Sutherland, se reescribe cada pocos años y es notablemente breve: la última versión cabe en quince páginas.

Scrum organiza el trabajo en Sprints: iteraciones de duración fija, típicamente de dos semanas, durante las cuales el equipo produce un incremento de producto potencialmente entregable. La duración es fija para crear ritmo y predictibilidad; el contenido es variable, se ajusta a la realidad. Cada Sprint atraviesa las cuatro fases del ciclo de vida en miniatura: planificación, ejecución (que incluye diseño, código y prueba simultáneamente), entrega e inspección.

Roles

Scrum define tres roles, ni más ni menos. El Product Owner es responsable de maximizar el valor del producto: prioriza el backlog, decide qué se hace y qué no, y es la única persona con autoridad para cambiar prioridades durante la planificación. El Scrum Master no es un gerente ni un coordinador: es un facilitador que se encarga de que el proceso se respete, que el equipo no se distraiga y que los impedimentos se resuelvan. Los Developers (en la guía actual, sin más jerarquía) son las personas que construyen el incremento; el equipo es auto-organizado y multidisciplinario.

Eventos

Los rituales de Scrum son pocos y específicos. Cada uno tiene un propósito bien definido y un timebox máximo; cuando se respetan, sostienen el ritmo, cuando se relajan, el framework se desmorona en reuniones interminables.

Los cinco eventos de un Sprint

1. Sprint Planning. Al inicio del Sprint, el equipo decide qué entrega y cómo. Timebox: hasta 8 h para Sprints de un mes; proporcionalmente menos para Sprints más cortos.
2. Daily Scrum. 15 minutos diarios, mismo lugar y hora. El equipo sincroniza, identifica impedimentos y ajusta el plan del día. No es un reporte de status: es coordinación entre pares.
3. Sprint. El bloque de trabajo en sí, donde se construye el incremento. No es un evento, es el contenedor de todos los demás.
4. Sprint Review. Al final del Sprint, se muestra el incremento a stakeholders y se recibe feedback. Es una conversación, no una presentación.
5. Sprint Retrospective. El último evento del Sprint, antes del próximo Planning. El equipo inspecciona cómo trabajó, no qué construyó, y acuerda mejoras concretas.

Artefactos

Scrum tiene tres artefactos. El Product Backlog es la lista priorizada de todo lo que podría hacerse en el producto, propiedad del Product Owner. El Sprint Backlog es el subconjunto que el equipo se compromete a hacer en el Sprint actual. El Incremento es la suma de todos los elementos completados en el Sprint, sumados a los anteriores, que cumplen la Definition of Done (DoD): el conjunto de criterios que determinan cuándo algo se considera realmente terminado, no solo "funcionando en mi máquina".

6. Kanban

Si Scrum nació en la industria del software, Kanban nació en una fábrica. Toyota lo desarrolló en los 50 como parte de su sistema de producción (Toyota Production System) para visualizar el flujo de trabajo y limitar el inventario en curso. David Anderson lo adaptó al desarrollo de software a fines de los 2000, manteniendo sus principios centrales: visualizar el trabajo, limitar el trabajo en progreso y gestionar el flujo.

A diferencia de Scrum, Kanban no impone iteraciones de duración fija ni roles especiales. El equipo mantiene un tablero (físico o digital) con columnas que representan los estados del trabajo —típicamente "por hacer", "en progreso", "en revisión", "hecho"— y mueve las tareas de izquierda a derecha. La regla central es el WIP limit (work in progress): cada columna tiene un máximo de tareas que puede contener. Si la columna está llena, no se puede empezar nada nuevo hasta que algo termine. Suena trivial pero es profundamente transformador: obliga al equipo a terminar antes que empezar, lo que reduce drásticamente el tiempo de ciclo y expone los cuellos de botella.

Scrum y Kanban no son alternativas excluyentes. Muchos equipos usan Kanban dentro de un Sprint de Scrum (a veces se le llama "Scrumban"), o Scrum para producto y Kanban para soporte y operaciones. La elección suele depender del tipo de trabajo: cuando el trabajo es predecible y se puede planificar en bloques, Scrum funciona bien; cuando llega de forma continua e impredecible —incidentes, bugs, pedidos de stakeholders— Kanban es más natural.

Scrum vs Kanban

Scrum

• Cadencia fija (Sprints), buena para trabajo planificable.
• Roles y ceremonias definidas: framework prescriptivo.
• Rígido frente a interrupciones no planificadas.
• Curva de adopción mayor: hay que aprender el framework.

Kanban

• Flujo continuo, ideal para soporte y trabajo reactivo.
• Curva plana: tres reglas (visualizar, limitar WIP, gestionar flujo).
• Sin ritmo natural: requiere disciplina para no postergar entregas.
• Menos estructura para coordinar equipos grandes.

7. Más allá de Scrum y Kanban

El ecosistema ágil tiene más actores que vale conocer aunque sea superficialmente. Extreme Programming (XP), creado por Kent Beck a fines de los 90, se enfoca en prácticas técnicas concretas —programación en pares, desarrollo guiado por pruebas (TDD), integración continua, refactoring constante— y es históricamente la fuente de muchas de las prácticas de ingeniería que hoy damos por sentadas. Mientras Scrum se ocupa del proceso, XP se ocupa de cómo escribir el código.

Lean Software Development, popularizado por Mary y Tom Poppendieck, traduce los principios del Lean manufacturing al software: eliminar desperdicio, amplificar el aprendizaje, decidir lo más tarde posible, entregar lo más rápido posible, empoderar al equipo, construir integridad, ver el todo. Es menos un framework y más una filosofía transversal.

SAFe (Scaled Agile Framework) intenta escalar el agilismo a organizaciones grandes con muchos equipos. Es controvertido: sus detractores argumentan que reintroduce la jerarquía y la documentación pesada que el Manifiesto rechazaba, vestidas con vocabulario ágil. Si te cruzás con él en un trabajo, vale la pena leerlo con espíritu crítico antes de comprarlo entero.

8. Cascada frente a Ágil

Después de recorrer ambos mundos vale resumir el contraste central. Ninguno es universalmente mejor: cada uno encaja en contextos distintos. Lo que pasó en la práctica es que los contextos donde encaja la cascada se redujeron a un puñado de nichos, mientras que los contextos donde encaja el agilismo crecieron hasta cubrir prácticamente todo el desarrollo web, móvil y cloud-native.

9. Ágil y la nube: por qué se necesitan mutuamente

La adopción masiva del agilismo durante los 2000 y la adopción masiva de la nube durante los 2010 no son eventos independientes: cada uno alimentó al otro. El agilismo prometió entregas frecuentes; sin nube, "frecuente" significaba cada pocos meses, limitado por los tiempos de aprovisionamiento de hardware en data centers propios. Con nube, esos tiempos se redujeron a minutos, lo que permitió cumplir la promesa original: entregar software funcionando "frecuentemente, de un par de semanas a un par de meses, con preferencia por la escala más corta", como dice el segundo principio del Manifiesto.

A su vez, la nube necesita del agilismo para no desperdiciar su potencial. Una arquitectura de microservicios elásticos operada por un equipo que despliega una vez por trimestre es un mal uso de la infraestructura: paga la complejidad de los microservicios sin cobrar el beneficio de la independencia de despliegue. La cultura de DevOps —que en su núcleo es la fusión de desarrollo y operaciones en equipos autónomos, con automatización fuerte de la cadena de despliegue— es el puente entre ambas realidades: arquitectura cloud-native + proceso ágil + automatización operacional.

Las prácticas concretas que hicieron esto posible son hoy estándar de la industria: integración continua (CI), donde cada cambio se integra al tronco principal varias veces al día y se valida automáticamente; despliegue continuo (CD), donde cada cambio que pasa CI se despliega automáticamente a producción; infraestructura como código (IaC), donde la infraestructura se define en archivos versionados como cualquier otro código; y observabilidad, donde se mide el comportamiento del sistema en producción y los datos retroalimentan las próximas iteraciones. La trazabilidad de esas decisiones suele apoyarse en diagram as code (Mermaid, PlantUML, D2), para que los diagramas que documentan la arquitectura cambien junto con el código que documentan en lugar de quedar congelados en un PNG colgado en algún wiki. Cada una de estas prácticas, por separado, era difícil antes de la nube; con nube, son lo normal.

10. Errores comunes

El agilismo es probablemente el conjunto de ideas más malentendido de la industria del software. Estos son los tres errores que se repiten en proyectos reales con mayor consistencia, y los que más vale anticipar.

11. Buenas prácticas

12. Glosario rápido

13. Para profundizar

14. Cierre

Esta unidad cierra el bloque fundamental del curso. Empezamos con qué es la nube como modelo económico, bajamos a las dos capas técnicas que la sostienen, subimos a los principios que moldean la arquitectura, y terminamos con el proceso humano que produce el software que corre sobre todo eso. Las cuatro unidades no son temas independientes sino capas de un mismo edificio: ninguna funciona sin las demás.

Lo que sigue es el bloque aplicado: la Unidad 5 entra al gran consumidor actual de esa infraestructura —la IA generativa— y la Unidad 6 muestra cómo se combinan todas las piezas vistas para armar un producto real, como puente directo al challenge final.

Conceptos básicos de IA

Esta unidad sale del territorio estricto de infraestructura para mirar de cerca al gran consumidor actual de esa infraestructura: la inteligencia artificial generativa. Vamos a ordenar el vocabulario que circula desordenado en cualquier conversación sobre IA, bajar al detalle técnico de cómo funcionan los modelos grandes de lenguaje, repasar a los tres laboratorios que dominan el mercado occidental y terminar con los modelos de negocio que están naciendo alrededor de todo esto. La motivación, además, es práctica: hoy una parte enorme del cómputo en la nube se va a entrenar e inferir modelos de IA, y entender el vocabulario es la mitad del trabajo para entender la economía.

1. La pirámide conceptual

En la conversación pública los términos inteligencia artificial, machine learning, deep learning y LLM suelen usarse como sinónimos, pero describen niveles distintos de una misma jerarquía. La forma más limpia de ordenarlos es como círculos concéntricos: el de afuera contiene a todos los demás, y cada uno hacia adentro es un subconjunto más específico del anterior. Tenerlos separados ayuda a discutir con precisión: no toda IA es machine learning, no todo ML es deep learning, y no todo deep learning produce un LLM.

En el círculo más amplio está la Inteligencia Artificial (IA): todo el campo que estudia cómo construir sistemas que realicen tareas asociadas a la inteligencia humana, ya sea razonar, percibir o decidir. Un motor de ajedrez basado en reglas y un asistente conversacional moderno son ambos IA, pero técnicamente tienen muy poco en común. Adentro de IA aparece el Machine Learning (ML), que es el subconjunto donde el sistema aprende patrones a partir de datos en lugar de seguir reglas escritas a mano. Adentro de ML está el Deep Learning (DL), que es el ML basado en redes neuronales con muchas capas —de ahí lo de "profundo"—. Y dentro del DL aparece la familia de los modelos generativos, una aplicación específica del DL enfocada en producir contenido nuevo: texto, imágenes, audio, código. Los LLMs (large language models) son la variante de modelos generativos especializada en texto.

Concepto clave

IA > ML > DL > LLMs: una jerarquía de subconjuntos, no de sinónimos.

Analogía didáctica

La IA es como la medicina; el ML es como la cardiología; el deep learning es una técnica quirúrgica específica; los LLMs son una operación particular que aprendiste a hacer. Permite mostrar que un médico no es necesariamente cardiólogo, y un cardiólogo no necesariamente opera.

Cómo se relacionan los niveles

IACampo amplio, incluye sistemas basados en reglas y en aprendizaje.

MLSubconjunto de IA donde el sistema aprende patrones de datos.

DLSubconjunto del ML basado en redes neuronales con muchas capas.

LLMsAplicación del DL para generar texto nuevo a partir de un prompt.

Para tener en cuenta

• Confundir los niveles lleva a discusiones torcidas: "¿esto es IA?" suele ser una pregunta mal planteada; mejor preguntar a qué nivel pertenece.
• Existen sistemas de IA que no son ML (motores de reglas) y sistemas de ML que no son DL (regresión lineal, árboles de decisión).

2. Tipos de aprendizaje

Dentro del machine learning hay varias maneras de que un modelo aprenda, y cada una se elige según qué tipo de datos tenemos y qué problema queremos resolver. La división clásica reconoce cuatro grandes familias: aprendizaje supervisado, no supervisado, por refuerzo y, más recientemente, auto-supervisado. Esta última categoría es relativamente nueva en el discurso público y es, sin embargo, la que sostiene a los LLMs modernos.

En el aprendizaje supervisado entrenamos al modelo con pares input → output conocidos. Un clasificador de spam recibe miles de mails ya etiquetados como "spam" o "no spam" y aprende a generalizar. Lo mismo ocurre con un clasificador de imágenes médicas que aprende a separar tumores malignos de benignos a partir de un conjunto de imágenes etiquetadas por médicos. El costo principal acá es el etiquetado: necesita personas (o procesos) que digan cuál es la respuesta correcta para cada ejemplo.

En el aprendizaje no supervisado el modelo encuentra estructura en datos sin etiquetas. Lo típico es la segmentación de clientes —agrupar usuarios por comportamiento similar sin decirle al modelo qué grupos esperar— y la detección de anomalías, donde el sistema aprende qué es "normal" y marca lo que se desvía. Es la herramienta natural cuando no sabemos a priori qué buscar.

El aprendizaje por refuerzo entrena al modelo a través de recompensas. El agente toma una acción, recibe una señal positiva o negativa, y ajusta su política. AlphaGo aprendió a jugar Go ganando y perdiendo partidas contra sí mismo; los robots de control aprenden a caminar cayéndose miles de veces. En los LLMs aparece bajo la sigla RLHF (reinforcement learning from human feedback), donde humanos puntúan respuestas del modelo y ese feedback se usa para refinarlo después del pre-entrenamiento.

Finalmente, el aprendizaje auto-supervisado es el truco central del pre-entrenamiento de los LLMs modernos: el modelo genera sus propias etiquetas a partir de los datos crudos. La tarea típica es "predecir la siguiente palabra de un texto dado el contexto anterior". Internet entera es el conjunto de entrenamiento, y la etiqueta de cada fragmento es, literalmente, la palabra que aparece a continuación. No requiere etiquetadores humanos, lo que permite escalar a billones de palabras de manera viable.

3. Conceptos clave para entender LLMs

Si vas a leer documentación, papers o pricing pages de modelos de lenguaje, hay un puñado de términos que aparecen una y otra vez. Vale dedicarles dos párrafos a cada uno: con esos siete u ocho conceptos ya podés conversar técnicamente sobre cualquier LLM moderno y entender por qué cuesta lo que cuesta.

Un token es la unidad mínima que procesa el modelo. No es exactamente una palabra: puede ser una sílaba, un signo de puntuación o una secuencia de caracteres frecuente. Como regla práctica, 1.000 tokens equivalen aproximadamente a 750 palabras en inglés; en español la proporción es algo peor por la riqueza morfológica del idioma, alrededor de 600 palabras por 1.000 tokens. Todo se factura en tokens —entrada y salida— y todos los límites del modelo se expresan en tokens, así que conviene tener la noción internalizada.

Los parámetros son los pesos numéricos que componen la red neuronal. Más parámetros generalmente implican más capacidad pero también más costo de entrenamiento e inferencia. Los modelos frontera actuales tienen cientos de miles de millones (e incluso billones) de parámetros; cada uno es un número flotante, así que el solo hecho de cargar uno de estos modelos en memoria requiere terabytes de RAM repartidos en clústeres de GPUs o TPUs.

La ventana de contexto (context window) es la cantidad máxima de tokens que el modelo puede "ver" simultáneamente: incluye el prompt del usuario, las instrucciones del sistema, el historial de la conversación y la respuesta que está generando. Hoy los modelos top manejan entre 200.000 y 2.000.000 de tokens, lo que permite poner libros enteros o repositorios completos como contexto antes de hacer una pregunta.

Una distinción central a la hora de pensar costos es la de inferencia versus entrenamiento. Entrenar un modelo frontera cuesta decenas o cientos de millones de dólares y consume meses de cómputo en clústeres dedicados. Ejecutarlo después —responder a un prompt, lo que se llama inferencia— cuesta fracciones de centavo por consulta. Esta asimetría es la clave para entender los modelos de negocio: quien entrena modelos juega un juego de capital intensivo de pocos jugadores; quien los consume vía API juega un juego de costo marginal bajísimo y volumen alto.

El fine-tuning es la práctica de re-entrenar un modelo base con datos específicos de una tarea o dominio. Si tu empresa tiene miles de tickets de soporte resueltos, podés afinar un modelo para que responda con el tono y la jerga propios; si tu dominio es legal, podés afinarlo sobre jurisprudencia. Es más caro que usar el modelo base como está, pero menos que entrenar desde cero.

Los embeddings son la representación numérica —en forma de vector de cientos o miles de dimensiones— de un texto, una imagen u otro dato. Su propiedad clave es que contenidos semánticamente similares producen vectores cercanos, lo que permite buscar "por significado" en lugar de "por palabra exacta". Son la base de los buscadores semánticos modernos y, como vamos a ver enseguida, de RAG.

4. RAG en profundidad

De todos los conceptos anteriores, RAG (Retrieval Augmented Generation) merece una sección propia porque es, lejos, la técnica más usada hoy para que los LLMs respondan con información específica que no estaba en su entrenamiento: documentación interna de una empresa, apuntes de clase, manuales técnicos, jurisprudencia, historia clínica. Es también el primer proyecto serio que cualquier estudiante puede armar en un fin de semana y entender de punta a punta.

Por qué existe RAG

Los LLMs tienen tres limitaciones inherentes que RAG ayuda a resolver. La primera es el conocimiento desactualizado: el modelo solo sabe lo que vio durante el entrenamiento; todo lo posterior a su knowledge cutoff es invisible. La segunda es la falta de información privada: no conoce los documentos internos de tu empresa, tus apuntes, ni nada que no esté en internet público. La tercera son las alucinaciones: cuando no sabe algo, los LLMs tienden a inventar respuestas plausibles antes que admitir ignorancia. RAG mitiga las tres porque le entrega al modelo el contexto relevante antes de pedirle que responda.

Cómo funciona, paso a paso

RAG tiene dos fases bien diferenciadas: una de indexación, que se hace una sola vez por cada documento, y otra de consulta, que se ejecuta cada vez que el usuario hace una pregunta. La fase de indexación es la inversión inicial; la fase de consulta es la que se ejecuta en tiempo real.

Concepto clave

RAG es como darle al modelo un examen a libro abierto.

El LLM es el estudiante —sabe razonar y escribir bien— y el sistema de recuperación es quien le pasa el libro abierto en la página correcta antes de cada pregunta. Sin RAG, el estudiante tiene que responder de memoria; con RAG, responde con la fuente delante.

Para tener en cuenta

• RAG no le enseña nada nuevo al modelo: solo le entrega información en el prompt. Si querés que el modelo "absorba" conocimiento, lo que buscás es fine-tuning, no RAG.
• La calidad del RAG depende más del retrieval que del LLM: con un LLM mediocre y buen retrieval podés tener respuestas excelentes; con un LLM top y mal retrieval, respuestas elegantes pero equivocadas.

Caso concreto: RAG sobre apuntes y bibliografía

Es un proyecto ideal para construir en un fin de semana y entender el pipeline completo. La idea: armar un asistente que responda preguntas sobre los PDFs de las materias, citando la página exacta de cada respuesta. Los materiales de entrada son los que cualquier estudiante tiene a mano: PDFs de la bibliografía obligatoria, apuntes propios y de compañeros en Word, Markdown o Google Docs, diapositivas de clase en PPTX, transcripciones de grabaciones si las hay, y exámenes y guías de ejercicios anteriores.

5. Los tres jugadores: ChatGPT, Gemini y Claude

Tres laboratorios dominan hoy el mercado occidental de modelos frontera, y conviene presentarlos en paralelo porque cada uno persigue una estrategia distinta. Las tres compañías compiten por los mismos benchmarks y, en apariencia, por los mismos clientes, pero el contexto institucional, las alianzas y los productos donde se diferencian son sorprendentemente distintos.

ChatGPT (OpenAI)

OpenAI fue fundada en 2015 con una estructura institucional poco común: una organización sin fines de lucro controla a una con fines de lucro "capeada" (capped-profit), donde los retornos a inversores tienen un techo definido. Sus modelos actuales son la familia GPT-5, con el flagship GPT-5.5 lanzado en abril de 2026, junto con variantes Mini y Nano para casos de menor complejidad. El diferenciador histórico de OpenAI es el first mover advantage: ChatGPT, lanzado en noviembre de 2022, fue el producto que masificó la IA generativa y todavía hoy es la referencia de mercado en cantidad de usuarios. Su alianza estratégica más importante es con Microsoft, que invirtió alrededor de 13 mil millones de dólares e integra los modelos en Azure, Copilot y Office. Los productos principales son ChatGPT para el consumidor final y la API de OpenAI para developers, complementados con Codex, Sora (video) y herramientas para agentes.

Gemini (Google / DeepMind)

Google DeepMind es la división de IA de Alphabet, formada por la fusión de Google Brain y DeepMind en 2023. Sus modelos actuales son Gemini 3 Pro y Gemini 3.1 Pro como flagships, junto con Flash y Flash-Lite para casos más simples y de menor costo. El diferenciador es la integración profunda con el ecosistema Google —Search, Workspace, Android, Chrome— y la mayor ventana de contexto del mercado (hasta 2 millones de tokens), apoyada en el acceso privilegiado a TPUs propios. Los productos principales son la app Gemini, las integraciones en Workspace (Docs, Gmail, Sheets) y Vertex AI para empresas. La ventaja estructural es triple: chips propios (TPUs), datos propios (Search, YouTube) y distribución propia (Android está en miles de millones de dispositivos).

Claude (Anthropic)

Anthropic fue fundada en 2021 por ex-empleados de OpenAI, los hermanos Dario y Daniela Amodei. Sus modelos actuales son Claude Opus 4.7 (lanzado en abril de 2026) como flagship, junto con Sonnet 4.6 y Haiku 4.5 para distintos balances entre capacidad y costo. El diferenciador es el foco fuerte en AI safety y en alineamiento usando una técnica propia llamada Constitutional AI; además, Claude se posicionó muy bien en tareas de programación, agentes de larga duración y trabajo profesional. Las alianzas incluyen inversiones de Amazon (~8 mil millones de dólares) y Google, lo que se traduce en disponibilidad tanto en AWS Bedrock como en Google Vertex AI. Los productos principales son Claude.ai para el consumidor, la API de Anthropic, Claude Code (CLI para desarrollo) y extensiones como Claude para Excel y Chrome.

Comparación lado a lado

Una tabla resumen ayuda a tener el panorama en una sola pantalla. Los números cambian rápido —cada laboratorio re-precia varias veces por año—, pero la forma del posicionamiento es razonablemente estable.

Precios y modelos referencia al 2026-04-01. Cambian varias veces por año: verificar en las páginas oficiales antes de citar.

6. Modelos de negocio en IA

Alrededor de estos modelos creció un ecosistema con varios patrones de monetización conviviendo al mismo tiempo. Conviene presentarlos como una taxonomía y discutir los trade-offs: cada modelo de negocio refleja una posición distinta en la cadena de valor, desde quien entrena los pesos hasta quien arma una experiencia de usuario sobre la API de un tercero. Para el listado de proveedores que exponen modelos vía API gestionada (Bedrock, Vertex AI, Azure OpenAI, Claude API, OpenAI, Gemini) y cuándo conviene cada uno, ver el recurso integración con IA.

Modelos directos (los grandes laboratorios)

El primer grupo son los modelos que aplican los laboratorios mismos sobre sus propios productos. El más visible es la API as a Service en formato pay-per-token: se cobra por consumo, con precios distintos para input y output (por ejemplo, GPT-5.5 a 5 dólares de input y 30 de output por millón de tokens). Es el modelo dominante de OpenAI, Anthropic y Google para developers. Para el consumidor existe la suscripción consumer: acceso "ilimitado" (con límites razonables) por una mensualidad fija, normalmente alrededor de USD 20 al mes; ahí entran ChatGPT Plus, Claude Pro y Google AI Pro. Para empresas grandes hay planes enterprise con seguridad, auditoría, mayores límites y SSO. Y atravesando todos los segmentos aparecen los tiered models: ofrecer el mismo producto con modelos de distintas capacidades a distintos precios —Pro, Pro+, Ultra—.

Modelos sobre infraestructura

El segundo grupo monetiza el cómputo necesario para entrenar e inferir. El cloud + IA bundling es la jugada de los hyperscalers: AWS Bedrock, Google Vertex AI y Azure AI Foundry venden los modelos como parte de su oferta cloud y capturan margen sobre el cómputo además del modelo en sí. El GPU as a Service es la jugada de empresas como CoreWeave, Lambda Labs o Crusoe, que alquilan capacidad de cómputo a startups que no pueden firmar contratos de largo plazo con NVIDIA. Y una jugada particular es la de open weights + servicios: Meta libera Llama gratis, pero se beneficia indirectamente de la adopción y de tener una IA optimizada para sus propios productos (Instagram, WhatsApp).

Modelos de producto sobre IA (la capa de aplicación)

El tercer grupo es donde nace la mayor cantidad de startups: productos cuyo core es IA pero que no entrenan modelos propios. AI-native SaaS agrupa a productos como Cursor (programación), Perplexity (búsqueda), Notion AI o Granola (notas de reuniones); suelen cobrar por usuario por mes con tiers según uso. Las AI features sobre SaaS existente son la jugada inversa: incumbents que agregan IA a productos consolidados como upsell —Salesforce Einstein, HubSpot AI, Atlassian Intelligence—. El outcome-based pricing es el modelo más emergente y polémico: se cobra por resultado, no por uso (agentes de soporte que cobran por ticket resuelto, por ejemplo); alinea incentivos pero es difícil de medir. Finalmente, los marketplaces y agregadores —OpenRouter, Replicate— agrupan modelos de distintos proveedores y capturan margen por ruteo, comparación y conveniencia.

Hasta acá vimos cómo se compone un sistema con IA generativa cuando el modelo se limita a responder: recibe prompt, devuelve texto. La próxima generación de productos da un paso más y construye agentes: LLMs equipados con herramientas (tools) que actúan en el mundo —leen archivos, consultan bases, llaman APIs, mandan mensajes—. La forma estándar de exponer esas herramientas se llama MCP (Model Context Protocol), publicado por Anthropic a fines de 2024. La Unidad 6 retoma este hilo con foco en cómo se construyen agentes IA en producción y cuándo conviene usar MCP frente a tool calling directo.

7. Errores comunes

El vocabulario de IA es nuevo y se presta a confusiones que vale anticipar. Estos son los dos errores que aparecen con más frecuencia cuando alguien empieza a integrar LLMs en un sistema real.

Calcular costos por usuario, no por token

Qué suele pasar

Se asume que "cada usuario nos cuesta X" cuando en realidad un usuario que abre una conversación larga con contexto de un millón de tokens cuesta diez veces más que uno que hace tres preguntas cortas. Los costos reales se descubren cuando llega la primera factura mensual de la API y triplica el estimado.

Por qué

El pricing es por token, no por usuario, y el output suele costar entre 3 y 6 veces más que el input. La variabilidad de uso entre usuarios es enorme y se concentra en una long tail que distorsiona el promedio.

Cómo evitarlo

Instrumentá desde el día uno tokens de input y output por usuario, por endpoint y por modelo. Aplicá prompt caching y elegí el modelo más chico que cumpla la tarea antes de optimizar precio del modelo grande.

8. Para profundizar

Aplicaciones concretas de la nube

En las cinco unidades anteriores recorrimos qué es la nube, cómo se virtualiza el cómputo, qué leyes rigen las arquitecturas distribuidas, qué metodologías permiten construir con ese material y, por último, cómo se integra la inteligencia artificial al mismo stack. Esta unidad cierra el arco mirando la pregunta práctica: ¿cómo se combinan todas esas piezas para construir un producto real? Vamos a recorrer el stack típico de una aplicación moderna, los servicios que casi cualquier producto necesita para hablar con sus usuarios y cobrarles, las plataformas que aceleran drásticamente el time-to-market y la forma de documentar lo que se va a construir. La motivación es directa: en pocos días vas a tener que diseñar e implementar tu propio prototipo, y este es el mapa que conecta los conceptos del curso con el catálogo de servicios disponibles.

1. De los conceptos al producto

Hay un salto incómodo entre saber qué es la computación en la nube y usar la nube para resolver un problema concreto. La teoría te da el vocabulario —IaaS, PaaS, SaaS, contenedores, regiones, eventual consistency— pero cuando te sentás frente a una idea de producto la pregunta es siempre la misma: ¿con qué piezas la armo?. Las decisiones se vuelven menos sobre conceptos y más sobre tradeoffs específicos: si elijo Stripe en vez de Mercado Pago pierdo cobertura local pero gano integración global; si uso Firebase me ahorro armar auth pero quedo atado a Google Cloud; si voy serverless pago por uso pero asumo cold starts.

La buena noticia es que casi todas las aplicaciones modernas se construyen combinando un puñado de servicios estándar. Hay un menú bastante estable de piezas —cómputo, base, storage, auth, canales de comunicación, pagos, integración con IA— y la mayoría del trabajo arquitectónico consiste en elegir una opción de cada categoría según el problema. Una vez que se internaliza ese menú, diseñar un nuevo producto se parece más a armar un lego conocido que a inventar algo desde cero. Esta unidad presenta el menú pieza por pieza.

2. El stack típico de una app moderna

Casi cualquier aplicación que se monta hoy comparte un esqueleto de servicios. No todos están siempre presentes, pero el patrón se repite con tanta frecuencia que conviene tenerlo memorizado como punto de partida. Cuando alguien describe una idea de producto —"un marketplace para artesanos", "un bot que reserva turnos", "un dashboard de ventas"— se puede recorrer mentalmente el esqueleto y ya empezar a anticipar qué piezas va a necesitar y dónde van a estar los puntos sensibles.

El esqueleto típico tiene siete capas y todas resuelven preguntas distintas. Dónde corre el código se resuelve con un VPS, un container en una plataforma gestionada, o funciones serverless según cuánto control y cuánta comodidad queramos. Dónde guardamos datos estructurados se resuelve con una base de datos gestionada. Dónde guardamos archivos se resuelve con object storage. Quién es el usuario se resuelve con un servicio de autenticación. Cómo le hablamos al usuario fuera de la app con email transaccional y/o mensajería. Cómo cobramos con una pasarela de pagos. Y cómo entregamos contenido cerca del usuario con un CDN. Después aparecen capas opcionales según el caso: cache para acelerar lecturas, colas para desacoplar trabajos pesados, integración con IA cuando el producto tiene un componente conversacional o de análisis automático.

Una forma útil de pensar el stack es como una línea de montaje donde cada servicio cumple un rol específico y las decisiones de arquitectura están en cómo se comunican entre sí. La línea típica es: el navegador del usuario habla con el CDN (que cachea los assets estáticos), el CDN reenvía al backend si hace falta lógica dinámica, el backend valida la sesión contra el servicio de auth, lee y escribe en la base de datos, sube archivos al object storage, encola tareas pesadas en una cola, dispara correos o mensajes para notificar al usuario y, si corresponde, cobra a través de la pasarela de pagos.

3. Identidad y cobro: los servicios al usuario

De todas las piezas del stack, dos suelen aparecer en cualquier producto que tenga usuarios humanos del otro lado: autenticación y, si hay monetización directa, pagos. Las dos son territorio resuelto por la industria hace tiempo y, sin embargo, las dos son lugares donde un equipo bien intencionado puede meterse en problemas serios si decide reinventar la rueda.

Autenticación

Manejar usuarios y sesiones parece simple: registro, login, recuperación de contraseña, sesión persistente. En la práctica es uno de los componentes con más superficie de ataque y más casos borde: hash correcto de contraseñas, verificación de email, MFA, login social con proveedores externos, manejo de tokens, expiración de sesiones, invalidación, sincronización entre dispositivos, recuperación cuando el usuario perdió el segundo factor. Hacer todo eso bien lleva meses; hacerlo medio bien suele terminar en una filtración de credenciales.

Por eso la recomendación práctica es delegar: usar un servicio de autenticación gestionado como Auth0, Clerk, AWS Cognito o Supabase Auth, o aprovechar la auth integrada de un BaaS como Firebase. El proveedor se encarga del flujo completo, expone un SDK para el frontend y emite tokens que tu backend valida. El tradeoff es lock-in: salir después de Auth0 implica re-migrar usuarios y reescribir el flujo.

Pagos

Cobrar online tiene la misma lógica: el cumplimiento PCI-DSS, la integración con tarjetas y bancos, la disputa de chargebacks y el manejo de fraude son tareas que llevan años de inversión y certificación. La decisión real al elegir una pasarela de pagos es entre opciones globales (Stripe, Square) que dan cobertura amplia y APIs limpias, y opciones locales (Mercado Pago, dLocal, Ualá Bis) que tienen mejor adopción en países específicos y soportan métodos como Rapipago, Pix o transferencias inmediatas. Para audiencia argentina típicamente conviene Mercado Pago; para vender a clientes globales, Stripe.

Guardar datos de tarjeta en tu propia base

Qué suele pasar

Para "ahorrar un paso" al usuario, alguien decide guardar el número de tarjeta o un token sensible en la base de datos del producto. A las semanas hay una auditoría, una filtración o simplemente una multa de tu adquirente.

Por qué

El estándar PCI-DSS regula con detalle qué se puede y qué no se puede almacenar; cumplirlo desde cero es carísimo. La pasarela existe para que vos nunca veas el dato sensible: solo manejás un token opaco emitido por el proveedor.

Cómo evitarlo

Usar las APIs de tokenización que vienen incluidas en cualquier pasarela. Lo único que guardás en tu base es el token devuelto por el proveedor; el dato sensible nunca toca tus servidores.

4. Hablarle al usuario sin que entre a tu app

Una vez que el usuario está registrado y eventualmente paga, el producto necesita comunicarse con él en momentos donde no está usando activamente la aplicación: confirmar un signup, mandar un recibo, recordarle un turno, avisarle que su pedido salió. Hay tres canales principales y cada uno tiene su lógica propia: correo electrónico, mensajería instantánea (típicamente WhatsApp o Telegram en Latam) y notificaciones push dentro de la app.

El correo transaccional se delega a un servicio de mailing como Postmark, Resend o SendGrid. Estos proveedores se ocupan de la entregabilidad —reputación de IP, autenticación SPF/DKIM/DMARC, manejo de bounces y complaints—, cosas que mandando mails desde tu propio SMTP no escalan más allá de unos cientos por día. El correo es el canal por defecto para comunicación no urgente: bienvenidas, recuperación de password, notificaciones, recibos, resúmenes periódicos.

La mensajería en cambio se reserva para comunicación urgente o conversacional. WhatsApp tiene tasas de apertura cercanas al 90% y permite bots interactivos; el costo por mensaje es órdenes de magnitud más alto que el mail. Twilio, MessageBird, 360dialog son los proveedores típicos para WhatsApp Business; Telegram ofrece su Bot API gratis y es ideal para prototipos. SMS sigue vivo donde hace falta llegar a usuarios sin smartphone o donde la verificación por número de teléfono es obligatoria.

Tip

Empezá siempre por mail transaccional. Es 10 a 50 veces más barato que WhatsApp por mensaje, no requiere alta como Business Account y cubre la mayoría de los casos. Sumá WhatsApp cuando tengas evidencia de que la audiencia no lee el correo o cuando la conversación bidireccional sea parte central del producto (un bot de turnos, una atención al cliente).

5. Datos más allá de la base relacional

En la Unidad 3 vimos que el dato típico de una aplicación vive en una base de datos relacional o documental: filas, columnas, índices, consistencia gestionada por el motor. Pero en cualquier producto real aparecen dos tipos de datos que no encajan en una base y que necesitan su propia infraestructura: archivos y datos externos que no son nuestros.

Object storage para archivos

Cualquier app con uploads necesita un lugar para archivos: avatares, documentos, PDFs subidos por el usuario, fotos de evidencia, videos grabados. Guardar archivos en la base relacional es un error clásico (infla las tablas, complica los backups, encarece las queries). El patrón correcto es separar: el archivo binario va a un servicio de object storage como S3, Cloud Storage, R2 o un Supabase Storage; la base de datos guarda solamente la referencia (path, URL, key) junto con los metadatos del archivo (tamaño, tipo, fecha, dueño).

Object storage tiene además una propiedad útil para servir contenido público: cada bucket puede exponerse detrás de un CDN, de manera que las imágenes se sirven desde el nodo más cercano al usuario sin tocar tu backend. El flujo típico para un upload es: el frontend pide una URL firmada al backend, sube directamente al bucket usando esa URL, y avisa al backend con la key del archivo subido. El backend nunca recibe el binario completo, solo el metadato.

Scraping para datos externos

Hay productos cuyo valor depende de información que vive en sitios web ajenos sin API: precios de la competencia, listados de eventos culturales, publicaciones inmobiliarias, contenido público para armar un buscador o para alimentar un RAG. Cuando no hay feed oficial, la alternativa es scraping: navegar y parsear el HTML como lo haría un usuario humano, pero programáticamente.

El stack típico de scraping va de menor a mayor complejidad: una librería como BeautifulSoup o Scrapy para sitios estáticos, un browser headless como Playwright o Puppeteer para sitios que renderizan con JavaScript, y un servicio gestionado como Bright Data o ScrapingBee cuando hace falta rotar proxies o resolver CAPTCHAs a escala. La complejidad real no suele ser técnica sino legal y operativa: cumplir términos de uso del sitio fuente, mantener el scraper cuando el HTML cambia, evitar bans por volumen.

6. Acelerar con plataformas todo-en-uno

Hasta acá presentamos cada pieza del stack por separado. Esa aproximación —elegir un servicio por categoría— da el máximo control y la mejor portabilidad, pero también pide más tiempo de integración: cada componente tiene su SDK, sus credenciales, su lógica de autenticación, su modelo de costos. Para muchos productos —sobre todo MVPs, prototipos y herramientas internas— el tiempo importa más que el control. Para esos casos existen plataformas que integran varias piezas en un mismo proveedor: BaaS y low-code.

BaaS: el backend como producto

Una plataforma de Backend as a Service como Firebase, Supabase o Convex te entrega en un único SDK auth, base de datos (con sync en tiempo real, en muchos casos), object storage, funciones serverless, hosting estático y notificaciones push. El cliente —web, iOS, Android— habla directamente con los servicios usando el SDK; del lado del producto solo modelás el dominio y la UI. Una app que armada pieza por pieza llevaría dos semanas suele estar funcionando en un día con BaaS.

El tradeoff es lock-in. Salir de Firestore o Convex después suele ser reescribir, no migrar: las queries, el modelo de datos y los patrones de sincronía son muy específicos. Supabase mitiga esto porque por abajo es PostgreSQL estándar, lo que facilita salirse eventualmente; Firebase está más fuertemente atado a Google Cloud. El otro tradeoff es el costo a escala: el pricing por reads/writes/egress se acumula rápido si el producto crece.

Low-code: ni siquiera escribir el SDK

Las plataformas low-code y no-code —Bubble, Webflow, Retool, FlutterFlow, las más recientes Lovable y v0— llevan la lógica un paso más allá: en vez de escribir código contra un SDK, armás la aplicación arrastrando componentes en una interfaz visual o describiéndola en lenguaje natural. Para casos como herramientas internas (un CRM simple, un panel de admin), MVPs para validar una idea o automatizaciones entre SaaS, es la opción más rápida. Para productos con lógica compleja, performance crítica o requisitos de portabilidad, no es viable.

7. Agentes IA en producción

La Unidad 5 introdujo los LLMs y RAG: el modelo recibe un prompt, eventualmente acompañado de contexto recuperado de una base vectorial, y devuelve texto. Ese patrón cubre buena parte de los productos con IA actuales (chatbots, asistentes de búsqueda, generadores de contenido). Pero hay una segunda generación de productos donde el LLM no solo responde: actúa. Lee archivos, consulta bases de datos, llama APIs, edita código, manda mails, agenda reuniones. Es lo que se conoce como agentes: un LLM más una caja de herramientas (tools) que puede invocar a voluntad para resolver una tarea.

Construir un agente requiere dos cosas además del modelo: exponer las tools (funciones que el modelo puede llamar, cada una con su schema de input/output) y manejar el bucle de razonamiento (el modelo decide qué tool llamar, recibe el resultado, decide si necesita otra, hasta que considera resuelta la tarea). Cada proveedor de LLM tiene su API de tool calling: OpenAI lo llama function calling, Anthropic lo llama tool use. Funcionan parecido y se programan a mano para cada agente.

MCP: el protocolo estándar para tools

El problema con armar tools a mano es que cada agente queda atado a las suyas y no son reutilizables. Si un equipo expone un acceso a su base de datos como tool para su agente propio, y otro equipo quiere darle al suyo el mismo acceso, tiene que reimplementar la integración. MCP (Model Context Protocol), publicado por Anthropic a fines de 2024, resuelve eso: estandariza cómo un cliente (Claude Code, Claude Desktop, Cursor, Windsurf, Zed) descubre y llama tools expuestas por un server MCP. Cualquier cliente compatible puede usar cualquier server compatible.

En la práctica, MCP permite "agentizar" un LLM con tools propias sin escribir glue code para cada cliente. Hay servers oficiales listos para filesystem, GitHub, Slack, Postgres, Google Drive, Sentry y otros; cualquier equipo puede escribir uno propio para su dominio. Para un prototipo del challenge, MCP es interesante cuando el producto es un asistente que necesita actuar sobre los datos del docente, del alumno o de la institución: leer submissions, consultar calificaciones, redactar devoluciones.

Concepto clave

Un chatbot responde; un agente actúa. La diferencia es tener tools.

El primer paso al diseñar un producto con IA es preguntarse si alcanza con un LLM puro (toma prompt, devuelve texto) o si el modelo necesita ejecutar acciones en el mundo. Si la respuesta es la segunda, vas a estar construyendo un agente, y vas a necesitar pensar el set de tools que le exponés.

Para tener en cuenta

• Los agentes amplifican errores: si una tool ejecuta una acción destructiva, el modelo puede invocarla incorrectamente. Diseñar el set de tools incluye decidir cuáles requieren confirmación humana.
• MCP es la opción estándar cuando ya tenés varios clientes o querés que terceros extiendan tu app; para un agente único con dos tools, el tool calling nativo del proveedor alcanza.

8. Documentar lo que vas a armar

La última pieza del puente entre concepto y producto no es técnica sino documental. Antes de tirar el primer container, conviene haber escrito dos documentos cortos que después facilitan la construcción y el mantenimiento: el PRD (Product Requirements Document) y el ADR (Architectural Decision Record). Los dos son centrales para la entrega del challenge final del curso.

PRD: qué vamos a construir

El PRD define el producto antes de pensar en cómo construirlo: qué problema resuelve, para qué usuario, con qué alcance, con qué criterio de éxito. No es un documento largo —una a tres páginas bien escritas alcanzan— pero es el filtro que evita construir cosas que nadie necesita. Atlassian tiene una guía canónica para escribir PRDs que es la referencia incluida en la pestaña Bibliografía de este curso.

ADR: por qué construimos así

El ADR registra las decisiones arquitectónicas importantes: para cada elección de stack (qué base de datos, qué auth, qué cómputo, qué pasarela de pagos), por qué la elegimos, qué alternativas evaluamos y qué tradeoffs aceptamos. Su valor real aparece seis meses después, cuando alguien (vos mismo, otro desarrollador) abre el proyecto y necesita entender por qué el sistema es como es. AWS publica una prescriptive guidance sobre ADRs que también está en la pestaña Bibliografía.

Diagram as code: el diagrama que no se desactualiza

Un ADR sin diagrama es difícil de leer; un diagrama subido como PNG a Confluence es difícil de mantener. La solución es diagram as code: lenguajes textuales como Mermaid, PlantUML o D2 que se renderizan automáticamente y viven en el repo junto al código. Mermaid en particular tiene la ventaja de que GitHub lo renderiza directo en cualquier archivo Markdown, así que un diagrama de arquitectura metido en el README se ve sin ningún paso adicional. Para el ADR del challenge, un diagrama Mermaid bien hecho vale por varios párrafos de prosa.

9. Caso integrador: bot de WhatsApp para turnos

Para terminar de bajar a tierra todo lo anterior, repasemos un caso completo a nivel de diseño. El producto es un bot de WhatsApp que permite a un consultorio médico recibir y gestionar turnos sin que la secretaria atienda teléfono. El paciente conversa con el bot en lenguaje natural ("hola, quiero un turno con la doctora para la semana que viene a la tarde"), el bot interpreta la intención, propone horarios disponibles, registra la reserva y manda un recordatorio por mail el día previo. Es un caso simple pero combina cinco piezas distintas del catálogo y obliga a tomar decisiones reales.

Las piezas elegidas y por qué

Canal de entrada: messaging (Twilio para WhatsApp Business). Twilio porque tiene buena documentación, proceso de alta razonablemente rápido y SDK en todos los lenguajes. Alternativa descartada: 360dialog (más barato a escala pero proceso de alta más lento).

Interpretación del lenguaje: AI integration (Claude Haiku). Haiku porque es más que suficiente para extraer intención y entidades de un mensaje corto, y cuesta una fracción de Sonnet u Opus. Alternativa descartada: GPT-5 Mini (similar precio pero el equipo ya tiene experiencia con la API de Anthropic).

Persistencia: database gestionada (Supabase Postgres). Supabase porque viene con Postgres real, dashboard incluido y nivel gratis suficiente para el prototipo. Alternativa descartada: Firestore (más rápido para empezar pero peor para queries por fecha y disponibilidad).

Recordatorios: mailing transaccional (Resend). Resend porque la API es simple, el nivel gratis cubre los 3.000 mails mensuales esperados y la integración desde Node es de cinco líneas. Alternativa descartada: mandar el recordatorio por WhatsApp (más caro por mensaje y, para un simple recordatorio diario, no aporta).

Cómputo: serverless (Vercel Functions). Vercel porque hostea también el panel web de administración del consultorio (que es Next.js), así que un solo deploy cubre web + webhooks de WhatsApp. Alternativa descartada: un contenedor en Fly.io (más control pero más overhead para algo que recibe pocos eventos al día).

El flujo, en un diagrama

El siguiente es el diagrama Mermaid que iría dentro del ADR. En GitHub se renderiza automáticamente; en otras plataformas se puede incluir el SVG generado.

sequenceDiagram
    participant U as Paciente (WhatsApp)
    participant T as Twilio
    participant F as Vercel Function
    participant C as Claude Haiku
    participant DB as Supabase
    participant R as Resend (día previo)

    U->>T: "quiero turno la semana que viene a la tarde"
    T->>F: webhook con el mensaje
    F->>C: extraer intención + fecha/hora
    C-->>F: { intent: "reservar", preferencia: "tarde, próxima semana" }
    F->>DB: consultar disponibilidad
    DB-->>F: horarios libres
    F->>T: enviar opciones al paciente
    T->>U: "tengo martes 16hs o jueves 18hs"
    U->>T: "martes"
    T->>F: webhook con confirmación
    F->>DB: crear turno
    F->>T: confirmar al paciente
    Note over R,U: 24h antes del turno
    R->>U: recordatorio por mail

Lo que faltaría discutir en el ADR completo

Este es solo el esqueleto del walk-through. Un ADR real para este producto tendría que cubrir también: cómo se autentican las requests de Twilio para que nadie pueda simular un mensaje, cómo se manejan los conflictos cuando dos pacientes piden el mismo horario al mismo tiempo, qué pasa si Claude devuelve una interpretación errónea, qué se hace si el paciente quiere cancelar, dónde se loguean los mensajes para auditoría futura. Cada una de esas preguntas es una decisión arquitectónica que merece quedar registrada.

Tu propio dominio: registrarlo en nic.ar y apuntarlo a DigitalOcean

Llegado el challenge, tu prototipo va a vivir en algún lado: un Droplet de DigitalOcean, una función serverless, una plataforma de hosting. Pero ese "algún lado" tiene una dirección IP cruda —algo como 164.92.130.45— que nadie va a tipear ni recordar. Esta unidad es un apéndice práctico que cierra el último kilómetro: cómo sacar un dominio propio en nic.ar (el registro de los dominios .ar) y cómo delegar su DNS a DigitalOcean para que tuproyecto.com.ar apunte a tu servidor. Es el paso que convierte un experimento de clase en algo que podés mandar por WhatsApp y que se ve profesional.

1. De la IP al nombre: qué resuelve el DNS

Toda máquina en internet se identifica por una dirección IP. Las personas, en cambio, recordamos nombres. El DNS (Domain Name System) es la capa que traduce un nombre legible —google.com, tuproyecto.com.ar— a la IP donde realmente vive el servicio. Es, en esencia, la guía telefónica de internet: vos pedís un nombre y el sistema te devuelve el número al que hay que llamar. Cada vez que el navegador abre una URL, lo primero que hace —antes de pedir una sola línea de HTML— es preguntarle al DNS "¿a qué IP corresponde este nombre?".

Esa traducción no la hace un único servidor mágico, sino una cadena de delegación jerárquica. Hay servidores raíz que saben quién maneja cada extensión (.com, .ar), servidores de cada extensión que saben quién maneja cada dominio puntual, y finalmente los servidores autoritativos de tu dominio, que son los que realmente contienen las respuestas: "el nombre www.tuproyecto.com.ar está en la IP tal". Sacar un dominio y configurarlo es, en el fondo, decidir quién va a ser autoritativo por tu nombre y qué respuestas va a dar.

DNS Domain Name System

El sistema distribuido que traduce nombres de dominio legibles a las direcciones IP donde corren los servicios.

Metáfora

Es la agenda de contactos del planeta: vos guardás "Mamá" y el teléfono sabe a qué número marcar. Si cambiás de servidor (de número), actualizás la agenda y todo el mundo sigue llamando al mismo nombre.

Las tres piezas que vas a tocar

Quién vende el nombre Registrante / Registro (nic.ar) Quién responde por él Nameservers (DigitalOcean) Qué responde Registros (A, CNAME...)

2. Anatomía de un dominio .ar y el rol de nic.ar

Un dominio se lee de derecha a izquierda, de lo más general a lo más específico. En www.tuproyecto.com.ar: .ar es el TLD (dominio de nivel superior de país, Argentina), .com.ar es la zona comercial dentro de ese país, tuproyecto es el nombre que vos elegís y registrás, y www es un subdominio que vos definís libremente una vez que sos dueño del nombre. Lo que comprás en nic.ar es la parte tuproyecto.com.ar; todo lo que cuelga a la izquierda (www, api, blog) lo creás vos sin pagar nada más.

nic.ar es el registro oficial de los dominios bajo .ar, operado por el Estado argentino. Es el único lugar donde se registra un .ar: no hay revendedores como sí los hay para .com. La zona más común es .com.ar (uso general/comercial, la opción por defecto) y se registra sin más requisito que estar dado de alta en el sistema; otras como .gob.ar, .edu.ar o .org.ar exigen acreditar que sos esa clase de entidad. Desde 2014 el registro es pago (una tarifa anual baja, del orden de unos pocos miles de pesos según la zona) y se renueva todos los años: si no pagás, el dominio se libera.

3. Registrar el dominio en nic.ar

El alta es íntegramente online y se hace con tu identidad fiscal: nic.ar usa autenticación del Estado, así que entrás con tu cuenta de Mi Argentina o con Clave Fiscal de AFIP. No hace falta más que eso y un medio de pago. El flujo es corto y rara vez cambia en lo esencial, aunque la interfaz exacta del sitio puede variar con el tiempo.

Sacar un dominio en nic.ar

1. Entrá a nic.ar e ingresá con Mi Argentina o Clave Fiscal de AFIP. La primera vez te crea automáticamente el "usuario" del registro asociado a tu identidad.
2. Buscá el nombre que querés (ej. tuproyecto) y elegí la zona (.com.ar para el caso general). El sistema te dice si está disponible.
3. Agregalo y pagá la tarifa anual. Recién cuando el pago se acredita el dominio queda registrado a tu nombre.
4. Entrá a la administración del dominio ya registrado: ahí vas a ver la sección de servidores DNS (o "delegación"). Por defecto suele venir con los DNS del propio nic.ar.
5. Anotá que más adelante (paso del punto 5) vas a reemplazar esos nameservers por los de DigitalOcean. Por ahora, dominio comprado: listo.

4. ¿Quién resuelve tu DNS? nic.ar vs DigitalOcean

Una vez registrado, el dominio necesita un juego de nameservers que respondan por él. Tenés dos caminos. Podés usar el DNS que provee nic.ar y cargar los registros directamente en su panel; o podés delegar los nameservers a un proveedor externo —en nuestro caso DigitalOcean— y manejar toda la zona desde ahí. Para un proyecto que ya vive en DigitalOcean, delegar el DNS al mismo proveedor es lo más cómodo: tenés Droplet, registros y, si sumás un balanceador o un certificado, todo en un solo panel.

5. Apuntar el dominio a DigitalOcean

Acá está el corazón de la unidad y el paso que más confunde la primera vez. La idea es de dos lados: primero le decís a DigitalOcean "voy a manejar este dominio acá" (y DO te entrega sus nameservers), y después volvés a nic.ar y le decís "delegá este dominio a estos nameservers". Recién cuando nic.ar publica esa delegación, el mundo empieza a preguntarle a DigitalOcean por tu nombre.

6. Crear los registros DNS en DigitalOcean

Con la delegación hecha, DigitalOcean es autoritativo por tu dominio y ahora sí cargás los registros que dicen a qué IP va cada nombre. Los que vas a usar casi siempre son pocos. Un registro A apunta un nombre a una IPv4 (tu Droplet); un AAAA hace lo mismo para IPv6; un CNAME es un alias que apunta un nombre a otro nombre; un MX dice qué servidor recibe el correo del dominio; y un TXT guarda texto libre, típico para verificaciones de propiedad y registros de email (SPF, DKIM).

Para una app web típica alcanza con dos registros. Un registro A en el apex del dominio (el nombre "pelado", tuproyecto.com.ar, que en los paneles se escribe como @) apuntando a la IP del Droplet, y un CNAME para www que apunte al apex, de manera que www.tuproyecto.com.ar y tuproyecto.com.ar lleven al mismo lugar. Si asociaste el dominio a un Droplet al crearlo, DigitalOcean ya te dejó algo parecido armado.

# A record en el apex (@) → IP del Droplet
doctl compute domain records create tuproyecto.com.ar \
  --record-type A --record-name @ \
  --record-data 164.92.130.45 --record-ttl 3600

# www como alias del apex
doctl compute domain records create tuproyecto.com.ar \
  --record-type CNAME --record-name www \
  --record-data @ --record-ttl 3600

Poner un CNAME en el apex del dominio

Qué suele pasar

Se intenta apuntar tuproyecto.com.ar (el apex) con un CNAME hacia otro nombre —por ejemplo el host de un servicio de hosting— y el dominio queda roto, sin resolver el correo o devolviendo errores intermitentes.

Por qué

El estándar DNS no permite un CNAME en el apex conviviendo con otros registros obligatorios (como NS y SOA, que siempre viven ahí). El CNAME, por definición, dice "para este nombre, mirá ese otro y nada más", y eso choca con esos registros.

Cómo evitarlo

En el apex usá siempre un registro A (o AAAA) con la IP directa. Dejá los CNAME para subdominios como www. Si necesitás apuntar el apex a un nombre, DigitalOcean no lo soporta de forma nativa: poné la IP.

7. Verificar que todo quedó bien

Antes de declarar victoria, conviene chequear dos cosas por separado, en el mismo orden en que las configuraste: primero que la delegación haya propagado (que el mundo le pregunte a DigitalOcean por tu dominio), y después que los registros respondan la IP correcta. Las herramientas dig y nslookup hacen exactamente las consultas que hace un navegador, pero te muestran la respuesta cruda.

# ¿Qué nameservers responden por el dominio? Deberían ser los de DigitalOcean
dig NS tuproyecto.com.ar +short
# → ns1.digitalocean.com.
#   ns2.digitalocean.com.
#   ns3.digitalocean.com.

# ¿A qué IP resuelve el dominio? Debería ser la del Droplet
dig tuproyecto.com.ar +short
# → 164.92.130.45

# Preguntando directo al nameserver de DO, sin esperar caches intermedios
dig @ns1.digitalocean.com tuproyecto.com.ar +short

Tip

Con el dominio resolviendo a tu Droplet, el último paso para que se vea profesional es el HTTPS. Un certificado gratuito de Let's Encrypt (vía Certbot en el Droplet, o el balanceador gestionado de DigitalOcean) se emite en minutos y valida la propiedad justamente a través del DNS que recién configuraste. Sin certificado, el navegador va a marcar tu sitio como "no seguro".

8. Cierre: del prototipo a una URL que se puede compartir

Recapitulando el camino completo: registrás tuproyecto.com.ar en nic.ar pagando la tarifa anual, agregás el dominio en DigitalOcean y tomás sus tres nameservers, volvés a nic.ar a delegar el dominio a esos nameservers, cargás en DigitalOcean un registro A en el apex hacia la IP de tu Droplet y un CNAME para www, verificás con dig que la delegación y la resolución estén bien, y rematás con un certificado HTTPS. El resultado es una dirección propia, memorable y segura, en lugar de una IP cruda.

Para el challenge, esto es lo que separa "tengo un prototipo corriendo en una IP" de "tengo un producto que puedo mostrar". No es obligatorio para que la solución funcione, pero un dominio propio comunica seriedad y te obliga a cerrar el último tramo del despliegue —el que casi nadie practica hasta que lo necesita en serio—. Si seguiste las seis unidades anteriores ya sabés elegir las piezas; esta unidad te dio la dirección donde ponerlas.