Infrastruktur aus Code: Vereinfachung von Cloud-Bereitstellungen

Im Laufe der Jahre habe ich mit verschiedenen Infrastructure as Code (IaC)-Tools gearbeitet, und eine Herausforderung sticht dabei besonders hervor: der Aufwand, der erforderlich ist, um die Lücke zwischen Anwendungsentwicklung und Infrastrukturmanagement zu schließen. Infrastructure from Code geht dieses Problem an, indem es die Infrastruktur direkt von der Anwendungslogik abstrahiert, wodurch die Entwicklungsabläufe nahtloser und agiler werden. In diesem Artikel werden wir verschiedene Tools besprechen, die den Weg zu Infrastructure from Code ebnen. Wir werden darauf eingehen, was Infrastructure from Code beinhaltet und welche Probleme es zu lösen versucht.

Was ist Infrastruktur aus Code?

Mit Infrastructure from Code können Sie die Cloud-Infrastruktur direkt aus dem Anwendungscode generieren und verwalten. Im Gegensatz zur traditionellen IaC, bei der die Infrastruktur manuell mit Tools wie Terraform oder Bicep definiert werden muss, optimiert Infrastructure from Code diesen Prozess, indem es die erforderliche Infrastruktur aus der Art und Weise ableitet, wie die Anwendung geschrieben ist. Dadurch können sich die Entwickler mehr auf ihren Code konzentrieren und sich darauf verlassen, dass die Infrastruktur nahtlos angepasst wird. Dies ist wichtig, da die Infrastruktur schneller bereitgestellt wird und somit Verzögerungen im Entwicklungszyklus reduziert werden. Es stellt sicher, dass Änderungen an Anwendungen und Infrastruktur immer synchron sind, was die Konsistenz zwischen verschiedenen Umgebungen verbessert. Da die Entwickler keine detaillierten Infrastrukturkonzepte mehr verstehen müssen, vereinfacht es die Arbeitsabläufe und ermöglicht es den Teams, sich stärker auf die Anwendungsentwicklung zu konzentrieren. Aber ist Infrastructure from Code der richtige Ansatz für Sie? Bevor wir in ein Infrastructure from Code-Tool eintauchen und sehen, wie es funktioniert, machen wir zunächst einen kleinen Ausflug in die Geschichte, um zu sehen, wie wir hierher gekommen sind und welche Veränderungen in unserer Branche dafür verantwortlich sind. Wir beginnen mit einem Blick auf die traditionellen IaC-Tools und ihre Herausforderungen. Als nächstes werden wir ein wenig darüber sprechen, wie DevOps und Platform Engineering die Art und Weise verändert haben, wie wir diese Tools und ihre Verwendung betrachten. Wir werden sehen, wie Tools, die eine Abstraktion auf den traditionellen IaC-Tools aufbauen, immer mehr Verbreitung finden. Schließlich werden wir uns ein Tool ansehen, das diese Abstraktion noch einen Schritt weiterführt, indem es die Infrastruktur automatisch auf der Grundlage des Anwendungscodes bereitstellt.

Ein Blick zurück: traditionelles IaC

Die herkömmliche IaC war für die reproduzierbare und vorhersehbare Verwaltung der Infrastruktur unterschiedlich nützlich. Tools wie Terraform und Bicep erleichtern die Automatisierung komplexer Cloud-Umgebungen durch die Verwendung deklarativer Konfigurationssprachen. Diese Tools haben mehrere Vorteile:

• Konsistenz: Die Infrastruktur kann auf konsistente Weise definiert werden, wodurch das Risiko menschlicher Fehler verringert wird.
• Skalierbarkeit: Die Infrastruktur kann je nach Bedarf problemlos auf- oder abgebaut werden.
• Kollaboration: Teams können gemeinsam am Infrastrukturcode arbeiten, was den Austausch von Wissen und Best Practices erleichtert.
• Dokumentation: Der Infrastrukturcode dient als Dokumentation, die das Verständnis der Architektur erleichtert.
• Testen: Der Code der Infrastruktur kann vor der Bereitstellung getestet und validiert werden, wodurch das Risiko von Fehlern in der Produktion verringert wird.
• Automatisierung: Eliminieren Sie manuelle Fehler und rationalisieren Sie die Bereitstellung.
• Versionskontrolle: Infrastrukturdefinitionen können in Repositories gespeichert und nachverfolgt werden.
• Wiederverwendbarkeit: Modulare Setups ermöglichen eine bessere Verwaltung über Regionen, Umgebungen und Teams hinweg.

Trotz seiner Vorteile hat das traditionelle IaC immer noch einige Schwachstellen:

• Lernkurve: Tools wie Terraform oder Bicep erfordern ein tiefgreifendes Verständnis der Sprachsyntax. Terraform-Neulinge haben zum Beispiel oft Schwierigkeiten mit komplexeren Konstrukten wie for_each oder Funktionen wie flatten. Diese können für diejenigen, die mit den fortgeschrittenen HCL-Funktionen nicht vertraut sind, schwierig sein. Der Umgang mit Statusdateien in Terraform, die lokal oder in entfernten Backends wie Azure Storage gespeichert sind, macht die Sache ebenfalls kompliziert, vor allem wenn es um die Zusammenarbeit über mehrere Umgebungen hinweg geht. Außerdem erfordert das Einrichten und Testen komplexer Terraform-Module für Skalierbarkeit und Wiederverwendung ein gründliches Verständnis. Ein weiteres Problem ist, dass es nicht ausreicht, nur Terraform oder Bicep zu lernen. Ein Ingenieur muss sich auch mit verschiedenen anderen Tools und Konzepten auskennen, wie Azure CLI, Azure DevOps, GitHub Actions und CI/CD-Pipelines. Das kann für Neulinge überwältigend sein.
• Overhead bei der Synchronisierung: Der Abgleich von Anwendungs- und Infrastrukturänderungen kann die Entwicklung verlangsamen. Wenn ein Ingenieur die Anwendungslogik ändert, ist die Aktualisierung des entsprechenden Infrastrukturcodes oft ein separater und zeitaufwändiger Prozess. Oft benötigen Teams ein separates Team für die Verwaltung des Infrastrukturcodes, was zu Wartezeiten und Kommunikationsaufwand führen kann.
• Tiefes Verständnis der Infrastruktur: Ingenieure müssen Cloud-Konzepte und -Services verstehen, um die Infrastruktur richtig zu definieren. Dies kann ein Hindernis für diejenigen sein, die sich mehr auf die Anwendungsentwicklung konzentrieren. Die Einrichtung einer einfachen Website auf einem Azure App Service erfordert beispielsweise Kenntnisse über App Service-Pläne, Netzwerke, Identität und andere Azure-Dienste.
• Multi-Cloud-Unterstützung: Obwohl Tools wie Terraform und Pulumi mehrere Cloud-Anbieter unterstützen, kann die Verwaltung von Multi-Cloud-Setups komplex sein. Ingenieure müssen die Feinheiten der einzelnen Cloud-Anbieter verstehen, was eine Herausforderung sein kann. Außerdem spreche ich immer noch mit Leuten, die denken, dass sie bei der Verwendung von Terraform einfach zwischen Cloud-Anbietern wechseln können. Das ist nicht der Fall. Die Syntax mag zwar die gleiche sein, aber die Ressourcen sind es nicht und die meiste Arbeit muss neu gemacht werden.
• Komplexität in fortgeschrittenen Szenarien: Erweiterte Szenarien, wie z.B. regionsübergreifende Failover oder die Integration von Tools von Drittanbietern, erfordern oft benutzerdefinierte Skripte oder manuelle Eingriffe. Dies kann zu erhöhter Komplexität und potenziellen Fehlern führen.
• Werkzeuge und Ökosystem: Das Ökosystem rund um IaC-Tools kann fragmentiert sein. Terraform verfügt zwar über eine Vielzahl von Anbietern, aber nicht alle Cloud-Dienste sind abgedeckt. Das kann dazu führen, dass Ingenieure eigene Anbieter oder Skripte schreiben müssen, um bestimmte Ressourcen zu verwalten.

