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

Este blog es el comienzo de una nueva serie de blogs sobre ejemplos de problemas reales que enfrentan las empresas y describe cómo la red de entrega de aplicaciones (ADN) de Volterra aborda los problemas descritos. Este blog específico detalla un desafío clave en el rendimiento de las aplicação web que las empresas en línea de todo el mundo enfrentan todos los días. Este desafío se agrava aún más porque la mayoría de los consumidores trabajan desde casa. Describo cómo Volterra puede ayudar a las empresas a “desdistanciar” su aplicación web para lograr una mejora del 77 % en el rendimiento de la aplicação sin necesidad de aplicação.

¿Qué es el rendimiento de las aplicaciones web?

El rendimiento de una aplicación web generalmente se mide por el tiempo que tarda en verse el contenido de la página, tal como lo percibe 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 "Documento completo" 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 en el rendimiento de la aplicación web tiene un gran impacto en la experiencia del usuario y, en consecuencia, en las ventas a través del portal en línea. El gigante del comercio electrónico Amazon informó que una degradación de 1 segundo en el rendimiento de la aplicação resulta en una pérdida de $1.6 mil millones en ingresos. Las empresas en línea observan un impacto económico similar en múltiples sectores verticales, como lo informa Akamai en este informe un poco más antiguo . Google y Microsoft informan cifras de impacto económico similares.

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

¿Cuál es el desafío?

Tomemos un ejemplo específico de una empresa en línea en el sector del comercio electrónico. Muchas empresas de comercio electrónico tienen su aplicação web en uno o varios centros de datos y estos centros de datos no existen en todos los países donde viven los usuarios de las empresas de comercio electrónico. Cuando el usuario se encuentra en un país o región diferente al del centro de datos, la alta latencia de la red entre el usuario y el centro de datos genera tiempos de carga de página lentos de casi 6 a 12 segundos. Como se mencionó anteriormente, cuando los tiempos de carga de la página superan los 5 segundos, la probabilidad de rebote aumenta al 90%.

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

• En primer lugar, se establece una sesión SSL segura, que requiere 6 mensajes de ida y vuelta entre el navegador del usuario y la aplicación web.
• A continuación, la aplicación web normalmente utilizará las cookies en el navegador del usuario para determinar si el usuario tiene una cuenta con el proveedor de comercio electrónico.
• Basado en 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 de pago como invitado.

Seis mensajes solo para configurar la sesión SSL segura cuando se transmiten a través de enlaces de alta latencia (potencialmente enlaces transatlánticos/transpacíficos) seguramente afectan los tiempos de carga de la página y, en consecuencia, dan como resultado una mala experiencia del usuario.

¿Cómo puede Volterra ADN mejorar el rendimiento de la aplicación?

Existen muchas técnicas para mejorar el rendimiento de las aplicaciones web aplicação, como comprimir las imágenes u optimizar las dependencias para reducir los tiempos de carga de la página. Muchas veces, estas optimizaciones podrían no ser posibles debido a los requisitos comerciales que impulsan el diseño de la aplicação . Incluso si estas optimizaciones son posibles, podría no ser una opción viable porque los desarrolladores que escribieron la aplicación ya no están en la organización o están ocupados desarrollando nuevos servicios. Por lo tanto, los equipos de DevOps en las organizaciones de comercio electrónico valoran las soluciones que pueden mejorar el rendimiento de la aplicación pero que no requieren cambios en la aplicação.

Volterra ofrece dos productos, VoltMesh y VoltStack, que combinados con el ADN de Volterra, pueden mejorar el rendimiento de la aplicação hasta en un 75% (vea la demostración en la siguiente sección). El producto VoltMesh de Volterra es un producto de seguridad y red distribuido globalmente que, cuando se configura en el ADN de Volterra, también proporciona capacidades de aceleración de aplicação . El producto VoltStack de Volterra proporciona implementación distribuida de aplicação y gestión del ciclo de vida, lo que permite a los usuarios descargar partes de sus aplicações al ADN de Volterra para mejorar aún más el rendimiento de las aplicação .

VoltMesh y VoltStack abordan el rendimiento de las aplicação web de las empresas de comercio electrónico de las siguientes tres maneras

Solución 1: Terminación SSL (también conocida como Descarga de TLS) en Volterra ADN

La solución más sencilla para mejorar el rendimiento de la aplicación web es realizar la finalización de la sesión SSL en el ADN global de Volterra. El conjunto de seis mensajes para configurar la sesión SSL se envía localmente al borde de la red global del país y no atraviesa enlaces transatlánticos o transpacíficos. Habrá una sesión SSL persistente entre el sitio de red global remoto 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.

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

Para mejorar aún más el rendimiento, las empresas pueden implementar partes de sus aplicaciones sensibles a la latencia en el ADN. Algunos ejemplos de partes de la aplicación web sensibles a la latencia incluyen el procesamiento de cookies, GraphQL o back-end para front-end. En un ejemplo de una empresa de comercio electrónico, normalmente procesan cookies para determinar qué página mostrar al usuario, p. ej., si el usuario tiene una cuenta, mostrar la página de inicio de sesión; de lo contrario, mostrar una página de invitado. El procesamiento de cookies en nuestro ADN mejora el rendimiento drásticamente en comparación con el procesamiento de cookies 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.

Solución 3: Trasladar la interfaz de la aplicación web (por ejemplo, el catálogo de productos) al borde, es decir, a la tienda física.

