Nachhaltiges Software-Engineering durch die Linse der Umwelt: Messung

"Wenn man es nicht messen kann, kann man es nicht verbessern." - Peter Drucker

Im XPRT Magazine #15 wurde der erste Artikel über nachhaltiges Software-Engineering zum Nutzen des Klimas veröffentlicht. In diesem Artikel möchten wir dieses Thema erneut aufgreifen und uns dabei auf die Messung der Kohlenstoffemissionen von Azure konzentrieren. Ohne die Messung unserer Ausgangsbasis können wir nicht mit der Arbeit an der CO2-Effizienz beginnen. Bevor wir eintauchen, lassen Sie uns kurz rekapitulieren. Nachhaltige Softwareentwicklung hat fünf Dimensionen:

Quelle: https://se.ewi.tudelft.nl/research-lines/sustainable-se/

In diesem Artikel konzentrieren wir uns auf das Thema "Umwelt". Wir werden näher darauf eingehen, wie wir durch cleveres Software-Engineering auf Azure eine grünere Umwelt fördern können. Dies kann geschehen, indem wir den CO2-Fußabdruck unserer Betriebssoftware in der Cloud reduzieren. Vielleicht können wir aber auch auf die linke Seite wechseln und die Kohlenstoffemissionen bei der Entwicklung und Erstellung von Software reduzieren. Aber bevor wir die Kohlenstoffemissionen optimieren, müssen wir eine Basislinie messen und wir brauchen Prinzipien, die uns auf unserem Weg zu einer grüneren Software leiten. An dieser Stelle kommt die Green Software Foundation (GSF) ins Spiel, wie Sie sich vielleicht aus dem vorherigen Artikel erinnern. Allerdings müssen wir die Grundsätze der GSF noch einmal überdenken.

Die 3 Prinzipien der Green Software Foundation

