Opciones de cómputo en la nube

Una máquina virtual (VM) es una computadora definida por software. Tiene procesadores virtuales, memoria, discos, una conexión de red y su propio sistema operativo. Un hipervisor divide un servidor físico entre máquinas virtuales y las mantiene aisladas. Una máquina virtual en la nube en ejecución también se llama instancia.

Elige los recursos

Los servicios principales son Amazon EC2, Azure Virtual Machines y Google Compute Engine. Cada uno te alquila infraestructura; tú administras el sistema operativo y la aplicación. Esto es infraestructura como servicio (IaaS).

Iniciar una máquina virtual implica varias elecciones relacionadas:

• Ubicación: una región y, donde se ofrezca, una zona de disponibilidad.
• Imagen: una plantilla que contiene el sistema operativo y el software preinstalado. AWS la llama Amazon Machine Image (AMI); Azure y Google ofrecen imágenes públicas y personalizadas.
• Tamaño: las vCPU, la memoria y la capacidad relacionada. Una vCPU es la unidad de procesamiento asignada a la máquina virtual.
• Disco: almacenamiento persistente desde el que arranca el sistema operativo.
• Red: una interfaz en una subred, más reglas de tráfico. Una dirección IP pública es opcional.

AWS usa volúmenes EBS, subredes VPC y grupos de seguridad. Azure usa discos administrados, subredes VNet y grupos de seguridad de red. Google usa discos persistentes, subredes VPC y reglas de cortafuegos. Los nombres son distintos, pero los recursos cumplen funciones comparables.

Sigue una decisión de inicio

Un equipo necesita un servidor web Linux en Fráncfort. Selecciona la región Europe (Frankfurt), una AMI de Ubuntu y m7g.large, con 2 vCPU y 8 GiB de memoria. Añade un volumen de arranque EBS de 30 GiB y conecta la máquina virtual a una subred VPC. Su grupo de seguridad permite HTTPS por el puerto 443 desde internet y SSH por el puerto 22 solo desde la red de la oficina. La imagen proporciona el punto de partida del software; el tamaño proporciona capacidad de cómputo; las reglas de tráfico deciden quién puede conectarse.

Sigue el ciclo de vida y la facturación

Una máquina virtual se crea, se ejecuta, puede detenerse y volver a iniciarse y, finalmente, se elimina. Los cargos de cómputo se acumulan mientras está asignada para ejecutarse, incluso si el uso de CPU es cercano a cero. Detenerla normalmente acaba con los cargos de cómputo, pero los discos conservados y las direcciones IP públicas reservadas aún pueden costar dinero. En Azure, comprueba que aparezca «Stopped (deallocated)»: apagar desde el sistema operativo invitado puede dejar la máquina virtual en «Stopped», con el cómputo aún facturado.

Los discos locales temporales son distintos de los discos de arranque persistentes. AWS instance store, los discos temporales de Azure y Google Local SSD guardan datos en el host físico; detener, trasladar o desasignar una máquina virtual puede hacer que se pierdan. Guarda los archivos que deben perdurar en almacenamiento persistente. Después de eliminar una máquina virtual, revisa los recursos facturables conservados. Un grupo de seguridad por sí solo no tiene un cargo independiente, mientras que un disco que no se elimina puede seguir generándolo.

Conoce quién se encarga del mantenimiento

El proveedor mantiene el centro de datos, el hardware físico y el hipervisor. Tú aplicas parches al sistema operativo invitado, actualizas el software instalado, proteges los datos y administras el acceso y la configuración del cortafuegos. Alquilar una máquina virtual no transfiere al proveedor la aplicación de parches al sistema invitado.

Un host dedicado reserva un servidor físico para tu uso, lo que resulta útil para licencias vinculadas a núcleos físicos. Una instancia de servidor físico expone el hardware sin una capa de hipervisor. En cambio, Azure Virtual Desktop y Amazon WorkSpaces transmiten escritorios alojados en la nube a los dispositivos de los usuarios.

La familia de una instancia establece el equilibrio entre procesamiento, memoria, almacenamiento y aceleradores. Su tamaño determina cuántos de esos recursos obtienes. Elige la familia según la necesidad principal de la carga de trabajo y después un tamaño que cumpla todos sus requisitos.

Reconoce las principales familias

El almacenamiento local rápido no hace que los datos sean persistentes. Una carga de trabajo que usa instancias optimizadas para almacenamiento sigue necesitando un plan para los datos que deben sobrevivir a la pérdida del host.

Interpreta el nombre

En m7g.large, m significa propósito general, 7 es la generación, g indica AWS Graviton y large es el tamaño. La misma familia pasa de 2 vCPU y 8 GiB en large a 4 vCPU y 16 GiB en xlarge, y después a 8 vCPU y 32 GiB en 2xlarge.

En Standard_D4s_v5 de Azure, D es la familia, 4 es el número de vCPU, s indica compatibilidad con SSD premium y v5 es la versión. e2-standard-4 de Google indica la serie E2, la proporción de memoria estándar y 4 vCPU. Una vCPU suele ser un hilo de hardware; en Graviton es un núcleo completo. No consideres que la vCPU de cada proveedor equivale a un núcleo físico idéntico.

Resuelve una elección de tamaño

