Crea arquitecturas híbridas y multinube con Google Cloud

Last reviewed 2024-11-27 UTC

En esta guía de arquitectura se ofrecen consejos prácticos sobre cómo planificar y diseñar tus entornos híbridos y multinube con Google Cloud. Este es el primero de los tres documentos del conjunto. En él se analizan las oportunidades y las consideraciones asociadas a estas arquitecturas desde el punto de vista empresarial y tecnológico. También analiza y describe muchos patrones de arquitectura híbrida y multinube probados.

El conjunto de documentos sobre patrones de arquitectura híbridos y multinube consta de las siguientes partes:

Puedes leer cada uno de estos artículos sobre arquitectura de forma independiente, pero, para sacar el máximo partido, te recomendamos que los leas en secuencia antes de tomar una decisión sobre la arquitectura.

El rápido ritmo de los cambios en las demandas del mercado ha aumentado los requisitos y las expectativas que se imponen a la TI empresarial, como la escalabilidad dinámica, el aumento del rendimiento para optimizar la experiencia de usuario y la seguridad. Muchas empresas de gran tamaño tienen dificultades para satisfacer estas demandas y expectativas utilizando solo infraestructuras y procesos tradicionales. Los departamentos de TI también están sometidos a presión para mejorar su rentabilidad, lo que dificulta la justificación de inversiones de capital adicionales en centros de datos y equipos.

Una estrategia de nube híbrida que utilice las funciones de computación en la nube pública ofrece una solución pragmática. Al usar la nube pública, puedes ampliar la capacidad y las prestaciones de tus plataformas de computación sin incurrir en costes de inversión inicial.

Si añades una o varias soluciones basadas en la nube pública, como Google Cloud, a tu infraestructura, no solo conservarás tus inversiones, sino que también evitarás depender de un único proveedor de servicios en la nube. Además, si usas una estrategia híbrida, puedes modernizar las aplicaciones y los procesos de forma incremental a medida que los recursos lo permitan.

Para ayudarte a planificar tu decisión de arquitectura y tu estrategia híbrida o multicloud, debes tener en cuenta varios posibles problemas y consideraciones de diseño. En esta guía de arquitectura de varias partes se destacan tanto las ventajas potenciales de varias arquitecturas como los posibles retos.

Descripción general de la nube híbrida y la multinube

Como las cargas de trabajo, la infraestructura y los procesos son únicos para cada empresa, cada estrategia de nube híbrida debe adaptarse a tus necesidades específicas. Por eso, los términos nube híbrida y multinube se usan a veces de forma incoherente.

En el contexto de esta Google Cloud guía de arquitectura, el término nube híbrida describe una arquitectura en la que las cargas de trabajo se despliegan en varios entornos informáticos, de los cuales uno de ellos está basado en la nube pública y por lo menos otro es privado (por ejemplo, un centro de datos on-premise o una instalación de coubicación).

El término multicloud describe una arquitectura que combina al menos dos proveedores de servicios en la nube públicos. Como se ilustra en el siguiente diagrama, a veces esta arquitectura incluye un entorno de computación privado (que puede incluir el uso de un componente de nube privada). Esta configuración se denomina arquitectura híbrida y multinube.

Diagrama de las tres arquitecturas que se analizan en esta serie: híbrida, multinube y una combinación de arquitecturas híbridas y multinube.

Colaboradores

Autor: Marwan Al Shawi | Ingeniero de clientes de partners

Otros colaboradores:

Factores, consideraciones, estrategias y enfoques

En este documento se definen y se analizan los objetivos, los factores y los requisitos empresariales, así como la forma en que estos factores pueden influir en las decisiones de diseño al crear arquitecturas híbridas y multinube.

Objetivos

Una organización puede adoptar una arquitectura híbrida o multinube como solución permanente para cumplir objetivos empresariales específicos o como estado temporal para facilitar ciertos requisitos, como una migración a la nube.

Responder a las siguientes preguntas sobre tu empresa es una buena forma de definir tus requisitos empresariales y establecer expectativas específicas sobre cómo alcanzar algunos o todos tus objetivos de negocio. Estas preguntas se centran en lo que necesita tu empresa, no en cómo conseguirlo técnicamente.

  • ¿Qué objetivos de negocio impulsan la decisión de adoptar una arquitectura híbrida o multicloud?
  • ¿Qué objetivos empresariales y técnicos se pueden alcanzar con una arquitectura híbrida o multinube?
  • ¿Qué factores empresariales han influido en estos objetivos?
  • ¿Cuáles son los requisitos empresariales específicos?

En el contexto de las arquitecturas híbridas y multicloud, un objetivo empresarial de un cliente de empresa podría ser ampliar las operaciones o los mercados de ventas online de una sola región para convertirse en uno de los líderes mundiales de su segmento de mercado. Uno de los objetivos empresariales podría ser empezar a aceptar órdenes de compra de usuarios de todo el mundo (o de regiones específicas) en un plazo de seis meses.

Para cumplir los requisitos y objetivos empresariales mencionados anteriormente, un posible objetivo técnico principal es ampliar la infraestructura de TI y la arquitectura de aplicaciones de una empresa de un modelo solo local a una arquitectura híbrida, utilizando las funciones y los servicios globales de las nubes públicas. Este objetivo debe ser específico y medible, y debe definir claramente el ámbito de la expansión en términos de regiones objetivo y plazos.

Por lo general, una arquitectura híbrida o multinube rara vez es un objetivo en sí mismo, sino un medio para alcanzar objetivos técnicos impulsados por determinados requisitos empresariales. Por lo tanto, para elegir la arquitectura híbrida o multinube adecuada, primero debes definir estos requisitos.

Es importante diferenciar entre los objetivos empresariales y los objetivos técnicos de tu proyecto de TI. Los objetivos de tu empresa deben centrarse en el objetivo y la misión de tu organización. Tus objetivos técnicos deben centrarse en crear una base tecnológica que permita a tu organización cumplir sus requisitos y objetivos empresariales.

Los factores empresariales influyen en la consecución de los objetivos de negocio. Por lo tanto, identificar claramente los factores empresariales puede ayudar a definir los objetivos de negocio para que se adapten mejor a las necesidades y tendencias del mercado.

En el siguiente diagrama de flujo se muestran los factores, los objetivos y los requisitos empresariales, así como los objetivos y los requisitos técnicos, y cómo se relacionan entre sí:

Diagrama de flujo que muestra los aspectos que se deben tener en cuenta al desarrollar los requisitos técnicos, como los factores, los objetivos y los requisitos empresariales, así como los objetivos técnicos.

Factores empresariales y técnicos

Ten en cuenta cómo influyen los factores que impulsan tu negocio en tus objetivos técnicos. Algunos de los factores empresariales comunes e influyentes a la hora de elegir una arquitectura híbrida son los siguientes:

  • Cumplir las leyes y los reglamentos sobre la soberanía de los datos.
  • Reducir el gasto de capital o el gasto general en TI con la ayuda de la gestión financiera en la nube y disciplinas de optimización de costes como FinOps.
    • La adopción de la nube puede estar motivada por situaciones que ayuden a reducir los gastos de capital, como la creación de una solución de recuperación tras desastres en una arquitectura híbrida o multinube.
  • Mejorar la experiencia de usuario.
  • Aumentar la flexibilidad y la agilidad para responder a los cambios en las demandas del mercado.
  • Mejorar la transparencia sobre los costes y el consumo de recursos.

Analiza la lista de factores empresariales que os llevan a adoptar una arquitectura híbrida o multinube. No los analices de forma aislada. La decisión final debe basarse en el equilibrio de las prioridades de tu empresa.

Una vez que tu organización se dé cuenta de las ventajas de la nube, puede que decida migrar por completo si no hay restricciones (como costes o requisitos de cumplimiento específicos que exijan que los datos altamente sensibles se alojen en las instalaciones) que se lo impidan.

