EU-Data Act für Digitale Dienste

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Massgeblich ist immer das im Mitschnitt gesprochene Wort.

Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute spreche ich mit Daniel Bornkessel. Hallo.

Daniel Bornkessel: Hallo.

Anja Kammer: Heute reden wir über die EU-Datenverordnung und was das für den Vendor Lock-in bedeutet. Also, was muss ich tun, wenn ich den Cloud-Anbieter wechseln möchte? Daniel, erzähl doch mal, wer bist du, was machst du und warum hast du dich mit dem Thema beschäftigt? Du hast ja auch einen Artikel dazu geschrieben.

Daniel Bornkessel: Genau. Mein Name ist Daniel Bornkessel. Ich bin Senior Consultant, schon verrückte 10 Jahre bei INNOQ. Meine Hauptthemengebiete sind Infrastruktur, Cloud, also DevOps im weitesten Sinne, DevSecOps und auch Continuous Integration und Continuous Delivery. Ich habe im Sommer einen Artikel über den EU Data Act oder die EU-Datenverordnung geschrieben, weil wir bei INNOQ ein Tech Briefing über digitale Souveränität geschrieben haben, können wir vielleicht auch hier verlinken.

Daniel Bornkessel: Ich hatte zwei Wochen die Ehre, den Chefredakteur zu vertreten, der damals im Urlaub war. Dabei habe ich mich mit dem Thema etwas mehr beschäftigt. Ein Kollege hat mich auf den EU Data Act aufmerksam gemacht und sagte, dass Unternehmen wie AWS die Exit-Kosten extrem senken müssen, beziehungsweise das sonst machen müssten. Das habe ich ihm nicht geglaubt, habe mir das durchgelesen, und er hatte natürlich recht. Dann dachte ich, das ist ein interessantes Thema, da kann ich auch mal einen Artikel drüber schreiben.

Anja Kammer: Ja, spannend. Also, ist es denn wirklich so, dass der Wechsel zwischen Cloud-Anbietern wirklich nichts kostet? Ich meine, es kostet ja doch organisatorisch Zeit und Aufwand, aber gab es denn überhaupt jemals Wechselkosten? Ich kann mich nicht daran erinnern, dass es jemals Wechselkosten gab.

Daniel Bornkessel: Doch, genau. Es gibt sie beziehungsweise gab sie noch ein bisschen. Es gibt natürlich die Kosten, die entstehen, wenn ich als Firma oder als Team weg migrieren möchte und meine Software anpasse. Aber es gab bei AWS zum Beispiel, wenn man sehr viele Daten auf S3 liegen hatte, sogenannte Egress Costs. Das heißt, wenn ich meine ganzen Daten aus AWS in ein anderes System überführen möchte, muss ich dafür bezahlen, wenn ich meine Daten raus migrieren möchte. Das waren wirklich Kosten, die, wenn man super viele Daten hatte, zum Beispiel sehr viele Medien, Videos oder Audio-Dateien, dann waren diese Kosten schon ziemlich hoch.

Anja Kammer: Im S3-Fall, sind das spezielle Egress-Kosten gewesen, weil man weg migrieren möchte, oder sind das die normalen Datenabrufkosten, die S3 sonst hatte?

Daniel Bornkessel: Da bin ich jetzt gerade überfragt. Ich glaube, sie waren noch höher, aber selbst wenn es einfach die normalen Kosten sind, wenn man sehr viele Daten hat und diese alle raus migrieren muss, dann entstehen auf jeden Fall super viele Kosten.

Anja Kammer: Okay.

Daniel Bornkessel: Das ist aber nur ein Teil vom EU Data Act. Der regelt relativ viel, und das ist ein Teil, der für uns natürlich sehr interessant ist, wenn man viel Infrastruktur betreibt. Er regelt aber noch andere Dinge. Es geht im Allgemeinen darum, dass Daten, die Personen erzeugen, für diese Personen auch zugänglich sein müssen. Dazu gehören, für uns jetzt hauptsächlich Cloud-Themen, aber nur der Vollständigkeit halber, auch viele IoT-Devices. Sprich, wenn meine Heizung zu Hause Sensordaten erzeugt, dann muss es möglich sein, diese Daten auch abzurufen. Das war bis jetzt nicht möglich. Man möchte damit verhindern, dass einzelne Firmen mehr oder weniger ein Datenmonopol aufbauen und es quasi nicht mehr möglich ist, aus diesen Systemen rauszukommen, weil es entweder gar nicht möglich oder viel zu teuer ist.

Anja Kammer: Für Privatpersonen war ja schon vorher der Abruf aller Daten über die EU-Datenschutzgrundverordnung möglich, nicht wahr? Das ist also schon etwas Spezielles jetzt.

Daniel Bornkessel: Genau. Nein, man muss hier tatsächlich etwas unterscheiden. Es gibt einmal die Datenschutzgrundverordnung; das sind persönliche Daten, auf die man ein Recht hat, sie zu bekommen. Das heißt, ich muss eine Firma anschreiben und fragen, welche Daten warum bei mir gespeichert werden, um dann einen Abzug zu bekommen. Hier geht es auch tatsächlich um Daten, die gar nicht personenbezogen sind. Klar, wenn ich jetzt auf das Heizungsbeispiel zurückkomme, könnte man vielleicht sagen, die sind etwas personenbezogen, weil sie an meinem Haushalt hängen, aber es geht hier allgemein um Daten, die von Sensoren erzeugt werden, und die müssen nicht grundsätzlich personenbezogen sein. Von daher regelt das eine andere Art von Daten als die DSGVO.

Anja Kammer: Das Ganze.

Daniel Bornkessel: Entschuldigung. Das Ganze kann sich zum Teil auch überschneiden, und wenn nicht ganz sicher ist, ob hier der EU Data Act oder die DSGVO greift, hat die DSGVO auf jeden Fall immer Vorrang.

Anja Kammer: Okay, du hattest gesagt, es gibt noch mehr Inhalte in der EU-Datenverordnung. Ist da noch mehr drin?

