Patrón híbrido en niveles.

Los componentes de la arquitectura de una aplicación se pueden categorizar como frontend o backend. En algunos casos, estos componentes se pueden alojar para operar desde diferentes entornos de procesamiento. Como parte del patrón de arquitectura híbrida por niveles, los entornos de procesamiento se encuentran en un entorno de procesamiento privado local y en Google Cloud.

Los componentes de la aplicación de frontend están expuestos directamente a los dispositivos o a los usuarios finales. Por lo tanto, estas aplicaciones suelen ser sensibles al rendimiento. Para desarrollar nuevas funciones y mejoras, las actualizaciones de software pueden ser frecuentes. Debido a que las aplicaciones de frontend suelen depender de las aplicaciones de backend para almacenar y administrar datos, y posiblemente la lógica empresarial y el procesamiento de entradas del usuario, a menudo son sin estado o administran solo volúmenes limitados de datos.

Para que sean accesibles y fáciles de usar, puedes compilar tus aplicaciones de frontend con varios frameworks y tecnologías. Algunos factores clave para que una aplicación de frontend sea exitosa incluyen el rendimiento de la aplicación, la velocidad de respuesta y la compatibilidad con el navegador.

Los componentes de la aplicación de backend suelen enfocarse en almacenar y administrar datos. En algunas arquitecturas, la lógica empresarial se puede incorporar en el componente de backend. En general, las nuevas versiones de aplicaciones de backend son menos frecuentes que las de aplicaciones de frontend. Las aplicaciones de backend tienen los siguientes desafíos para administrar:

• Cómo controlar un gran volumen de solicitudes
• Cómo manejar un gran volumen de datos
• Protege los datos
• Mantener datos actuales y actualizados en todas las réplicas del sistema

La arquitectura de aplicaciones de tres niveles es una de las implementaciones más populares para compilar aplicaciones web empresariales, como sitios web de comercio electrónico que contienen diferentes componentes de la aplicación. Esta arquitectura contiene los siguientes niveles. Cada nivel funciona de forma independiente, pero están estrechamente vinculados y todos funcionan juntos.

• Nivel de presentación y frontend web
• Nivel de aplicación
• Acceso a los datos o nivel de backend

Colocar estas capas en contenedores separa sus necesidades técnicas, como los requisitos de escalamiento, y ayuda a migrarlas en un enfoque por fases. Además, te permite implementarlos en servicios en la nube independientes de la plataforma que se pueden portar a todos los entornos, usar la administración automatizada y escalar con plataformas administradas en la nube, como Cloud Run o la edición empresarial de Google Kubernetes Engine (GKE). Además, las bases de datos administradas por Google Cloud, como Cloud SQL, ayudan a proporcionar el backend como la capa de base de datos.

El patrón de arquitectura híbrida en niveles se enfoca en implementar los componentes existentes de la aplicación de frontend en la nube pública. En este patrón, mantienes los componentes existentes de la aplicación de backend en su entorno de computación privado. Según la escala y el diseño específico de la aplicación, puedes migrar los componentes de la aplicación de frontend caso por caso. Para obtener más información, consulta Migra a Google Cloud.

Si tienes una aplicación existente con componentes de backend y frontend alojados en tu entorno local, considera los límites de tu arquitectura actual. Por ejemplo, a medida que tu aplicación se escala y aumentan las demandas de su rendimiento y confiabilidad, debes comenzar a evaluar si las partes de tu aplicación deben refactorizarse o trasladarse a una arquitectura diferente y más óptima. El patrón de arquitectura híbrida por niveles te permite transferir algunas cargas de trabajo y componentes de la aplicación a la nube antes de realizar una transición completa. También es fundamental considerar el costo, el tiempo y el riesgo que implica una migración de este tipo.

En el siguiente diagrama, se muestra un típico patrón de arquitectura híbrida en niveles.