Una aplicación interna de informes necesita 2 vCPU y 6 GiB en el momento de mayor actividad. Compara estos tamaños de AWS:

• c7g.large: 2 vCPU y 4 GiB; la memoria es insuficiente.
• m7g.large: 2 vCPU y 8 GiB; cumple ambos requisitos y deja 2 GiB de margen.
• r7g.large: 2 vCPU y 16 GiB; proporciona mucha más memoria de la que necesita esta aplicación.

El tamaño de propósito general es un punto de partida razonable. Su memoria por vCPU es $8÷2=4$ GiB. Las opciones optimizada para cómputo y optimizada para memoria proporcionan 2 y 8 GiB por vCPU, respectivamente. Los tipos E2 highcpu, standard y highmem de Google con 4 vCPU varían de forma similar en memoria: 4 GB, 16 GB y 32 GB.

El dimensionamiento adecuado consiste en medir el uso real y ajustar la elección. Examina el uso de memoria, disco y red junto con el de CPU antes de reducir el tamaño. AWS Compute Optimizer, Azure Advisor y las recomendaciones de tipos de máquina de Google pueden ayudar. Cambiar el tamaño de una máquina virtual existente requiere detenerla o reiniciarla, así que planifica la interrupción de una aplicación con un solo servidor.

Distingue las ráfagas de las interrupciones

Los tipos de rendimiento ampliable por ráfagas AWS T, Azure B y Google E2 de núcleo compartido son adecuados para cargas de trabajo con poca actividad y picos breves. AWS T y Azure B acumulan créditos de CPU por debajo de un nivel de referencia y los gastan por encima de él. Cuando se agotan los créditos, Azure B y AWS T en modo estándar vuelven al nivel de referencia; los tipos AWS T actuales usan por defecto el modo ilimitado y pueden cobrar por la CPU excedente.

Las máquinas virtuales de capacidad interrumpible usan capacidad sobrante que el proveedor puede recuperar con poco aviso. Son adecuadas para trabajos por lotes reiniciables con el progreso guardado. Una única base de datos de producción es una mala opción. Las antiguas máquinas virtuales interrumpibles de Google también tienen una duración máxima de 24 horas; ese límite no es la regla que define las máquinas virtuales Spot actuales.

Un servicio se enfrenta a dos problemas distintos: la llegada de más trabajo y los fallos de los equipos. El escalado cambia la capacidad. La alta disponibilidad mantiene el servicio utilizable cuando fallan componentes. Un diseño puede resolver un problema y dejar el otro sin resolver.

Cambia el tamaño o el número

El escalado vertical cambia el tamaño de una máquina: por ejemplo, 2 vCPU y 8 GiB pasan a ser 8 vCPU y 32 GiB. Escalar hacia arriba añade recursos; escalar hacia abajo los elimina. Es una forma directa de dar más capacidad a una aplicación existente, pero normalmente hay que reiniciar la máquina, el tamaño máximo es limitado y la máquina sigue siendo un punto de fallo.

El escalado horizontal cambia el número de copias. Tres servidores web pueden pasar a ser nueve y después volver a tres. Aumentar el número añade instancias; reducirlo las elimina. Un equilibrador de carga comparte las solicitudes web, mientras que los trabajadores en segundo plano pueden tomar tareas de una cola compartida. La aplicación debe admitir varias copias que realicen trabajo útil conjuntamente. Una base de datos compartida aún puede limitar la tasa de transferencia o fallar aunque muchos servidores web sigan en buen estado.

La escalabilidad es la capacidad de gestionar más trabajo añadiendo recursos. La elasticidad es el crecimiento y la reducción automáticos y oportunos a medida que cambia la demanda. Una tienda que pasa automáticamente de 4 servidores por la noche a 20 durante una promoción es elástica. Un conjunto fijo de servidores con capacidad de reserva puede tener alta disponibilidad sin ser elástico.

Haz que las copias sean reemplazables

Una instancia de aplicación sin estado no conserva datos únicos que necesite una solicitud posterior. Guarda carritos, sesiones y archivos cargados en una base de datos, una caché o un servicio de almacenamiento compartidos. Así, una solicitud puede llegar a cualquier instancia y la reducción del número de instancias puede eliminar una sin perder los carritos de sus usuarios.

Por ejemplo, un carrito guardado solo en la memoria de un servidor web desaparece cuando ese servidor se termina. Mantener al usuario en ese servidor mediante afinidad de sesión no protege el carrito frente al fallo del servidor. Trasladar el carrito a un almacenamiento compartido cambia lo que puede eliminarse de forma segura.

Mantén suficiente capacidad tras el fallo de una zona

Las zonas de disponibilidad son ubicaciones separadas dentro de una región con alimentación eléctrica, refrigeración y redes independientes. Distribuir instancias entre zonas protege frente al fallo de una zona completa. Varias instancias en una sola zona siguen compartiendo el riesgo de esa zona.

Supón que una aplicación debe conservar la capacidad de 4 instancias después de perder cualquiera de 3 zonas. Cada una de las dos zonas restantes debe proporcionar 2 instancias:

Ejecuta 2 instancias en cada zona, 6 en total. Si se pierde cualquier zona, quedan 4. Esta es capacidad de reserva para un fallo, no un aumento del requisito normal de la carga de trabajo. Un equilibrador de carga dirige las solicitudes a las instancias restantes; cualquier servicio de datos compartido también necesita una disponibilidad adecuada.

Reconoce los conjuntos de disponibilidad de Azure

Un conjunto de disponibilidad distribuye máquinas virtuales dentro de un centro de datos entre dominios de fallo de hardware y dominios de actualización para mantenimiento. Un dominio de fallo comparte hardware como la alimentación eléctrica y los conmutadores de red. Los conjuntos admiten hasta 3 dominios de fallo; los dominios de actualización son 5 por defecto y pueden llegar a 20. Reducen los riesgos de fallos de racks y reinicios programados. Las zonas abordan el riesgo mayor de que toda una ubicación de centro de datos deje de estar disponible.

El escalado automático añade y elimina instancias a medida que cambia la demanda. Amazon EC2 Auto Scaling usa grupos de Auto Scaling, Azure usa Virtual Machine Scale Sets con reglas de escalado automático y Google usa grupos de instancias administradas con un escalador automático.

Parte de una plantilla repetible

Una instancia nueva necesita la misma imagen, tamaño, configuración de red e instrucciones de inicio que las demás. AWS usa una plantilla de lanzamiento, Azure un modelo de VM del conjunto de escalado y Google una plantilla de instancia. Un cambio hecho a mano dentro de una máquina virtual en ejecución desaparecerá cuando se sustituya, salvo que se incluya en la configuración repetible.

El grupo tiene tres ajustes de capacidad:

• Mínima: el límite inferior que mantiene el grupo.
• Deseada: el número de instancias que busca ejecutar en ese momento.
• Máxima: el límite superior que no debe superar.

Con un mínimo de 2, un deseado de 4 y un máximo de 10, el grupo busca mantener 4 instancias. Las políticas pueden cambiar la capacidad deseada entre 2 y 10. El máximo permite crecer; establecerlo en 10 no ejecuta ni factura por sí mismo 10 máquinas virtuales. Limita el número de instancias, no todos los cargos de la aplicación.

Elige qué provoca un cambio

El seguimiento de objetivos intenta mantener una métrica cerca de un objetivo, como un uso medio de CPU del 50 %. El escalado por pasos o basado en reglas cambia la capacidad cuando se cruza un umbral, por ejemplo, añadiendo 2 instancias después de que la CPU permanezca por encima del 70 % durante 5 minutos. El escalado programado establece la capacidad a horas conocidas. El escalado predictivo pronostica la demanda a partir de patrones anteriores y prepara la capacidad por adelantado.

Un pico diario a las 08:00 favorece preparar las instancias antes de las 08:00. Si se espera a una alarma de CPU alta, el pico ya habrá llegado mientras las máquinas virtuales adicionales aún están arrancando.

Calcula la capacidad para el seguimiento de objetivos

Cuatro instancias idénticas tienen una media de CPU del 80 % y el objetivo es el 50 %. Para una estimación simplificada con carga constante, suma primero el trabajo en unidades de porcentaje por instancia:

Divide por el objetivo por instancia:

Redondea hacia arriba a 7 instancias porque con 6 la media quedaría por encima del objetivo. Con 7, la estimación es $320÷7\approx \mathrm{45,7}\mathrm{\%}$. Si el máximo del grupo es 6, se detiene ahí y alcanza una media de aproximadamente el 53,3 %.

Distingue la preparación de la recuperación de fallos

Una máquina virtual necesita tiempo para arrancar, ejecutar sus tareas de inicio y superar las comprobaciones de estado. El calentamiento evita que las mediciones incompletas de una instancia nueva distorsionen una decisión de escalado. Un período de estabilización limita los cambios rápidos de un lado a otro.

Los grupos de escalado también pueden sustituir máquinas virtuales que han fallado para recuperar la capacidad deseada. Las comprobaciones y las acciones de reparación a nivel de aplicación requieren configuración: una máquina virtual puede estar en ejecución mientras su aplicación web falla. En Azure, una acción de reparación puede reiniciar, volver a crear a partir de una imagen o sustituir; Google llama autohealing a la recuperación. Un equilibrador de carga puede detectar una aplicación que falla, pero el grupo de escalado debe estar configurado para usar esa información en la reparación.

Reducir el número de instancias implica eliminarlas. Guarda los registros de forma centralizada y los datos duraderos fuera de sus archivos locales para que eliminar una copia en buen estado no elimine información única.

Un equilibrador de carga proporciona a los clientes una dirección de entrada y envía el tráfico entrante a servidores en buen estado. AWS llama target group al conjunto de servidores; Azure usa backend pool; Google usa backend service. Los clientes no necesitan una dirección nueva cada vez que cambia el conjunto.

Enruta el tráfico y detecta fallos

Una comprobación de estado verifica repetidamente un destino, por ejemplo, solicitando /health cada 10 segundos. Tras suficientes comprobaciones fallidas, el destino se marca como en mal estado y no recibe tráfico nuevo hasta que vuelve a superarlas. La detección lleva tiempo porque las comprobaciones se ejecutan a intervalos.

