[Articulo] Microsoft Azure | Modelos de Despliegue en Azure: Resource Manager y Service Management hoy en dia

Microsoft Azure, hoy en día, presenta dos modelos posibles de despliegue de recursos y servicios: el clásico conocido como “Service Management”, y el moderno conocido como “Resource Manager”.

En esta publicación vamos a hacer una completa recorrida sobre las características de ambos modelos y cuál es la recomendación al momento de elegir cuál utilizar en nuestras implementaciones.

Esperamos que la publicación les sea de interés y ayuda. Enjoy!

IMPORTANTE: Hemos realizado revisiones y actualizado esta publicación desde lo técnico, que originalmente fue publicada el 25/06/2016. ¡Gracias por todo el soporte!

[toc]

Introducción

Objetivo y Alcance

Esta publicación tiene como objetivo demostrar cuál es la diferencia entre los modelos de implementación existentes hoy en Microsoft Azure: el Modelo del Administrador de Recursos (conocido como Resource Manager Deployment Model) y Modelo de Servicio (Service Management Model), en pos que los Administradores de Servicio y Profesionales puedan tomar mejores decisiones al momento de realizar una implementación.

En realización al alcance de esta publicación, vamos a hacer una recorrida en alto nivel técnico sobre Resource Manager Deployment Model y Service Deployment Model, demostrando pros y contras de cada uno de estos modelos y sus niveles de compatibilidad.

Audiencia

Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en leer e investigar sobre la tecnología alcanzada por esta publicación.

Comentarios y Corrección de Errores

Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.

Desarrollo

Introducción a los Modelos de Implementación [Deployment Models]

Durante el evento “Build” del año 2014, Microsoft anunció la disponibilidad de un nuevo Azure Portal y la disponibilidad del nuevo modelo de administración en Azure conocido como Azure Resource Manager. Hoy en día, estos modelos y portal son moneda corriente en la vida de cualquier profesional IT que utilice la plataforma.

No obstante, durante algunos años los Administradores de Azure (nosotros) hemos usado el portal clásico y nos hemos acostumbrado a él, inclusive negándonos a utilizar el nuevo portal. Esto lo vi reflejado, en persona, por ejemplo en un MVP Summit del año 2016 donde León Welicki (PM del Portal de Azure) inició su charla con bromas al respecto: ¿cuántos portales vamos a tener en total para Azure?

Hoy los tiempos han cambiado, y el portal clásico de Azure casi es inaccesible. El excelente trabajo que ha realizado el grupo de producto encargado del tema y los avances en funcionalidades e integraciones han desplazado en forma completa el portal legacy.

El objetivo de esta publicación es, entonces, hacer un poco de historia y ayudar a integrar conceptos entre ambos modelos e identificar por qué es una ventaja utilizar Azure Resource Manager sobre el modelo clásico de despliegue y qué pasará con aquellas cargas de trabajo (fundamentalmente Cloud Services) que hoy aún estén activas.

Qué es el “Service Management Model” (Classic)

El modelo clásico de implementación lo encontraremos con el nombre de “Classic Model“, “Classic” o “Service Management Model“. Este modelo es el que utilizaron históricamente los desarrolladores y profesionales de IT a través del “viejo portal” para aprovisionar recursos de Azure. Hoy en día, desde el “nuevo portal” (que es el único vigente desde el 8 de Enero de 2018) se pueden seguir operando recursos desde este modelo e, inclusive, seguir aprovisionando otros. Esto es debido a retrocompatibilidad y que hoy en día siguen existiendo varias aplicaciones basadas en “Cloud Services” que necesitan seguir operando.

El “viejo portal” al que hacemos referencia: ¿lo has operado? Aquí tenemos una foto:

Este modelo clásico está basado en un grupo de APIs que, como dijimos, incluso hoy en día siguen siendo soportadas si bien no significa que dichas APIs soporten nuevas funcionalidades. Microsoft es claro sobre su soportabilidad: las nuevas funcionalidades y servicios NO SOPORTARÁN este modelo. No obstante, este modelo sigue activo.

Qué es el “Resource Manager Deployment Deployment Model” (ARM)

Este es el “nuevo modelo” de despliegue para recursos de Azure que está presente desde mediados del año 2014. Los nuevos recursos y servicios que se publicaron desde ese momento en Azure lo soportaron, y los existentes se fueron actualizándose (algunos automáticamente y otros requerirán migración) al nuevo modelo. Un ejemplo de la necesidad de “migración manual” fueron las máquinas virtuales, redes y almacenamiento (estos últimos en algunos servicios).

