Cómo elegir un proveedor de nube

Al elegir un proveedor en la nube, puede observar el reconocimiento de marca, las funciones de seguridad y almacenamiento y otros elementos. Pero los proveedores de la nube dependen de redes como el resto de nosotros, y no todos se crean o configuran de la misma manera.

En general, para quienes están considerando la nube, es importante hacer coincidir la ubicación de sus usuarios finales y la ubicación de la nube que los atenderá. También debe apuntar a un rendimiento de referencia continuo cuando comience por primera vez con un proveedor de nube, lo que lo ayudará en el futuro si hay problemas de rendimiento.

Dado que cada uno de los principales proveedores de la nube tiene varios puntos de presencia, es fundamental que considere el impacto en la red de trasladar sus datos o aplicaciones de sus oficinas a la nube. Para ilustrar este impacto, hemos creado una comparación rápida de los tres principales proveedores.

Pruebas, pruebas

Para echar un vistazo bajo las sábanas de los tres grandes proveedores, hemos realizado algunas pruebas. Configuramos un sistema de demostración de SaaS CRM en el punto de presencia noroeste (las ubicaciones exactas varían según el proveedor) para los tres proveedores de nube pública más grandes:AWS, Azure y Google Cloud. Luego, esperamos a que llegaran los resultados, y ciertamente han sido interesantes.

Pruebas desde Los Ángeles

Este gráfico a continuación muestra el tráfico de la red desde Los Ángeles hasta la ubicación más cercana de los principales proveedores en la región noroeste. Con nuestro CRM basado en el noroeste, realmente no hay un ganador distinto. Google y AWS están ubicados en la vecina Oregón, mientras que Azure está a poca distancia de ellos en el norte de California. Aquí, AWS puede simplemente ganar, pero todos muestran una variabilidad extrema en el transcurso de un mes (menos, mejor aquí). La diferencia en la distancia física no se manifiesta completamente como tiempo de red adicional para las solicitudes web (como referencia, se necesitan 40 ms para el tráfico entre países). Lo más probable es que se produzcan cambios en la ruta.

Los Ángeles → Región Noroeste | AWS | Azure | Google

Pruebas desde Atlanta

El siguiente ejemplo muestra las rutas de la red de los tres proveedores desde nuestro monitor con sede en Atlanta hasta los puntos de presencia o zonas de disponibilidad del noroeste. AWS es el proveedor de nube más lento, aunque los tres experimentan variabilidad a lo largo de la ventana de un mes. Con una separación física mucho más larga entre el usuario sintético y el servidor, podemos ignorar pequeñas variaciones en la velocidad de la red. Sin embargo, está claro que AWS sufre una latencia adicional promedio de 1,5 segundos. La causa puede variar, pero con hasta dos segundos de tiempo adicional para las solicitudes web, esto podría generar niveles más altos de frustración en el usuario. También podemos ver cierta coherencia en los picos observados, lo que indica que el tráfico puede compartir rutas y problemas de congestión diaria.

Es importante recordar que nuestra implementación con sede en Seattle probablemente no sea la opción ideal ni común para una empresa con sede en Atlanta. Pero con tantas startups que salen del área de Silicon Valley, existe una buena posibilidad de que muchas aplicaciones SaaS que usa todos los días estén haciendo este viaje de ida y vuelta de larga distancia.

Atlanta → Región Noroeste | AWS | Azure | Google

Pruebas desde Nueva York

Nuestro último ejemplo a continuación muestra el rendimiento de la red a lo largo de la ruta de la red desde la zona de Nueva York hasta nuestro CRM con base en el noroeste. AWS aún muestra los tiempos de respuesta más lentos de los tres proveedores. Google y Azure son consistentemente más rápidos, salvo por un problema de congestión observado a fines de enero. Debido a que podemos suponer que con el tiempo Internet enrutará gran parte de este tráfico de manera similar en todo el país, hay una buena indicación de que el enrutamiento detrás del firewall de AWS podría ser la causa de la latencia adicional.

Nueva York → Región Noroeste | AWS | Azure | Google

Lo que encontraron nuestras pruebas en la nube

No tenemos un tamaño de muestra grande y nuestra implementación de prueba no está personalizada para la complejidad de la mayoría de las aplicaciones modernas, pero nuestros resultados nos recordaron lo importante que es investigar la ubicación cuando planifica sus implementaciones en la nube. Obtenga el mapa para ver dónde se ubicarán sus servicios y aplicaciones cuando estén en la nube. Luego, cúbrelos con la ubicación de los usuarios de esas aplicaciones y servicios.

Hay una serie de razones que podrían contribuir a lo que parece ser una falla por parte de AWS para brindar respuestas rápidas, como acuerdos de intercambio de tráfico en el medio del país o enrutamiento adicional detrás de su firewall. Lo que está claro es que el rendimiento varía según el lugar donde se encuentren los usuarios finales. Ser consciente de este hecho conducirá a mejores decisiones en lo que respecta al rendimiento.

Probar proveedores en la nube no es nuestro único propósito, pero puede obtener la visibilidad que hicimos (y que necesita) con las herramientas de AppNeta para cualquiera de sus aplicaciones en la nube. Este tipo de conocimiento de la red puede salvar el día en que los usuarios se quejan de ralentizaciones o interrupciones y es necesario identificar la causa raíz de la degradación del rendimiento.