DevOps und Plattformtechnik

Der Aufstieg von DevOps und Platform Engineering hat die Landschaft weiter verkompliziert. In dem Maße, in dem Unternehmen DevOps-Praktiken einführen, ist die Zusammenarbeit zwischen Entwicklungs- und Betriebsteams immer schwieriger geworden, insbesondere in großen Unternehmen. Diese Verschiebung hat zur Entstehung neuer Rollen geführt, wie z.B. Plattformingenieure, die sich auf den Aufbau und die Wartung der Infrastruktur konzentrieren, die die Anwendungsentwicklung unterstützt. Plattformingenieure sind für die Schaffung von Self-Service-Plattformen verantwortlich, die es Entwicklern ermöglichen, ihre Anwendungen bereitzustellen und zu verwalten, ohne dass sie über tiefgreifende Infrastrukturkenntnisse verfügen müssen. Dieser Wandel hat zur Entwicklung von Tools und Frameworks geführt, die die Komplexität der traditionellen IaC abstrahieren und es den Entwicklern ermöglichen, sich auf das Schreiben von Code statt auf die Verwaltung der Infrastruktur zu konzentrieren.

Alternativen zum traditionellen IaC

Ein Vorteil von Tools wie Bicep oder Terraform ist, dass Sie damit die volle Kontrolle über die bereitzustellende Infrastruktur haben. Diese Macht hat jedoch ihren Preis: Sie müssen die zugrunde liegende Infrastruktur und die Tools selbst verstehen. Bevor wir uns mit Infrastructure from Code befassen, sehen wir uns an, wie drei andere Tools die oben genannten Tools nutzen, um uns das Leben leichter zu machen. Da jedes dieser Tools uns eine höhere Abstraktionsebene bietet, können wir sie schön auf einer Leiter darstellen. Je höher wir kommen, desto weniger müssen die Entwickler über die zugrunde liegende Infrastruktur und die für ihre Bereitstellung verwendeten Tools wissen.

Azure Entwickler CLI (azd)

Erstens gibt es das Azure Developer CLI (azd). Azure azd ist ein Tool, das die Bereitstellung und den Einsatz von Anwendungsressourcen auf Azure beschleunigt. Ingenieure beginnen damit, ein Projektverzeichnis zu erstellen und Befehle wie azd init auszuführen, um die Anwendungsvorlage zu initialisieren. Dies bildet das Gerüst für den Code und die Infrastruktur. Dies kann eine C#-Webanwendung und die benötigte Infrastruktur wie Azure App Services, Function Apps oder Cosmos DB und Speicher umfassen, die alle auf der ausgewählten Vorlage basieren. Die zugrunde liegende Infrastruktur wird entweder mit Bicep oder Terraform definiert. Die Standardeinstellung ist Bicep, aber Sie können auch zu Terraform wechseln, das sich noch in der Beta-Phase befindet, wenn Sie dies bevorzugen. Mit azd up können Entwickler die Infrastruktur und die Anwendung in einem einzigen Schritt bereitstellen, wodurch der Lebenszyklus der Ressourcenerstellung, der Anwendungsbereitstellung und der Einrichtung der Umgebung vereinfacht wird. Wenn ein Techniker beispielsweise eine Webanwendung bereitstellt, übernimmt azd up Aufgaben wie die Erstellung des App Service Plans, die Bereitstellung einer Ressourcengruppe und die Anwendung geeigneter Konfigurationen - alles in Abhängigkeit von den Anforderungen der Anwendung. Dieser Ansatz löst Probleme wie die zeitintensive Koordination zwischen Entwicklungs- und DevOps-Teams, falsch abgestimmte Anwendungsanforderungen und redundante Skripterstellung für sich wiederholende Bereitstellungen. Darüber hinaus ermöglicht Azure azd den Entwicklern, die Konsistenz über verschiedene Umgebungen hinweg aufrechtzuerhalten, indem alles als Teil der Projektvorlage definiert wird. Es hilft den Entwicklern auch, sich auf die Anwendungslogik zu konzentrieren, indem es die zugrundeliegenden Infrastrukturdetails abstrahiert, über die sie möglicherweise nicht genügend Kenntnisse haben. Azure azd hat jedoch Einschränkungen. Es ist in erster Linie auf Azure-spezifische Dienste zugeschnitten, was bedeutet, dass Ingenieure es nicht in Multi-Cloud-Strategien einsetzen können. Außerdem vereinfacht es zwar die Standardanwendungsfälle, aber die Anpassung der Infrastruktur für fortgeschrittene Szenarien - wie regionsübergreifende Failover oder die Integration von Tools von Drittanbietern - erfordert häufig die Ergänzung von azd durch traditionelle IaC-Tools wie Terraform oder ARM-Vorlagen. Ich sehe Azure azd daher eher als ein Tool, das die Standardanwendungsfälle vereinfacht, um schnell loszulegen, aber nicht als Ersatz für traditionelle IaC-Tools.

