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, creciendo y reduciéndote 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.
19 conceptos · un diagrama para cada uno · hoja de referencia al final
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.
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.
- 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.
- 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.
- 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 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.
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.
- 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.
- 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.
- 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é.
- 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.
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.
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.
- 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.
- 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.
- 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.
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.
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.
- 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.
- 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».
- 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).
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.
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.
- 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.
- 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.
- 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.
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.
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.
- 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.
- 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.
- 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.
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.
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.
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.
- 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?
- 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 Computingla nube, the cloud
Alquilar por internet los ordenadores de otra persona en lugar de comprar los tuyos.
- CapEx → OpExalquilar en lugar de comprar
Una enorme compra inicial de hardware se convierte en una factura pay-as-you-go.
- On-demandautoservicio, self-service
Arrancar o detener un recurso tú mismo, en segundos.
Modelos de servicio
- Cloud Service Modelspizza as a service
La escala de cuántas capas gestiona el proveedor y cuántas gestionas tú.
- IaaSInfrastructure as a Service
Máquinas virtuales, discos y red en bruto; todo lo de encima es tuyo.
- PaaSPlatform as a Service
Una plataforma lista: tú traes el código, el proveedor gestiona los servidores.
- SaaSSoftware as a Service
Software terminado; gestionas solo tus datos y ajustes.
Elasticity y dinero
- Elasticityautoscaling
La capacidad crece para un pico y se reduce después.
- Pay-as-you-gofacturación por uso, usage-based billing
Pagas por el cómputo, el almacenamiento y el tráfico que realmente consumes.
- Bill Shockfactura sorpresa, surprise bill
Una factura inesperadamente enorme cuando algo se descontrola. Se cura vigilando el gasto.
Dónde se ejecuta
- Regionlatencia, latency
Centros de datos en una parte del mundo; más cerca de los usuarios significa menos latencia.
- Availability ZoneAZ
Un centro de datos separado dentro de una región; las copias entre zonas sobreviven a un fallo.
- High Availabilityredundancia, redundancy
Sin punto único de fallo: el sistema sigue en pie ante fallos.
Managed services
- Managed ServiceBD, cola, caché gestionadas
Una base de datos, cola o caché que el proveedor gestiona por ti.
- Undifferentiated Heavy Liftingoperaciones que no te diferencian
Operaciones duras que no hacen especial a tu producto: conviene cederlas.
- Vendor Lock-independencia del proveedor, provider lock-in
Cuanto más metido estás en los servicios de un proveedor, más caro es irse.
Serverless
- ServerlessFaaS
Solo tu código; el proveedor lo ejecuta en cada evento.
- Scale to Zerofacturación por petición, per-request billing
Sin peticiones no se ejecuta nada y no se factura nada.
- Cold Startretraso 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.