Ir al contenido principal

FP Grado Superior · Fundamentos de Computación en la Nube

Tema 1: Computación en la nube: conceptos básicos, modelos y ejemplos reales

13 min de lectura

← Volver al listado de temas

1. Introducción

Hoy en día usamos la computación en la nube constantemente, muchas veces sin darnos cuenta. Cuando consultamos el correo desde Gmail, guardamos documentos en Google Drive, vemos una serie en Netflix, usamos Microsoft 365 desde el navegador o compartimos archivos en Dropbox, estamos utilizando servicios alojados en la nube.

La computación en la nube, o cloud computing, consiste en utilizar recursos informáticos a través de Internet sin necesidad de poseer físicamente toda la infraestructura. En lugar de comprar servidores, instalar discos duros, mantener redes, configurar sistemas de alimentación o encargarse de la refrigeración de un centro de datos, una empresa puede contratar esos recursos a un proveedor cloud.

Esto permite que una organización pueda disponer de servidores, almacenamiento, bases de datos, redes, herramientas de análisis, inteligencia artificial o servicios de seguridad de forma flexible, escalable y bajo demanda.

En el modelo tradicional, una empresa necesitaba comprar y mantener su propia infraestructura. En el modelo cloud, en cambio, puede utilizar recursos gestionados por proveedores como Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) u otros servicios especializados.

Dicho de forma sencilla: la nube permite usar tecnología como un servicio, de forma parecida a como usamos la electricidad. No necesitamos construir una central eléctrica para encender una lámpara; pagamos por el consumo. Con la nube ocurre algo similar: no necesitamos comprar un centro de datos completo para alojar una aplicación.

2. Concepto clave

La computación en la nube se basa en ofrecer recursos informáticos a través de Internet de forma flexible, escalable y medible.

Sus características fundamentales son las siguientes:

Autoservicio bajo demanda

El usuario puede solicitar recursos cuando los necesita, sin esperar a que una persona instale físicamente un servidor o configure manualmente toda la infraestructura.

Por ejemplo, una empresa puede crear una máquina virtual desde un panel de administración en pocos minutos.

Acceso amplio a través de la red

Los servicios cloud están disponibles a través de Internet. Esto permite acceder desde distintos dispositivos: ordenadores, móviles, tablets o incluso sistemas automatizados.

Un ejemplo claro sería acceder al correo corporativo desde casa, desde el instituto o desde el móvil.

Recursos compartidos

Los proveedores cloud utilizan grandes centros de datos donde los recursos físicos se comparten entre muchos clientes. Aunque la infraestructura sea común, cada cliente trabaja en entornos separados y aislados.

Es como vivir en un edificio de oficinas: varias empresas comparten el edificio, pero cada una tiene su propio espacio privado.

Elasticidad rápida

Los recursos pueden aumentar o disminuir según la demanda.

Por ejemplo, una tienda online puede necesitar más capacidad durante el Black Friday y menos recursos durante una semana normal. En un entorno cloud, esa ampliación puede hacerse de forma rápida, incluso automática.

Servicio medido

El consumo se monitoriza y se factura según el uso. Esto permite pagar por lo que realmente se utiliza, aunque también exige controlar bien los costes.

Aquí aparece una de las grandes ventajas y, al mismo tiempo, uno de los grandes peligros de la nube: si no se supervisa bien el consumo, la factura puede crecer más de lo esperado.

3. Ejemplo mínimo

Imaginemos una pequeña academia que tiene una página web informativa y una plataforma Moodle para sus alumnos.

Modelo tradicional

La academia compra un servidor físico, lo instala en sus propias instalaciones, configura el sistema operativo, instala Moodle, contrata una conexión a Internet adecuada y se encarga del mantenimiento.

Esto implica:

  • Comprar hardware.
  • Configurar el servidor.
  • Gestionar copias de seguridad.
  • Proteger el sistema frente a ataques.
  • Resolver averías.
  • Ampliar el servidor si hay más alumnos.

Modelo en la nube