Daniel Bornkessel: Genau, der Data Act regelt, welche Daten zugreifbar sein müssen, wie sie zugreifbar sein müssen und auch, dass sie automatisiert verarbeitbar sein müssen. Das ist hier etwas anders als bei der DSGVO, wie gesagt. Bei der DSGVO kann ich beantragen, welche persönlichen Daten bei mir gespeichert werden, und dann bekomme ich quasi einen Snapshot zugeschickt.

Anja Kammer: Aber es muss doch maschinenlesbar sein, glaube ich, nicht wahr? Also es.

Daniel Bornkessel: Ich bin bei der DSGVO jetzt gar nicht so sicher. Ich habe das mal bei Facebook gemacht. Da hat man im Prinzip ein Directory, ich glaube mit HTML-Dateien, bekommen. Ich bin da nicht so ganz sicher. Auf jeden Fall ist beim EU Data Act die Vorschrift, dass es maschinenlesbar sein muss.

Daniel Bornkessel: Und wenn möglich auch automatisiert und in Echtzeit abrufbar. Das ist vielleicht nicht überall möglich, aber es steht – und das ist auch das, was etwas schwammig ist, da der EU Data Act ganz neu ist – dass er am 1.11.2024 in Kraft getreten ist und die ersten Regelungen jetzt seit Dezember dieses Jahres in Kraft getreten sind.

Anja Kammer: 2025.

Daniel Bornkessel: Bitte?

Anja Kammer: 2025.

Daniel Bornkessel: Genau, der ist seit 2024 in Kraft, und seit September 2025 sind die ersten Regelungen wirklich scharf geschaltet. Das heißt, wenn wir auf das Beispiel von AWS S3 zurückkommen, sind die Egress-Kosten für AWS jetzt auch schon tatsächlich ziemlich gesunken. Zurzeit ist es noch so, dass die Kosten so niedrig sein müssen, wie die Kosten, die tatsächlich für AWS anfallen.

Anja Kammer: Anfallen. Okay, sie sind auf jeden Fall sehr niedrig, also sollten sie niedrig sein.

Daniel Bornkessel: Genau, sie sind jetzt sehr niedrig, müssen aber ab 2027 tatsächlich kostenlos sein. Das heißt, dann kann AWS tatsächlich keine Kosten mehr berechnen, wenn ich in ein anderes System ziehen möchte. Was auch tatsächlich sehr interessant ist – wir beziehungsweise ich schaue oft aus der Entwicklerbrille darauf. Super interessant ist auch, da wir uns eben über Daten unterhalten haben: Ab 2027 müssen auch aktuell bestehende Verträge den EU Data Act erfüllen. Sprich, wenn ich jetzt einen Vertrag habe, der bis 2030 festgezurt ist, und ich Egress machen möchte, dann muss ich relativ viel bezahlen oder ich komme an die Daten nicht heran. Das ist durch den EU Data Act hinfällig, da diese Teile dann durch den EU Data Act überschrieben werden. Das heißt, für alle, die sich um die Verträge kümmern – CIOs oder je nachdem, wer das in der Firma macht – ist es auf jeden Fall interessant, sich alte Verträge anzugucken. Wenn man wirklich überlegt hat, aus einer bestimmten Public Cloud oder einem bestimmten Service rauszuziehen, und das bisher aufgrund von Kosten oder fehlendem Zugriff verworfen hat, lohnt es sich, bestehende Verträge eventuell zu überprüfen. Das kann auf jeden Fall auch ein interessanter Aspekt sein durch den EU Data Act.

Anja Kammer: Was bringt mir die Überprüfung? Was genau kann ich daraus lesen?

Daniel Bornkessel: Na ja, ich hatte es tatsächlich schon im Projekt: Wir hatten super viele Daten, es ging um viele Petabyte, und da war immer die Aussage, wir können überhaupt nicht von S3 weg, weil die Kosten so dermaßen hoch sind. Und wenn das die Argumentationslinie bisher war, dann lohnt es sich, alte Argumentationsmuster zu überprüfen, wenn es sich tatsächlich A um die hohen Egress-Kosten handelt oder B man eventuell an Daten gar nicht herankommt, die jetzt durch den EU Data Act zur Verfügung gestellt werden müssen. Das Datum steht fest: Das passiert im September 2027. Das heißt, man muss dann auch nicht bis zum 30. August warten, sondern kann jetzt schon vielleicht anfangen zu planen, da ab 2027 die Daten beziehungsweise die Kosten wegfallen. Es kann also durchaus interessant sein.

Anja Kammer: Und vor allem auch die Verträge zu ändern, wenn sie nicht mehr konform sind nach der EU-Verordnung.

Daniel Bornkessel: Genau, ich weiß jetzt aber gar nicht, wie das vonstattengeht, ob einzelne Teile dann quasi im Vertrag hinfällig sind und einfach dem EU Data Act entsprechen müssen oder ob sie dann neu ausgehandelt werden. Das Prozedere ist mir da unsicher. Aber für alle, die vielleicht dieses Problem haben, können sich das im Hinterkopf behalten und sich vielleicht noch mal genauer erkundigen, ob das jetzt wirklich ein interessantes Thema ist, mit dem sie sich schon beschäftigen wollen, weil 2027 gar nicht mehr so weit weg ist – das sind anderthalb Jahre.

Anja Kammer: Ja, vor allem für alle digitalen Dienste, nicht wahr? Es kann sein, dass Unternehmen viele digitale Dienste nutzen, nicht wahr?

Daniel Bornkessel: Ja, genau. Das kann für manche schon sehr interessant sein.

Anja Kammer: Und was soll die EU-Datenverordnung damit bezwecken? Soll es wirklich darum gehen, die Monopolstellung von EU- oder US-Cloud-Anbietern zu durchbrechen, oder was ist das Ziel hier gewesen?

Daniel Bornkessel: Ja, genau, du sagst es ja gerade schon: Monopolstellung. Wir haben jetzt kein Monopol, was AWS und die Public Clouds allgemein angeht. Ich würde es eher so sehen – mathematisch schon gar nicht – aber wir haben eigentlich drei große Public Cloud-Anbieter, und alle drei sind amerikanisch: sprich AWS, Microsoft Azure und Google Cloud. So richtig verlässliche Zahlen gibt es nicht. Was ich herausgefunden habe, war zwar nur halbseriös, aber es werden auf jeden Fall um die 66 % ungefähr sein. Das habe ich ein paarmal gelesen. Aus persönlichen, anekdotischen Erfahrungen hätte ich das sogar noch höher eingeschätzt, weil die meisten Kunden, bei denen ich bin, AWS oder Azure nutzen.

