Azure Service Manager (ASM) vs Azure Resource Manager (ARM). ¿Que hago?,¿migro?¿me actualizo?

Buenos dias,

Hay mucha información y literatura en Internet sobre las dos versiones de Azure, Azure Service Manager (ASM), versión 1 o classic, y Azure Resource Manager (ARM), versión 2, se habla de Cloud Services, IaaS, Worker Roles, migraciones de una versión a otra, etc., Si me gustaría compartir con vosotros una serie de Posts, primero explicando ambas versiones, el enfoque que tiene cada una, y en posteriores posts, como migrar nuestros recursos desde un despliegue clásico a uno en ARM.

Hoy ASM vs ARM. Espero no aburriros ya que es un poco teórico, hago una explicación básica, sencilla y directa. La práctica, lo que nos gusta lo dejo para los siguientes posts.

ASM

Modelo de despliegue basado en el Servicio:

• El Cloud Service actua como un contenedor para hospedar los servicios, como por ejemplo las máquinas virtuales (IaaS), con todos sus componentes, ya sean interfaces de red, Direcciones IP públicas, nombres DNS, así como balanceador/equilibrador de carga, Endpoints de acceso ya sea via Powershell, RDP o SSH.
• Asimismo se agrega el almacenamiento necesario donde ubicar los discos duros virtuales para una máquina virtual, incluido el sistema operativo, discos de datos temporales y adicionales.
• Para finalizar, se incluiría una red virtual opcional que actúa como un contenedor adicional, en el que se puede crear una estructura de subredes y designar la subred en la que se encuentra nuestro Cloud Service.

ASM tiene el siguiente diagrama, todo integrado dentro de un Cloud Service:

ARM

Por otro lado, este modelo de despliegue se basa en «Recursos»:

• Todos los recursos se despliegan dentro de un grupo de recursos (RG), nuestro contenedor lógico.
• Básicamente, el almacenamiento, el tipo de instancia y la red (Interfaz de red, balanceador de carga, Network Segurity Group, VNet, Subred, etc), son los pilares de una VM, aunque podemos asignar y desasignar muchos de estos servicios sin tener que redesplegar el IaaS.
• Disponemos de los Network Security Groups (NSG) – Grupos de Seguridad de Red que actuan como Firewalls aplicándose directamente contra una subred o contra una interfaz de red de una VM.
• Las VMs se crean dentro de una VNet, ya sea nueva o existente.

El modelo de despliegue ARM tiene el siguiente diagrama:

Llegado a este punto solo nos queda reflexionar …

¿Por qué tengo que migrar mi infraestructura desplegada en Azure? Pros y Cons.

Situaciones en las que voy a valorar esta migración:

• Actualización.- Obvio, si mi proveedor de nube se está actualizando ¿porque no hacerlo yo? ¿Por que quedarme obsoleto en la nube? Suena paradójico pero es real.
• Contrato.- Por cambio de contrato. Estoy mirando si mi contrato actual de Cloud es mas económico que un Contrato tipo CSP. Para migrar a este tipo de facturación pago por uso necesito que todos mis recursos estén en ARM.
• Mejoras.- Microsoft solo está aplicando las mejoras y las actualizaciones sobre ARM …. me estoy perdiendo lo mejor si no actualizo.
• Ofertas.- Las ofertas y las nuevos productos, por ejemplo IaaS, version Av2, Av3, Dv2, Dv3, etc., solo están disponibles en ARM …. otra vez, … me lo estoy perdiendo!!!!
• …..

¿Que ventajas me aporta estar en ARM?

Independientemente de que se utilizan portales distintos para el acceso (ASM: https://manage.windowsazure.com vs ARM: https://portal.azure.com ), poco a poco todo se va migrando al portal nuevo y desaparece del clásico. Os dejo las que a mi parecer son las principales diferencias a tener en cuenta que nos pueden empujar a acelerar el movimiento de un Azure a otro:

• Powershell.- Los cmdlets a utilizar son distintos, basta con ver que tenemos que cargar el módulode Azure (Clasic) o el de AzureRM (ARM).
• Servicios vs Recursos.- Está claro que el modo de despliegue de cada una de las versiones es opuesta, ASM está orientado a Servicios, el despliegue se hacia de forma «paquetizada» y, normalmente habia que hacer un redespliegue de la solución por cada cambio vs ARM, orientada a Recurso,
• RBAC.- Control de Acceso basado en Roles que se aplica en ARM. En la versión clásica teniamos poco por donde movernos ¿quien no recuerda este comentario?: O eres Service Administrator o eres Co-administrado. Vaaaamos.
• Tagging.- Vamos, etiquetado. Esta solución de control de gasto solo se puede aplicar en ARM. Un punto mas.
• Plantillas.- En ARM podemos crearnos y tenemos a nuestra disposición infinidad de plantillas JSON para automatizar al máximo nuestros despliegues.
• Redespliegue.- Otro detalle para añadir es la opción de «Redesplegar» una solución desde una ya existente …. vamos
• Nuevo portal.– El nuevo portal está desarrollado en HTML5 y en formato «Blade» … vamos que nunca se acaba.

Y alguna mas que se me pasará por alto.

Tabla de compatibilidad

Quiero dejar claro que muchos servicios de Azure ASM los podemos migrar directamente y también está claro que hay otros que no se pueden migrar, que tendremos que hacer un nuevo desarrollo. En resumen, recursos compatibles para la migración:

• Máquinas virtuales
• Conjuntos de disponibilidad
• Cloud Services
• Cuentas de almacenamiento
• Redes virtuales
• Puertas de enlace de VPN
• Puertas de enlace de ExpressRoute (en la misma suscripción que solo Virtual Network)
• Grupos de seguridad de red
• Tablas de ruta
• Direcciones IP reservadas

Vamos, la mayoría de los que nos importan.

El modelo de despliegue de «Cloud Services» tipo Web roles y Worker roles no es compatible con el modelo de despliegue ARM y, como ya hemos comentado, habrá que ver opciones y posibilidades que tenemos: Service Fabric, App Service, … nuevo desarrollo.

En el próximo Post…. Cómo migrar de ASM2ARM con herramientas oficiales: Azure Powershell.

Un abrazo a todos. Feliz Black Friday ….

No os lo gasteis todo, dejar algo para mañana.