Azure: Naming Conventions

Beim Aufsetzen deiner Cloud-Infrastruktur in Azure ist eine einheitliche Namenskonvention entscheidend. Sie erlaubt es dir, Ressourcen schnell zuzuordnen und einen klaren Überblick zu bewahren. Für neue Mitarbeitende ist eine nachvollziehbare Benennungssystematik besonders wichtig, um sich schnell zurechtzufinden.

Fertige Konventionen nutzen

Du musst das Rad nicht neu erfinden, da es bereits etablierte Namenskonventionen gibt, etwa die vom Microsoft Cloud Adoption Framework. Bei der Benennung ist es wichtig, den Typ der Ressource zu kennzeichnen, wie beispielsweise App Service oder Storage Account. Auch die Region und die Umgebung, wie Test oder Produktion, sollten im Namen erkennbar sein. Diese Informationen sorgen dafür, dass Ressourcennamen global eindeutig sind.

Eine Empfehlung, aufbauend auf dem Cloud Adoption Framework:

<ResourceType>-<Project>-<Environment|dev|tst|prd|stg>-<Region|weu|neu>-<AppName>

Daraus ergibt sich z.B. ein App Service für eine Web API des Open Space Planner mit dem Namen app-osp-dev-weu-api.

Um die Einhaltung der Konventionen zu gewährleisten, kannst du Infrastructure as Code nutzen. Ein Beispiel in Bicep:

@export()
func constructResourceName(
  resourceType string,
  applicationName string,
  environment string,
  location string,
  resourceName string,
  withDashes bool
) string =>
  withDashes
    ? '${resourceType}-${applicationName}-${environment}-${location}-${resourceName}'
    : '${resourceType}${applicationName}${environment}${location}${resourceName}'

Eine Alternative kann sein, Resource Type und Project von der Position im Namen zu wechseln, um so schneller eine Übersicht über alle Resourcen eines Projektes zu erhalten. Hierbei ist es wichtig, dass die Konventionen klar definiert und dokumentiert sind, um Missverständnisse zu vermeiden.

Maximale Länge beachten

Ein weiterer wichtiger Aspekt ist die maximale Länge von Ressourcennamen. Viele Ressourcen, wie Storage Accounts, haben spezifische Längenbeschränkungen. Ein Storage Account darf zum Beispiel maximal 24 Zeichen lang sein. Achte darauf, dass du bereits verwendete Buchstaben für die Region oder Umgebung berücksichtigst, um genügend Platz für den eigentlichen Ressourcennamen zu erhalten. Eine durchdachte Planung hilft, spätere Probleme zu vermeiden. Eine Übersicht über die Einschränkungen gibt es hier.

Beachte auch deine Abkürzungen für die Umgebung und auch die Region einheitlich lang zu machen. Wer seine Dev-Umgebung mit dev abkürzt, aber seine Produktiv-Umgebung mit prod, wird beim Deployment nach Dev noch kein Problem haben, aber spätestens bei Production in Probleme kommen.

Versuche auch die Länge von resourceType, applicationName, environment und location so kurz wie möglich zu halten, um genügend Platz für den eigentlichen Namen zu haben. Hier ist maximal 3 Zeichen empfehlenswert.

Eine Hilfe kann wieder Infrastructure as Code sein, bei dem du die maximale Länge direkt vor dem Deployment prüfen kannst. Bicep z.B. unterstützt eine Validierung von Parametern und das Definieren einer minLength und maxLength. Diese sind von Haus aus in Azure Resource Manager Templates schon vorhanden, so dass beim Anlegen einer Resource auch die Länge des Namens geprüft wird.

Bindestriche oder nicht?

Eine häufige Fragestellung ist die Verwendung von Bindestrichen in den Namen. Während viele Ressourcen Bindestriche unterstützen, tun es andere nicht. Ein gemischter Ansatz, bei dem du Bindestriche zur Verbesserung der Lesbarkeit nutzt, während du bei Ressourcen, die keine erlauben, darauf verzichtest, hat sich bewährt.

Bindestriche können die Lesbarkeit und Struktur von Ressourcennamen erheblich verbessern. Sie helfen dabei, verschiedene Teile des Namens klar zu trennen und machen es einfacher, auf den ersten Blick zu erkennen, um welche Art von Ressource es sich handelt und zu welchem Projekt oder welcher Umgebung sie gehört. Zum Beispiel ist app-osp-dev-weu-api auf den ersten Blick verständlicher als appospdevweuapi.

Sinnvolle Suffixe nutzen

Denke darüber nach, Suffixe für bestimmte Ressourcen zu verwenden, um sie mit einer Anwendung oder einem Produkt zu verbinden. Oft kann dies hilfreicher sein als feste Konventionen wie ein Counter. Wenn der Bedarf besteht, eine Ressource mit spezifischen Anhängen zu versehen, kann dies klare Vorteile mit sich bringen. Letztlich trägt eine durchdachte Namensgebung dazu bei, die Zuordnung und Verwendung von Ressourcen in deiner Infrastruktur zu optimieren.

Ein finales Beispiel könnt ihr dem Open Space Planner entnehmen.

Wie handhabst du die Namenskonventionen in deiner Azure-Infrastruktur? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.