Compila arquitecturas híbridas y multinube con Google Cloud

Last reviewed 2024-11-27 UTC

Esta guía de arquitectura proporciona orientación práctica sobre la planificación y la arquitectura de tus entornos híbridos y multinube con Google Cloud. Este documento es el primero de los tres del conjunto. Examina las oportunidades y las consideraciones asociadas con estas arquitecturas desde un punto de vista empresarial y tecnológico. También analiza y discute muchos patrones de arquitectura híbrida y de múltiples nubes comprobados.

El conjunto de documentos para patrones de arquitectura híbrida y de múltiples nubes consta de estas partes:

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

El rápido ritmo de cambio en las demandas del mercado aumentó los requisitos y las expectativas que se imponen 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 de la empresa les resulta difícil cumplir con 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 usa capacidades de computación en la nube pública proporciona una solución pragmática. Mediante el uso de la nube pública, puedes ampliar la capacidad y las capacidades de tus plataformas de procesamiento sin costos iniciales de inversión de capital.

Si agregas una o más soluciones basadas en la nube pública, como Google Cloud, a tu infraestructura existente, no solo conservas tus inversiones existentes, sino que evitas tener que comprometerte con un solo 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 la planificación de estrategias híbridas o de múltiples nubes, debes tener en cuenta varios desafíos y consideraciones de diseño potenciales. En esta guía de arquitectura de varias partes, se destacan los posibles beneficios de varias arquitecturas y los posibles desafíos.

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 guía de arquitectura de Google Cloud de Google Cloud, 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 colocalizació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 computación privado (que podría incluir el uso de un componente de nube privada). Esa disposición se denomina arquitectura híbrida y de múltiples nubes.

Diagrama de las tres arquitecturas que se analizan en esta serie: híbrida, de múltiples nubes y una combinación de ambas.

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 impulsores y los requisitos de la empresa, y cómo estos factores pueden influir en tus decisiones de diseño cuando construyes arquitecturas híbridas y multinube.

Objetivos

Una organización puede adoptar una arquitectura híbrida o de múltiples nubes, ya sea 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 lograr algunos o todos tus objetivos comerciales. Estas preguntas se enfocan en lo que tu empresa necesita, 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 multinube, 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 requisitos y objetivos 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, con las capacidades y los servicios globales de las nubes públicas. Este objetivo debe ser específico y medible, y definir con claridad el alcance de la expansión en términos de regiones y plazos objetivo.

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 empresariales. Por lo tanto, para elegir la arquitectura híbrida o de múltiples nubes correcta, primero debes aclarar estos requisitos.

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

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

En el siguiente diagrama de flujo, se ilustran los impulsores, los objetivos y los requisitos comerciales, y los objetivos y requisitos técnicos, y cómo se relacionan todos estos factores entre sí:

Flujo de trabajo que muestra los aspectos que se deben tener en cuenta cuando se desarrollan requisitos técnicos, incluidos los impulsores comerciales, los objetivos y los requisitos, así como los objetivos técnicos.

Impulsores técnicos y empresariales

Considera cómo los impulsores comerciales influyen en tus objetivos técnicos. Entre los impulsores empresariales comunes y que influyen cuando se elige una arquitectura híbrida, se incluyen los siguientes:

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

