Tiene razón en que hasta hace poco todo esto ha sido teórico, pero si bien la portabilidad y la federación en la nube son capacidades muy poderosas pero no una panacea.
Permítanme aclarar un par de cosas en su pregunta:
– La explosión en la nube de las instalaciones a la nube no requiere federación de nubes o interclouds Es posible en Rackspace, por ejemplo, donde un agente de monitoreo puede desencadenar la explosión en la nube una vez que la infraestructura dedicada alcanza cierta capacidad dentro o fuera de las instalaciones.
- Cómo cambiar mi carrera a la computación en la nube del soporte de Citrix Xendektop
- ¿Por qué la nube de Amazon es la opción de facto para la mayoría de los desarrolladores? ¿Es más fácil de usar, más barato o más poderoso que los competidores? ¿O es simplemente reconocimiento de marca?
- ¿Qué es la computación en la nube y su arquitectura?
- ¿Por qué es importante el agente de seguridad de acceso a la nube?
- ¿Conoces alguna solución de alojamiento en la nube que también proporcione un panel de control que pueda usar para instalar varios servicios en mi instancia (como elasticsearch, redis, etc.)?
– El equilibrio de carga en geografías, proveedores de nube y otros tipos de infraestructura también es posible con la mayoría de los equilibradores de carga (sin necesidad de interclouds). Después de todo, un LB solo distribuye el tráfico a través de direcciones IP en función de ciertas reglas como la latencia, la capacidad, la persistencia de la sesión, etc.
– Mover mágicamente las cargas de trabajo entre proveedores no es valioso para las empresas. No es que quiera que su sistema ERP se ejecute en HP un día y al día siguiente querrá trasladarlo a IBM.
El valor de una federación de nubes que comparten una arquitectura, interfaces (API) y herramientas de administración similares está en la flexibilidad para mover cargas de trabajo si es necesario. No necesita ser ‘mágico’ o incluso automatizado, solo debe ser sencillo.
El problema es que, cuando diseña un sistema complejo para un sistema propietario, la arquitectura de su sistema debe cumplir con las reglas, las mejores prácticas, las API y el paradigma general de ese sistema. Intentar moverlo a algo diferente es posible pero en su mayor parte no es práctico. Los ejemplos van desde Netflix (bloqueo) hasta Netscape (murió tratando de reescribir su software).
Una aplicación diseñada para OpenStack se dirige a un conjunto de API, mejores prácticas y arquitectura que se comparte entre múltiples proveedores de nube e incluso nubes privadas alojadas dentro o fuera de las instalaciones. Incluso si no necesita utilizar múltiples proveedores, tener la capacidad de hacerlo si es necesario es una póliza de seguro muy valiosa para el futuro.
Además, hoy existen aplicaciones que se benefician de esta federación en la nube. HubSpot, por ejemplo, es una compañía de rápido crecimiento que tiene una aplicación central que puede crear instancias de servidor adicionales cuando sea necesario, donde sea necesario . La aplicación utiliza la misma API OpenStack para crear un servidor en una nube pública (Rackspace en este caso), nube privada (también alojada en Rackspace pero con una red privada, hardware personalizado y mejor economía que la nube pública), o dedicada (bare metal) ) hardware.
Al servidor creado no le importa dónde está alojado (el logotipo en la fuente del edificio se vuelve irrelevante), el modelo de facturación o aprovisionamiento (“nube” o de otro modo), o la empresa que administra la infraestructura. Esto le da a HubSpot la capacidad de usar la infraestructura que desean no en función de las limitaciones tecnológicas, la compatibilidad de la aplicación o las preferencias del proveedor, sino en lo que satisface sus propias necesidades: capacidad, economía, seguridad, CapEx vs OpEx, etc.
Las implementaciones en múltiples nubes son reales y son poderosas. Al igual que HubSpot, hay cada vez más empresas que lo aprovechan.