La academia contrata servicios cloud para alojar Moodle. Puede usar una máquina virtual para la aplicación, una base de datos gestionada y almacenamiento en la nube para los archivos.

Esto permite:

  • Reducir la inversión inicial.
  • Acceder desde cualquier lugar.
  • Escalar si aumenta el número de alumnos.
  • Delegar parte del mantenimiento en el proveedor.
  • Mejorar la disponibilidad del servicio.

La diferencia principal es que, en el modelo tradicional, la academia gestiona casi todo. En el modelo cloud, contrata recursos tecnológicos como servicio.

4. Ejemplo completo

Supongamos que una empresa llamada Sportiva quiere lanzar una plataforma online para gestionar actividades deportivas, reservas de pistas, pagos de socios y estadísticas de uso.

Al principio, Sportiva tiene pocos usuarios. Sin embargo, espera crecer rápidamente si la aplicación funciona bien.

Situación inicial

Sportiva podría comprar un servidor propio e instalar allí toda la aplicación. El problema es que no sabe cuántos usuarios tendrá dentro de seis meses.

  • Si compra un servidor pequeño, puede quedarse corto.
  • Si compra uno demasiado grande, gastará mucho dinero en infraestructura que quizá no utilice.

Aquí es donde la computación en la nube empieza a tener sentido.

Diseño básico en la nube

La empresa podría contratar una solución cloud formada por varios elementos:

NecesidadPosible solución cloud
Alojar la aplicación webMáquina virtual o PaaS
Guardar datos de usuarios y reservasBase de datos gestionada
Guardar imágenes y documentosAlmacenamiento en la nube
Mejorar la disponibilidadDespliegue en varias zonas
Controlar el tráficoBalanceador de carga
Aumentar capacidad automáticamenteAutoescalado
Vigilar errores y rendimientoMonitorización

Modelos de servicio utilizados

En este ejemplo podrían aparecer varios modelos de servicio cloud.

IaaS — Infraestructura como Servicio

Sportiva podría contratar máquinas virtuales, almacenamiento y redes. Tendría bastante control, pero también más responsabilidad técnica.

Ejemplo: crear una máquina virtual donde instalar su aplicación.

PaaS — Plataforma como Servicio

Sportiva podría usar una plataforma gestionada donde solo tenga que subir su código. El proveedor se encarga de muchos detalles de infraestructura.

Ejemplo: desplegar la aplicación en un entorno gestionado sin administrar directamente el servidor.

SaaS — Software como Servicio

Sportiva también podría utilizar herramientas ya preparadas, como correo corporativo, almacenamiento documental, CRM o herramientas de colaboración.

Ejemplo: usar Microsoft 365 o Google Workspace para la gestión interna.

Modelos de despliegue

Además de los modelos de servicio, Sportiva debe decidir cómo desplegar su infraestructura.

  • Nube pública: sería la opción más habitual para una startup o empresa que busca flexibilidad y escalabilidad. Los recursos se alojan en un proveedor como AWS, Azure o Google Cloud.
  • Nube privada: podría tener sentido si Sportiva gestionara datos muy sensibles o tuviera requisitos legales muy estrictos. Es más cara, pero ofrece mayor control.
  • Nube híbrida: Sportiva podría mantener algunos datos sensibles en servidores propios y usar la nube pública para la parte web, estadísticas o procesamiento de datos.
  • Nube comunitaria: sería menos habitual en este caso, pero podría aplicarse si varias organizaciones deportivas compartieran una infraestructura común con requisitos parecidos.

Estrategia de migración

Si Sportiva ya tuviera una aplicación funcionando en un servidor local, podría migrarla a la nube de diferentes maneras:

  • Rehost (o lift and shift): mover la aplicación casi tal cual a la nube. Es rápido, pero no siempre aprovecha todas las ventajas cloud.
  • Replatform: hacer pequeños cambios para mejorar rendimiento, costes o mantenimiento. Por ejemplo, mantener la aplicación igual pero sustituir la base de datos local por una base de datos gestionada.
  • Refactor: rediseñar la aplicación para aprovechar servicios nativos de la nube. Es la opción más potente, pero también la más compleja. Por ejemplo, dividir la aplicación en microservicios, usar funciones serverless, colas de mensajes y almacenamiento distribuido.

