Compila arquitecturas híbridas y de múltiples nubes con Google Cloud

Last reviewed 2024-11-27 UTC

En esta guía de arquitectura, se proporciona orientación práctica para planificar y diseñar tus entornos híbridos y de múltiples nubes con Google Cloud. Este documento es el primero de un conjunto de tres. En él, se analizan las oportunidades y las consideraciones asociadas a estas arquitecturas desde un punto de vista empresarial y tecnológico. También analiza y explica muchos patrones de arquitectura híbrida y de múltiples nubes comprobados.

El conjunto de documentos sobre patrones de arquitectura híbrida y de múltiples nubes consta de las siguientes partes:

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

El rápido ritmo de cambio en las demandas del mercado aumentó los requisitos y las expectativas que se aplican a la TI empresarial, como el escalamiento dinámico, el aumento del rendimiento para una experiencia del usuario optimizada y la seguridad. A muchas empresas a nivel empresarial les resulta difícil satisfacer estas demandas y expectativas solo con la infraestructura y los procesos tradicionales. Los departamentos de TI también están bajo 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 utiliza capacidades de computación en la nube pública proporciona una solución pragmática. Con la nube pública, puedes ampliar la capacidad y las habilidades de tus plataformas de procesamiento sin costos de inversión inicial de capital.

Si agregas una o más soluciones basadas en la nube pública, como Google Cloud, a tu infraestructura existente, no solo conservarás tus inversiones existentes, sino que evitarás tener que comprometerte con un único proveedor de servicios en la nube. Además, con una estrategia híbrida, puedes modernizar las aplicaciones y los procesos de forma progresiva mientras los recursos lo permitan.

Para ayudarte a planificar tu decisión arquitectónica y tu estrategia híbrida o de múltiples nubes, debes tener en cuenta varios desafíos potenciales y consideraciones de diseño. En esta guía de arquitectura de varias partes, se destacan los posibles beneficios y desafíos de las distintas arquitecturas.

Descripción general de la nube híbrida y las múltiples nubes

Debido a que las cargas de trabajo, la infraestructura y los procesos son exclusivos de cada empresa, cada estrategia de nube híbrida debe adaptarse a tus necesidades específicas. El resultado es que los términos nube híbrida y multinube a veces se usan de forma inconsistente.

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 implementan en varios entornos de computación, uno basado en la nube pública y al menos uno privado, por ejemplo, un centro de datos local o una instalación de colocación.

El término múltiples nubes describe una arquitectura que combina al menos dos CSP públicos. Como se ilustra en el siguiente diagrama, a veces esta arquitectura incluye un entorno de procesamiento privado (que podría incluir el uso de un componente de nube privada). Ese diseño se denomina arquitectura híbrida y de múltiples nubes.

Diagrama de las tres arquitecturas analizadas en esta serie: híbrida, de múltiples nubes y una combinación de arquitecturas híbridas y de múltiples nubes.

Colaboradores

Autor: Marwan Al Shawi | Ingeniero de Atención al Cliente para Socios

Otros colaboradores:

Factores de impulso, consideraciones, estrategia y enfoques

En este documento, se definen y analizan los objetivos, los factores y los requisitos comerciales, y cómo estos factores pueden influir en tus decisiones de diseño cuando construyes arquitecturas híbridas y de varias nubes.

Objetivos

Una organización puede adoptar una arquitectura híbrida o de múltiples nubes como una solución permanente para cumplir con objetivos comerciales específicos o como un estado temporal para facilitar ciertos requisitos, como una migración a la nube.

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

  • ¿Qué objetivos comerciales impulsan la decisión de adoptar una arquitectura híbrida o de múltiples nubes?
  • ¿Qué objetivos comerciales y técnicos ayudará a lograr una arquitectura híbrida o de múltiples nubes?
  • ¿Qué impulsores comerciales influyeron en estos objetivos?
  • ¿Cuáles son los requisitos comerciales específicos?

En el contexto de las arquitecturas híbridas y de varias nubes, un objetivo comercial para un cliente empresarial podría ser expandir las operaciones o los mercados de ventas en línea de una sola región para convertirse en uno de los líderes globales en su segmento de mercado. Uno de los objetivos comerciales podría ser comenzar a aceptar órdenes de compra de usuarios de todo el mundo (o de regiones específicas) en un plazo de seis meses.

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

En general, una arquitectura híbrida o multinube rara vez es un objetivo en sí misma, sino más bien un medio para cumplir con objetivos técnicos impulsados por ciertos requisitos comerciales. Por lo tanto, para seleccionar la arquitectura híbrida o de múltiples nubes correcta, primero es necesario aclarar estos requisitos.

Es importante diferenciar entre los objetivos comerciales y los objetivos técnicos de tu proyecto de TI. Tus objetivos comerciales deben centrarse en la meta y la misión de tu organización. Tus objetivos técnicos deben enfocarse en crear una base tecnológica que permita a tu organización cumplir con sus requisitos y objetivos comerciales.

Los factores comerciales influyen en el logro de los objetivos comerciales y las metas. Por lo tanto, identificar claramente los factores comerciales puede ayudar a definir los objetivos o las metas comerciales para que sean más relevantes para las necesidades y las tendencias del mercado.

El siguiente diagrama de flujo ilustra los factores, los objetivos, las metas y los requisitos comerciales, así como los objetivos y requisitos técnicos, y cómo se relacionan todos estos factores entre sí:

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

Factores técnicos y comerciales

Ten en cuenta cómo los factores de impulso de tu negocio influyen en tus objetivos técnicos. Estos son algunos de los impulsores comerciales comunes e influyentes a la hora de elegir una arquitectura híbrida:

  • Acatamiento de leyes y reglamentos sobre la soberanía de los datos
  • Reducir el gasto de capital (CAPEX) o la inversión general en TI con el apoyo de las disciplinas de administración financiera y optimización de costos en la nube, como FinOps
    • La adopción de la nube puede estar impulsada por situaciones que ayudan a reducir el CAPEX, como la creación de una solución de recuperación ante desastres en una arquitectura híbrida o de varias nubes.
  • Mejorar la experiencia del usuario
  • Mayor flexibilidad y agilidad para responder a las cambiantes demandas del mercado
  • Mejorar la transparencia sobre los costos y el consumo de recursos

Consideren juntos la lista de motivos de negocio para adoptar una arquitectura híbrida o de múltiples nubes. No los consideres de forma aislada. Tu decisión final debe depender del equilibrio de las prioridades de tu empresa.

Después de que tu organización se dé cuenta de los beneficios de la nube, es posible que decida migrar por completo si no hay restricciones, como costos o requisitos de cumplimiento específicos que exijan que los datos altamente seguros se alojen de forma local, que le impidan hacerlo.

