Vollständige technologische oder digitale Souveränität lässt sich nach Einschätzung von Gartner derzeit kaum außerhalb der USA und Chinas erreichen. Ursachen dafür sind die Dominanz der großen Hyperscaler sowie anhaltende Abhängigkeiten bei Infrastruktur, Plattformdiensten und Lieferketten. Darauf wies Gartner-VP-Analyst Douglas Toombs auf der Konferenz „IT Infrastructure, Operations & Cloud Strategies“ in Sydney hin.

Geopolitische Spannungen, regulatorische Unsicherheiten und die starke Marktstellung US-amerikanischer Cloudanbieter haben die Debatte um digitale Souveränität zuletzt weiter angeheizt. Vor allem in Europa suchen Unternehmen und Behörden nach Wegen, ihre Abhängigkeit von US-Hyperscalern zu verringern und Datenhoheit sowie regulatorische Kontrolle abzusichern.

Mehr als nur der Speicherort der Daten

„Derzeit gibt es keine geeigneten nicht-US-amerikanischen Alternativen zu den großen Hyperscalern – außer in China, wo der Schutz geistigen Eigentums Bedenken aufwirft“, erklärte Toombs laut den von Gartner veröffentlichten Konferenz-Highlights. Echte technologische Souveränität sei daher außerhalb dieser beiden Länder zurzeit nicht möglich.

Gartner meint damit nicht nur, wo Daten physisch liegen. Technologische Souveränität umfasse auch die Kontrolle über Cloud-Infrastruktur, Management-Software, Sicherheitsmechanismen, Supportprozesse und die zugrunde liegenden Lieferketten. Selbst lokal betriebene Varianten globaler Cloudplattformen blieben meist technisch und organisatorisch an ihre Anbieter gebunden.

Gleichzeitig beobachtet Gartner eine wachsende Nachfrage nach Kontrolle, Portabilität und digitaler Autonomie. Unternehmen müssten sich gegen Risiken wie regulatorische Änderungen, Sanktionen, Sicherheitsvorfälle oder Ausfälle einzelner Anbieter wappnen. In Europa prägen seit Jahren vor allem mögliche Zugriffe US-amerikanischer Behörden auf Daten europäischer Kunden die Diskussion, etwa über den Cloud-Act oder FISA-Regelungen.

Exit-Strategien als blinder Fleck

Besonders kritisch sieht Gartner die fehlenden Exit-Strategien vieler Cloudkunden. Organisationen müssten klar festlegen, unter welchen Bedingungen sie einen Anbieter verlassen. Wer das versäume, schaffe Folgeprobleme und bringe seine Teams in eine kaum lösbare Lage, warnte Toombs. Nötig seien konkrete Auslöser, feste Budgets und realistische Zeitpläne.

Ein Cloud-Exit beschränkt sich dabei nicht auf den Export von Daten. Vor allem cloudnative Anwendungen, proprietäre Plattformdienste und eng integrierte PaaS-Angebote erschweren einen Wechsel erheblich. Migrationen komplexer Unternehmensanwendungen ziehen sich laut Gartner häufig über mehrere Jahre.

Als Strategien nennt Gartner Sovereign-Cloud-, Hybrid- und Multicloud-Ansätze. Hinzu kommen Konzepte wie „Shelter in Place“, bei dem Unternehmen trotz bekannter Risiken bewusst bei ihrem bisherigen Anbieter bleiben, oder „Hide in Plain Sight“, bei dem sie sensible Daten und Workloads stärker segmentieren oder verschlüsseln.

US-Hyperscaler und europäische Antworten

Die großen US-Anbieter versuchen derweil aktiv, ihre Kunden mit eigenen, als souverän beworbenen Angeboten für Europa zu halten. AWS baut etwa an einer „European Sovereign Cloud“ mit eigenständigen EU-Strukturen und zusätzlichen Compliance-Zusagen. Parallel treiben europäische Anbieter und Behörden eigene Initiativen voran, darunter Projekte von Schwarz Digits sowie Kooperationen mit dem BSI für souveräne Cloud- und Sicherheitslösungen sowie ein gemeinsames Notsystem europäischer Anbieter für den Fall einer Cloudabschaltung.

(fo)

Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind.