En el diagrama anterior, las solicitudes del cliente se envían al frontend de la aplicación que se aloja en Google Cloud. A su vez, el frontend de la aplicación envía datos al entorno local en el que se aloja el backend de la aplicación (idealmente, a través de una puerta de enlace de API).

Con el patrón de arquitectura híbrida por niveles, puedes aprovechar la infraestructura y los servicios globales de Google Cloud, como se muestra en la arquitectura de ejemplo del siguiente diagrama. Se puede acceder al frontend de la aplicación a través de Google Cloud. También puede agregar elasticidad al frontend mediante el uso del ajuste de escala automático para responder de forma dinámica y eficiente a la demanda de escalamiento sin sobreaprovisionar la infraestructura. Existen diferentes arquitecturas que puedes usar para compilar y ejecutar apps web escalables en Google Cloud. Cada arquitectura tiene ventajas y desventajas para diferentes requisitos.

Para obtener más información, mira el video Tres formas de ejecutar apps web escalables en Google Cloud en YouTube. Para obtener más información sobre las diferentes formas de modernizar tu plataforma de comercio electrónico en Google Cloud, consulta Cómo crear una plataforma de comercio digital en Google Cloud.

En el diagrama anterior, el frontend de la aplicación se aloja en Google Cloud para proporcionar una experiencia del usuario optimizada a nivel global y multirregional que usa el balanceo de cargas, el escalamiento automático y la protección contra DSD a través de Google Cloud Armor.

Con el tiempo, la cantidad de aplicaciones que implementes en la nube pública podría aumentar hasta el punto en el que podrías considerar migrar los componentes de la aplicación de backend a la nube pública. Si esperas entregar mucho tráfico, optar por servicios administrados en la nube podría ayudarte a ahorrar esfuerzo de ingeniería cuando administres tu propia infraestructura. Considera esta opción, a menos que las restricciones o los requisitos exijan el alojamiento de componentes de aplicaciones de backend de forma local. Por ejemplo, si los datos de tu backend están sujetos a restricciones reglamentarias, es probable que debas mantenerlos en las instalaciones. Sin embargo, cuando corresponda y se cumpla con las políticas, usar las funciones de Protección de datos sensibles, como las técnicas de desidentificación, puede ayudarte a mover esos datos cuando sea necesario.

En el patrón de arquitectura híbrida en niveles, también puedes usar Google Distributed Cloud en algunas situaciones. Distributed Cloud te permite ejecutar clústeres de Google Kubernetes Engine en hardware dedicado que Google proporciona y mantiene, y es independiente del centro de datos de Google Cloud. Para asegurarte de que Distributed Cloud cumpla con tus requisitos actuales y futuros, conoce las limitaciones de Distributed Cloud en comparación con una zona de GKE convencional basada en la nube.

Ventajas

Enfocarse primero en las aplicaciones de frontend tiene varias ventajas, entre las que se incluyen las siguientes:

• Los componentes de frontend dependen de los recursos de backend y, en ocasiones, de otros componentes de frontend.
• Los componentes de backend no dependen de los componentes de frontend. Por lo tanto, aislar y migrar aplicaciones de frontend suele ser menos complejo que migrar aplicaciones de backend.
• Como las aplicaciones de frontend a menudo no tienen estado o no administran datos por sí mismas, no suelen ser tan difíciles de migrar como los backends.
  • Los componentes del frontend se pueden optimizar como parte de la migración para usar una arquitectura sin estado. Para obtener más información, mira el video Cómo portar apps web con estado a Cloud Run en YouTube.

La implementación de aplicaciones de frontend existentes o desarrolladas hace poco en la nube pública ofrece varias ventajas:

• Muchas aplicaciones de frontend están sujetas a cambios frecuentes. La ejecución de estas aplicaciones en la nube pública simplifica la configuración de un proceso de integración continua/implementación continua (CI/CD). Puedes usar CI/CD para enviar actualizaciones de manera eficiente y automatizada. Para obtener más información, consulta CI/CD en Google Cloud.
• Los frontends sensibles al rendimiento con cargas de tráfico variables pueden beneficiarse de manera significativa del balanceo de cargas, las implementaciones multirregionales, el almacenamiento en caché de Cloud CDN, las capacidades sin servidores y de escalamiento automático que permite una implementación basada en la nube (idealmente, con una arquitectura sin estado).