Si bien adoptar un solo proveedor de servicios en la nube puede ofrecer varios beneficios, como una menor complejidad, integraciones integradas entre los servicios y opciones de optimización de costos, como los descuentos por uso comprometido, aún existen algunas situaciones en las que una arquitectura de múltiples nubes puede ser beneficiosa para una empresa. A continuación, se indican los impulsores comerciales comunes para adoptar una arquitectura de múltiples nubes, junto con las consideraciones asociadas para cada impulsor:

  • Acatamiento de leyes y reglamentos sobre la soberanía de los datos: El caso más común es cuando una organización expande su empresa a una nueva región o país y debe cumplir con nuevas reglamentaciones de alojamiento de datos.
    • Si el proveedor de servicios en la nube (CSP) existente que se usa no tiene una región de nube local en ese país, para cumplir con los requisitos, la solución común es usar otro CSP que sí tenga una región de nube local en ese país.
  • Reducción de costos: La reducción de costos suele ser el factor comercial más común para adoptar una tecnología o arquitectura. Sin embargo, es importante tener en cuenta más que solo el costo de los servicios y los posibles descuentos en los precios cuando se decide adoptar una arquitectura de múltiples nubes. Ten en cuenta el costo de crear y operar una solución en múltiples nubes, y cualquier restricción de arquitectura que pueda surgir de los sistemas existentes.

A veces, los posibles desafíos asociados con una estrategia de múltiples nubes pueden superar los beneficios. Una estrategia de múltiples nubes puede generar costos adicionales más adelante.

Entre los desafíos habituales asociados con el desarrollo de una estrategia de múltiples nubes, se incluyen los siguientes:

  • Aumento de la complejidad de la administración
  • Mantener la seguridad de forma coherente
  • Integrar entornos de software
  • Lograr un rendimiento y una confiabilidad coherentes en múltiples nubes
  • Crear un equipo técnico con habilidades en múltiples nubes puede ser costoso y requerir la expansión del equipo, a menos que lo administre una empresa externa.
  • Administrar las herramientas de administración y precios de los productos de cada CSP
  • Uso de las capacidades únicas de cada CSP: Una arquitectura de múltiples nubes permite que las organizaciones usen nuevas tecnologías adicionales para mejorar sus propias ofertas de capacidades comerciales sin limitarse a las opciones que ofrece un solo proveedor de servicios en la nube.
    • Para evitar cualquier riesgo o complejidad imprevistos, evalúa tus posibles desafíos a través de una evaluación de factibilidad y eficacia, incluidos los desafíos comunes que se mencionaron anteriormente.
  • Evitar la dependencia de un solo proveedor: A veces, las empresas quieren evitar depender de un solo proveedor de servicios en la nube. Un enfoque de múltiples nubes les permite elegir la mejor solución para sus necesidades comerciales. Sin embargo, la viabilidad de esta decisión depende de varios factores, como los siguientes:
    • Dependencias técnicas
    • Consideraciones de interoperabilidad entre aplicaciones
    • Costos de refactorización o reconstrucción de aplicaciones
    • Conjuntos de habilidades técnicas
    • Seguridad y capacidad de administración coherentes
  • Mejora el nivel de confiabilidad y disponibilidad de las aplicaciones fundamentales para la empresa: En algunas situaciones, una arquitectura de múltiples nubes puede proporcionar resistencia a las interrupciones. Por ejemplo, si una región de un CSP deja de funcionar, el tráfico se puede enrutar a otro CSP en la misma región. En este caso, se supone que ambos proveedores de servicios en la nube admiten las capacidades o los servicios requeridos en esa región.

Cuando las reglamentaciones de residencia de datos de un país o región específicos exigen el almacenamiento de datos sensibles, como la información de identificación personal (PII), dentro de esa ubicación, un enfoque de múltiples nubes puede proporcionar una solución que cumpla con los requisitos. Si usas dos CSP en una región para proporcionar resiliencia ante las interrupciones, puedes facilitar el cumplimiento de las restricciones reglamentarias y, al mismo tiempo, abordar los requisitos de disponibilidad.

A continuación, se incluyen algunas consideraciones sobre la resiliencia que debes evaluar antes de adoptar una arquitectura de múltiples nubes:

  • Movimiento de datos: ¿Con qué frecuencia se pueden mover los datos dentro de tu entorno de varias nubes?
    • ¿El movimiento de datos puede generar cargos significativos por transferencia de datos?
  • Seguridad y capacidad de administración: ¿Existen posibles complejidades de seguridad o capacidad de administración?
  • Paridad de capacidades: ¿Ambos CSP de la región seleccionada ofrecen las capacidades y los servicios requeridos?
  • Conjunto de habilidades técnicas: ¿El equipo técnico tiene las habilidades necesarias para administrar una arquitectura de varias nubes?

Ten en cuenta todos estos factores cuando evalúes la viabilidad de usar una arquitectura de varias nubes para mejorar la resiliencia.

Cuando evalúes la viabilidad de una arquitectura de múltiples nubes, es importante que tengas en cuenta los beneficios a largo plazo. Por ejemplo, la implementación de aplicaciones en varias nubes para la recuperación ante desastres o el aumento de la confiabilidad puede aumentar los costos a corto plazo, pero podría evitar interrupciones o fallas. Estas fallas pueden causar daños financieros y de reputación a largo plazo. Por lo tanto, es importante comparar los costos a corto plazo con el valor potencial a largo plazo de adoptar múltiples nubes. Además, el potencial valor a largo plazo puede variar según el tamaño de la organización, la escala de la tecnología, la criticidad de la solución tecnológica y la industria.

Las organizaciones que planean crear con éxito un entorno híbrido o multinube deben considerar la creación de un centro de excelencia para la nube (COE) de Cloud. Un equipo del COE puede convertirse en el conducto para transformar la forma en que los equipos internos de tu organización atienden las necesidades de la empresa durante tu transición a la nube. Un COE es una de las formas en 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 comercial y tus inversiones en la nube.

Si el objetivo de la arquitectura híbrida o de múltiples nubes es crear un estado temporal, los factores comerciales comunes incluyen los siguientes:

  • La necesidad de reducir el CAPEX o la inversión general en TI para proyectos a corto plazo
  • La capacidad de aprovisionar rápidamente esa infraestructura para admitir un caso de uso comercial Por ejemplo:
    • Esta arquitectura se puede usar para proyectos de tiempo limitado. Se podría usar para respaldar un proyecto que requiere una infraestructura distribuida a gran escala durante un período limitado, y, al mismo tiempo, usar datos locales.
  • La necesidad de proyectos de transformación digital de varios años que requieren que una gran empresa establezca y use una arquitectura híbrida durante un tiempo para ayudarla a alinear la modernización de su infraestructura y sus aplicaciones con sus prioridades comerciales.
  • La necesidad de crear una arquitectura híbrida, de múltiples nubes o mixta temporal después de una fusión corporativa De esta manera, la nueva organización puede definir una estrategia para el estado final de su nueva arquitectura de nube. Es común que dos empresas que se fusionan usen diferentes proveedores de servicios en la nube, o que una empresa use un centro de datos privado local y la otra use la nube. En cualquier caso, el primer paso en la fusión y adquisición casi siempre es integrar los sistemas de TI.

