Acerca tu aplicación web con Volterra App Delivery Network (ADN)

Pranav DharwadkarVicepresidente de Productos de IA | F5

Este blog inaugura una nueva serie sobre problemas reales a los que se enfrentan las empresas y explica cómo la red de entrega de aplicaciones (ADN) de Volterra aborda los problemas descritos. En concreto, este artículo detalla uno de los principales retos relacionados con el rendimiento de las aplicaciones web al que se enfrentan a diario las empresas en línea de todo el mundo. Este reto se agrava aún más ahora que la mayoría de los consumidores trabajan desde casa. Explico cómo Volterra puede ayudar a las empresas a «eliminar la distancia» de sus aplicaciones web para mejorar su rendimiento en un 77 %, sin necesidad de reescribirlas.

¿Qué es el rendimiento de las aplicaciones web?

El rendimiento de una aplicación web suele medirse por el tiempo que tarda el contenido de la página en hacerse visible para el usuario final. Los desarrolladores web utilizan varias métricas para medir el rendimiento de sus aplicaciones web, como First Contentful Paint, Largest Contentful Paint o Document Complete. En este blog, he utilizado la métrica «Document Complete» para medir el rendimiento de mi aplicación web. Los desarrolladores web miden estas métricas con herramientas como Web Page Test, Google Lighthouse o Rigor.

¿Por qué es importante el rendimiento de las aplicaciones web?

Una ligera degradación del rendimiento de una aplicación web tiene un enorme impacto en la experiencia del usuario y, por consiguiente, en las ventas a través del portal en línea. El gigante del comercio electrónico Amazon señaló que una degradación de un segundo en el rendimiento de una aplicación se traduce en una pérdida de ingresos de 1.600 millones de dólares. Empresas en línea de diversos sectores observan un impacto económico similar, según lo indicado por Akamai en este informe algo antiguo. Google y Microsoft presentan cifras similares sobre el impacto económico.

Figura 1

Estos datos confirman claramente que el rendimiento de las aplicaciones web es una prioridad para las empresas en línea.

¿Cuál es el reto?

Veamos un ejemplo concreto de una empresa online del sector del comercio electrónico. Muchas empresas de comercio electrónico alojan su aplicación web en uno o unos pocos centros de datos, que no están presentes en todos los países donde residen sus usuarios. Cuando el usuario se encuentra en un país o región diferente al del centro de datos, la elevada latencia de la red entre el usuario y el centro de datos hace que las páginas tarden entre 6 y 12 segundos en cargarse. Como se ha mencionado anteriormente, cuando el tiempo de carga supera los 5 segundos, la probabilidad de abandono aumenta hasta el 90 %.

Analicemos en detalle la carga de una página de una aplicación web, como se muestra en la figura 2

Figura 2

• En primer lugar, se establece una sesión SSL segura, lo que requiere el intercambio de 6 mensajes entre el navegador del usuario y la aplicación web.
• A continuación, la aplicación web suele utilizar las cookies del navegador del usuario para determinar si este tiene una cuenta con el proveedor de comercio electrónico.
• En función de la cookie, si el usuario tiene una cuenta, se le muestra una página de inicio de sesión; de lo contrario, se le muestra una página para finalizar la compra como invitado.

El mero hecho de intercambiar seis mensajes para establecer la sesión SSL segura a través de enlaces de alta latencia (posiblemente transatlánticos o transpacíficos) afecta sin duda a los tiempos de carga de la página y, por consiguiente, se traduce en una mala experiencia de usuario.

¿Cómo puede Volterra ADN mejorar el rendimiento de las aplicaciones?

Existen muchas técnicas para mejorar el rendimiento de las aplicaciones web mediante su optimización, como comprimir las imágenes u optimizar las dependencias para reducir los tiempos de carga de las páginas. A menudo, estas optimizaciones pueden no ser posibles debido a los requisitos empresariales que condicionan el diseño de la aplicación. Incluso si fueran posibles, podrían no ser una opción viable porque los desarrolladores que crearon la aplicación ya no trabajan en la organización o están ocupados desarrollando nuevos servicios. Por ello, los equipos de DevOps de las empresas de comercio electrónico valoran las soluciones que permiten mejorar el rendimiento de las aplicaciones sin necesidad de modificarlas.

Volterra ofrece dos productos, VoltMesh y VoltStack, que, combinados con la ADN de Volterra, pueden mejorar el rendimiento de las aplicaciones hasta en un 75 % (consulte la demostración en la siguiente sección). VoltMesh de Volterra es un producto de redes y seguridad distribuido globalmente que, cuando se configura en la ADN de Volterra, también proporciona funciones de aceleración de aplicaciones. VoltStack de Volterra permite gestionar de forma distribuida el despliegue y el ciclo de vida de las aplicaciones, lo que permite a los usuarios trasladar partes de sus aplicaciones a la ADN de Volterra para mejorar aún más su rendimiento.