Aunque adoptar un único proveedor de servicios en la nube puede ofrecer varias ventajas, como una menor complejidad, integraciones entre servicios y opciones de optimización de costes como los descuentos por uso comprometido, hay algunas situaciones en las que una arquitectura multinube puede ser beneficiosa para una empresa. A continuación, se indican los motivos empresariales habituales para adoptar una arquitectura multicloud, así como las consideraciones asociadas a cada motivo:

  • Cumplir las leyes y los reglamentos sobre la soberanía de los datos: el caso más habitual es cuando una organización amplía su negocio a una nueva región o país y tiene que cumplir nuevas normativas sobre el alojamiento de datos.
    • Si el proveedor de servicios en la nube (CSP) que se está usando no tiene ninguna región de nube local en ese país, la solución habitual para cumplir los requisitos es usar otro CSP que sí tenga una región de nube local en ese país.
  • Reducción de costes: la reducción de costes suele ser el factor empresarial más habitual para adoptar una tecnología o una arquitectura. Sin embargo, es importante tener en cuenta más factores que el coste de los servicios y los posibles descuentos en los precios a la hora de decidir si se adopta una arquitectura multicloud. Ten en cuenta el coste de crear y operar una solución en varias nubes, así como las restricciones de la arquitectura que puedan surgir en los sistemas que ya se tengan.

A veces, los posibles problemas asociados a una estrategia multicloud pueden superar a las ventajas. Una estrategia multinube puede conllevar costes adicionales más adelante.

Entre los retos habituales asociados al desarrollo de una estrategia multicloud se incluyen los siguientes:

  • Aumenta la complejidad de la gestión.
  • Mantener una seguridad coherente.
  • Integrar entornos de software.
  • Conseguir un rendimiento y una fiabilidad coherentes entre nubes.
  • Crear un equipo técnico con conocimientos sobre multinube puede ser caro y requerir la ampliación del equipo, a menos que lo gestione una empresa externa.
  • Gestionar los precios de los productos y las herramientas de gestión de cada proveedor de servicios en la nube.
  • Usar las funciones únicas de cada proveedor de servicios en la nube: una arquitectura multinube permite a las organizaciones usar nuevas tecnologías adicionales para mejorar sus propias ofertas de funciones empresariales sin limitarse a las opciones que ofrezca un único proveedor de servicios en la nube.
    • Para evitar riesgos o complejidades imprevistos, evalúa los posibles problemas mediante una evaluación de viabilidad y eficacia, incluidos los problemas habituales mencionados anteriormente.
  • Evitar la dependencia de proveedores: a veces, las empresas quieren evitar depender de un único proveedor de servicios en la nube. Una estrategia multinube les permite elegir la mejor solución para las necesidades de su empresa. Sin embargo, la viabilidad de esta decisión depende de varios factores, como los siguientes:
    • Dependencias técnicas
    • Consideraciones sobre la interoperabilidad entre aplicaciones
    • Costes de reconstrucción o refactorización de aplicaciones
    • Conjuntos de conocimientos técnicos
    • Seguridad y gestión coherentes
  • Mejorar la fiabilidad y el nivel de disponibilidad de las aplicaciones empresariales críticas: en algunos casos, una arquitectura multinube puede proporcionar resistencia ante las interrupciones. Por ejemplo, si una región de un CSP deja de funcionar, el tráfico se puede dirigir a otro CSP de la misma región. En este caso, se da por hecho que ambos proveedores de la nube admiten las funciones o los servicios necesarios en esa región.

Cuando las normativas de residencia de datos de un país o una región concretos exigen que los datos sensibles, como la información personal identificable (IPI), se almacenen en esa ubicación, un enfoque multicloud puede proporcionar una solución que cumpla los requisitos. Al usar dos CSPs en una región para ofrecer resiliencia ante las interrupciones, puedes facilitar el cumplimiento de las restricciones normativas y, al mismo tiempo, satisfacer los requisitos de disponibilidad.

A continuación, se indican algunas consideraciones sobre la resiliencia que debes tener en cuenta antes de adoptar una arquitectura multicloud:

  • Movimiento de datos: ¿con qué frecuencia se pueden mover los datos en tu entorno multicloud?
    • ¿El movimiento de datos puede generar cargos importantes por transferencia de datos?
  • Seguridad y gestión: ¿hay alguna complejidad potencial en cuanto a seguridad o gestión?
  • Paridad de funciones: ¿ofrecen ambos CSPs de la región seleccionada las funciones y los servicios necesarios?
  • Conocimientos técnicos: ¿el equipo técnico tiene las habilidades necesarias para gestionar una arquitectura multinube?

Ten en cuenta todos estos factores al evaluar la viabilidad de usar una arquitectura multicloud para mejorar la resiliencia.

Al evaluar la viabilidad de una arquitectura multicloud, es importante tener en cuenta las ventajas a largo plazo. Por ejemplo, desplegar aplicaciones en varias nubes para la recuperación tras fallos o mejorar la fiabilidad puede aumentar los costes a corto plazo, pero también puede evitar que se produzcan interrupciones o errores. Estos fallos pueden provocar daños económicos y de reputación a largo plazo. Por lo tanto, es importante sopesar los costes a corto plazo y el valor potencial a largo plazo de adoptar un entorno multinube. Además, el valor potencial a largo plazo puede variar en función del tamaño de la organización, la escala de la tecnología, la importancia de la solución tecnológica y el sector.

Las organizaciones que quieran crear un entorno híbrido o multinube con éxito deben plantearse crear un centro de excelencia de Cloud (COE). Un equipo del centro de excelencia puede convertirse en el canal para transformar la forma en que los equipos internos de tu organización prestan servicios a la empresa durante la transición a la nube. Un centro de excelencia es una de las formas en las que tu organización puede adoptar la nube más rápido, impulsar la estandarización y mantener una mayor alineación entre tu estrategia empresarial y tus inversiones en la nube.

Si el objetivo de la arquitectura híbrida o multinube es crear un estado temporal, los factores empresariales habituales son los siguientes:

  • La necesidad de reducir la inversión de capital o el gasto general en TI para proyectos a corto plazo.
  • La capacidad de aprovisionar esa infraestructura rápidamente para dar soporte a un caso práctico empresarial. Por ejemplo:
    • Esta arquitectura se puede usar en proyectos de duración limitada. Se podría usar para admitir un proyecto que requiera una infraestructura distribuida a gran escala durante un periodo limitado, sin dejar de usar los datos locales.
  • La necesidad de proyectos de transformación digital plurianuales que requieren que una gran empresa establezca y utilice una arquitectura híbrida durante un tiempo para alinear la modernización de su infraestructura y sus aplicaciones con sus prioridades empresariales.
  • La necesidad de crear una arquitectura híbrida, multinube o mixta temporal tras una fusión empresarial. De esta forma, la nueva organización puede definir una estrategia para el estado final de su nueva arquitectura de nube. Es habitual que dos empresas que se fusionan usen diferentes proveedores de servicios en la nube, o que una de ellas use un centro de datos privado on‐premise y la otra, la nube. En cualquier caso, el primer paso en una fusión o adquisición empresarial es casi siempre integrar los sistemas de TI.

Factores técnicos

En la sección anterior se han tratado los factores empresariales. Para obtener la aprobación, las decisiones arquitectónicas importantes casi siempre necesitan el apoyo de esos impulsores. Sin embargo, los factores técnicos, que pueden basarse en una ventaja o una limitación técnica, también pueden influir en los factores empresariales. En algunos casos, es necesario traducir los factores técnicos en factores empresariales y explicar cómo pueden afectar a la empresa de forma positiva o negativa.

