Curso exprés · No. 25
«La nube» suena abstracto, pero es solo alquilar los ordenadores de otra persona en lugar de comprar los tuyos, y pagar solo por lo que usas, escalando hacia arriba y hacia abajo on-demand. Serverless va más allá: dejas de pensar en las máquinas por completo y solo ejecutas tu código. Aprende las palabras y la nube deja de ser una palabra de moda para convertirse en un conjunto claro de compromisos entre comodidad, control y coste.
Solo lo esencial · Una imagen por idea · Aprende las palabras
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.
La nube son solo los 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.
La nube 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.
Alquilar le gana a comprar para la mayoría
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. Alquilar le da la vuelta a eso: sin gran coste inicial, sin hardware ocioso, y otra persona se encarga del lado físico. 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.
On-demand: obtén 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 y 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.
La nube es alquilar los 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.
Los servicios en la nube vienen en capas, distinguidas por una sola cosa: cuánto gestiona el proveedor frente a cuánto haces tú. Tres siglas nombran los puntos principales de ese espectro.
El espectro: cuánto operan por ti
Conseguir una comida: alquila una cocina y prepárala toda tú mismo, consigue una cocina con los ingredientes ya listos, o simplemente pide el plato terminado a domicilio. La misma cena, esfuerzos radicalmente distintos.
Las ofertas en la nube se sitúan en un espectro que va de «gestionas casi todo» a «gestionas casi nada». En un extremo alquilas máquinas en bruto y haces el resto; en el otro simplemente usas software terminado. La forma famosa de recordarlo es «pizza as a service»: hazla desde cero, llévatela para hornear, o pídela a domicilio. Las tres capas con nombre —IaaS, PaaS, SaaS— son puntos a lo largo de esa línea.
IaaS y PaaS: máquinas en bruto o una plataforma lista
Alquilar un taller vacío donde instalas cada herramienta tú mismo (IaaS), frente a un taller totalmente equipado donde solo traes tu proyecto y empiezas (PaaS).
IaaS (Infrastructure as a Service) te alquila bloques de construcción en bruto —máquinas virtuales, almacenamiento, redes— y tú instalas y gestionas todo lo de encima: máximo control, máximo trabajo. PaaS (Platform as a Service) te entrega un entorno listo donde solo despliegas tu código y el proveedor opera los servidores, el escalado y los parches por debajo: menos control, mucho menos trabajo. La elección es cuánta de la fontanería quieres poseer.
SaaS: software terminado que solo usas
No cultivas trigo ni horneas para conseguir un sándwich en una cafetería: simplemente lo pides y comes. Otra persona hizo cada paso antes de que llegara a ti.
SaaS (Software as a Service) es el extremo opuesto: software terminado que simplemente usas por internet, con el proveedor operando absolutamente todo —Gmail, Slack, tu CRM—. No gestionas nada salvo tus propios datos y ajustes. La mayoría 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 para las partes que son tu producto. Saber la capa te dice quién es responsable de qué.
Las capas de la nube se diferencian por cuánto opera 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.
El superpoder de la nube es que la capacidad no es fija. Crece y se encoge con tu necesidad, y pagas por lo que usas, lo cual es un regalo y, si te descuidas, una trampa.
Elasticity: escala hacia arriba en el pico, hacia abajo después
Un recinto de conciertos que podría añadir mil asientos para la gran noche y retirarlos 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 retirarlos cuando cae. Una rebaja, un momento viral, una hora cargada: la nube levanta más servidores para absorberlo, luego reduce de nuevo después, así no pagas por capacidad que no necesitas. Con hardware propio tendrías que comprar para tu momento más ocupado y dejarlo ocioso el resto del tiempo. Elasticity ajusta lo que ejecutas a lo que realmente necesitas, minuto a minuto.
Pay-as-you-go: un contador, no una compra
Una factura de suministros: pagas por la electricidad que realmente usaste este mes, no una tarifa plana por poseer la red. Usa más, paga más; no uses nada, no pagues 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. Esto es lo que hace accesible a la nube: puedes empezar diminuto y barato, y tus costes crecen con tu uso en lugar de ser una apuesta enorme hecha antes de tener un solo cliente. La factura refleja la realidad.
El contador corta por ambos lados
El contador de un taxi 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. El mismo contador que te ahorra dinero cuando el uso es bajo puede producir una factura impactante cuando algo se descontrola: un proceso que quedó encendido, un escalado desbocado, un error que entra en bucle. Las sorpresas de coste en la nube son comunes precisamente porque es muy fácil levantar cosas y muy fácil olvidarlas. La otra cara de «paga solo por lo que usas» es «pagas por todo lo que usas», así que tienes que vigilar el contador.
Elasticity escala la capacidad hacia arriba en los picos y hacia abajo después; pay-as-you-go cobra solo por lo que usas. El mismo contador que ahorra dinero puede acumular una factura de susto, así que vigílalo.
La nube no es un solo lugar: son centros de datos repartidos por todo el mundo. Dónde se ejecutan tus cosas afecta tanto a lo rápida que se siente como a lo bien que sobrevive a un fallo.
Las regiones reparten cómputo por el mundo
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 mandarlo todo desde un único centro.
Los proveedores operan centros de datos en regiones por todo el planeta. Eliges dónde se ejecuta tu aplicación, y ponerla en una región cerca de tus usuarios reduce la latency: 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 le gana a una servida desde el otro lado de un océano. La elección de región es la palanca de la geografía: coloca tu cómputo y tus datos cerca de la gente que los usa.
Las availability zones sobreviven a un fallo
Un banco que guarda copias de sus registros en varios edificios separados: si uno se inunda, los demás continúan y nada se pierde. La redundancy es justamente el objetivo.
Dentro de una región hay múltiples availability zones —centros de datos físicamente separados— para que puedas ejecutar copias de tu sistema repartidas entre ellos. Si una zona pierde la energía o falla, las demás siguen sirviendo, y tu aplicación se mantiene en pie. Esto es redundancy: ningún edificio, máquina o zona es un punto único de fallo fatal. Repartir entre zonas es como los sistemas en la nube logran alta availability: mantenerse en pie a través de fallos que tumbarían a una sola ubicación.
Cerca del usuario, y resistente al fallo
Una tienda con sucursales en cada ciudad, y cada sucursal respaldada por una segunda cercana: cerca de los clientes y dura ante el apagón de cualquier ubicación.
Las dos ideas se combinan en el núcleo de la arquitectura en la nube: coloca el cómputo en regiones cerca de tus usuarios para la velocidad, y repártelo entre zonas para la resiliencia. Juntas permiten que un servicio global se sienta local en todas partes y sobreviva al inevitable fallo de hardware en algún sitio. Ya no estás apostando todo tu producto a una máquina en un edificio: estás repartido por diseño, que es la mayor parte de lo que realmente significa «la nube es fiable».
Las regiones ponen tu cómputo cerca de los usuarios para reducir la latency; las availability zones lo reparten entre centros de datos separados para la redundancy: cerca de la gente, resistente a cualquier fallo único.
Más allá de alquilar máquinas, la nube operará por ti piezas enteras de infraestructura —una base de datos, una cola, una caché— para que puedas usarlas sin operarlas. Esa comodidad es un compromiso real.
Deja que el proveedor opere las partes difíciles
Un apartamento con servicios donde otra persona se encarga de la fontanería, la calefacción y las reparaciones: tú simplemente vives ahí, en lugar de ser el conserje de tu propio edificio.
Un managed service es infraestructura que el proveedor de la nube opera por ti —una base de datos, una cola de mensajes o una caché gestionadas— encargándose de la configuración, el escalado, las copias de seguridad, los parches y el failover. La 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. El proveedor hace el trabajo operativo duro y poco glamuroso, y tú obtienes la capacidad lista para usar.
Menos ops, más foco en tu 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 verdadero negocio, no en convertirse también en panadero.
El sentido de los managed services es el foco: cada hora no gastada en mantener viva una base de datos es una hora gastada en lo que realmente es tu producto. Operar infraestructura de forma fiable —copias de seguridad, escalado, parches de seguridad, fallos a las 3 de la mañana— es un trabajo difícil y especializado, y para la mayoría de los equipos no es su valor. Descargarlo en el proveedor permite que un equipo pequeño rinda muy por encima de su tamaño, construyendo funcionalidades en lugar de cuidar servidores. Esto es una gran parte de por qué los productos modernos salen rápido con equipos pequeños.
Comodidad frente a control y lock-in
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 en 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, y cuanto más a fondo adoptas sus servicios específicos, más difícil es marcharte, que es el 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 verdaderamente críticas, el mismo criterio que elegir entre una API gestionada y el autoalojamiento.
Los managed services dejan que el proveedor opere la base de datos, la cola o la caché, para que te centres en tu producto en lugar de en las operaciones. El compromiso es menos control y algo de vendor lock-in.
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 la forma de trabajo adecuada.
Serverless: solo tu código, sin servidores que atender
Una sala de reuniones que reservas por media hora: no la posees, ni la calientas, ni la limpias; simplemente apareces, la usas, y se borra de tu mente en el momento en que te vas.
Serverless te permite ejecutar código sin gestionar ningún servidor en absoluto. Le entregas al proveedor una función —un pequeño trozo de código— y este ejecuta esa función cada vez que se dispara, encargándose de todas las máquinas, el escalado y la capacidad de forma invisible. Sigue habiendo servidores, por supuesto; simplemente nunca piensas en ellos. Es el final lógico del viaje de la nube: de poseer máquinas, a alquilarlas, a ni siquiera ser consciente de ellas.
Hace scale to zero y factura por petición
Una luz con sensor de movimiento: apagada y sin costar nada cuando la sala está vacía, encendida al instante en cuanto alguien entra. Pagas por la luz solo mientras está realmente encendida.
Serverless hace scale to zero: cuando nadie usa tu función, nada se ejecuta y no pagas nada; cuando las peticiones llegan 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. Esto es ideal para trabajo con picos, ocasional o impredecible: obtienes un escalado sin esfuerzo y no pagas nada durante la calma, algo que un servidor en marcha constante no puede igualar.
Los compromisos: cold starts y encaje
Esa luz con sensor de movimiento tiene un diminuto parpadeo de retardo al encenderse: bien para un pasillo, molesto si necesitabas un brillo instantáneo y constante.
Serverless no está libre de compromisos. Una función que ha estado ociosa tiene un cold start —un breve retardo mientras el proveedor la levanta— que puede perjudicar al trabajo sensible a la latency. Encaja mejor con tareas cortas y dirigidas por eventos que con las de larga duración o de tráfico alto y sostenido, donde un servidor en marcha constante puede ser más simple y barato. Y se apoya en servicios específicos del proveedor, así que aplica el lock-in. Serverless es una herramienta afilada para el trabajo adecuado —a ráfagas, dirigido por eventos, scale-to-zero—, no un valor por defecto universal.
Serverless ejecuta solo tu código, haciendo scale to zero y facturando por petición: ideal para trabajo a ráfagas dirigido por eventos. Atento a los cold starts y al lock-in; es una herramienta afilada, no un valor por defecto.
La nube es una caja de herramientas de compromisos, no una única respuesta correcta. Usarla bien es ajustar cada pieza al modelo que encaja, y mantenerse 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 trabajo pesado no diferenciador, serverless para trabajo a ráfagas dirigido por eventos, y máquinas en bruto cuando necesitas control total. La habilidad es 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.
Vigila la factura y cuidado con el lock-in
Alquilar es liberador hasta que dejas de leer los recibos, y el alquiler más cómodo es el diseñado para que nunca puedas mudarte.
Dos cosas muerden de forma consistente a los usuarios de la nube. Primero, la factura: los recursos fáciles y on-demand significan que los costes pueden trepar o dispararse sin que te des cuenta, así que monitorizas el gasto igual que monitorizas 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 marcharse. Ninguna de las dos significa evitar la nube: significan usarla con los ojos abiertos: rastrea el contador, y evita que tus piezas genuinamente críticas y portables queden permanentemente soldadas a un solo proveedor.
- Alquilar o poseer: ¿encaja mejor on-demand, pay-as-you-go que comprar hardware? - Qué modelo por pieza: IaaS, PaaS, SaaS, serverless, ¿para el control que necesitas? - ¿Escala elásticamente con la demanda, hacia arriba en los picos y hacia abajo después? - Región y zonas: cómputo cerca de los usuarios, repartido para la resiliencia? - Gestionado o autooperado: ¿es operar esta parte realmente tu valor? - La factura y el lock-in: ¿estoy monitorizando el gasto y manteniendo portables las piezas críticas?
- cloud / on-demand: alquilar los ordenadores de otra persona, disponibles en segundos. - IaaS / PaaS / SaaS: máquinas en bruto, una plataforma lista, software terminado. - elasticity / pay-as-you-go: escalar con la demanda, y facturar por lo que usas. - region / availability zone / redundancy / availability: ubicación para la velocidad y para sobrevivir al fallo. - managed service: infraestructura que el proveedor opera por ti. - serverless / scale to zero / cold start: solo tu código, on-demand, con un retardo de arranque. - vendor lock-in: el coste de estar atado a los servicios específicos de un proveedor.
- Alquilas on-demand y pagas por uso en lugar de comprar para tu hora más ocupada. - Cada pieza usa el modelo que encaja, de máquinas en bruto a serverless. - Tu sistema escala elásticamente y se ejecuta en regiones cerca de los usuarios, repartido entre zonas. - Descargas el trabajo no diferenciador en managed services y te centras en tu producto. - Monitorizas la factura y mantienes portables las piezas críticas frente al lock-in.
La nube es alquilar cómputo on-demand, en capas que van de máquinas en bruto a serverless. Úsala bien ajustando cada pieza al modelo correcto, y manteniendo un ojo en la factura y en el lock-in.