Git Visual Studio
Cómo configurar un repositorio Git en Visual Studio
4 enero, 2018
HoloLens
Realidad Mixta e Inteligencia Artificial, la Revolución 3D: Reloaded
15 enero, 2018

A los que hacemos uso habitual de los servicios de Azure u ofrecemos servicios gestionados de Azure, nos puede haber surgido la siguiente pregunta: ¿Deberíamos seguir utilizando el modo clásico o, por el contrario, usar el nuevo Azure Resource Manager (ARM)?
 

Historia de los modelos de implementación de Azure

Los que hicimos uso de Azure durante sus primeros pasos no tuvimos que realizar esta elección inicial entre modelos, ya que Azure sólo proporcionaba el modelo de implementación clásico. Para implementar una solución, era necesario crear cada recurso individualmente mediante el portal clásico, o crear un script que implementara todos los recursos en el orden correcto. Para eliminar una solución, se tenía que eliminar cada recurso de forma individual. Era inevitable realizar un seguimiento manual de los recursos que componían la solución y administrarlos de manera coordinada.

En el año 2014, Microsoft presentó Azure Resource Manager, que incorporaba el concepto de grupo de recursos. Un grupo de recursos es un contenedor para los recursos que comparten un ciclo de vida común. Al incorporarse el Azure Resource Manager, todos los recursos se agregaron retroactivamente a los grupos de recursos predeterminados. Si ahora se crea un recurso a través de la implementación clásica, el recurso se crea automáticamente dentro de un grupo de recursos predeterminado para el servicio, aunque no se especifique dicho grupo de recursos durante la implementación. Sin embargo, sólo el hecho de existir dentro de un grupo de recursos no significa que el recurso se haya convertido al modelo Resource Manager.
 

Características de la implementación clásica

Conocido coloquialmente como modelo de implementación clásico, técnicamente este modelo es llamado modelo de administración de servicios (Azure Service Management).

Azure Service Management (ASM) es una API REST en XML que agrega cierta sobrecarga a las llamadas API en comparación con JSON. La API de ASM cubre la mayoría de las características de Azure, mientras que algunas funciones sólo están disponibles a través de la API REST de Azure Resource Manager (ARM), de la que se hablará más adelante.

Este modelo proporciona el servicio en la nube para las cargas de trabajo de IaaS y algunas cargas de trabajo de PaaS específicas.

El término “servicio en la nube” es un término ambiguo. “Cloud Service” en Azure es una oferta de PaaS que permite alojar aplicaciones escalables y de alta disponibilidad. Sin embargo, la Virtual Machine (IaaS) desplegada en ASM debe estar dentro de un contenedor virtual llamado Cloud Service. Por lo tanto, uno puede tener varias máquinas virtuales dentro de un único contenedor llamado Cloud Service. Junto con esta ambigüedad, hay una serie de terminologías que es importante conocer para comprender la arquitectura subyacente.

Un servicio de nube típico en el modelo clásico se compone de Web Role y de Worker Role. Simplificándolo, un web role no es más que una máquina virtual con un IIS instalado y habilitado, mientras que un worker role es una máquina virtual con la función IIS no instalada. Se puede acceder al servicio en la nube desde Internet utilizando una IP virtual (VIP), que será una IP pública asignada al servicio en la nube. La URL predeterminada para cualquier servicio en la nube implementado en ASM será de la siguiente forma: <NOMBRE>.cloudapp.net.

El Cloud Service (PaaS) puede ser representado como se muestra a continuación:

Ilustración 1: Modelo clásico – Web Role y Worker Role

 

Grupos de recursos en el modelo de implementación Resource Manager

Un grupo de recursos podría definirse como un contenedor que almacena los recursos relacionados con una solución de Azure. El grupo de recursos puede incluir todos los recursos de la solución o sólo aquellos que se desean administrar como grupo. Para decidir cómo asignar los recursos a los grupos de recursos, hay que tener en cuenta lo que sea más conveniente para cada caso individual.

Hay algunos factores importantes que se deben tener en cuenta al definir el grupo de recursos:

  • Todos los recursos del grupo deben compartir el mismo ciclo de vida. Se implementan, actualizan y eliminan de forma conjunta. Si un recurso (por ejemplo, un servidor de base de datos) debe existir en un ciclo de implementación diferente, éste debe estar en otro grupo de recursos.
  • Cada recurso sólo puede existir en un grupo de recursos.
  • Se puede agregar o quitar un recurso de un grupo de recursos en cualquier momento.
  • Se puede mover un recurso de un grupo de recursos a otro.
  • Un grupo de recursos puede contener recursos que residen en diferentes regiones.
  • Un grupo de recursos puede utilizarse para definir el ámbito de control de acceso para las acciones administrativas.
  • Un recurso puede interactuar con los recursos de otros grupos. Esta interacción es común cuando ambos recursos están relacionados pero no comparten el mismo ciclo de vida (por ejemplo, aplicaciones web que se conectan a una base de datos).

Al crear un grupo de recursos, es preciso proporcionar una ubicación para dicho grupo de recursos. Ahora bien, ¿por qué necesita un grupo de recursos una ubicación? Si los recursos pueden tener ubicaciones distintas a las del grupo de recursos, ¿por qué es importante la ubicación de éste? Los grupos de recursos almacenan metadatos acerca de los recursos. Por lo tanto, al especificar la ubicación del grupo de recursos, se especifica el lugar en que se almacenan dichos metadatos. Por motivos de compatibilidad, es posible que los datos deban almacenarse en una región concreta.
 

Ventajas del modelo de implementación Resource Manager