En la siguiente lista no exhaustiva se incluyen algunos de los motivos técnicos más habituales para adoptar una arquitectura híbrida o multicloud:

  • Desarrollar funciones tecnológicas, como servicios de analíticas avanzadas e IA, que podrían ser difíciles de implementar en entornos actuales.
  • Mejorar la calidad y el rendimiento del servicio.
  • Automatizar y acelerar los lanzamientos de aplicaciones para conseguir un tiempo de lanzamiento más rápido y ciclos más cortos.
  • Usar APIs y servicios de alto nivel para acelerar el desarrollo.
  • Acelerar el aprovisionamiento de recursos de computación y almacenamiento.
  • Usar servicios sin servidor para crear servicios y funciones elásticos más rápido y a gran escala.
  • Usar las funciones de la infraestructura global para crear arquitecturas globales o multirregionales que cumplan determinados requisitos técnicos.

El motivo técnico más habitual para usar arquitecturas híbridas y multinube temporales es facilitar la migración de entornos on-premise a la nube o a otra nube. En general, las migraciones a la nube casi siempre derivan en una configuración de nube híbrida. Las empresas suelen tener que migrar aplicaciones y datos de forma sistemática en función de sus prioridades. Del mismo modo, una configuración a corto plazo puede tener como objetivo facilitar una prueba de concepto con tecnologías avanzadas disponibles en la nube durante un periodo determinado.

Decisiones de diseño técnico

El objetivo técnico identificado y sus factores son fundamentales para tomar una decisión de arquitectura basada en la empresa y para seleccionar uno de los patrones de arquitectura que se describen en esta guía. Por ejemplo, para alcanzar un objetivo de negocio concreto, una empresa puede fijar el objetivo de desarrollar una práctica de investigación y desarrollo durante un periodo de entre tres y seis meses. El principal requisito empresarial para alcanzar este objetivo podría ser crear el entorno tecnológico necesario para la investigación y el diseño con el menor CAPEX posible.

En este caso, el objetivo técnico es tener una configuración de nube híbrida temporal. El objetivo técnico es aprovechar el modelo de precios bajo demanda de la nube para cumplir el requisito empresarial mencionado anteriormente. Otro factor es la influencia de los requisitos tecnológicos específicos que requieren una solución basada en la nube con una gran capacidad de computación y una configuración rápida.

Usar Google Cloud para arquitecturas híbridas y multinube

Usar soluciones de software libre puede facilitar la adopción de un enfoque híbrido y multinube, así como minimizar la dependencia de un proveedor. Sin embargo, debes tener en cuenta las siguientes posibles complejidades al planificar una arquitectura:

  • Interoperabilidad
  • Facilidad de gestión
  • Coste
  • Seguridad

Si desarrollas tu actividad en una plataforma en la nube que contribuye al software libre y lo admite, podrás simplificar la adopción de arquitecturas híbridas y multinube. La nube abierta te ofrece un enfoque que te permite elegir lo que quieras y abstraer la complejidad. Además, Google Cloud ofrece la flexibilidad de migrar, crear y optimizar aplicaciones en entornos híbridos y multinube, a la vez que reduce la dependencia de proveedores, usa las mejores soluciones y cumple los requisitos normativos.

Google también es uno de los principales colaboradores del ecosistema de software libre y trabaja con la comunidad de software libre para desarrollar tecnologías de código abierto muy conocidas, como Kubernetes. Si se implementa como un servicio gestionado, Kubernetes puede ayudar a reducir la complejidad de la gestión y la seguridad de los entornos híbridos y multinube.

Planificar una estrategia híbrida y multinube

Este documento se centra en cómo aplicar consideraciones empresariales predefinidas al planificar una estrategia híbrida y multinube. Se amplía la información de la sección Factores, consideraciones, estrategias y enfoques. En ese artículo se definen y analizan las consideraciones empresariales que deben tener en cuenta las empresas al planificar una estrategia de este tipo.

Clarificar y acordar la visión y los objetivos

En última instancia, el objetivo principal de una estrategia de nube híbrida o multinube es cumplir los requisitos de negocio identificados y los objetivos técnicos asociados de cada caso de uso empresarial, que deben estar alineados con objetivos de negocio específicos. Para conseguir este objetivo, crea un plan bien estructurado que incluya los siguientes aspectos:

Ten en cuenta que definir un plan que tenga en cuenta todas las cargas de trabajo y los requisitos es difícil en el mejor de los casos, sobre todo en un entorno de TI complejo. Además, la planificación lleva tiempo y puede dar lugar a visiones contradictorias de las partes interesadas.

Para evitar estas situaciones, formula inicialmente una declaración de la visión que responda (como mínimo) a las siguientes preguntas:

  • ¿Cuál es el caso práctico empresarial objetivo para cumplir objetivos de negocio específicos?
  • ¿Por qué no son suficientes el enfoque y el entorno informático actuales para alcanzar los objetivos de negocio?
  • ¿Cuáles son los principales aspectos tecnológicos que se pueden optimizar al usar la nube pública?
  • ¿Por qué y cómo va a optimizar y alcanzar tus objetivos de negocio el nuevo enfoque?
  • ¿Cuánto tiempo tiene previsto usar su configuración híbrida o multinube?

Acordar los objetivos y los factores clave empresariales y técnicos, y obtener la aprobación de las partes interesadas pertinentes puede sentar las bases para los siguientes pasos del proceso de planificación. Para alinear de forma eficaz la solución que propones con la visión arquitectónica general de tu organización, ponte de acuerdo con tu equipo y con las partes interesadas responsables de dirigir y patrocinar esta iniciativa.

Identificar y aclarar otras consideraciones

Al planificar una arquitectura híbrida o multinube, es importante identificar y acordar las restricciones arquitectónicas y operativas de tu proyecto.

En cuanto a las operaciones, la siguiente lista no exhaustiva proporciona algunos requisitos que pueden crear ciertas restricciones que debes tener en cuenta al planificar tu arquitectura:

  • Gestionar y configurar varias nubes por separado en lugar de crear un modelo integral para gestionar y proteger los diferentes entornos de nube.
  • Asegurar la coherencia de la autenticación, la autorización, la auditoría y las políticas en los distintos entornos.
  • Usar herramientas y procesos coherentes en todos los entornos para ofrecer una visión integral de la seguridad, los costes y las oportunidades de optimización.
  • Usar estándares de cumplimiento y seguridad coherentes para aplicar un gobierno unificado.

En cuanto a la planificación de la arquitectura, las mayores limitaciones suelen derivarse de los sistemas actuales y pueden incluir lo siguiente:

  • Dependencias entre aplicaciones
  • Requisitos de rendimiento y latencia para la comunicación entre sistemas
  • Dependencia de hardware o sistemas operativos que podrían no estar disponibles en la nube pública
  • Restricciones de licencia
  • Dependencia de la disponibilidad de las funciones necesarias en las regiones seleccionadas de una arquitectura multicloud

Para obtener más información sobre otras consideraciones relacionadas con la portabilidad de las cargas de trabajo, el movimiento de datos y los aspectos de seguridad, consulta Otras consideraciones.

Diseñar una estrategia de arquitectura híbrida y multinube

Una vez que hayas aclarado los detalles de los objetivos empresariales y técnicos con los requisitos empresariales asociados (y, a ser posible, hayas definido y acordado una declaración de principios), podrás crear tu estrategia para diseñar una arquitectura híbrida o multicloud.

En el siguiente diagrama de flujo se resumen los pasos lógicos para crear una estrategia de este tipo.

Cuando elabores una estrategia, ten en cuenta tus objetivos de negocio, consigue la aprobación de las partes interesadas, crea un plan general y, a continuación, úsalo para definir tu estrategia.