El enrutamiento y la reparación son tareas distintas. El equilibrador de carga deja de enviar solicitudes nuevas a un destino que ha fallado. Un grupo de escalado o un operador repara o sustituye ese servidor. Añadir solo un equilibrador de carga no añade capacidad de procesamiento a la aplicación.

La distribución por turnos toma los destinos en buen estado por orden. El método de menos conexiones o menos solicitudes pendientes favorece el destino con menos trabajo en curso. El enrutamiento basado en hash asigna un destino a partir de los datos de la conexión, incluidas direcciones y puertos. Una conexión permanece unida, pero una conexión nueva del mismo usuario puede llegar a otro destino.

La afinidad de sesión mantiene las solicitudes de un usuario en un servidor. Puede dar soporte a una aplicación con sesiones locales, pero hace que el tráfico sea menos uniforme y deja las sesiones expuestas al fallo de ese servidor. El almacenamiento compartido de sesiones permite que otros servidores en buen estado continúen el trabajo del usuario.

Calcula el efecto de perder un servidor

Tres servidores en buen estado comparten 900 solicitudes por minuto de forma equitativa. Cada uno gestiona:

Un servidor falla las comprobaciones de estado. El mismo trabajo pasa ahora a dos:

Si cada uno solo puede gestionar 400 solicitudes por minuto, el enrutamiento a servidores en buen estado sigue dejando una sobrecarga. El conjunto necesita capacidad de reserva o más instancias. El escalado automático cambia la capacidad; el equilibrio de carga la distribuye.

Elige la capa adecuada para el enrutamiento

Un servicio de capa 7 también puede terminar TLS, descifrando HTTPS en el punto de entrada, y puede trabajar con un cortafuegos de aplicaciones web. Un servicio de capa 4 no inspecciona una ruta HTTP para elegir su destino. Comprueba qué protocolos de transporte admite cada producto.

AWS Elastic Load Balancing ofrece Application Load Balancers en la capa 7, Network Load Balancers en la capa 4 y Gateway Load Balancers para dispositivos de red, dentro de una región. Azure Load Balancer es de capa 4; Application Gateway es regional de capa 7; Front Door proporciona un punto de entrada global de capa 7. Google Cloud Load Balancing ofrece Application y Network Load Balancers en modalidades regionales y globales.

Combina el enrutamiento con el escalado

Con la integración configurada, las nuevas instancias del grupo se registran como destinos y reciben tráfico cuando están en buen estado. Durante la eliminación, el drenaje de conexiones permite que las solicitudes activas terminen antes de que desaparezca un destino. Una implementación en varias zonas enruta hacia las zonas en buen estado durante una interrupción, siempre que las restantes tengan suficiente capacidad. Incluso dos servidores se benefician de este punto de entrada compartido y del enrutamiento basado en el estado.

Un contenedor ejecuta una aplicación y sus dependencias como un proceso aislado en un host. Empaquetar sus bibliotecas y su entorno de ejecución permite reproducir en producción el software probado.

Imagen, registro y copia en ejecución

Una imagen es la plantilla de solo lectura; un registro almacena y distribuye imágenes; un contenedor es una copia en ejecución. Amazon ECR, Azure Container Registry y Google Artifact Registry proporcionan registros. La Open Container Initiative define formatos de imagen estándar; Docker ayudó a popularizar su uso.

Por ejemplo, un equipo empaqueta su API de pedidos en Python como orders-api:1.4, la prueba, la envía a un registro e inicia 3 contenedores de producción a partir de esa imagen. Los ajustes del entorno y el acceso a servicios externos aún requieren configuración.

Comparte un núcleo en vez de arrancar un sistema operativo invitado

Cada máquina virtual lleva un sistema operativo invitado completo detrás de un hipervisor. Los contenedores comparten el núcleo del host, la parte central del sistema operativo que administra recursos y procesos. Tienen menos software que transportar e iniciar: las imágenes suelen ocupar decenas o cientos de megabytes y el arranque tarda segundos o menos. Las imágenes de máquinas virtuales suelen ocupar gigabytes y arrancan en minutos. Por tanto, un host puede ejecutar más contenedores que máquinas virtuales completas.

Compartir también afecta al aislamiento. Un fallo en el núcleo del host puede afectar a varios contenedores, mientras que los núcleos invitados separados proporcionan a las máquinas virtuales una frontera más sólida. Los contenedores Linux necesitan un núcleo Linux; los contenedores Windows necesitan Windows. La imagen también debe coincidir con la arquitectura del procesador, como x86 o Arm. Los contenedores suelen ejecutarse en máquinas virtuales en la nube.

Sustituye el software y conserva los datos

Actualiza un contenedor creando una imagen corregida y sustituyendo las copias antiguas. Un parche aplicado a mano desaparece al sustituir el contenedor y deja las demás réplicas sin cambios.

Lo mismo ocurre con los archivos creados durante la ejecución en la capa de escritura. Una factura generada allí debe guardarse en un volumen persistente o un servicio de almacenamiento antes de la sustitución. El registro de imágenes conserva paquetes de aplicaciones, no documentos creados por contenedores en ejecución.

Separa los servicios cuando sea útil

Una aplicación monolítica se implementa como una sola unidad. Los microservicios dividen una aplicación en servicios conectados por red que se implementan y escalan por separado. Una tienda puede añadir contenedores del servicio de pagos sin añadir copias del servicio de catálogo.

