De Cero a Cloud: El Camino DevOps en AWS - ¿Cómo funciona una app?
En tecnología no hay magia: hay código corriendo en una computadora y mensajes que viajan. Primer artículo de la serie De Cero a Cloud: El Camino DevOps en AWS, para quienes arrancan desde cero.
Antes de hablar de AWS, hay que entender qué pasa cuando tocás un botón en una pantalla.
Sobre esta serie
En julio de 2026, junto al grupo AWS User Group Girls Uruguay , hicimos un ciclo de cinco sesiones en YouTube pensadas para quien quiere entrar al mundo Cloud y DevOps, o aprender AWS desde cero:
- ¿Cómo funciona una app?
- Bienvenidos a la nube: qué es AWS
- Las herramientas del día a día de un DevOps
- Terraform: de la consola al código
- ¿Y ahora qué sigue? Tu camino a una certificación AWS
Podes ver todas las sesiones en la playlist de YouTube y encontrar más info en el sitio web del ciclo .
La idea de esta serie de artículos es plasmar por escrito todo lo que enseñamos, para que lo puedas leer a tu ritmo, volver cuando quieras y compartirlo. Fue una experiencia hermosa: pude aportar en la gran tarea de crear comunidad, ayudarnos entre todas y fomentar el talento femenino en el mundo Cloud.
En tecnología no hay magia
Cuando empecé en tecnología, lo que más me costaba era sentir que muchas cosas pasaban por arte de magia. Abría una app, apretaba un botón y aparecía el saldo de mi cuenta. Cómo? Ni idea.
Con los años entendí algo que hoy repito siempre: en tecnología no hay magia. Hay código corriendo en alguna computadora y mensajes que viajan de un lado a otro. Si estás buscando un cambio de carrera, vas a trabajar en IT por primera vez o simplemente querés aprender algo nuevo, este artículo es para vos. Arrancamos por lo más básico: entender cómo viaja una solicitud. Sin eso, AWS se vuelve una lista de nombres raros. Con eso, empieza a tener sentido.
Una computadora solo entiende electricidad
Arranquemos por el principio del principio. Una computadora, en el fondo, entiende una sola cosa: si pasa corriente eléctrica o no pasa. Es como el interruptor de la luz: prendido o apagado. A eso le pusimos nombre: 1 cuando pasa, 0 cuando no pasa. Cada uno de esos valores es un bit.
Hace mucho, un grupo de personas se puso de acuerdo en que ciertas combinaciones de ceros y unos representan una letra, un número, un color o un píxel. Tu teclado y tu pantalla funcionan gracias a ese acuerdo. Ahora, escribir ceros y unos a mano sería imposible. Por eso se fueron armando capas por encima, de abajo hacia arriba:
- El procesador, que entiende la electricidad.
- Un traductor por encima.
- El sistema operativo (Windows, macOS, Android, iOS).
- Los lenguajes de programación (Python, JavaScript, Go).
Vos escribís algo que un humano puede leer, y en cada capa se traduce hasta llegar a impulsos eléctricos. Cada capa existe para hacernos la vida más fácil. Y si lo pensás, la IA es una capa más que se está sumando arriba para ayudarnos a escribir código.
Recorda esto: programar no es magia.
Tipos de aplicaciones
Con esas capas resueltas, programar se vuelve algo que cualquiera puede aprender. Y gracias a la programación hoy existen aplicaciones y sitios web para casi todo: bancos, hospitales, tiendas, escuelas, juegos, redes sociales.
Pero aunque todas son "apps", no todas viven en el mismo lugar. Algunas están instaladas en tu celular, otras en tu computadora, y otras ni siquiera están en tus dispositivos: las abrís desde el navegador. Saber dónde corre cada una es el primer paso para entender qué es la nube.
| Tipo | Dónde corre | Ejemplos |
|---|---|---|
| Móvil | Se instala en tu celular (iOS o Android) | Instagram, WhatsApp, TikTok |
| De escritorio | Se instala en tu compu (Windows o macOS) | Word, Chrome |
| Web | La abrís desde el navegador, pero vive en una computadora remota: un servidor | El home banking, una tienda online |
Esa última idea es clave para lo que viene. Cuando hablamos de cloud, hablamos de computadoras que están en otro lado y a las que nos conectamos por internet. Como suelo decir: AWS no deja de ser computadoras remotas.
Frontend y backend: el cajero automático
Ya sabemos dónde viven las apps. Ahora veamos cómo están armadas por dentro.
Casi todas tienen dos partes que trabajan juntas: una que vos ves y usás, y otra que hace el trabajo pesado sin que te des cuenta. Para entenderlo, pensá en algo que seguro usaste alguna vez: un cajero automático.
Todo lo que ves (los botones, la pantalla, los textos) es el frontend: la cara visible del sistema.
Cuando ponés el PIN y pedís consultar el saldo, el frontend no sabe resolverlo. Le pasa el pedido al backend, que es donde vive la lógica de negocio, las reglas:
- Se valida que el PIN sea correcto.
- Si querés sacar plata, se valida que tengas saldo suficiente.
- Si todo está bien, se hace la resta y se te entrega el resultado.
Cada parte usa sus propias herramientas:
- Frontend: HTML (la estructura de la página), CSS (el estilo) y JavaScript (la funcionalidad, como agregar ítems a un carrito).
- Backend: Python, Node.js, Java, Go, entre muchos otros.
Se puede usar un lenguaje para cualquier cosa, pero cada uno está especializado. Es como escribir un documento en PowerPoint: se puede, pero para eso está Word.
La base de datos: donde vive la información
El backend no guarda los datos por su cuenta. Habla con una base de datos, que es donde la información queda de forma persistente. Si apagás la compu, el dato sigue ahí, igual que un archivo en tu disco duro. Tu saldo, tu PIN y tus datos personales no pueden estar en cualquier lado. Tienen que estar en un lugar seguro, que no se borre y que siempre esté disponible. Algunos ejemplos de bases de datos: PostgreSQL, MySQL, SQL Server y SQLite.
Las APIs: el contrato del backend
Ya tenemos el frontend, el backend y la base de datos. Pero falta una pieza: ¿cómo se hablan entre sí? El frontend no puede entrar al backend y hacer lo que quiera. Necesita una forma ordenada y segura de pedir las cosas. Ahí aparecen las APIs, una palabra que vas a escuchar todo el tiempo en el mundo cloud. A mí me costaron mucho al principio, así que va la versión simple.
Una API es la puerta de entrada al backend. Es un contrato que dice: "estas son las cosas que me podés pedir, y así me las tenés que pedir".
Si el frontend del cajero le pregunta al backend del banco cómo está el clima, la respuesta es que eso no está en el contrato. El backend solo sabe responder lo que expuso: saldo, movimientos, retiro. Lo bueno es que un mismo backend puede atender a varios frontends. La app del celular y la web del banco son frontends distintos, pero entran por la misma puerta.
Y las APIs no solo conectan frontend con backend. También conectan servicios entre sí:
- El clima: la app del clima no tiene satélites. Le pregunta a la API de un servicio de meteorología qué temperatura hay en Montevideo.
- Iniciar sesión con Google: el sitio le pregunta a la API de Google si sos quien decís ser.
- Cobrar con Mercado Pago: si tenés una tienda online, no programás toda la lógica de pago. Le mandás el pedido a la API de Mercado Pago y recibís un "pago procesado".
Cómo sabe el frontend dónde está el backend?
Ya sabemos que el frontend le pide cosas al backend a través de una API, pero el backend puede estar en cualquier computadora del mundo. Entonces, ¿cómo sabe el frontend a quién mandarle el pedido?
No adivina, tiene la dirección del backend guardada en su configuración, igual que un contacto en tu agenda. Cuando agendás a Pedro con su número, no tenés que recordarlo nunca más: apretás "llamar" y el teléfono ya sabe a dónde ir. Con el frontend pasa lo mismo.
Esa configuración se guarda en lo que se llaman variables de entorno. Por ejemplo, una dirección como
api.mibanco.com. Además, la solicitud va a una ruta específica. Para consultar el saldo no vas a la ruta del perfil: vas a la ruta donde está esa lógica, y la API puede dejar algunas rutas públicas y otras no.El viaje de una solicitud, paso a paso
Volvamos al cajero y sigamos una consulta de saldo de punta a punta.
El pedido sale del frontend, pasa por el control del backend y solo llega a la base de datos si sabés quién sos.
- Se arma el pedido. El frontend arma un mensaje en formato HTTP con tres cosas: qué querés hacer, dónde lo querés hacer y quién sos. Los verbos más comunes son GET para consultar, POST para crear, PUT para actualizar y DELETE para borrar.
- Viaja encriptado. El mensaje va por internet, pero cifrado. Si alguien lo intercepta, no entiende nada: solo el destinatario tiene la llave para descifrarlo. El candadito que ves en el navegador indica justamente eso.
- El backend valida quién sos. Es como la portería de un edificio: "mostrame tu documento". Si algo no cierra, corta ahí y devuelve un error.
- Consulta la base de datos. Si la autenticación pasa, el backend busca tu saldo.
- Vuelve la respuesta. El backend la empaqueta con un código de estado y la manda de vuelta, también encriptada. El frontend la descifra y te la muestra lindo
Los códigos de estado que más vas a ver
| Código | Qué significa | Ejemplo en el cajero |
|---|---|---|
| 200 | Todo bien | Ves tu saldo |
| 401 | No autorizado | Pusiste mal el PIN |
| 404 | No se encontró lo que pedías | Pediste una ruta que no existe |
| 500 | Error interno del servidor | Algo falló del lado del banco |
Hay muchísimos más, pero es importante conocer los más utilizados.
Y esto qué tiene que ver con DevOps?
Todo lo que vimos es código corriendo en algún servidor. Puede ser un servidor en AWS, pero sigue sin ser magia. Cuando más adelante aparezcan servicios como EC2, RDS o S3, vas a poder ubicarlos: ahí corre el backend, ahí se guardan archivos. Y cuando algo falle en un deploy, vas a tener un mapa mental para investigar: falló el frontend? La API? La base de datos? Es un 401 o un 500?
Un desafío para practicar
La mejor forma de que todo esto deje de ser teoría es verlo con tus propios ojos. No necesitás instalar nada: tu navegador ya trae las herramientas.
- Abrí tu navegador (Chrome, Firefox o Edge) y entrá a cualquier página.
- Apretá F12 para abrir las herramientas de desarrollo.
- Andá a la pestaña Network (en español puede aparecer como Red).
- Recargá la página y mirá cómo se llena la lista.
Cada fila es una solicitud que hizo el frontend. Fijate en dos columnas: el método (vas a ver muchos GET) y el status, que es el código de estado. Buscá un 200 y, si tenés suerte, un 404. Si hacés clic en una fila, podés ver a qué dirección fue el pedido y qué respondió el servidor.
Ahora que sabés qué pasa cuando tocás un botón, estás lista para la pregunta que sigue: ¿dónde corre todo eso? En el próximo artículo, Bienvenidos a la nube: qué es AWS, vamos a ver qué son esas computadoras remotas de las que hablamos, por qué tantas empresas las usan y cómo se empiezan a usar.
Sugerencias o comentarios de mejora, siempre son bienvenidos! 🚀
Nos vemos en el próximo articulo :)
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article