Factores técnicos

En la sección anterior, se analizaron los impulsores del negocio. Para obtener la aprobación, las principales decisiones de arquitectura casi siempre necesitan el respaldo de esos impulsores. Sin embargo, los factores técnicos, que pueden basarse en una ganancia o una restricción técnica, también pueden influir en los factores comerciales. En algunos casos, es necesario traducir los factores técnicos en factores comerciales y explicar cómo podrían afectar positiva o negativamente a la empresa.

En la siguiente lista no exhaustiva, se incluyen algunos factores técnicos comunes para adoptar una arquitectura híbrida o de múltiples nubes:

  • Desarrollo de capacidades tecnológicas, como servicios de estadísticas avanzadas y de IA, que podrían ser difíciles de implementar en los entornos existentes
  • Mejora de la calidad y el rendimiento del servicio
  • Automatización y aceleración de lanzamientos de aplicaciones para lograr un tiempo de lanzamiento al mercado más rápido y ciclos más cortos
  • Uso de APIs y servicios de alto nivel para acelerar el desarrollo
  • Aceleración del aprovisionamiento de recursos de computación y almacenamiento
  • Usa servicios sin servidores para compilar servicios y capacidades elásticos más rápido y a gran escala.
  • Usar las capacidades de infraestructura global para compilar arquitecturas globales o multirregionales que satisfagan ciertos requisitos técnicos

El factor técnico más común para las arquitecturas híbridas y de múltiples nubes temporales es facilitar una migración desde las instalaciones locales a la nube o a una nube adicional. En general, las migraciones a la nube casi siempre generan naturalmente una configuración de nube híbrida. A menudo, las empresas deben realizar la transición de aplicaciones y datos de forma sistemática según sus prioridades. Del mismo modo, una configuración a corto plazo podría tener como objetivo facilitar una prueba de concepto con tecnologías avanzadas disponibles en la nube durante un período determinado.

Decisiones de diseño técnico

El objetivo técnico identificado y sus factores determinantes son clave para tomar una decisión de arquitectura basada en el negocio y seleccionar uno de los patrones de arquitectura que se analizan en esta guía. Por ejemplo, para respaldar un objetivo comercial específico, una empresa podría establecer el objetivo comercial de crear una práctica de investigación y desarrollo durante un período de tres a seis meses. El principal requisito comercial para respaldar este objetivo podría ser crear el entorno tecnológico necesario para la investigación y el diseño con el CAPEX más bajo 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 a pedido de la nube para cumplir con el requisito comercial mencionado anteriormente. Otro factor determinante son los requisitos tecnológicos específicos que exigen una solución basada en la nube con alta capacidad de procesamiento y configuración rápida.

Uso Google Cloud para arquitecturas híbridas y de múltiples nubes

Usar soluciones de código abierto puede facilitar la adopción de un enfoque híbrido y de múltiples nubes, y minimizar la dependencia de un proveedor. Sin embargo, debes tener en cuenta las siguientes complejidades potenciales cuando planifiques una arquitectura:

  • Interoperabilidad
  • Administración
  • Costo
  • Seguridad

Crear sobre una plataforma de nube que contribuya a respaldar el código abierto podría ayudarte a simplificar tu camino hacia la adopción de arquitecturas híbridas y de múltiples nubes. La nube abierta te brinda un enfoque que proporciona la máxima variedad de opciones y abstrae la complejidad. Además, Google Cloud ofrece la flexibilidad para migrar, compilar y optimizar aplicaciones en entornos híbridos y de múltiples nubes, a la vez que minimiza la dependencia de los proveedores, utiliza soluciones de primer nivel y satisface los requisitos normativos.

Google también es uno de los colaboradores más importantes del ecosistema de código abierto y trabaja con la comunidad de código abierto para desarrollar tecnologías de código abierto conocidas, como Kubernetes. Cuando se implementa como un servicio administrado, Kubernetes puede ayudar a reducir las complejidades en torno a la administración y la seguridad híbridas y de múltiples nubes.

Planifica una estrategia de nube híbrida y múltiples nubes

En este documento, se explica cómo aplicar consideraciones comerciales predefinidas cuando se planifica una estrategia de nube híbrida y múltiples nubes. Se amplía la orientación en factores de impulso, consideraciones, estrategia y enfoques. En ese artículo, se definen y analizan las consideraciones comerciales que las empresas deben tener en cuenta cuando planifican una estrategia de este tipo.

Aclara y acuerda la visión y los objetivos

En última instancia, el objetivo principal de una estrategia de nube híbrida o de múltiples nubes es satisfacer los requisitos comerciales identificados y los objetivos técnicos asociados para cada caso de uso comercial alineado con objetivos comerciales específicos. Para lograr este objetivo, crea un plan bien estructurado que incluya las siguientes consideraciones:

Ten en cuenta que definir un plan que considere todas las cargas de trabajo y los requisitos es difícil en el mejor de los casos, especialmente en un entorno de TI complejo. Además, la planificación lleva tiempo y puede generar conflicto entre las visiones de las partes interesadas.

Para evitar estas situaciones, primero formula una declaración de visión que aborde las siguientes preguntas (como mínimo):

  • ¿Cuál es el caso de uso comercial objetivo para cumplir con objetivos comerciales específicos?
  • ¿Por qué el enfoque y el entorno de computación actuales no son suficientes para cumplir con los objetivos comerciales?
  • ¿Cuáles son los principales aspectos tecnológicos que se deben optimizar con la nube pública?
  • ¿Por qué y cómo el nuevo enfoque optimizará y cumplirá tus objetivos comerciales?
  • ¿Por cuánto tiempo planeas usar tu configuración de nube híbrida o multinube?

Acuerdo sobre los objetivos y los factores de impulso comerciales y técnicos clave y, luego, obtener la aprobación relevante de las partes interesadas puede proporcionar una base para los siguientes pasos en el proceso de planificación. Para alinear de manera eficaz la solución propuesta con la visión arquitectónica general de la organización, alinéate con tu equipo y las partes interesadas responsables de liderar y patrocinar esta iniciativa.

Identificar y aclarar otras consideraciones

Cuando planifiques una arquitectura híbrida o de múltiples nubes, es importante identificar y acordar las restricciones operativas y de arquitectura de tu proyecto.