Pulumi

Pulumi ist ein weiteres Tool, das (hauptsächlich) Terraform unter der Haube verwendet, um die Bereitstellung durchzuführen. Mit Pulumi können Entwickler die Infrastruktur mit vertrauten Programmiersprachen wie C#, Python, TypeScript oder Go definieren. Dies ermöglicht es Entwicklern, dieselbe Sprache sowohl für den Anwendungs- als auch für den Infrastrukturcode zu verwenden, was den Kontextwechsel reduziert und eine nahtlosere Entwicklungserfahrung ermöglicht. Pulumi löst einige Herausforderungen, auf die Ingenieure normalerweise bei herkömmlicher IaC stoßen, wie das Debuggen des geschriebenen Codes. Es ermöglicht Entwicklern auch die Wiederverwendung bestehender Programmierkonstrukte wie Schleifen und Konditionale, die vertraut und ausdrucksstark sind. Außerdem können sie dieselben Konzepte nutzen, um Code zwischen Teams und Projekten auszutauschen, was bei der Skalierung von Infrastrukturen oder der Festlegung konformer Standards von Vorteil sein kann. Trotz seiner Vorteile hat Pulumi auch seine Grenzen. Es erfordert von den Entwicklern Programmierkenntnisse, die über die Standardsyntax des IaC-Tools hinausgehen, was ein Hindernis darstellen könnte. Daher sehe ich Pulumi nur für Anwendungsentwickler als nützlich an, die bereits ein tiefes Verständnis für eine Programmiersprache haben. Für diejenigen, die das nicht haben, ist es vielleicht besser, bei den traditionellen IaC-Tools zu bleiben. Ein Vorteil von Azure azd ist, dass es die zugrundeliegenden Infrastrukturdetails abstrahiert, was den Einstieg für Entwickler erleichtert. Pulumi hingegen erfordert ein tieferes Verständnis von Cloud-Infrastrukturkonzepten, wie es bei der Verwendung von Terraform oder Bicep erforderlich war.

using Pulumi;
using Pulumi.AzureNative.Resources;
using Pulumi.AzureNative.Storage;
using Pulumi.AzureNative.Storage.Inputs;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading;

return await Pulumi.Deployment.RunAsync(() =>
{
    while (!Debugger.IsAttached)
    {
        Thread.Sleep(100);
    }

    // Create an Azure Resource Group
    var resourceGroup = new ResourceGroup("rg-pulumi-debug");

    // Create an Azure resource (Storage Account)
    var storageAccount = new StorageAccount("stgpulumidebug", new StorageAccountArgs
    {
        ResourceGroupName = resourceGroup.Name,
        Sku = new SkuArgs
        {
            Name = SkuName.Standard_LRS
        },
        Kind = Kind.StorageV2
    });
});