Resultado esperado

Gracias a la nube, Sportiva puede empezar con pocos recursos y crecer gradualmente. Si la aplicación tiene éxito, podrá escalar. Si no crece como esperaba, no habrá invertido miles de euros en servidores infrautilizados.

La nube no elimina la necesidad de planificar. De hecho, exige tomar buenas decisiones técnicas. Pero permite una flexibilidad que el modelo tradicional no ofrece con la misma facilidad.

5. Errores frecuentes

Pensar que la nube es “el ordenador de otra persona” y nada más

Aunque técnicamente los recursos están en centros de datos de terceros, la computación en la nube es mucho más que usar servidores ajenos. Incluye automatización, elasticidad, pago por uso, servicios gestionados, monitorización, seguridad, disponibilidad y escalabilidad.

Reducir la nube a “usar el ordenador de otro” es una forma graciosa de explicarlo, pero se queda bastante corta.

Creer que la nube siempre es más barata

La nube puede reducir costes iniciales, pero no siempre es más barata a largo plazo.

Si no se apagan recursos innecesarios, si se sobredimensionan servidores o si no se controla el tráfico, la factura puede dispararse.

La nube no es magia financiera. Es más flexible, pero hay que gobernarla bien.

Confundir IaaS, PaaS y SaaS

Un error común es mezclar los modelos de servicio:

  • IaaS ofrece infraestructura básica.
  • PaaS ofrece una plataforma gestionada para desplegar aplicaciones.
  • SaaS ofrece una aplicación completa lista para usar.

No es lo mismo contratar una máquina virtual que usar Gmail. Ambos son servicios cloud, pero pertenecen a niveles distintos.

Pensar que migrar a la nube es solo copiar servidores

Migrar a la nube no debería consistir únicamente en mover máquinas de un sitio a otro. Antes hay que analizar costes, seguridad, rendimiento, disponibilidad, dependencias y requisitos legales.

Una mala migración puede trasladar los mismos problemas de siempre… pero con factura mensual.

Ignorar el vendor lock-in

El vendor lock-in aparece cuando una empresa depende demasiado de un proveedor concreto. Cuanto más se usen servicios específicos de un proveedor, más difícil puede ser migrar a otro en el futuro.

Esto no significa que haya que evitar todos los servicios cloud avanzados, pero sí que hay que tomar decisiones con criterio.

No tener en cuenta la legislación

En Europa, aspectos como el RGPD son fundamentales. No basta con guardar datos “en la nube”. Hay que saber dónde se almacenan, quién tiene acceso, cómo se protegen y qué responsabilidades tiene cada parte.

6. Buenas prácticas

Analizar primero las necesidades reales

Antes de elegir servicios cloud, hay que entender qué necesita la organización:

  • Número de usuarios.
  • Tipo de datos tratados.
  • Presupuesto disponible.
  • Nivel de disponibilidad requerido.
  • Necesidades de seguridad.
  • Posible crecimiento futuro.

No todas las soluciones necesitan una arquitectura compleja. A veces, empezar de forma sencilla es la decisión más profesional.

Elegir bien el modelo de servicio

  • Si se necesita mucho control, IaaS puede ser una buena opción.
  • Si se quiere desplegar código sin gestionar servidores directamente, PaaS puede ser más adecuado.
  • Si solo se necesita una herramienta lista para usar, SaaS suele ser la opción más eficiente.

La clave está en no complicar la solución más de lo necesario.

Controlar los costes desde el principio

Configurar presupuestos, alertas y revisiones periódicas de consumo. También conviene eliminar recursos que ya no se usan, ajustar tamaños de servidores y revisar el almacenamiento acumulado.

En cloud, lo que se olvida encendido puede acabar apareciendo en la factura.

Diseñar pensando en la seguridad