Anja Kammer: Also die deutschsprachigen Kunden.

Daniel Bornkessel: Genau. Ja, wir sind in Deutschland hauptsächlich unterwegs, selten in Österreich. Wir haben einen Anteil von ungefähr zwei Dritteln, würde ich sagen. Wir haben da ein Oligopol.

Anja Kammer: Und was ist mit dem anderen Drittel? Was sind das für Cloud-Anbieter? Sind das EU-Cloud-Anbieter oder sind das eigene Rechenzentren? Wie sieht es da aus?

Daniel Bornkessel: Das ist so ein bisschen die Frage, die ich hatte. Ich hätte gerne eine Statistik gehabt, das Ganze aufgeschlüsselt, aber das ist tatsächlich gar nicht so leicht feststellbar. Es gibt natürlich europäische Anbieter. Die Franzosen haben Scaleway und OVH Cloud. In Deutschland gibt es Ionos, die Schwarz IT von Lidl, die eine relativ große Cloud haben, und die Open Telekom Cloud. Wie groß die Anteile sind, weiß ich aber tatsächlich nicht. Der EU Data Act versucht jetzt, AWS ist ein super System. Wer schon mal mit AWS gearbeitet hat, kennt die vielen Infrastructure-as-a-Service-Angebote, und man wird nach und nach immer tiefer reingezogen. Das heißt, es gibt proprietäre Services, die man nach und nach benutzen möchte, und häufig kommt irgendwann der Zeitpunkt, wo die AWS-Rechnung relativ hoch wird. Ich habe das auch schon in eigenen Projekten gesehen: Man macht ein Proof of Concept, dann ist das alles sogar günstig, und wenn man in Produktion geht, ist die Rechnung ziemlich schnell fünfstellig.

Anja Kammer: Ich glaube, wir beide sind uns einig, dass die Public Cloud auf jeden Fall teurer ist als ein eigenes Rechenzentrum, zumindest im Betrieb, nur der Betrieb an sich, oder?

Daniel Bornkessel: Es ist relativ schwer. Public Cloud ist erstmal schön, wenn man einfach anfangen kann. Man muss sich keine eigenen Maschinen kaufen, und man hat natürlich die Leute, die man braucht, um ein Rechenzentrum am Laufen zu halten, externalisiert. Das heißt, man bezahlt das einfach mit ab. Man braucht die Leute zum Teil nicht einzustellen, außer die DevOps-Leute, die das Ganze aufsetzen. Von daher ist es relativ schwer. Und das macht es auch attraktiv, mit AWS, Azure oder Google anzufangen, weil man mit relativ wenig Vorabinvestition ein System aufsetzen kann – vorausgesetzt, man hat schon ein bisschen Erfahrung. Man schaufelt dann die Daten ins S3 rein, und irgendwann nach zwei Jahren, wenn man den Luxus hat, dass es gut läuft, ist die S3-Rechnung auf einmal sehr hoch. Und dass man dann dort in AWS gefangen ist und nicht einfach in andere Systeme umziehen kann ohne extreme Kosten, das ist zum Beispiel eine der Sachen, die der EU Data Act auch ändern möchte, damit man da raus kann.

Anja Kammer: Wie realistisch ist es, dass Unternehmen jetzt sagen: 'Oh wow, jetzt gibt es den EU Data Act, und jetzt können wir endlich wechseln’? Wie realistisch ist es, dass sie das jetzt als Startschuss nehmen?

Daniel Bornkessel: Das ist eine gute Frage. Ich bin auch super gespannt. Ich glaube nicht, dass sich von heute auf morgen etwas ändern wird. Es werden jetzt nicht viele Firmen anfangen, auf einmal das komplette System umzubauen, weil sie die Daten in zwei Jahren quasi kostenlos aus AWS, Azure oder Google herausbekommen. Man kann das aber, wenn man neue Projekte hat, von vornherein mit einplanen, dass man vielleicht sagt: 'Okay, wir fangen mit AWS an, aber unsere Langzeitstrategie ist, ab einer bestimmten Größe, wenn wir es schaffen, diese Größe zu erreichen, dann wirklich auf andere Systeme umzustellen.’ Statt S3 gibt es zum Beispiel von Cloudflare R2 (wobei von S3 auf S2 abgezogen wurde). Die sind auf jeden Fall sehr viel günstiger als AWS, und es gibt auch viele EU-Anbieter; die meisten Anbieter in der EU sind um einiges günstiger als AWS. Sie haben natürlich auch nicht den gleichen Funktionsumfang. Ich könnte mir schon vorstellen, ich würde es zumindest so machen: Wenn ich ein Produkt neu anfange, würde ich das von Anfang an mit einplanen, dass diese Möglichkeit besteht und auch in der Entscheidung festhalten, dass man sagt: 'Wir gehen mit AWS.’ Es ist am Anfang relativ teuer, beziehungsweise am Anfang erstmal billig, um zu starten, aber absolut gesehen ist AWS schon teurer als viele Services, die es gibt. Aber dass man sagt: 'Langfristig erwägen wir auch den Umzug zu Alternativangeboten.’

Anja Kammer: Das kann die Entscheidung ein wenig erleichtern, so eine Strategie zu fahren. Allerdings gehört viel mehr dazu, den Wechsel zu begünstigen, als nur ein günstigerer Datentransfer. Allein Architektur-Entscheidungen, dass ich proprietäre Services nicht nutze, die es potenziell bei der Zielplattform nicht gibt. Ich glaube, es wäre Augenwischerei, jetzt zu sagen: 'Es gibt kein Vendor Lock-in mehr.’ Das ist Quatsch.