• Adoptar microservicios con contenedores mediante una plataforma administrada en la nube, como GKE, te permite usar arquitecturas modernas, como microfrontend, que extienden los microservicios a los componentes del frontend.

  La extensión de microservicios se usa comúnmente con frontends que involucran a varios equipos que colaboran en la misma aplicación. Ese tipo de estructura de equipo requiere un enfoque iterativo y un mantenimiento continuo. Estas son algunas de las ventajas de usar microfrontends:

  • Se puede convertir en módulos de microservicios independientes para el desarrollo, las pruebas y la implementación.
  • Proporciona separación en la que los equipos de desarrollo individuales pueden seleccionar sus tecnologías y códigos preferidos.
  • Puede fomentar ciclos rápidos de desarrollo e implementación sin afectar al resto de los componentes del frontend que otros equipos podrían administrar.

• Ya sea que se implementen interfaces de usuario o APIs, o se maneje la transferencia de datos de Internet de las cosas (IoT), las aplicaciones de frontend pueden beneficiarse de las capacidades de los servicios en la nube, como Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine o Cloud Run.

• Los proxies de API administrados en la nube ayudan a hacer lo siguiente:

  • Separa la API orientada a la app de tus servicios de backend, como los microservicios.
  • Protege las apps de los cambios en el código de backend.
  • Admite tus arquitecturas de frontend existentes impulsadas por APIs, como backend para frontend (BFF), microfrontend y otras.
  • Implementa proxies de API en Apigee para exponer tus APIs en Google Cloud o en otros entornos.

También puedes aplicar el patrón híbrido en niveles a la inversa. Para ello, implementa backends en la nube mientras mantienes los frontends en entornos de computación privados. Aunque es menos común, este enfoque se aplica mejor cuando se trata de un frontend pesado y monolítico. En esos casos, podría ser más fácil extraer las funcionalidades de backend de forma iterativa y, luego, implementar estos nuevos backends en la nube.

En la tercera parte de esta serie, se analizan los posibles patrones de red para habilitar una arquitectura de este tipo. Apigee Hybrid es una plataforma que ayuda a compilar y administrar proxies de API en un modelo de implementación híbrida. Para obtener más información, consulta Arquitectura de acoplamiento flexible, incluidas las arquitecturas monolíticas y de microservicios en niveles.

Prácticas recomendadas

Usa la información de esta sección cuando planifiques tu arquitectura híbrida en niveles.

Prácticas recomendadas para reducir la complejidad

Cuando apliques el patrón de arquitectura híbrido en niveles, ten en cuenta las siguientes prácticas recomendadas que pueden ayudar a reducir su complejidad operativa y de implementación general:

• En función de la evaluación de los modelos de comunicación de las aplicaciones identificadas, selecciona la solución de comunicación más eficiente y eficaz para esas aplicaciones.

Debido a que la mayor parte de la interacción del usuario involucra sistemas que se conectan en múltiples entornos de computación, es importante que estos sistemas cuenten con una conectividad rápida y de baja latencia. Para cumplir con las expectativas de disponibilidad y rendimiento, debes diseñar para una alta disponibilidad, baja latencia y niveles de capacidad de procesamiento adecuados. Desde el punto de vista de la seguridad, la comunicación debe ser detallada y controlada. Lo ideal es que expongas los componentes de la aplicación con APIs seguras. Para obtener más información, consulta Salida con control de acceso.