Nachdem der erste Teil gezeigt hat, wie man in Java eine in C geschriebene Shared Library lädt und einfache Funktionen dieser Shared Library aufruft, geht es jetzt um komplexere Szenarien. Er zeigt, wie man aus Java Funktionen mit veränderbaren Parametern aufrufen und Arrays sowie Strukturen übergeben kann.

Funktionen mit veränderbarem Parameter

Die bisherigen Beispiele haben die Aufrufe der nativen Funktionen einfach gehalten. Die Java-Anwendung hat lediglich Parameter durchgereicht und den Rückgabewert übernommen.

Anders sieht es bei den nächsten Beispielen aus. Als erstes folgt die einfache C-Funktion getVersion2, die wie die Funktion getVersion aus Teil 1 die Version der Library ermittelt. Die neue Funktion gibt die Versionsnummer aber nicht als Wert zurück, sondern verändert dazu einen Parameter. Das funktioniert in C, indem eine Anwendung für einen Parameter nicht den Wert selbst, sondern dessen Adresse übergibt (Call by Reference). Dieses Konstrukt sieht in C folgendermaßen aus:

EXPORT void   getVersion2(int* version);

Folgender Java-Code ruft die Funktion auf:

int version;
getVersion2(&version);

Das & kennzeichnet in C, dass die Funktion die Adresse der Variablen nutzt. Java erlaubt das Vorgehen nicht, sodass ein Rückgabewert unerlässlich ist. Folgende Java-Methode verwendet die C-Funktion mit Referenz:

public int getVersion2() throws Throwable
{
  MethodHandle method = getMethodHandle("getVersion2",   
     FunctionDescriptor.of(
				ValueLayout.JAVA_INT, 
				ValueLayout.ADDRESS
				));
  try (Arena arena = Arena.ofConfined())
  {
    MemorySegment versionSeg =   
      arena.allocate(ValueLayout.JAVA_INT.byteSize());
    method.invoke(versionSeg);
    int version = versionSeg.get(ValueLayout.JAVA_INT, 0);
    return version;
  }
}

Zuerst ruft der Code wie im ersten Teil der Serie wieder die Methode getMethodHandle() auf. Der Aufruf definiert den FunctionDescriptor für die Funktion getVersion2().

Die Angabe ValueLayout.ADDRESS für den Parameter zeigt an, dass die C-Funktion eine Adresse erwartet.

Jetzt kommt der spannendere Teil: Um eine Adresse übergeben zu können, muss die Java-Anwendung mittels der FFM-API einen Speicherbereich von vier Byte (für den Datentyp int) reservieren. Das geschieht mit einer Arena, die er erste Teil bereits erläutert hat. Das Erzeugen der Arena mit dem try-with-ressources-Statement stellt sicher, dass die Arena nach dem try-Block automatisch geschlossen und der darin verwaltete Speicher automatisch freigegeben wird. Es gibt verschiedene Typen von Arenas – die im Beispiel über ofConfined erzeugte sorgt dafür, dass die Anwendung nur auf Speicher des aktuellen Thread zugreifen kann. Eine mit ofConfined() erzeugte Arena – beziehungsweise der damit allozierte Speicher – ist daher nicht threadsicher.

Als nächstes gilt es, den erforderlichen Speicherbereich für den Parameter version zu allokieren. Dafür besitzt die Arena die Methode allocate(). Die Größe des benötigten Speichers kann man durch die Funktion byteSize() für die Variable ermitteln. Hier sei nochmals darauf hingewiesen, dass der Wert die Größe des Java-Datentyps darstellt und nicht zwingend etwas über den C-Datentyp aussagt. Da die C-Funktion einen int-Parameter entgegennimmt, sind wir auf der sicheren Seite, da int in C stets vier Byte umfasst. Bei einem long-Wert in C hängt die Größe dagegen von der Plattform ab.

Der Speicherbereich wird durch ein MemorySegment dargestellt, das beim Aufruf der Methode invoke an die C-Funktion weitergereicht werden muss.

Anschließend kann die Anwendung das Ergebnis auslesen. Dazu ruft sie auf dem MemorySegment die Funktion get auf und übergibt ihr das Layout des Speichers (in diesem Fall ein JAVA_INT) und den Offset zum Lesen aus dem MemorySegment. Für das Beispiel ist der Offset null. Durch die Angabe JAVA_INT gibt die Funktion einen int-Wert zurück, den die Anwendung weiterverarbeiten kann.

Funktionen mit einem Array-Parameter