Radius

Radius ist ein Tool, das ursprünglich vom Inkubationsteam bei Microsoft entwickelt wurde, jetzt aber Open Source ist und ein CNCF-Projekt darstellt. Es ist eine Plattform für Cloud-native Anwendungen, die nicht nur Entwicklern, sondern auch den Infrastrukturbetreibern, die sie unterstützen, helfen soll. Das Ziel ist es, die Entwicklung von Cloud-nativen Anwendungen effizienter und zugänglicher zu machen, unabhängig davon, auf welcher Cloud-Plattform Sie landen. Radius bietet diese Selbstbedienungsplattform, die es Entwicklern ermöglicht, sich auf ihre Kernaufgaben zu konzentrieren. Für die einen ist das die Codierung von Microservices, für die anderen die Erstellung der Anwendungsinfrastruktur. Cloud-native Anwendungen werden immer komplexer. Die Synergie zwischen Entwicklern und IT-Betreibern wird daher immer wichtiger. Radius erleichtert die Zusammenarbeit zwischen diesen beiden wichtigen Teams. Und so funktioniert es:

• Definieren Sie Ihre Anwendung: Entwickler definieren ihre Anwendungen in Radius, einschließlich aller Dienste, Abhängigkeiten und Beziehungen zwischen ihnen, wo sie dies normalerweise in Infrastruktur- oder Kubernetes-Ressourcen tun würden. Dieser Ansatz strafft den Entwicklungsprozess und macht es einfacher, komplexe Anwendungen zu verwalten.
• Erstellen von Umgebungen: Parallel dazu definieren Betreiber innerhalb von Radius Umgebungen, die Infrastrukturvorlagen, Richtlinien und organisatorische Anforderungen für die von ihnen gewählte Plattform kapseln, unabhängig davon, ob es sich um Azure, AWS oder eine selbstgehostete Plattform handelt. So wird sichergestellt, dass Ihre Anwendungen auf jeder Cloud-Plattform reibungslos funktionieren.

Das folgende Codeschnipsel zeigt, wie Sie eine einfache Anwendung in Radius definieren. Der Code ist in Bicep geschrieben, der von Radius verwendeten Sprache. Der Code definiert eine einfache Webanwendung, die einen Redis-Speicher verwendet. Die Anwendung wird als Container definiert und der Redis-Speicher als Datenspeicher. Beachten Sie, dass wir keine spezifischen Details über die zugrunde liegende Infrastruktur angegeben haben. Dies wird alles von Radius erledigt.

extension radius

@description('The Radius Application ID. Injected automatically by the rad CLI.')
param application string

@description('The environment ID of your Radius Application. Set automatically by the rad CLI.')
param environment string

resource demo 'Applications.Core/containers@2023-10-01-preview' = {
  name: 'demo'
  properties: {
    application: application
    container: {
      image: 'ghcr.io/radius-project/samples/demo:latest'
      ports: {
        web: {
          containerPort: 3000
        }
      }
    }
    connections: {
      redis: {
        source: db.id
      }
    }
  }
}

resource db 'Applications.Datastores/redisCaches@2023-10-01-preview' = {
  name: 'db'
  properties: {
    application: application
    environment: environment
  }
}

Wenn Sie den Befehl 'rad up' ausführen, wird die Anwendung auf unserem lokalen Cluster bereitgestellt, ich verwende K3D. Die Übersetzung zwischen den im obigen Beispiel definierten Typen und der tatsächlich ausgeführten Infrastruktur erfolgt durch das, was wir in Radius 'Rezepte' nennen. Wenn Sie also 'rad up' ausführen, sieht sich Radius die Anwendungs- und Umgebungsdefinitionen an und verwendet dann die Rezepte, um die Anwendung auf dem lokalen Cluster bereitzustellen. Wenn Sie die Anwendung z.B. auf Azure bereitstellen, verwendet Radius die Azure-Rezepte, um die Anwendung auf Azure bereitzustellen. Die Abbildung unten zeigt, wie Radius die Rezepte für die Bereitstellung der Anwendung in Azure verwendet.

