Los componentes de la arquitectura de una aplicación se pueden clasificar como frontend o backend. En algunos casos, estos componentes se pueden alojar para que funcionen en diferentes entornos informáticos. Como parte del patrón de arquitectura híbrida por niveles, los entornos de computación se encuentran en un entorno de computación privado on‐premise y en Google Cloud.
Los componentes de la aplicación frontend se exponen directamente a los usuarios finales o a los dispositivos. Por este motivo, estas aplicaciones suelen ser sensibles al rendimiento. Para desarrollar nuevas funciones y mejoras, las actualizaciones de software pueden ser frecuentes. Como las aplicaciones de frontend suelen depender de las aplicaciones de backend para almacenar y gestionar datos (y, posiblemente, lógica empresarial y procesamiento de entradas de usuario), a menudo son sin estado o gestionan solo volúmenes de datos limitados.
Para que sean accesibles y utilizables, puedes crear tus aplicaciones frontend con varios frameworks y tecnologías. Algunos factores clave para que una aplicación frontend funcione correctamente son el rendimiento de la aplicación, la velocidad de respuesta y la compatibilidad con el navegador.
Los componentes de las aplicaciones backend suelen centrarse en almacenar y gestionar datos. En algunas arquitecturas, la lógica empresarial puede incorporarse en el componente backend. Las nuevas versiones de las aplicaciones de backend suelen ser menos frecuentes que las de las aplicaciones de frontend. Las aplicaciones backend tienen los siguientes problemas que gestionar:
- Gestionar un gran volumen de solicitudes
- Gestionar un gran volumen de datos
- Proteger los datos
- Mantener los datos actualizados en todas las réplicas del sistema
La solución de aplicación web de tres niveles es una de las implementaciones más populares para crear aplicaciones web empresariales, como sitios web de comercio electrónico que contienen diferentes componentes de aplicación. Esta arquitectura contiene los siguientes niveles. Cada nivel funciona de forma independiente, pero están estrechamente vinculados y funcionan en conjunto.
- Frontend web y nivel de presentación
- Nivel de aplicación
- Acceso a datos o nivel de backend
Al poner estas capas en contenedores, se separan sus necesidades técnicas, como los requisitos de escalado, y se facilita la migración de forma gradual. Además, te permite desplegarlas en servicios en la nube independientes de la plataforma que se pueden transferir entre entornos, usar la gestión automatizada y escalar con plataformas gestionadas en la nube, como Cloud Run o la edición Enterprise de Google Kubernetes Engine (GKE). Además, las Google Cloudbases de datos gestionadas como Cloud SQL ayudan a proporcionar el backend como capa de base de datos.
El patrón de arquitectura híbrida por niveles se centra en desplegar los componentes de la aplicación frontend en la nube pública. En este patrón, mantienes los componentes de la aplicación backend en su entorno de computación privado. En función de la escala y el diseño específico de la aplicación, puedes migrar los componentes de la aplicación frontend caso por caso. Para obtener más información, consulta el artículo Migrar a Google Cloud.
Si tienes una aplicación con componentes de backend y frontend alojados en tu entorno local, ten en cuenta los límites de tu arquitectura actual. Por ejemplo, a medida que tu aplicación se vaya ampliando y aumenten las exigencias de rendimiento y fiabilidad, deberías empezar a evaluar si es necesario refactorizar partes de la aplicación o moverlas a una arquitectura diferente y más óptima. El patrón de arquitectura híbrida por niveles te permite migrar algunas cargas de trabajo y componentes de aplicaciones a la nube antes de hacer una transición completa. También es fundamental tener en cuenta el coste, el tiempo y los riesgos que conlleva una migración de este tipo.
En el siguiente diagrama se muestra un patrón de arquitectura híbrida por niveles típico.
En el diagrama anterior, las solicitudes de los clientes se envían al frontend de la aplicación, que está alojado en Google Cloud. A su vez, el frontend de la aplicación envía datos al entorno local donde se aloja el backend de la aplicación (idealmente, a través de una pasarela de APIs).
Con el patrón de arquitectura híbrida por niveles, puedes aprovechar laGoogle Cloud infraestructura y los servicios globalesGoogle Cloud , como se muestra en el ejemplo de arquitectura del siguiente diagrama. Se puede acceder al frontend de la aplicación a través de Google Cloud. También puede añadir elasticidad al frontend mediante el escalado automático para responder de forma dinámica y eficiente a la demanda de escalado sin aprovisionar en exceso la infraestructura. Hay diferentes arquitecturas que puedes usar para crear y ejecutar aplicaciones web escalables en Google Cloud. Cada arquitectura tiene ventajas e inconvenientes en función de los requisitos.
Para obtener más información, consulta el vídeo Tres formas de ejecutar aplicaciones web escalables en Google Cloud en YouTube. Para obtener más información sobre las diferentes formas de modernizar su plataforma de comercio electrónico enGoogle Cloud, consulte 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 ofrecer una experiencia de usuario multirregional y optimizada a nivel mundial que utiliza el balanceo de carga, el escalado automático y la protección frente a DDoS a través de Google Cloud Armor.
Con el tiempo, el número de aplicaciones que implementes en la nube pública puede aumentar hasta el punto de que te plantees trasladar los componentes de la aplicación backend a la nube pública. Si prevés que vas a tener mucho tráfico, optar por servicios gestionados en la nube puede ayudarte a ahorrar tiempo y esfuerzo de ingeniería al gestionar tu propia infraestructura. Considera esta opción a menos que las restricciones o los requisitos exijan que los componentes de la aplicación backend se alojen en las instalaciones. Por ejemplo, si los datos de backend están sujetos a restricciones normativas, probablemente tengas que conservarlos en las instalaciones. Sin embargo, si es posible y cumple los requisitos, puedes usar las funciones de Protección de Datos Sensibles, como las técnicas de desidentificación, para transferir 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 proporcionado y mantenido por Google, que está separado del centro de datos. Google Cloud Para asegurarte de que Distributed Cloud cumple tus requisitos actuales y futuros, debes conocer las limitaciones de Distributed Cloud en comparación con una zona de GKE basada en la nube convencional.
Ventajas
Centrarse primero en las aplicaciones 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 del backend no dependen de los componentes del frontend. Por lo tanto, aislar y migrar aplicaciones frontend suele ser menos complejo que migrar aplicaciones backend.
- Como las aplicaciones de frontend suelen ser sin estado o no gestionan datos por sí mismas, suelen ser más fáciles de migrar que 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, consulta el vídeo Cómo migrar aplicaciones web con estado a Cloud Run en YouTube.
Implementar aplicaciones de frontend ya creadas o de nuevo desarrollo en la nube pública ofrece varias ventajas:
- Muchas aplicaciones frontend están sujetas a cambios frecuentes. Ejecutar estas aplicaciones en la nube pública simplifica la configuración de un proceso de integración continua y despliegue continuo (CI/CD). Puedes usar CI/CD para enviar actualizaciones de forma eficiente y automática. Para obtener más información, consulta CI/CD en Google Cloud.
- Los front-ends sensibles al rendimiento con cargas de tráfico variables pueden beneficiarse considerablemente del balanceo de carga, los despliegues multirregionales, el almacenamiento en caché de Cloud CDN, las funciones sin servidor y las funciones de escalado automático que permite un despliegue basado en la nube (idealmente con una arquitectura sin estado).
Si adoptas microservicios con contenedores mediante una plataforma gestionada en la nube, como GKE, podrás usar arquitecturas modernas, como microfrontend, que amplían los microservicios a los componentes del frontend.
La extensión de microservicios se suele usar con las interfaces que implican que varios equipos colaboren en la misma aplicación. Este 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 una separación en la que los equipos de desarrollo pueden seleccionar las tecnologías y el código que prefieran.
- Puede fomentar ciclos rápidos de desarrollo e implementación sin afectar al resto de los componentes del frontend que puedan gestionar otros equipos.
Tanto si implementan interfaces de usuario o APIs como si gestionan la ingesta de datos del Internet de las cosas (IoT), las aplicaciones frontend pueden beneficiarse de las funciones de servicios en la nube como Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine o Cloud Run.
Los proxies de API gestionados en la nube te permiten:
- Desvincula la API orientada a aplicaciones de los servicios de backend, como los microservicios.
- Protege las aplicaciones frente a cambios en el código del backend.
- Admite tus arquitecturas de frontend basadas en APIs, como backend para frontend (BFF) y microfrontend, entre otras.
- Expón tus APIs en Google Cloud u otros entornos implementando proxies de API en Apigee.
También puedes aplicar el patrón híbrido por niveles al revés, desplegando back-ends en la nube y manteniendo los front-ends en entornos informáticos privados. Aunque es menos habitual, este enfoque es el más adecuado cuando se trata de un frontend pesado y monolítico. En estos casos, puede ser más fácil extraer la funcionalidad del backend de forma iterativa y desplegar estos nuevos backends en la nube.
En la tercera parte de esta serie se analizan los posibles patrones de redes para habilitar este tipo de arquitectura. Apigee hybrid es una plataforma que te ayuda a crear y gestionar proxies de API en un modelo de despliegue híbrido. Para obtener más información, consulta Arquitectura con bajo nivel de acoplamiento, incluidas las arquitecturas monolíticas y de microservicios por niveles.
Prácticas recomendadas
Usa la información de esta sección para planificar tu arquitectura híbrida por niveles.
Prácticas recomendadas para reducir la complejidad
Cuando apliques el patrón de arquitectura híbrida por niveles, ten en cuenta las siguientes prácticas recomendadas, que pueden ayudarte a reducir la complejidad general de la implementación y las operaciones:
- 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.
Como la mayoría de las interacciones de los usuarios implican sistemas que se conectan en varios entornos informáticos, es importante que la conectividad entre esos sistemas sea rápida y tenga una latencia baja. Para cumplir las expectativas de disponibilidad y rendimiento, debes diseñar un sistema de alta disponibilidad, baja latencia y niveles de rendimiento adecuados. Desde el punto de vista de la seguridad, la comunicación debe ser detallada y controlada. Lo ideal es exponer los componentes de la aplicación mediante APIs seguras. Para obtener más información, consulta Salida controlada.
- Para minimizar la latencia de comunicación entre entornos, selecciona una Google Cloud región que esté geográficamente cerca del entorno de computación privado en el que se alojan los componentes backend de tu aplicación. Para obtener más información, consulta las prácticas recomendadas para seleccionar regiones de Compute Engine.
- Minimiza las dependencias elevadas entre sistemas que se ejecutan en entornos diferentes, sobre todo cuando la comunicación se gestiona de forma síncrona. Estas dependencias pueden ralentizar el rendimiento, reducir la disponibilidad general y, posiblemente, generar cargos adicionales por transferencia de datos saliente.
- 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 de tráfico saliente.Google Cloud Google Cloud Sin embargo, debes conocer el volumen previsto de transferencia de datos salientes de Google Cloud. Si tienes previsto usar esta arquitectura a largo plazo con volúmenes de transferencia de datos salientes elevados, te recomendamos que utilices Cloud Interconnect. Cloud Interconnect puede ayudarte a optimizar el rendimiento de la conectividad y reducir los cargos por transferencia de datos salientes del tráfico que cumpla determinadas condiciones. Para obtener más información, consulta los precios de Cloud Interconnect.
- Para proteger la información sensible, te recomendamos que cifres todas las comunicaciones en tránsito. Si se requiere cifrado en la capa de conectividad, puedes usar túneles VPN, VPN de alta disponibilidad mediante Cloud Interconnect y MACsec para Cloud Interconnect.
Para superar las incoherencias en los protocolos, las APIs y los mecanismos de autenticación de los diferentes back-ends, te recomendamos que, cuando sea posible, despliegues una pasarela o un proxy de APIs como fachada unificadora. Esta pasarela o proxy actúa como punto de control centralizado y lleva a cabo las siguientes medidas:
- Implementa medidas de seguridad adicionales.
- Protege las aplicaciones cliente y otros servicios frente a cambios en el código del backend.
- Facilita las pistas de auditoría de la comunicación entre todas las aplicaciones de distintos entornos y sus componentes desacoplados.
- Actúa como una capa de comunicación intermedia entre los servicios antiguos y los modernizados.
- Apigee y Apigee hybrid te permiten alojar y gestionar pasarelas híbridas y de nivel empresarial en entornos locales, perimetrales y de otras nubes, así como enGoogle Cloud entornos.
Para facilitar la configuración híbrida, usa Cloud Load Balancing con conectividad híbrida. Esto significa que puedes ampliar las ventajas del balanceo de carga en la nube a los servicios alojados en tu entorno de computación local. Este enfoque permite realizar migraciones de cargas de trabajo por fases a Google Cloud con una interrupción mínima o inexistente del servicio, lo que garantiza una transición fluida para los servicios distribuidos. Para obtener más información, consulta la información general sobre los grupos de puntos finales de red de conectividad híbrida.
A veces, usar una pasarela de API o un proxy y un balanceador de carga de aplicaciones juntos puede proporcionar una solución más sólida para gestionar, proteger y distribuir el tráfico de APIs a gran escala. Usar Cloud Load Balancing con pasarelas de API te permite hacer lo siguiente:
- Ofrece APIs de alto rendimiento con Apigee y Cloud CDN para reducir la latencia, alojar APIs en todo el mundo y aumentar la disponibilidad durante las temporadas de tráfico máximo. Para obtener más información, consulta el vídeo Delivering high-performing APIs with Apigee and Cloud CDN en YouTube.
- Implementa la gestión avanzada del tráfico.
- Usa Cloud Armor como servicio de protección contra ataques DDoS y de seguridad de red para proteger tus APIs.
- Gestiona el balanceo de carga eficiente en las pasarelas de varias regiones. Para obtener más información, consulta el vídeo Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee en YouTube.
Usa la gestió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 que los servicios se comuniquen entre sí y mantengan su calidad en un sistema compuesto por servicios distribuidos en el que puedes gestionar la autenticación, la autorización y el cifrado entre servicios.
- Usa una plataforma de gestión de APIs como Apigee, que permite que tu organización y entidades externas consuman esos servicios exponiéndolos como APIs.
Establecer una identidad común entre los entornos para que los sistemas puedan autenticarse de forma segura a través de los límites de los entornos.
Implementar sistemas de CI/CD y de gestión de la configuración en la nube pública. Para obtener más información, consulta el patrón de arquitectura de red reflejada.
Para aumentar la eficiencia operativa, usa herramientas y canalizaciones de CI/CD coherentes en todos los entornos.
Prácticas recomendadas para arquitecturas de cargas de trabajo y aplicaciones individuales
- Aunque este patrón se centra en las aplicaciones frontend, no olvides que también debes modernizar las backend. Si el ritmo de desarrollo de las aplicaciones backend es considerablemente más lento que el de las aplicaciones frontend, la diferencia puede generar una complejidad adicional.
- Tratar las APIs como interfaces de backend simplifica las integraciones, el desarrollo del frontend y las interacciones de los servicios, además de ocultar las complejidades del sistema de backend. Para hacer frente a estos retos, Apigee facilita el desarrollo y la gestión de gateways o proxies de APIs para despliegues híbridos y multinube.
- Elige el método de renderización de tu aplicación web frontend en función del contenido (estático o dinámico), el rendimiento de la optimización para buscadores y las expectativas sobre la velocidad de carga de las páginas.
- Cuando se selecciona una arquitectura para aplicaciones web basadas en contenido, hay varias opciones disponibles, como las arquitecturas monolíticas, sin servidor, 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 sobre la arquitectura que se ajuste a tus objetivos empresariales 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 en contenedores con Kubernetes como capa de tiempo de ejecución común. Con el patrón de arquitectura híbrida por niveles, puedes ejecutarlo en cualquiera de los siguientes casos:
En ambos entornos (Google Cloud y en tus entornos locales).
- Si usas contenedores y Kubernetes en distintos entornos, puedes modernizar las cargas de trabajo y, después, migrar a Google Cloud en momentos diferentes. Esto resulta útil cuando una carga de trabajo depende en gran medida de otra y no se puede migrar de forma individual, o 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. Para obtener más información, consulta el artículo sobre el entorno híbrido de GKE Enterprise.
En un Google Cloud entorno para los componentes de la aplicación migrados y modernizados.
- Utiliza este enfoque cuando tengas back-ends antiguos en las instalaciones que no admitan la contenerización o que requieran mucho tiempo y recursos para modernizarse a corto plazo.
Para obtener más información sobre cómo diseñar y refactorizar una aplicación monolítica para convertirla en una arquitectura de microservicios y modernizar la arquitectura de tu aplicación web, consulta el artículo Introducción a los microservicios.
Puedes combinar tecnologías de almacenamiento de datos en función de las necesidades de tus aplicaciones web. Usar Cloud SQL para datos estructurados y Cloud Storage para archivos multimedia es una práctica habitual para satisfacer diversas necesidades de almacenamiento de datos. Dicho esto, la elección depende en gran medida de tu caso práctico. Para obtener más información sobre las opciones de almacenamiento de datos para back-ends de aplicaciones basadas en contenido y las modalidades eficaces, consulta Opciones de almacenamiento de datos para aplicaciones web basadas en contenido. Consulta también Explicación de las opciones de bases de datos Google Cloud .