Para ayudarte a determinar los objetivos y las necesidades técnicas de tu arquitectura híbrida o multinube, los pasos del diagrama de flujo anterior empiezan con los requisitos y los objetivos empresariales. La forma de implementar tu estrategia puede variar en función de los objetivos, los factores y la ruta de migración tecnológica de cada caso práctico.

Es importante recordar que una migración es un proceso. El siguiente diagrama muestra las fases de este proceso, tal como se describe en el artículo Migrar a Google Cloud.

Ruta de migración con cuatro fases.

En esta sección se ofrecen directrices sobre las fases "Evaluar", "Planificar", "Implementar" y "Optimizar" del diagrama anterior. Presenta esta información en el contexto de una migración híbrida o multinube. Debes alinear cualquier migración con las directrices y las prácticas recomendadas que se describen en la sección de rutas de migración de la guía Migrar a Google Cloud . Estas fases pueden aplicarse a cada carga de trabajo por separado, no a todas a la vez. En cualquier momento, varias cargas de trabajo pueden estar en diferentes fases:

Fase de evaluación

En la fase de Evaluación, se lleva a cabo una evaluación inicial de la carga de trabajo. Durante esta fase, ten en cuenta los objetivos que se describen en los documentos de planificación de tu visión y estrategia. Decide un plan de migración. Para ello, identifica primero una lista de cargas de trabajo que se podrían beneficiar de desplegarse o migrarse a la nube pública.

Para empezar, elige una carga de trabajo que no sea crítica para la empresa ni demasiado difícil de migrar (con dependencias mínimas o nulas de cualquier carga de trabajo en otros entornos), pero que sea lo suficientemente típica como para servir de modelo para futuras implementaciones o migraciones.

Lo ideal es que la carga de trabajo o la aplicación que selecciones forme parte de un caso de uso o una función empresarial específicos que tengan un efecto medible en la empresa una vez que se hayan completado.

Para evaluar y mitigar los posibles riesgos de la migración, realiza una evaluación de los riesgos de la migración. Es importante que evalúes la carga de trabajo candidata para determinar si es adecuada para migrar a un entorno multicloud. Esta evaluación implica valorar varios aspectos de las aplicaciones y la infraestructura, entre los que se incluyen los siguientes:

  • Requisitos de compatibilidad de las aplicaciones con los proveedores de servicios en la nube que hayas seleccionado
  • Modelos de precios
  • Funciones de seguridad que ofrecen los proveedores de servicios en la nube que hayas seleccionado
  • Requisitos de interoperabilidad de las aplicaciones

Realizar una evaluación también te ayuda a identificar los requisitos de privacidad de los datos, los requisitos de cumplimiento, los requisitos de coherencia y las soluciones en varios entornos de nube. Los riesgos que identifiques pueden afectar a las cargas de trabajo que elijas migrar o utilizar.

Hay varios tipos de herramientas, como Google Cloud Migration Center, para ayudarte a evaluar las cargas de trabajo actuales. Para obtener más información, consulta Migración a Google Cloud: elige una herramienta de evaluación.

Desde el punto de vista de la modernización de las cargas de trabajo, la herramienta de evaluación de adecuación ayuda a evaluar una carga de trabajo de una VM para determinar si es adecuada para modernizarla a un contenedor o para migrarla a Compute Engine.

Fase de planificación

En la fase Planificación, empieza con las aplicaciones y las cargas de trabajo en la nube identificadas y lleva a cabo las siguientes tareas:

  1. Desarrolla una estrategia de migración priorizada que defina las fases de migración de aplicaciones y las rutas.
  2. Identifica el patrón de arquitectura de aplicación híbrida o multinube de alto nivel que corresponda.
  3. Seleccione un patrón de arquitectura de red que admita el patrón de arquitectura de aplicación seleccionado.

Lo ideal es que incorpores el patrón de red de Cloud al diseño de la zona de aterrizaje. El diseño de la zona de aterrizaje es un elemento fundamental de las arquitecturas híbridas y multinube. El diseño requiere una integración perfecta con estos patrones. No diseñes la zona de aterrizaje de forma aislada. Considera estos patrones de red como un subconjunto del diseño de la zona de aterrizaje.

Una zona de aterrizaje puede constar de diferentes aplicaciones, cada una con un patrón de arquitectura de red diferente. Además, en esta fase, es importante decidir el diseño de la Google Cloud organización, los proyectos y la jerarquía de recursos para preparar la zona de aterrizaje de tu entorno de nube para la integración y la implementación híbrida o multinube.

Como parte de esta fase, debes tener en cuenta lo siguiente:

  • Define la estrategia de migración y modernización. En esta guía se ofrece más información sobre los enfoques de migración. También se explica con más detalle en la sección Tipos de migración del artículo Migrar a Google Cloud.
  • Usa las conclusiones de la fase de evaluación y descubrimiento. Alinea los con la carga de trabajo candidata que quieras migrar. A continuación, desarrolla un plan de olas de migración de la aplicación. El plan debe incluir los requisitos de tamaño de los recursos estimados que hayas determinado durante la fase de evaluación.
  • Define el modelo de comunicación necesario entre las aplicaciones distribuidas y entre los componentes de la aplicación para la arquitectura híbrida o multinube prevista.
  • Elige un arquetipo de implementación adecuado para implementar tu carga de trabajo, como zonal, regional, multirregional o global, para el patrón de arquitectura elegido. El arquetipo que selecciones será la base para crear las arquitecturas de implementación específicas de la aplicación que se adapten a tus necesidades empresariales y técnicas.
  • Decide los criterios de éxito medibles de la migración, con hitos claros para cada fase o etapa de la migración. Es fundamental seleccionar criterios, aunque el objetivo técnico sea tener la arquitectura híbrida como configuración a corto plazo.
  • Define los SLAs y los KPIs de las aplicaciones cuando estas funcionen en una configuración híbrida, sobre todo en el caso de las aplicaciones que puedan tener componentes distribuidos en varios entornos.

Para obtener más información, consulta el artículo Acerca de la planificación de la migración, que te ayudará a planificar una migración correcta y a minimizar los riesgos asociados.

Fase de implementación

En la fase Implementar, ya puedes empezar a ejecutar tu estrategia de migración. Dado el número potencial de requisitos, lo mejor es adoptar un enfoque iterativo.

Prioriza tus cargas de trabajo en función de las fases de migración y de las aplicaciones que hayas desarrollado durante la fase de planificación. Con las arquitecturas híbridas y multinube, empieza tu implementación estableciendo la conectividad necesaria entre Google Cloud y los demás entornos informáticos. Para facilitar el modelo de comunicación necesario para tu arquitectura híbrida o multinube, basa la implementación en el diseño y el tipo de conectividad de red que hayas seleccionado, así como en el patrón de red aplicable. Te recomendamos que adoptes este enfoque para tomar una decisión sobre el diseño general de tu zona de aterrizaje.

Además, debes probar y validar la aplicación o el servicio según los criterios de éxito definidos. Lo ideal es que estos criterios incluyan requisitos de pruebas funcionales y de carga (no funcionales) antes de pasar a producción.

Fase de optimización

En la fase de optimización, prueba tu implementación: cuando hayas terminado las pruebas y la aplicación o el servicio cumplan las expectativas de capacidad funcional y de rendimiento, podrás pasarla a producción. Las herramientas de monitorización y visibilidad de la nube, como Cloud Monitoring, pueden proporcionar información valiosa sobre el rendimiento, la disponibilidad y el estado de tus aplicaciones e infraestructura, así como ayudarte a optimizar lo que necesites.

Para obtener más información, consulta el artículo Migrar a Google Cloud: optimizar el entorno. Para obtener más información sobre cómo diseñar este tipo de herramientas para arquitecturas híbridas o multinube, consulta Patrones de monitorización y registro híbridos y multinube.

Evaluar las cargas de trabajo de los candidatos