• Para minimizar la latencia de comunicación entre entornos, selecciona una región de Google Cloud que esté geográficamente cerca del entorno de computación privado en el que se alojan los componentes del backend de tu aplicación. Si quieres obtener más información, consulta Prácticas recomendadas para la selección de regiones de Compute Engine.
• Minimiza las dependencias altas entre sistemas que se ejecutan en diferentes entornos, en especial, cuando la comunicación se maneja de forma síncrona. Estas dependencias pueden disminuir el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por la transferencia de datos salientes.
• Con el patrón de arquitectura híbrida en niveles, es posible que tengas volúmenes más grandes de tráfico entrante de entornos locales que ingresan a Google Cloud en comparación con el tráfico saliente que sale de Google Cloud. Sin embargo, debes conocer el volumen estimado de transferencia de datos salientes que sale de Google Cloud. Si planeas usar esta arquitectura a largo plazo con grandes volúmenes de transferencia de datos salientes, considera usar Cloud Interconnect. Cloud Interconnect puede ayudar a optimizar el rendimiento de la conectividad y puede reducir los cargos por transferencia de datos salientes para el tráfico que cumple con ciertas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.
• Para proteger la información sensible, te recomendamos que encriptes todas las comunicaciones en tránsito. Si se requiere encriptación en la capa de conectividad, puedes usar túneles de VPN, VPN con alta disponibilidad en Cloud Interconnect y MACsec para Cloud Interconnect.

• Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación en diversos backends, recomendamos, cuando corresponda, implementar una puerta de enlace de API o un proxy como una fachada. Esta puerta de enlace o proxy actúa como un punto de control centralizado y realiza las siguientes medidas:

  • Implementa medidas de seguridad adicionales.
  • Protege a las apps cliente y a otros servicios de los cambios en el código de backend.
  • Facilita los registros de auditoría para la comunicación entre todas las aplicaciones multientorno y sus componentes desacoplados.
  • Actúa como una capa de comunicación intermedia entre los servicios heredados y los modernizados.
    • Apigee y Apigee Hybrid te permiten alojar y administrar puertas de enlace híbridas y de nivel empresarial en entornos locales, perimetral, otras nubes y entornos de Google Cloud.

• Para facilitar el establecimiento de configuraciones híbridas, usa Cloud Load Balancing con conectividad híbrida. Esto significa que puedes extender los beneficios del balanceo de cargas en la nube a los servicios alojados en tu entorno de procesamiento local. Este enfoque permite realizar migraciones de cargas de trabajo por fases a Google Cloud con interrupciones mínimas o sin ellas, lo que garantiza una transición fluida para los servicios distribuidos. Para obtener más información, consulta Descripción general de los grupos de extremos de red de conectividad híbrida.

• A veces, el uso de una puerta de enlace de API, un proxy y un balanceador de cargas de aplicaciones en conjunto puede proporcionar una solución más sólida para administrar, proteger y distribuir el tráfico de API a gran escala. El uso de Cloud Load Balancing con puertas de enlace de API te permite lograr lo siguiente:

  • Proporciona APIs de alto rendimiento con Apigee y Cloud CDN para reducir la latencia, alojar APIs a nivel global y aumentar la disponibilidad durante las temporadas de mayor tráfico. Para obtener más información, mira Delivering high-performance APIs with Apigee and Cloud CDN en YouTube.
  • Implementa la administración avanzada del tráfico.
  • Usa Google Cloud Armor como protección contra DSD y servicio de seguridad de red para proteger tus APIs.
  • Administra un balanceo de cargas eficiente en varias puertas de enlace de varias regiones. Para obtener más información, mira Protege las APIs e implementa la conmutación por error multirregional con Private Service Connect y Apigee en YouTube.

• Usa la administración de APIs y la malla de servicios para proteger y controlar la comunicación y la exposición de los servicios con la arquitectura de microservicios.

  • Usa Cloud Service Mesh para permitir una comunicación de servicio a servicio que mantenga la calidad del servicio en un sistema compuesto por servicios distribuidos en los que puedes administrar la autenticación, la autorización y la encriptación entre servicios.
  • Usa una plataforma de administración de API como Apigee que permita que tu organización y las entidades externas consuman esos servicios exponiendo las APIs.

