Cómo hacer que las aplicaciones funcionen más rápido

A medida que continuamos desmantelando el centro de datos al desmantelar las aplicações y las redes de las que dependen, un aforismo empresarial sigue siendo cierto: la velocidad es el rey. El rendimiento sigue siendo una preocupación a nivel empresarial que impacta todo, desde las ventas hasta la productividad, afectando negativamente, y a veces afectando negativamente, el resultado final.

Un artículo reciente en DZone, How Fast Are Web Aplicações in 2016, profundizó en algunos aspectos específicos con respecto al rendimiento y señaló que “para una aplicação web típica, el 4,2 % de las transacciones se abandonan”. Esto se basa en “cinco mil millones de interacciones de usuarios con 500 aplicações web diferentes”.

La forma en que esto se traduce en dólares y su impacto en las ganancias o la productividad depende, por supuesto, del modelo de negocio. Podría representar millones o miles de millones de dólares, u horas perdidas y clientes enojados por el aumento de los tiempos de llamada.

De todos modos, el rendimiento sigue siendo un factor importante tanto para los desarrolladores como para las operaciones. Y por operaciones me refiero a todas las operaciones: infraestructura, red, almacenamiento y seguridad. Nuestra encuesta más reciente sobre el estado de la entrega de aplicação continuó respaldando la actitud en todos los roles de TI de que el rendimiento es fundamental. Era lo menos probable de abandonarse en favor de una mejor seguridad (solo el 9 % haría tal trato) y fue citado por el 14 % de los encuestados como un desafío importante al que se enfrentan las implementaciones de múltiples nubes.

A pesar de esto, solo el 38% indicó que emplea servicios de aceleración de aplicaciones ahora, y solo el 22% planea implementarlos el próximo año. Un sorprendente 40% dijo que no tenía planes de implementar o utilizar aceleración de aplicaciones.

Esto puede deberse a que la percepción de lo que implica la “aceleración de aplicaciones” es un tanto confusa. Y no por “la nube”, sino porque ha evolucionado y se ha transformado a lo largo de los años desde QoS a delta refresh y cachés basados ​​en navegador hasta los llamados front-end de aplicação (AFE), que en realidad son servidores proxy especializados con capacidades muy centradas en el rendimiento.

La mayoría de las veces, cuando pensamos en “aceleración de aplicaciones”, pensamos en compresión y almacenamiento en caché, minimización y optimización de imágenes. No consideramos las optimizaciones de protocolo como parte de toda la mentalidad de “Necesitamos Warp 9, Scotty” que impregna las expectativas de los usuarios y las empresas hoy en día. Pero deberíamos.

Oh, estamos viendo que la descarga de protocolos se utiliza mucho estos días. A lo largo de 2015, el uso de la descarga de SSL del lado del cliente (el lado que gestiona el HTTP seguro con los usuarios) aumentó de poco menos del 80% a casi el 100%. Esto no es sorprendente dada la creciente atención que se presta a las comunicaciones seguras con iniciativas como “Let's Encrypt!” y “SSL Everywhere”. SSL/TLS afecta el rendimiento (y no de una manera positiva), especialmente a medida que aumenta la carga. Tiene sentido delegar la carga en un proxy capaz, y estamos viendo que las organizaciones hacen justamente eso para compensar el impacto en el rendimiento que supone hacer que todo sea seguro.

Pero no estamos viendo un aumento similar en el back-end, en el lado del servidor, de la ecuación. El uso de multiplexación TCP para mejorar el rendimiento (y simultáneamente aumentar la capacidad de los recursos) no ha cambiado mucho en el último año. Casi la mitad (alrededor del 46 % de manera constante) de las organizaciones utilizan esta técnica de optimización poco reconocida.

Lo cual es alarmante si tenemos en cuenta que muchas de esas mismas organizaciones están padeciendo actualmente la fiebre de los contenedores.

¿Por qué da miedo? Déjame decirte por qué... Si bien es totalmente posible que la virtualización haya permitido a las organizaciones ajustar la pila TCP de cada instancia para garantizar el mayor rendimiento posible por aplicación, la llegada de los contenedores amenaza ese modelo. Esto se debe a que los contenedores comparten una única pila de red. El ajuste de una aplicación implementada en un contenedor no garantiza la mejor configuración para una aplicación diferente en un contenedor diferente en el mismo host .

Debido a que las optimizaciones basadas en TCP, como la multiplexación TCP, operan en la capa de protocolo, son como tejones de miel. No les importa si la aplicación está en un contenedor, en una máquina virtual o simplemente en una plataforma web. Desconectarán por completo de esa conexión y mejorarán el rendimiento independientemente de cómo o dónde se implemente la aplicación. Estos servicios solo se preocupan por el protocolo y aprovechan la separación entre el lado del cliente y el lado del servidor para garantizar que el lado del cliente esté optimizado para el cliente y el lado del servidor para la aplicación. Esto se traduce en mejoras de rendimiento multiplicadas por dos.

Los servicios y técnicas de aceleración de aplicaciones tradicionales son increíbles, no me malinterpreten, y como pueden ver en el gráfico multicolor anterior, las organizaciones los aprovechan todos para mejorar el rendimiento de sus aplicações. Pero se puede hacer más y, como indican los datos sobre el rendimiento antes mencionados, se debe hacer más de lo que se debería.

Es una buena idea mirar tu proxy (el que probablemente solo usas para equilibrar la carga) y descubrir si puede hacer más por el rendimiento de tu aplicación de lo que estás usando actualmente.

Descubra cómo F5 hace que las aplicaciones sean más rápidas, más inteligentes y más seguras.