La elección de los entornos de computación para las diferentes cargas de trabajo influye significativamente en el éxito de una estrategia híbrida y multinube. Las decisiones sobre la colocación de cargas de trabajo deben estar en consonancia con objetivos empresariales específicos. Por lo tanto, estas decisiones deben basarse en casos prácticos empresariales específicos que permitan obtener resultados empresariales medibles. Sin embargo, no siempre es necesario ni recomendable empezar por la carga de trabajo o la aplicación más importante para la empresa. Para obtener más información, consulta el artículo Elegir las aplicaciones que se migrarán primero de la guía Migrar a Google Cloud .

Como se explica en la sección Factores empresariales y técnicos, hay diferentes tipos de factores y consideraciones para las arquitecturas híbridas y multinube.

La siguiente lista resumida de factores puede ayudarte a evaluar tu caso práctico de migración en el contexto de una arquitectura híbrida o multinube con oportunidades para tener un efecto empresarial medible:

  • Posibilidad de diferenciación o innovación en el mercado gracias al uso de servicios en la nube para habilitar determinadas funciones o capacidades empresariales, como las de inteligencia artificial, que utilizan datos locales para entrenar modelos de aprendizaje automático.
  • Ahorro potencial en el coste total de propiedad de una aplicación.
  • Posibles mejoras en la disponibilidad, la resiliencia, la seguridad o el rendimiento, por ejemplo, añadiendo un sitio de recuperación tras desastres en la nube.
  • Posibilidad de acelerar los procesos de desarrollo y lanzamiento, por ejemplo, creando tus entornos de desarrollo y pruebas en la nube.

Los siguientes factores pueden ayudarte a evaluar los riesgos de la migración:

  • El posible efecto de las interrupciones causadas por una migración.
  • La experiencia de tu equipo con los despliegues en la nube pública o con los despliegues de un proveedor de servicios en la nube nuevo o secundario.
  • La necesidad de cumplir las restricciones legales o normativas vigentes.

Los siguientes factores pueden ayudarte a evaluar las dificultades técnicas de una migración:

  • El tamaño, la complejidad y la antigüedad de la aplicación.
  • El número de dependencias con otras aplicaciones y servicios en diferentes entornos informáticos.
  • Cualquier restricción impuesta por licencias de terceros.
  • Cualquier dependencia de versiones específicas de sistemas operativos, bases de datos u otras configuraciones del entorno.

Una vez que hayas evaluado tus cargas de trabajo iniciales, puedes empezar a priorizarlas y a definir tus fases de migración y enfoques. Después, puedes identificar los patrones de arquitectura aplicables y los patrones de redes compatibles. Este paso puede requerir varias iteraciones, ya que tu evaluación puede cambiar con el tiempo. Por lo tanto, merece la pena volver a evaluar las cargas de trabajo después de hacer las primeras implementaciones en la nube.

Enfoques arquitectónicos para adoptar una arquitectura híbrida o multinube

En este documento se ofrecen directrices sobre enfoques y consideraciones comunes y probados para migrar tu carga de trabajo a la nube. Se trata de una ampliación de la guía Diseñar una estrategia de arquitectura híbrida y multinube, que aborda varios pasos posibles y recomendados para diseñar una estrategia de adopción de una arquitectura híbrida o multinube.

Prioridad de la nube

Una forma habitual de empezar a usar la nube pública es con la estrategia primero la nube. Con este enfoque, despliegas tus nuevas cargas de trabajo en la nube pública, mientras que las cargas de trabajo que ya tienes se quedan donde están. En ese caso, plantéate hacer un despliegue clásico en un entorno de computación privado solo si no es posible hacer un despliegue en una nube pública por motivos técnicos o de organización.

La estrategia de priorizar la nube tiene ventajas y desventajas. Por otro lado, es una herramienta prospectiva. Puedes desplegar nuevas cargas de trabajo de forma modernizada y, al mismo tiempo, evitar (o al menos minimizar) los problemas que conlleva migrar las cargas de trabajo que ya tienes.

Aunque una estrategia cloud-first puede ofrecer ciertas ventajas, podría provocar que se pierdan oportunidades de mejorar o usar cargas de trabajo. Las cargas de trabajo nuevas pueden representar una fracción del panorama de TI general y su efecto en los gastos y el rendimiento de TI puede ser limitado. Asignar tiempo y recursos a la migración de una carga de trabajo ya existente podría generar más ventajas o ahorros de costes que intentar adaptar una carga de trabajo nueva al entorno de la nube.

Si sigues un enfoque cloud-first estricto, también corres el riesgo de aumentar la complejidad general de tu entorno de TI. Este enfoque puede crear redundancias, reducir el rendimiento debido a una comunicación excesiva entre entornos o dar lugar a un entorno informático que no se adapte bien a la carga de trabajo individual. Además, el cumplimiento de las normativas del sector y las leyes de privacidad de los datos puede impedir que las empresas migren determinadas aplicaciones que contengan datos sensibles.

Teniendo en cuenta estos riesgos, puede que te convenga más usar un enfoque que dé prioridad a la nube solo para determinadas cargas de trabajo. Si adoptas una estrategia basada en la nube, puedes centrarte en las cargas de trabajo que más se beneficien de una implementación o migración a la nube. Este enfoque también tiene en cuenta la modernización de las cargas de trabajo actuales.

Un ejemplo habitual de arquitectura híbrida cloud-first es cuando las aplicaciones y los servicios antiguos que contienen datos críticos deben integrarse con datos o aplicaciones nuevos. Para completar la integración, puedes usar una arquitectura híbrida que modernice los servicios antiguos mediante interfaces de API, lo que permite que los nuevos servicios y aplicaciones en la nube los utilicen. Con una plataforma de gestión de APIs en la nube, como Apigee, puedes implementar estos casos prácticos con cambios mínimos en la aplicación y añadir seguridad, analíticas y escalabilidad a los servicios antiguos.

Migración y modernización

La multinube híbrida y la modernización de TI son conceptos distintos que están vinculados en un círculo virtuoso. Usar la nube pública puede facilitar y simplificar la modernización de las cargas de trabajo de TI. Modernizar tus cargas de trabajo de TI puede ayudarte a sacar más partido a la nube.

Los objetivos principales de la modernización de las cargas de trabajo son los siguientes:

  • Consigue una mayor agilidad para adaptarte a los cambios en los requisitos.
  • Reduzca los costes de su infraestructura y sus operaciones.
  • Aumenta la fiabilidad y la resiliencia para minimizar los riesgos.

Sin embargo, puede que no sea viable modernizar todas las aplicaciones del proceso de migración al mismo tiempo. Como se describe en Migración a Google Cloud, puedes implementar uno de los siguientes tipos de migración o incluso combinar varios tipos según sea necesario:

  • Cambio de alojamiento (migrar mediante lift-and-shift)
  • Cambio de plataforma (trasladar y optimizar)
  • Refactorizar (migrar y mejorar)
  • Cambiar de arquitectura (seguir modernizando)
  • Recompilación (eliminar y sustituir, a veces denominado sustitución por completo)
  • Volver a comprar

Cuando tomes decisiones estratégicas sobre tus arquitecturas híbridas y multicloud, es importante que tengas en cuenta la viabilidad de tu estrategia desde el punto de vista de los costes y los plazos. Puede que te interese adoptar un enfoque de migración por fases, empezando por la migración tal cual o la migración a otra plataforma, y luego refactorizar o rediseñar la arquitectura como paso siguiente. Por lo general, la migración lift-and-shift ayuda a optimizar las aplicaciones desde el punto de vista de la infraestructura. Una vez que las aplicaciones se ejecutan en la nube, es más fácil usar e integrar servicios en la nube para optimizarlas aún más con arquitecturas y funciones cloud-first. Además, estas aplicaciones pueden seguir comunicándose con otros entornos a través de una conexión de red híbrida.