Die GSF ist eine gemeinnützige Organisation, die sich für die Verringerung der Umweltauswirkungen von Software einsetzt (https://greensoftware.foundation/). Im Gegensatz zu dem früheren Artikel hat die GSF ihre Grundsätze auf die folgenden drei Prinzipien gestrafft: * Energieeffizienz * Hardware-Effizienz * Kohlenstoff-Bewusstsein

Drei Prinzipien sind leichter zu merken und vereinfachen die Einhaltung. Bevor Sie jedoch an der "Energieeffizienz", der "Hardware-Effizienz" und dem "Kohlenstoff-Bewusstsein" Ihrer Betriebssoftware auf Azure arbeiten können, müssen Sie Ihren Kohlenstoff-Fußabdruck messen, um eine Basislinie zu erstellen. Microsoft hat den Carbon Optimization Service auf Azure und eine dazugehörige REST API veröffentlicht! Das ist eine hervorragende Nachricht. Die Messung Ihrer CO2-Emissionen auf Azure ist jetzt viel leichter zugänglich. Werfen wir einen Blick auf den Carbon Optimization Service und seine API.

Kohlenstoff-Optimierungsservice

Geben Sie "Carbon Optimization" in Ihre Suchleiste im Azure-Portal ein, und Sie werden den Carbon Optimization Service finden. Er verwendet Azure's RBAC für die Autorisierung und führt daher eine neue Rolle ein: Carbon Optimization Leser-Rolle. Erwerben Sie diese Rolle, und schon sind Sie startklar! Der Carbon Optimization Service startet mit den Emissionstrends:

Der obige Screenshot zeigt die Kohlenstoffemissionsmetriken, die in Ihren Berichten verwendet werden können, z.B. in der Corporate Sustainability Reporting Directive (CSRD) in Europa oder der Securities and Exchange Commission (SEC) in den USA. Wir wollen hier nicht aufhören, denn wir wollen unsere Kohlenstoffemissionen genauer untersuchen, um unsere Softwarelandschaft auf Azure zu optimieren. Deshalb sollten Sie auf Emissionsdetails klicken:

Auf dieser Registerkarte können Sie Ihre Kohlenstoffemissionen sogar pro Ressource aufschlüsseln, wie im Screenshot gezeigt (Ressourcennamen wurden von mir geschwärzt). Andere Ebenen sind Abonnements, Ressourcengruppen, Dienste (alle Ihre virtuellen Maschinen oder Funktions-Apps usw.) und Standorte. Wenn Sie eine Basislinie für die Kohlenstoffemissionen jeder Ressource in Ihren Abonnements erstellt haben, können Sie sogar auf "Emissionsreduzierung" klicken, um einige Empfehlungen zu erhalten:

Im Moment denke ich, dass die Vorschläge größtenteils mit den Vorschlägen übereinstimmen, die Sie zum Kostenmanagement in Azure Advisor erhalten. Es gibt sogar eine Spalte "Monatliche Kosteneinsparungen" am Ende. Die Kosten können ein guter Indikator für den Ausstoß von Kohlendioxid sein, aber Sie können niemals gedankenlos den Kosteneinsparungen folgen. Es ist gut, dies im Hinterkopf zu behalten.

Das Anklicken dieses Dienstes im Azure-Portal und der Export von Daten ist für den Anfang gut und ein hervorragender Start für die Berichterstattung über Ihre Kohlenstoffemissionen in der Azure-Cloud. Aber früher oder später werden Sie die Kohlenstoffemissionen Ihrer Ressourcen auf Azure programmatisch abrufen wollen, um sie in einer CI/CD-Pipeline oder einem Nachhaltigkeits-Tool usw. weiter zu verarbeiten. Werfen wir einen Blick auf die neue Carbon Optimization REST API!

Kohlenstoff-Optimierung REST API

Die neue API hat mehrere Vorteile. Erstens verwendet sie die normale Authentifizierung und Autorisierung mit RBAC und Microsoft Entra ID, wie alle anderen modernen APIs auf Azure. Alles, was Sie tun müssen, ist: * Erstellen Sie einen Client in Microsoft Entra ID (der als App-Registrierung bezeichnet wird); * Stellen Sie sicher, dass der Client die neue Carbon Optimization Reader-Rolle hat; * Notieren Sie sich die Client-ID (Anwendungs-ID auf Azure) und das Client-Geheimnis, nachdem Sie den Client erstellt haben Danach sind Sie startklar! Ich habe eine Console App in C#.NET erstellt, um die API zu testen. Um sich zu authentifizieren, benötigen wir zunächst die folgenden Codezeilen:

 string authority = "https://login.microsoftonline.com/"+ tenantId;
string[] scopes = new string[] { "https://management.azure.com/.default" };
string[] subscriptions = new string[] {
    "[SUBSCRIPTION ID]"
};

Ersetzen Sie tenantId durch die ID Ihres Mandanten. Dann werden wir ein Zugriffstoken für diesen Client erwerben:

var app = ConfidentialClientApplicationBuilder.Create(clientId)
    .WithClientSecret(clientSecret)
    .WithAuthority(authority)
   .Build();
 
var authenticationResult = await app.AcquireTokenForClient(scopes).ExecuteAsync();

string accessToken = authenticationResult.AccessToken;

Ersetzen Sie clientId und clientSecret durch die Client-ID und das Client-Geheimnis des Clients, den Sie zuvor mit der Carbon Optimization Reader Rolle erstellt haben. Nachdem wir ein Zugriffstoken abgerufen haben, können wir die Carbon Optimization API aufrufen. Zum Zeitpunkt der Erstellung dieses Artikels haben wir zwei Endpunkte: * List Carbon Emission Reports * Query Carbon Emission Data Available Date Range

Lassen Sie uns zunächst den verfügbaren Datenbereich abrufen.

Abfrage von Kohlenstoffemissionsdaten Verfügbarer Datenbereich

Es ist sinnvoll, zunächst den verfügbaren Datenbereich für die Kohlendioxidemissionsdaten abzurufen, damit wir nicht einen Aufruf zur Auflistung der Kohlendioxidemissionsberichte mit einem ungültigen Datenbereich machen. Der C#-Code hierfür sieht wie folgt aus:

using (HttpClient client = new HttpClient())
{
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);

   string queryCarbonEmissionDataAvailableDateRangeUrl = "https://management.azure.com/providers/Microsoft.Carbon/queryCarbonEmissionDataAvailableDateRange?api-version=2023-04-01-preview";
    HttpResponseMessage response = await client.PostAsync(queryCarbonEmissionDataAvailableDateRangeUrl, null);

    string responseContent = await response.Content.ReadAsStringAsync();
    Console.WriteLine(responseContent);
}

Beachten Sie, dass das Zugriffstoken, das wir zuvor abgerufen haben, im Authentifizierungs-Header als Inhaber-Token verwendet wird. Beachten Sie auch, dass die URL mit der allgemeinen URL"https://management.azure.com/providers/"beginnt, dann den Anbieter "Microsoft.Carbon/" angibt, dann den Endpunkt "queryCarbonEmissionDataAvailableDateRange" auswählt und mit dem Abfrageparameter "api-version=2023-04-01-preview" abschließt. Denken Sie daran, dass dies alles nur eine Vorschau ist und sich jederzeit ändern kann. Beachten Sie, dass es sich um eine POST-Methode handelt. Wenn wir diesen POST-Aufruf am Endpunkt über den HTTP-Client ausführen, erhalten wir die folgende Antwort:

{
    "endDate": "2024-01-01",
    "startDate": "2022-02-01"
}

Liste Kohlenstoffemissionsberichte

Im folgenden Aufruf verwenden wir diesen Datenbereich, um detaillierte Emissionsdaten auf Ressourcenebene zu erhalten. Ich bin sehr an diesem Aufruf interessiert, da es bisher nicht möglich war, mit der Sustainability API Kohlenstoffemissionsdaten auf Ressourcenebene zu erhalten. Ich bin sehr gespannt darauf, sie auf Ressourcenebene zu sehen! In C# würde dies wie folgt aussehen:

DateRangeResponse dateRange = JsonConvert.DeserializeObject<DateRangeResponse>(responseContent);

DateRangeRequest dateRangeRequest = new DateRangeRequest
{
   StartDate = dateRange.StartDate,
    EndDate = dateRange.EndDate
};
 
ItemDetailsQueryFilter itemDetailsQueryFilter = new ItemDetailsQueryFilter
{
   CarbonScopeList = [EmissionScopeEnum.Scope1.ToString(), EmissionScopeEnum.Scope2.ToString(), 
    EmissionScopeEnum.Scope3.ToString()],
   CategoryType = CategoryTypeEnum.Resource.ToString(),
   DateRange = dateRangeRequest,
   OrderBy = OrderByEnum.TotalCarbonEmission.ToString(),
    PageSize = 10,
   ReportType = ReportTypeEnum.ItemDetailReport.ToString(),
    ResourceGroupUrlList = Array.Empty<string>(),
    SortDirection = SortDirectionEnum.Asc.ToString(),
    SubscriptionList = subscriptions
};
string itemDetailsQueryFilterAsJson = JsonConvert.SerializeObject(itemDetailsQueryFilter);
StringContent itemDetailsQueryFilterAsStringContent = new
    StringContent(itemDetailsQueryFilterAsJson, Encoding.UTF8, "application/json");
 
string carbonUrl = 
    "https://management.azure.com/providers/Microsoft.Carbon/carbonEmissionReports?api- 
    version=2023-04-01-preview";
>HttpResponseMessage postResponse = await client.PostAsync(carbonUrl, 
    itemDetailsQueryFilterAsStringContent);
string postResponseContent = await postResponse.Content.ReadAsStringAsync();
Console.WriteLine(postResponseContent);

Zunächst wird das DataRangeResponse-Objekt in ein DataRangeRequest-Objekt umgewandelt. Denn wenn Sie sich das DataRangeResponse-Objekt ansehen, sieht es wie folgt aus:

internal class DateRangeResponse
{
   [JsonProperty("startDate")]
    public string StartDate { get; set; }
    [JsonProperty("endDate")]
    public string EndDate { get; set; }
}

Und wenn Sie sich das DataRangeRequest-Objekt ansehen, sieht es wie folgt aus:

internal class DateRangeRequest
{
    [JsonProperty("start")]
    public string StartDate { get; set; }
    [JsonProperty("end")]
    public string EndDate { get; set; }
}

Bitte beachten Sie den Unterschied in den JSON-Eigenschaften, startDate vs. start und endDate vs. Ende. Mit dem richtigen DataRangeRequest-Objekt können wir das ItemDetailsQueryFilter-Objekt konstruieren, das wie folgt aussieht:

internal class ItemDetailsQueryFilter
{
   [JsonProperty("carbonScopeList")]
   public string[] CarbonScopeList { get; set; }
 
    [JsonProperty("categoryType")]
    public string CategoryType { get; set; }
 
    [JsonProperty("dateRange")]
    public DateRangeRequest DateRange { get; set; }
 
   //[JsonProperty("groupCategory")]
    //public string GroupCategory { get; set; }
 
    [JsonProperty("orderBy")]
    public string OrderBy { get; set; }

    [JsonProperty("pageSize")]
    public int PageSize { get; set; }
 
    [JsonProperty("reportType")]
   public string ReportType { get; set; }
 
    [JsonProperty("sortDirection")]
    public string SortDirection { get; set; }
 
    [JsonProperty("subscriptionList")]
    public string[] SubscriptionList { get; set; }

   [JsonProperty("resourceGroupUrlList")]
    public string[] ResourceGroupUrlList { get; set; }
 
