Virtualización y nube

Imagina alquilar una habitación en un gran edificio en lugar de construir una casa. Ganas comodidad, pero necesitas saber quién controla la puerta, la recepción y la infraestructura. La virtualización y los servicios en la nube plantean preguntas similares, aunque sus límites técnicos son más precisos que esa analogía.

Las máquinas virtuales preceden al auge de la nube

Los experimentos de IBM en los años sesenta exploraron cómo dar a los usuarios entornos virtuales separados sobre hardware compartido. La empresa anunció VM/370 en 1972. Una máquina virtual presenta recursos a un sistema huésped mientras otra capa administra el hardware. Así podían coexistir entornos distintos sin comprar una computadora física para cada trabajo.

“Virtual” no significa imaginario. El tiempo de procesador, la memoria, el almacenamiento y la electricidad siguen siendo físicos. Cambia cómo los presenta y asigna el software. Los fallos del hardware, los defectos de software y las decisiones administrativas aún pueden afectar a varias cargas.

El aprovisionamiento remoto cambió el trabajo

La beta limitada de Amazon EC2 de 2006 es un hito visible de la nube pública. Su anuncio describía entornos de computación virtual creados mediante interfaces de servicio. En vez de esperar a comprar e instalar una máquina, un desarrollador podía solicitar capacidad a distancia. Cambió la entrega de computación; no fue la invención de la máquina virtual.

La definición de NIST de 2011 describe características como acceso bajo demanda, recursos agrupados y elasticidad rápida. Por tanto, una VM en tu portátil no es automáticamente una nube. Los servicios también pueden ofrecer bases de datos administradas o aplicaciones completas sin exponer un sistema operativo huésped al cliente.

La puerta de administración importa

Piensa en el sitio de un club ficticio alojado en una VM alquilada. Una cuenta administra el huésped. Otra puede crear máquinas, conectar almacenamiento o modificar redes desde el panel del proveedor. Proteger el huésped y descuidar la cuenta de administración deja sin revisar otra autoridad poderosa.

Las responsabilidades dependen del servicio. Al alquilar una VM, el club puede mantener el sistema huésped y la aplicación. En una aplicación administrada, el proveedor puede encargarse de más capas. El club todavía necesita permisos apropiados sobre los datos, acuerdos de recuperación y entender el servicio contratado.

PrediceConsigues permisos de administrador dentro de la VM del club. ¿Eso autoriza automáticamente cambios en la VM de otro cliente?

No. La autoridad del huésped y la de infraestructura son distintas. Su separación depende de controles implementados; ni el nombre del producto ni el del rol demuestran que todo límite sea correcto.

Nuevo empaquetado, preguntas conocidas

Los contenedores suelen aislar procesos compartiendo un kernel. Pueden funcionar dentro de VM, pero no aportan automáticamente el mismo límite que kernels huéspedes separados. Pregunta qué se comparte y qué componente impone la separación.

Persisten las preguntas de propiedad y recuperación: quién modifica el recurso, dónde están sus copias y cómo se restablece un servicio útil. El aprovisionamiento rápido las vuelve más urgentes: los recursos pueden aparecer y desaparecer antes de que un inventario manual consiga seguirlos.