Por ejemplo, puedes refactorizar o rediseñar la arquitectura de una aplicación grande y monolítica basada en VMs y convertirla en varios microservicios independientes basados en una arquitectura de microservicios en la nube. En este ejemplo, la arquitectura de microservicios usa Google Cloud servicios de contenedores gestionados, como Google Kubernetes Engine (GKE) o Cloud Run. Sin embargo, si la arquitectura o la infraestructura de una aplicación no se admiten en el entorno de nube de destino tal como están, puedes empezar por replataformar, refactorizar o rediseñar tu estrategia de migración para superar esas limitaciones cuando sea posible.

Cuando utilices cualquiera de estos métodos de migración, considera la posibilidad de modernizar tus aplicaciones (si procede y es viable). La modernización puede requerir la adopción e implementación de los principios de ingeniería de fiabilidad de sitios (SRE) o de DevOps, por lo que también puede que tengas que extender la modernización de las aplicaciones a tu entorno privado en una configuración híbrida. Aunque la implementación de los principios de SRE implica la ingeniería en su esencia, se trata más de un proceso de transformación que de un reto técnico. Por lo tanto, es probable que requiera cambios en los procedimientos y en la cultura. Para obtener más información sobre cómo conseguir el apoyo de la dirección es el primer paso para implementar la SRE en una organización, consulta el artículo Con la SRE, no planificar es planificar el fracaso.

Combinar enfoques de migración

Cada enfoque de migración que se describe aquí tiene sus ventajas y desventajas. Una de las principales ventajas de seguir una estrategia híbrida y multinube es que no es necesario decantarse por un solo enfoque. En su lugar, puedes decidir qué enfoque se adapta mejor a cada carga de trabajo o pila de aplicaciones, como se muestra en el siguiente diagrama.

Diagrama de flujo que muestra diferentes enfoques para migrar cargas de trabajo desde tu entorno de nube.

Este diagrama conceptual ilustra las distintas rutas o enfoques de migración y modernización que se pueden aplicar simultáneamente a diferentes cargas de trabajo, en función de los requisitos y objetivos técnicos y empresariales únicos de cada carga de trabajo o aplicación.

Además, no es necesario que los componentes de la misma pila de aplicaciones sigan el mismo enfoque o estrategia de migración. Por ejemplo:

  • La base de datos backend local de una aplicación se puede cambiar de plataforma de MySQL autogestionado a una base de datos gestionada mediante Cloud SQL en Google Cloud.
  • Las máquinas virtuales de frontend de la aplicación se pueden refactorizar para que se ejecuten en contenedores mediante Autopilot de GKE, donde Google gestiona la configuración del clúster, incluidos los nodos, el escalado, la seguridad y otros ajustes preconfigurados.
  • La solución de balanceo de carga de hardware local y las funciones del cortafuegos de aplicaciones web (WAF) se pueden sustituir por Cloud Load Balancing y Google Cloud Armor.

Elige la opción de cambiar el alojamiento (lift and shift) si se cumple alguna de las siguientes condiciones en las cargas de trabajo:

  • Tienen un número relativamente pequeño de dependencias en su entorno.
  • No se considera que merezca la pena refactorizarlo o no es viable hacerlo antes de la migración.
  • Se basan en software de terceros.

Considera la refactorización (migración y mejora) para estos tipos de cargas de trabajo:

  • Tienen dependencias que deben resolverse.
  • Se basan en sistemas operativos, hardware o sistemas de bases de datos que no se pueden alojar en la nube.
  • No están aprovechando los recursos de computación o almacenamiento de forma eficiente.
  • No se pueden implementar de forma automática sin esfuerzo.

Determina si la recompilación (eliminar y sustituir) se adapta a tus necesidades en estos tipos de cargas de trabajo:

  • Ya no cumplen los requisitos actuales.
  • Se pueden incorporar a otras aplicaciones que ofrezcan funciones similares sin poner en riesgo los requisitos empresariales.
  • Se basan en tecnología de terceros que ha llegado al final de su ciclo de vida.
  • Requieren tarifas de licencia de terceros que ya no son económicas.

El Programa de Migración Rápida muestra cómo Google Cloud ayuda a los clientes a usar las prácticas recomendadas, reducir los riesgos, controlar los costes y simplificar el proceso para alcanzar el éxito en la nube.

Otras cuestiones:

En este documento se destacan las consideraciones de diseño principales que desempeñan un papel fundamental en la configuración de la arquitectura híbrida y multinube general. Analiza y evalúa de forma integral estos aspectos en toda la arquitectura de tu solución, incluidas todas las cargas de trabajo, no solo algunas específicas.

Refactorizar

En una migración de refactorización, se modifican las cargas de trabajo para aprovechar las prestaciones de la nube, no solo para que funcionen en el nuevo entorno. Puedes mejorar cada carga de trabajo en cuanto a rendimiento, funciones, coste y experiencia de usuario. Como se destaca en Refactorizar: mover y mejorar, algunos casos prácticos de refactorización te permiten modificar cargas de trabajo antes de migrarlas a la nube. Este enfoque de refactorización ofrece las siguientes ventajas, sobre todo si tu objetivo es crear una arquitectura híbrida como arquitectura objetivo a largo plazo:

  • Puedes mejorar el proceso de implementación.
  • Puedes acelerar la cadencia de lanzamientos y acortar los ciclos de comentarios invirtiendo en infraestructura y herramientas de integración y despliegue continuos (CI/CD).
  • Puedes usar la refactorización como base para crear y gestionar una arquitectura híbrida con portabilidad de aplicaciones.

Para que este enfoque funcione bien, normalmente se requiere una inversión en infraestructura y herramientas locales. Por ejemplo, configurar un registro de contenedores local y aprovisionar clústeres de Kubernetes para contenerizar aplicaciones. La edición Enterprise de Google Kubernetes Engine (GKE) puede ser útil en este enfoque para entornos híbridos. En la siguiente sección se ofrece más información sobre GKE Enterprise. También puedes consultar la arquitectura de referencia del entorno híbrido de GKE Enterprise para obtener más información.

Portabilidad de las cargas de trabajo

Con las arquitecturas híbridas y multinube, es posible que quieras poder transferir cargas de trabajo entre los entornos informáticos que alojan tus datos. Para facilitar el movimiento fluido de las cargas de trabajo entre entornos, ten en cuenta los siguientes factores:

  • Puedes mover una aplicación de un entorno informático a otro sin modificarla significativamente ni su modelo operativo:
    • La implementación y la gestión de aplicaciones son coherentes en todos los entornos de computación.
    • La visibilidad, la configuración y la seguridad son coherentes en todos los entornos informáticos.
  • La capacidad de hacer que una carga de trabajo sea portátil no debe entrar en conflicto con el hecho de que la carga de trabajo esté diseñada para la nube.

Automatización de infraestructuras

La automatización de la infraestructura es esencial para la portabilidad en arquitecturas híbridas y multinube. Una forma habitual de automatizar la creación de infraestructuras es mediante la infraestructura como código (IaC). La IaC implica gestionar tu infraestructura en archivos en lugar de configurar manualmente los recursos (como una VM, un grupo de seguridad o un balanceador de carga) en una interfaz de usuario. Terraform es una herramienta de IaC popular que permite definir recursos de infraestructura en un archivo. Terraform también te permite automatizar la creación de esos recursos en entornos heterogéneos.

Para obtener más información sobre las funciones principales de Terraform que pueden ayudarte a automatizar el aprovisionamiento y la gestión de recursos, consulta Planos y módulos de Terraform para Google Cloud. Google Cloud

