Arquitecturas de backend para backends de apps web basadas en el contenido

La arquitectura de backend se refiere a la forma en que se estructura el backend de tu aplicación web. La arquitectura de backend determina cómo las partes de la aplicación se comunican entre sí para procesar solicitudes entrantes y crear respuestas. Cuando compiles una aplicación web, selecciona una arquitectura de backend según tus requisitos y factores específicos, incluidos el costo (en curso y a gran escala), la complejidad de la aplicación, los objetivos de escalamiento y la experiencia de tu equipo.

Específicamente para las aplicaciones web basadas en el contenido, como comercio electrónico, periódicos o blogs, los requisitos fundamentales incluyen la coherencia de tus datos y el rendimiento, en especial a medida que tu aplicación crece a escala global y puede estar más distribuida. Para las aplicaciones web basadas en el contenido, el almacenamiento de datos que usa tu aplicación también es fundamental y se analizará con más detalle en la guía de almacenamiento de datos. Ir más allá de las arquitecturas típicas de aplicaciones, alojar tu contenido y permitir que sea accesible es fundamental para optimizar el rendimiento de tu app. Obtén más información en la guía de hosting para seleccionar la estrategia de hosting correcta y optimizar tu app.

Si tienes un backend existente para una aplicación web, ten en cuenta los límites de tu arquitectura actual. Por ejemplo, a medida que tu aplicación escala verticalmente y exige un aumento de rendimiento y confiabilidad, considera si partes de la aplicación deben refactorizarse o moverse a una arquitectura diferente más adecuada para tu mayor escala. Por ejemplo, las arquitecturas híbridas (o de múltiples nubes) te permiten cambiar algunas cargas de trabajo a la nube antes de realizar una transición completa. Tener en cuenta el costo, el tiempo y el riesgo que implica esta migración también es esencial.

Arquitecturas monolíticas

Una arquitectura monolítica tiene una estructura unificada con todos los componentes de la aplicación estrechamente integrados en una sola base de código. Toda la aplicación se compila como una unidad única e independiente. La arquitectura monolítica tiene varios niveles, en la que diferentes capas de la aplicación realizan tareas específicas.

Capas estructurales

• La interfaz de usuario (IU), que incluye componentes para presentar las funciones de la aplicación, suele ser una aplicación basada en la Web o para computadoras que interactúa con los usuarios.
• La lógica de la aplicación es donde reside la funcionalidad principal.Esta parte de la base de código contiene las reglas, los cálculos y las operaciones que definen el funcionamiento de la aplicación.
• La capa de acceso a los datos contiene funciones para leer y escribir datos, y traducir entre las estructuras de datos de la aplicación y el esquema de la base de datos. Esta capa es responsable de interactuar con la base de datos o el almacenamiento de datos de la aplicación.
• La base de datos es donde la aplicación almacena sus datos. Por lo general, hay una sola base de datos que almacena todos los datos de la aplicación, incluidos los datos del usuario, las configuraciones y otra información.
• Los componentes de middleware controlan tareas como la autenticación, el enrutamiento de solicitudes y la validación de datos. Estos componentes ayudan a administrar el flujo de datos y las solicitudes.
• Algunas aplicaciones monolíticas tienen puntos de integración con APIs o servicios externos. Estos puntos permiten que la aplicación interactúe con servicios de terceros, fuentes de datos y otros sistemas.

Por lo general, las capas estructurales forman parte de una sola base de código. Esa base de código contiene toda la aplicación y, por lo general, se organiza en directorios, módulos y clases. Los desarrolladores trabajan en varias partes de la base de código para compilar y mantener la aplicación. Sin embargo, toda la aplicación se suele implementar como una sola unidad. Cuando se realizan actualizaciones o cambios, toda la aplicación se vuelve a implementar.

Posibles desafíos

• A medida que crecen las aplicaciones monolíticas, la base de código tiende a volverse compleja y difícil de mantener. Esto puede generar ciclos de desarrollo largos y dificultades para comprender toda la base de código.
• Implementar cambios en una aplicación monolítica puede ser riesgoso, ya que los cambios realizados en una parte del código pueden afectar inadvertidamente otras partes de la aplicación. Esto puede crear un proceso de implementación largo y propenso a errores.
• Las aplicaciones monolíticas puede ser difícil de escalar, ya que se implementan como una sola unidad. Debes escalar toda la aplicación, incluso si solo un componente experimenta una mayor demanda.
• Las aplicaciones monolíticas a menudo dependen de una sola pila tecnológica o de un solo lenguaje de programación. Por lo tanto, tu capacidad de usar la mejor herramienta para una tarea específica dentro de la aplicación puede ser limitada.
• Incluso durante períodos de baja demanda, las aplicaciones monolíticas requieren muchos recursos para funcionar. Los costos de mantenimiento también aumentan a medida que la aplicación avanza, ya que se vuelve más difícil actualizarla y aplicarle parches sin causar regresiones.
• Los equipos de desarrollo que trabajan en aplicaciones monolíticas suelen organizarse en torno a toda la aplicación, lo que genera equipos más grandes y una coordinación más compleja entre los miembros del equipo.