Un orquestador ubica contenedores entre hosts, reinicia copias que han fallado, las escala, implementa versiones y conecta servicios. Kubernetes lo hace, al igual que servicios administrados de contenedores más sencillos. Los contenedores no requieren Kubernetes.

Kubernetes implementa y administra contenedores en un grupo de máquinas llamado clúster. Es de código abierto, se originó en Google y se mantiene dentro de la Cloud Native Computing Foundation. La misma plataforma puede funcionar en distintas nubes y centros de datos privados.

Comprende las partes del clúster

El plano de control almacena la configuración, programa el trabajo y coordina el clúster. Los nodos de trabajo, normalmente máquinas virtuales, proporcionan el procesamiento y la memoria que consumen los contenedores.

Un pod es la unidad más pequeña que programa Kubernetes. Contiene uno o más contenedores que comparten una dirección de red y permanecen juntos en un nodo. Un pod no es una máquina virtual independiente. Varios pods pueden compartir el mismo nodo de trabajo si sus necesidades de recursos lo permiten.

Declaras un estado deseado: por ejemplo, 3 réplicas de orders-api:1.4. Kubernetes trabaja para mantener 3 pods en ejecución. Cuando falla un pod, crea uno de reemplazo; si falla un nodo, los pods de reemplazo pueden ejecutarse en los nodos restantes con capacidad disponible. Un servicio de Kubernetes proporciona un nombre y una dirección estables para acceder a los pods incluso cuando cambian sus direcciones individuales.

Escala los pods y las máquinas por separado

Un escalador automático horizontal de pods (HPA) cambia el número de pods mediante métricas como la demanda de CPU. Un escalador automático de clústeres cambia la capacidad de los nodos cuando los pods no caben o los nodos dejan de ser necesarios. Añadir pods sin espacio para ejecutarlos crea trabajo pendiente, no más capacidad de procesamiento.

Supón que cada pod solicita 0,5 vCPU y cada nodo tiene 2 vCPU disponibles para pods. En este ejemplo, ignora los demás límites de recursos. Un nodo puede alojar:

Si el HPA aumenta el número deseado a 10 pods, dos nodos solo alojan 8. El requisito es:

Redondea hacia arriba a 3 nodos. El tercer nodo proporciona espacio para los 2 últimos pods. Usa la capacidad disponible para pods, porque el sistema operativo del nodo y los componentes de Kubernetes también necesitan recursos. En la programación real, la memoria y las reglas de ubicación importan junto con la CPU.

Reparte las responsabilidades de administración

Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE) ejecutan planos de control administrados. El proveedor mantiene ese plano de control, incluidas su disponibilidad y sus actualizaciones. Tú administras las imágenes, los ajustes de la aplicación, el acceso y las solicitudes de recursos de las cargas de trabajo. En muchas modalidades también administras las opciones y las actualizaciones de los nodos de trabajo. Las tarifas del clúster pueden cobrarse por separado de los cargos de los nodos.

GKE Standard deja en tus manos la elección de los nodos y factura las máquinas virtuales de los nodos. GKE Autopilot aprovisiona y administra los nodos y, por lo general, cobra por los recursos solicitados por los pods. EKS puede ejecutar pods aptos en AWS Fargate para que no tengas que administrar las máquinas virtuales de los nodos. Estas modalidades reducen el trabajo operativo, aunque limitan algunas opciones del host.

Decide si la complejidad ayuda

Kubernetes es adecuado para muchos servicios implementados de forma independiente y para equipos que necesitan una plataforma común entre proveedores. Sus herramientas y definiciones de cargas de trabajo mejoran la portabilidad, aunque las bases de datos en la nube, los sistemas de identidad y las redes conectados aún pueden requerir cambios.

Para una aplicación web sencilla, una plataforma de alojamiento o un servicio de contenedores sin servidor puede requerir menos trabajo. Kubernetes administrado no corrige un error en tu imagen ni elige por ti la solicitud de memoria adecuada. Si una aplicación se queda sin memoria repetidamente, el equipo debe diagnosticar la aplicación y sus ajustes incluso cuando el plano de control está totalmente administrado.

Los servicios de contenedores sin servidor ejecutan tus imágenes en hosts administrados por el proveedor. Tú sigues eligiendo los recursos, manteniendo la imagen y configurando la aplicación. El escalado y la facturación dependen del servicio.

Separa la orquestación del cómputo

Amazon ECS orquesta contenedores como tareas. Un servicio de ECS mantiene un número deseado de tareas, opcionalmente detrás de un equilibrador de carga. Las tareas se ejecutan en hosts EC2 que tú administras o en cómputo de Fargate.

Fargate también admite pods aptos de EKS. Eliges las vCPU y la memoria de la tarea o del pod y pagas mientras esos recursos se ejecutan; no eliges, parcheas ni escalas los hosts EC2 subyacentes. El escalado automático del servicio de ECS usa políticas que tú configuras. Fargate proporciona cómputo, pero no determina el número deseado de tareas de la aplicación. ECS en EC2 conserva más control sobre el host y la familia de instancias, con más trabajo de administración.

Compara los servicios de Azure y Google