Daniel Bornkessel: Das stimmt. Das stimmt natürlich. Ich hoffe, was passieren wird, und ich glaube, es hat auch schon ein bisschen angefangen in den letzten Jahren, ohne den EU Data Act. Vor 10 Jahren gab es eine Entwicklung, die sich fast anfühlte wie Microsoft in den 90er Jahren: Da haben einfach alle Microsoft genutzt, das hat niemand in Frage gestellt. Und vor 10 Jahren habe ich bei vielen Kunden das Gleiche gesehen: Sie sagten, 'Wir gehen zu AWS, nutzen auch alles, was proprietär ist, und sind uns des Lock-ins bewusst. Wir machen das ganz bewusst so, weil wir AWS möglichst effizient nutzen wollen.’

Anja Kammer: Daniel Bornkessel: Ich sehe jetzt zum Teil schon eine andere Strategie bei einigen Unternehmen, und ich hoffe, dass es in Zukunft zunimmt, dass man eben nicht DynamoDB nutzt, sondern ein Produkt, das überall verfügbar ist. Dass man nicht SQS nimmt, sondern eine andere Queuing-Lösung. Ich bin jetzt immer sehr AWS-spezifisch, weil ich mich mit AWS am besten auskenne. Ich kenne die Äquivalente in Azure und Google jetzt nicht so. Aber dass man weg von den Produkten kommt, die man nutzen will, und wieder zu Architektur-Entscheidungen. Also, wir wollen eine Queuing-Lösung haben, nicht Produkt XY von einem Anbieter nutzen.

Anja Kammer: Das finde ich sehr gut. Die typischen Solution Architects waren oftmals nur diejenigen, die beispielsweise AWS-zertifiziert sind und wirklich nur mit Produktnamen um sich geschmissen haben, statt mit Architekturprinzipien oder Konzepten. Das hat mich schon immer gestört.

Daniel Bornkessel: Das darf man auch nicht vergessen, dass es tatsächlich einige gibt. Ich war auch mal bei einem Kunden, da haben wir Kubernetes eingeführt, und der war dann beim AWS Summit und hatte gesagt, dass Kubernetes gar nichts taugen würde, dass ECS von Amazon viel besser wäre. Ich dachte, okay, das ist ein Solution Architect, aber ein Solution Architect ist eben auch immer ein Verkäufer, weil die natürlich ihr eigenes Zeug verkaufen wollen.

Anja Kammer: Welche Architekturprinzipien könnten helfen, möglichst anbieterunabhängig zu sein? Welche Architekturprinzipien sollte ich mir bewusst sein und implementieren, um gut wechseln zu können? Mir fallen technische Dinge ein, wie auf Containerisierung zu setzen. Das heißt, wenn ich beispielsweise AWS Lambda nutzen möchte, weil ich gerade bei AWS bin, dann sollte ich eher die Container-Variante nutzen. Das bedeutet, Container liefern und Lambda übergeben, denn auch andere Functions-as-a-Service-Lösungen können mit Containern umgehen. Das kann ich auf jeder Plattform laufen lassen, und ich muss dann nicht auf eine Functions-as-a-Service-Lösung gehen, sondern kann auch in einem Kubernetes-Cluster diese Container laufen lassen. Da bin ich sehr flexibel, wenn ich meine Lieferartefakte beispielsweise in Containern ausliefere.

Daniel Bornkessel: Genau. Ich glaube, Container sind heute schon Standard. Functions-as-a-Service ist schwer. Sie haben natürlich auch ihren Platz, weil man diese ganze Infrastruktur – wenn ich jetzt auf Container Kubernetes gehe, habe ich natürlich schon eine Grundinfrastruktur, die läuft. Functions-as-a-Service ist da ein bisschen anders. Eine Exit Readiness zu haben – damit meine ich zum Beispiel, wenn man bei Banken und Versicherungen ist, wird das tatsächlich von der BaFin oder von der EZB verlangt, dass Banken und Versicherungen immer einen sogenannten Exit Plan haben müssen. Das heißt, sie müssen darauf vorbereitet sein, wenn eine Bank komplett auf AWS ist, zu dokumentieren, was passiert, wenn AWS aus Grund XYZ nicht mehr da ist oder sie nicht mehr bedienen möchte, wie sie da rauskommt, wie sie in eine eigene Cloud kommt, wie sie in eine Public Cloud kommt. Von daher wäre so etwas wie eine DynamoDB entweder gar nicht möglich für Banken oder Versicherungen, oder sie müssen ganz genau dokumentieren: 'Wenn wir das nicht mehr nutzen können, nutzen wir etwas anderes.’ Dann braucht man meistens wahrscheinlich schon eine Art Translation Layer dazwischen, was dann auch eine gute Idee ist, damit man darauf vorbereitet ist.

Anja Kammer: Steht darin auch, wie schnell man wechselfähig sein muss? Denn wenn ich ein Jahr dafür Zeit habe, sind das andere Lösungen, die ich betrachten kann, als wenn ich innerhalb von zwei oder drei Wochen wechselfähig sein muss.

Daniel Bornkessel: Meinst du jetzt bei BaFin und EZB? Das weiß ich tatsächlich nicht, wie die Zeiten da sind. Ich glaube, die stehen drin, aber das weiß ich gerade gar nicht, wie die Zeiten da sind. Aber nicht ein Monat oder so, das wäre komplett unrealistisch für eine Versicherung.

Anja Kammer: Wir hatten auch über europäische Anbieter gesprochen. Kannst du mal aus dem Nähkästchen plaudern, welche europäischen Anbieter gut genug sind, um beispielsweise von AWS darauf zu wechseln? Hast du da schon Dinge angeschaut und Erfahrung gesammelt?

Daniel Bornkessel: Ich habe mir schon ein paar angeguckt, aber es war tatsächlich eher Proof-of-Concept-mäßig, weil bei den Kunden, bei denen ich bisher war, tatsächlich entweder eine der drei großen amerikanischen Public Clouds oder On-Premises genutzt wurde. Es gibt aber tatsächlich einige Anbieter, die sehr vielversprechend aussehen. Sie bauen aber alle auf dem gleichen Stack, auf OpenStack, auf, was natürlich auch ein Vorteil sein kann, weil das ganze Setup erstmal relativ ähnlich ist. Bei den Franzosen sind das Scaleway und OVH Cloud. OVH Cloud kennen wir vielleicht sogar vom Hörensagen; die hatten vor ein paar Jahren auch einen großen Ausfall. Das ist vielleicht nicht die beste Werbung. Ich glaube, die sind aber tatsächlich relativ groß; sie haben in Frankreich auch einen ziemlich großen Anteil.