Uso sugerido

Las arquitecturas monolíticas son adecuadas cuando una aplicación tiene requisitos sencillos y el equipo de desarrollo es pequeño. A medida que una aplicación crece en complejidad y escala, o cuando diferentes partes de la aplicación requieren diferentes tecnologías o estrategias de implementación, las arquitecturas monolíticas pueden volverse menos flexibles y más difíciles de mantener.

Puedes crear y administrar máquinas virtuales que pueden ejecutar aplicaciones monolíticas en Compute Engine. Tienes el control total sobre los sistemas operativos, el software y la administración de estas máquinas virtuales para ejecutar tu aplicación monolítica.

Con un servicio de plataforma como servicio, como App Engine, puedes compilar tu aplicación y ejecutarla en una infraestructura completamente administrada que se escala automáticamente con las solicitudes.

Si tu aplicación monolítica está alojada en contenedores, puedes ejecutarla con Google Kubernetes Engine (GKE) o Cloud Run. Se pueden usar servicios como Cloud SQL o Cloud Spanner a fin de almacenar datos para aplicaciones monolíticas. Considera una combinación de servicios y sistemas según los requisitos específicos de tu aplicación.

Arquitecturas sin servidores

Mediante una arquitectura sin servidores, puedes compilar y ejecutar aplicaciones sin administrar servidores físicos ni virtuales. El proveedor de servicios en la nube administra automáticamente la infraestructura, el escalamiento y la asignación de recursos para que los desarrolladores puedan enfocarse en escribir el código para sus aplicaciones. Las arquitecturas sin servidores pueden simplificar el desarrollo, reducir la sobrecarga operativa y optimizar los costos, ya que eliminan la necesidad de mantener servidores. Son adecuadas para microservicios, procesamiento de datos en tiempo real, aplicaciones web con cargas de trabajo variables y procesamiento de eventos.

Arquitecturas sin servidores basadas en eventos

Las arquitecturas sin servidores basadas en eventos son un tipo específico de arquitectura de computación sin servidores que se basa en eventos o activadores para iniciar la ejecución de funciones o microservicios. Los componentes del sistema se comunican a través de eventos y las funciones se invocan en respuesta a ellos. A menudo, dependen de la comunicación asíncrona, ya que los eventos activan las funciones y, luego, las procesan de forma independiente. Además, pueden producir eventos que activen acciones posteriores. Este tipo de arquitectura sin servidores es una buena opción para compilar sistemas escalables, responsivos y con acoplamiento bajo.

Google Cloud Functions y Cloud Functions para Firebase te permiten compilar e implementar funciones controladas por eventos en un entorno completamente administrado y sin servidores. Te permite ejecutar código en respuesta a varios eventos y activadores, incluidas las solicitudes HTTP, los mensajes de Cloud Pub/Sub, los cambios de Google Cloud Storage y las actualizaciones de Firebase Realtime Database, sin la necesidad de administrar la infraestructura. Las funciones clave incluyen compatibilidad con varios lenguajes, escalabilidad, facturación detallada, integraciones de terceros, registro y supervisión sólidos y, también, integración en otros servicios de Google y Firebase.

Las arquitecturas sin servidores pueden ser rentables para muchos casos de uso, en especial para aplicaciones con cargas de trabajo variables, necesidades de desarrollo rápido y tráfico impredecible. La confiabilidad depende del proveedor de servicios en la nube y se celebran acuerdos de nivel de servicio (ANS) para garantizar objetivos de rendimiento y confiabilidad específicos. Debes evaluar tu caso de uso y requisitos particulares para determinar si la arquitectura sin servidores es la mejor opción.

Creación de contenedores

La creación de contenedores permite que las aplicaciones y sus dependencias se empaqueten en contenedores livianos y portátiles. Proporcionan un entorno de aplicaciones coherente que admite el desarrollo y la implementación en diferentes sistemas y plataformas. Algunas plataformas sin servidores ofrecen la capacidad de ejecutar cargas de trabajo en contenedores. Ejecutar contenedores en un entorno sin servidores puede ser beneficioso cuando tienes cargas de trabajo complejas o con estado que no se pueden expresar como funciones básicas. Proporciona flexibilidad en términos de compatibilidad de lenguajes y entornos de ejecución.

Cloud Run es una plataforma de computación sin servidores que permite a los desarrolladores implementar y ejecutar aplicaciones en contenedores en un entorno completamente administrado. Proporciona una forma sencilla de compilar, implementar y escalar aplicaciones sin administrar la infraestructura subyacente. Es adecuado para una amplia gama de aplicaciones web y de microservicios, en especial aquellas con cargas de trabajo variables, y en las que la creación de contenedores ofrece beneficios en términos de coherencia y empaquetado de aplicaciones.

Arquitecturas de microservicios

Las aplicaciones se dividen en partes pequeñas que tienen acoplamiento bajo y que implementan funciones o capacidades distintas. Estos servicios pueden comunicarse a través de mensajes asíncronos, canales basados en eventos o directamente a través de la exposición de una interfaz. Cada servicio se desarrolla, prueba y escala de forma independiente en su contenedor, que a menudo se administra a través de un servicio de organización, como Kubernetes, o se implementa mediante una plataforma administrada, como Cloud Run.