Puedes usar herramientas de gestión de la configuración, como Ansible, Puppet o Chef, para establecer un proceso de despliegue y configuración común. También puedes usar una herramienta de creación de imágenes, como Packer, para crear imágenes de VM para diferentes plataformas. Si usas un único archivo de configuración compartido, puedes usar Packer y Cloud Build para crear una imagen de VM que se pueda usar en Compute Engine. Por último, puedes usar soluciones como Prometheus y Grafana para asegurarte de que la monitorización sea coherente en todos los entornos.

Con estas herramientas, puedes crear una cadena de herramientas común, como se muestra en el siguiente diagrama lógico. Esta cadena de herramientas común abstrae las diferencias entre los entornos de computación. También te permite unificar el aprovisionamiento, la implementación, la gestión y la monitorización.

Una cadena de herramientas permite la portabilidad de las aplicaciones.

Aunque una cadena de herramientas común puede ayudarte a conseguir la portabilidad, está sujeta a varias de las siguientes limitaciones:

  • Si se usan máquinas virtuales como base común, puede resultar difícil implementar aplicaciones que realmente estén diseñadas para la nube. Además, si solo usas máquinas virtuales, no podrás usar servicios gestionados en la nube. Puede que no aproveches oportunidades para reducir la sobrecarga administrativa.
  • Crear y mantener una cadena de herramientas común conlleva costes operativos y de infraestructura.
  • A medida que se amplía la cadena de herramientas, puede desarrollar complejidades únicas adaptadas a las necesidades específicas de tu empresa. Este aumento de la complejidad puede contribuir a que aumenten los costes de entrenamiento.

Antes de decidirte por desarrollar herramientas y automatizaciones, explora los servicios gestionados que ofrece tu proveedor de servicios en la nube. Cuando tu proveedor ofrece servicios gestionados que admiten el mismo caso práctico, puedes abstraer parte de su complejidad. De esta forma, puedes centrarte en la carga de trabajo y en la arquitectura de la aplicación en lugar de en la infraestructura subyacente.

Por ejemplo, puedes usar el modelo de recursos de Kubernetes para automatizar la creación de clústeres de Kubernetes mediante un enfoque de configuración declarativo. Puedes usar Deployment Manager convert para convertir tus configuraciones y plantillas de Deployment Manager a otros formatos de configuración declarativa que admita Google Cloud (como Terraform y el modelo de recursos de Kubernetes) para que sean portátiles cuando publiques.

También puedes automatizar la creación de proyectos y de recursos en esos proyectos. Esta automatización puede ayudarte a adoptar un enfoque de infraestructura como código para aprovisionar proyectos.

Contenedores y Kubernetes

El uso de funciones gestionadas en la nube ayuda a reducir la complejidad de crear y mantener una cadena de herramientas personalizada para automatizar y portar cargas de trabajo. Sin embargo, si solo se usan las máquinas virtuales como base común, resulta difícil implementar aplicaciones que sean realmente nativas de la nube. Una solución es usar contenedores y Kubernetes.

Los contenedores ayudan a que tu software se ejecute de forma fiable cuando lo mueves de un entorno a otro. Como los contenedores desacoplan las aplicaciones de la infraestructura del host subyacente, facilitan el despliegue en entornos informáticos, como los híbridos y multinube.

Kubernetes se encarga de la orquestación, el despliegue, el escalado y la gestión de tus aplicaciones en contenedores. Es de código abierto y está gestionado por la Cloud Native Computing Foundation. Usar Kubernetes proporciona los servicios que forman la base de una aplicación que prioriza la nube. Como puedes instalar y ejecutar Kubernetes en muchos entornos informáticos, también puedes usarlo para establecer una capa de tiempo de ejecución común en diferentes entornos informáticos:

  • Kubernetes ofrece los mismos servicios y APIs en un entorno de computación en la nube o privado. Además, el nivel de abstracción es mucho mayor que cuando se trabaja con máquinas virtuales, lo que generalmente se traduce en menos trabajo preliminar y una mayor productividad de los desarrolladores.
  • A diferencia de una cadena de herramientas personalizada, Kubernetes se usa en muchos sitios para el desarrollo y la gestión de aplicaciones, por lo que puedes aprovechar la experiencia, la documentación y la asistencia de terceros.
  • Kubernetes admite todas las implementaciones de contenedores que:

Cuando una carga de trabajo se ejecuta en Google Cloud, puedes evitar el esfuerzo de instalar y operar Kubernetes usando una plataforma de Kubernetes gestionada, como Google Kubernetes Engine (GKE). De esta forma, el personal de operaciones puede centrarse en crear y mantener aplicaciones en lugar de infraestructuras.

También puedes usar Autopilot, un modo de funcionamiento de GKE que gestiona la configuración de tu clúster, incluidos los nodos, el escalado, la seguridad y otros ajustes preconfigurados. Cuando uses Autopilot de GKE, ten en cuenta los requisitos de escalado y los límites de escalado.

Técnicamente, puedes instalar y ejecutar Kubernetes en muchos entornos de computación para establecer una capa de tiempo de ejecución común. Sin embargo, en la práctica, crear y operar una arquitectura de este tipo puede generar complejidad. La arquitectura se vuelve aún más compleja cuando necesitas un control de seguridad a nivel de contenedor (malla de servicios).

Para simplificar la gestión de implementaciones multiclúster, puedes usar GKE Enterprise para ejecutar aplicaciones modernas en cualquier lugar a gran escala. GKE incluye potentes componentes de código abierto gestionados para proteger las cargas de trabajo, aplicar políticas de cumplimiento y proporcionar una observabilidad y una resolución de problemas de red profundas.

Como se muestra en el siguiente diagrama, si usas GKE Enterprise, puedes operar aplicaciones multiclúster como flotas.

Diagrama de pila que muestra las oportunidades de gestión de flotas que ofrece GKE Enterprise.

GKE Enterprise ofrece las siguientes opciones de diseño para admitir arquitecturas híbridas y multinube:

  • Diseña y crea experiencias similares a la nube on-premise o soluciones unificadas para migrar aplicaciones al entorno híbrido de GKE Enterprise. Para obtener más información, consulta la arquitectura de referencia del entorno híbrido de GKE Enterprise.

  • Diseña y crea una solución para resolver la complejidad multinube con una postura de gobernanza, operaciones y seguridad coherente con GKE Multi-Cloud. Para obtener más información, consulta la documentación de GKE multicloud.

GKE Enterprise también proporciona agrupaciones lógicas de entornos similares con seguridad, configuración y gestión de servicios coherentes. Por ejemplo, GKE Enterprise ofrece una arquitectura distribuida de confianza cero. En una arquitectura distribuida de confianza cero, los servicios que se implementan de forma local o en otro entorno de nube pueden comunicarse entre entornos mediante comunicaciones de servicio a servicio seguras con mTLS de extremo a extremo.

Consideraciones sobre la portabilidad de las cargas de trabajo

Kubernetes y GKE Enterprise proporcionan una capa de abstracción para las cargas de trabajo que puede ocultar las numerosas complejidades y diferencias entre los entornos de computación. En la siguiente lista se describen algunas de esas abstracciones:

  • Una aplicación puede ser portátil a otro entorno con cambios mínimos, pero eso no significa que la aplicación funcione igual de bien en ambos entornos.
    • Las diferencias en los recursos de computación subyacentes, las funciones de seguridad de la infraestructura o la infraestructura de red, así como la proximidad a los servicios dependientes, pueden dar lugar a un rendimiento muy diferente.
  • Para mover una carga de trabajo entre entornos de computación, también es posible que tengas que mover datos.
    • Los distintos entornos pueden tener diferentes servicios e instalaciones de almacenamiento y gestión de datos.
  • El comportamiento y el rendimiento de los balanceadores de carga aprovisionados con Kubernetes o GKE Enterprise pueden variar de un entorno a otro.

Migración de datos