Anja Kammer: Daniel Bornkessel: In Deutschland gibt es die Open Telekom Cloud. Ich habe damit experimentiert und finde, dass das Erstellen eines Accounts etwas hakelig ist, nicht so unkompliziert wie bei AWS und Azure. Dann gibt es Ionos, also quasi 1&1, glaube ich, und die Schwarz IT Cloud Stack IT, die von der Lidl IT stammt. Ich glaube, die haben tatsächlich auch relativ Großes vor. Hetzner ist natürlich bekannt, aber Hetzner ist im Wesentlichen nur Infrastructure as a Service. Das heißt, ich kann dort relativ einfach virtuelle Maschinen hochfahren. Ich glaube, Datenbanken haben die auch, aber meines Wissens bieten die nicht so viele Services an wie die anderen, die ich gerade genannt habe. Die anderen bieten Infrastructure as a Service und normalerweise auch Database as a Service an. Das heißt, ich kann mir meine PostgreSQL-Datenbank dort klicken und muss mir um Backup und so weiter keine großen Sorgen machen, sondern kann das anklicken oder einfach konfigurieren, sodass automatische Backups gemacht werden. Meines Wissens ist das bei Hetzner so nicht möglich. Die haben alle Object Storage, also das S3-Äquivalent. Sie bringen relativ viel mit, und die meisten haben auch ein Kubernetes-Angebot. Wenn ich mich auf Kubernetes verlasse, habe ich ohnehin schon eine relativ gute Exit-Strategie. Kubernetes in Verbindung mit Datenbank-Services ist natürlich bei vielen relativ ähnlich.

Anja Kammer: Was meinst du mit 'ähnlich bei vielen’? Braucht man nur Kubernetes auf dem Datenbank-Service, und dann sind alle Use Cases abgedeckt, oder wie meinst du das?

Daniel Bornkessel: Ja, genau, 'ähnlich bei’ hört sich jetzt gerade ein bisschen komisch an, das stimmt. Aber OpenStack beinhaltet quasi schon relativ viel: wie ich eine virtuelle Maschine hochfahre, wie sie ein Volume, also Plattenplatz, bekommen kann, wie Netzwerk funktioniert, wie virtuelle Netzwerke funktionieren, wie Public Private Clouds innerhalb der virtuellen Netzwerke funktionieren, VPN, Datenbanken. Das ist alles in diesem OpenStack-System enthalten, das Open Source ist und quasi alle in Europa nutzen. Kubernetes gehört jedoch nicht dazu. Das heißt, sie haben alle die gleiche Basis, aber dieser Kubernetes-Teil wird von jeder Firma selbst implementiert.

Anja Kammer: Mhm.

Daniel Bornkessel: Daher unterscheiden sich die Anbieter bei Kubernetes geringfügig. Aber Kubernetes an sich greift dann wieder auf eine Infrastruktur zu, die zwischen allen Anbietern relativ ähnlich ist, weil sie auf derselben OpenStack-Basis aufsetzt.

Anja Kammer: Mhm. Der EU Data Act hat nicht nur Implikationen für die Konsumenten von Cloud-Diensten oder digitalen Diensten, sondern auch für die Anbieter. Auch europäische Anbieter müssen sich natürlich dessen beugen und die Daten genauso zur Verfügung stellen. Was müssen die Anbieter denn jetzt konkret tun?

Daniel Bornkessel: Und vor allem: Bis wann?

Anja Kammer: Wann müssen sie auf jeden Fall alles implementiert haben?

Daniel Bornkessel: Ja, genau, guter Hinweis. Wir freuen uns jetzt, dass wir unabhängig von den großen, bösen Amerikanern werden. Aber wenn ich jetzt eine Firma bin, die Daten sammelt – ich komme jetzt mal wieder auf den Heizungsanbieter zurück: Wir haben bei uns Thermostate an den Heizungen in unserem Mehrfamilienhaus. Das wird einmal im Jahr abgerechnet, und das wird von einer Firma gemacht, die die ganzen Sensoren liest. Diese Firma muss die Daten, die sie liest, dann auch so bereitstellen, dass man sie automatisiert abrufen könnte. Das heißt, bei aller Freude: Wenn ich eine Firma bin, die solche Daten sammelt, muss ich diese Daten demnächst zur Verfügung stellen. Wenn ich ein neues Produkt baue, gilt das ab jetzt, also ab September diesen Jahres. Wenn ich ein existierendes Produkt habe, muss ich diese Daten spätestens ab 2027 zur Verfügung stellen bzw. ab September 2026 überhaupt zur Verfügung stellen können. Und noch mal ganz kurz: Du hast ja eben EU gesagt. Das ist auch interessant: Genauso wie die DSGVO gilt das nicht nur für europäische Unternehmen und auch nicht nur für Europäer, die in Europa wohnen, sondern für alle Firmen, die ihre Dienste auch in Europa anbieten. Das heißt, wie die DSGVO hat das auch internationale Auswirkungen. Und die Strafen sind tatsächlich deftig: Das können bis zu 4 % vom Jahresumsatz des vergangenen Jahres sein. Das ist additiv zur DSGVO. Das heißt, ich glaube, da sind es auch 4 %. Wenn sich das aufaddiert, sind 8 % vom Jahresumsatz auf jeden Fall eine Strafe, bei der man sich als Firma vielleicht überlegt: 'Okay, sollten wir das vielleicht doch machen?’

Anja Kammer: Glaubst du, dass Unternehmen, die digitale Dienste anbieten, sich dessen bewusst sind, dass sie hier etwas tun müssen? Wie bekommen sie mit, dass sie eigentlich darunter fallen?