Considera tu lista de impulsores empresariales 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 tus prioridades comerciales.

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

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

  • Acatamiento de leyes y reglamentaciones sobre la soberanía de los datos: La situación más común es cuando una organización expande su negocio a una región o un país nuevos y debe cumplir con nuevas reglamentaciones de alojamiento de datos.
    • Si el proveedor de servicios en la nube (CSP) que se usa actualmente no tiene una región de nube local en ese país, a los efectos de cumplimiento, la solución común es usar otro CSP que tenga una región de nube local en ese país.
  • Reducción de costos: A menudo, la reducción de costos es el impulsor comercial más común para adoptar una tecnología o arquitectura. Sin embargo, es importante considerar más que solo el costo de los servicios y los posibles descuentos de precios cuando decidas si adoptar una arquitectura multinube. Ten en cuenta el costo de crear y operar una solución en varias 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 varias nubes pueden superar los beneficios. Una estrategia de múltiples nubes podría generar costos adicionales más adelante.

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

  • Aumenta la complejidad de la administración.
  • Mantener una seguridad coherente
  • Integrar entornos de software
  • Lograr un rendimiento y una confiabilidad coherentes entre nubes
  • Crear un equipo técnico con habilidades de varias nubes puede ser costoso y requerir que se expanda el equipo, a menos que lo administre una empresa externa.
  • Administrar las herramientas de administración y precios de los productos de cada CSP
  • Usar las capacidades únicas de cada CSP: Una arquitectura de múltiples nubes permite a las organizaciones usar tecnologías nuevas adicionales para mejorar sus propias ofertas de capacidades empresariales 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 viabilidad y eficacia, incluidos los desafíos comunes mencionados anteriormente.
  • Evitar la dependencia de un solo proveedor: A veces, las empresas quieren evitar estar atadas a 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 volver a compilar o refactorizar 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 algunos casos, una arquitectura multinube puede proporcionar resiliencia a las interrupciones. Por ejemplo, si una región de un CSP deja de estar disponible, el tráfico se puede enrutar a otro CSP en la misma región. En esta situación, se asume que ambos proveedores de servicios en la nube admiten las funciones o los servicios necesarios en esa región.

Cuando las reglamentaciones de residencia de datos de un país o una región específicos exigen el almacenamiento de datos sensibles, como información de identificación personal (PII), dentro de esa ubicación, un enfoque multinube puede proporcionar una solución que cumpla con las reglamentaciones. Si usas dos CSP en una región para proporcionar resiliencia a 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 de resiliencia que debes evaluar antes de adoptar una arquitectura multinube:

  • Movimiento de datos: ¿Con qué frecuencia se pueden mover los datos dentro de tu entorno multinube?
    • ¿El traslado de datos podría generar cargos significativos por transferencia de datos?
  • Seguridad y capacidad de administración: ¿Hay alguna complejidad potencial de seguridad o administración?
  • Paridad de capacidades: ¿Ambos CSP de la región seleccionada ofrecen las capacidades y los servicios necesarios?
  • Conjunto de habilidades técnicas: ¿El equipo técnico tiene las habilidades necesarias para gestionar una arquitectura multinube?

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

Cuando evalúes la viabilidad de una arquitectura de múltiples nubes, es importante considerar 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 valor potencial 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 de múltiples nubes deben considerar crear un centro de excelencia para la nube (COE). Un equipo de COE puede convertirse en el conducto para transformar la forma en que los equipos internos de tu organización sirven a la empresa durante la transición a la nube. Un COE es una de las formas en que tu organización puede adaptarse a la nube más rápido, impulsar la estandarización y mantener una alineación más sólida 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 impulsores comerciales comunes incluyen los siguientes:

  • La necesidad de reducir el CapEx o los gastos generales de TI para proyectos a corto plazo
  • La capacidad de aprovisionar esa infraestructura rápidamente para admitir un caso de uso comercial Por ejemplo:
    • Esta arquitectura se puede usar para proyectos por tiempo limitado. Se podría usar para admitir un proyecto que requiera una infraestructura distribuida a gran escala en un período limitado y, al mismo tiempo, seguir usando datos locales.
  • La necesidad de proyectos de transformación digital de varios años que requieren que una gran empresa se establezca y que use una arquitectura híbrida durante un tiempo para ayudar a alinear la modernización de su infraestructura y 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 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.

Impulsores técnicos

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

La siguiente lista no exhaustiva contiene algunos impulsores técnicos comunes para la adopción de una arquitectura híbrida o de múltiples nubes:

  • Desarrollo de capacidades tecnológicas, como los servicios de estadísticas avanzadas y la IA, que podrían ser difíciles de implementar en los entornos existentes
  • Mejorar 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
  • Usar 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 funciones elásticas 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 impulsor técnico más común para las arquitecturas híbridas temporales y de múltiples nubes temporales es facilitar una migración de las instalaciones locales a la nube o a una nube adicional. En general, las migraciones a la nube casi siempre conducen de forma natural a la configuración de nube híbrida. Las empresas a menudo 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 impulsores son clave para tomar una decisión de arquitectura basada en la empresa 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 un objetivo comercial para desarrollar una práctica de investigación y desarrollo durante tres a seis meses. El principal requisito comercial para respaldar este objetivo podría ser crear el entorno tecnológico requerido para la investigación y el diseño con el CAPEX más bajo posible.

