Punto de partida. Actividad «Decisiones de cloud, datos e IA», sesión 1 de 4. Abre los materiales enlazados y crea el registro de la unidad. La guía de arranque permite preparar las herramientas sin depender de otros módulos.
Se explica
10 minutos · contexto, explicación y ejemplo
El dimensionamiento ajusta recursos a una necesidad. Tener cuatro máquinas casi vacías puede indicar una oportunidad de revisión, pero reducirlas sin comprobar disponibilidad o redundancia puede deteriorar el servicio. Necesitamos observar carga, picos y requisitos antes de decidir.
El escalado permite ajustar capacidad según demanda; mantener el máximo de una campaña durante todo el año no siempre es proporcional. En esta unidad trabajaremos con cifras del caso, sin contratar servicios ni configurar infraestructura. Digitalización y Servidor no son requisitos de acceso.
Consultar ejemplos y conceptos de esta sesión
Right-sizing
Right-sizing
Usar recursos adecuados a la carga real de la aplicación. Ni demasiado pocos, ni muchos más de los necesarios.
Un ejemplo típico: una aplicación que usa de media un 15 % de CPU y un 25 % de RAM, sobre una máquina virtual de 16 CPU y 64 GB. Eso significa mayor coste, más recursos reservados e infraestructura infrautilizada.
Conviene evitar, no obstante, la conclusión inmediata:
Falso
Menos recursos siempre es mejor.
Cierto
Los recursos se ajustan a la necesidad real, incluidos los picos.
Una máquina demasiado pequeña provoca lentitud, errores, caídas, mala experiencia y falta de capacidad justo cuando más gente llega. Dimensionar por debajo no es sostenibilidad: es un fallo de servicio con otro nombre.
Escalado
No hace falta mantener siempre toda la capacidad que necesitaremos en un pico:
- Carga baja · pocos recursos
- Carga alta · más recursos
- Carga baja otra vez · se devuelven
A eso lo llamamos escalado, y cuando ocurre solo:
Autoscaling
La idea es tener capacidad cuando hace falta y dejar de pagarla —y de ocuparla— cuando deja de hacer falta.
Se trabaja
45 minutos · trabajo guiado sobre la actividad
- Abre los siete escenarios de PixelStore y crea la tabla de UD5: necesidad, datos, propuesta, riesgo y comprobación. Empieza por la web corporativa, distinta de la tienda.
- Examina sus cuatro máquinas al 5 % de CPU y 12 % de RAM. Explica por qué sugieren revisar capacidad y qué falta saber antes de retirar una máquina.
- Compara conservar todo, reducir capacidad y usar un servicio más sencillo. Anota un beneficio y un riesgo de cada alternativa, sin inventar una factura real.
- Analiza la campaña de 2.000 a 40.000 usuarios simultáneos. Propón cómo comprobar la capacidad necesaria y cuándo ampliar o reducir recursos.
- Incluye quién revisaría recursos olvidados y con qué frecuencia. Guarda una decisión provisional y los datos que la harían cambiar.
Cierre
5 minutos · comprobar el resultado
Al terminar la sesión:
Las propuestas responden a carga y servicio. «Menos máquinas» no se presenta como solución correcta sin comprobar las condiciones de uso.