Daniel Bornkessel: Ja, das kann ich auch gar nicht einschätzen. Ich hatte tatsächlich, bis wir dieses Tech Briefing gemacht haben – das war im Juli, August –, schon mal etwas vom EU Data Act oder von der Datenverordnung gehört, aber es war mir tatsächlich auch nicht so präsent. Ich denke, es ist wahrscheinlich wie bei der DSGVO: Alle versuchen es erstmal zu ignorieren, oder vielleicht weiß man es auch tatsächlich gar nicht. Aber ich denke, es werden immer mehr Artikel darüber erscheinen, und wenn die ersten Strafen sich annähern oder anbahnen, dann wird das schon vielen bewusst werden. Wahrscheinlich wird es auch viele Last-Minute-Implementierungen geben müssen, weil ich irgendwie festgestellt habe, dass das häufig so passiert, dass man es versucht zu ignorieren und dann kurz vorher große Panik ausbricht. Vielleicht gibt es auch noch mal eine Verlängerung oder eine andere Übergangsfrist, aber man muss sagen, die Daten stehen in der Verordnung alle schon fest. Das ist dann nicht einfach so, dass man das dann macht. Aber es ist auch alles ein bisschen schwammig, nicht wahr? Da sind viele Begriffe, die auch erstmal definiert werden müssen. Das heißt, zum Beispiel geht es um Rohdaten, aber es ist gar nicht definiert, was überhaupt Rohdaten sind. Dann gibt es solche Sachen: Es muss in Echtzeit zur Verfügung gestellt werden, wenn es technisch zumutbar ist. Und es gibt relativ viele von diesen Begriffen. Das haben wir, glaube ich, in der EU schon öfter gesehen, dass sie erst dann nachgeschärft werden müssen. Wahrscheinlich probieren erstmal viele Leute, mit so wenig wie möglich voranzukommen und vielleicht auch das so schwer wie möglich zu machen, meine Daten herauszubekommen, weil es natürlich viele auch als Wettbewerbsvorteil sehen, wenn sie die Kunden in ihrem System einsperren können.

Anja Kammer: Ich finde das sehr spannend. Vor allem gibt es vielleicht auch im EU Data Act – es müsste ja eine geben – eine Zeitangabe, bis wann die Daten zur Verfügung gestellt werden müssen. In der EU-Datenschutzgrundverordnung ist es ja so, dass es da auch Fristen gibt: 30 Tage, 60 Tage, je nachdem, welche Art von Daten zur Verfügung gestellt werden müssen. Wie sieht es da mit den Fristen aus? Müssen das wirklich APIs sein, sodass man nahezu in Echtzeit Daten abrufen kann, oder?

Daniel Bornkessel: Ja, bei diesen Dingen ist tatsächlich auch wieder die Zumutbarkeit entscheidend. Eine Echtzeit-API ist erforderlich, wenn es technisch zumutbar ist. Es wird bestimmt auch tatsächlich Fälle geben, wo das vielleicht gar nicht möglich ist, das weiß ich nicht so genau. Aber es geht hier tatsächlich auch um Rohdaten. Wenn intern die Daten super aufbereitet und aggregiert werden, muss das nicht zur Verfügung gestellt werden; es geht hier um die Rohdaten, die gesammelt werden. Es gibt irgendwie, ich glaube, zwei Monate 'Notice’. Ich weiß aber nicht so genau, was damit gemeint ist. Wenn ich das richtig interpretiert habe, müssen diese Daten innerhalb von vier Monaten zur Verfügung gestellt werden.

Anja Kammer: Mhm.

Daniel Bornkessel: Das können wir vielleicht auch noch mal in den Shownotes verlinken, da bin ich jetzt nicht hundertprozentig sicher. Meiner Meinung nach gibt es irgendwie eine 'Notice Period’, dann noch 30 Kalendertage, die sich 'Transition’ nennen, und dann eine 'Retrieval Period’ von weiteren 30 Tagen.

Anja Kammer: Mhm.

Daniel Bornkessel: Das rechne ich jetzt mal zu vier Monaten zusammen. Da bin ich jetzt gar nicht hundertprozentig sicher, das können wir dann aber noch mal verlinken.

Anja Kammer: Ja, allein die Zeit, bis große Datenmengen zur Verfügung gestellt werden können – das ist technisch schon ziemlich aufwendig, nicht wahr? Je nachdem, wie groß die Datenmenge ist, braucht man ja auch eine gewisse Zeit. Ich weiß noch, in einem Unternehmen ging es auch um große Datenmengen, die von einer Festplatte zur anderen transferiert werden mussten. Wir haben es nicht übers Internet gemacht, sondern über einen Boten, weil das viel schneller ging, die Daten über den Boten zu verschicken, als sie irgendwie übers Internet zu transferieren.

Daniel Bornkessel: Genau, ja, das ist technisch auch nicht trivial. Da muss man sich als Firma überlegen: Macht man jetzt wirklich so eine Lösung, klatscht das irgendwie dahin, oder nutzt man das auch wirklich als Möglichkeit, ein internes Datenprodukt zu bauen, das man auch intern nutzen kann? Man hätte dann eine API, mit der man Daten abholen kann, denn intern muss man mit den Daten ja auch arbeiten. Und dann macht man einfach nach außen hin eine spezialisierte API, wo Kunden ihre eigenen Daten abrufen können. Vielleicht kann man das auch wirklich, wenn man ein Unternehmen ist, das die Daten zur Verfügung stellen muss, als Chance sehen, ein gutes Datenprodukt zu entwickeln, wie man das heutzutage mit Data Mesh oder Ähnlichem macht. Dann hat man auch gleichzeitig noch einen Gewinn dazu, den man sonst wahrscheinlich nicht gemacht hätte und der vielleicht nicht so hoch auf der Prioritätenliste gestanden hätte. Aber da man es jetzt ohnehin machen muss, kann man das vielleicht auch als Chance sehen, dass man da mal ordentlich aufräumt und intern gute Datenprodukte baut, wie das heutzutage schon viele machen.

Anja Kammer: Mhm. Das klingt gut, und wir werden auch einen Podcast dazu haben, den wir dann in den Shownotes verlinken. Genau, da geht es auch um Dateninventare, also wie Daten in Unternehmen richtig katalogisiert und sichtbar gemacht werden, Datenflüsse sichtbar gemacht werden, um genau das, was du sagst, aufzubauen: Datenprodukte aufzubauen.

