[Articulo] Azure | Guía de convención de nombres para Azure

¿Por qué pensar en lineamientos de nomenclatura? Esta es una pregunta que ustedes, como lectores, nos podemos hacer cuando ingresamos a esta publicación quizás por curiosidad.

Microsoft, como fabricante, provee lineamientos generales y recomendaciones a tener en cuenta al momento de elegir los nombres de las suscripciones y recursos en Azure. Si a esto le sumamos recomendaciones en base a nuestra experiencia como profesionales, plus acuerdos con nuestra organización, tenemos un combo muy nutrido de buenas prácticas en materia de nombres.

En esta publicación vamos a recorrer: las recomendaciones del fabricante, sus consideraciones, y por último nuestras recomendaciones en base a la experiencia de estos años.

¡Esperamos que lo disfruten y estamos en contacto!

[toc]

Introducción

Objetivo y Alcance

Esta publicación tiene como objetivo que las organizaciones, como así también sus administradores de IT, comentar los lineamientos recomendados en relación a la nomenclatura de recursos recomendada para Microsoft Azure (si bien puede aplicarse a cualquier nube pública).

Todos los temas tratados aquí serán en alto nivel técnico, es decir que no entraremos en detalles de bajo nivel sobre el cómo hacer una determinada tarea o acción.

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

¿Convención de Nombres? ¿Para qué?

Una estrategia y convención de nombres para los recursos de cualquier nube informática (y en este caso Azure) es ideal para que dichos recursos sean fáciles de ubicar e identificar. Podemos tener el mejor proyecto IaaS, PaaS o híbrido, pero si el nombre de los recursos no dice nada para una organización o dificultan su localización, la percepción de éxito se puede ver afectada.

Cuando decimos “convención de nombres” estamos englobando tres aspectos fundamentales, sin importar la plataforma de la cual hablemos:

1. Entender qué tipo de restricciones o consideraciones hay en la utilización de caracteres: ya sea en longitud total, caracteres permitidos y no permitodos, uso de caracteres especiales, etc.
2. Entender qué opciones provee la plataforma, para poder identificar que incluir o no en la nomenclatura: ¿existen opciones Windows / Linux?, ¿existen diferentes zonas geográficas?, ¿existen diferentes ambientes (desarrollo / QA / producción)?
3. Entender qué es significativo y cómodo para la organización que utilizará esos nombres: no siempre las recomendaciones son aplicables en todos lados.

En esta publicación vamos a recorrer los lineamientos generales, consideraciones especiales y algunos ejemplos de nuestra experiencia. ¡Esperamos les sirvan!

Lineamientos Generales

Restricciones y Consideraciones

Existen algunas restricciones en los caracteres y longitudes a utilizar en Azure para el nombre de algunos recursos. Estras restricciones pueden variar según el recurso del que hablemos. Veamos algunos ejemplos:

• Los Resource Groups tienen una longitud permitida de 1-64 caracteres y se permiten valores alfanuméricos, barra baja (underscore) y guión.
• En cambio, los Storage Accounts tienen una longitud permitida de 3-24 caracteres y solo se permiten caracteres en minúscula alfanuméricos.

El cuadro actualizado y completo de estas restricciones y consideraciones se podrá encontrar en la siguiente URL: https://docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions

Recomendaciones de Azure

Como recomendaciones generales para nomenclaturas en Azure, podemos identificar las siguientes.

Nombre de Suscripciones

• Los nombres detallados nos permiten entender el contexto y propósito de la suscripción, y más en un entorno donde hay muchas suscripciones.
• Una recomendación puede ser: <NombreDeCompania> <UnidadDeNegocioODepartamento> <Proyecto (si corresponde)> <Ambiente (si corresponde)>.

Vamos a dar algunos ejemplos:

Recomendaciones para Recursos

• En lo posible, utilizar prefijos o surfijos para identificar el tipo de recurso. Por ejemplo: vm-nombredeequipo ó nombredeequipo-vm para indicar que es una máquina virtual.
• Dependiendo del recurso, a veces un aspecto importante es el Ambiente (dev, prod, QA).
• Dependiendo del recurso, a veces es util poder especificar la ubicación (US West = uw, US East = ue).
• Dependiendo del recurso, a veces es útil poder indicar la instancia (01, 02, 03) del recurso.
• Dependiendo del recurso, a veces es recomendado indicar el producto, proyecto o linea de servicio.
• Por último, es siempre recomendado indicar en un prefijo o surfijo el rol (sql, web, rg para resource groups, etc).

Conclusiones

Tener lineamientos claros y acordados con el equipo de trabajo sobre nomenclatura de recursos en Azure no solo ayuda a una mejor organización, sino que también nos permite ubicar más rapidamente los recursos. En infraestructuras de nube cada vez más grandes, esto se vuelve más crítico aún.

Como hemos visto, existen algunos fundamentos, restricciones y consideraciones sobre los caracteres y longitudes a tener en cuenta, además de consideraciones y recomendaciones adicionales que podemos plasmar aquí en base a nuestra experiencia.

Esperamos que esta publiación les haya resultado de interés. ¡Saludos!

Referencias y Links

• Sin datos.

Acerca del Autor