El objetivo técnico en este caso es tener una configuración de nube híbrida temporal. El impulsor de este objetivo técnico es aprovechar el modelo de precios on demand de la nube para cumplir con el requisito comercial mencionado anteriormente. Otro factor que influye son los requisitos de tecnología específicos que requieren una solución basada en la nube con alta capacidad de procesamiento y configuración rápida.

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

El uso de 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 considerar las siguientes posibles complejidades cuando planifiques una arquitectura:

  • Interoperabilidad
  • Administración
  • Costo
  • Seguridad

Compilar en una plataforma de nube que contribuya a la compatibilidad con el código abierto y la promueva podría ayudarte a simplificar tu camino hacia la adopción de arquitecturas híbridas y de múltiples nubes. La nube abierta te empodera con 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 minimizas la dependencia de los proveedores, aprovechas soluciones de primer nivel y cumples con 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 lanza como un servicio administrado, Kubernetes puede ayudar a reducir las complejidades relacionadas con 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 híbrida o de múltiples nubes es lograr los requisitos empresariales 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 tenga en cuenta 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 este tipo de situaciones, formula inicialmente 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 entorno de computación actuales no son suficientes para cumplir con los objetivos comerciales?
  • ¿Cuáles son los aspectos tecnológicos principales que se deben optimizar mediante el uso de 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 híbrida o de múltiples nubes?

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.

Identifica y aclara otras consideraciones

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

En el aspecto de las operaciones, la siguiente lista no exhaustiva proporciona algunos requisitos que podrían crear algunas restricciones que debes tener en cuenta cuando planifiques 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 multinube

Para obtener más información sobre las otras consideraciones relacionadas con la portabilidad de cargas 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 desarrollar tu estrategia para crear una arquitectura híbrida o multinube.

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 comerciales, obtén aceptación, crea un plan de alto nivel y, luego, utilízalo para fundamentar 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 comienzan con los requisitos y objetivos 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, como se describe en Migración 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 Migra 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 tus documentos de planificación de la visión y la estrategia. Para decidir un plan de migración, 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 evaluar varios aspectos de las aplicaciones y la infraestructura, incluidos los siguientes:

  • Requisitos de compatibilidad de la aplicación con los proveedores de servicios en la nube que seleccionaste
  • Modelos de precios
  • Funciones de seguridad que ofrecen los proveedores de servicios en la nube que seleccionaste
  • 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 para migrar o operar.

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 aplicación híbrida o multinube de alto nivel aplicable.
  3. Selecciona un patrón de arquitectura de red que admita el patrón de arquitectura de la aplicación seleccionado.

Idealmente, debes incorporar el patrón de red en la nube con el diseño de la zona de destino. El diseño de la zona de destino sirve como elemento fundamental de las arquitecturas híbridas y de múltiples nubes en general. 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 red 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 deGoogle Cloud para preparar la zona de destino del entorno de nube para la integración y la implementación híbridas o de múltiples nubes.

Como parte de esta fase, debes considerar lo siguiente:

  • Define el enfoque de migración y modernización. Más adelante en esta guía, encontrarás 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 Cómo migrar a Google Cloud.
  • Usa los hallazgos de la fase de evaluación y descubrimiento. Alinéalos con la carga de trabajo candidata que planeas migrar. Luego, desarrolla un plan de oleadas de migración para la aplicación. El plan debe incorporar los requisitos estimados de tamaño de los recursos que determinaste durante la fase de evaluación.
  • Define el modelo de comunicación requerido entre las aplicaciones distribuidas y entre los componentes de la aplicación para la arquitectura híbrida o de múltiples nubes 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 forma la base para construir las arquitecturas de implementación específicas de la aplicación adaptadas a tus necesidades técnicas y empresariales.
  • Decide los criterios de éxito medibles para la migración, con hitos claros para cada fase o ola de migración. La selección de criterios es esencial, incluso si el objetivo técnico es tener la arquitectura híbrida como 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. Dada la cantidad potencial de requisitos, es mejor adoptar un enfoque iterativo.