VoltMesh y VoltStack mejoran el rendimiento de las aplicaciones web de las empresas de comercio electrónico de las tres formas siguientes

Solución 1: terminación SSL (también conocida como descarga TLS) en Volterra ADN

La solución más sencilla para mejorar el rendimiento de las aplicaciones web consiste en finalizar la sesión SSL en la ADN global de Volterra. Los seis mensajes necesarios para establecer la sesión SSL se envían localmente al extremo de la red global situado en el mismo país, sin atravesar enlaces transatlánticos ni transpacíficos. Se mantendrá una sesión SSL persistente entre el sitio remoto de la red global de Volterra y el servidor de origen, lo que mejorará aún más el rendimiento. Esto se puede visualizar como se muestra en la Figura 3.

Figura 3

Solución 2: Trasladar a Volterra ADN el procesamiento sensible a la latencia, como el procesamiento de cookies

Para mejorar aún más el rendimiento, las empresas pueden desplegar en la ADN las partes de sus aplicaciones sensibles a la latencia. Algunos ejemplos de partes de una aplicación web sensibles a la latencia son el procesamiento de cookies, GraphQL o el patrón backend-for-frontend. En el caso de una empresa de comercio electrónico, normalmente se procesan las cookies para determinar qué página mostrar al usuario; por ejemplo, si el usuario tiene una cuenta, se muestra la página de inicio de sesión y, de lo contrario, una página para visitantes. Procesar las cookies en nuestra ADN mejora drásticamente el rendimiento en comparación con hacerlo en centros de datos centralizados o en la nube, al otro lado del mundo. Esto se puede visualizar como se muestra en la Figura 4.

Figura 4

Solución 3: Trasladar el propio front-end de la aplicación web (p. ej., el catálogo de productos) al extremo de la red, es decir, a la tienda física

Muchos comercios, como Macy’s, Home Depot y Target, también cuentan con tiendas físicas en las que los consumidores consultan el catálogo de productos en línea para comprobar la ubicación de los artículos y acceder a ofertas y cupones. Para mejorar la experiencia de usuario, podrían optar por trasladar únicamente el front-end de su aplicación web a la infraestructura informática de la tienda. El resto de los componentes de la aplicación, como las bases de datos, podrían permanecer en el centro de datos del back-end, ya que no se accedería a ellos con tanta frecuencia como al catálogo de productos del front-end. Esto se puede visualizar como se muestra en la Figura 5.

Figura 5

Principios arquitectónicos clave que deben tenerse en cuenta en cualquier solución

Este problema es, en esencia, un problema de computación distribuida entre múltiples nubes heterogéneas. Los equipos de DevOps podrían optar por crear su propia solución combinando soluciones parciales de distintos proveedores, como proveedores de nube pública, de CDN o de servicios en el edge, o bien adquirir una solución integral de proveedores de plataformas de servicios de nube distribuida. Los retos se destacan en la Figura 6.

Figura 6

Estos son los principios arquitectónicos clave que los equipos de DevOps deben tener en cuenta al evaluar cualquier solución.

1. Entorno de ejecución de aplicaciones coherente en varias nubes: La aplicación de los equipos de DevOps se distribuirá entre su nube de backend, que podría ser un centro de datos privado o una nube pública, sus ubicaciones en el extremo de la red y sus tiendas físicas, cada una de las cuales podría tener un entorno de ejecución de aplicaciones completamente distinto. Los equipos de DevOps deberían considerar seriamente soluciones que aprovechen Kubernetes para proporcionar un entorno de ejecución de aplicaciones coherente en todas estas nubes distribuidas. Kubernetes homogeneiza las nubes y facilita el traslado de componentes de las aplicaciones entre ellas.
2. Enrutamiento del tráfico por proximidad geográfica: Dado que el front-end de la aplicación podría implementarse en distintas ubicaciones —en la nube, en el extremo de la red o en el extremo de la red de una tienda física—, cualquier solución debe garantizar que el tráfico del usuario se dirija a la ubicación más cercana en la que esté implementado el servicio de front-end. Además, ninguna de las soluciones consideradas debería exigir a los equipos de DevOps que modifiquen las políticas de enrutamiento de Internet.
3. Equilibrado de carga global: Cualquier solución que se considere debe ofrecer equilibrado de carga global, ya que los servicios de backend podrían estar ubicados en múltiples lugares de todo el mundo.
4. Políticas uniformes de seguridad de aplicaciones y redes en varias nubes: Aunque la ubicación de los componentes de la aplicación puede variar según la región, cualquier solución que se considere debe permitir aplicar una política uniforme de seguridad de aplicaciones y redes en cualquier nube en la que se implemente el servicio de front-end.
5. Observabilidad desde un único panel para múltiples nubes y para la conectividad de aplicaciones y redes: En un entorno de nube distribuida, resulta extremadamente difícil diagnosticar problemas relacionados con las aplicaciones y la conectividad en múltiples nubes. Cualquier solución que se considere debe ofrecer observabilidad desde un único panel para la conectividad, la seguridad y los despliegues de aplicaciones en múltiples nubes.