En cuanto a las operaciones, la siguiente lista no exhaustiva proporciona algunos requisitos que podrían generar ciertas restricciones que se deben tener en cuenta al planificar tu arquitectura:

  • Administrar y configurar varias nubes por separado en lugar de crear un modelo integral para administrar y proteger los diferentes entornos de nube
  • Garantizar la autenticación, la autorización, la auditoría y políticas coherentes en todos los entornos.
  • Usar herramientas y procesos coherentes en todos los entornos para proporcionar una visión integral de la seguridad, los costos y las oportunidades de optimización.
  • Usar estándares de cumplimiento y seguridad coherentes para aplicar una administración unificada

En el lado de la planificación de la arquitectura, se detallan las mayores limitaciones que generalmente derivan de los sistemas existentes:

  • Las dependencias entre las aplicaciones
  • Los requisitos de rendimiento y latencia para la comunicación entre los sistemas
  • Fiabilidad en el hardware o los sistemas operativos que podrían no estar disponibles en la nube pública
  • Restricciones de licencias
  • Dependencia de la disponibilidad de las capacidades requeridas en las regiones seleccionadas de una arquitectura de varias nubes

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

Diseña una estrategia de arquitectura híbrida y de múltiples nubes

Después de aclarar los detalles de los objetivos comerciales y técnicos con los requisitos comerciales asociados (y, de manera ideal, aclarar y acordar una declaración de visión), puedes crear tu estrategia para crear una arquitectura híbrida o de varias nubes.

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

Cuando elabores tu estrategia, ten en cuenta tus objetivos comerciales, obtén la aprobación, crea un plan general y, luego, úsalo para fundamentar tu estrategia.

Para ayudarte a determinar los objetivos y las necesidades técnicas de tu arquitectura híbrida o de múltiples nubes, los pasos del diagrama de flujo anterior comienzan con los objetivos y requisitos comerciales. La forma en que implementes tu estrategia puede variar según los objetivos, los factores de impulso y la ruta de migración tecnológica de cada caso de uso empresarial.

Es importante recordar que una migración es un viaje. En el siguiente diagrama, se ilustran las fases de este recorrido, tal como se describen en Migra a Google Cloud.

Ruta de migración con cuatro fases

En esta sección, se proporciona orientación sobre las fases de evaluación, planificación, implementación y optimización en el diagrama anterior. Presenta esta información en el contexto de una migración híbrida o de múltiples nubes. Debes alinear cualquier migración con la guía y las prácticas recomendadas que se analizan en la sección de la ruta de migración de la guía Migrar a Google Cloud . Estas fases pueden aplicarse a cada carga de trabajo de forma individual, 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, realiza una evaluación de carga de trabajo inicial. 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, primero identifica una lista de posibles cargas de trabajo que podrían beneficiarse de la implementación o la migración a la nube pública.

Para comenzar, elige una carga de trabajo que no sea fundamental para la empresa o que no sea demasiado difícil de migrar (con dependencias mínimas o nulas de cualquier carga de trabajo en otros entornos), pero que no sea lo suficientemente habitual para servir de modelo en las próximas implementaciones o migraciones.

Lo ideal sería que la carga de trabajo o la aplicación que selecciones forme parte de una función o un caso de uso empresarial orientado que tenga un efecto medible en la empresa una vez que se complete.

Para evaluar y mitigar los posibles riesgos de migración, realiza una evaluación de riesgos de migración. Es importante evaluar la carga de trabajo candidata para determinar su idoneidad para la migración a un entorno de múltiples nubes. Esta evaluación implica analizar varios aspectos de las aplicaciones y la infraestructura, incluidos los siguientes:

  • Requisitos de compatibilidad de las aplicaciones con los proveedores de servicios en la nube seleccionados
  • Modelos de precios
  • Funciones de seguridad que ofrecen los proveedores de servicios en la nube seleccionados
  • Requisitos de interoperabilidad de la aplicación

Ejecutar 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 las cargas de trabajo que elijas migrar o ejecutar.

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

Desde la perspectiva de la modernización de la carga de trabajo, la herramienta de evaluación de idoneidad ayuda a evaluar una carga de trabajo de VM para determinar si es adecuada para la modernización a un contenedor o para la migración a Compute Engine.

Fase de planificación

En la fase de planificación, comienza con las aplicaciones identificadas y las cargas de trabajo en la nube requeridas, y realiza 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 aplicaciones híbridas o de múltiples nubes de alto nivel aplicable.
  3. Selecciona un patrón de arquitectura de redes que admita el patrón de arquitectura de aplicaciones seleccionado.

Lo ideal es que incorpores el patrón de redes en la nube con el diseño de la zona de destino. El diseño de la zona de destino sirve como un elemento fundamental clave de las arquitecturas híbridas y de múltiples nubes generales. El diseño requiere una integración perfecta con estos patrones. No diseñes la zona de destino de forma aislada. Considera estos patrones de redes como un subconjunto del diseño de la zona de destino.

Una zona de destino 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 organización, los proyectos y la jerarquía de recursos para preparar la zona de destino del entorno de nube para la integración y la implementación híbrida o de múltiples nubes.Google Cloud

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

  • Define el enfoque de migración y modernización. Más adelante en esta guía, se proporciona 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 de Migra a Google Cloud.
  • Usa los hallazgos de la fase de evaluación y descubrimiento. Alinea los recursos con la carga de trabajo candidata que planeas migrar. Luego, desarrolla un plan de conjuntos de migración de la aplicación. El plan debe incorporar los requisitos de dimensionamiento de recursos estimados que determinaste 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 de múltiples nubes prevista.
  • Decide 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 constituirá la base para construir las arquitecturas de implementación específicas de la aplicación que se adapten a tus necesidades comerciales y técnicas.
  • Decide criterios de éxito medibles para la migración, con hitos claros para cada fase o conjunto de la migración. Seleccionar criterios es fundamental, incluso si el objetivo técnico es tener la arquitectura híbrida como una configuración a corto plazo.
  • Define los ANSs y los KPIs de la aplicación cuando tus aplicaciones operen en una configuración híbrida, en especial para aquellas aplicaciones que podrían tener componentes distribuidos en varios entornos.

Para obtener más información, consulta Acerca de la planificación de la migración para planificar una migración exitosa y minimizar los riesgos asociados.

Fase de implementación

En la fase de implementación, estás listo para comenzar a ejecutar tu estrategia de migración. En función de la cantidad potencial de requisitos, es mejor adoptar un enfoque de iteración.

