Microsoft hat die nächste Stufe bei der Einstellung von SQL Data Sync gezündet: Seit dem 9. September lassen sich in Azure-Abonnements, die den Dienst bislang nicht genutzt haben, keine neuen SQL-Data-Sync-Bereitstellungen mehr anlegen. Bestehende Nutzer können Sync-Gruppen und Mitgliedsdatenbanken dagegen noch bis zum vollständigen Aus des Dienstes am 30. September 2027 erstellen, ändern und betreiben.

Die Einstellung hatte Microsoft bereits 2024 mit dreijähriger Übergangsfrist angekündigt. SQL Data Sync gleicht ausgewählte Daten zwischen mehreren Datenbanken ab, sowohl zwischen Azure SQL Database als auch mit SQL-Server-Instanzen im eigenen Rechenzentrum. Die Daten können dabei je nach Konfiguration in beide Richtungen fließen. Microsoft beschreibt die Einstellung und die vorgesehenen Migrationspfade in seiner Dokumentation.

Keine Einschränkung für bestehende Abonnements

Die neue Einschränkung trifft ausdrücklich ausschließlich Azure-Abonnements, die SQL Data Sync zuvor nie eingesetzt haben. Für Abonnements, die SQL Data Sync bereits nutzen, ändert sich zunächst nichts: Administratoren dürfen weiterhin Sync-Gruppen anlegen und verwalten sowie Datenbanken als Mitglieder hinzufügen. Microsoft will damit verhindern, dass kurz vor dem Endtermin noch neue Abhängigkeiten von dem auslaufenden Dienst entstehen. Die Details zur nun begonnenen letzten Ausmusterungsphase nennt Microsoft im Azure-SQL-Blog.

SQL Data Sync organisiert die Replikation in Sync-Gruppen nach einem Hub-and-Spoke-Prinzip. Als Hub dient stets eine Azure SQL Database; weitere Azure-SQL-Datenbanken oder SQL-Server-Datenbanken können als Mitglieder teilnehmen. Bei lokalen SQL-Server-Datenbanken ist zusätzlich ein lokaler Sync-Agent nötig. Der Dienst kann Daten in beide Richtungen oder nur vom Hub zu einem Mitglied beziehungsweise umgekehrt übertragen.

Inventur vor der Migration

Microsoft rät betroffenen Organisationen, zunächst alle vorhandenen Bereitstellungen zu erfassen – auch inaktive Sync-Gruppen. Dazu gehören Hub- und Mitgliedsdatenbanken, gegebenenfalls installierte Sync-Agenten sowie die Anwendungen, die auf replizierte Daten angewiesen sind. In kleineren Umgebungen lassen sich die Sync-Gruppen über den Bereich „Sync to other databases“ einer Azure SQL Database im Azure-Portal prüfen. Für größere Azure-Landschaften verweist Microsoft auf die PowerShell und die Azure-SQL-Management-REST-API.

Vor der Umstellung sollten Administratoren außerdem Datenfluss, Synchronisierungsrichtung, Intervall, Datenvolumen sowie Anforderungen an Latenz und Verfügbarkeit festhalten. Das ist wichtig, weil SQL Data Sync kein einheitliches Nachfolgeprodukt erhält. Je nach bisherigem Einsatz kann die Migration eine bloße Umkonfiguration sein oder einen Umbau der Replikationsarchitektur erfordern.

Ersatz hängt vom Einsatzfall ab

Für geplante oder inkrementelle Übertragungen nennt Microsoft Azure Data Factory als Alternative. Das eignet sich etwa, wenn Daten in festen Intervallen für ein Data Warehouse oder einen Reporting-Bestand kopiert werden sollen. Für die einseitige Verteilung von SQL Server zu Azure SQL Database verweist der Konzern auf die transaktionale Replikation.