Infrastruktur aus Code

Wenn Sie eines der oben genannten Tools verwenden, müssen Sie immer noch die Infrastruktur definieren. Dies geschieht entweder direkt über z.B. Terraform oder mit einem Tool, das die Infrastruktur abstrahiert, wie Azure azd. Infrastructure from Code geht bei dieser Abstraktion noch einen Schritt weiter, indem es die Infrastruktur automatisch auf der Grundlage des Anwendungscodes bereitstellt. Dieser Ansatz ist besonders leistungsfähig für serverlose und ereignisgesteuerte Anwendungen, bei denen Infrastrukturkomponenten wie APIs, Message Queues oder Datenbanken eng mit dem Code verbunden sind. Es gibt verschiedene Tools, die dieses Konzept auf die eine oder andere Weise umsetzen. Lassen Sie uns einige dieser Tools auf einer hohen Ebene vergleichen, bevor wir einige davon in Aktion sehen. Bei der Auswahl eines Tools gibt es mehrere Faktoren, die wir berücksichtigen können. Zum Beispiel, welche Cloud-Plattformen sie ansteuern können, welche Programmiersprachen sie unterstützen und welche IaC-Sprache sie unter der Haube verwenden. Hier finden Sie eine Tabelle mit den Tools und den unterstützten Cloud-Plattformen.

Werkzeug	Azure	AWS	GCP
Stickstoff	X	X	X
Klotho		X
Ampt		X
Zugabe		X	X

Unterstützte Programmiersprachen:

Werkzeug	.Net	Java	Python	Gehen Sie	TypeScript	Node.js
Stickstoff	X*	X	X	X	X
Klotho			X	X
Ampt					X	X
Zugabe				X	X	X

Die zugrunde liegende IaC-Sprache:

Werkzeug	Terraform	Pulumi	Andere
Stickstoff	X	X	X
Klotho			X
Ampt			X
Zugabe			X

Nachdem ich mir diese Liste angesehen hatte, beschloss ich, mir Nitric anzusehen. Mit diesem Tool kann ich Azure anvisieren und meinen Code in einer Sprache schreiben, die ich (irgendwie ;-)) kenne, nämlich TypeScript. Es gibt eine (sehr) experimentelle Unterstützung für C#, also habe ich mich entschieden, diesen Weg nicht zu gehen.

Stickstoff

Nitric bietet ein Framework für die Erstellung von Backends. Es handelt sich um ein deklaratives Framework mit gemeinsamen Komponenten wie APIs, Warteschlangen und Datenbanken. Nitric abstrahiert die zugrunde liegende Infrastruktur, so dass sich die Entwickler auf die Erstellung von Anwendungen konzentrieren können, aber auch mit diesen Ressourcen interagieren können. Die zugrunde liegenden Dienste können leicht ausgetauscht werden, da sie steckbar sind. Ein einfacher API-Endpunkt in Nitric sieht wie folgt aus:

import { api } from '@nitric/sdk'

const main = api('main')

main.get('/hello/:name', async ({ req, res }) => {
  const { name } = req.params
  ctx.res.body = `Hello ${name}`
})

Der obige Code wird in Nitric auch als Dienst bezeichnet. Er ist der Einstiegspunkt für die Anwendung. Sie können einen oder viele davon haben. Indem wir die import-Anweisung verwenden und eine Instanz des Typs api erstellen, teilen wir Nitric mit, dass wir eine API bereitstellen möchten. Wenn wir Nitric später ausführen und in Azure bereitstellen, wird eine Azure Container App erstellt, auf der die Anwendung ausgeführt wird, und es wird eine Instanz der API-Verwaltung erstellt, um die API bereitzustellen und zu testen. In einer Konfigurationsdatei, wie der folgenden, teilen Sie Nictric mit, wo die Dienste zu suchen sind und wie sie ausgeführt werden sollen.