Prioriza tus cargas de trabajo según las fases de migración y aplicación que desarrollaste durante la fase de planificación. Con las arquitecturas híbridas y de múltiples nubes, comienza tu implementación estableciendo la conectividad necesaria entre Google Cloud y los demás entornos de computación. Para facilitar el modelo de comunicación requerido para tu arquitectura híbrida o de múltiples nubes, basa la implementación en el diseño y el tipo de conectividad de red que seleccionaste, junto con el patrón de redes aplicable. Te recomendamos que adoptes este enfoque para tu decisión general de diseño de la zona de destino.

Además, debes probar y validar la aplicación o el servicio según los criterios de éxito definidos para la aplicación. 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: después de completar las pruebas y que la aplicación o el servicio cumplan con las expectativas de capacidad funcional y de rendimiento, puedes moverlo a producción. Las herramientas de supervisión y visibilidad de Cloud, como Cloud Monitoring, pueden proporcionar estadísticas sobre el rendimiento, la disponibilidad y el estado de la infraestructura y las aplicaciones, y ayudarte a optimizar en caso de que sea necesario.

Para obtener más información, consulta Migra a Google Cloud: Optimiza tu entorno. Para obtener más información sobre cómo diseñar este tipo de herramientas para una arquitectura híbrida o de múltiples nubes, consulta Patrones de registro y supervisión para nubes híbridas y múltiples.

Evalúa las cargas de trabajo candidatas

La elección de los entornos de computación para diferentes cargas de trabajo afecta significativamente el éxito de una estrategia híbrida y multinube. Las decisiones sobre la colocación de cargas de trabajo deben alinearse con objetivos comerciales específicos. Por lo tanto, estas decisiones deben basarse en casos de uso comerciales específicos que permitan efectos comerciales medibles. Sin embargo, no siempre es necesario ni recomendable comenzar con la carga de trabajo o la aplicación más importante para el negocio. Para obtener más información, consulta Elige las apps que se migrarán primero en la guía de migración a Google Cloud .

Como se analizó en la sección Factores técnicos y comerciales, existen diferentes tipos de factores y consideraciones para las arquitecturas híbridas y de múltiples nubes.

La siguiente lista resumida de factores puede ayudarte a evaluar tu caso de uso de migración en el contexto de una arquitectura híbrida o de múltiples nubes con oportunidades para tener un efecto comercial medible:

  • Potencial de diferenciación o innovación en el mercado que se logra con el uso de servicios en la nube para habilitar ciertas funciones o capacidades comerciales, como las capacidades de inteligencia artificial que usan datos locales existentes para entrenar modelos de aprendizaje automático
  • Ahorros posibles en el costo total de propiedad de una aplicación.
  • Posibles mejoras en la disponibilidad, la resiliencia, la seguridad o el rendimiento (por ejemplo, agregar un sitio de recuperación ante desastres [DR] en la nube)
  • Aceleración posible de los procesos de desarrollo y lanzamiento, por ejemplo, la compilación de tus entornos de desarrollo y pruebas en la nube.

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

  • Es el posible efecto de las interrupciones causadas por una migración.
  • La experiencia que tiene tu equipo con implementaciones de nube pública o con implementaciones de un proveedor de servicios en la nube nuevo o secundario.
  • Necesidad de cumplir con las restricciones legales o reglamentarias existentes.

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

  • Tamaño, complejidad y antigüedad de la aplicación.
  • La cantidad de dependencias con otras aplicaciones y servicios en diferentes entornos de computación.
  • Cualquier restricción impuesta por licencias de terceros.
  • Dependencias de versiones específicas de sistemas operativos, bases de datos o configuraciones de entorno.

Después de evaluar tus cargas de trabajo iniciales, puedes comenzar a organizarlas por prioridad y definir tus conjuntos de migración y enfoques. Luego, puedes identificar patrones de arquitectura aplicables y patrones de redes de asistencia. Este paso puede requerir varias iteraciones, ya que tu evaluación podría cambiar con el tiempo. Por lo tanto, vale la pena volver a evaluar las cargas de trabajo después de realizar las primeras implementaciones en la nube.

Enfoques arquitectónicos para adoptar una arquitectura híbrida o de múltiples nubes

En este documento, se proporciona orientación sobre enfoques y consideraciones comunes y comprobados para migrar tu carga de trabajo a la nube. Se amplía la orientación que se brinda en Diseña una estrategia de arquitectura híbrida y de múltiples nubes, en la que se analizan varios pasos posibles y recomendados para diseñar una estrategia para adoptar una arquitectura híbrida o de múltiples nubes.

Centrada en la nube

Una forma común de comenzar a usar la nube pública es el enfoque centrado en la nube. En este enfoque, implementas tus cargas de trabajo nuevas en la nube pública, mientras que las cargas de trabajo existentes permanecen donde están. En ese caso, considera una implementación clásica para un entorno de computación privado, solo si no se puede implementar en la nube pública por razones técnicas o de la organización.

Esta estrategia tiene ventajas y desventajas. Uno de los aspectos positivos es que la estrategia es prospectiva. Puedes implementar cargas de trabajo nuevas de forma modernizada y evitar (o al menos minimizar) las complicaciones de la migración de las cargas de trabajo existentes.

Si bien un enfoque centrado en la nube puede proporcionar ciertas ventajas, también podría generar oportunidades perdidas para mejorar o usar las cargas de trabajo existentes. Las cargas de trabajo nuevas pueden representar una fracción del panorama general de TI, y su efecto en los gastos y el rendimiento de TI puede ser limitado. Asignar tiempo y recursos para migrar una carga de trabajo existente podría generar beneficios o ahorros de costos más significativos en comparación con intentar alojar una carga de trabajo nueva en el entorno de nube.

Seguir un enfoque estricto centrado en la nube también puede aumentar la complejidad general de tu entorno de TI. Este enfoque puede crear redundancias, disminuir el rendimiento debido a la posible comunicación excesiva en el entorno o generar un entorno de computación que no es adecuado para la carga de trabajo individual. Además, el cumplimiento de las reglamentaciones de la industria y las leyes de privacidad de los datos puede restringir la migración de ciertas aplicaciones que contienen datos sensibles.

En función de estos riesgos, podría ser mejor utilizar un enfoque centrado en la nube solo para cargas de trabajo seleccionadas. Usar un enfoque centrado en la nube te permite concentrarte en las cargas de trabajo que más se pueden beneficiar de una implementación o migración a la nube. Este enfoque también considera la modernización de las cargas de trabajo existentes.

Un ejemplo común de una arquitectura híbrida centrada en la nube es cuando las aplicaciones y los servicios heredados 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 heredados con interfaces de API, lo que los desbloquea para que los consuman los nuevos servicios y aplicaciones en la nube. Con una plataforma de administración de APIs en la nube, como Apigee, puedes implementar estos casos de uso con cambios mínimos en la aplicación y agregar seguridad, estadísticas y escalabilidad a los servicios heredados.