Prioriza tus cargas de trabajo según las oleadas de migración y aplicación que desarrollaste durante la fase de planificación. Con las arquitecturas híbridas y de múltiples nubes, empieza tu implementación estableciendo la conectividad necesaria entre Google Cloud y los otros entornos de procesamiento. 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 seleccionados, junto con el patrón de red 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. Idealmente, estos criterios deben incluir 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 esas herramientas para la 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 de manera significativa el éxito de una estrategia híbrida y multinube. Las decisiones de ubicación de la carga de trabajo deben alinearse con objetivos comerciales específicos. Por lo tanto, estas decisiones deben guiarse por casos de uso comerciales segmentados 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 la empresa. 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 explica en la sección Motivos empresariales y técnicos, existen diferentes tipos de impulsores 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 multinube con oportunidades para tener un efecto comercial medible:

  • Diferenciación del mercado o innovación posible que permite el uso de servicios en la nube para habilitar ciertas funciones o capacidades empresariales, como las capacidades de inteligencia artificial que usan datos existentes en las instalaciones para entrenar modelos de aprendizaje automático.
  • Ahorros posibles en el costo total de propiedad de una aplicación.
  • Posibilidades de 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:

  • 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 priorizarlas y definir tus olas de migración y enfoques. Luego, puedes identificar los patrones de arquitectura aplicables y los patrones de red compatibles. 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 expande 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 de adopción de una arquitectura híbrida o de múltiples nubes.

Centrada en la nube

Una forma común de empezar a usar la nube pública es el enfoque centrada en la nube. En este enfoque, implementas las 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 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 de prioridad en la nube puede proporcionar ciertas ventajas, 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 sustanciales en comparación con intentar alojar una carga de trabajo nueva en el entorno de nube.