Muchos vendedores comerciales como Macy’s, Home Depot y Target también tienen tiendas físicas donde los consumidores exploran el catálogo de productos en línea, dentro de la tienda física, para verificar la ubicación de los artículos y acceder a ofertas/cupones. Para mejorar la experiencia del usuario, podrían optar por trasladar solo la parte frontal de su aplicación web al procesamiento en la tienda. Todos los componentes restantes de su aplicación, es decir, las bases de datos, podrían permanecer en el centro de datos back-end, ya que no se accederá a ellos con tanta frecuencia como al catálogo de productos front-end. Esto se puede visualizar como se muestra en la Figura 5.

Principios arquitectónicos clave a tener en cuenta en cualquier solución

Este problema es fundamentalmente un problema de computación distribuida en múltiples nubes heterogéneas. Los equipos de DevOps podrían optar por hacerlo ellos mismos, combinando soluciones fragmentadas de distintos proveedores, como proveedores de nube pública, proveedores de CDN o proveedores de borde, o comprar una solución empaquetada de proveedores de plataformas de servicios de nube distribuida. Los desafíos se destacan en la 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 aplicação consistente en múltiples nubes: Las aplicação de los equipos de DevOps se distribuirán entre su nube backend, que podría ser un centro de datos privados o una nube pública, y su ubicación de borde y la ubicación de la tienda física, todos los cuales podrían ser entornos de ejecución de aplicação completamente diferentes. Los equipos de DevOps deberían considerar seriamente soluciones que aprovechen Kubernetes para proporcionar un entorno de ejecución de aplicação consistente en todas estas nubes distribuidas. Kubernetes homogeneiza las nubes y facilita el traslado de partes de las aplicações entre ellas.
2. Enrutamiento de tráfico por geoproximidad: Como el frontend de la aplicação se puede implementar en diferentes ubicaciones (en la nube, en el borde o en el borde de la tienda física), cada solución debe garantizar que el tráfico del usuario se desvíe a la ubicación más cercana donde se implementa el servicio frontend. Y cualquier solución considerada no debería requerir que los equipos de DevOps cambien las políticas de enrutamiento de Internet.
3. Equilibrio de carga global: Cualquier solución considerada debe ofrecer equilibrio de carga global, ya que los servicios de backend podrían estar en múltiples ubicaciones alrededor del mundo.
4. Políticas uniformes de seguridad de aplicação y redes en múltiples nubes: Si bien la ubicación de los componentes de la aplicação puede variar según la región, cualquier solución considerada debe brindar la capacidad de aplicar una política de seguridad de red y aplicação uniforme en cualquier nube en la que se implemente el servicio front-end.
5. Observación desde un único panel en múltiples nubes y en toda la conectividad de aplicação y redes: En un entorno de nube distribuida es extremadamente difícil solucionar problemas entre aplicações y conectividad en múltiples nubes. Cualquier solución considerada debe proporcionar un panel único de observación que permita observar la conectividad, la seguridad y las implementaciones de aplicação en múltiples nubes.

Resultados obtenidos con las soluciones de Volterra

Configuración de 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 Volterra descritas en la sección anterior: 

• La aplicación web utilizada fue Online Boutique , una aplicação 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

• 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 empresa 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 siguientes cuatro escenarios y se describen las mejoras de rendimiento para cada escenario.

Escenario base: En primer lugar, establezco una línea de base del rendimiento de la aplicación web con el usuario en San Francisco y la aplicación web ejecutándose completamente en el centro de datos de París, como se muestra en la Figura 8. El rendimiento de la aplicación web para el escenario de referencia se midió en 3,5 segundos.

Solución 1 Escenario de prueba: En la prueba de la solución 1, el usuario todavía está en San Francisco, la aplicación web todavía se está ejecutando en el centro de datos de París, sin embargo, la sesión SSL se finaliza en el proxy inverso VoltMesh que se ejecuta en Volterra ADN en San José. Este escenario se muestra en la 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 rendimiento de la aplicación web mejoró a 2,9 segundos , una mejora de ~18% .

Escenario de prueba de la solución 2: En la prueba de la solución 2, el microservicio front-end y de moneda se implementan en el ADN en San José. Los microservicios y bases de datos restantes todavía funcionan en el centro de datos de París. Este escenario se muestra en la Figura 10.

La razón detrás de mover únicamente los microservicios front-end y monetarios es que solo estos microservicios están involucrados durante la actividad de navegación casual de los usuarios. El rendimiento de la aplicación web mejora a 2 segundos , una mejora del 31% 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 microservicio front-end y monetario se implementaron en un Intel NUC básico (4 núcleos virtuales) en el borde de una tienda física.

La razón detrás de mover únicamente los microservicios front-end y monetarios es que solo estos microservicios están involucrados durante la actividad de navegación casual de los usuarios en el borde de la tienda física. El rendimiento de la aplicación web mejora a 0,8 segundos , una mejora del 60% 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 el consiguiente valor económico. El valor económico se puede determinar extrapolando las mejoras en segundos con el valor de cada segundo de mejora para la organización. Por ejemplo, Amazon valora cada mejora de los resultados de 1 segundo en un valor económico de $1.6 mil millones; por lo tanto, la solución 3 proporciona un valor económico de $4.3 mil millones por encima de la línea base.

Como se puede ver en estos resultados, los equipos de DevOps pueden lograr mejoras de rendimiento significativas sin reescribir la aplicação utilizando las tres opciones propuestas en este blog y manteniendo el mismo nivel de protección de seguridad para su aplicação. Para obtener más información sobre casos de uso de clientes reales que se pueden resolver mediante una plataforma de nube distribuida o si tiene casos de uso de clientes reales para compartir conmigo, no dude en comunicarse conmigo a través de LinkedIn o Twitter .