En este artículo se abordan tanto el modelo de implementación de Azure Resource Manager como el modelo de implementación clásico. Ambos modelos representan dos formas diferentes de implementar y administrar las soluciones de Azure.

Se va a trabajar con ellos a través de dos conjuntos de API distintos, y los recursos implementados pueden contener diferencias importantes. Cabe señalar que los dos modelos no son totalmente compatibles entre sí. Para simplificar la implementación y administración de recursos, Microsoft recomienda que se utilice Resource Manager para los nuevos recursos.

El modelo de implementación de Resource Manager permite lo siguiente:

  • Implementar la solución repetidamente a lo largo del ciclo de vida y tener la seguridad de que los recursos se implementan de forma coherente.
  • Implementar, administrar y supervisar todos los servicios para su solución como grupo, en lugar de controlar estos servicios individualmente.
  • Aplicar control de acceso a todos los recursos del grupo de recursos; las directivas se aplican automáticamente cuando se agregan nuevos recursos al grupo de recursos.
  • Aplicar etiquetas a los recursos para organizar de manera lógica todos los recursos de la suscripción.
  • Hacer uso de la notación de objetos JavaScript (JSON) para definir la infraestructura de la solución. Al archivo JSON se le conoce como una plantilla de Resource Manager. Esta plantilla se puede utilizar para implementar los recursos de manera repetida y uniforme.
  • Definir las dependencias entre recursos, de modo que se implementen en el orden correcto.

 

Compatibilidad de los modelos

A la hora de utilizar y crear servicios en Azure, debemos plantearnos tres escenarios posibles:

  • El servicio admite Resource Manager y proporciona un solo tipo. Si el servicio admite Resource Manager y no es una máquina virtual, cuenta de almacenamiento o red virtual, puede usar Resource Manager sin mayores problemas.
  • El servicio no admite Resource Manager. En este caso, tendremos que continuar haciendo uso de la implementación clásica.
  • El servicio admite Resource Manager, pero proporciona dos tipos, uno para Resource Manager y otro para el modelo clásico. Este escenario se aplica sólo a las máquinas virtuales, las cuentas de almacenamiento y las redes virtuales.

En el caso de una máquina virtual, cuenta de almacenamiento o red virtual, si el recurso se creó mediante la implementación clásica, debe continuar trabajando mediante las operaciones clásicas. Si la máquina virtual, la cuenta de almacenamiento o la red virtual se creó haciendo uso de la implementación de Resource Manager, debe continuar usando operaciones de Resource Manager. Esta distinción puede resultar confusa cuando la suscripción contiene una combinación de los recursos creados mediante Resource Manager y la implementación clásica; esta combinación de recursos puede crear resultados inesperados al no ser los recursos compatibles con las mismas operaciones.
 

Portal clásico y Portal nuevo

Ambos portales -clásico y nuevo- están en uso a día de hoy:

  • Portal clásico de Azure. Se usa hoy en día para crear y configurar recursos de Azure más antiguos que admiten el modelo de implementación clásico. No puede usarse para crear o configurar recursos que sólo sean compatibles con Resource Manager. Puede accederse a este portal a través de https://manage.windowsazure.com.
  • Nuevo portal de Azure. Se puede usar para crear y configurar algunos recursos de Azure. Con el tiempo, se podrán crear y configurar todos los recursos de Azure. Para algunos recursos que admiten ambos modelos de implementación, este portal puede ser utilizado para crear y configurar un recurso usando cualquiera de los modelos de implementación. Puede accederse a este portal a través de https://portal.azure.com/.

Ilustración 2: Portal clasico de Azure vs. Portal nuevo de Azure

 

¿Qué modelo de implementación utilizar?

Aunque Microsoft se posicione a favor de su uso, en mi opinión no hay que dar por hecho que ARM (Azure Resource Manager) sea la mejor opción, ya que simplemente puede no satisfacer todas nuestras necesidades.

Bajo mi punto de vista, si estáis buscando una experiencia más confiable y utilizar una API que se haya aprovechado de una base de clientes más grande, es probable que deséeis seguir con la API de Azure Service Management (ASM), es decir, con el modelo clásico. En cambio, si analizáis y modeláis vuestra solución con anticipación, estáis abiertos a experimentar problemas de usabilidad y disponéis de una curva de aprendizaje pronunciada, lo más probable es que os decantéis por hacer uso de Azure Resource Manager (ARM).

En ocasiones, por experiencia propia, se ha de ir a ambos portales para crear un conjunto de recursos y servicios en Azure. Sin embargo, el nuevo portal se está posicionando como el único portal para crear y administrar servicios en ambos mundos. Desafortunadamente, algunas funcionalidades sólo se pueden hallar en el portal clásico, aunque lo cierto es que estas funcionalidades exclusivas del portal clásico se encuentran actualmente en proceso de migración al nuevo portal, por lo que cabe esperar que dentro de no mucho estarán disponibles en el mismo.

Por otra parte, se debe tener presente que la API del modelo clásico (ASM) se eliminará progresivamente. En algún momento, se terminarán migrando sus recursos aprovisionados en ASM a la API de Azure Resource Manager (ARM), y es que el ritmo de las funciones y actualizaciones recientemente implementadas en ARM es difícil de seguir. Hoy por hoy, Microsoft está creando herramientas para ayudar con este proceso de migración en la nube.

 

 

Podéis comentarnos lo que sea en info@kabel.es.

También podéis seguirnos en Twitter, LinkedIn y Facebook.

 

proudtobegeek


 

Licencia de Creative Commons
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 4.0 Internacional.

 

Compártelo: Share on FacebookTweet about this on TwitterShare on LinkedInPin on Pinterest

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

NEWSLETTER