Die nächste Aufgabe baut auf dem Vorgehen auf, verarbeitet aber nicht nur einen Wert, sondern ermittelt den Durchschnitt aus einer Liste von int-Werten. Dazu muss sie der nativen Funktion ein Array von int-Werten übergeben:

public double calcAverage(int [] values) throws Throwable
{
  MethodHandle calcAverage =  
     getMethodHandle("calcAverage"),
	    FunctionDescriptor.of(
	    ValueLayout.JAVA_DOUBLE,     // return value 
	    ValueLayout.ADDRESS,         // data values 
	    ValueLayout.JAVA_INT));      // number of elements

  try(Arena arena = Arena.ofConfined())  
  {
    long totalSize = ValueLayout.JAVA_INT.byteSize() * values.length;
    MemorySegment valueSegment = arena.allocate(totalSize);
    for (int i = 0; i < values.length; i++) 
    {
      valueSegment.setAtIndex(ValueLayout.JAVA_INT, i, values[i]); 
    }
    double result = (double) calcAverage.invoke(valueSegment, 
                                                values.length);
    return result;
  }
}

Zunächst berechnet der Code die gesamte Speichergröße des Arrays (totalSize) und reserviert den benötigten Speicher mit allocate(). Anschließend belegt der Code den Speicher mit der Methode setAtIndex für das jeweilige MemorySegment. Der Aufruf erfolgt für jedes Element des Arrays.

Schließlich ruft der Code die Methode invoke für den MethodHandle auf und übergibt ihr als Parameter das Array und dessen Länge. Schließlich gibt sie das Ergebnis der C-Funktion zurück.

Ende dieses Jahres werde es schätzungsweise nur noch 25,6 Millionen Prepaid-Karten in Deutschland geben und damit rund sieben Prozent weniger als 2025, heißt es in einer Marktstudie des Internet-Branchenverbandes VATM. In den vergangenen beiden Jahren waren die Rückgänge mit neun beziehungsweise zehn Prozent noch kräftiger ausgefallen. Im Jahr 2023 hatte es im Bundesgebiet den Angaben zufolge noch 33,6 Millionen Prepaid-Sim-Karten gegeben. Ein Teil dieser Handys schlummert ungenutzt in den Schubladen.

Bei Prepaid-Karten zahlt der Nutzer vorab Geld ein, damit er eine Handyverbindung bekommt. Ist das Guthaben aufgebraucht, ist Schluss. Anders ist es bei „Postpaid“. Hierbei unterschreibt man einen Vertrag und zahlt dann im Monatsrhythmus Geld. Solche SIM-Karten sind im Aufwind, laut der vom VATM in Auftrag gegebenen Studie des Beratungsunternehmens Dialog Consult werden es am Jahresende in Deutschland 88 Millionen Postpaid-Karten sein und damit fünf Prozent mehr als ein Jahr zuvor. Auch hier gibt es schon seit längerem einen Anstieg, 2023 waren es nur 72,2 Millionen gewesen.

Flatrates lassen Interesse an Prepaid sinken

„Der klassische Postpaid-Vertrag ist weiter auf dem Vormarsch“, sagt Marktforscher Andreas Walter von Dialog Consult. Er begründete die Entwicklung mit der „Reife des Marktes“. Die Verträge seien heute fair ausgestaltet und das Misstrauen der Kunden geringer als früher. „Die Kunden erleben keine bösen Überraschungen mehr, was die höhere Rechnung angeht – sie brauchen sowieso jeden Tag Datenübertragung.“ Ganz früher habe der Prepaid-Anteil bei mehr als 50 Prozent gelegen, inzwischen seien es nur noch 22,5 Prozent. Sei es früher im Wesentlichen um Anrufe gegangen, so gehe es inzwischen vor allem um Datenübertragung.

VATM-Präsidentin Valentina Daiber sagte, man lebe im „Zeitalter von Flatrates“ und der Kostenkontroll-Effekt sei nicht mehr nötig. Damit meinte sie, dass sich früher viele Menschen ganz bewusst für eine Prepaid-Karte entschieden, weil damit eine finanzielle Grenze gezogen war: Waren die 10 Euro abtelefoniert, brach die Verbindung ab. Bei Postpaid-Verträgen konnte es hingegen sein, dass dem Handynutzer die Kosten eines Anrufs erst im Nachhinein bewusst wurden und er mit der Monatsabrechnung gewissermaßen eine böse Überraschung erlebte.

(dahe)