• Establece una identidad común entre los entornos para que los sistemas puedan autenticarse con seguridad a través de los límites del entorno.

• Implementa sistemas de CI/CD y administración de configuraciones en la nube pública. Para obtener más información, consulta Patrón de arquitectura de redes reflejadas.

• Para ayudar a aumentar la eficiencia operativa, usa herramientas coherentes y canalizaciones de CI/CD en todos los entornos.

Prácticas recomendadas para cargas de trabajo individuales y arquitecturas de aplicaciones

• Aunque el enfoque se encuentra en las aplicaciones de frontend en este patrón, mantente al tanto de la necesidad de modernizar tus aplicaciones de backend. Si el ritmo de desarrollo de las aplicaciones de backend es, en gran medida, más lento que el de las aplicaciones de frontend, la diferencia puede causar una complejidad adicional.
• Tratar a las APIs como interfaces de backend optimiza las integraciones, el desarrollo del frontend, las interacciones de los servicios y oculta las complejidades del sistema de backend. Para abordar estos desafíos, Apigee facilita el desarrollo y la administración de la puerta de enlace o el proxy de API para las implementaciones híbridas y de múltiples nubes.
• Elige el enfoque de renderización para tu aplicación web de frontend en función del contenido (estático o dinámico), el rendimiento de la optimización para motores de búsqueda y las expectativas sobre las velocidades de carga de la página.
• Cuando se selecciona una arquitectura para aplicaciones web impulsadas por contenido, hay varias opciones disponibles, incluidas las arquitecturas monolíticas, sin servidores, basadas en eventos y de microservicios. Para seleccionar la arquitectura más adecuada, evalúa en detalle estas opciones en función de tus requisitos actuales y futuros de la aplicación. Para ayudarte a tomar una decisión arquitectónica que esté alineada con tus objetivos técnicos y comerciales, consulta Comparación de diferentes arquitecturas para backends de aplicaciones web impulsados por contenido y Consideraciones clave para backends web.

• Con una arquitectura de microservicios, puedes usar aplicaciones alojadas en contenedores con Kubernetes como la capa de tiempo de ejecución común. Con el patrón de arquitectura híbrida en niveles, puedes ejecutarlo en cualquiera de las siguientes situaciones:

  • En ambos entornos (Google Cloud y tus entornos locales).

    • Cuando usas contenedores y Kubernetes en entornos, tienes la flexibilidad para modernizar las cargas de trabajo y luego migrar a Google Cloud en diferentes momentos. Esto ayuda cuando una carga de trabajo depende en gran medida de otra y no se puede migrar de forma individual, o bien para usar la portabilidad de cargas de trabajo híbridas y aprovechar los mejores recursos disponibles en cada entorno. En todos los casos, GKE Enterprise puede ser una tecnología clave que habilita este enfoque. Para obtener más información, consulta Entorno híbrido de GKE Enterprise.

  • En un entorno de Google Cloud para los componentes de la aplicación migrados y modernizados.

    • Usa este enfoque cuando tengas backends heredados on-premises que no admitan la contenedorización o requieran tiempo y recursos significativos para modernizarse a corto plazo.

    Para obtener más información sobre el diseño y la refactorización de una app monolítica a una arquitectura de microservicios para modernizar la arquitectura de tu aplicación web, consulta Introducción a los microservicios.

• Puedes combinar tecnologías de almacenamiento de datos según las necesidades de tus aplicaciones web. Usar Cloud SQL para datos estructurados y Cloud Storage para archivos multimedia es un enfoque común para satisfacer diversas necesidades de almacenamiento de datos. Dicho esto, la elección depende en gran medida de tu caso de uso. Para obtener más información sobre las opciones de almacenamiento de datos para los backend de aplicaciones impulsadas por contenido y las modalidades eficaces, consulta Opciones de almacenamiento de datos para apps web impulsadas por contenido. Consulta también Explicación de las opciones de bases de datos de Google Cloud.