La seguridad no debe añadirse al final. Debe estar presente desde el diseño. Algunas medidas básicas son:

  • Usar autenticación fuerte.
  • Aplicar el principio de mínimo privilegio.
  • Cifrar datos sensibles.
  • Revisar accesos.
  • Mantener copias de seguridad.
  • Monitorizar actividad sospechosa.

Pensar en escalabilidad, pero sin exagerar

Es positivo diseñar sistemas que puedan crecer, pero no siempre hace falta construir una arquitectura enorme desde el primer día. Una aplicación pequeña no necesita la misma complejidad que Netflix.

La buena arquitectura no consiste en usar muchos servicios, sino en usar los adecuados.

Documentar las decisiones

Cada decisión importante debería quedar justificada:

  • Por qué se elige nube pública o privada.
  • Por qué se usa IaaS, PaaS o SaaS.
  • Qué riesgos existen.
  • Qué costes se esperan.
  • Cómo se hará la migración.
  • Cómo se protegerán los datos.

La documentación ayuda a mantener el proyecto, facilita auditorías y evita depender únicamente de la memoria del equipo.

7. Ejercicio propuesto

Caso práctico: migración de una plataforma educativa a la nube

Un centro educativo tiene instalada una plataforma Moodle en un servidor local. El servidor se utiliza para subir contenidos, entregar tareas, realizar cuestionarios y consultar calificaciones.

En los últimos meses han aparecido varios problemas:

  • El servidor se ralentiza cuando muchos alumnos acceden a la vez.
  • Solo una persona del centro sabe administrarlo.
  • Las copias de seguridad se hacen manualmente.
  • Durante algunos fines de semana el servicio ha dejado de estar disponible.
  • El centro quiere facilitar el acceso desde casa y mejorar la seguridad.

El equipo directivo se plantea migrar la plataforma a la nube.

Tareas. Responde de forma razonada a las siguientes cuestiones:

  1. Explica qué ventajas tendría migrar esta plataforma a la nube.
  2. Indica al menos tres posibles inconvenientes o riesgos de la migración.
  3. Decide qué modelo de servicio sería más adecuado: IaaS, PaaS o SaaS. Justifica tu respuesta.
  4. Decide qué modelo de despliegue utilizarías: nube pública, privada, híbrida o comunitaria. Justifica tu elección.
  5. Propón una estrategia de migración: rehost, replatform o refactor.
  6. Explica qué medidas aplicarías para controlar costes.
  7. Explica qué medidas aplicarías para proteger los datos del alumnado.
  8. Indica qué mejoras esperaría notar el centro después de la migración.

Orientación para la respuesta. Una buena respuesta no debe limitarse a decir “lo subiría a AWS” o “lo pondría en Azure”. Lo importante es justificar las decisiones.

Por ejemplo, se podría proponer una solución inicial basada en una máquina virtual para Moodle y una base de datos gestionada. También se podrían valorar copias de seguridad automáticas, monitorización, control de accesos y alertas de consumo.

Lo más importante es demostrar que se entiende que la nube no es solo un lugar donde alojar servidores, sino una forma diferente de consumir, gestionar y escalar recursos tecnológicos.

Conclusión

La computación en la nube ha cambiado la forma en la que empresas, centros educativos y usuarios acceden a la tecnología. Permite disponer de recursos bajo demanda, reducir inversión inicial, mejorar la escalabilidad y acceder a servicios avanzados sin construir toda la infraestructura desde cero.

Sin embargo, también introduce nuevos retos: dependencia de Internet, control de costes, seguridad, cumplimiento legal y posible dependencia del proveedor.

Por eso, aprender cloud no consiste únicamente en conocer nombres de servicios. Consiste en entender cuándo tiene sentido usar la nube, qué modelo elegir, qué riesgos existen y cómo diseñar soluciones eficientes, seguras y sostenibles.

La nube no es simplemente “usar servidores por Internet”. Es una forma moderna de pensar la infraestructura, el software y la evolución de los proyectos digitales.

Contenido complementario a Moodle

Moodle mantiene entregas y calificaciones; este espacio amplía la visión arquitectónica y técnica.

Base curricular: Programación Didáctica de Fundamentos de Computación en la Nube (CFGS Informática).