Daniel Bornkessel: Ja, genau das meinte ich. Das kann man dann wirklich auch als Chance sehen, nicht wahr? Vielleicht eine Ausgabe, die man sich lieber gespart hätte, aber wenn man es gut plant, hat man ein internes Datenprodukt oder Dateninventar, wie du gesagt hast, das man auch zum eigenen Vorteil nutzen kann.

Anja Kammer: Mhm. Ja, vielen Dank, Daniel, dass ich mit dir sprechen durfte. Das hat dann doch mehr Implikationen, als man vorher dachte, nicht wahr? Vorher dachte man, dieser EU Data Act hat ja nicht so wirklich viel Inhalt, aber am Ende hört es sich dann doch viel weitreichender an, als man vorher glaubte. Vielen Dank.

Daniel Bornkessel: Okay. Ciao.

Anja Kammer: Tschüss.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Massgeblich ist immer das im Mitschnitt gesprochene Wort.

Wie verändert der EU Data Act Ihre Strategie im Umgang mit Cloud-Anbietern und dem gefürchteten Vendor Lock-in?

Einführung in den EU Data Act und seine Auswirkungen auf Cloud-Exit-Kosten

Anja Kammer und Daniel Bornkessel beleuchten im Podcast die Implikationen des EU Data Act, insbesondere im Hinblick auf den Vendor Lock-in bei Cloud-Anbietern. Daniel, Senior Consultant bei INNOQ, erklärt, dass er sich mit dem Thema befasst hat, nachdem ein Kollege ihn auf die potenziellen Auswirkungen auf die Exit-Kosten bei Cloud-Anbietern wie AWS aufmerksam machte. Er bestätigt, dass es in der Vergangenheit tatsächlich erhebliche Kosten für den Datentransfer aus der Cloud gab, die sogenannten Egress Costs. Diese Kosten konnten bei großen Datenmengen, wie sie beispielsweise bei Medienarchiven anfallen, einen Wechsel des Anbieters unattraktiv machen. Der EU Data Act zielt darauf ab, diese Hürden abzubauen und den Zugang zu Daten zu erleichtern.

Haben Sie in Ihren Projekten bereits hohe Egress Costs erlebt, die einen Wechsel des Cloud-Anbieters unattraktiv machten? Welche Rolle spielen diese Kosten bei Ihren aktuellen Architektur- und Migrationsentscheidungen?

«Das waren wirklich Kosten, die, wenn man super viele Daten hatte, wenn man zum Beispiel sehr viele Medien hat, Videos oder oder Audio-Dateien, dann waren diese Kosten schon ziemlich hoch.»

Umfang und Abgrenzung zur DSGVO

Daniel erläutert, dass der EU Data Act einen breiteren Anwendungsbereich hat als die Datenschutz-Grundverordnung (DSGVO). Während die DSGVO den Schutz und den Zugang zu personenbezogenen Daten regelt, befasst sich der Data Act mit einem umfassenderen Spektrum von Daten. Dazu gehören auch Daten, die von IoT-Geräten oder Sensoren erzeugt werden und nicht notwendigerweise personenbezogen sind, wie beispielsweise Sensordaten einer Heizungsanlage. Das übergeordnete Ziel ist es, die Entstehung von Datenmonopolen zu verhindern und den Zugriff auf diese Daten zu ermöglichen, selbst wenn sie nicht direkt einer Person zugeordnet werden können. Bei möglichen Überschneidungen zwischen beiden Verordnungen hat die DSGVO stets Vorrang.

Wie unterscheiden Sie in Ihren Systemen zwischen personenbezogenen Daten (DSGVO-relevant) und anderen generierten Daten (Data Act-relevant)? Welche neuen Herausforderungen ergeben sich für Ihre Datenarchitektur, wenn Sie auch nicht-personenbezogene Sensordaten zugänglich machen müssen?

«Hier geht es auch tatsächlich um Daten, die gar nicht Personen gebunden sind. Also klar, wenn ich jetzt auf das Heizungsbeispiel zurückkomme, könnte man vielleicht sagen, okay, die sind ein bisschen Personen gebunden, weil sie an an meinem Haushalt hängen, aber es geht hier allgemein um Daten, die von irgendwelchen Sensoren erzeugt werden und die müssen nicht grundsätzlich Personen gebunden sein.»

Kernregelungen, Zeitplan und vertragliche Implikationen

Daniel führt aus, dass der EU Data Act detailliert vorschreibt, welche Daten zugänglich sein müssen und wie diese Bereitstellung erfolgen soll: maschinenlesbar, wenn möglich automatisiert und in Echtzeit. Eine der signifikantesten Änderungen ist die schrittweise Reduzierung der Egress Costs, die bis 2027 vollständig entfallen müssen. Bereits seit Dezember dieses Jahres sind die Kosten für den Datentransfer aus der Cloud deutlich gesunken und müssen den tatsächlichen Kosten des Anbieters entsprechen. Ein entscheidender Aspekt ist, dass der Data Act auch bestehende Verträge überschreibt. Dies bedeutet, dass Unternehmen ihre aktuellen Cloud-Verträge überprüfen sollten, um von den neuen Regelungen zu profitieren, selbst wenn diese ursprünglich andere Konditionen für den Datentransfer vorsahen.

Haben Sie bereits eine Strategie, um die maschinenlesbare und automatisierte Bereitstellung von Daten zu gewährleisten, wie es der Data Act fordert? Welche Auswirkungen hat die Überschreibung bestehender Verträge auf Ihre langfristige Cloud-Strategie und Budgetplanung?

«Ab 2027 müssen auch aktuell bestehende Verträge den EU Data Act erfüllen. Also sprich, wenn ich jetzt sage, okay, ich habe jetzt einen Vertrag, der ist aber bis 2030 festgezurt, das heißt, wenn ich Egress haben machen möchte, dann muss ich relativ viel bezahlen oder ich komme an die vorhin Daten nicht dran, ist das durch den EU Data Act hinfällig, da diese Teile dann durch den EU Data Act überschrieben werden.»

Strategische Ziele und Auswirkungen auf die Cloud-Adoption