Migración y modernización

La modernización de la nube híbrida, multinube y TI son conceptos diferentes que se vinculan en un círculo virtuoso. El uso de 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 aprovechar al máximo la nube.

A continuación, se detallan los objetivos principales de la modernización de las cargas de trabajo:

  • Lograr mayor agilidad para adaptarse a los requisitos cambiantes
  • Reducir los costos de infraestructura y operaciones
  • Aumentar la confiabilidad y la resiliencia para minimizar el riesgo

Sin embargo, es posible que no sea factible modernizar todas las aplicaciones en el 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 host (lift‑and‑shift)
  • Cambio de plataforma (lift‑and‑optimize)
  • Refactorización (traslado y mejora)
  • Rediseño (continúa con la modernización)
  • Reconstrucción (quitar y reemplazar, a veces llamado extraer y reemplazar)
  • Recompra

Cuando tomes decisiones estratégicas sobre tus arquitecturas híbridas y de múltiples nubes, es importante que consideres la viabilidad de tu estrategia desde una perspectiva de costos y tiempo. Puedes considerar un enfoque de migración por fases, comenzando con lift-and-shift o replatforming y, luego, refactoring o rediseño como el siguiente paso. Por lo general, la migración directa ayuda a optimizar las aplicaciones desde la perspectiva de la infraestructura. Una vez que las aplicaciones se ejecutan en la nube, es más fácil usar e integrar los servicios de nube para optimizarlas aún más con arquitecturas y capacidades que priorizan la nube. Además, estas aplicaciones aún pueden comunicarse con otros entornos a través de una conexión de red híbrida.

Por ejemplo, puedes refactorizar o rediseñar una aplicación monolítica grande basada en VM y convertirla en varios microservicios independientes, basados en una arquitectura de microservicios basada en la nube. En este ejemplo, la arquitectura de microservicios usa servicios de contenedores administrados por Google Cloud , como Google Kubernetes Engine (GKE) o Cloud Run. Sin embargo, si la arquitectura o infraestructura de una aplicación no es compatible con el entorno de nube de destino tal como es, puedes considerar comenzar con la replataformización, la refactorización o la reestructuración de tu estrategia de migración para superar esas limitaciones cuando sea posible.

Cuando uses cualquiera de estos enfoques de migración, considera modernizar tus aplicaciones (cuando sea aplicable y factible). La modernización puede requerir la adopción y la implementación de los principios de ingeniería de confiabilidad de sitios (SRE) o DevOps, por lo que también es posible que debas extender la modernización de la aplicación a tu entorno privado en una configuración híbrida. Si bien la implementación de los principios de la SRE implica ingeniería en su núcleo, se trata más de un proceso de transformación que de un desafío técnico. Por lo tanto, es probable que requiera cambios culturales y de procedimiento. Para obtener más información sobre cómo el primer paso para implementar SRE en una organización es obtener la aceptación del liderazgo, consulta Con SRE, no planificar es planificar el fracaso.

Combina y adapta enfoques de migración

Cada enfoque de migración que se analiza aquí tiene ciertas fortalezas y debilidades. Una ventaja principal de la estrategia de nube híbrida y multinube implica que no es necesario establecer un solo enfoque. En cambio, puedes decidir qué enfoque funciona mejor para 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 diversas 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 comerciales y técnicos únicos de cada carga de trabajo o aplicación.

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

  • La base de datos local de backend de una aplicación se puede volver a crear en otra plataforma, desde MySQL autoalojado hasta una base de datos administrada con Cloud SQL en Google Cloud.
  • Las máquinas virtuales de frontend de la aplicación se pueden refactorizar para que se ejecuten en contenedores con GKE Autopilot, en el que Google administra la configuración del clúster, incluidos los nodos, el escalamiento, la seguridad y otros parámetros de configuración ya establecidos.
  • La solución de balanceo de cargas de hardware local y las capacidades del firewall de aplicaciones web (WAF) se pueden reemplazar por Cloud Load Balancing y Google Cloud Armor.

Elige la opción de volver a alojar (lift and shift) si se cumple alguna de las siguientes condiciones para las cargas de trabajo:

  • Tienen una cantidad relativamente pequeña de dependencias en sus entornos.
  • No se considera que valga la pena reestructurarlas, o bien no es factible reestructurarlas antes de la migración.
  • Se basan en software de terceros.

Considera refactorizar (mover y mejorar) estos tipos de cargas de trabajo:

  • Tienen dependencias que deben ser desvinculadas.
  • Se basan en sistemas operativos, hardware o sistemas de bases de datos que no se pueden alojar en la nube.
  • No usan de manera eficiente los recursos de computación o de almacenamiento.
  • No se pueden implementar de manera automatizada sin cierto esfuerzo.

Considera si la reconstrucción (quitar y reemplazar) satisface tus necesidades para estos tipos de cargas de trabajo:

  • Ya no cumplen con los requisitos actuales.
  • Se pueden incorporar a otras aplicaciones que proporcionan capacidades similares sin comprometer los requisitos comerciales.
  • Se basan en tecnología de terceros ya obsoleta.
  • 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 costos y simplificar su camino al éxito en la nube.

Otras consideraciones

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

Refactorizar

En una migración de refactorización, debes modificar tus cargas de trabajo para aprovechar las capacidades de la nube y no solo para que funcionen en el entorno nuevo. Puedes mejorar cada carga de trabajo para el rendimiento, las funciones, el costo y la experiencia del usuario. Como se destaca en Refactor: move and improve, algunos casos de refactorización te permiten modificar las cargas de trabajo antes de migrarlas a la nube. Este enfoque de refactorización ofrece los siguientes beneficios, en especial si tu objetivo es compilar una arquitectura híbrida como una arquitectura objetivo a largo plazo:

  • Puedes mejorar el proceso de implementación.
  • Puedes ayudar a acelerar la cadencia de actualización y acortar los ciclos de respuesta invirtiendo en la infraestructura y herramientas de integración continua/implementación continua (CI/CD).
  • Puedes usar la refactorización como base para compilar y administrar una arquitectura híbrida con portabilidad de aplicaciones.

Para que funcione bien, este enfoque suele requerir ciertas inversiones en infraestructura y herramientas locales. Por ejemplo, configurar un registro de Container Registry local y aprovisionar clústeres de Kubernetes para crear contenedores para 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 incluye 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 detalles.

Portabilidad de la carga de trabajo