  [JsonProperty("skipToken")]
    public string SkipToken { get; set; }
}

Bitte beachten Sie, dass GroupCategory auskommentiert ist. Ich habe einen Fehler erhalten, als ich versucht habe, sie leer oder mit gültigen Werten zu übergeben. Offenbar können Sie den Namen der Gruppenkategorie hier ignorieren, da es sich um ResourceItemDetailsData handelt, was ich von Microsoft gelernt habe. Andere Varianten, bei denen dieser Wert von Bedeutung ist, sind z.B. die Gruppierung nach Abonnement, ResourceGroup usw. Beachten Sie auch, dass Skiptoken vorerst ignoriert wird, aber Sie können es verwenden, um zur nächsten Seite zu gelangen; siehe PageSize. Die Aufzählungen, die zur Konstruktion des ItemDetailsQueryFilter-Objekts verwendet werden, sind

internal enum EmissionScopeEnum
{
    Scope1,
    Scope2,
    Scope3
}
 
internal enum CategoryTypeEnum
{
    Location,
    Resource,
    ResourceGroup,
    ServiceType,
    Subscription
}
 
internal enum SortDirectionEnum
{
    Asc,
    Desc
}
 
internal enum OrderByEnum
{
    Name,
    TotalCarbonEmission,
    TotalCarbonEmissionLastMonth,
    SubscriptionId
}
 
internal enum ReportTypeEnum
{
    ItemDetailReport,
    OverallSummaryReport
}
 
internal enum GroupCategoryEnum
{
    ResourceGroup,
    SubscriptionId
}

Beachten Sie, dass es ItemDetailReport für ReportTypeEnum heißt und nicht ItemDetailsReport (siehe das fehlende 's').

Die vollständigen Beschreibungen für die Attribute des ItemDetailsQueryFilter lauten wie folgt: * carbonScopeList (Erforderlich, EmissionScopeEnum[]): Dieses Array definiert die Bereiche der Kohlenstoffemissionen, die in die Abfrage einbezogen werden sollen. Die Emissionsbereiche umfassen in der Regel Scope 1 (direkte Emissionen aus eigenen oder kontrollierten Quellen), Scope 2 (indirekte Emissionen aus der Erzeugung von zugekaufter Energie) und Scope 3 (alle anderen indirekten Emissionen, die in der Wertschöpfungskette eines Unternehmens entstehen). Die Entwickler müssen angeben, welche dieser Bereiche sie in die Abfrage der Emissionsdaten einbeziehen möchten, um sicherzustellen, dass die Daten die spezifischen Umweltauswirkungsbereiche widerspiegeln, die für ihre Analyse relevant sind. * categoryType (Erforderlich, CategoryTypeEnum): Diese Eigenschaft gibt die Art der Elementkategorien an, die im Emissionsdatenbericht berücksichtigt werden sollen. Der Kategorietyp kann von Ressourcentypen, Servicetypen, Standorten usw. reichen. Sie hilft dabei, die Emissionsdaten auf der Grundlage der angegebenen Dimension zu kategorisieren und bietet einen klareren Überblick darüber, welche Bereiche zum CO2-Fußabdruck beitragen, so dass gezielte Bemühungen um Nachhaltigkeit möglich sind. * dateRange (Erforderlich, DateRange): Gibt das Start- und Enddatum des Zeitraums an, für den die Emissionsdaten abgerufen werden sollen. Dies ermöglicht es Entwicklern, einen bestimmten Zeitrahmen für die Analyse festzulegen, der die Verfolgung von Emissionen im Laufe der Zeit, die Ermittlung von Trends und die Bewertung der Wirksamkeit von Strategien zur Reduzierung von Kohlenstoffemissionen ermöglicht. * Gruppenkategorie (Erforderlich, String): Legt den Namen der Gruppenkategorie fest, für die die Emissionsdaten aggregiert werden sollen. Dies kann eine Ressourcengruppe, eine Servicekategorie oder ein anderes relevantes Gruppierungskriterium sein. Es ermöglicht eine detailliertere Analyse innerhalb der breiteren Kategorietypen und hilft dabei, bestimmte Bereiche mit hohen Emissionen innerhalb einer Kategorie zu identifizieren. * orderBy (Erforderlich, String): Bestimmt den Spaltennamen, nach dem die zurückgegebenen Elemente geordnet werden sollen. Dies kann sich auf jedes relevante Datenfeld beziehen, z.B. Gesamtemissionen, Name des Dienstes usw. Das Aufrufen der Ergebnisse macht die Daten besser lesbar und hilft, die wichtigsten Verursacher des CO2-Fußabdrucks schnell zu identifizieren. * pageSize (Erforderlich, Ganzzahl): Legt die Anzahl der Elemente fest, die in einer Antwort zurückgegeben werden sollen. Dies ermöglicht es den Entwicklern, die von der API erzeugte Datenmenge zu verwalten und erleichtert die Datenverarbeitung und -analyse, insbesondere bei großen Mengen von Emissionsdaten. * reportType (Erforderlich, string: ItemDetailReport): Gibt die Art des zu erstellenden Berichts an. In diesem Fall ist der Berichtstyp auf ItemDetailReport (nicht ItemDetailsReport) eingestellt, was bedeutet, dass die Abfrage darauf abzielt, detaillierte Emissionsdaten abzurufen. Dieser Berichtstyp ist wichtig, wenn Sie bestimmte Artikel oder Kategorien genauer unter die Lupe nehmen möchten, um die Höhe ihrer Kohlenstoffemissionen zu verstehen. * sortDirection (Erforderlich, String): Gibt die Sortierrichtung für die Abfrageergebnisse an, z. B. aufsteigend oder absteigend. Dies wirkt sich auf die Reihenfolge aus, in der die Elemente im Bericht dargestellt werden, und hilft bei der Interpretation der Daten, indem die höchsten oder niedrigsten Emittenten je nach gewähltem Sortierkriterium hervorgehoben werden. * subscriptionList (Erforderlich, string[]): Ein Array von Abonnement-IDs, für die Emissionsdaten abgerufen werden sollen. Dadurch können die Daten so gefiltert werden, dass sie nur bestimmte Azure-Abonnements enthalten, so dass die Analyse für die ausgewählten Cloud-Ressourcen und -Dienste relevant ist. * resourceGroupUrlist (Optional, string[]): Dieses optionale Array gibt die URLs der Ressourcengruppen für den Abruf von Emissionsdaten an. Durch die Einbeziehung bestimmter Ressourcengruppen kann der Datenabruf weiter auf relevante Bereiche eingegrenzt werden, so dass eine gezieltere Analyse bestimmter Segmente eines Azure-Abonnements möglich ist. * skipToken (Optional, String): Dies wird für die Paginierung verwendet; es gibt die Anzahl der zu überspringenden Ergebniselemente an. Dies ist besonders nützlich, wenn Sie mit großen Datensätzen arbeiten, da es Entwicklern ermöglicht, schrittweise durch die Ergebnisse zu navigieren und überschaubare Datenpakete auf einmal abzurufen.