Las implementaciones de microservicios también suelen aprovechar el paradigma de la aplicación sin servidores, ya que no dependen de un servidor centralizado.

Separar una aplicación en servicios autónomos puede simplificar un sistema complejo. Los límites y objetivos bien definidos pueden acelerar el desarrollo y mejorar el mantenimiento. Cada microservicio se puede desarrollar de forma independiente con los frameworks o las herramientas más eficaces. La comunicación entre servicios suele controlarse mediante eventos, comunicaciones de publicación y suscripción, canalizaciones de mensajes o llamadas de procedimiento remoto, como gRPC.

Para la organización de tareas dentro de una arquitectura de microservicio, considera usar un framework que admita las plataformas a las que apuntas, suficiente profundidad para las tareas y los tipos de flujos de trabajo que estás organizando, así como el manejo de errores y la telemetría para depurar problemas. Las opciones populares incluyen ofertas de conductores o de un proveedor de servicios en la nube, como Google Workflows.

Las aplicaciones basadas en microservicios pueden ser complejas de desarrollar y mantener debido a su naturaleza distribuida y la necesidad de comunicación dentro del servicio. Por lo tanto, administrar las implementaciones, la supervisión y el registro es más complejo que otras opciones de arquitectura. Dado que la confiabilidad depende de la arquitectura de los servicios individuales, la naturaleza distribuida puede ofrecer resiliencia adicional, en especial si se implementan y habilitan la supervisión y la telemetría si es necesario.

Comparación de diferentes arquitecturas para backends de aplicaciones web basados en el contenido

En la siguiente tabla, se comparan arquitecturas con los requisitos clave del backend de una aplicación web basada en el contenido.

	Arquitecturas monolíticas	Arquitecturas sin servidores basadas en eventos	Arquitecturas sin servidores y microservicios
Complejidad y mantenimiento	Facilidad de implementación para proyectos pequeños e independientes, pero la complejidad aumenta con el escalamiento. Requieren de mantenimiento y coordinación manuales.	El escalamiento cuenta con una buena compatibilidad y integrada en la plataforma. La solución de problemas y la depuración pueden ser un desafío. No es necesario administrar la infraestructura.	Servicios autónomos que se prueban y se implementan de forma independiente, lo que facilita el mantenimiento de cada unidad. Se requiere una comunicación cuidadosa entre los servicios. Requiere herramientas de administración y organización para gestionar a mayor escala.
Escalabilidad y rendimiento	Eficiente a pequeña escala, difícil de escalar más allá de un tamaño específico. Necesidades de infraestructura específicas, lo que limita las opciones de escalamiento dinámico. Ajuste de escala manual (o uso de servicios manuales) dentro de la arquitectura, por ejemplo, a través del balanceo de cargas	Escalabilidad integrada mediante el uso de una plataforma administrada. Escala en cualquier dirección.	Cada servicio se adapta a una necesidad específica y se puede escalar y optimizar de forma independiente.
Estrategias de resiliencia y resguardo	La implementación es compleja y puede generar tiempo de inactividad (“todo o nada”).	Es inherente al proveedor de servicios en la nube. Cada función independiente se puede reintentar de forma independiente.	Cada servicio es autónomo, lo que hace que el sistema general sea más resistente mediante pruebas y desarrollo independientes.
Experiencia de desarrollo	Desarrollo rápido a pequeña escala mediante un acoplamiento estricto de la arquitectura (por ejemplo, mediante consultas eficientes) Los tiempos de compilación son largos, y la colaboración y las pruebas son difíciles a medida que aumenta la complejidad.	No es necesario mantener y administrar ninguna infraestructura, lo que agiliza el desarrollo. La prueba y la depuración de una aplicación activa dependen de los servicios del proveedor de servicios en la nube.	Los servicios son independientes y pueden desarrollarse de forma independiente. Una gran cantidad de servicios se deben coordinar y administrar.
Costo	El desarrollo complejo puede aumentar los costos. Requiere una inversión significativa en hardware o infraestructura, especialmente a mayor escala. Es difícil lograr eficiencias en los costos a partir del aumento y la reducción vertical de la escala.	Sin costos de hardware dedicado. Escalamiento vertical para optimizar el uso de recursos y el costo (disminuido a cero)	Sin costos de hardware dedicado. Escalamiento vertical para optimizar el costo y el uso de recursos dentro de los límites Costos adicionales por supervisar y administrar un gran conjunto de servicios independientes.

Más información sobre las arquitecturas de backend para aplicaciones web basadas en contenido

Estos son algunos recursos con los que puedes obtener más información sobre las arquitecturas de las aplicaciones web basadas en contenido, incluido cómo migrar tu app a una arquitectura diferente:

• Obtén más información sobre las arquitecturas de backend de apps web con acoplamiento bajo, incluidas las aplicaciones web monolíticas en niveles y sin servidores.

• Migra una app monolítica a una arquitectura de microservicios.

• Casos de uso típicos de Cloud Functions sin servidores.