Anja und Daniel erörtern das übergeordnete Ziel des EU Data Act: die Dominanz der drei großen US-Cloud-Anbieter (AWS, Microsoft Azure, Google Cloud) zu mindern und europäische Alternativen zu stärken. Daniel schätzt, dass diese Anbieter zusammen etwa zwei Drittel des Marktes ausmachen. Er betont, dass der Data Act zwar nicht zu einem sofortigen Massenwechsel führen wird, aber Unternehmen ermutigen könnte, bei neuen Projekten von Anfang an eine Exit-Strategie zu planen. Dies beinhaltet die bewusste Entscheidung, proprietäre Services zu vermeiden und stattdessen auf plattformunabhängige Lösungen zu setzen. Langfristig soll dies Unternehmen mehr Flexibilität verschaffen und die Kosten für den Wechsel zwischen Anbietern reduzieren.

Wie bewerten Sie die Marktstellung der großen US-Cloud-Anbieter in Ihrem Unternehmen? Welche Rolle spielt die Vermeidung von Vendor Lock-in bei der Auswahl von Cloud-Services für neue Projekte, und wie könnte der Data Act diese Entscheidungen beeinflussen?

«Ich hoffe, was passieren wird und ich glaube, es ist auch schon, es hat auch schon so ein bisschen angefangen in den letzten Jahren ohne den EU Data Act. Aber ich habe vor 10 Jahren war so eine Entwicklung, die fühlt sich fast an wie Microsoft in den 90er Jahren, dass da haben einfach alle Microsoft gemacht, das hat niemand in Frage gestellt.»

Architektonische Strategien für Anbieterunabhängigkeit

Anja und Daniel diskutieren konkrete Architekturprinzipien, die Unternehmen helfen können, anbieterunabhängiger zu werden. Anja schlägt vor, auf Containerisierung zu setzen, um Artefakte plattformübergreifend einsetzen zu können – beispielsweise durch die Nutzung von Container-Varianten bei Functions-as-a-Service-Lösungen, die dann auch in einem Kubernetes-Cluster laufen könnten. Daniel ergänzt, dass eine «Exit Readiness» entscheidend ist. Ähnlich den Anforderungen der BaFin oder EZB für Banken und Versicherungen, die einen dokumentierten Exit-Plan verlangen, sollten Unternehmen darauf vorbereitet sein, ihre Systeme bei Bedarf zu migrieren. Dies beinhaltet die Vermeidung proprietärer Datenbanken oder Queuing-Lösungen zugunsten universellerer Alternativen, die einen Translation Layer überflüssig machen oder vereinfachen.

Welche Architekturprinzipien wenden Sie bereits an, um den Vendor Lock-in zu minimieren? Wie könnten Sie Ihre aktuellen Systeme so gestalten, dass sie eine «Exit Readiness» aufweisen, die über die reinen Datentransferkosten hinausgeht?

«Von daher wäre sowas wie eine Dynamo DB entweder gar nicht möglich für Banken oder Versicherung oder die müssen ganz genau dokumentieren, ähm wenn wir das nicht mehr nutzen können, nutzen wir etwas anderes und dann brauche ich meistens wahrscheinlich schon so eine Art Translation Layer dazwischen, was wahrscheinlich dann auch eine gute Idee ist, damit ich darauf vorbereitet bin.»

Europäische Cloud-Alternativen und technische Grundlagen

Daniel gibt Einblicke in europäische Cloud-Anbieter, die eine Alternative zu den großen US-Playern darstellen könnten. Er nennt Scaleway und OVH Cloud aus Frankreich sowie in Deutschland die Open Telekom Cloud, Ionos und die Schwarz IT Cloud (Stackit). Hetzner wird als bekannter Infrastructure-as-a-Service-Anbieter erwähnt, der jedoch weniger Managed Services anbietet. Viele dieser europäischen Anbieter basieren auf OpenStack, einer Open-Source-Plattform, die eine ähnliche Infrastrukturbasis für virtuelle Maschinen, Netzwerke und Speicherdienste schafft. Sie bieten oft auch Database-as-a-Service und Kubernetes-Angebote, wobei die Kubernetes-Implementierungen sich geringfügig unterscheiden können, aber auf einer ähnlichen OpenStack-Infrastruktur aufsetzen.

Haben Sie bereits europäische Cloud-Anbieter in Betracht gezogen oder evaluiert? Welche Kriterien sind für Sie entscheidend bei der Auswahl einer Cloud-Plattform, insbesondere im Hinblick auf Open-Source-Technologien wie OpenStack und Kubernetes?

«Die bauen aber alle auf den gleichen Stack auf Open Stack auf, was natürlich auch ein Vorteil sein kann, weil da ist dann natürlich das ganze Setup erstmal relativ ähnlich.»

Pflichten für Datenanbieter und Chancen

Der EU Data Act betrifft nicht nur die Konsumenten von Cloud-Diensten, sondern auch die Anbieter digitaler Dienste, die Daten sammeln. Daniel erklärt, dass diese Unternehmen ihre gesammelten Daten – insbesondere Rohdaten – ab September 2026 zur Verfügung stellen müssen; für neue Produkte gilt dies sogar schon ab September dieses Jahres. Die Verordnung hat, ähnlich der DSGVO, internationale Auswirkungen und gilt für alle Firmen, die ihre Dienste in Europa anbieten. Bei Nichteinhaltung drohen hohe Strafen von bis zu 4 % des Jahresumsatzes. Trotz einiger unklarer Begriffe, die noch definiert werden müssen (z.B. «Rohdaten» oder «technisch zumutbar»), sieht Daniel darin eine Chance für Unternehmen, ihre internen Datenprodukte und -inventare zu verbessern und so einen Mehrwert aus der notwendigen Datenbereitstellung zu ziehen.

Sind Sie sich der Verpflichtungen bewusst, die der EU Data Act für Ihr Unternehmen als Datenanbieter mit sich bringt? Wie könnten Sie die Notwendigkeit, Daten zugänglich zu machen, als Chance nutzen, um Ihre internen Datenprodukte und -strategien zu optimieren?

«Vielleicht kann ich das auch wirklich, wenn ich ein Unternehmen bin, was die Daten zur Verfügung stellen muss, als Chance sehen, da ein gutes Datenprodukt machen, wie man das heutzutage macht mit mit Data Mesh oder so.»