Wir fahren fort, indem wir die URL aufrufen:

https://management.azure.com/providers/Microsoft.Carbon/carbonEmissionReports?api-version=2023-04-01-preview

Was wiederum eine POST-Methode ist. Sie erwartet verschiedene Attribute, die auf dem Wert des Berichtstyps basieren. In unserem Fall haben wir ItemDetailReport angegeben und die Attribute mit den entsprechenden Werten für diese Attribute übergeben. Und nachdem wir den Client aufgerufen haben, erhalten wir...

Ein Fehler??

Als wir diesen Blogbeitrag schrieben, unterstützte die API noch nicht den ItemDetailReport für mehrere Monate. Wir müssen den Teil des Codes, in dem das DateRangeRequest-Objekt erstellt wurde, wie folgt umschreiben:

DateRangeRequest dateRangeRequest = new DateRangeRequest
{
    StartDate = "2024-01-01",
    EndDate = "2024-01-01"
};

So erhalten wir detaillierte Emissionsdaten auf Ressourcenebene für Januar 2024. Passen Sie dies für einen Monat an, für den Sie Kohlenstoffemissionsdaten haben. Das hat wahrscheinlich damit zu tun, dass die Kohlenstoffemissionsdaten im Grunde nur pro Monat vorliegen und sogar einen Monat zurückliegen. Ich hoffe, dass Microsoft dies verbessern wird. Nachdem wir diesen Workaround angewandt haben, erhielten wir die folgende Antwort:

 {
    "skipToken": "",
    "value": [
        {
            "categoryType": "Resource",
            "changeRatioFor12Months": 0,
            "changeRatioForLastMonth": 0,
            "changeValueMonthOverMonth": 0.157786430917075,
            "dataType": "ResourceItemDetailsData",
            "groupName": "",
            "itemName": "dirtyvm",
            "resourceGroup": "dirty-console-app-rg",
            "resourceId": "/subscriptions/[SUBSCRIPTION ID]/resourcegroups/dirty-console-app-rg/providers/microsoft.compute/virtualmachines/dirtyvm",
            "resourceType": "microsoft.compute/virtualmachines",
            "subscriptionId": " [SUBSCRIPTION ID]",
            "totalCarbonEmission": 0.157786430917075,
            "totalCarbonEmission12MonthsAgo": 0,
            "totalCarbonEmissionLastMonth": 0
        }
    ]
}