Geht es vor allem um lesende Replikate oder regionale Verfügbarkeit, kommen etwa aktive Georeplikation und Read Replicas infrage. Für Reporting-Replikate vollständiger Datenbanken nennt Microsoft Always On Availability Groups bei SQL Server auf Azure-VMs sowie Managed Instance Link bei Azure SQL Managed Instance. Daneben führt die Migrationsdokumentation Azure Functions mit Azure-SQL-Triggern für anwendungsspezifische Synchronisation sowie Mirroring in Microsoft Fabric für Analyseumgebungen auf. Welche Variante passt, hängt unter anderem von Quell- und Zielplattform, Datenrichtung, Topologie, zulässiger Verzögerung und Durchsatz ab. Die Migrationsdokumentation enthält dazu eine Übersichtstabelle, die alle Pfade nach Quell- und Zielplattform aufschlüsselt.

Nach erfolgreicher Validierung der Ersatzlösung in einer Nicht-Produktivumgebung empfiehlt Microsoft, die automatische Synchronisierung der bisherigen Gruppe vorübergehend abzuschalten. Erst wenn Anwendungen nicht mehr auf SQL Data Sync angewiesen sind, sollten Unternehmen die alten Ressourcen entfernen. Spätestens zum 30. September 2027 muss der Umstieg abgeschlossen sein.

(fo)

Um Werte zu testen, ohne etwas zu ändern, lässt sich in .NET 10.0 JSON Patch verwenden.

Das folgende Beispiel zeigt die Anwendung der neuen Klasse JsonPatchDocument aus System.Text.Json Version 10.0 auf ein JSON-Patch-Dokument, dass nur aus Test-Operationen besteht:

CUI.H2("Testen mit JSON Patch-Dokument");
string jsonPatchTest = """
[
    { "op": "test", "path": "/FirstName", "value": "Dr. Holger" },
{ "op": "test", "path": "/PrivateEmail", "value": null},
    { "op": "test", "path": "/PrivateWebsite", "value": null},
    { "op": "test", "path": "/Address/ZipCode", "value": "45257" }
]
""";
 
// JSON Patch-Dokument laden
JsonPatchDocument? patchTestDoc = JsonSerializer.Deserialize>(jsonPatchTest);
 
// JSON Patch-Dokument anwenden auf das Person-Objekt
patchTestDoc!.ApplyTo(person, patchError => CUI.PrintError(patchError.ErrorMessage));

In diesem Fall gibt es keine Fehlerausgabe. Wenn man das JSON-Patch-Dokument aber verändert

CUI.H2("Reines Testen eines Objekts mit JSON Patch-Dokument (absichtlich mit drei Fehlern!)");
string jsonPatchTest = """
[
    { "op": "test", "path": "/FirstName", "value": "Dr.Holger" },
    { "op": "test", "path": "/PrivateEmail", "value": null},
    { "op": "test", "path": "/PrivateWebsite", "value": ""},
    { "op": "test", "path": "/Address/ZipCode", "value": "45251" }
]
""";

bekommt man drei Fehlermeldungen:

Dabei ist die Fehlermeldung bei 'PrivateWebsite' ungünstig, denn sie unterscheidet nicht zwischen Leerstring und Null. Im Objekt steht null, getestet wird auf Leerstring. In der Fehlermeldung steht jedoch in beiden Fällen ' '.

(rme)

In weniger als vier Monaten sollen die Deutschen ihren Ausweis, Führerschein und vielleicht irgendwann auch ihr Schulzeugnis und den Kaninchenzuchtstammbaum auf dem Smartphone vorzeigen können. Eine Brieftasche als App halt. Ein echter, guter Fortschritt – den die EU ja auch erzwingt. Angesichts des offensichtlichen Security-Schabernacks ist das aber auch ein Projekt, das dringend Vertrauen bei den Bürgern aufbauen muss. Der neue Name, den Bundesdigitalminister Karsten Wildberger (CDU) dafür bei einer Veranstaltung in Berlin verkündet hat, lautet: d-you.

Stop mal – d-you. Was ist denn das? Eine Dating-App? Ein Jugendportal? Ein Motivationspodcast? Wer nicht ohnehin schon von der EUDI-Wallet gehört hat, wird daraus niemals schlau und installiert die App schon einmal gar nicht. So wird ein dämlicher Name zu einem unnötigen Problem.