name: example
services:
  - match: services/*.ts
    start: npm run dev:services $SERVICE_PATH

Dann haben wir das Konzept der Ressourcen. Diese sind die zugrunde liegende Infrastruktur, die die Dienste nutzen. In dem folgenden Beispiel verwende ich eine Speicherressource.

import { bucket } from '@nitric/sdk'

const uploads = bucket('uploads').allow('read')

const files = await uploads.files()

files.forEach((file) => {
  console.log(file.name)
})

Der obige Bucket wird in Azure als Speicherkonto bereitgestellt. Der Bucket wird dann zum Speichern von Dateien in Blobs verwendet. Sehen Sie, wie einfach es ist, Ihre Anforderungen zu definieren, ohne eine einzige Zeile Infrastrukturcode zu schreiben? Der obige Code listet alle Dateien im Bucket auf. Aber woher weiß Nitric, wie es die Ressourcen bereitstellen soll? Dies geschieht in einer nitric..yaml-Datei. In dieser Datei legen Sie den zu verwendenden Provider fest. Im folgenden Beispiel verwende ich den Anbieter Pulumi, um Azure anzusteuern.

provider: nitric/azure@1.1.1
region: northeurope

Nun ist es an der Zeit, unsere Anwendung zu starten. Sie können dies lokal tun, indem Sie 'nitric start' in einem Terminal ausführen. Alle Dienste werden dann mithilfe von Containern lokal emuliert. Außerdem wird eine Dashboard-Benutzeroberfläche für die Interaktion mit den Ressourcen bereitgestellt. Wenn Sie nun 'nitric up' ausführen, wird Ihre Anwendung in der Cloud bereitgestellt. In meinem Fall sehe ich, dass verschiedene Ressourcen wie eine API-Verwaltungsinstanz, ein Azure-Speicherkonto und eine Funktions-App erstellt werden. Die API-Verwaltungsinstanz wird verwendet, um die API-Endpunkte bereitzustellen. Das Azure Storage-Konto wird verwendet, um Dateien in Blobs zu speichern. Die Function App wird verwendet, um den Anwendungscode auszuführen. Und das alles, ohne dass wir eine einzige Zeile Infrastruktur definieren müssen.

Wann und warum Sie Infrastructure from Code verwenden sollten

Nachdem wir nun ein Beispiel dafür gesehen haben, wie wir die Leistungsfähigkeit von IfC mit Nitric ausnutzen können, lassen Sie uns darüber sprechen, wo es meiner Meinung nach am besten geeignet ist. Infrastructure from Code eignet sich am besten für Situationen, in denen Geschwindigkeit und Einfachheit für Entwickler wichtiger sind als eine feinkörnige Kontrolle der Infrastruktur. Sie ist besonders in den folgenden Kontexten von Vorteil:

Startups und MVPs

Startups müssen oft schnell liefern, ohne Zeit für die Entwicklung der Infrastruktur aufzuwenden. Die IfC-Tools ermöglichen ihnen das:

• Konzentrieren Sie sich ausschließlich auf das Schreiben von Produktcode.
• Stellen Sie die Infrastruktur automatisch bereit, ohne dass Sie viel Unterstützung durch ein Plattformteam benötigen.
• Iterieren Sie schnell und drehen Sie sich um, ohne sich um die Cloud zu kümmern.

Ereignisgesteuerte Anwendungen

Viele IfC-Tools wurden mit Blick auf Cloud-native, ereignisgesteuerte Muster entwickelt (z. B. HTTP-Routen, Warteschlangen, Funktionen). Sie sind ideal für:

• APIs, die durch HTTP oder Ereignisse ausgelöst werden.
• Hintergrundarbeiter, Cron-Jobs.
• Serverlose Anwendungsfälle, die Dienste miteinander verbinden.

Interne Tools und Prototypen

Für interne Anwendungen, die betriebliche Probleme lösen oder Arbeitsabläufe automatisieren:

• Einfachheit und Geschwindigkeit überwiegen oft den Bedarf an unternehmensgerechtem Infrastrukturdesign.
• Mit IfC können Entwickler Tools einführen, ohne die Infrastruktur-/Plattformteams einzuschalten.

Entwicklergesteuerte Teams

In Teams, in denen die Entwickler für den gesamten Lebenszyklus verantwortlich sind (Build → Deploy → Monitor), reduziert IfC die Notwendigkeit, Terraform, Bicep oder YAML zu lernen.

• Es unterstützt das Modell "Sie bauen es, Sie betreiben es".
• Geringere Hürde für die Cloud-Bereitstellung = mehr Möglichkeiten für Entwickler.

Überlegungen und Zukunftsaussichten

Ein Tool wie Nitric sieht wirklich vielversprechend aus und macht die Erstellung einer neuen Anwendung wirklich einfach. Das Tool, wie auch andere IfC-Tools, wirkt noch nicht wirklich ausgereift. Ich bin auf dem Weg dorthin auf einige Fehler gestoßen. Die meisten davon wurden zwar schnell in einer neuen Version behoben, aber dennoch. Auch die Unterstützung für verschiedene Cloud-Ressourcen ist recht gering. Ich kann mir zwar gut vorstellen, dass dieser neue Ansatz in Zukunft funktionieren wird, aber er bringt auch einige zusätzliche Überlegungen mit sich:

• Abstraktions-Overhead: Zu viel Abstraktion kann die Kontrolle beeinträchtigen.
• Cloud- oder Anbieterbindung: Tools können manchmal eng an bestimmte Anbieter oder SDKs gebunden sein, wie im Fall von Nitric.
• Komplexe Szenarien: Fortgeschrittene Anpassungen können immer noch auf traditionelle IaC-Techniken zurückgreifen.

Infrastructure from Code bietet einen transformativen Ansatz für die Cloud-Entwicklung. Durch die Konzentration auf anwendungsorientierte Workflows und die Abstrahierung der Details der Infrastruktureinrichtung können Entwickler schneller vorankommen und die betriebliche Komplexität reduzieren. Tools wie Nitric können Ihre Entwicklungsprozesse wirklich beschleunigen, sind aber nicht für jeden geeignet. Jedes der anderen erwähnten Tools kann bereits einen erheblichen Fortschritt gegenüber der Verwendung von traditionellem IaC darstellen. Nachfolgend finden Sie eine Tabelle, die die in diesem Beitrag erwähnten Tools auflistet und ihre Eigenschaften wie Abstraktionsebene, verwendete Sprache und Cloud-Unterstützung zusammenfasst. Dies sollte Ihnen helfen, das richtige Tool für Ihre Bedürfnisse auszuwählen.

Werkzeug	Infra Definiert in	Abstraktionsebene	Verwendete Sprache	Cloud-Unterstützung	Am besten für
Terraform	Deklarativ (HCL)	Niedrig	HCL	Multi-Cloud	Infra-Teams kennen sich mit Code aus
Bizeps	Deklarativ (Bizeps)	Niedrig	Bizeps	Azurblau	Azure-fokussierte Infra-Teams
Pulumi	Imperativ (Code)	Medium	TypeScript, Python, Go, C#	Multi-Cloud	Entwickler bevorzugen echte Sprachen
azd	Schablonen + IaC	Medium	CLI (Bicep/Terraform unter der Haube)	Azurblau	Schnelles App-Bootstrapping auf Azure
Radius	Rezepte + IaC	Hoch	Konfig + Bizeps	Azure, AWS, Google, Kubernetes	Plattformteams ermöglichen Entwicklern
Stickstoff	In Anwendungscode	Höchste	TypeScript, Python, Go	Multi-Cloud	Serverlose und ereignisgesteuerte Anwendungen

  Dieser Artikel ist Teil des XPRT. Magazin. Die Goldene Ausgabe! Laden Sie Ihr kostenloses Exemplar hier herunter