Resultados obtenidos con las soluciones de Volterra

Configuración de la prueba

La configuración de prueba que se describe a continuación se utilizó para demostrar las mejoras de rendimiento que ofrece cada una de las soluciones de Volterra descritas en la sección anterior:

• La aplicación web utilizada fue Online Boutique, una aplicación de demostración de microservicios nativa de la nube de Google. La aplicación web consta de 11 microservicios, como se muestra en la Figura 7

Figura 7

• El rendimiento de la aplicación web se midió utilizando webpagetest.org
• La métrica utilizada para determinar el rendimiento de la aplicación web en webpagetest.org fue «Documento completo»
• La empresa es una compañía europea de comercio electrónico con centros de datos ubicados en París
• El usuario (o cliente) siempre se encuentra en San Francisco.

Escenario de prueba y resultados

Se probaron los cuatro escenarios siguientes y se describen las mejoras de rendimiento obtenidas en cada uno de ellos.

Escenario de referencia: En primer lugar, establecí como referencia el rendimiento de la aplicación web con el usuario en San Francisco y la aplicación web ejecutándose íntegramente en el centro de datos de París, tal como se muestra en la Figura 8. El rendimiento de la aplicación web en el escenario de referencia se midió en 3,5 segundos.

Figura 8

Escenario de prueba de la solución 1: En la prueba de la solución 1, el usuario sigue estando en San Francisco y la aplicación web continúa ejecutándose en el centro de datos de París; sin embargo, la sesión SSL finaliza en el proxy inverso VoltMesh que se ejecuta en Volterra ADN en San José. Este escenario se muestra en la Figura 9.

Figura 9

VoltMesh crea automáticamente una sesión SSL persistente entre el proxy inverso que se ejecuta en el PoP de San José y la aplicación web que se ejecuta en el centro de datos de París. El tiempo de respuesta de la aplicación web mejoró hasta situarse en 2,9 segundos, lo que supone una mejora de ~18 %.

Escenario de prueba de la solución 2: En la prueba de la solución 2, el front-end y el microservicio de divisas se implementan en la ADN de San José. Los demás microservicios y bases de datos siguen ejecutándose en el centro de datos de París. Este escenario se muestra en la Figura 10.

Figura 10

La razón para trasladar únicamente los microservicios de front-end y de divisas es que solo estos intervienen durante la navegación ocasional de los usuarios. El tiempo de respuesta de la aplicación web mejora hasta situarse en 2 segundos, lo que supone una mejora del 31 % con respecto a los resultados de la Solución 1.

Escenario de prueba de la solución 3: En la prueba de la solución 3, el front-end y el microservicio de divisas se desplegaron en un Intel NUC estándar (4 núcleos virtuales) ubicado en el extremo de red de una tienda física.

Figura 11

La razón para trasladar únicamente los microservicios de front-end y de divisas es que solo estos microservicios intervienen durante la navegación ocasional de los usuarios en el extremo de la tienda física. El rendimiento de la aplicación web mejora hasta los 0,8 segundos, lo que supone una mejora del 60 % con respecto a los resultados de la Solución 2.

Resumen de resultados y valor económico

En la Figura 12 se muestra un resumen de los resultados de las pruebas y del valor económico resultante. El valor económico puede determinarse extrapolando las mejoras en segundos en función del valor que cada segundo de mejora aporta a la organización. Por ejemplo, Amazon estima que cada mejora de 1 segundo genera un valor económico de 1.600 millones de dólares; por lo tanto, la solución 3 aporta un valor económico de 4.300 millones de dólares con respecto al valor de referencia.

Figura 12

Como se puede observar en estos resultados, los equipos de DevOps pueden lograr mejoras significativas de rendimiento sin tener que reescribir la aplicación mediante las tres opciones propuestas en este blog, manteniendo al mismo tiempo el mismo nivel de protección de seguridad para su aplicación. Si quieres obtener más información sobre casos de uso reales de clientes que pueden resolverse mediante una plataforma de nube distribuida, o si quieres compartir conmigo casos de uso reales de clientes, no dudes en ponerte en contacto conmigo a través de LinkedIn o Twitter.

Sobre el autor

Pranav DharwadkarVicepresidente de Productos de IA | F5

Más artículos de Pranav Dharwadkar