Ein Name ist keine Kosmetik

Natürlich entscheidet kein Name allein darüber, ob eine Technologie bei IT-affinen Nutzern angenommen wird oder nicht. Sicherheit, Datenschutz, einfache Einrichtung und echte Anwendungsfälle zählen da mehr. Aber der Name ist der erste Berührungspunkt für den Otto-Normal-Bürger. Der kommt dann noch nicht einmal zum Download, liest den verklausulierten Datenschutzhinweis oder erkundet die tollen Funktionen in der App. Ein guter Name beantwortet schon davor und in Millisekunden die Frage: Worum geht es hier, und ist das etwas für mich?

Die Technikakzeptanzforschung weiß das seit Jahrzehnten. Fred Davis zeigte bereits 1989 in seinem Technology Acceptance Model, dass Menschen neue Technologien vor allem dann nutzen, wenn sie deren Nutzen verstehen und sie als leicht handhabbar wahrnehmen. Spätere Forschung ergänzte soziale Einflüsse und Rahmenbedingungen. Was all diese Modelle gemeinsam haben: Der erste kognitive Eindruck zählt. Und im Gegensatz dazu erzeugt ein Name, der keine Orientierung gibt, Reibung – und zwar noch bevor jemand die Funktionen der App überhaupt wahrgenommen hat.

Leer, nicht nur englisch

Die berechtigte Kritik an d-you ist keine Kulturkritik an Anglizismen. Kunstnamen können funktionieren. Apple erklärt keine Computer, O2 erklärt keinen Mobilfunk. Aber private Marken kaufen sich über Jahre Bedeutung ein: durch Werbung, durch Nutzung, durch Wiederholung. Eine staatliche Identitätsinfrastruktur startet unter anderen Bedingungen. Sie und das Technikkonzept sind für die Bürger neu. Sie berührt sensible Daten. Und sie muss von möglichst vielen Menschen verstanden und genutzt werden, damit sie sich durchsetzt. Dafür genügen nicht nur wenige Early Adopter, die sich ohnehin für digitale Verwaltung interessieren.

d-you ist dabei nicht einmal ein besonders starker Kunstname. Das „d“ könnte für Deutschland stehen, muss es aber nicht. „you“ verspricht Individualität, sagt aber nichts über die Funktion. Der Bindestrich macht die Schreibweise erklärungsbedürftig. Und die Aussprache? „Di-ju“? „Dü“? In Behördenbriefen, Suchmaschinen und mündlicher Weitergabe werden schon bald Varianten kursieren. Vor allem aber: Kein Wort im Namen verrät, dass es hier um Ausweis, Nachweise oder digitale Identität geht. d-you ist also nicht zu Englisch, sondern zu leer.

Die Metapher, die man weggeworfen hat

Mein Gegenvorschlag: schlicht „Digitale Brieftasche“ und gut ist. Das ist technisch gesehen natürlich keine perfekte Bezeichnung. Eine Brieftasche liegt in der Tasche, ist offline, gehört einem allein. Und eine staatliche Wallet ist Software, Sicherheitsarchitektur und Schnittstelle zu Behörden und Unternehmen zugleich. Die EU-Kommission beschreibt die EUDI-Wallet als Ort für digitale Identitätsdaten und attestierte Nachweise. Die Metapher hängt sich also in vielen Details auf.

Aber sie stimmt im Wesentlichen: Eine Brieftasche verwahrt persönliche Dokumente, gibt sie auf Nachfrage vor und bleibt unter der Kontrolle ihres Besitzers. Das ist genau das, was die Wallet verspricht. Die Metapher ist eben ein brauchbarer Einstieg. Und genau deshalb hätte man sie nicht durch einen Fantasienamen ersetzen müssen.

Wildberger betonte bei der Vorstellung, wie wichtig ihm Kontrolle und Transparenz für die Bürgerinnen und Bürger seien. Das ist das offensichtlich richtige Versprechen. Aber wer Datensouveränität verspricht, sollte nicht mit sprachlicher Intransparenz beginnen.

(fo)