Con las arquitecturas híbridas y de varias nubes, es posible que desees poder cambiar las cargas de trabajo entre los entornos de computación que alojan tus datos. Para facilitar el movimiento fluido de las cargas de trabajo entre entornos, considera los siguientes factores:

  • Puedes mover una aplicación de un entorno de procesamiento a otro sin modificar significativamente la aplicación ni su modelo operativo:
    • La implementación y la administración de la aplicación son coherentes en todos los entornos de computación.
    • La visibilidad, la configuración y la seguridad son coherentes en todos los entornos de procesamiento.
  • La capacidad de hacer que una carga de trabajo sea portátil no debe generar un conflicto con el hecho de que la carga de trabajo sea centrada en la nube.

Automatización de la infraestructura

La automatización de la infraestructura es fundamental para la portabilidad en arquitecturas híbridas y de múltiples nubes. Un enfoque común para automatizar la creación de infraestructura es a través de la infraestructura como código (IaC). La IaC implica administrar tu infraestructura en archivos en lugar de configurar recursos manualmente (como una VM, un grupo de seguridad o un balanceador de cargas) en una interfaz de usuario. Terraform es una herramienta de IaC popular para 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 administración de recursos de Google Cloud , consulta Planos y módulos de Terraform para Google Cloud.

Puedes usar herramientas de administración de configuración, como Ansible, Puppet o Chef para establecer un proceso común de implementación y configuración. Otra alternativa es usar una herramienta de creación de imágenes como Packer para crear imágenes de VM para diferentes plataformas. Con un solo 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 garantizar la supervisión coherente en los entornos.

En función de estas herramientas, puedes combinar una cadena de herramientas común como se ilustra 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 administración y la supervisión.

Una cadena de herramientas permite la portabilidad de la aplicación.

Aunque una cadena de herramientas común puede ayudarte a lograr la portabilidad, esta presenta varias de las siguientes deficiencias:

  • Usar VMs como base común puede dificultar la implementación de aplicaciones verdaderamente centradas en la nube. Además, usar solo VMs puede impedir que uses servicios administrados en la nube. Es posible que pierdas oportunidades para reducir la sobrecarga administrativa.
  • El desarrollo y mantenimiento de una cadena de herramientas común generan gastos de sobrecarga y operativos.
  • A medida que se expande la cadena de herramientas, puede desarrollar complejidades únicas adaptadas a las necesidades específicas de tu empresa. Esta mayor complejidad puede contribuir a un aumento de los costos de entrenamiento.

Antes de decidir desarrollar herramientas y automatización, explora los servicios administrados que ofrece tu proveedor de servicios en la nube. Cuando tu proveedor ofrece servicios administrados que admiten el mismo caso de uso, puedes abstraer parte de su complejidad. De esta manera, puedes enfocarte en la carga de trabajo y la arquitectura de la aplicación en lugar de la infraestructura subyacente.

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

También puedes considerar la opción de automatizar la creación de proyectos y la creación de recursos dentro de esos proyectos. Esta automatización puede ayudarte a adoptar un enfoque de infraestructura como código para el aprovisionamiento de proyectos.

Contenedores y Kubernetes

El uso de capacidades administradas en la nube ayuda a reducir la complejidad de crear y mantener una cadena de herramientas personalizada para lograr la automatización y la portabilidad de la carga de trabajo. Sin embargo, usar solo VMs como base común dificulta la implementación de aplicaciones verdaderamente centradas en la nube. Una solución es usar contenedores y Kubernetes.

Los contenedores ayudan a que el software se ejecute de manera confiable cuando lo mueves de un entorno a otro. Debido a que los contenedores desacoplan las aplicaciones de la infraestructura del host subyacente, facilitan la implementación en entornos de procesamiento, como los híbridos y de múltiples nubes.

Kubernetes se encarga de la organización, la implementación, el escalamiento y la administración de tus aplicaciones en contenedores. Es de código abierto y se rige por la Cloud Native Computing Foundation. El uso de Kubernetes proporciona los servicios que forman la base de una aplicación que prioriza la nube. Debido a que puedes instalar y ejecutar Kubernetes en muchos entornos de computación, también puedes usarlo para establecer una capa de entorno de ejecución común en los entornos de computación:

  • Kubernetes proporciona los mismos servicios y las API en una nube o en un entorno de computación privado. Además, el nivel de abstracción es mucho mayor que cuando se trabaja con VM, lo que generalmente se traduce en un menor trabajo de base y una mayor productividad de los desarrolladores.
  • A diferencia de una cadena de herramientas personalizadas, Kubernetes se utiliza ampliamente para el desarrollo y la administración de aplicaciones, por lo que puedes aprovechar la experiencia, la documentación y el soporte de terceros existentes.
  • Kubernetes admite todas las implementaciones de contenedores que cumplen con los siguientes requisitos:

Cuando una carga de trabajo se ejecuta en Google Cloud, puedes evitar el esfuerzo de instalar y operar Kubernetes usando una plataforma administrada de Kubernetes, como Google Kubernetes Engine (GKE). Esto puede ayudar al personal de operaciones a cambiar su enfoque de la creación y el mantenimiento de la infraestructura a la creación y el mantenimiento de las aplicaciones.

También puedes usar Autopilot, un modo de operación de GKE que administra la configuración de tu clúster, incluidos los nodos, el escalamiento, la seguridad y otros parámetros de configuración ya establecidos. Cuando uses GKE Autopilot, ten en cuenta tus requisitos de escalamiento y sus límites de escalamiento.

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

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

Como se ilustra en el siguiente diagrama, usar GKE Enterprise significa que puedes operar aplicaciones de varios clústeres como flotas.

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

GKE Enterprise ayuda con las siguientes opciones de diseño para admitir arquitecturas híbridas y de múltiples nubes:

  • Diseñar y compilar experiencias similares a las de la nube a nivel local o soluciones unificadas para la transición de 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 de las múltiples nubes con una postura coherente de administración, operaciones y seguridad con GKE Multi-Cloud. Para obtener más información, consulta la documentación de GKE Multi-cloud.

GKE Enterprise también proporciona agrupaciones lógicas de entornos similares con seguridad, configuración y administración de servicios coherentes. Por ejemplo, GKE Enterprise potencia la 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 a través de comunicaciones seguras de servicio a servicio con mTLS de extremo a extremo.

Consideraciones sobre la portabilidad de la carga 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 para un entorno diferente con cambios mínimos, pero eso no implica que se desempeñará de la misma manera en ambos entornos.
    • Las diferencias en la infraestructura de computación subyacente, las capacidades de seguridad de la infraestructura o la infraestructura de redes, junto con la proximidad a los servicios dependientes, pueden dar lugar a un rendimiento sustancialmente diferente.
  • Mover una carga de trabajo entre los entornos de computación también puede requerir mover datos.
    • Los diferentes entornos pueden tener diferentes servicios e instalaciones de almacenamiento y administración de datos.
  • El comportamiento y el rendimiento de los balanceadores de cargas aprovisionados con Kubernetes o GKE Enterprise pueden diferir entre los entornos.

