# La nube es el ordenador de otra persona Curso exprés sobre la nube y serverless. 19 conceptos (Cloud computing, CapEx → OpEx, On-demand, IaaS, PaaS, SaaS, Elasticity, Pay-as-you-go, Region, Availability zone, Managed service, Vendor lock-in, Serverless, Cold start y más), cada uno con su nombre en inglés, un diagrama y una tarjeta: qué es → ejemplo → inconveniente → relaciones. Una hoja de referencia de una página al final. Solo lo esencial: la nube no es una palabra de moda, es alquilar cómputo on-demand, un conjunto de compromisos claros entre comodidad, control y coste. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~30 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/cloud-express --- ## 1. Ordenadores alquilados Quita el misticismo y la nube es una idea de negocio sencilla: usar ordenadores que no posees. Todo lo demás es detalle sobre cuánto del trabajo hace por ti el dueño. ### El mapa: 19 conceptos en seis grupos > Un mapa de metro: primero ves todas las líneas juntas, luego recorres estación por estación. Cada concepto de este curso pertenece a uno de seis grupos. Cada grupo responde a su propia pregunta: qué es la nube en sí, cuánto hace por ti el proveedor, cómo crecen la capacidad y la factura, dónde se ejecuta físicamente tu código, qué piezas puedes entregar enteras al proveedor y cómo ejecutar código sin servidores de los que ocuparte. _Diagram: Seis grupos de conceptos: los capítulos 1–6 los siguen. El capítulo 7 explica cómo usarlos juntos._ ### Cómo leer este curso > Un pasaporte: los mismos campos para todos, así es fácil compararlos. Cada concepto recibe el mismo trato: su **nombre en inglés** (recuérdalo: es el término de la documentación de AWS, Google Cloud y Azure), una imagen de la vida cotidiana, un **diagrama** y una **tarjeta** con campos: _qué es_, _ejemplo_, _inconveniente_ y conceptos _relacionados_. La idea principal del curso: cada palabra de moda de la nube es un punto en la escala de «cuánto hace otro por ti», y el precio que pagas por ello. ### Cloud Computing: la nube son ordenadores de otra persona > Un taxi en lugar de comprar un coche: el vehículo es real y el viaje es real, pero no lo posees, ni lo aparcas, ni lo aseguras, ni lo mantienes; solo lo usas cuando lo necesitas. **Cloud computing** son ordenadores en el centro de datos de otra persona que alquilas por internet, en lugar de comprar y operar los tuyos. Cuando tu aplicación se ejecuta «en la nube», se ejecuta en máquinas reales y físicas; simplemente pertenecen a un proveedor como Amazon, Google o Microsoft, que se encarga del edificio, la energía y el hardware. Obtienes potencia de cómputo como servicio, igual que obtienes electricidad, sin poseer la central eléctrica. _Diagram: Tu aplicación se ejecuta en las máquinas del proveedor: servidores, discos, red y el edificio son cosa suya._ #### Cloud Computing (la nube, the cloud) - **Qué es:** Alquilar por internet los ordenadores de otra persona en lugar de comprar los tuyos. - **Ejemplo:** Un sitio web se ejecuta en servidores de AWS: Amazon cuida del edificio, la energía y el hardware; tú cuidas de tu código. - **Inconveniente:** Los servidores no han desaparecido: solo son de otro. Cambias propiedad por dependencia de un proveedor. - **Relaciones:** La base de todo el curso; cuánto hace el proveedor lo deciden **IaaS / PaaS / SaaS**. ### CapEx → OpEx: alquilar en lugar de comprar > No construyes una central eléctrica para abastecer tu casa: te conectas a la red y pagas por lo que usas. Poseer toda la planta solo tiene sentido a una escala enorme. Poseer servidores significa comprar hardware caro por adelantado, adivinar cuánto vas a necesitar y operar una sala llena de máquinas las uses o no. Eso es **gasto de capital (CapEx)**. Alquilar le da la vuelta: sin gran coste inicial, sin hardware ocioso, y otra persona se encarga del lado físico; eso es **gasto operativo (OpEx)**. Para casi todo el mundo, ese intercambio —convertir una compra inicial enorme en una factura pay-as-you-go— es por lo que la nube ganó. Gastas dinero a medida que usas el recurso, no años antes. _Diagram: Izquierda: compras hardware por adelantado y adivinas la capacidad. Derecha: alquilas y pagas según uses._ #### CapEx → OpEx (alquilar en lugar de comprar) - **Qué es:** Cambiar una gran compra inicial de hardware (CapEx) por una factura continua según el uso (OpEx). - **Ejemplo:** Una startup no compra un rack de servidores por si acaso: paga un par de máquinas en la nube mientras tiene pocos clientes. - **Inconveniente:** A una escala enorme y estable, tu propio hardware puede salir más barato, como tu propia central eléctrica. - **Relaciones:** Lo hacen posible **On-demand** y **Pay-as-you-go**. ### On-demand: recursos en segundos > Abrir un grifo y que el agua fluya al instante: sin esperar semanas a una entrega, sin obra de fontanería. El suministro está ahí en el momento en que lo pides. La característica que la define es que los recursos son **on-demand**: puedes levantar un nuevo servidor, una base de datos o un entorno entero en segundos con unos pocos clics o una línea de código, y apagarlo igual de rápido. Compáralo con pedir, esperar e instalar hardware físico. Este acceso instantáneo de **autoservicio** es lo que hace que la nube se sienta menos como comprar máquinas y más como abrir un grifo: capacidad siempre que la pidas. _Diagram: Hardware propio: semanas desde el pedido hasta que funciona. Nube: una llamada a la API y está listo en segundos._ #### On-demand (autoservicio, self-service) - **Qué es:** Arrancar o detener un recurso tú mismo en segundos, sin tickets ni esperar una entrega. - **Ejemplo:** Necesitas un entorno de pruebas por un día: lo levantas con una línea de código por la mañana y lo borras por la tarde. - **Inconveniente:** Igual de fácil de levantar y olvidar: de ahí las sorpresas en la factura (**Bill shock**). - **Relaciones:** La base de **Elasticity** y **Serverless**. > **La pregunta de fondo:** «¿Quiero poseer y operar máquinas físicas —el coste, las conjeturas, el mantenimiento— o alquilar cómputo on-demand y pagar solo por lo que realmente uso?» > La nube es alquilar ordenadores de otra persona on-demand en lugar de comprar los tuyos. Conviertes una compra inicial enorme en pay-as-you-go y obtienes capacidad en segundos. ## 2. IaaS, PaaS, SaaS Los servicios en la nube vienen en capas, que se distinguen por una sola cosa: cuánto gestiona el proveedor y cuánto haces tú. Tres siglas nombran los puntos principales de esa escala. ### Cloud Service Models: la escala de cuánto gestionan por ti > Conseguir una comida: alquilas una cocina y cocinas todo tú, o una cocina con los ingredientes ya preparados, o pides el plato terminado a domicilio. La misma cena, un esfuerzo muy distinto. Los **modelos de servicio en la nube** se sitúan en una escala que va de «gestionas casi todo» a «no gestionas casi nada». En un extremo alquilas máquinas en bruto y haces el resto; en el otro solo usas software terminado. La forma famosa de recordarlo es **«pizza as a service»**: hacerla desde cero, comprarla para hornear en casa o que te la lleven a casa. Las tres capas con nombre (**IaaS, PaaS, SaaS**) son puntos a lo largo de esa línea. _Diagram: De izquierda a derecha, el proveedor asume más y más capas. Tus propios datos y ajustes siguen siendo tuyos en todas partes._ #### Cloud Service Models (pizza as a service) - **Qué es:** La escala de cuántas capas (del hardware a la aplicación) gestiona el proveedor y cuántas gestionas tú. - **Ejemplo:** Tu propia sala de servidores → IaaS → PaaS → SaaS: cada paso reduce de lo que eres responsable. - **Inconveniente:** Cuanto más hacen por ti, menos control tienes: la comodidad nunca es gratis. - **Relaciones:** Puntos de la escala: **IaaS**, **PaaS**, **SaaS**; lo más lejano de todo: **Serverless**. ### IaaS y PaaS: máquinas en bruto o una plataforma lista > Alquilar un taller vacío donde instalas tú todas las herramientas (IaaS), frente a un taller totalmente equipado donde solo traes tu proyecto y empiezas (PaaS). **IaaS (Infrastructure as a Service)** te alquila piezas en bruto —máquinas virtuales, almacenamiento, red— y tú instalas y gestionas todo lo que va encima: máximo control, máximo trabajo. **PaaS (Platform as a Service)** te da un entorno listo donde solo despliegas tu código y el proveedor se encarga de los servidores, el escalado y los parches: menos control, mucho menos trabajo. La elección es cuánta de la fontanería quieres poseer. _Diagram: IaaS: el proveedor te da solo máquinas virtuales. PaaS: el proveedor gestiona todo salvo tu código._ #### IaaS (Infrastructure as a Service) - **Qué es:** Alquilar máquinas virtuales, discos y red; el SO, el runtime y la aplicación son tuyos. - **Ejemplo:** Una máquina virtual en AWS EC2: instalas el software, configuras el sistema y lo mantienes actualizado tú mismo. - **Inconveniente:** Máximo control = máximo trabajo: los parches y el escalado corren de tu cuenta. - **Cuándo usarlo:** Cuando necesitas control total sobre cómo está configurado todo. - **Relaciones:** La base de **Cloud Service Models**; encima, **PaaS**. #### PaaS (Platform as a Service) - **Qué es:** Una plataforma lista: tú traes el código, el proveedor gestiona servidores, escalado y parches. - **Ejemplo:** Haces push a Heroku o a una plataforma similar y la aplicación funciona, sin servidores que configurar. - **Inconveniente:** Menos control: vives según las reglas de la plataforma y dependes de lo que soporta. - **Cuándo usarlo:** Cuando solo quieres desplegar código y no pensar en máquinas. - **Relaciones:** Entre **IaaS** y **SaaS**; primo de **Managed Service**. ### SaaS: software terminado que solo usas > Para tomar un sándwich en una cafetería no cultivas trigo ni horneas: pides y comes. Otra persona hizo cada paso antes de que llegara a ti. **SaaS (Software as a Service)** es el extremo final: software terminado que simplemente usas por internet, con el proveedor gestionando absolutamente todo: Gmail, Slack, tu CRM. No gestionas nada salvo tus propios datos y ajustes. La mayor parte del software que usas a diario es SaaS. Como constructor, _consumes_ SaaS para las partes que no quieres construir y _construyes_ sobre IaaS o PaaS las partes que son tu producto. Saber la capa te dice quién es responsable de qué. _Diagram: El correo, el chat y el CRM los tomas ya hechos (SaaS); tu propio producto lo construyes sobre IaaS o PaaS._ #### SaaS (Software as a Service) - **Qué es:** Una aplicación terminada por internet; gestionas solo tus datos y ajustes. - **Ejemplo:** Gmail, Slack, un CRM: nada que instalar ni mantener. - **Inconveniente:** Casi nada de control: el proveedor decide cómo funciona el software. - **Cuándo usarlo:** Para todo lo que no es tu producto. - **Relaciones:** La cima de **Cloud Service Models**; lo opuesto a **IaaS**. > **La pregunta del modelo:** «Para cada pieza, ¿cuánto quiero gestionar —máquinas en bruto (IaaS), una plataforma lista (PaaS) o nada salvo mis datos (SaaS)— frente a cuánto control necesito realmente?» > Las capas de la nube se diferencian por cuánto gestiona el proveedor por ti: IaaS son máquinas en bruto que gestionas tú, PaaS es una plataforma lista para tu código, SaaS es software terminado que solo usas. ## 3. Elasticity y pay-as-you-go El superpoder de la nube es que la capacidad no es fija. Crece y se reduce según tu necesidad, y pagas por lo que usas: un regalo y, si eres descuidado, una trampa. ### Elasticity: arriba en el pico, abajo después > Un recinto de conciertos que pudiera añadir mil asientos para la gran noche y quitarlos a la mañana siguiente: capacidad que se ajusta al público, nunca desperdiciada en una sala vacía. **Elasticity** es la capacidad de la nube de añadir recursos cuando la demanda se dispara y quitarlos cuando baja. Una oferta, un momento viral, una hora punta: la nube levanta más servidores para atenderlo y luego vuelve a reducirse, así que no pagas por capacidad que no necesitas. Con hardware propio tendrías que comprar para tu momento de más trabajo y dejarlo parado el resto del tiempo. Elasticity ajusta lo que ejecutas a lo que realmente necesitas, minuto a minuto. El mecanismo que lo hace automáticamente se llama **autoscaling**. _Diagram: La capacidad sube y baja con la demanda. La línea roja es el hardware propio, comprado para el pico y ocioso el resto del tiempo._ #### Elasticity (autoscaling) - **Qué es:** La capacidad crece ante un pico de demanda y se reduce cuando pasa. - **Ejemplo:** Durante unas rebajas la tienda funciona con diez servidores; por la noche, con dos. - **Inconveniente:** Escalar sin techo puede disparar la factura por sí solo (**Bill shock**). - **Relaciones:** Necesita **On-demand**; se paga mediante **Pay-as-you-go**; su forma extrema es **Scale to Zero**. ### Pay-as-you-go: un contador, no una compra > Una factura de suministros: pagas la electricidad que realmente usaste este mes, no una cuota fija por poseer la red. Usas más, pagas más; no usas nada, no pagas nada. La nube factura como un suministro: **pay-as-you-go**, cobrando por el cómputo, el almacenamiento y el tráfico que realmente consumes. Sin compra inicial, sin pagar por capacidad ociosa: el contador corre solo mientras usas el recurso. Eso es lo que hace accesible la nube: puedes empezar pequeño y barato, y tus costes crecen con tu uso en lugar de ser una apuesta enorme hecha antes de tener ningún cliente. La factura sigue a la realidad. _Diagram: Cómputo, almacenamiento y tráfico pasan por un contador; a fin de mes la factura es igual a lo que usaste._ #### Pay-as-you-go (facturación por uso, usage-based billing) - **Qué es:** Pagar por el cómputo, el almacenamiento y el tráfico que realmente consumiste. - **Ejemplo:** Un proyecto pequeño cuesta céntimos mientras tiene pocos usuarios; el tráfico crece, la factura crece. - **Inconveniente:** «Paga solo por lo que usas» = «paga por todo lo que usas». - **Relaciones:** El lado del dinero de **CapEx → OpEx** y **Elasticity**. ### Bill Shock: el contador corta por los dos lados > El taxímetro es justo en un trayecto corto y aterrador si olvidas que lleva horas corriendo: el mismo precio por uso que te ahorra dinero puede acumular una fortuna en silencio. Pay-as-you-go es un arma de doble filo. La misma medición que te ahorra dinero cuando el uso es bajo puede producir una factura espantosa cuando algo se descontrola: un proceso que se quedó encendido, un escalado desbocado, un error que entra en bucle. Esa sorpresa se llama **bill shock**. Es común precisamente porque es muy fácil levantar cosas y muy fácil olvidarlas. De ahí la regla: tienes que vigilar el contador, por ejemplo con una **alerta de presupuesto** que salta cuando el gasto cruza un límite. _Diagram: Días normales, gasto plano. Luego algo se descontrola y los costes se disparan; una alerta de presupuesto lo detecta pronto._ #### Bill Shock (factura sorpresa, surprise bill) - **Qué es:** Una factura de la nube inesperadamente enorme porque algo se descontroló. - **Ejemplo:** Un servidor de pruebas que se quedó encendido un mes; un bucle en el código que llama una y otra vez a un servicio de pago. - **Cómo evitarlo:** Vigila el gasto como vigilas el rendimiento; pon alertas de presupuesto y techos de escalado. - **Relaciones:** El reverso de **Pay-as-you-go**, **On-demand** y **Elasticity**. > **La pregunta del coste:** «¿Mi capacidad escala con la demanda real y se reduce cuando baja, y estoy vigilando el contador para que pay-as-you-go ahorre dinero en lugar de acumular en silencio una factura sorpresa?» > Elasticity sube la capacidad para los picos y la baja después; pay-as-you-go cobra solo lo que usas. El mismo contador que ahorra dinero puede producir una factura de susto, así que vigílalo. ## 4. Regiones y disponibilidad La nube no es un solo lugar: son centros de datos repartidos por el mundo. Dónde se ejecutan tus cosas afecta tanto a lo rápido que se sienten como a lo bien que sobreviven a un fallo. ### Region: cómputo cerca del usuario > Una empresa de reparto con almacenes en cada continente envía a cada cliente desde el más cercano: más rápido para todos que enviarlo todo desde un único centro. Los proveedores tienen centros de datos en **regiones** por todo el planeta. Tú eliges dónde se ejecuta tu aplicación, y ponerla en una región cercana a tus usuarios reduce la **latencia**: los datos tienen menos distancia que recorrer, así que la aplicación se siente más rápida. Una aplicación europea servida desde una región europea supera a una servida desde el otro lado de un océano. Elegir región es la palanca de la geografía: coloca tu cómputo y tus datos cerca de las personas que los usan. _Diagram: Los usuarios de Europa van a la región europea: un viaje corto. Una región lejana significa un viaje largo a través del océano._ #### Region (latencia, latency) - **Qué es:** Un grupo de centros de datos de un proveedor en una parte del mundo que eliges para tu código. - **Ejemplo:** Una aplicación para europeos se despliega en una región europea. - **Inconveniente:** Una región es un solo lugar: los usuarios del otro lado del mundo la reciben más lenta. - **Relaciones:** Dentro de una región hay varias **Availability Zones**; juntas dan **High Availability**. ### Availability Zone: sobrevivir a que falle un edificio > Un banco que guarda copias de sus registros en varios edificios separados: si uno se inunda, los demás siguen y no se pierde nada. Dentro de una región hay varias **availability zones**: centros de datos físicamente separados. Ejecutas copias de tu sistema en varias zonas a la vez. Si una zona se queda sin energía o falla, las demás siguen sirviendo y tu aplicación sigue en pie. _Diagram: Tres zonas, tres centros de datos separados. La zona B se quedó sin energía, pero las copias en A y C siguen respondiendo._ #### Availability Zone (AZ) - **Qué es:** Un centro de datos físicamente separado dentro de una región. - **Ejemplo:** Copias de la aplicación en tres zonas: una se queda sin energía y las otras dos siguen funcionando. - **Inconveniente:** Solo te protege de que falle un edificio si realmente ejecutas copias en varias zonas. - **Relaciones:** Parte de una **Region**; un ladrillo de **Redundancy / High Availability**. ### Redundancy y High Availability: cerca del usuario, resistente a fallos > Una tienda con sucursales en cada ciudad, y cada sucursal respaldada por otra cercana: cerca de los clientes y a prueba de que cualquier ubicación se apague. **Redundancy** significa que ningún edificio, máquina o zona es un **punto único de fallo** fatal. Lo que obtienes de ello es **high availability**: seguir en pie a pesar de fallos que tumbarían una ubicación única. Las dos ideas se combinan en el núcleo de la arquitectura en la nube: coloca el cómputo en **regiones** cercanas a tus usuarios para la velocidad, y repártelo entre **zonas** para la resiliencia. Un servicio global se siente local en todas partes y sobrevive al inevitable fallo de hardware en algún lugar. Ya no apuestas todo tu producto a una máquina en un edificio: estás repartido por diseño, que es la mayor parte de lo que significa realmente «la nube es fiable». _Diagram: Dos regiones cerca de dos grupos de usuarios; en cada una, copias en dos zonas. Ningún punto único de fallo._ #### High Availability (redundancia, redundancy) - **Qué es:** El sistema sigue en pie ante fallos porque cada parte tiene una copia en otro sitio. - **Ejemplo:** Un servicio global: una región en Europa y otra en EE. UU., cada una con copias en dos zonas. - **Inconveniente:** Las copias cuestan dinero y añaden complejidad: cada copia está en la factura. - **Relaciones:** Construida con **Region** (velocidad) y **Availability Zone** (resiliencia). > **La pregunta de la ubicación:** «¿Está mi cómputo en una región cercana a mis usuarios para tener baja latencia, y repartido entre availability zones para que el fallo de un centro de datos no tumbe todo?» > Las regiones ponen tu cómputo cerca de los usuarios para reducir la latencia; las availability zones lo reparten entre centros de datos separados para la redundancia: cerca de las personas, resistente a cualquier fallo único. ## 5. Managed services Más allá de alquilar máquinas, la nube gestionará por ti piezas enteras de infraestructura —una base de datos, una cola, una caché— para que las uses sin operarlas. Esa comodidad es un compromiso real. ### Managed Service: deja que el proveedor lleve lo difícil > Un apartamento con servicio donde otra persona se ocupa de la fontanería, la calefacción y las reparaciones: tú solo vives allí, en lugar de ser tu propio conserje. Un **managed service** es infraestructura que el proveedor de la nube gestiona por ti —una base de datos gestionada, una cola de mensajes o una caché—, encargándose de la puesta en marcha, el escalado, las copias de seguridad, los parches y el **failover**. Lo usas a través de una interfaz y nunca tocas las máquinas de debajo. En lugar de convertirte en experto en operar una base de datos de forma fiable a escala, alquilas esa experiencia. _Diagram: Base de datos propia: todo corre de tu cuenta. Base de datos gestionada: solo tu aplicación y tus consultas; el resto es del proveedor._ #### Managed Service (base de datos, cola, caché gestionadas) - **Qué es:** Una base de datos, cola o caché que el proveedor configura, escala, respalda y parchea por ti. - **Ejemplo:** Postgres gestionado (por ejemplo AWS RDS) en lugar de tu propia base de datos en una máquina virtual. - **Inconveniente:** Menos control y una atadura al proveedor (**Vendor Lock-in**). - **Relaciones:** Elimina el **Undifferentiated Heavy Lifting**; el siguiente paso es **Serverless**. ### Undifferentiated Heavy Lifting: menos operaciones, más producto > El dueño de un food truck que compra el pan en una panadería en lugar de moler la harina: se centra en las comidas que son su negocio real, no en convertirse también en panadero. El sentido de los managed services es el **enfoque**. Operar infraestructura de forma fiable (copias de seguridad, escalado, parches de seguridad, fallos a las 3 de la madrugada) es un trabajo difícil y especializado, y para la mayoría de los equipos no es donde está su valor. Este tipo de trabajo se llama **undifferentiated heavy lifting**: trabajo pesado que no te distingue de la competencia. Cada hora que no gastas en mantener viva una base de datos es una hora dedicada a lo que realmente es tu producto. Descargarlo permite a un equipo pequeño rendir muy por encima de su tamaño, construyendo funciones en lugar de cuidar servidores. Esta es una gran parte de por qué los productos modernos salen rápido con equipos pequeños. #### Undifferentiated Heavy Lifting (operaciones que no te diferencian) - **Qué es:** Trabajo operativo duro que todos necesitan, pero que no hace especial a tu producto. - **Ejemplo:** Copias de seguridad, parches de seguridad y fallos de la base de datos a las 3 de la madrugada, en lugar de trabajar en funciones. - **Inconveniente:** Si las operaciones son tu valor, cedérselas a otro es un error. - **Relaciones:** La razón para elegir **Managed Service** y **Serverless**. ### Vendor Lock-in: comodidad frente a control > Un kit de comida preparada es maravillosamente cómodo, hasta que quieres cambiar un ingrediente y descubres que el kit decide la receta. La comodidad se paga con control. El compromiso es real: un managed service cede algo de control y te ata a la forma de hacer las cosas de ese proveedor. Cuanto más a fondo adoptas sus servicios específicos, más difícil y costoso es irse. Eso es **vendor lock-in**. Estás eligiendo comodidad y velocidad ahora frente a flexibilidad e independencia después. A menudo es la decisión correcta, pero tómala a conciencia, manteniendo intercambiables las piezas realmente críticas. Es el mismo criterio que al elegir entre una API gestionada y el autoalojamiento. _Diagram: La aplicación se apoya en la base de datos, la cola y las API únicas de un proveedor, y mudarse a otro se vuelve caro._ #### Vendor Lock-in (dependencia del proveedor, provider lock-in) - **Qué es:** Cuanto más metido estás en los servicios de un proveedor, más caro es irse. - **Ejemplo:** La aplicación está atada a las API únicas del proveedor: mudarse significa reescribir. - **Cómo convivir con ello:** Acepta el lock-in a conciencia; mantén portátiles las piezas realmente críticas. - **Relaciones:** El precio de **Managed Service** y **Serverless**. > **La pregunta de lo gestionado:** «¿Operar esta pieza yo mismo forma parte de mi valor, o debo dejar que lo lleve un managed service y dedicar ese esfuerzo a mi producto, aceptando algo de lock-in a cambio del enfoque?» > Los managed services dejan que el proveedor lleve la base de datos, la cola o la caché, para que te centres en tu producto y no en las operaciones. El compromiso es menos control y algo de vendor lock-in. ## 6. Serverless El paso más lejano de «no gestiones las máquinas» es serverless: aportas solo tu código y la nube lo ejecuta on-demand, escalando y facturando por petición. Es potente para el tipo de trabajo adecuado. ### Serverless: solo tu código, sin servidores de los que ocuparte > Una sala de reuniones que reservas por medias horas: no es tuya, no la calientas ni la limpias; solo llegas, la usas y en cuanto te vas desaparece de tu cabeza. **Serverless** te permite ejecutar código sin gestionar ningún servidor. Entregas al proveedor una **función** —un pequeño trozo de código— y la ejecuta cada vez que la dispara un evento: una petición, la subida de un archivo, una programación. Se ocupa de todas las máquinas, el escalado y la capacidad de forma invisible. Esta variante también se llama **FaaS (Function as a Service)**. Por supuesto, siguen existiendo servidores; solo que nunca piensas en ellos. Es el final lógico del viaje a la nube: de poseer máquinas, a alquilarlas, a ni siquiera ser consciente de ellas. _Diagram: Un evento (petición, archivo, programación) dispara tu función; los servidores y el escalado quedan ocultos en el proveedor._ #### Serverless (FaaS, Function as a Service) - **Qué es:** Entregas una función; el proveedor la ejecuta en cada evento y gestiona todas las máquinas. - **Ejemplo:** Una función de AWS Lambda comprime una imagen cada vez que un usuario sube una. - **Inconveniente:** **Cold Start**, poco adecuado para trabajo largo y constante, y atadura al proveedor. - **Cuándo usarlo:** Tareas cortas dirigidas por eventos, carga a ráfagas. - **Relaciones:** El extremo lejano de **Cloud Service Models**; escala a cero (**Scale to Zero**). ### Scale to Zero: cero peticiones, cero coste > Una luz con sensor de movimiento: apagada y sin costar nada cuando la sala está vacía, encendida al instante en cuanto entra alguien. Pagas la luz solo mientras está realmente encendida. Serverless **escala a cero**: cuando nadie usa tu función, no se ejecuta nada y no pagas nada; cuando llegan peticiones a raudales, levanta automáticamente tantas copias como hagan falta. Se te factura **por petición** y por fracción de segundo de cómputo, no por un servidor ocioso esperando. Es ideal para trabajo irregular, ocasional o impredecible: obtienes un escalado sin esfuerzo y no pagas nada en los momentos de calma, algo que un servidor siempre encendido no puede igualar. _Diagram: Arriba: peticiones; abajo: copias de la función. Sin peticiones, cero copias y cero en la factura; en una avalancha, tantas copias como hagan falta._ #### Scale to Zero (facturación por petición, per-request billing) - **Qué es:** Sin peticiones no se ejecuta nada y la factura es cero; ante una avalancha, las copias arrancan solas. - **Ejemplo:** Un informe interno que se llama un par de veces al día cuesta casi nada. - **Inconveniente:** Tras un rato de calma, la primera petición espera al arranque (**Cold Start**). - **Relaciones:** La forma extrema de **Elasticity** y **Pay-as-you-go**. ### Cold Start: el precio de que no se ejecute nada > Esa luz con sensor de movimiento tiene un pequeño parpadeo de retraso al encenderse: bien para un pasillo, molesto si necesitabas una luz instantánea y constante. Serverless no está libre de compromisos. Una función que ha estado ociosa tiene un **cold start**: un breve retraso mientras el proveedor la levanta, que puede perjudicar al trabajo sensible a la latencia. Encaja mejor con tareas cortas dirigidas por eventos que con las de larga duración o de tráfico alto y constante, donde un servidor siempre encendido puede ser más simple y barato. Y se apoya en servicios propios del proveedor, así que el lock-in también aplica. Serverless es una herramienta afilada para el trabajo adecuado —a ráfagas, dirigido por eventos, de scale to zero—, no un valor por defecto universal. _Diagram: Una función fría primero arranca y solo después responde; una caliente responde de inmediato._ #### Cold Start (retraso de arranque, startup delay) - **Qué es:** El retraso en la primera petición mientras el proveedor despierta una función ociosa. - **Ejemplo:** Una función poco usada responde a su primera petición notablemente más lento que a las siguientes. - **Cómo convivir con ello:** Para trabajo sensible a la latencia o tráfico constante, usa un servidor siempre encendido. - **Relaciones:** El precio de **Scale to Zero** en **Serverless**. > **La pregunta de serverless:** «¿Este trabajo es a ráfagas o dirigido por eventos, donde brillan el scale to zero y la facturación por petición, o constante y sensible a la latencia, donde un servidor encendido evita los cold starts?» > Serverless ejecuta solo tu código, escalando a cero y facturando por petición: ideal para trabajo a ráfagas dirigido por eventos. Cuidado con los cold starts y el lock-in; es una herramienta afilada, no un valor por defecto. ## 7. Usarla bien La nube es una caja de herramientas de compromisos, no una única respuesta correcta. Usarla bien es ajustar cada pieza al modelo que le encaja, y estar atento a las dos cosas que muerden: la factura y el lock-in. ### Ajusta el modelo a la necesidad > No usas un camión de reparto para llevar a los niños al colegio ni una bicicleta para una mudanza: eliges el vehículo que encaja con el trayecto, no uno por defecto para todo. No hay una única capa correcta. Usa **SaaS** para capacidades que no son tu producto, **managed services** para descargar el undifferentiated heavy lifting, **serverless** para trabajo a ráfagas dirigido por eventos, y **máquinas en bruto (IaaS)** cuando necesitas control total. La habilidad está en ajustar cada parte de tu sistema al modelo que encaja con sus necesidades: control donde importa, comodidad donde no. Una buena arquitectura en la nube suele ser una mezcla deliberada, no un solo modelo aplicado en todas partes. _Diagram: Cada tipo de trabajo recibe su propio modelo: SaaS, un managed service, serverless o máquinas en bruto._ ### Vigila la factura y ten cuidado con el lock-in > Alquilar libera hasta que dejas de leer los extractos, y el alquiler más cómodo es el que está diseñado para que nunca puedas mudarte. Dos cosas muerden de forma constante a los usuarios de la nube. Primero, la **factura**: los recursos on-demand fáciles hacen que los costes puedan crecer poco a poco o dispararse sin que nadie lo note (**bill shock**), así que vigilas el gasto igual que vigilas el rendimiento. Segundo, el **lock-in**: cuanto más a fondo te conectas a los servicios únicos de un proveedor, más difícil y costoso es irse. Ninguna significa evitar la nube: significan usarla con los ojos abiertos: sigue el contador y evita que tus piezas realmente críticas y portátiles queden soldadas para siempre a un solo proveedor. ### Cómo encaja todo > Un puzle: cada pieza significa poco por sí sola; juntas forman la imagen. Los conceptos de este curso son un solo sistema. **Cloud computing** es alquilar en lugar de poseer. De ahí crecen tres ramas. La primera es el dinero: **on-demand** hace posible **elasticity**, que se paga mediante **pay-as-you-go**, y el contador tiene un lado oscuro: **bill shock**. La segunda es cuánto se hace por ti: **IaaS → PaaS → SaaS**, **managed services** y **serverless**, que **escala a cero** al precio de **cold starts** y **vendor lock-in**. La tercera es dónde se ejecutan las cosas: **region**, **availability zones** y, juntas, **high availability**. _Diagram: La nube se divide en tres ramas: dinero, cuánto hace el proveedor y ubicación. El rojo marca el riesgo de cada rama._ #### Antes de construir sobre la nube - **Alquilar o poseer**: ¿encajan mejor on-demand y pay-as-you-go que comprar hardware? - **Qué modelo para cada pieza**: IaaS, PaaS, SaaS, serverless, según el control que necesites. - **¿Escala?** De forma elástica con la demanda, arriba para los picos y abajo después. - **Región y zonas**: cómputo cerca de los usuarios, repartido para la resiliencia. - **Gestionado o propio**: ¿operar esta parte es realmente tu valor? - **La factura y el lock-in**: ¿vigilo el gasto y mantengo portátiles las piezas críticas? #### Señales de que usas bien la nube - **Alquilas on-demand** y pagas por el uso en lugar de comprar para tu hora de más trabajo. - Cada pieza usa el **modelo que le encaja**, de las máquinas en bruto a serverless. - Tu sistema **escala de forma elástica** y funciona en **regiones cercanas a los usuarios**, repartido entre **zonas**. - Descargas el trabajo indiferenciado en **managed services** y te centras en tu producto. - **Vigilas la factura** y mantienes portátiles las piezas críticas frente al **lock-in**. ## Hoja de referencia: los 19 conceptos ### Ordenadores alquilados - **Cloud Computing** (la nube, the cloud): Alquilar por internet los ordenadores de otra persona en lugar de comprar los tuyos. - **CapEx → OpEx** (alquilar en lugar de comprar): Una enorme compra inicial de hardware se convierte en una factura pay-as-you-go. - **On-demand** (autoservicio, self-service): Arrancar o detener un recurso tú mismo, en segundos. ### Modelos de servicio - **Cloud Service Models** (pizza as a service): La escala de cuántas capas gestiona el proveedor y cuántas gestionas tú. - **IaaS** (Infrastructure as a Service): Máquinas virtuales, discos y red en bruto; todo lo de encima es tuyo. - **PaaS** (Platform as a Service): Una plataforma lista: tú traes el código, el proveedor gestiona los servidores. - **SaaS** (Software as a Service): Software terminado; gestionas solo tus datos y ajustes. ### Elasticity y dinero - **Elasticity** (autoscaling): La capacidad crece para un pico y se reduce después. - **Pay-as-you-go** (facturación por uso, usage-based billing): Pagas por el cómputo, el almacenamiento y el tráfico que realmente consumes. - **Bill Shock** (factura sorpresa, surprise bill): Una factura inesperadamente enorme cuando algo se descontrola. Se cura vigilando el gasto. ### Dónde se ejecuta - **Region** (latencia, latency): Centros de datos en una parte del mundo; más cerca de los usuarios significa menos latencia. - **Availability Zone** (AZ): Un centro de datos separado dentro de una región; las copias entre zonas sobreviven a un fallo. - **High Availability** (redundancia, redundancy): Sin punto único de fallo: el sistema sigue en pie ante fallos. ### Managed services - **Managed Service** (BD, cola, caché gestionadas): Una base de datos, cola o caché que el proveedor gestiona por ti. - **Undifferentiated Heavy Lifting** (operaciones que no te diferencian): Operaciones duras que no hacen especial a tu producto: conviene cederlas. - **Vendor Lock-in** (dependencia del proveedor, provider lock-in): Cuanto más metido estás en los servicios de un proveedor, más caro es irse. ### Serverless - **Serverless** (FaaS): Solo tu código; el proveedor lo ejecuta en cada evento. - **Scale to Zero** (facturación por petición, per-request billing): Sin peticiones no se ejecuta nada y no se factura nada. - **Cold Start** (retraso de arranque, startup delay): El retraso en la primera petición mientras una función arranca tras estar ociosa. > La nube es alquilar cómputo on-demand, en capas que van de las máquinas en bruto a serverless. Úsala bien ajustando cada pieza al modelo adecuado, y vigilando la factura y el lock-in. Fin del curso exprés · 7 capítulos · 19 conceptos Ahora toca practicar: toma una aplicación pequeña y despliégala en una plataforma en la nube; elige una opción PaaS o serverless para que solo hagas push del código, y observa cómo escala y factura según el uso. Luego añade un managed service, como una base de datos, en lugar de operar la tuya. Los compromisos se vuelven concretos en cuanto notas lo poco que tienes que operar, y ves el contador avanzando. Pero conserva una idea por encima de las demás: la nube es solo el ordenador de otra persona, alquilado on-demand. Cada palabra de moda es un punto en una escala de cuánto gestiona otro por ti, y usarla bien es elegir, pieza a pieza, cuánta comodidad cambiar por cuánto control.