Microsoft bietet mit „Azure Dev Box“ einen Self-Service für den Zugriff auf vorkonfigurierte, direkt zum Programmieren einsatzbereite, Cloud-basierte Workstations an. Entwicklungsprojekte sollen von maßgeschneiderten Tools, Quellcode und vorgefertigten Binaries profitieren.
Der Dienst „Azure Dev Box“ wurde initial im vergangenen Jahr angekündigt und hat mit Blick auf die Build-Konferenz zahlreiche Neuerungen erfahren. Dev Box eignet sich für unterschiedliche Szenarien. So unterstützt es beispielsweise Teams für die Plattformtechnik darin, die passenden „Dev-Box-Computer“ für die Workloads der jeweiligen Benutzer bereitzustellen.
Die Möglichkeiten umfassen das Hinzufügen von „Dev-Box-Pools“, „Dev-Box-Definitionen“ und das Zuweisen des Zugriffs für die „Dev-Box-Benutzer“, sowie das Steuern der Kosten unter Zuhilfenahme von Zeitplänen für automatisches Beenden. Auch das Definieren der „Netzwerkkonfiguration“ gehört in diese Kategorie, ebenso wie das Zuweisen der integrierten „Dev Box-Benutzerrolle“, um dem Entwicklungsteam beispielsweise zu erlauben, selbstständig Dev-Boxen bereitstellen zu können. Die Service-spezifischen Begriffe erläutern wir weiter unten.
- Auch für IT-Administratoren bietet Azure Dev Box zahlreiche Vorteile, denn diese können Boxen genauso verwalten, wie jedes andere Gerät im Netzwerk. So werden Dev-Boxes beispielsweise genauso automatisch in Intune registriert, wie z. B. ein Cloud PC in der Enterprise-Version. So können Admins beispielsweise durch das Verwenden beschleunigter Qualitätsupdates in Intune alle ihre Windows-Geräte auf dem neuesten Stand halten.
- Dev Box bietet außerdem sicheren Zugriff in einer geschützten Umgebung. Administratoren können nämlich mittels Zugriffssteuerung in Azure Active Directory (Azure AD) sämtliche Zugriffe nach Projekt- oder Benutzertyp regeln, weil Dev-Boxes nativ mit einer Azure AD- oder Active Directory-Domäne verknüpft sind.
- Das schließt dann auch die Verwendung von Conditional Access Policies mit ein. Hierunter fallen z. B. das Einschränken des Zugriffs über ein Intune-kompatibles Gerät oder das Erzwingen von Multi-Faktor-Authentifizierung. Ebenso lassen sich Identity Protecs mittels einer automatischen Risikobewertung für Benutzer oder Anmeldungen einrichten, die dann als Kriterium in eine Regel für den bedingten Zugriffe einfließen können.
- Leiter von Entwickler-Teams mit der Rolle des DevCenter-Projektadministrators sind insofern ein Szenario für Dev Box, als diese das gesamte Projekt verwalten, indem Sie Dev Box-Pools erstellen und entsprechende Dev Box-Definitionen hinzufügen. In erste Linie adressiert die Dev Box aber natürlich Entwickler.
- Ein Unternehmen mit global verteilten Development-Teams könnte Dev Boxes so konfigurieren, dass Entwicklerinnen und Entwickler bei Bedarf eigene Dev-Boxen in der jeweils nächstgelegenen Region erstellen oder nach Bedarf Dev-Boxen erstellen können, ohne auf das IT-Admins angewiesen zu sein. Benutzer können dann von jedem Gerät und von jedem Betriebssystem aus auf ihre Dev-Boxen zugreifen.
- Außerdem könne Developer an mehreren Projekten arbeiten, indem sie separate Dev-Boxen für separate Workloads, Projekte oder Aufgaben erstellen. Bedarfsweise lassen sich auch mehrere Dev-Boxen aus vordefinierten Pools erstellen. Unternehmen können sogar Dev-Boxen für verschiedene Rollen in einem Team definieren, etwa eine Standard-Dev-Box mit Administratorrechten, an der Vollzeitentwickler mehr Kontrolle haben, während Auftragnehmer eingeschränktere Berechtigungen erhalten.
Rollenspiel
Microsoft hat den Dev-Box-Dienst für drei verschiedene „Rollen“ einer „Organisation“ konzipiert, Platform Engineers, die Leitung des Entwicklungsteams und die Developer selbst. Plattform-Technikerinnen und -Techniker konfigurieren und verwalten dann die Sicherheitseinstellungen, Netzwerkkonfigurationen und Organisationsrichtlinien, damit die Dev-Boxen sicher auf Ressourcen zugreifen können.
Leiter der Entwicklung verfügen idealerweise über spezifische Projekt-Kenntnisse und bekommen daher die DevCenter-Rolle „Projektadministrator“. Sie helfen dann beim Erstellen und Verwalten der Entwicklungsumgebungen, während „Projektadministratoren“ Pools von Dev-Boxen verwalten.
Die Mitglieder eines Entwicklungsteams bekommen die DevCenter-Rolle Dev-Box-Benutzer zugewiesen und können damit Dev-Boxen aus den für das Projekt aktivierten Pools erstellen und selbst verwalten. Nutzer von Dev-Boxen können an mehreren Projekten oder Aufgaben mitwirken, indem sie mehrere Dev-Boxen erstellen.
Interessante Historie
Erst auf der Build-Konferenz hat Microsoft mehrere neue Funktionen für seinen Dev-Box-Dienst vorgestellt, darunter z. B. die Integrationen mit Visual Studio. Dabei ist es insgesamt interessant, die Entwicklungsgeschichte von Dev Box Revue passieren zu lassen. Erstmalig angekündigt worden war Dev Box auf der Microsoft Build 2022.
Die Vorgeschichte geht aber schon viel weiter zurück nämlich auf die im Jahr 2016 eingeführten Azure DevTest Labs, einen Dienst, der es Entwicklungsteams ermöglicht, mit Vorlagen versehene virtuelle Maschinen (VMs) für eine Vielzahl von Entwicklungs- und Testanwendungsfällen zu erstellen. Unser Einführung-Beitrag zu DevTest-Labs wird im Kontext der neuen Dev-Box-Funktionen noch fortgeführt.
Ein besonders häufiger Anwendungsfall für die DevTest-Labs ist z. B. das Erstellen dauerhafter, vorkonfigurierter Entwicklungsumgebungen. Trotzdem aller Vorteile ist der Aufbau benutzerdefinierter Lösungen auf Basis der DevTest-Labs auch heute noch eine Herausforderung und erfordert einen erheblichen Aufwand für die Entwicklung zusätzlicher Governance- und Verwaltungsfunktionen, sodass sich viele Kunden laut Microsoft eine schlüsselfertige Lösung wünschten.
Als Reaktion darauf hat Microsoft 2019 Visual Studio Codespaces eingeführt. Hierbei handelt es sich um vorkonfigurierte, Container- und Linux-basierte Entwicklungsumgebungen, die sich in Sekundenschnelle direkt aus Visual Studio Code erstellen lassen und Entwicklern eine schnelle und einfache Möglichkeit bieten, auch von unterwegs an ihren Apps weiterzuarbeiten. Der Dienst existiert bis heute in Form der GitHub Codespaces, schätzen ihn doch viele Entwickler wegen seiner Geschwindigkeit und Mobilität.
Engagierte Softwareentwicklung erfordert allerdings alle möglichen Werkzeuge und da Microsoft Codespaces ursprünglich zur Unterstützung von Visual Studio Code und GitHub entwickelt hatte, kam bei Kunden schnell der Wunsch nach Unterstützung für andere integrierte Entwicklungsumgebungen (IDEs), Quellcodeverwaltung und Tools auf. Microsoft hatte daraufhin zunächst damit begonnen, Codespaces um die Unterstützung von Visual Studio zu erweitern. Dies erwies sich allerdings als herausfordernder, als erwartet, vor allem im Hinblick Management- und Governance-Features auf Unternehmensniveau.
In Anbetracht der Tatsache, dass Entwickler in ihrer Cloud-Umgebung Zugriff auf sämtliche Tools benötigen würden, war schnell klar, dass eine wie auch immer geartete Lösung einige Schlüsselmerkmale würde aufweisen müssen. Dazu gehören unternehmenstaugliche Sicherheits-, Compliance- und Kostenmanagement-Funktionen, Cloud-basierte Leistung mit Entwicklungstool-Integrationen sowie Self-Service-Zugriff auf vorkonfigurierte, projektspezifische Ressourcen. Letztendlich würde es auf eine für Entwickler optimierte Virtualisierungslösung hinauslaufen.
Da Microsoft bereits den Cloud PC/Windows 365 anbietet, der ein sicheres Streamen personalisierter Windows-Desktops, samt Apps, Einstellungen und Inhalten aus der Microsoft Cloud auf jedes Gerät von überall auf der Welt ermöglicht, bot sich dieser als eine optimale Basis für das gesteckte Ziel an. Dabei ist allerdings entscheidend, dass Windows 365 ( in der Enterprise-Version) vollständig in Microsoft Intune integriert ist.
Erst Intune erlaubt es, dass IT-Administratoren, Cloud-PCs neben den physischen Geräten verwalten können. Dank der Vorkonfiguration solcher Cloud-Workstations müssen sich Entwickler nicht jedes Mal an die IT kontaktieren, sobald sie neue Workstation benötigen. Da Microsoft mit dem Cloud-PC für ein einzelnes Projekt mehrere Workstation-Konfigurationen zur Verfügung stellen kann, sind Entwickler auch nicht an eine einzige Konfiguration gebunden, sondern können eine maßgeschneiderte Workstation auswählen, hochfahren und schnell mit dem Codieren beginnen.
Microsoft Dev Box
Mit dem neuen Dienst stellt Microsoft sogar ein spezielles Developer-Portal zur Verfügung, das schnellen und einfachen Zugriff auf die projektbasierten Workstations zur Verfügung stellt. So können Entwickler und Entwicklerinnen das Portal auch nutzen, um mithilfe der ebenfalls allgemein verfügbaren Azure-Bereitstellungsumgebungen schnell Umgebungen für jede Entwicklungsphase bereitzustellen.
Bei Microsoft Dev Box handelt es sich also um Workstations auf Basis der Cloud-PC-Technologie, die speziell für Anwendungsfälle und Produktivität von Entwicklern optimiert sind. Dev Box kombiniert also für die Programmierarbeit optimierte Funktionen mit der unternehmenstauglichen Verwaltung von Windows 365 und Microsoft Intune.
Laut Microsoft arbeitet das Dev-Box-Team eng mit anderen Teams bei Microsoft zusammen. Zuletzt war dies das Visual Studio-Team, um dem Dev-Box-Dienst Integrationen hinzuzufügen, die das Visual Studio-Erlebnis auf Dev Box optimieren sollen, etwa in Form der „Configuration-as-Code“-Anpassung in der Dev Box. Dieser erlaubt Entwicklungsleitern eine noch detailliertere Kontrolle bei der Konfiguration von Dev Boxes für bestimmte Aufgaben und ermöglicht es unter anderem, die Dev-Box-Bereitstellung mit bestehenden Git-Flows zu verbinden.
Vor der Markteinführung 2022 hat Dev Box laut Microsoft zahlreiche interne Stresstests mit Produkten auf Basis von Repos durchlaufen, die Hunderte von Gigabyte groß waren. Laut Microsoft nutzen heute intern bereits mehr als 10.000 Ingenieure bei Microsoft den Dev-Box -Dienst intern und zahlreiche Kunden setzen ihn produktiv ein. Das Produkt eignet sich demnach vorzüglich als vollwertiger Desktop-Ersatz. Man kann aber auch leistungsstarke Dev Boxen für eine besonders rechenintensive Aufgabe als Zweit-Maschine betreiben, etwa für Experimente oder Machbarkeitsstudien.
Preise
Microsoft hatte wohl ursprünglich geplant, den Preis der Dev Box auf Grundlage eines reinen Verbrauchsmodells zu etablieren. Dies hätte zwar für eine Teilzeit-Nutzung gut funktioniert, ließ aber nicht viel Spielraum für Administratoren, die für die Vollzeit-Nutzung standardisierte monatliche Preise zu zahlen bereit wären.
Microsoft hat daher doch einen vorhersehbaren monatlichen Preis für die Vollzeit-Dev-Box-Nutzung eingeführt, behält aber gleichzeitig den verbrauchsbasierten, nutzungsbasierten Preis bei, der bis zu einer monatlichen Preisobergrenze berechnet wird. Das neue Preismodell für Dev Box bringt die beiden Extreme Vollnutzungs- und Abonnementpreis ins Gleichgewicht und stellt sicher, dass Entwickler ihre Ausgaben sowohl für Vollzeit- als auch für Teilzeit-Anwendungsfälle optimieren können.
So zahlt der Nutzer z. B. im Ernstfall den maximalen monatliche Preis pro Instanz immer nur dann, wenn die Nutzung für eine bestimmte Instanz die Kosten über diesen Höchstpreis für den Monat hinaus erhöhen würde. Der Dienst wechselt automatisch vom Stundenpreis zum maximalen monatlichen Preis (z. B. 8 vCPU, 32 GB RAM, 256 GB für $138,20 ), sodass sich der Nutzer keine Gedanken über die Verwaltung der Nutzung machen muss. Allerdings ist der Dienst derzeit nur in USA verfügbar.
Funktionsprinzip der Dev Box
Das Einrichten des Dev-Box-Dienstes startet mit dem Erstellen eines „Dev Center“. Dieses repräsentiert alle organisatorischen Einheiten eines Unternehmens. Ein Dev Center ist ein logischer Container, der Unternehmen beim Organisieren ihrer Dev-Box-Ressourcen unterstützt. Darin können Unternehmen dann beliebig viele Dev Center-Instanzen erstellen, obwohl meist nur eine benötigt wird.
Die Kommunikation der Boxen mit dem Unternehmensnetzwerk wird mit Hilfe von „Netzwerkverbindungen“ erreicht. In einer solchen „Netzwerkverbindung“ definieren Admins, wie Dev-Boxes mit Azure AD verknüpft sind, etwa mittels Azure-AD-Einbindung (AAD Join), damit ausschließlich eine Verbindung mit Cloud-basierten Ressourcen hergestellt werden können oder bei Bedarf mittels Azure AD-Hybrideinbindung, um eine Verbindung mit lokalen und cloudbasierten Ressourcen herzustellen zu können. Mit Hilfe von „Dev-Box-Definitionen“ definieren Unternehmen dann die Konfiguration der Dev-Boxen.
Unternehmen können dazu ein Image aus dem Azure Marketplace verwenden, wie z. B. „Visual Studio 2022 Enterprise in Windows 11 Enterprise + Microsoft 365 Apps 22H2“ oder optional ein eigenes benutzerdefiniertes Image, welches zuvor erstellt und in der Azure Compute Gallery gespeichert wurde. Schließlich gibt man eine SKU mit Compute und Speicher an, um die Dev-Box-Definition abzuschließen.
„Dev-Box-Projekte“ schließlich stellen den Zugriffspunkt für Entwicklungsteams bereit. Admins weisen einem Projekt dann beispielsweise die Dev-Box-Benutzerrolle zu, um Developern einen Zugriff auf die zugeordneten Dev-Box-Pools des Projekts zu ermöglichen. Dev-Box-Pools wiederum machen Dev-Box-Definitionen in Projekten verfügbar. Ein Dev-Box-Pool ist eine Gruppe von Dev-Box-Definitionen mit vergleichbaren Einstellungen.
Unternehmen können z. B. Dev-Box-Pools mit einem Zeitplan für automatisches Beenden konfigurieren. Ist die Konfiguration abgeschlossen, können Entwickler ihre Dev-Boxen im Entwickler-Portal erstellen und verwalten. Sie haben dann nur Zugriff auf die Dev-Box-Pools, die genau den Projekten zugeordnet sind, für die Entwickler die „Dev-Box-Benutzer“-Rolle haben. Begleiten Sie uns im nächsten Teil beim Erstellen und Konfigurieren von Dev Boxes.