Los componentes de la arquitectura de una aplicación se pueden clasificar como de frontend o de backend. En algunas situaciones, 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 las aplicaciones de frontend están expuestos directamente a los usuarios finales o a los dispositivos. 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 entrada del usuario), a menudo no tienen estado o administran solo cantidades limitadas de datos.
Para que sean accesibles y utilizables, puedes compilar tus aplicaciones de frontend con varios frameworks y tecnologías. Algunos factores clave para una aplicación de frontend exitosa incluyen el rendimiento de la aplicación, la velocidad de respuesta y la compatibilidad con el navegador.
Los componentes de las aplicaciones de backend suelen enfocarse en almacenar y administrar datos. En algunas arquitecturas, la lógica empresarial se puede incorporar dentro del 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 que deben administrar:
- Cómo manejar un gran volumen de solicitudes
- Manejo de un gran volumen de datos
- Proteger los datos
- Mantener los datos actualizados en todas las réplicas del sistema
La solución de app web 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 opera de forma independiente, pero están estrechamente vinculados y funcionan en conjunto.
- Frontend web y nivel de presentación
- Nivel de aplicación
- Nivel de acceso a los datos o de backend
Colocar estas capas en contenedores separa sus necesidades técnicas, como los requisitos de escalamiento, y ayuda a migrarlas con un enfoque por fases. Además, te permite implementarlos en servicios de nube independientes de la plataforma que pueden ser portátiles en diferentes entornos, usar administración automatizada y escalar con plataformas administradas por la nube, como Cloud Run o la edición Enterprise de Google Kubernetes Engine (GKE). Además, las bases de datos administradas porGoogle Cloud, como Cloud SQL, ayudan a proporcionar el backend como la capa de la base de datos.
El patrón de arquitectura híbrida en niveles se enfoca en implementar los componentes de aplicaciones de frontend existentes en la nube pública. En este patrón, mantienes los componentes de la aplicación de backend existentes 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. Si quieres 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 expande y aumentan las exigencias en cuanto a su rendimiento y confiabilidad, debes comenzar a evaluar si se deben refactorizar partes de tu aplicación o moverlas a una arquitectura diferente y más óptima. El patrón de arquitectura híbrida por niveles te permite trasladar algunas cargas de trabajo y componentes de la aplicación a la nube antes de realizar una transición completa. También es fundamental tener en cuenta 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 de clientes 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 de vuelta 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 en niveles, puedes aprovechar la infraestructura y los servicios globales deGoogle 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 usando el ajuste de escala automático para responder de manera dinámica y eficiente a la demanda de escalamiento sin aprovisionar en exceso la infraestructura. Existen diferentes arquitecturas que puedes usar para compilar y ejecutar aplicaciones web escalables en Google Cloud. Cada arquitectura tiene ventajas y desventajas para diferentes requisitos.
Para obtener más información, mira Three ways to run scalable web apps on Google Cloud en YouTube. Para obtener más información sobre las diferentes formas de modernizar tu plataforma de comercio electrónico enGoogle 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 enGoogle Cloud para proporcionar una experiencia del usuario multirregional y optimizada a nivel global que utiliza el balanceo de cargas global, el ajuste de escala automático y la protección contra DSD a través de Google Cloud Armor.
Con el tiempo, la cantidad de aplicaciones que implementas en la nube pública puede aumentar hasta el punto en el que podrías considerar migrar los componentes de las aplicaciones de backend a la nube pública. Si prevés que tu sitio tendrá mucho tráfico, optar por servicios administrados en la nube puede 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 alojar los componentes de la aplicación 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 cumplan los requisitos, usar las capacidades de Sensitive Data Protection, como las técnicas de desidentificación, puede ayudarte a migrar esos datos cuando sea necesario.
En el patrón de arquitectura híbrida por niveles, también puedes usar Google Distributed Cloud en algunos casos. Distributed Cloud te permite ejecutar clústeres de Google Kubernetes Engine en hardware dedicado que proporciona y mantiene Google, y que es independiente del Google Cloud centro de datos. Para asegurarte de que Distributed Cloud satisfaga tus requisitos actuales y futuros, debes conocer sus limitaciones 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 la arquitectura sin estado. Para obtener más información, mira 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 una carga de tráfico variable 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 ajuste de escala automático que permite una implementación basada en la nube (idealmente con una arquitectura sin estado).
Adoptar microservicios con contenedores a través de una plataforma administrada por la nube, como GKE, te permite usar arquitecturas modernas, como microfrontend, que extienden los microservicios a los componentes de frontend.
La extensión de microservicios se usa comúnmente con los 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, ya que los equipos de desarrollo individuales pueden seleccionar sus tecnologías y código preferidos.
- Puede fomentar ciclos rápidos de desarrollo e implementación sin afectar al resto de los componentes de frontend que podrían administrar otros equipos.
Ya sea que implementen interfaces de usuario o APIs, o manejen 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 por Cloud ayudan a hacer lo siguiente:
- Desacopla 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 basadas en APIs, como backend para frontend (BFF), microfrontend y otras.
- Expón tus APIs en Google Cloud o en otros entornos implementando proxies de API en Apigee.
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 redes para habilitar esa arquitectura. Apigee Hybrid ayuda como plataforma para compilar y administrar proxies de API en un modelo de implementación híbrida. Para obtener más información, consulta Arquitectura con 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 por niveles.
Prácticas recomendadas para reducir la complejidad
Cuando apliques el patrón de arquitectura híbrido en niveles, considera las siguientes prácticas recomendadas que pueden ayudarte a reducir su complejidad operativa y de implementación general:
- Según 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 tu sistema para que tenga 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 controlada.
- Para minimizar la latencia de comunicación entre entornos, selecciona una región deGoogle Cloud que esté cerca de la ubicación geográfica del entorno de computación privado en el que se alojan los componentes de backend de tu aplicación. Si deseas 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 por niveles, es posible que tengas volúmenes más grandes de tráfico entrante desde entornos locales que ingresan aGoogle Cloud en comparación con el tráfico saliente que sale de Google Cloud. Sin embargo, debes conocer el volumen previsto de transferencia de datos salientes que saldrá 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 unificadora. 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 las apps para clientes y 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 de varios entornos 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, perimetrales, otras nubes y entornos deGoogle 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 de Cloud a los servicios alojados en tu entorno de procesamiento local. Este enfoque permite migraciones de cargas de trabajo por fases a Google Cloud con una interrupción mínima o nula del servicio, lo que garantiza una transición fluida para los servicios distribuidos. Para obtener más información, consulta la 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, o 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 en las temporadas de tráfico pico. Para obtener más información, mira Delivering high-performing APIs with Apigee and Cloud CDN en YouTube.
- Implementa la administración avanzada del tráfico.
- Usa Google Cloud Armor como servicio de protección contra DSD y seguridad de red para proteger tus APIs.
- Administra el balanceo de cargas eficiente en las puertas de enlace de varias regiones. Para obtener más información, mira Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee (Protege las APIs e implementa la conmutación por error multirregional con Private Service Connect y Apigee) en YouTube.
Utiliza la administración de APIs y la malla de servicios para proteger y controlar la comunicación y la exposición de servicios con la arquitectura de microservicios.
- Usa Cloud Service Mesh para permitir la comunicación de servicio a servicio que mantiene la calidad del servicio en un sistema compuesto por servicios distribuidos en el que puedes administrar la autenticación, la autorización y la encriptación entre servicios.
- Usa una plataforma de administración de APIs, como Apigee, que permita que tu organización y las entidades externas consuman esos servicios exponiéndolos como 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 la configuración en la nube pública. Para obtener más información, consulta Patrón de arquitectura de redes duplicadas.
Para ayudar a aumentar la eficiencia operativa, usa herramientas coherentes y canalizaciones de CI/CD en todos los entornos.
Prácticas recomendadas para arquitecturas de aplicaciones y cargas de trabajo individuales
- 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 las APIs como interfaces de backend optimiza las integraciones, el desarrollo de frontend, las interacciones de servicios y oculta las complejidades del sistema de backend. Para abordar estos desafíos, Apigee facilita el desarrollo y la administración de proxies o puertas de enlace de API para implementaciones híbridas y de múltiples nubes.
- Elige el enfoque de renderización para tu aplicación web de frontend según el 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 basadas en 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 a fondo estas opciones en función de los requisitos actuales y futuros de tu aplicación. Para ayudarte a tomar una decisión de arquitectura que se alinee con tus objetivos comerciales y técnicos, consulta Comparación de diferentes arquitecturas para back-ends de aplicaciones web basadas en contenido y Consideraciones clave para los back-ends 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 diferentes entornos, tienes la flexibilidad de 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 Google Cloud para los componentes de la aplicación modernizada y migrada
- Usa este enfoque cuando tengas back-ends heredados locales que no admitan la contenedorización o que requieran una gran cantidad de tiempo y recursos para modernizarse a corto plazo.
Para obtener más información sobre el diseño y la refactorización de una app monolítica en 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 mucho de tu caso de uso. Para obtener más información sobre las opciones de almacenamiento de datos para los backends de aplicaciones basadas en contenido y las modalidades eficaces, consulta Opciones de almacenamiento de datos para apps web basadas en contenido. Consulta también Explicación de las opciones de bases de datos. Google Cloud