Transferencia de datos

Dado que puede ser complejo mover, compartir y acceder a los datos a gran escala entre los entornos de procesamiento, las empresas a nivel empresarial pueden dudar en crear una arquitectura híbrida o de varias nubes. Esta duda puede aumentar si ya almacenan la mayor parte de sus datos de forma local o en una nube.

Sin embargo, las diversas opciones de movimiento de datos que ofrece Google Cloudproporcionan a las empresas un conjunto integral de soluciones para ayudarlas a mover, integrar y transformar sus datos. Estas opciones ayudan a las empresas a almacenar, compartir y acceder a los datos en diferentes entornos de una manera que satisfaga sus casos de uso específicos. En última instancia, esa capacidad facilita que los responsables de la toma de decisiones comerciales y tecnológicas adopten arquitecturas híbridas y de múltiples nubes.

El movimiento de datos es un factor importante que se debe tener en cuenta en la planificación de la estrategia y la arquitectura híbrida y de múltiples nubes. Tu equipo debe identificar los diferentes casos de uso 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 industrias reguladas, esa clasificación puede ayudar a identificar las ubicaciones de almacenamiento y las restricciones de movimiento de datos entre regiones para ciertas clases de datos. Para obtener más información, consulta Sensitive Data Protection. Sensitive Data Protection es un servicio completamente administrado diseñado para ayudarte a descubrir, clasificar y proteger tus recursos de datos.

Para explorar el proceso, desde la planificación de una transferencia de datos hasta el uso de prácticas recomendadas para implementar un plan, consulta Migración a Google Cloud: Transfiere tus conjuntos de datos grandes.

Seguridad

A medida que las organizaciones adoptan arquitecturas híbridas y de varias nubes, su superficie de ataque puede aumentar según la forma en que sus sistemas y datos se distribuyen en diferentes entornos. En combinación con el panorama de amenazas en constante evolución, el aumento de las superficies de ataque puede generar un mayor riesgo de acceso no autorizado, pérdida de datos y otros incidentes de seguridad. Ten en cuenta la seguridad cuando planifiques e implementes estrategias híbridas o de múltiples nubes.

Para obtener más información, consulta Administración de la superficie de ataque para Google Cloud.

Cuando se diseña una arquitectura híbrida, no siempre es técnicamente factible o viable extender los enfoques de seguridad locales a la nube. Sin embargo, muchas de las capacidades de seguridad de redes de los dispositivos de hardware son funciones centradas en la nube y operan de forma distribuida. Para obtener más información sobre las capacidades de seguridad de red centradas en la nube de Google Cloud, consulta Seguridad de red en la nube.

Las arquitecturas híbridas y de múltiples nubes pueden generar desafíos de seguridad adicionales, como la coherencia y la observabilidad. Cada proveedor de servicios en la nube pública tiene su propio enfoque de seguridad, que incluye diferentes modelos, prácticas recomendadas, capacidades de seguridad de infraestructura y aplicaciones, obligaciones de cumplimiento y hasta 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 servicios en la nube puede ser diferente. Es fundamental identificar y comprender la demarcación exacta de responsabilidades en una arquitectura de múltiples nubes.

La observabilidad es clave para obtener estadísticas y métricas de los diferentes entornos. En una arquitectura de varias nubes, cada nube suele proporcionar herramientas para supervisar la postura de seguridad y los errores de configuración. Sin embargo, el uso de estas herramientas genera una visibilidad aislada, lo que impide crear inteligencia sobre amenazas avanzada en todo el entorno. Como resultado, el equipo de seguridad debe cambiar entre herramientas y paneles para mantener la nube segura. Sin una visibilidad integral de la seguridad de extremo a extremo para los entornos híbridos y de múltiples nubes, es difícil priorizar y mitigar las vulnerabilidades.

Para obtener la visibilidad y la postura completas de todos tus entornos, prioriza tus vulnerabilidades y mitiga las que identifiques. Te recomendamos un modelo de visibilidad centralizado. Un modelo de visibilidad centralizado evita la necesidad de correlación manual entre diferentes herramientas y paneles de diferentes plataformas. Para obtener más información, consulta Patrones de registro y supervisión de nubes híbridas y múltiples.

Como parte de tu planificación para mitigar los riesgos de seguridad y, también, implementar cargas de trabajo enGoogle Cloud, y para ayudarte a planificar y diseñar tu solución en la nube para cumplir con tus objetivos de seguridad y cumplimiento de normas, explora el Google Cloud centro de prácticas recomendadas de seguridad y el plano de bases empresariales.

Los objetivos de cumplimiento pueden variar, ya que están influenciados por las reglamentaciones específicas de la industria y los diferentes requisitos reglamentarios de las distintas regiones y países. Para obtener más información, consulta el Google Cloud Centro de recursos de cumplimiento. Estos son algunos de los principales enfoques recomendados para diseñar arquitecturas híbridas y de múltiples nubes seguras:

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

    Es fundamental comprender 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.

  • Considera una arquitectura de seguridad unificada en entornos híbridos y de múltiples nubes.

  • Estandarizar el diseño y las implementaciones de la nube, en especial el diseño y las capacidades de seguridad Esto puede mejorar la eficiencia y habilitar la administración y las herramientas unificadas.

  • Usar varios controles de seguridad

    Por lo general, ningún control de seguridad único puede abordar de manera adecuada 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 en capas, también conocido como defensa en profundidad.

  • Supervisa y mejora continuamente las posturas de seguridad: Tu organización debe supervisar sus diferentes entornos en busca de amenazas y vulnerabilidades de seguridad. También debe intentar mejorar continuamente su postura de seguridad.

  • Considera usar la administración de la postura de seguridad en la nube (CSPM) para identificar y corregir errores de configuración de seguridad y amenazas de ciberseguridad. La CSPM también proporciona evaluaciones de vulnerabilidades en entornos híbridos y de múltiples nubes.

Security Command Center es una solución integrada de seguridad y administración de riesgos para Google Cloudque ayuda a identificar parámetros de configuración incorrectos, vulnerabilidades y mucho más. Security Health Analytics es una herramienta administrada 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 tu entorno deGoogle Cloud y proporciona recomendaciones para solucionarlos.

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

  • Solución de administración de información y eventos de seguridad (SIEM) en la nube: Ayuda a recopilar y analizar registros de seguridad de entornos híbridos y de varias nubes para detectar amenazas y responder a ellas. El SIEM de Google Security Operations de Google Cloud ayuda a proporcionar información de seguridad y administración de eventos recopilando, analizando, detectando e investigando todos tus datos de seguridad en un solo lugar.

Crea arquitecturas híbridas y de múltiples nubes con Google Cloud: Próximos pasos