Ha pasado tiempo desde que me comenzara a interesar Azure más allá del ámbito de los datos. Esto me llevó a avanzar en el estudio de diferentes componentes y soluciones que me han permitido crecer y sobre todo, disfrutar de una visión mucho más general del mundo Cloud.
Sin duda, un paso importante fue el que di cuando completé el Programa de Experto Universitario en Cloud Computing de la UNIR. Pues, como ya he comentado en más de una ocasión, me permitió conectar muchas de la piezas que había ido descubriendo de un modo «autodidacta» y así completar un puzle que se antoja necesario si quieres dedicarte a la Arquitectura Cloud.
Pues bueno, llegados a este punto y sabiendo que mi agenda está algo libre (recordar que en junio terminé el Máster Universitario de Ciencia de Datos de la UOC), me he decantado por preparar la certificación Microsoft Azure Administrator (AZ-104), ya que considero que es el pilar principal sobre la que construir cualquier arquitectura que de respuesta al caso de uso empresarial.
Hasta aquí, ¡todo perfecto!
A partir de ahora es donde surgen la diferencias pues para mi, la certificación es importante, sin embargo, aprender los conceptos asegurando que pasado un tiempo sea capaz de seguir aplicando bien sus especificidades y así construir soluciones robustas es sin duda el fin deseado. Mientras que, para otras personas, la certificación es el fin y cómo llegar a conseguirla es simplemente una mera sucesión de repeticiones de los test del examen. Es decir, son especialistas en contestar rápidamente los cientos de preguntas que circulan por internet.
Expuestas las diferentes estrategias, mi primera acción ha sido buscar bibliografía de referencia para poder afrontar el path de formación con garantías y eso me ha llevado a pedir el libro oficial de la certificación. Además, echo un vistazo a Microsoft Learn 😉
Pues bien, este fin de semana he comenzado con el libro, si bien no ha sido por el principio, sino que directamente he saltado al capítulo de Networking. Me resulta apasionante entender todos esos conceptos y sobre todo descubrir lo que hace diferente una solución a otra. Esto mismo me ha sucedido con respecto al concepto Service Chaining de la topología Hub and Spoke.
Para los que no estén algo puestos en arquitecturas empresariales, comentar que la Hub and Spoke lo que busca es la optimización de recursos. Es decir, componentes como Azure Firewall, servidores DNS, Bastion, VPN Gateway, Azure Monitor u otros son desplegados en el Hub y accedidos desde las múltiples Spoke. Hasta aquí, todo genial, sin embargo si quieres conectar varias Spoke entre ellas, comienza el problema, sobre todo cuando el número de ellas es muy elevado. Esto, se debe entre otras cosas a que la posibilidad de peering no es una relación transitiva. Es decir que si tengo tres VNet A, B y C y emparejo A con B y B con C, no significa que A y C estén emparejadas, sino que debería completar dicho emparejamiento. Como puedes entender, eso complica sobre manera el proceso. Pues bien, para solucionar ese inconveniente se debe implementar el Service Chaining que no es más que habilitar el Allow Forwarded Traffic en las VNet emparejadas, configurar las User Defined Routes (Route Tables) para dirigir el tráfico entre Spokes mediante el Azure Network Appliance previamente desplegado en el Hub y estaría.
Abajo puedes observar una sencillo diagrama de la configuración del Service Chaining en Hub and Spoke.
CONCLUSIÓN
Este simple tip me ha servido para entender lo importante que es conocer en detalle las capacidades de los distintos componentes y como combinándolos nos permiten solucionar infinidad de casuísticas ayudándonos así a ser más eficientes optimizando tiempo y recursos a la hora de gobernar las arquitecturas.
Alb3rto Alonso 