La nube híbrida describe las conexiones entre diferentes entornos en la nube. La multicloud significa utilizar servicios de al menos dos proveedores de la nube. Estas características pueden coexistir. Una empresa puede conectar una nube privada a servicios públicos de dos proveedores y utilizar ambos enfoques.
Comiencen identificando la composición de su entorno: dónde se ejecutan las aplicaciones, quién proporciona servicios en la nube y qué dependencias conectan los sistemas. Esta descripción es más útil que elegir una etiqueta. Muestra quién necesita tener control sobre el acceso, la conectividad, las actualizaciones y la resolución de problemas.
Primero, distingan entre tres conceptos
Una nube privada no tiene que estar en la oficina
Una nube privada sirve a una sola organización. Puede operar dentro de la empresa o a través de un operador externo. Un servidor de oficina normal no se convierte automáticamente en una nube. La definición de nube de NIST incluye el auto servicio bajo demanda, el acceso a la red, un conjunto de recursos compartidos, la elasticidad y el uso medido.
Aclare el modelo real antes de compararlo. Un servidor que ejecuta software de contabilidad que un administrador configura manualmente puede considerarse un sistema local. No lo etiqueten como una nube privada simplemente para crear un diagrama de presentación.
Un entorno de TI híbrido es más amplio que una nube híbrida
Según la definición de NIST, una nube híbrida combina infraestructuras de nube separadas que permanecen distintas pero se conectan a través de tecnologías que permiten la portabilidad de datos y aplicaciones. Vincular una nube privada a una nube pública es un ejemplo común. Todavía es necesario diseñar y probar el mecanismo de portabilidad específico.
Los proveedores pueden utilizar el término de forma más amplia. Por ejemplo, AWS describe un modelo híbrido a través del propio centro de datos de una empresa y un proveedor de la nube. Acuerden sobre la terminología al discutir un proyecto. En este artículo, una combinación de sistemas locales y servicios en la nube es un entorno de TI híbrido. Utilizamos la definición estricta de la nube cuando es aplicable.
«Multicloud» se refiere a los proveedores, no a los servidores
Dos regiones de un mismo proveedor de la nube no crean por sí solas un entorno multicloud. Dos proveedores crean un entorno de este tipo, incluso si sus aplicaciones no intercambian datos. La etiqueta no promete una gestión unificada, la portabilidad de la carga de trabajo o la conmutación por fallo ante desastres.
Aclare qué está contando. Una empresa puede utilizar la infraestructura de nube de un proveedor y las aplicaciones listas para usar de otro. Para un inventario completo de las dependencias de la nube, esto significa múltiples proveedores. Para un proyecto de migración de aplicaciones a un servidor, distinga entre plataformas de infraestructura y servicios listos para usar. Utilizar los últimos no implica la portabilidad de la aplicación entre ellos.
Comparar modelos según las tareas operativas
|
Pregunta |
Entorno híbrido |
Multicloud |
Qué registrar |
|---|---|---|---|
|
¿Qué significa «combinado»? |
Sistemas locales y de nube, o diferentes nubes conectadas |
Servicios de dos o más proveedores de nube |
Una lista de sistemas, proveedores y conexiones |
|
¿Por qué es necesaria la conectividad? |
Para establecer dependencias específicas entre entornos |
Cuando las aplicaciones de diferentes proveedores deben interactuar |
Direcciones de intercambio de datos y requisitos de las aplicaciones |
|
Cómo funciona el acceso |
Las cuentas locales y en la nube pueden requerir coordinación |
Cada proveedor tiene sus propios roles y límites administrativos |
La fuente de identidad y el propietario de las asignaciones de permisos |
|
Quién resuelve un fallo |
Distinguir los componentes locales, la nube y la conexión |
Distinguir las plataformas, las integraciones y la conexión |
Un propietario para todo el servicio |
|
Si una aplicación puede moverse |
Depende de los formatos, las licencias, los datos e integraciones |
Un segundo proveedor no establece la portabilidad |
Una ruta de migración probada para la carga de trabajo específica |
|
Si existe una opción de recuperación |
Solo si ha sido diseñada y probada |
El segundo entorno en la nube puede desempeñar una tarea completamente diferente |
Un escenario de fallo y resultado de la prueba |
|
¿Qué costes incluyen? |
Hardware, servicios en la nube, conectividad y soporte |
Servicios de diferentes proveedores, intercambio de datos y habilidades específicas |
Un modelo de costes con un responsable para cada categoría |
La tabla no identifica un ganador en términos de seguridad, precio o fiabilidad. Estas cualidades dependen de los componentes específicos y del trabajo del equipo. Compare los diseños para la misma tarea empresarial y los mismos requisitos de resultado.
Distinga un diseño deliberado de una colección accidental de suscripciones
Los diferentes departamentos pueden adquirir servicios de diferentes proveedores sin un proyecto compartido. Este entorno ya crea múltiples dependencias en la nube, incluso si nadie lo ha planeado como un entorno multicloud. Primero, identifique los responsables de las suscripciones, las cuentas administrativas, los métodos de pago y los datos en cada servicio. Mantenga los servicios útiles, pero resuelva los límites de responsabilidad desconocidos.
Si un proveedor cumple con los requisitos y el equipo no tiene motivos para añadir un segundo, la complejidad adicional es innecesaria. Los entornos en la nube múltiples no son una etapa obligatoria del crecimiento empresarial. Separe la necesidad de una función específica de la necesidad de una opción de recuperación para la misma aplicación. Estas tareas requieren diferentes soluciones.
Tres diseños de entorno para una pequeña empresa
Los siguientes ejemplos muestran tres posibles configuraciones. Compara estas con tus sistemas y verifica las conexiones, el acceso y la responsabilidad en cada caso.
Un sistema de oficina y un proveedor de la nube
Configuración: empleados de la oficina, una aplicación local y su base de datos, y correo electrónico en la nube de un proveedor. Registra cualquier conexión entre la aplicación y el correo electrónico por separado. Este es un entorno de TI híbrido. Si el componente local es un servidor estándar, el término «híbrido» no es necesario.
La pregunta principal aquí no es el número de nubes. Determina si la aplicación puede funcionar sin conectividad externa, donde los empleados se autentican, y cómo se envían las notificaciones. Incluso una aplicación local puede depender de la verificación de licencias externas o de un directorio en la nube.
Dos proveedores de la nube sin servidor local
Configuración: empleados, un sistema de ventas en la nube del proveedor A, un sitio web en la nube del proveedor B, y el intercambio de solicitudes entre el sitio web y el sistema de ventas. Esto es multicloud. Dos proveedores por sí solos no establecen un entorno híbrido. Para ello, se necesitan infraestructuras en la nube separadas conectadas a través de mecanismos para la portabilidad de datos y aplicaciones.
Verifica el propietario del intercambio, el formato de datos, los límites de la interfaz y el manejo de errores. Si el sitio web está disponible pero las solicitudes nunca llegan al sistema de ventas, un estado de funcionamiento para ambas plataformas no logrará la tarea empresarial. Supervisa el resultado de la transferencia.
Una nube privada y dos proveedores públicos
Configuración: la nube privada de la empresa, la nube pública A para una aplicación, la nube pública B para una tarea de análisis separada, y conexiones de transferencia de datos acordadas. Si las infraestructuras se conectan a través de mecanismos para la portabilidad de datos y aplicaciones, el diseño combina un entorno híbrido y multicloud.
Un pequeño equipo necesita una razón sólida para este diseño. Por ejemplo, un sistema existente puede requerir un entorno privado mientras que dos servicios en la nube satisfacen diferentes requisitos confirmados. Si una nube debe manejar la carga máxima, verifica la compatibilidad de la aplicación, la capacidad disponible, las cuotas y la transferencia oportuna de datos. El crecimiento de los recursos no ocurre por sí solo. Desear independencia de un proveedor no demuestra que el equipo puede soportar ambas plataformas y trasladar la carga de trabajo entre ellas.
Verifica las conexiones, el acceso y la responsabilidad
Mapear los flujos de datos y los puntos de fallo
Para cada conexión, especificar el remitente, el destinatario, el tipo de datos, la frecuencia de intercambio y la interrupción aceptable. Separar el tráfico empresarial, el inicio de sesión del usuario, el acceso administrativo y la supervisión. Pueden utilizar diferentes rutas y tener diferentes consecuencias en caso de fallo.
Luego, preguntar qué ocurre si la conexión, el directorio de cuentas o la interfaz de la aplicación se vuelven inaccesibles. Definir la cola de operaciones no procesadas, el proceso de reintento y el método para detectar transferencias perdidas. Medir una operación real bajo una carga esperada a lo largo de toda la ruta de intercambio. Un segundo proveedor no garantiza una menor latencia. Una conexión entre plataformas no garantiza un intercambio de datos correcto.
Coordinar el inicio de sesión y el ciclo de vida del acceso
Definir la fuente de la cuenta, los propietarios de los grupos y el proceso de eliminación de acceso. Si algunos sistemas no admiten el inicio de sesión único, incluir sus cuentas separadas en los procesos de contratación, cambios de rol y salida. El soporte para el inicio de sesión único no significa roles idénticos en todos los servicios.
Separar el trabajo diario de las acciones administrativas. Verificar la autenticación multifactor, las cuentas de integración, la expiración de las contraseñas y un método controlado para recuperar el acceso administrativo. No combinar todas las autorizaciones en una sola cuenta por conveniencia.
Asignar un propietario para todo el servicio
Cada plataforma puede cumplir sus propios compromisos mientras que el proceso general sigue siendo defectuoso. Asignar a alguien que sea responsable de todo el problema y que coordine al equipo local, a los proveedores y al operador de conectividad. Registrar los contactos, los límites de responsabilidad y el proceso de escalada en el registro del servicio.
El tipo de servicio afecta a la forma en que se divide el trabajo. Con una máquina virtual, la empresa puede poseer el sistema y la aplicación de invitado. Con una aplicación en la nube lista para usar, puede gestionar el acceso y la configuración. Los servicios en la nube no eliminan la responsabilidad de los datos y las cuentas. Verificar el alcance del trabajo en la documentación y el contrato del servicio elegido, en lugar de confiar únicamente en la palabra «multicloud».
Evaluar la portabilidad y la resiliencia sin promesas
Un segundo proveedor no elimina la dependencia del primero.
Una aplicación puede depender de las interfaces de una plataforma, el formato de la base de datos, el servicio de identidad y las licencias. Un contenedor simplifica el empaquetado de una parte de la aplicación, pero no hace que una base de datos externa o los permisos de acceso sean idénticos en diferentes nubes. Verifique la portabilidad de toda la cadena de trabajo.
Describa la ruta de salida: qué datos puede exportar, en qué formato, quién puede acceder a la exportación y dónde se ejecutará la aplicación posteriormente. Verifique las conexiones restauradas y el trabajo del usuario. Si la migración no se ha probado, regístrela como una limitación en lugar de una capacidad lista.
Diferentes nubes no reemplazan un plan de recuperación.
Si el correo electrónico se utiliza con un proveedor y un sitio web con otro, el sitio web no se convierte en un sistema de recuperación de correo electrónico. Ejecutar la misma carga de trabajo en otra plataforma requiere una aplicación compatible, datos actuales, acceso, enrutamiento y un procedimiento de conmutación de fallo probado. Un proveedor de identidad o conectividad compartido puede seguir siendo un único punto de fallo.
Registre el resultado requerido durante un fallo y verifique a través de pruebas. Un plan detallado de recuperación ante desastres y las opciones de ubicación de copia de seguridad son tareas separadas. Identifique qué dependencia requiere ese plan y quién lo mantiene.
Calcule el costo de la complejidad adicional.
Agregue los costos y el monitoreo en una sola vista.
Agregue los términos de intercambio de datos, las conexiones, las herramientas de gestión, las licencias, el soporte y el tiempo de los especialistas en las facturas del proveedor. El beneficio de un servicio individual puede desaparecer una vez que se incluye la integración. Los términos de transferencia de datos varían según el servicio y la ruta. Calcule los flujos reales, en lugar de solo el volumen de almacenamiento.
Utilice etiquetas comunes para los propietarios de los recursos, los propósitos y los entornos, siempre que sea posible. Consolidar los costos por servicio de negocio y monitorear las desviaciones. Una etiqueta compartida no elimina las diferencias entre las facturas y las reglas de dos plataformas.
Verifique los límites de un panel de control de gestión compartido.
Un panel de control unificado ayuda cuando muestra los recursos y los eventos que necesita. Verifique su alcance: plataformas y operaciones compatibles, frescura de los datos y comportamiento cuando falla la conectividad. Algunas actualizaciones, investigaciones y configuraciones aún pueden requerir las propias herramientas del proveedor.
Supervise el proceso de negocio, no solo los servidores. Para el intercambio de pedidos, es útil tener visibilidad de las transferencias exitosas, las colas y los errores. Defina quién recibe las alertas, quién las verifica y cómo el equipo distingue los datos obsoletos de un sistema saludable.
Establezca las reglas antes de automatizar acciones repetitivas
Una pequeña empresa no siempre necesita una plataforma de orquestación separada. Primero, defina las reglas para la asignación de recursos, la verificación de cambios y la eliminación de componentes no deseados. Luego, elija una herramienta que reduzca el trabajo manual a su escala. La automatización sin una regla común simplemente reproducirá configuraciones inconsistentes más rápidamente.
Para cada acción automatizada, defina permisos, un registro de resultados y un proceso de reversión. Verifique quién mantiene el flujo de trabajo cuando el proveedor cambia su interfaz y quién puede realizar la tarea si la herramienta falla. Un equipo de desarrollo dedicado, contenedores y una orquestación compleja deben seguir los requisitos de la aplicación. No son características obligatorias de la multicloud.
Complete la lista de verificación antes de agregar un proveedor
|
Pregunta |
Qué registrar |
|---|---|
|
Qué tarea resuelve el nuevo servicio |
Qué requisito no puede cumplir el entorno actual |
|
Qué sistemas dependen unos de otros |
Un mapa de flujos de datos, inicio de sesión y acceso administrativo |
|
Qué datos cruzan entornos |
Tipos de datos, rutas y ubicaciones permitidas para el procesamiento |
|
Qué funciona sin conectividad externa |
Funciones disponibles y el proceso para volver a la operación |
|
Quién otorga y revoca permisos |
El responsable del proceso y una lista de cuentas separadas |
|
Quién es responsable del resultado final |
El propietario del servicio y los datos de contacto de los participantes |
|
Cómo se ha verificado la portabilidad |
Un resultado de prueba o una limitación explícita |
|
Qué ocurre si un proveedor falla |
Un escenario de operación y un requisito de recuperación separado |
|
Cómo se visualizan los errores y los costes |
Fuentes de eventos, responsables y componentes de costes |
|
Si el equipo tiene la capacidad suficiente |
Habilidades requeridas, personal de respaldo y alcance del soporte |
|
Cómo finalizar el servicio |
Formatos de exportación, acceso, horarios y términos de finalización |
Traducir las restricciones de datos en requisitos específicos: ubicaciones permitidas para el procesamiento, acceso del personal, registros y condiciones de soporte. La implementación local o una nube privada por sí sola no demuestran el cumplimiento. Verifique la aplicabilidad en todo el sistema y las obligaciones actuales de la empresa.
Después de completar la lista de verificación, designe un responsable y una condición de decisión para cada pregunta abierta. Si se necesita un nuevo servicio solo para una función, pruebe esa función con el intercambio de datos y el acceso del usuario reales. Decida sobre la expansión después de verificar los resultados, en lugar de simplemente observar una demostración de una plataforma general.
Seleccione el entorno para una tarea confirmada
Primero, describa las aplicaciones, proveedores y dependencias. Luego, identifique dónde se necesita la integración y qué capacidades puede soportar el equipo. Un entorno híbrido conecta los componentes necesarios, mientras que la multicloud ofrece la opción de servicios de diferentes proveedores. Un proceso de trabajo con propietarios claros y límites demuestra el beneficio.
Para evaluar las conexiones y los requisitos de gestión existentes, discuta la infraestructura en la nube y híbrida con los expertos de DK. Comience con una lista de sistemas, proveedores y dependencias problemáticas.