Como puede ser complejo mover, compartir y acceder a datos a gran escala entre entornos informáticos, las empresas de nivel empresarial pueden dudar a la hora de crear una arquitectura híbrida o multinube. Esta reticencia puede aumentar si ya almacenan la mayoría de sus datos de forma local o en una nube.

Sin embargo, las distintas opciones de movimiento de datos que ofrece Google Cloudproporcionan a las empresas un conjunto completo de soluciones para mover, integrar y transformar sus datos. Estas opciones ayudan a las empresas a almacenar, compartir y acceder a datos en diferentes entornos de una forma que se adapte a sus casos prácticos específicos. En última instancia, esta capacidad facilita a los responsables de la toma de decisiones empresariales y tecnológicas la adopción de arquitecturas híbridas y multinube.

El movimiento de datos es un aspecto importante que se debe tener en cuenta en la estrategia híbrida y multinube, así como en la planificación de la arquitectura. Tu equipo debe identificar los distintos casos prácticos de tu empresa y los datos que los respaldan. También debes tener en cuenta el tipo de almacenamiento, la capacidad, la accesibilidad y las opciones de movimiento.

Si una empresa tiene una clasificación de datos para sectores regulados, esa clasificación puede ayudar a identificar las ubicaciones de almacenamiento y las restricciones de movimiento de datos entre regiones para determinadas clases de datos. Para obtener más información, consulta Protección de Datos Sensibles. Protección de Datos Sensibles es un servicio totalmente gestionado diseñado para ayudarte a descubrir, clasificar y proteger tus recursos de datos.

Para conocer el proceso, desde la planificación de una transferencia de datos hasta las prácticas recomendadas para implementar un plan, consulte el artículo Migrar a Google Cloud: transferir conjuntos de datos grandes.

Seguridad

A medida que las organizaciones adoptan arquitecturas híbridas y multinube, su superficie de ataque puede aumentar en función de la forma en que se distribuyan sus sistemas y datos en diferentes entornos. Si a esto le sumamos el panorama de amenazas en constante evolución, el aumento de las superficies de ataque puede provocar un mayor riesgo de acceso no autorizado, pérdida de datos y otros incidentes de seguridad. Ten en cuenta la seguridad al planificar e implementar estrategias de nube híbrida o multinube.

Para obtener más información, consulta Attack Surface Management para Google Cloud.

Al diseñar una arquitectura híbrida, no siempre es técnicamente posible o viable extender los enfoques de seguridad locales a la nube. Sin embargo, muchas de las funciones de seguridad de redes de los dispositivos de hardware son funciones cloud-first y funcionan de forma distribuida. Para obtener más información sobre las funciones de seguridad de redes en la nube de Google Cloud, consulta Seguridad de redes en la nube.

Las arquitecturas híbridas y multinube pueden plantear problemas de seguridad adicionales, como la coherencia y la observabilidad. Cada proveedor de nube pública tiene su propio enfoque de seguridad, que incluye diferentes modelos, prácticas recomendadas, funciones de seguridad de infraestructura y aplicaciones, obligaciones de cumplimiento e incluso los nombres de los servicios de seguridad. Estas incoherencias pueden aumentar el riesgo de seguridad. Además, el modelo de responsabilidad compartida de cada proveedor de la nube puede ser diferente. Es fundamental identificar y comprender la demarcación exacta de las responsabilidades en una arquitectura multinube.

La observabilidad es fundamental para obtener estadísticas y métricas de los diferentes entornos. En una arquitectura multinube, cada nube suele proporcionar herramientas para monitorizar la postura de seguridad y los errores de configuración. Sin embargo, el uso de estas herramientas da lugar a una visibilidad aislada, lo que impide crear inteligencia de amenazas avanzada en todo el entorno. Por lo tanto, el equipo de seguridad debe cambiar entre herramientas y paneles de control para mantener la nube protegida. Si no se tiene una visibilidad de seguridad integral en los entornos híbridos y multinube, es difícil priorizar y mitigar las vulnerabilidades.

Para obtener una visibilidad y una postura completas de todos tus entornos, prioriza tus vulnerabilidades y mitiga las que identifiques. Recomendamos un modelo de visibilidad centralizado. Un modelo de visibilidad centralizado evita la necesidad de correlacionar manualmente diferentes herramientas y paneles de control de distintas plataformas. Para obtener más información, consulta Patrones de almacenamiento de registros y monitorización para despliegues híbridos y multinube.

Como parte de la planificación para mitigar los riesgos de seguridad y desplegar cargas de trabajo enGoogle Cloud, y para ayudarte a planificar y diseñar tu solución en la nube con el fin de alcanzar tus objetivos de seguridad y cumplimiento, consulta el centro de prácticas recomendadas de seguridad y el blueprint de aspectos básicos de seguridad para empresas. Google Cloud

Los objetivos de cumplimiento pueden variar, ya que se ven influidos tanto por las normativas específicas del sector como por los diferentes requisitos normativos de las distintas regiones y países. Para obtener más información, consulta el Google Cloud Centro de recursos para el cumplimiento. A continuación, se indican algunos de los enfoques principales recomendados para diseñar arquitecturas híbridas y multinube seguras:

  • Desarrollar una estrategia y una arquitectura de seguridad en la nube unificadas y personalizadas. Las estrategias de seguridad híbrida y multicloud deben adaptarse a las necesidades y los objetivos específicos de tu organización.

    Es fundamental conocer la arquitectura y el entorno de destino antes de implementar los controles de seguridad, ya que cada entorno puede usar diferentes funciones, configuraciones y servicios.

  • Plantéate usar una arquitectura de seguridad unificada en entornos híbridos y multinube.

  • Estandarizar el diseño y los despliegues en la nube, especialmente el diseño y las funciones de seguridad. De esta forma, se puede mejorar la eficiencia y habilitar la gobernanza y las herramientas unificadas.

  • Usa varios controles de seguridad.

    Por lo general, ningún control de seguridad puede cumplir adecuadamente todos los requisitos de protección de seguridad. Por lo tanto, las organizaciones deben usar una combinación de controles de seguridad en un enfoque de defensa por capas, también conocido como defensa en profundidad.

  • Monitoriza y mejora continuamente las posturas de seguridad: tu organización debe monitorizar sus diferentes entornos para detectar amenazas y vulnerabilidades de seguridad. También debe intentar mejorar continuamente su posición de seguridad.

  • Te recomendamos que uses la gestión de la postura de seguridad en la nube (CSPM) para identificar y corregir errores de configuración de seguridad y amenazas de ciberseguridad. CSPM también ofrece evaluaciones de vulnerabilidades en entornos híbridos y multinube.

Security Command Center es una solución integrada de gestión de riesgos y seguridad para Google Cloud que ayuda a identificar errores de configuración, vulnerabilidades y más. Security Health Analytics es una herramienta gestionada de análisis de evaluación de vulnerabilidades. Es una función de Security Command Center que identifica los riesgos y las vulnerabilidades de seguridad en tuGoogle Cloud entorno y proporciona recomendaciones para solucionarlos.

Mandiant Attack Surface Management for Google Cloud permite a tu organización ver mejor los recursos de su entorno multinube o de nube híbrida. Descubre automáticamente los recursos de varios proveedores de la nube, DNS y la superficie de ataque externa ampliada para que tu empresa conozca mejor su ecosistema. Usa esta información para priorizar la corrección de las vulnerabilidades y las exposiciones que supongan el mayor riesgo.

  • Solución de gestión de información y eventos de seguridad (SIEM) en la nube: ayuda a recoger y analizar registros de seguridad de entornos híbridos y multinube para detectar y responder a amenazas. SIEM de Google Security Operations de Google Cloud ayuda a proporcionar información de seguridad y gestión de eventos recogiendo, analizando, detectando e investigando todos tus datos de seguridad en un solo lugar.

Crea arquitecturas híbridas y multinube con Google Cloud: qué es lo siguiente