Qué es la nube pública y qué ejemplos hay
La nube pública permite utilizar recursos informáticos —como servidores, almacenamiento, bases de datos o herramientas de análisis— que un proveedor opera en sus centros de datos y ofrece a través de internet. La empresa usuaria los configura y paga según el servicio y el consumo, sin tener que comprar y mantener por su cuenta todo el hardware que los ejecuta.
Amazon Web Services (AWS), Microsoft Azure y Google Cloud son ejemplos de proveedores de nube pública. En sus plataformas se pueden crear máquinas virtuales, guardar copias de archivos, alojar aplicaciones o contratar bases de datos gestionadas. Que el servicio sea público no quiere decir que los datos sean visibles para cualquiera: el acceso se controla mediante identidades, permisos y configuración de seguridad.
Qué se comparte y qué controla cada organización
El proveedor mantiene la infraestructura física y ofrece capacidades comunes a muchos clientes. Esa infraestructura incluye, entre otros componentes, servidores, redes y sistemas de almacenamiento. Los recursos de cada cliente se aíslan mediante mecanismos técnicos y de control de acceso; el cliente no suele elegir ni manipular directamente el servidor físico que los ejecuta.
La separación de responsabilidades es esencial. El proveedor se ocupa de proteger y mantener los componentes que gestiona, mientras que la organización debe configurar correctamente los servicios que utiliza. El reparto exacto varía según el producto: no se gestiona igual una máquina virtual que una aplicación completa ofrecida como servicio.
- Con una máquina virtual: el proveedor mantiene el centro de datos y la capa de virtualización; el cliente suele administrar el sistema operativo, las aplicaciones, las cuentas y los datos.
- Con una base de datos gestionada: el proveedor asume tareas operativas como parte del mantenimiento del servicio, pero el cliente sigue definiendo quién accede, qué datos almacena y cómo los utiliza.
- Con una aplicación lista para usar: el proveedor gestiona una parte mayor de la plataforma. La empresa usuaria conserva responsabilidades sobre sus cuentas, permisos, dispositivos y uso de la información.
Por eso, contratar un servicio en la nube no elimina la necesidad de gobernarlo. Una cuenta con permisos excesivos, una copia de seguridad mal planteada o datos expuestos por una configuración incorrecta siguen siendo problemas que la organización debe prevenir.
Ejemplos concretos de nube pública
Máquinas virtuales para alojar aplicaciones
Un equipo puede contratar una máquina virtual para ejecutar una aplicación web o un programa interno. En AWS, Amazon Elastic Compute Cloud (Amazon EC2) ofrece capacidad de computación bajo demanda; en Azure existe Azure Virtual Machines, y Google Cloud ofrece Compute Engine. El cliente selecciona características del recurso, configura el sistema operativo y despliega su software.
Este modelo resulta útil cuando se necesita controlar el entorno de ejecución o trasladar una aplicación que ya funciona en servidores tradicionales. A cambio, el equipo debe encargarse de tareas como aplicar actualizaciones al sistema operativo, vigilar el rendimiento y preparar la recuperación ante fallos. La máquina esté en la nube no convierte esas tareas automáticamente en responsabilidad del proveedor.
Almacenamiento de archivos y objetos
Una empresa puede guardar documentos, imágenes, registros o copias de seguridad en servicios de almacenamiento accesibles desde aplicaciones y sistemas autorizados. Amazon Simple Storage Service (Amazon S3), Azure Blob Storage y Cloud Storage de Google son ejemplos de almacenamiento de objetos. No son necesariamente equivalentes a una carpeta de red: su funcionamiento y la forma de acceder a los datos dependen de la aplicación y del servicio elegido.
Antes de utilizarlos para información importante, hay que decidir quién podrá leer o modificar los archivos, cuánto tiempo se conservarán y cómo se recuperarán si se borran o se alteran. Replicar datos entre ubicaciones puede mejorar la disponibilidad, pero no sustituye por sí solo a una estrategia de copia de seguridad: un borrado autorizado o una cuenta comprometida podrían afectar también a las copias replicadas, según cómo estén configuradas.
Bases de datos y otros servicios gestionados
Los proveedores también ofrecen bases de datos en las que se encargan de parte de la instalación y el mantenimiento. Amazon Relational Database Service (Amazon RDS), Azure SQL Database y Cloud SQL de Google son ejemplos de servicios para bases de datos relacionales. La empresa configura el servicio y gestiona su uso, mientras que determinadas tareas de infraestructura quedan en manos del proveedor.
Otros recursos incluyen colas de mensajes, análisis de datos, redes virtuales y herramientas para desplegar aplicaciones. La ventaja práctica es que se pueden combinar servicios sin comprar previamente el equipo físico. Sin embargo, cada producto tiene opciones, límites y formas de administración propias; elegir un nombre conocido no basta para comprobar que cubre una necesidad concreta.
Nube pública, privada e híbrida: en qué se distinguen
En una nube pública, el proveedor ofrece infraestructura y servicios a distintos clientes, que utilizan recursos separados lógicamente. En una nube privada, la infraestructura se reserva para una organización, aunque puede estar alojada en sus instalaciones o gestionada por un tercero. Un entorno híbrido combina infraestructura local o privada con servicios de nube pública y mantiene conexiones o intercambios entre ambos.
La diferencia no determina automáticamente cuál es más segura o más barata. Una nube privada puede proporcionar más control sobre ciertos componentes, pero exige disponer de capacidad para operarla. La nube pública ofrece acceso a recursos gestionados y escalables, pero requiere controlar la configuración, el consumo y las dependencias del proveedor. Un entorno híbrido añade opciones de ubicación y transición, aunque también hace más complejas la conexión, la supervisión y la gestión de identidades.
Qué valorar antes de trasladar una carga
Supongamos, como ejemplo hipotético, que una empresa quiere alojar una aplicación de gestión de pedidos y conservar sus documentos de trabajo. No debería empezar por escoger una marca de nube, sino por describir cómo funciona la aplicación, qué datos utiliza y qué necesita para estar disponible.
- Identificar dependencias: comprobar qué sistema operativo, base de datos, licencias, integraciones y conexiones necesita la aplicación. Un programa antiguo que depende de un servidor local puede requerir cambios o mantener parte de su infraestructura en las instalaciones de la empresa.
- Definir acceso y protección: establecer qué usuarios y aplicaciones accederán a cada recurso. Separar cuentas administrativas de las de uso habitual y limitar permisos ayuda a reducir el impacto de errores o credenciales expuestas.
- Estimar el coste completo: revisar qué se cobra por los recursos contratados y por su uso. Además de la computación y el almacenamiento, pueden influir el tráfico de datos, las copias, los servicios adicionales y el tiempo necesario para administrar el entorno. El precio depende de la configuración y de las condiciones vigentes del proveedor.
- Planificar continuidad y salida: determinar cómo se recuperará la aplicación si falla un componente y cómo se exportarán los datos si el servicio cambia. Conviene comprobar formatos, dependencias y costes de transferencia antes de que exista una urgencia.
- Probar con una carga acotada: una aplicación secundaria o un entorno de pruebas permite revisar rendimiento, permisos, facturación y procedimientos de recuperación antes de trasladar un sistema crítico.
En ese ejemplo, la empresa podría ejecutar la aplicación en máquinas virtuales, contratar una base de datos gestionada y guardar documentos en almacenamiento de objetos. La combinación concreta dependería de las necesidades técnicas y de quién pueda administrar cada componente. La nube pública describe el modelo de provisión; no obliga a contratar todos los servicios de un mismo tipo ni a trasladarlo todo a la vez.
La escalabilidad no elimina la necesidad de control
Una característica útil de estos servicios es que permiten ajustar recursos sin comprar un servidor físico para cada pico de demanda. Si aumenta la carga, una organización puede ampliar capacidad o habilitar servicios adicionales; si disminuye, puede reducirlos. Para que el ajuste sea eficaz, la aplicación debe admitirlo y alguien debe revisar que los recursos no permanezcan activos o sobredimensionados innecesariamente.
También importa la dependencia tecnológica. Una aplicación construida alrededor de servicios específicos de un proveedor puede ser más difícil de trasladar que otra basada en componentes más portables. Esa dependencia no es siempre un inconveniente: un servicio gestionado puede reducir trabajo operativo. La decisión consiste en comparar ese ahorro con el grado de control, las posibilidades de migración y el coste de mantener la solución.
Para ampliar otros conceptos y usos de estos servicios, puedes consultar la sección de Computación en la Nube. La elección de una plataforma concreta debería partir de los requisitos de la carga, las capacidades del equipo que la administrará y las condiciones del servicio que se vaya a contratar.