Die C#-Klasse für die Klasse collection sieht so aus:

internal class CarbonEmissionDataListResult
 {
     [JsonProperty("skipToken")]
     public string SkipToken { get; set; }
     [JsonProperty("value")]
     ResourceItemDetailsData[] Value { get; set; }
 }

Wie Sie sehen können, befindet sich im Attribut "value" ein Array von Objekten der Klasse CarbonEmissionDataListResult. In der Dokumentation steht, dass es auch einen "nextLink" enthalten sollte. In meinem Test habe ich keinen "nextLink" gesehen. Die C#-Klasse für die Detailobjekte sieht wie folgt aus:

public class CarbonEmissionItemDetailData
{
   [JsonProperty("dataType")]
    public string DataType { get; set; }
 
    [JsonProperty("itemName")]
    public string ItemName { get; set; }
 
    [JsonProperty("categoryType")]
    public string CategoryType { get; set; }
 
    [JsonProperty("groupName")]
    public string GroupName { get; set; }
 
    [JsonProperty("subscriptionId")]
    public string SubscriptionId { get; set; }
 
   [JsonProperty("resourceGroup")]
    public string ResourceGroup { get; set; }

    [JsonProperty("resourceId")]
    public string ResourceId { get; set; }
 
   [JsonProperty("resourceType")]
    public string ResourceType { get; set; }
 
    [JsonProperty("totalCarbonEmission")]
    public double TotalCarbonEmission { get; set; }

    [JsonProperty("totalCarbonEmission12MonthsAgo")]
    public double TotalCarbonEmission12MonthsAgo { get; set; }
 
  [JsonProperty("totalCarbonEmissionLastMonth")]
    public double TotalCarbonEmissionLastMonth { get; set; }
 
    [JsonProperty("changeRatioFor12Months")]
   public double ChangeRatioFor12Months { get; set; }
 
    [JsonProperty("changeRatioForLastMonth")]
    public double ChangeRatioForLastMonth { get; set; }

   [JsonProperty("changeValueMonthOverMonth")]
    public double ChangeValueMonthOverMonth { get; set; }
}