Seguir un enfoque estricto de prioridad 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 impedir que las empresas migren 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 benefician de la 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 que prioriza 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 moderniza los servicios heredados a través de interfaces de API, lo que los desbloquea para que los consuman nuevos servicios y aplicaciones en la nube. Con una plataforma de administración de APIs en la nube, como Apigee, puedes implementar esos 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. La modernización de 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 tu 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 del proceso de migración al mismo tiempo. Como se describe en la sección Migración a Google Cloud, puedes implementar uno de los siguientes tipos de migración, o incluso combinar varios tipos según sea necesario:

  • Vuelve a alojar (lift-and-shift)
  • Cambia la plataforma (lift-and-optimize)
  • Refactorización (reubica y mejora)
  • Reestructuración (continúa con la modernizació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 considerar la viabilidad de tu estrategia desde una perspectiva de costo y tiempo. Te recomendamos que consideres un enfoque de migración por fases, que comience con el traslado o la migración de plataforma y, luego, la refactorización o la reestructuración como el siguiente paso. Por lo general, el traslado y la migración ayudan a optimizar las aplicaciones desde una perspectiva de infraestructura. Una vez que las aplicaciones se ejecutan en la nube, es más fácil usar e integrar los servicios en la nube para optimizarlos 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ña 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 de Google Cloud , comoGoogle Kubernetes Engine (GKE) oCloud Run. Sin embargo, si la arquitectura o infraestructura de una aplicación no es compatible con el entorno de nube de destino tal como está, te recomendamos que comiences por cambiar de plataforma, refactorizar o reestructurar 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 (si corresponde y es factible). La modernización puede requerir la adopción y la implementación de ingeniería de confiabilidad de sitios (SRE) o principios de DevOps, de modo que también es posible que debas extender la modernización de aplicaciones a tu entorno privado en una configuración híbrida. Si bien implementar los principios de SRE implica ingeniería en su esencia, es más un proceso de transformación que un desafío técnico. Por lo tanto, es probable que requiera cambios procedimentales y culturales. Para obtener más información sobre cómo el primer paso para implementar SRE en una organización es obtener la aceptación de los líderes, 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 algunas fortalezas y debilidades. Una ventaja clave de la estrategia de nube híbrida y múltiples nubes 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.

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

En este diagrama conceptual, se ilustran las diferentes rutas o enfoques de migración y modernización que se pueden aplicar de forma simultánea a diferentes cargas de trabajo, impulsados por los requisitos técnicos y empresariales únicos, y los objetivos 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 cambiar de plataforma de MySQL autoalojado a una base de datos administrada con Cloud SQL en Google Cloud.
  • Las máquinas virtuales del frontend de la aplicación se pueden refactorizar para ejecutarse 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 preconfigurados.
  • La solución de balanceo de cargas de hardware local y las capacidades de firewall de aplicación 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 las cargas de trabajo cumplen con alguna de las siguientes condiciones:

  • Tienen una cantidad relativamente pequeña de dependencias en sus entornos.
  • No se considera que valga la pena reestructurarlas, o bien la refactorización antes de la migración no es factible.
  • 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 forma automatizada sin 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 empresariales.
  • Se basan en tecnología de terceros ya obsoleta.
  • Requieren tarifas de licencia de terceros que ya no son económicas.

En el Programa de migración rápida, se muestra cómo Google Cloud ayuda a los clientes a usar prácticas recomendadas, reducir los riesgos, controlar los costos y simplificar su recorrido al éxito en la nube.

Otras consideraciones

En este documento, se destacan las consideraciones de diseño principales que juegan un rol fundamental en la configuración de tu arquitectura híbrida y de múltiples nubes en 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 las 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 Refactorización: mover y mejorar, algunas situaciones 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 orientada a largo plazo:

  • Puedes mejorar el proceso de implementación.
  • Puedes acelerar la cadencia de lanzamiento y acortar los ciclos de respuesta invirtiendo en la infraestructura y las herramientas de integración continua/implementación continua (CI/CD).
  • Puedes usar el refactorización como base para compilar y administrar la 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 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 multinube, es posible que desees poder cambiar las cargas de trabajo entre los entornos de computación que alojan tus datos. Para permitir el movimiento fluido de cargas de trabajo entre entornos, ten en cuenta los siguientes factores:

  • Puedes mover una aplicación de un entorno de procesamiento a otro sin modificar significativamente la aplicación y 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 entrar en conflicto con el hecho de que la carga de trabajo se centre en la nube.

Automatización de la infraestructura

La automatización de la infraestructura es esencial para la portabilidad en las 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 de forma manual, 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 Plantillas 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 para 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 las aplicaciones.

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

  • El uso de 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 use 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 genera gastos de sobrecarga y operativos.
  • A medida que la cadena de herramientas se expande, puede desarrollar complejidades únicas adaptadas a las necesidades específicas de tu empresa. Esta mayor complejidad puede contribuir al aumento de los costos de capacitación.

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 admiten Google Cloud (como Terraform y el modelo de recursos de Kubernetes) para que sean portátiles cuando los publiques.

También puedes considerar 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 compilar y mantener una cadena de herramientas personalizada para lograr la automatización y portabilidad de la carga de trabajo. Sin embargo, el uso exclusivo de VMs como base común dificulta la implementación de aplicaciones realmente 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 desvinculan las aplicaciones de la infraestructura subyacente del host, 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 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 cumplan con los siguientes requisitos:

Cuando se ejecuta una carga de trabajo en Google Cloud, puedes evitar el esfuerzo de instalar y operar Kubernetes mediante el uso de una plataforma administrada de Kubernetes, como Google Kubernetes Engine (GKE). De esta manera, el personal de operaciones puede cambiar su enfoque de la compilación y el mantenimiento de la infraestructura a la compilación y el mantenimiento de 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 necesitas 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 de código abierto administrados 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ña y compila experiencias similares a 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 múltiples nubes con una postura coherente de administración, operaciones y seguridad con GKE Multicloud. 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 de servicio a servicio seguras de 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 muchas 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 red, junto con la proximidad a 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 y facilidades 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.

Traslado de datos

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

Sin embargo, las diversas opciones de traslado de datos que ofrecen Google Cloud, proporcionan a las empresas un conjunto integral de soluciones para ayudar a mover, integrar y transformar sus datos. Estas opciones ayudan a las empresas a almacenar, compartir y acceder a datos en diferentes entornos de una manera que cumpla con sus casos de uso específicos. Esa capacidad facilita, en última instancia, que los tomadores de decisiones empresariales y tecnológicas adopten arquitecturas híbridas y de múltiples nubes.

El movimiento de datos es una consideración importante para la estrategia y la planificación de la arquitectura de las nubes híbridas y de múltiples nubes. Tu equipo debe identificar los diferentes casos de uso de tu empresa y los datos que los potencian. 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 Protección de datos sensibles. La Protección de datos sensibles 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 las prácticas recomendadas para la implementación de 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 multinube, su superficie de ataque puede aumentar según la forma en que se distribuyen sus sistemas y datos en diferentes entornos. Si se combina con el panorama de amenazas que evoluciona constantemente, el aumento de las superficies de ataque puede aumentar el riesgo de acceso no autorizado, pérdida de datos y otros incidentes de seguridad. Ten en cuenta la seguridad con cuidado 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 las redes de los dispositivos de hardware son funciones centradas en la nube y funcionan de forma distribuida. Para obtener más información sobre las capacidades de seguridad de la red centradas en la nube de Google Cloud, consulta Seguridad de la red en la nube.

Las arquitecturas híbridas y de múltiples nubes pueden presentar 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, incluidos diferentes modelos, prácticas recomendadas, capacidades de seguridad de la infraestructura y las aplicaciones, obligaciones de cumplimiento y hasta los nombres de los servicios de seguridad. Estas inconsistencias pueden aumentar el riesgo de seguridad. Además, el modelo de responsabilidad compartida de cada proveedor de servicios en la nube puede diferir. Es fundamental identificar y comprender la demarcación exacta de las responsabilidades en una arquitectura de múltiples nubes.

La observabilidad es clave para obtener estadísticas y métricas de los diferentes ambientes. En una arquitectura multinube, cada nube suele proporcionar herramientas para supervisar la postura de seguridad y los parámetros de configuración incorrectos. Sin embargo, el uso de estas herramientas genera una visibilidad fragmentada, lo que impide crear una inteligencia de amenazas avanzada en todo el entorno. Como resultado, el equipo de seguridad debe cambiar entre herramientas y paneles para mantener la seguridad de la nube. Sin una visibilidad de 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. 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, además, implementar cargas de trabajo enGoogle Cloud, y para ayudarte a planificar y diseñar tu solución en la nube para lograr tus objetivos de seguridad y cumplimiento, explora el centro de prácticas recomendadas de seguridad y el plano de bases empresariales de Google Cloud.

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

  • Desarrolla una estrategia y una arquitectura de seguridad en la nube unificadas y personalizadas. Las estrategias de seguridad híbridas y multinube 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 controles de seguridad, ya que cada entorno puede usar diferentes funciones, parámetros de configuración 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 De esta manera, se puede mejorar la eficiencia y permitir una administración y herramientas unificadas.

  • Usa varios controles de seguridad.

    Por lo general, ningún control de seguridad 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.

  • Supervisar y mejorar de forma continua 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 remediar errores de configuración de seguridad y amenazas de seguridad cibernética. 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 configuraciones incorrectas, vulnerabilidades y mucho más. Security Health Analytics es una herramienta de análisis de evaluaciones de vulnerabilidades administrada. Es una función de Security Command Center que identifica riesgos y vulnerabilidades de seguridad en tu entorno deGoogle Cloud y proporciona recomendaciones para corregirlos.

La administración de la superficie de ataque de Mandiant para Google Cloud permite que tu organización vea mejor los activos de su entorno de nube múltiple o híbrida. Descubre automáticamente recursos de varios proveedores de servicios en la nube, DNS y la superficie de ataque externa extendida para brindarle a tu empresa una comprensión más profunda de 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 multinube 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 a través de la recopilación, el análisis, la detección y la investigación de todos tus datos de seguridad en un solo lugar.

Compila arquitecturas híbridas y de múltiples nubes con Google Cloud: ¿Qué sigue?