Azure Container Instances (ACI) inicia un contenedor o un grupo pequeño sin clúster y factura por segundo. Es adecuado para pruebas y tareas sencillas de duración limitada, pero no tiene escalado automático integrado.

Azure Container Apps oculta su plataforma de Kubernetes subyacente. Las reglas configuradas escalan aplicaciones en contenedores según el tráfico HTTP o los eventos, incluso hasta cero para cargas de trabajo adecuadas.

Google Cloud Run ofrece servicios para solicitudes entrantes y trabajos que se ejecutan hasta completarse. Los servicios pueden crecer desde cero y volver a reducirse. La facturación de cómputo basada en solicitudes cubre el procesamiento de solicitudes más el arranque y el apagado. Sin instancias mínimas ni instancias en ejecución, el cómputo inactivo no cuesta nada; las bases de datos y las imágenes almacenadas aún pueden generar cargos. Cloud Run también aloja Cloud Run functions, que parten del código de una función en vez de una imagen de aplicación proporcionada por el cliente.

Equilibra el ahorro durante la inactividad y la demora de arranque

Una API interna de reservas tiene mucha actividad de 08:00 a 18:00 los días laborables: 10 horas durante 5 días, o 50 de las 168 horas de la semana. También llegan solicitudes ocasionales por la noche. Cloud Run o Container Apps pueden ejecutar varias copias en el pico y llegar a cero entre solicitudes durante los períodos de poca actividad.

Una solicitud después de un período de inactividad puede esperar por un arranque en frío. Mantener preparada una instancia como mínimo reduce la demora dentro de su capacidad y añade un costo continuo. Una ráfaga que supere esa capacidad aún puede iniciar instancias adicionales en frío.

Elige el control del host que necesitas

Estos servicios restringen el acceso al host e imponen límites de recursos y duración. No puedes instalar agentes en el host ni cambiar su núcleo. Las máquinas virtuales o los nodos adecuados de Kubernetes cubren esas necesidades. Para API estándar en contenedores, los servicios más sencillos pueden evitar el trabajo de operar Kubernetes; ACI es una opción directa para un grupo sencillo de contenedores.

Una función sin servidor es código que se ejecuta cuando llega un evento correspondiente. El proveedor administra los servidores y el entorno de ejecución administrado. AWS Lambda, Azure Functions y Google Cloud Run functions ofrecen este modelo de función como servicio (FaaS).

Conecta un desencadenante con una invocación

Un desencadenante inicia una ejecución, llamada invocación. Entre los desencadenantes están las solicitudes HTTP, los archivos cargados, los mensajes de cola, los cambios en bases de datos y los temporizadores. La carga de una foto puede desencadenar una función que crea una miniatura de 200 píxeles y la guarda en el almacenamiento. Si no hay cargas, una implementación bajo demanda puede no tener cómputo de funciones en ejecución.

El proveedor escala la ejecución a medida que llegan eventos, dentro de los límites de concurrencia y del servicio. Muchas funciones simultáneas pueden abrir muchas conexiones a una base de datos. La capa de funciones puede tener margen para escalar incluso cuando la base de datos no lo tiene. Limita la concurrencia a lo que puedan gestionar los sistemas conectados.

Las funciones son sin estado entre invocaciones. Una invocación posterior puede usar un entorno nuevo, por lo que no puede depender de la memoria ni de los archivos temporales de una llamada anterior. Guarda contadores, sesiones y resultados duraderos en una base de datos, una caché o el almacenamiento de objetos. Un entorno preparado puede reutilizarse, pero esa reutilización no garantiza la persistencia.

Calcula el uso en un modelo basado en el consumo

La facturación estándar bajo demanda de Lambda combina el número de invocaciones y los gigabyte-segundos (GB·s): la memoria asignada en GB multiplicada por los segundos de ejecución. Para un cálculo ilustrativo, supón que cada una de 3 000 000 de invocaciones se ejecuta durante 0,2 segundos con 0,5 GB de memoria. Ignora las cuotas gratuitas y todos los demás servicios.

Con precios supuestos de 0,0000167 u.m. por GB·s y 0,20 u.m. por millón de solicitudes, el cómputo cuesta 5,01 u.m. y las solicitudes cuestan 0,60 u.m., un total de 5,61 u.m.. Estos precios son supuestos para aprender el modelo. Cloud Run functions también mide la CPU; los planes de Azure pueden cobrar por instancias preparadas o asignadas.

Con 100 000 000 de invocaciones por lo demás idénticas, el uso es de 10 000 000 GB·s: 167 u.m. por cómputo más 20 u.m. por solicitudes a esas tarifas supuestas. Una máquina virtual con un precio supuesto de 0,04 u.m. por hora cuesta 29,20 u.m. por 730 horas, pero una comparación justa también comprueba si puede procesar el mismo trabajo e incluye su esfuerzo operativo. Una demanda con picos favorece evitar capacidad inactiva; una carga constante puede favorecer el cómputo siempre activo.

Comprueba los límites de ejecución y la demora de arranque

El cómputo predeterminado de Lambda permite un máximo de 15 minutos por invocación y hasta 10 240 MB de memoria. Una conversión de 40 minutos no cabe en esa invocación. Pueden servir un trabajo en contenedor, una máquina virtual o pasos más cortos; las reglas de tiempo máximo difieren para otros planes y modalidades de cómputo.

