¿Cuál es la mejor región de Azure para Latam?
En muchos equipos y empresas de Latam, cuando se trata de usar Azure, se suele usar la región “(US) East US 2” o “eastus2”. He visto tomar esta decisión a muchos equipos, ya sea por recomendación de un conocido, algún colega con experiencia en Azure o porque es lo que recomendaban muchas publicaciones y/o documentación. Incluso porque es una práctica que heredaron y que, con el pasar de los años, no se ha replanteado o retado.
Pero con la evolución actual de la plataforma, es decir, nuevos centros de datos en ubicaciones geográficas donde antes Azure no tenía presencia, mejora de los datacenter y mejora de la conectividad global, ¿sigue siendo “(US) East US 2” la mejor opción? ¿No existen otras alternativas?
Este artículo no busca tener la verdad absoluta a estas preguntas, pero sí busca hacer un análisis de las alternativas actuales para Latam y cuáles son los criterios de decisión que se deben tener en cuenta y que luego pueden ser cruzados con nuestra propia situación o escenario de aplicación.
¿Qué consideraciones se deben tener al momento de elegir una región?
- Latencia. No solo de usuarios, sino también entre regiones.
- Disponibilidad de servicios. No todas las regiones tienen habilitados todos los servicios; por ejemplo, dimensiones de máquinas virtuales, recursos en preview y capacidades preview no se lanzan en todas las regiones. Para esto puedes consultar “products-by-region” de Azure, una web que te ayuda con esta información.
- Regiones con zonas de disponibilidad. No todas las regiones tienen zonas de disponibilidad y algunas tienen más zonas que otras. Esto es un factor importante si diseñas para la alta disponibilidad dentro de una región. Aquí puedes consultar “azure-regions-list”.
- Pares de regiones. Hay regiones que soportan el emparejamiento con otras regiones; hay regiones que no tienen emparejamiento. Esto es un factor para el diseño de recuperación ante desastres.
- Costos y límites de cuota. Los precios de tráfico, almacenamiento, entre otros, varían entre regiones. La variación suele ser muy baja, pero es un detalle que puedes tener en cuenta. Para esto puedes consultar el clásico “Azure calculator”. Por otro lado, hay regiones que tienen límites de cuántos recursos puedes crear por tipo de recurso.
- Normatividad y cumplimiento. Cuestiones como la soberanía de datos y normas específicas a tu localidad son un factor al momento de elegir la región.
- Considera usar múltiples regiones. Los requisitos de muchas aplicaciones apuntan al uso de varias regiones, sobre todo para alta disponibilidad y recuperación ante desastres.
¿Entonces, Cuáles son las mejores opciones para Latam?
Como mencioné, no hay una respuesta absoluta y, con base en mi experiencia, me inclino al uso de múltiples regiones. De forma informativa, dejo una prueba interesante usando el popular sitio “azurespeed”. Este sitio te da un análisis de latencia, pero además te aporta con información de zonas de disponibilidad, emparejamiento, entre otros:
Como se puede apreciar, la reciente región de Chile repunta en esta prueba, pero se debe tener la consideración de que, al ser una región nueva, es muy probable que no todos los servicios estén disponibles como en otras regiones maduras como Central US, East US y East US 2, donde se puede apreciar que la diferencia de latencia es mínima, cuestión de milisegundos. Por el contrario, con la región West Europe, tiene una mayor latencia y es lo que suele suceder con regiones de ubicación europea.
Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades