1. Introducción
El cómputo en la nube es la capacidad de ejecutar aplicaciones, APIs, procesos y tareas sin tener servidores físicos propios.
En lugar de comprar hardware y administrar todo manualmente, en cloud elegimos el modelo de ejecución más adecuado según:
- nivel de control deseado,
- mantenimiento que asumirá el equipo,
- patrón de carga,
- escalabilidad esperada.
No existe una única forma de ejecutar software en cloud. Podemos usar:
- máquinas virtuales (EC2),
- despliegue administrado (Elastic Beanstalk),
- funciones serverless (Lambda),
- contenedores (ECS/EKS).
La clave profesional es elegir por caso de uso, no por moda.
2. Concepto clave
El punto central es la relación control vs responsabilidad:
- más control => más mantenimiento técnico,
- más servicio gestionado => menos mantenimiento, menor control fino.
Esquema general de servicios de cómputo
Servicios de cómputo en la nube │ ├── Máquinas virtuales │ └── Amazon EC2 │ ├── Despliegue administrado de aplicaciones │ └── AWS Elastic Beanstalk │ ├── Funciones sin servidor │ └── AWS Lambda │ └── Contenedores ├── Amazon ECS └── Amazon EKS
Comparativa inicial
| Tipo | Servicio AWS | Control | Gestión del usuario | Caso típico |
|---|---|---|---|---|
| VM | EC2 | Alto | Alta | Aplicación legacy / servidor clásico |
| PaaS administrado | Elastic Beanstalk | Medio | Media-baja | Web/API estándar |
| Serverless | Lambda | Bajo | Muy baja | Eventos, automatización |
| Contenedores | ECS/EKS | Medio-alto | Media-alta | Microservicios |
Máquinas virtuales (EC2)
EC2 es lo más cercano al servidor tradicional, pero virtualizado.
Permite decidir AMI, tipo de instancia, red, subred, SG, disco y acceso SSH.
Ventajas:
- control total,
- flexibilidad alta,
- familiar para equipos con background sysadmin.
Inconvenientes:
- mantenimiento (parches, hardening, logs, backups),
- mayor responsabilidad operativa y de seguridad.
Elastic Beanstalk
Punto intermedio entre control y simplicidad.
- subes código,
- el servicio monta entorno y despliegue,
- facilita escalado y operación básica.
Ideal para aplicaciones web/API estándar cuando no quieres gestionar toda la infraestructura manualmente desde el primer día.
Serverless (Lambda)
Modelo por eventos: el código se ejecuta cuando ocurre algo.
Ejemplos de eventos:
- subida de archivo a S3,
- petición HTTP,
- mensaje en cola,
- tarea programada.
Ventajas:
- no gestionas servidores,
- pago por ejecución,
- escalado automático.
Limitaciones:
- no es ideal para procesos largos,
- menor control del entorno,
- arquitectura puede volverse compleja si se fragmenta sin diseño.
Contenedores (ECS/EKS)
Empaquetan aplicación + dependencias para ejecución consistente.
| Aspecto | ECS | EKS |
|---|---|---|
| Orquestador | Propio AWS | Kubernetes |
| Complejidad | Menor | Mayor |
| Portabilidad | Menor | Mayor |
| Curva aprendizaje | Más suave | Más exigente |
Regla práctica:
- ECS si quieres contenedores en AWS con menor complejidad.
- EKS si necesitas Kubernetes y su ecosistema.
Esquema de decisión rápido
¿Necesitas control de SO? ├── Sí -> EC2 └── No ├── ¿Evento corto y puntual? -> Lambda ├── ¿Contenedores? │ ├── ¿Kubernetes? -> EKS │ └── ¿Más simple en AWS? -> ECS └── ¿Web/API estándar? -> Elastic Beanstalk
3. Ejemplo mínimo
Queremos desplegar una API pequeña de cursos.
Opciones:
- EC2: máximo control, más administración.
- Elastic Beanstalk: despliegue más simple para web/API.
- Lambda + API Gateway: ejecución bajo demanda.
- Contenedor (ECS): buena base si crecerá a microservicios.
4. Ejemplo completo
Caso: CloudTasks Academy con web, API, subida de archivos, informes y posible evolución a microservicios.
Arquitectura híbrida razonable:
Usuarios │ ▼ Frontend web │ ▼ Backend principal │ ├── EC2 (legacy) ├── Elastic Beanstalk (web/API estándar) ├── Lambda (procesos por evento) └── ECS/EKS (microservicios)
Mapeo por necesidad
| Necesidad | Servicio recomendado | Motivo |
|---|---|---|
| Migrar legacy | EC2 | control completo del entorno |
| Despliegue web estándar | Elastic Beanstalk | reduce complejidad inicial |
| Procesar archivos subidos | Lambda | ejecución por evento |
| Microservicios | ECS/EKS | escalado por componente |
| Informes pesados | ECS o EC2 | procesos potencialmente largos |
Conclusión de arquitectura: no se usa un solo servicio para todo; se combina según responsabilidad, coste y perfil de carga.
5. Errores frecuentes
- Usar EC2 para todo por costumbre.
- Usar Lambda para procesos largos.
- Meter Kubernetes sin necesidad real.
- No entender responsabilidades del modelo elegido.
- Permisos excesivos (IAM) en funciones/instancias/contenedores.
- No monitorizar.
- No diseñar costes.
- No separar entornos.
- Despliegues manuales sin automatización.
6. Buenas prácticas
- Elegir cómputo por caso de uso.
- Empezar simple y evolucionar con evidencia.
- Aplicar mínimo privilegio en IAM.
- Estandarizar imágenes/plantillas (evitar “servidores artesanales”).
- Monitorizar desde el inicio (métricas + logs + alertas).
- Diseñar para fallos y escalado.
- Separar dev/test/prod.
- Gestionar secretos fuera de código.
- Gobernar costes por servicio.
- Documentar por qué se eligió cada pieza.
7. Ejercicio propuesto
Caso: ComputeAula Cloud.
Componentes:
- web para alumnado/profesorado,
- API backend,
- subida de archivos,
- procesamiento automático,
- informes,
- aplicación legacy,
- posible evolución a microservicios.
Tareas:
- Explicar qué resuelven los servicios de cómputo frente a servidores físicos.
- Describir EC2: control, responsabilidades y casos.
- Elegir servicio para legacy y justificar.
- Explicar Elastic Beanstalk y caso de uso en la plataforma.
- Explicar Lambda y validar si encaja para procesamiento de archivos.
- Dibujar flujo evento -> Lambda.
- Explicar contenedores y ventaja de portabilidad.
- Comparar ECS vs EKS.
- Completar tabla de elección por componente.
- Ordenar servicios por nivel de control (de mayor a menor).
- Identificar errores a evitar.
- Proponer arquitectura global razonada.
Solución orientativa
ComputeAula Cloud │ ├── App legacy -> EC2 ├── Web/API estándar -> Elastic Beanstalk ├── Procesamiento de archivos -> Lambda ├── Informes pesados -> ECS/EC2 └── Evolución a microservicios -> ECS (o EKS si Kubernetes)
Conclusión
Los servicios de cómputo son el motor operativo de la nube. La decisión correcta no es “el servicio más moderno”, sino el que mejor encaja con:
- el problema,
- el equipo,
- el mantenimiento esperado,
- la escalabilidad,
- y el coste.
En arquitectura cloud profesional, elegir bien cómputo es elegir bien el equilibrio entre control, velocidad de entrega y sostenibilidad operativa.