Un arranque en frío ocurre cuando debe prepararse un nuevo entorno de ejecución, después de un período de inactividad o durante un aumento del número de instancias. Los entornos preparados que se reutilizan arrancan más rápido. La concurrencia aprovisionada de Lambda, las instancias siempre preparadas de Azure Premium o Flex Consumption y las instancias mínimas de Cloud Run reducen las demoras de arranque a un costo adicional.

El proveedor mantiene los servidores y el entorno de ejecución administrado. Tú sigues corrigiendo tu código y las bibliotecas incluidas, protegiendo los secretos, configurando los permisos y asegurando los datos. La computación sin servidor elimina la administración de servidores, pero no la responsabilidad sobre la aplicación.

Una plataforma de alojamiento de aplicaciones toma tu código o imagen de contenedor y proporciona la infraestructura para ejecutarlo. Es plataforma como servicio (PaaS): la implementación, la supervisión del estado, la operación de servidores y el escalado se proporcionan mediante la plataforma, mientras tú creas la aplicación.

Compara las principales plataformas

AWS Elastic Beanstalk crea recursos habituales de AWS para tu aplicación, normalmente instancias EC2 en un grupo de Auto Scaling detrás de un Elastic Load Balancer. Se encarga de las implementaciones y de la supervisión del estado. Beanstalk en sí no tiene una tarifa de servicio adicional; pagas por los recursos que crea. Esos recursos siguen visibles en tu cuenta y puedes personalizar su configuración.

Azure App Service aloja aplicaciones web, API y componentes de servidor para aplicaciones móviles a partir de código o contenedores. Un plan de App Service establece la región, el tamaño de instancia y el número de instancias. Las aplicaciones del plan comparten esas instancias. Los niveles dedicados facturan por el plan incluso cuando las aplicaciones tienen poca actividad. Las funciones como el escalado automático y las ranuras de implementación dependen del nivel elegido.

Google App Engine tiene entornos estándar y flexible. El estándar usa entornos de ejecución compatibles en un entorno aislado y puede escalar a cero con el escalado automático adecuado. El flexible ejecuta contenedores en máquinas virtuales de Compute Engine, permite más personalización y mantiene al menos una instancia en ejecución. Cloud Run es otra opción para alojar una aplicación ya empaquetada en un contenedor.

Publica una nueva versión de forma segura

Un equipo de dos personas de una tienda usa un nivel de App Service con ranuras de implementación. Ejecuta 2 instancias e implementa una nueva versión en una ranura de preproducción, un lugar separado para probar la versión antes de que la usen los clientes. Después de probarla, intercambia preproducción y producción. La versión anterior permanece disponible en la otra ranura para una posible reversión.

Durante una promoción, la regla de escalado automático configurada aumenta el plan a 5 instancias después de que la CPU media permanezca por encima del 70 % y vuelve a 2 cuando disminuye la demanda. La plataforma realiza el escalado, pero el equipo sigue eligiendo el plan, las reglas y los límites. Nunca instala el sistema operativo del host ni el servidor web.

Conserva las responsabilidades adecuadas

En todas las plataformas mantienes el código, las bibliotecas incluidas, los ajustes, los secretos, los datos y el acceso. App Service y App Engine mantienen el sistema operativo del host y el entorno de ejecución administrado. Beanstalk permite una mayor personalización de EC2; AWS publica actualizaciones de plataforma y tú las aplicas o habilitas las actualizaciones administradas de la plataforma. El software adicional que instalas también necesita atención.

Una plataforma es distinta del SaaS. Con PaaS implementas la aplicación que creas; con SaaS usas una aplicación terminada de otra persona, como una suite de correo electrónico. Los ajustes específicos de la plataforma y las integraciones con servicios también pueden dificultar una migración posterior a otro proveedor.

Cubre necesidades de alojamiento más sencillas

Amazon Lightsail agrupa un servidor privado virtual, almacenamiento y transferencia de datos en un paquete mensual previsible. Es adecuado para sitios web pequeños, pero sigue implicando responsabilidades sobre la máquina virtual. Un sitio estático consta de archivos como HTML, CSS, JavaScript e imágenes. AWS Amplify Hosting, Azure Static Web Apps y Firebase Hosting pueden servir esos archivos globalmente sin que tengas que mantener un servidor web. Una aplicación que requiere control completo del sistema operativo del host debe ejecutarse en máquinas virtuales.

Compara los modelos de cómputo para una misma carga de trabajo. Comprueba el control, el esfuerzo operativo, el arranque, la facturación, los límites y la portabilidad.

¿Quién mantiene cada parte?

Los datos y el acceso siguen siendo responsabilidad del cliente en todos los casos. Elastic Beanstalk también requiere elegir cómo se aplican las actualizaciones de la plataforma.

Compara el tráfico y la capacidad utilizable

Una máquina virtual suele necesitar un minuto o más para arrancar y superar las comprobaciones; un contenedor suele arrancar en segundos; una función con el entorno preparado puede empezar a trabajar en milisegundos. Un entorno nuevo puede añadir una demora de arranque en frío. La capacidad preparada reduce esa demora a un costo continuo.

