Fundamentos de la computación en la nube
Servicios de cómputo
Las opciones de cómputo reales detrás de IaaS y PaaS: cómo se dimensionan y cobran las máquinas virtuales, qué te quita de encima una plataforma de cómputo administrado, y dónde caen los contenedores y las funciones sin servidor en ese mismo espectro.
- Explicar qué significa el cómputo como recurso facturado en la nube
- Elegir una familia de máquina virtual adecuada para un perfil de carga dado
- Distinguir el escalado vertical del escalado horizontal como 2 respuestas distintas a quedarse sin capacidad
- Ubicar máquinas virtuales, cómputo administrado, contenedores y funciones sin servidor en un solo espectro de control contra comodidad
Lo que en verdad estás alquilando
El tema anterior te dijo que IaaS te entrega una máquina virtual y PaaS te entrega una plataforma que corre tu código. Ninguno de los 2 te dijo qué está pasando en realidad dentro de esa caja: cierta cantidad de CPU y memoria, sentada en un centro de datos, que rentas por hora, por segundo o por solicitud. Ese recurso es el cómputo, y cuánto obtienes, cómo viene empaquetado y cómo lo pagas son decisiones que dan forma a casi cualquier otra elección que hagas en una plataforma de nube.
Máquinas virtuales: la unidad base
Una máquina virtual sigue siendo la forma más común de vender cómputo, y los proveedores agrupan sus ofertas de máquinas virtuales en familias construidas alrededor de distintas proporciones de recursos.
| Familia | Optimizada para | Uso típico |
|---|---|---|
| Propósito general | Un balance de cómputo, memoria y redes | Servidores web, bases de datos pequeñas o medianas, entornos de desarrollo |
| Optimizada en cómputo | Procesadores de alto rendimiento, más vCPU por GB de memoria | Procesamiento por lotes, transcodificación de medios, servidores de juegos |
| Optimizada en memoria | Grandes cantidades de RAM en relación a la vCPU | Bases de datos en memoria, analítica en tiempo real |
| Optimizada en almacenamiento | Alto rendimiento de disco local de baja latencia | Bases de datos de alto rendimiento, procesamiento de datos en streaming |
| Cómputo acelerado | GPUs u otros aceleradores de hardware | Entrenamiento de machine learning, renderizado gráfico |
Un trabajo por lotes que pasa su tiempo haciendo cálculos de punto flotante y apenas toca memoria pertenece a optimizada en cómputo, no a propósito general. Una base de datos con un working set grande en memoria pertenece a optimizada en memoria. Elegir la familia equivocada no solo desperdicia dinero, puede dejar a una carga sin el único recurso que en verdad necesitaba.
Los tamaños de instancia dentro de una familia siguen un patrón de duplicación: una large sube a xlarge, que sube a 2xlarge, duplicando aproximadamente vCPUs y memoria en cada salto. En la lección de IaaS viste que una t3.micro, 2 vCPUs y 1 GiB de memoria, cuesta cerca de $7.59 al mes antes de almacenamiento. Subir un tamaño duplica aproximadamente los recursos y la factura, cambiar a otra familia en un tamaño similar cambia la proporción de recursos en su lugar.
Escalado vertical contra escalado horizontal
Digamos que esa misma aplicación empieza a fallar por timeouts bajo carga. Un vistazo rápido a sus métricas muestra la CPU clavada al 100% mientras el uso de memoria se mantiene bajo. Hay 2 formas distintas de responder, y no son intercambiables.
El escalado vertical redimensiona la instancia existente a una más grande, más vCPUs, más memoria, la misma máquina única. Es simple, pero tiene un techo, el tipo de instancia más grande de la familia, y brevemente interrumpe la instancia durante el redimensionado.
El escalado horizontal agrega más instancias del mismo tamaño y reparte la carga entre todas, típicamente detrás de un balanceador de carga. Evita ese techo y no exige tiempo fuera de servicio en las instancias existentes, pero solo funciona si la aplicación realmente puede dividir su trabajo entre varias máquinas en vez de depender de una sola.
Para la aplicación con la CPU clavada y la memoria bien del ejemplo anterior, cualquiera de los 2 movimientos resuelve el síntoma. Cuál elige un equipo real depende de si la aplicación se construyó para correr en más de una instancia a la vez, lo cual es una pregunta de diseño, no de cómputo, pero es una pregunta que las opciones de cómputo te obligan a enfrentar.
Cómputo administrado: alguien más corre la flota
Ya conociste a AWS Elastic Beanstalk, Google App Engine y productos similares como ejemplos de PaaS. Por debajo, siguen corriendo tu código sobre máquinas virtuales, la diferencia es quién aprovisiona y opera esas máquinas. Una plataforma de cómputo administrado se encarga de lanzar instancias, desplegar nuevas versiones de tu código y, en la mayoría de los casos, escalar la flota conforme cambia el tráfico. Tú sigues eligiendo tu runtime y aportando tu aplicación, dejas de escribir los scripts que de otra forma tendrían que aprovisionar y cuidar las instancias a mano.
El espectro completo de cómputo
Las máquinas virtuales y el cómputo administrado son 2 puntos en una línea más larga. Los contenedores y las funciones sin servidor están más adelante en esa línea, y este dominio le dedica una lección completa a cada uno más tarde. Por ahora, la forma del espectro completo importa más que la mecánica de cualquier parada individual en él.
| Opción | Qué administras | Arranque típico |
|---|---|---|
| Máquina virtual | Sistema operativo, runtime, escalado | Minutos |
| Cómputo administrado | Código de la aplicación y configuración | Minutos |
| Contenedor | La aplicación y sus dependencias de runtime, empaquetadas juntas | Segundos |
| Función sin servidor | Solo el código de la función | Milisegundos |
Un contenedor comparte el kernel del sistema operativo de su anfitrión en vez de correr un sistema operativo invitado completo como hace una máquina virtual, que es justo por eso que arranca en segundos en vez de minutos. Una función sin servidor, como una función de AWS Lambda, va todavía más lejos: el proveedor administra todo el entorno de ejecución, y te cobran por solicitud y por fracción de segundo que la función realmente corre, no por el tiempo inactivo entre invocaciones.
El error de concepto: "sin servidor siempre es más barato"
Es tentador asumir que pagar solo por lo que usas siempre le gana a pagar por una máquina que se queda ahí. Eso es cierto para tráfico irregular o de bajo volumen, donde una pequeña máquina virtual siempre encendida pasa la mayor parte de su tiempo inactiva y facturada de todos modos. Corre una carga a volumen alto y constante, en cambio, y la cuenta se invierte: los cargos por invocación en una función sin servidor pueden sumar más de lo que habría costado una instancia modesta siempre encendida por el mismo trabajo total. Ningún extremo del espectro es más barato en todos los casos. El patrón de tráfico decide, y por eso la comparación completa espera a su propia lección más adelante en este dominio.
Dónde te deja esto
Cada opción de cómputo en este espectro responde a la misma pregunta de fondo: cuánto del trabajo de operar y escalar quieres conservar frente a delegarle al proveedor, al costo de cuánto control. Las máquinas virtuales conservan lo máximo en tus manos, las funciones sin servidor conservan lo mínimo. La siguiente lección deja atrás el cómputo y cubre qué pasa con los datos que esos recursos de cómputo leen y escriben: almacenamiento.