Bitte beachten Sie, dass in meinen Tests beim Datentyp ResourceItemDetailsData steht, was nicht mit der Dokumentation übereinstimmt. Die Details der Attribute sind wie folgt: * categoryType (Erforderlich, CategoryTypeEnum): Diese Eigenschaft gibt die Kategorie des Elements an, das auf Kohlenstoffemissionen analysiert wird. Die Kategorie hilft dabei, die Daten nach verschiedenen Aspekten der Azure-Nutzung zu segmentieren, z. B. nach Servicetyp, Ressource usw. Das Verständnis der Kategorie ist für Entwickler entscheidend, um Bereiche zu identifizieren, in denen die Kohlenstoffemissionen reduziert werden können. * changeRatioFor12Months (Erforderlich, Zahl): Dieser numerische Wert stellt die prozentuale Veränderung der Kohlenstoffemissionen für das angegebene Element oder die Kategorie im Vergleich zum Wert vor 12 Monaten dar. Er hilft Entwicklern, die langfristige Effektivität ihrer Strategien zur Verringerung des Kohlenstoffausstoßes zu bewerten, indem sie die aktuelle Leistung mit vergangenen Daten vergleichen. * changeRatioForLastMonth (Erforderlich, Zahl): Ähnlich wie bei changeRatioFor12Months zeigt diese Eigenschaft die prozentuale Veränderung der Kohlenstoffemissionen im Vergleich zum Vormonat an. Sie gibt Aufschluss über die kurzfristigen Auswirkungen von Änderungen an Azure-Ressourcen oder Nutzungsmustern und hilft Entwicklern, sich schnell anzupassen und ihre Bemühungen um Nachhaltigkeit zu verbessern. * changeValueMonthOverMonth (Erforderlich, Zahl): Diese Eigenschaft gibt die tatsächliche Differenz der gesamten Kohlenstoffemissionen zwischen dem aktuellen Berichtszeitraum und dem letzten Monat an. Sie bietet ein präzises, unmittelbares Maß für die Auswirkungen der jüngsten Änderungen und ermöglicht es den Entwicklern, die Auswirkungen ihrer jüngsten Anpassungen oder Interventionen zu quantifizieren. * dataType (Erforderlich, string: ItemDetailsData): Gibt den Datentyp an, der von der Abfrage zurückgegeben wird. Diese Struktur sollte immer auf 'ItemDetailsData' gesetzt werden, was bedeutet, dass sich die Daten auf detaillierte Einblicke in die Kohlenstoffemissionen bestimmter Azure-Ressourcen oder -Dienste beziehen. * groupName (Erforderlich, String): Definiert den Namen der Gruppe, die mit dem Element verbunden ist. Dabei kann es sich um eine Ressourcengruppe oder eine andere Organisationseinheit innerhalb von Azure handeln. Diese Klassifizierung hilft bei der Organisation und Kontextualisierung der Emissionsdaten innerhalb bestimmter Segmente der Azure-Infrastruktur eines Unternehmens. * itemName (Erforderlich, String): Gibt den Namen des Elements an, für das Daten zu Kohlenstoffemissionen gemeldet werden. Dies bezieht sich in der Regel auf eine einzelne Azure-Ressource für diese Struktur, so dass Entwickler emissionsintensive Bereiche innerhalb ihrer Cloud-Infrastruktur identifizieren und sich auf diese konzentrieren können. * totalCarbonEmission (Erforderlich, Zahl): Spiegelt die gesamten Kohlenstoffemissionen wider, die mit dem betreffenden Element verbunden sind, basierend auf den angegebenen Abfrageparametern. Diese Zahl ist entscheidend für das Verständnis der gesamten Umweltauswirkungen bestimmter Azure-Dienste oder -Ressourcen. * totalCarbonEmission12MonthsAgo (Erforderlich, Zahl): Gibt die gesamten Kohlenstoffemissionen für das Element an, wie sie 12 Monate zuvor waren. Dies ermöglicht es Entwicklern, aktuelle Emissionsdaten mit historischen Zahlen zu vergleichen, um langfristige Trends und die Wirksamkeit von Strategien zur Emissionsreduzierung im vergangenen Jahr zu bewerten. * totalCarbonEmissionLastMonth (Erforderlich, Zahl): Gibt die gesamten Kohlenstoffemissionen für das Element im letzten Monat an. Dies ermöglicht einen Vergleich von Monat zu Monat und hilft Entwicklern, aktuelle Trends und die unmittelbaren Auswirkungen von Änderungen bei der Nutzung von Azure-Ressourcen oder Optimierungsmaßnahmen zu verstehen.

Weitere Dokumentation und Ressourcen finden Sie in der offiziellen Dokumentation von Microsoft.

Diese Messungen sind jedoch nicht ausreichend. Es ist immer noch schwierig zu sagen, ob Ihr Arbeitsaufwand kohlenstoffeffizient ist, wenn Sie sich nur diese Kennzahlen ansehen. Daher gibt es den Software Carbon Intensity (SCI) Score von GSF, der die tatsächliche CO2-Effizienz von Software berechnet.

Die SCI-Spezifikation der GSF

Die SCI-Spezifikation der Green Software Foundation bietet einen standardisierten Ansatz zur Messung der CO2-Bilanz von Software. Er hilft, die Nachhaltigkeit Ihrer digitalen Lösungen zu verstehen und zu verbessern. Der SCI wird wie folgt berechnet:

SCI = C pro R

Dabei ist C die Gesamtmenge an Kohlenstoff, die durch die Software emittiert wird, R ist die funktionale Einheit der Elemente in der SCI-Gleichungsskala (z.B. Kohlenstoffemissionen pro zusätzlichem Benutzer, API-Aufruf oder ML-Trainingslauf).

C kann wie folgt berechnet werden:

SCI = (O + M) pro R

Dabei sind O die betrieblichen Emissionen und M die verkörperten Emissionen (eingebetteter Kohlenstoff).

O könnte ausgedrückt werden als:

O = (E * I)

E ist die Energie, die ein Softwaresystem für eine funktionale Arbeitseinheit in kWh verbraucht. Und I ist die Kohlenstoffintensität des verbrauchten Stroms in gCO2eq/kWh.

Und hier fangen die Dinge an, ein wenig vage zu werden. Wenn wir Microsofts Scope-3-Transparenz in einem Dokument mit dem Titel "A New Approach for Scope 3 Emissions" (Ein neuer Ansatz für Scope-3-Emissionen) lesen , ist der entscheidende Satz, den ich hier hervorheben möchte:

"Microsoft weist den einzelnen Cloud-basierten Kunden auf der Grundlage ihrer Azure-Dienstnutzung IT-Hardware-basierte Azure-Cloud-Dienst-Emissionen zu.

Und wie definieren sie "Verwendung"?

"Um die Microsoft Scope 3 Hardware-Emissionen den Azure-Kunden zuzuordnen, definiert Microsoft die Nutzung als die normalisierte Kostenmetrik, die mit Infrastruktur als Dienst (IaaS), Plattform als Dienst (PaaS) oder Software als Dienst (SaaS) verbunden ist.

Die Schlüsselwörter sind hier "normalisierte Kostenmetrik". Die Nutzung ist an Kostenmetriken gekoppelt. Wenn ich dieser Dokumentation folge, kann ich nicht mit Sicherheit sagen, dass die Kohlenstoffemissionen aus der verbrauchten Energie(E) mal der Kohlenstoffintensität des Stroms zum jeweiligen Zeitpunkt(I) abgeleitet sind.

Aber ich würde es lieber nicht an den Verbrauch koppeln (lesen Sie normalisierte Kostenkennzahlen). Er sollte vielmehr mit der verbrauchten Energie und der standortbezogenen Kohlenstoffintensität des Netzes zum Zeitpunkt des Verbrauchs verknüpft werden. Außerdem kann ich in der Dokumentation nicht finden, ob eingebetteter Kohlenstoff berücksichtigt wurde. Aber lassen Sie uns hier einfach davon ausgehen, dass es sich bei den vom Carbon Optimization Service bereitgestellten Kohlenstoffemissionen um betriebliche Emissionen(O) handelt, und weiter geht's. Wir nehmen an, dass eingebetteter Kohlenstoff(M) hinzugefügt wurde. Dann nehmen wir an, dass wir die Gesamtmenge an Kohlenstoff, die die Software emittiert, haben(C).

Microsoft erwähnt in seinem Azure Architecture Center auch einen SCI-Wert. Aber die Gleichung lautet wie folgt:

SCI = C * R

Beachten Sie, dass es sich dabei nicht um einen Wert pro R handelt. Microsoft sagt, dass Sie auf diese Weise den Gesamteffekt der Nutzung der Anwendung bewerten können (z.B. durchschnittliche gleichzeitige Benutzer für das betrachtete Zeitfenster). Aber ich fürchte, dieser Artikel ist veraltet, da der Carbon Optimization Service nicht erwähnt wird und der letzte Commit sieben Monate zurückliegt, um Application Insights durch Azure Monitor zu ersetzen:

Ich bin mir nicht sicher, ob die Kohlenstoffemissionen von Azure's Carbon Optimization mit dem C des GSF übereinstimmen, aber das bedeutet nicht, dass die Metriken des Carbon Optimization Service nutzlos sind. Auch sie sind für Berichtszwecke und als erster Schritt zu einer grüneren Software auf Azure akzeptabel. Ich würde sie vorerst einfach als das C in der Gleichung verwenden.

Fazit

Zusammenfassend lässt sich sagen, dass wir auf dem Weg zu nachhaltigem Software-Engineering die entscheidende Rolle einer genauen Messung bei der Reduzierung der Kohlenstoffemissionen auf Azure erkennen. Die Einführung des Carbon Optimization Service von Azure stellt einen bedeutenden Fortschritt dar, der die schwierige Aufgabe der Emissionsmessung in ein leichter zugängliches und umsetzbares Unterfangen verwandelt. Indem wir diesen Service zusammen mit den Prinzipien der Green Software Foundation nutzen, können wir den Weg zu Energieeffizienz, Hardware-Effizienz und Kohlenstoffbewusstsein effektiver beschreiten. Mit diesen Tools und Erkenntnissen sind wir zwar noch nicht am Ziel, aber wir sind besser gerüstet, um sinnvolle Änderungen vorzunehmen und unsere Softwarelösungen effizienter und umweltfreundlicher zu gestalten.

Dieser Artikel ist Teil von XPRT.#16. Sie können das Magazin hier herunterladen.

Tauchen Sie tiefer in die Welt der Innovation ein - besuchen Sieunsere Bibliothek'Your Essential Guides to Innovation and Expertise' und greifen Sie auf eine Sammlung von Magazinen und eBooks zu, die Ihr Verständnis von Spitzentechnologie verbessern und Sie zu Ihrer nächsten großen Idee inspirieren werden.