Un directorio con poca actividad durante la noche puede beneficiarse del escalado a cero; una demanda constante puede favorecer el cómputo asignado. Compara una tasa de transferencia, memoria y concurrencia equivalentes antes de comparar los totales mensuales: una máquina virtual económica puede no atender el mismo trabajo que muchas invocaciones de funciones simultáneas. Incluye también el esfuerzo operativo.

Las máquinas virtuales y los planes de alojamiento dedicados facturan por el tiempo asignado, tanto si están ocupados como inactivos. La facturación estándar bajo demanda de Lambda combina solicitudes y gigabyte-segundos; otros planes de funciones usan otras unidades de medición. Cero instancias elimina los cargos de cómputo inactivo solo cuando no queda un mínimo de pago. El almacenamiento y las bases de datos pueden seguir facturándose.

Comprueba los límites y el traslado entre plataformas

Los procesos de larga duración se adaptan a máquinas virtuales o contenedores adecuados. Una invocación del cómputo predeterminado de Lambda está limitada a 15 minutos, por lo que un trabajo ininterrumpido de dos horas necesita otra opción de ejecución compatible. Las funciones no pueden depender de que el estado local sobreviva entre llamadas; los contenedores reemplazables y las máquinas virtuales de grupos de escalado también necesitan datos duraderos externos.

El control completo del sistema operativo invitado, los cambios en el núcleo y el software especializado con licencia favorecen las máquinas virtuales. Muchos servicios implementados de forma independiente pueden justificar Kubernetes. Las aplicaciones web estándar suelen encajar en plataformas de alojamiento; las tareas breves basadas en eventos encajan en funciones.

Las imágenes de contenedor se trasladan entre hosts compatibles y Kubernetes ofrece herramientas de implementación comunes entre nubes. Las bases de datos, la identidad y las redes aún pueden necesitar cambios. La migración de máquinas virtuales depende de los formatos y las herramientas del proveedor; las funciones y las plataformas están más vinculadas a los ajustes y desencadenantes del proveedor. Distintos componentes pueden usar distintos modelos.

Comprueba primero los requisitos que podrían descartar una opción. Después compara el tráfico, el costo y las habilidades del equipo.

Identifica la restricción decisiva

1. Comprueba el acceso al sistema operativo invitado, el software especial, el hardware y las licencias.
2. Para trabajos breves desencadenados por eventos, comprueba la duración, el estado y la concurrencia de las funciones.
3. Para aplicaciones en contenedores, compara el control de Kubernetes con servicios administrados más sencillos.
4. Para aplicaciones web estándar implementadas como código, considera una plataforma de alojamiento.
5. Comprueba la demora de arranque, los patrones de tráfico, los límites de recursos y el costo operativo total.

Relaciona los casos empresariales con las opciones

Un proveedor solo admite una aplicación de contabilidad en Windows Server, con una licencia basada en núcleos. Las máquinas virtuales conservan ese entorno; usa un host dedicado si la licencia por núcleo físico lo requiere. Las copias en varias zonas necesitan un diseño compatible de aplicación y datos. El traslado prácticamente sin cambios es realojamiento, o traslado directo, y conserva el mantenimiento del sistema invitado.

Las cargas de fotos pasan de unas pocas por la noche a miles por minuto. Las tareas breves e independientes de creación de miniaturas encajan en funciones desencadenadas por las cargas. Escalan con las llegadas; comprueba los arranques en frío, los límites de duración y la capacidad de los servicios posteriores.

Una empresa de venta tiene 30 microservicios, 6 equipos y el requisito de una plataforma en dos nubes. Kubernetes administrado proporciona herramientas comunes de orquestación. Una empresa emergente con 3 servicios y sin experiencia en Kubernetes puede usar Cloud Run, Container Apps o ECS con Fargate, conservando las responsabilidades sobre la imagen y la aplicación sin trabajo sobre los hosts.

La agencia de un museo crea un sitio web de venta de entradas, pero no tiene personal de operaciones. Una plataforma de alojamiento proporciona herramientas de implementación y escalado para los días de inauguración. App Service y App Engine mantienen los hosts; Beanstalk requiere elegir cómo actualizar la plataforma, por ejemplo, mediante actualizaciones administradas.

Un informe nocturno de dos horas encaja en un trabajo en contenedor o una máquina virtual con un límite de ejecución adecuado, no en una sola invocación del cómputo predeterminado de Lambda. La capacidad interrumpible puede reducir el costo si el trabajo guarda el progreso y se reanuda tras una interrupción.

El entrenamiento en GPU durante varios días necesita máquinas virtuales aceleradas o nodos adecuados de Kubernetes con GPU. Los puntos de control persistentes hacen viable la capacidad interrumpible al limitar el progreso perdido.

Explica una elección por etapas

Una empresa puede realojar primero para abandonar rápidamente su centro de datos y después modernizar componentes seleccionados con contenedores, plataformas de alojamiento o funciones. El realojamiento por sí solo conserva el modelo operativo anterior.

Por ejemplo: «Usa Cloud Run porque la API ya está en un contenedor, el tráfico se detiene por la noche y el equipo no tiene un administrador de servidores; ten en cuenta un arranque en frío después de la inactividad».