En ARM los recursos de Microsoft Azure pueden agruparse y tener interrelaciones entre si, permitiendo por ejemplo generar plantillas para reutilizar una implementación donde se integren: servicios PaaS y IaaS. Además de esto, y en lo referente al Cómputo, Almacenamiento y Redes, la estructura lógica ha tenido cambios y mejoras importantes.

Todas las nuevas funcionalidades de la plataforma han sido entregadas bajo este modelo de despliegue y no fueron soportadas en el modelo “clásico” salvo excepciones puntuales.

Transición de la Plataforma hacia Resource Manager

Microsoft Azure, desde hace fines de 2014, sufrió una transformación del modelo clásico al modelo basado en recursos. Este cambio da respuesta a necesidades tecnológicas y de mercado, mostrando una evolución de la plataforma considerable.

En la actualidad, estando en Octubre de 2018, muchos servicios ofrecidos desde Azure ya han sido migrados automáticamente hacia este nuevo modelo, sin necesidad que el usuario realice cambios. No obstante, hay otros servicios que se han descontinuado (si bien el usuario los puede seguir consumiendo) e incluso hay algunos que no se migrarán al nuevo modelo, salvo intervención explícita y una migración de datos manual.

En el caso de los servicios de Cómputo, Redes y Almacenamiento, la transformación es manual y la debe realizar el cliente con el costo de tener interrupciones en los servicios brindados. Existen otros casos en donde los servicios solo son ofrecidos mediante el nuevo modelo de implementación.

No obstante a todo lo dicho, hoy en día cualquier proyecto basado en Azure debería estar soportado sobre ARM sin excepciones. Esto, hace algunos años, era un punto a considerar importante debido a que no todo estaba soportado bajo dicho modelo.

Características del “Service Management Model”

Vamos a separar el análisis en dos: conoceremos las características generales y luego las características específicas para Cómputo, Almacenamiento y Redes.

Características Generales

En el modelo Clásico los recursos creados se deben administrar por separado, en comparación con el modelo basado en recursos donde los mismos pueden ser administrados y tratados como grupo.

Lo comentado anteriormente tiene diversas implicancias en nuestras implementaciones:

• No se pueden especificar relaciones entre los recursos ni orden de despliegue.
• No se pueden crear plantillas de despliegue de aplicaciones que requieran más de un servicio.
• No existe la posibilidad de aplicar Role-Based Access Control (RBAC) para el servicio ni sus elementos.
• Se pueden administrar los servicios desplegados en este modelo desde el portal clásico (https://manage.windowsazure.com/) y desde el nuevo portal (https://portal.azure.com/).

La mayoría de los servicios, siempre y cuando no sean de Cómputo, Almacenamiento y Redes, son migrados al nuevo método de despliegue automáticamente (ARM) sin necesidad de intervención del usuario.

Características para Cómputo, Almacenamiento y Redes

En lo referido puntualmente al cómputo, almacenamiento y redes para alojar máquinas virtuales, en el modelo clásico son provistas por:

• Un servicio en la nube [Cloud Service] que actúa como contenedor para alojar las máquinas virtuales. Las máquinas virtuales son provistas con una red (NIC – Network Interface Card) y una IP asginada por Azure. Adicionalmente, este servicio en la nube [Cloud Service] contiene un balanceador externo [External Load Balancer], una IP pública [Public IP] y puntos de acceso configurables [EndPoints] implícitos. En este sentido, y para pasar en limpio el concepto, los equipos virtuales al pertenecer a un servicio en la nube se balancean naturalmente.
• Una cuenta de almacenamiento [Storage Account] que aloja los VHDs para la máquina virtual, incluidos el disco del sistema operativo, disco temporario y otros adicionales.
• Una red virtual opcional [Virtual Network] que actúa como un contenedor adicional donde se puede crear una estructura de subredes.

Hay que tener en cuenta que, mientras los servicios que no sean de Cómputo, Almacenamiento y Redes son migrados al nuevo método de despliegue automáticamente (ARM), el Cómputo, Almacenamiento y Redes no. Para poder pasar al modelo basado en recursos (Resource Manager) se debe realizar una migración manual de los mismos.

Características del “Resource Manager Deployment”

Al igual que lo hicimos para el modelo Clásico, vamos a separar el análisis en dos: conoceremos las características generales y luego las características específicas para Cómputo, Almacenamiento y Redes.

Características Generales

En el modelo basado en recursos, los mismos pueden ser administrados y tratados como grupo. En base a esto, tenemos las siguientes características generales comparativamente con el modelo clásico:

• Podemos desplegar, administrar y monitorear todos los Servicios como un grupo.
• La implementación repetida de una aplicación en forma consistente.
• Podemos utilizar plantillas declarativas para definir una implementación.
• Podemos identificar dependencias entre recursos que se despliegan para indicar un orden.
• Se puede utilizar Role-Based Access Control (RBAC).

Como hemos comentado anteriormente, la mayoría de los servicios, siempre y cuando no sean de Cómputo, Almacenamiento y Redes, son migrados al nuevo método de despliegue automáticamente (ARM) sin necesidad de intervención del usuario.

En este nuevo modelo tenemos algunos conceptos que vale la pena aclarar para que todos hablemos el mismo idioma. Estos son: Recursos, Grupo de Recursos, Proveedores de Recursos, Plantillas de Recursos y Etiquetas.

Recursos [Resources]

Un recurso en ARM, es algo que se aprovisiona en una suscripción de Azure y está asociado a un grupo de recursos. Por ejemplo: una base de datos SQL, un Web App, una Cuenta de Almacenamiento, una Máquina Virtual, etc.

Grupo de Recursos [Resource Groups]

Un grupo de recursos (resource group) es una agrupación lógica de recursos que soportan una aplicación o carga de trabajo en particular. Por ejemplo, si en nuestra infraestructura tenemos una aplicación de línea de negocios (line-of-business app – LOB) que está compuesta por un Web App, una Cuenta de Almacenamiento y una Base de Datos SQL, podemos agrupar todos estos recursos en un Grupo de Recursos. Lo mismo si tenemos una infraestructura 100% IaaS, compusta por dos máquinas virtuales, una Cuenta de Almacenamiento, una Base de Datos SQL y otra MySQL:

Normalmente, los recursos que forman parte de un mismo grupo de recursos tienen el mismo ciclo de vida de administración. Vamos a poner como ejemplo la misma aplicación de línea de negocios anterior, pero supongamos que los desarrolladores administran el Web App y la Cuenta de Almacenamiento, pero la base de datos es administrada por un equipo distinto. En dicho caso, podemos pensar en dos grupos de recursos:

Proveedores de Recursos [Resource Providers]

Los recursos en un grupo de recursos son creados y administrados por proveedores de recursos Cada recurso tiene un proveedor que conoce cómo administrarlo y configurarlo. Desde el punto de vista de la arquitectura, este es un gran cambio en Azure.

Plantillas de Despliegue [Deployment Templates]

Con la administración basada en recursos, se pueden crear plantillas en formato JSON que definen cómo será la implementación y configuración final de una aplicación. Esta plantilla es una via declarativa para definir un despliegue, permitiendo hacer repetidamente y sin diferencias una implementación dejando los recursos que la componen en un estado consistente.

Dentro de la plantilla, se definen varios aspectos, a saber:

• Infraestructura de la aplicación.
• Cómo configurar esa infraestructura.
• Cómo publicar la aplicación y código para esa infraestructura.

No hay que preocuparse por el orden para la implementación, dado que ARM analiza las dependencias y asegura que los recursos son creados en el orden correcto. Ahora bien, sí debemos ocuparnos de las dependencias internas de la infra, propias de la lógica de la aplicación.

También podemos usar las plantillas para actualizar una aplicación. Por ejemplo, cuando necesitamos agregar nuevos recursos a la misma.

Etiquetas [Tags]

ARM permite agregar etiquetas para categorizar recursos en base a los requerimientos para su administración y facturación. Por ejemplo, podemos utilizar etiquetas cuando tenemos una colección de grupos de recursos y recursos compleja, y necesitamos visualizar esos recursos de modo tal que tenga más sentido lógico para quién lo ve.

Características para Cómputo, Almacenamiento y Redes

En lo referido puntualmente al cómputo, almacenamiento y redes para alojar máquinas virtuales, el modelo conocido como “Resource Manager” está organizado por componentes y es ofrecido a través de una serie de proveedores de recursos:

• Storage Resource Provider (SRP).
• Compute Resource Provider (CRP).
• Network Resource Provider (NRP).

El objetivo de esta división de componentes es brindar mayor flexibilidad para construir configuraciones más complejas y automatizar su configuración. Existen relaciones entre dichos componentes y los recursos, a saber:

• Una máquina virtual depende de una cuenta de almacenamiento específicada en el SRP para almacenar sus discos (esto es obligatorio).
• Una máquina virtual referencia a una interfaz de red (NIC) definida en el NRP (esto es obligatorio) y un conjunto de disponibilidad definido en el NRP (esto es opcional).
• Una interfaz de red (NIC) referencia a la dirección IP asignada a la máquina (esto es obligatorio), la subred de la red virtual asignada a la máquina virtual (esto es obligatorio) y a un grupo de seguridad de red (esto es opcional).
• Una instancia del balanceador hace referencia a un grupo de direcciones IP de backend que incluye la interfaz de red de una máquina virtual (esto es opcional) y referencia a la dirección IP pública o privada (esto es opcional).

Compatibilidad entre los Modelos

Hoy en día son MUY limitados los servicios que funcionan en ASM (modelo clásico). Muchos de ellos, aunque se hayan creado en el “viejo portal” y bajo el clásico modelo de implementación, son totalmente compatibles con el Administrador de Recursos [Resource Manager] y permiten realizar la transición nuevo modelo sin ningún esfuerzo adicional.

No obstante, algunos proveedores de recursos ofrecen dos versiones del recurso (una para el modelo clásico y otra para el Administrador de Recursos) debido a las diferencias de arquitectura de ellos. Los proveedores de recursos que distinguen entre los dos modelos son:

• Cómputo.
• Almacenamiento.
• Red.

Para este tipo de recursos se debe tener cuidado sobre qué versión elegir dado que pueden diferir las funcionalidades y la transición entre el modelo Clásico [Classic] y el modelo de Administrador de Recursos [Resource Manager] requiere esfuerzo y reconfiguraciones.

¿Qué modelo elegir para mis implementaciones?

Sin lugar a dudas, esta es la primera pregunta que nos podemos hacer o que un cliente puede hacernos. La respuesta es simple: la recomendación es ir por ARM ya desde hace un tiempo. Todos los nuevos servicios tendrán solo soporta a través de ARM, y solo algunos retrocompatibles podrán administrarse y crearse bajo el modelo clásico. Es por esta razón que la recomendación es ir por el nuevo modelo, y no por el clásico.

¿Qué hago si tengo implementaciones en Cloud Services, por ejemplo?

Hoy en día aún podrían existir servicios basados en los viejos “Cloud Services”. En dicho caso, se debe poner foco en el planeamiento (relevamiento y diseño) de nuevas soluciones. Una alternativa a tener en cuenta es, por ejemplo, migrar hacia Virtual Machine Scale Sets, que es un servicio MUY similar a los viejos ofrecidos por Cloud Services, pero con todo el poder de ARM.

Conclusiones

Azure Resource Manager (ARM) representa un cambio de arquitectura muy grande en Azure, que nos agregó grandes funcionalidades y posibilidades a nuestros despliegues comparado con el modelo clásico. Hoy en día ya es una moneda corriente.

En esta publicación hemos recorrido los puntos más importantes de ambos modelos, y hemos hecho el mayor esfuerzo por identificar diferencias y alternativas a elegir hoy en día.

Esperamos que esta publicación les haya resultado de interés y ¡nos leemos pronto!

Referencias y Links

• Azure Resource Group Model – Modern Management for Modern Cloud: http://bit.ly/1RIzXFd
• Using the Azure Portal to manage your Azure resources: https://azure.microsoft.com/en-us/documentation/articles/resource-group-portal/
• Azure Resource Manager Tools Preview: https://azure.microsoft.com/en-us/blog/azure-resource-manager-tools-preview/
• Azure Compute, Network, and Storage Providers under the Azure Resource Manager: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-azurerm-versus-azuresm/
• Understanding Resource Manager deployment and classic deployment: https://azure.microsoft.com/en-us/documentation/articles/resource-manager-deployment-model/#considerations-for-virtual-machines
• Azure subscription and service limits, quotas, and constraints: https://azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/
• AN INTRODUCTION TO THE AZURE RESOURCE MANAGER (ARM): http://rickrainey.com/2016/01/19/an-introduction-to-the-azure-resource-manager-arm/
• Azure Resource Manager overview: https://4sysops.com/archives/azure-resource-manager-overview/

Acerca del Autor