La lentitud es el nuevo fracaso

Hemos escuchado de nuestros clientes que "La lentitud es el nuevo camino". Tener un mal rendimiento de las aplicação es tan malo como tenerlo en cuenta la mayoría de los propietarios y operadores de aplicação modernas. FAANG Las empresas han acostumbrado a los consumidores a un rendimiento excelente y constante, y los consumidores que son clientes de otro software comienzan a tener las mismas expectativas, especialmente cuando los competidores en un mercado abarrotado ofrecen una buena experiencia de usuario.

Algunos clientes incluso nos han dicho que, a menudo, un rendimiento lento puede ser peor que una caída total del sistema. Tener algo que parezca casi funcionar y luego volver a intentarlo una y otra vez es más molesto que simplemente no funcionar. Por ejemplo, la calidad de la voz sobre IP es mala y ambas partes tienen que repetir lo que dicen una y otra vez, en comparación con su indisponibilidad, lo que provoca que las personas opten por un teléfono celular o fijo.

La importancia de satisfacer las expectativas de la experiencia del cliente se reconoce como alta en todas las industrias. Una encuesta realizada en 2020 en la industria minorista determinó que mejorar la experiencia del cliente era una prioridad digital principal para casi un tercio (32%) de los encuestados. Más del 71% citó la mejora de la experiencia del cliente como el principal resultado comercial a corto plazo que buscaban de los esfuerzos de transformación digital .

Ahora bien, es indudable que tanto los operadores como las partes interesadas comerciales se preocupan por sus usuarios. Una de las razones por las que no se aborda el bajo rendimiento es la falta de visibilidad de qué causa la lentitud o incluso qué significa "lentitud" para una aplicação como la suya. A veces, esa falta de visibilidad es el resultado directo de no haber medido nada.

Una encuesta de Turbonomic expone este fenómeno (énfasis añadido): "Cuando preguntamos a los encuestados cómo mide su organización el rendimiento de las aplicação , fue prometedor ver que más del 60 % lo mide de alguna forma. Pero el enfoque más común fue medir la disponibilidad, en lugar de gestionar los Objetivos de Nivel de Servicio (SLO), que normalmente toman la forma de tiempo de respuesta o rendimiento de transacciones. El 13% no mide en absoluto el rendimiento de las aplicação ".

Pero antes de elogiar a quienes sí miden , observemos lo que miden. El enfoque más común para medir el rendimiento fue medir la disponibilidad. La disponibilidad es una medida de arriba o abajo. No es una medida de lentitud o rapidez, aunque podríamos dedicar un blog entero (o más) a argumentar que debería serlo.

Pero no es así, y una de las razones puede encontrarse en la mensurabilidad de los costos del negocio. El impacto financiero del tiempo de inactividad está bien documentado. Podemos encontrar múltiples fuentes que proporcionan desgloses detallados de los costos en toda la organización. ¿Pero en cuanto al rendimiento? Tenemos algunas encuestas que resaltan las respuestas de los usuarios en forma de abandono o redes sociales negativas. ¿Pero cuáles son los costos reales para la empresa? Casi inexistente.

En general, podemos resumir el problema de medir el rendimiento hoy en día como "No medimos el costo de la lentitud. Medimos el coste del tiempo de inactividad." Los humanos tienden a trabajar en función de aquello que se les mide. Este no es un concepto nuevo y, de hecho, es uno de los principios de DevOps y la razón por la que la metodología incluye un cambio en las mediciones hacia lo que más importa. En F5, planeamos no sólo ayudarlo a medir en una escala absoluta, sino también en relación con los datos de las aplicações de otras personas para ver cómo sus usuarios finales experimentan sus aplicações en comparación con cómo experimentan otras aplicações similares.

Lo que más importa es cumplir con las expectativas de los usuarios finales y hoy eso significa más que sólo disponibilidad; también significa rapidez y confiabilidad. Planeamos ayudar a los propietarios de aplicação no solo con datos y visualizaciones sobre la experiencia del usuario final, sino también con información, expresada en lenguaje natural, como "Los cambios que implementó en producción durante el fin de semana mejoraron la experiencia típica del lunes por la mañana para sus usuarios finales, ¡excelente trabajo!" o "Se pronostica que su experiencia para los usuarios de Chrome en Nueva York empeorará más que el promedio para aplicações bancarias como la suya en cuatro días". Aquí está el cambio de política de equilibrio de carga que le recomendamos realizar en sus balanceadores de carga NGINX en AWS US East. Siéntase libre de hacer el cambio usted mismo o haga clic aquí para que lo hagamos por usted”.

Si desea respuestas a preguntas como:

• “¿Mis usuarios finales están teniendo una buena experiencia en general? 
• ¿Cómo es su experiencia en comparación con aplicações similares a la mía? 
• ¿Puedo exponer un indicador de salud simple para mi aplicação que incorpore una experiencia de usuario final adaptable para que mis equipos de soporte la monitoreen? 
• ¿Qué medidas puedo tomar para mejorar la experiencia del usuario final? 
• ¿Qué puedo hacer para mantener la misma experiencia de usuario final pero con costos más bajos? 
• ¿Los usuarios finales que tienen una mala experiencia se van o vuelven? 

...entonces permanezca atento a los próximos artículos donde analizaremos más en detalle.