Drücke „Enter”, um zum Inhalt zu springen.
Ausprobieren
Online Webseiten-Check
sofort das Ergebnis sehen
Auf meiner Webseite sind externe Links mit dem Symbol gekennzeichnet. Datenschutzhinweise · Wissensartikel

Cloud Computing: Datenschutzfreundliche Alternative aus Deutschland statt AWS, Google Cloud oder Microsoft Azure

0

Wer Datenschutz ernst meint, nimmt Abstand von AWS, der Google Cloud oder Microsoft Azure, wenn personenbezogene Daten verarbeitet werden sollen. Verteiltes Rechnen ist mittlerweile mit der Open Telekom Cloud komfortabel möglich, auch ohne Kubernetes-Kenntnisse. Mein Praxistest zeigt, was möglich ist und wie eine ausfallsichere, lastverteilte Architektur errichtet werden kann.

Einleitung

Cloud Computing basiert insbesondere auf einer ausfallsicheren, verteilten Infrastruktur, auf der Berechnungen durchgeführt werden können. Vereinfacht gesagt, können in einer Cloud Infrastruktur Programme auf mehreren Servern ausgeführt werden, sodass ein Zugriff von außen (über das Internet) möglich ist.

Die bekanntesten Cloud-Anbieter haben Ihren Sitz in den USA (Muttergesellschaft). Weil es schon so oft gesagt wurde, nur in Kürze: Die Geheimdienstgesetze der USA stehen der DSGVO entgegen. Das entschied der EuGH in seinem Schrems II-Urteil. Damit können Dienste mit amerikanischen Wurzeln (Serverstandort egal) oder auf amerikanischen Servern nicht datenschutzkonform genutzt werden.

Die Open Telekom Cloud (kurz: OTC) ist ein Angebot der Telekom. Wer es vergessen haben sollte: Die Telekom ist ein deutscher Anbieter. Die OTC Dienstleistungen werden in zwei deutschen Rechenzentren angeboten, nämlich in Sachsen-Anhalt in Magdeburg und Biere. Letztgenannter Standort ist mir vom Namen her irgendwie sympathischer …

Die OTC arbeitet mit einem Per per use Modell, so wie man es auch von anderen Anbietern kennt. Das bedeutet, bezahlt wird für genutzte Ressourcen. Die klassische Miete eines Servers für einen Monat oder länger entfällt. Benötigte Komponenten werden spezifisch eingerichtet. Das ist ziemlich komfortabel möglich, in weiten Teilen über eine visuelle Oberfläche. Später nicht mehr oder zeitweise nicht benötigte Server und andere Komponenten der Cloud-Infrastruktur können auf Knopfdruck bedarfsgerecht heruntergefahren werden.

Ich bin mit der Telekom nicht besonders verbunden. Bis auf eine achtjährige Tätigkeit als Freiberufler für die T-Systems, die im Jahr 2015 endete, pflege ich keine nennenswerten Beziehungen zur Telekom. Da der deutsche Markt im Cloud Computing noch recht dünn gesät ist, lag das Telekom-Angebot nahe.

Mein Praxistest konzentriert sich darauf, eine lastverteilte, hochverfügbare Cloud-Computing Lösung aufzubauen. Diese Lösung nutzt auf Seiten der Telekom faktisch Node.js, Docker-Container und Kubernetes. Eine vergleichbare Lösung, die einige Vor- und Nachteile gegenüber der OTC-Lösung hat, habe ich mit AWS aufgebaut.

Praxistest Cloud Computing

Die Aufgabe lautet, ein Programm auf mehreren Servern gleichzeitig bereitzustellen. Die Lösung soll ausfallsicher und lastverteilt sein. Als Cloud-Lösung angedacht, soll ein Zugriff aus dem Internet möglich sein. Das bedeutet konkret folgende Eigenschaften:

  • Die Cloud-Lösung soll über einen Aufruf via HTTP (Internet) angesprochen werden können.
  • Die Cloud ist „immer“ erreichbar. Der Ausfall eines Servers soll sich also nicht negativ auswirken.
  • Ist ein Server ausgelastet, also mit Rechnen beschäftigt, dann soll ein anderer Server einspringen.
  • Das Ergebnis der Arbeit soll irgendwo gespeichert werden (Datenbank, externe Schnittstelle). Das untersuche ich hier nur aus Zeitgründen nicht näher. Speichermöglichkeiten sind sowohl auf AWS als auch auf der OTC zu Genüge vorhanden.

Die Aufgabe soll mit AWS und mit der Open Telekom Cloud (OTC) gleichermaßen gelöst werden. Mein AWS-Ansatz basiert auf AWS Lambda-Funktionen, auf die ich gleich näher eingehe. Der OTC-Ansatz basiert auf einer Cloud-Infrastruktur mit einem Cluster aus mehreren Servern, einem Elastic Load Balancer und einer externen IP-Adresse. Später mehr dazu.

Skalierbare Cloud-Infrastrukturen

Heutzutage werden sogenannte Container verwendet, um skalierbare Infrastrukturen zu errichten. Ein Container ist eine in sich gekapselte Einheit eines Programms, zusammen mit der zugehörigen Laufzeitumgebung, die möglichst betriebssystemunabhängig ist. Populär wurden Container über Docker, eine Virtualisierungslösung für Software. Docker ist schlanker und portabler als virtuelle Maschinen. Eine virtuelle Maschine (VM) emuliert ein Betriebssystem und benötigt mehr Ressourcen als ein Container. Ebenso sind die Schnittstellen einer VM nicht so gut ausgeprägt wie die von Containern. Container sind konzeptionell auf den Datenaustausch mit anderen Einheiten ausgelegt.

Laufzeitumgebung

Als Programmiersprache habe ich mir Node.js ausgesucht. Node.js ist in Kürze serverseitig ausgeführtes JavaScript. JavaScript läuft für gewöhnlich nur im Browser (im Client). Mit Node.js wurde schon vor einiger Zeit ein Weg geschaffen, diese leistungsfähige Programmiersprache auch auf dem Server zu nutzen.

Auf AWS wäre mit meinem nachfolgend genannten Ansatz neben Node.js ohne weiteres auch Java möglich.

Von AWS Lambda-Funktionen unterstützte Laufzeitumgebungen (plus ein paar ältere Versionen).

Auf der OTC wären neben Java noch PHP und andere Laufzeitumgebungen, die von Docker unterstützt werden, ohne zusätzliche Umstände möglich.

Praxistest mit AWS

Amazon bietet auf der AWS-Plattform sogenannte Lambda-Funktionen an. Wie mir ein Telekom-Mitarbeiter die Tage mitteilte, plant die Telekom, ein analoges Produkt in diesem Jahr bereitzustellen.

Eine Lambda-Funktion ist ein Programm, welches serverless ausgeführt wird. Serverless bedeutet: Für Sie als Lambda-Entwickler oder AWS-Kunde existiert keine Hardware. Die Hardware wird von AWS so stark weggekapselt, dass Sie nichts davon mitbekommen, welche Server und wie viele davon eingesetzt werden, um Ihre Lambda-Funktion auszuführen.

Jedes Programm benötigt Ressourcen. Diese können über eine einfache Konfiguration eingestellt werden:

Ressourcenkonfiguration einer Lambda-Funktion.

Die wichtigste Ressource ist der Arbeitsspeicher. Das war’s eigentlich schon. Das Timeout ist nur für Lambda-Funktionen wichtig, die nicht von außen (über das Internet) aufgerufen werden.

Eine Lambda-Funktion kann über den API-Gateway exponiert werden.

Endpunkt einer Lambda-Funktion auf AWS.

Damit kann die Lambda-Funktion über den genannten Endpunkt einfach von außen über eine Schnittstelle aufgerufen werden.

Der Programmcode einer Lambda-Funktion wird üblicherweise hochgeladen. Programme, die sehr klein sind, können auch in der Lambda-Konfiguration als Text eingefügt werden. Node-js Programme sind aber regelmäßig zu groß dafür, weil oft Node.js-Pakete eingebunden werden. Pakete sind hier quasi Bibliotheken, die genutzt werden können.

Lambda-Funktionen bringen von sich aus einige herausragende Eigenschaft mit. Diese sind:

  • Massive Parallelisierbarkeit bis zu 1000 Instanzen gleichzeitig
  • Ausfallsicherheit

Die Konfiguration ist denkbar einfach. Pro Lambda-Funktion kann die Nebenläufigkeit definiert werden, das bedeutet, wie viele Instanzen einer bestimmten Lambda-Funktion maximal gleichzeitig ausgeführt werden dürfen. Auf Kontoebene kann diese Einstellung global vorgenommen werden. Die Lambda-Funktionen erben die Einstellung dann.

So muss die Einstellung nicht für jede Lambda-Funktion vorgenommen werden, sondern kann allgemein vorgegeben werden.

Was ich hier nicht beschreibe, ist der Aufbau einer lokalen Node.js Entwicklungsumgebung. Zusätzlich sollte ein Serverless-Tool auf dem Entwicklungsrechner installiert werden, mit dem die lokalen Entwicklungen komfortabel auf AWS hochgeladen werden können, ohne sich bei AWS einloggen zu müssen.

Man darf sich nicht täuschen: Wer noch nie eine AWS Lambda-Umgebung genutzt hat, braucht je nach Anwendungsfall gerne mal einige Wochen, um einen zufrieden stellenden, lauffähigen Stand zu erreichen. Es ist also nicht alles so einfach, wie es die obigen Abbildungen vielleicht suggerieren. Zur Lösungsfindung gehört es auch, sich durch die wirklich sehr zahlreichen AWS Services durchzuwühlen und die eigentlich benötigten Dienste herauszufinden. Dann muss noch pro Dienst die richtige Konfiguration gefunden werden.

Die Abrechnung mit AWS macht auch nicht wirklich Spaß. Wer nur wenig Kosten verursacht, wird genötigt, per Kreditkarte zu bezahlen. Weil Amazon nach Nutzung der Dienste abrechnet, muss man Vorkehrungen treffen, um nicht ungewollt tausende von Euro zu verballern.

Lambda-Funktionen verbrauchen sowohl Rechenzeit als auch Hauptspeicher. Beides wird abgerechnet. Wenn man Lambda-Funktionen rekursiv aufruft, kann es passieren, dass innerhalb kürzester Zeit hunderttausende Aufrufe zustande kommen. Die Kosten können sich derart immens aufsummieren. Allerdings gibt es sogenannte Alerts und Budgets, mit denen das in den Griff zu kriegen ist.

Zwischenfazit: Wer AMS Lambda kennt, kann damit einfach massiv nebenläufige Funktionen errichten und betreiben. Wer AWS noch nicht kennt, wird einige Wochen brauchen, um anspruchsvollere Anwendungen zu erstellen. Datenschutzfreundlich wird die Nutzung von AWS mit personenbezogenen Daten nicht möglich sein, wenn man sich die Schrems II-Problematik ansieht.

Praxistest mit der OTC

Die Open Telekom Cloud (OTC) kennt (noch?) keine Lambda-Funktionen. Dafür gelang es mir, innerhalb von ca. 6 Stunden eine Cloud Infrastruktur mit Cluster, Worker Nodes, Lastverteiler und Elastischen IP Adressen zu errichten und auf den Workern einen installationstechnisch anspruchsvolleren Container zu installieren. Wahrscheinlich hätte ich deutlich länger gebraucht, wenn ich nicht zuvor bereits Erfahrungen mit Node.js auf Cloud Plattformen gesammelt hätte. Aber 6 Stunden ist ziemlich wenig für das, was ich errichtet habe. Das liegt zum einen an der OTC-Oberfläche, die komfortabel ist. Zum anderen schadet eine gewisse Erfahrung mit Informationssytemen aller Art nicht.

Meine Telekom-Cloud-Architektur besteht aus folgenden Komponenten:

  • Cloud Cluster Environment (CCE): Bildet die Cloud ab, indem mehrere Knoten (Nodes) zusammengefasst werden.
  • Elastic Cloud Server (ECS): Virtueller Server, der den Cluster verwaltet.
  • Image und Container: Gekapseltes Programm für die verteilte Ausführung. Oft wird hiermit Docker assoziiert.
  • Workload: Arbeitspaket (Programm), das lastverteilt in der Cloud-Umgebung ablaufen soll. Basiert auf Kubernetes.
  • Elastic Load Balancer: Lastverteiler, der wohl hochverfügbar ist (daher das Attribut „Elastic“).
  • Elastic IP (EIP): Öffentlich erreichbare IP-Adresse. Soweit ich verstanden habe, heißt diese Elastic, weil sie hochverfügbar ist.

Cloud Cluster

Der Cluster ist recht schnell konfiguriert und installiert. Der von der Telekom Cloud angebotene CCE Turbo Cluster machte bei der Installation Probleme. Mit dem „normalen“ Cluster ging es aber gut. Zum Cluster müssen ein Netz für die virtuelle private Cloud und ein Subnetz angelegt werden, was in Sekunden möglich ist. Weiterhin kann definiert werden, aus wie vielen Nodes der Cluster maximal bestehen darf. Möglich sind die Werte 50, 200, 1000 und 2000. Ich vermute, dass die OTC dies abfragt, um dem Serverless Ansatz näher zu kommen. Denn ein kleiner Cluster kann auf einer anderen Hardware laufen als ein großer.

Zum Cluster wird dann noch definiert, welche Ausprägung die Nodes im Cluster haben sollen. Diese Ausprägung wird Flavor genannt. Ein Bild sagt mehr als tausend Worte:

Node-Flavors innerhalb eines Clusters in der OTC.

Dies erinnert an AWS, wo ebenfalls Flavors für bestimmte AWS Dienste angegeben werden können. Alle Nodes können dadurch mit einem Knopfdruck erstellt werden. Somit können mehrere Server, auf denen jeweils eine Node abgebildet wird, sehr schnell und komfortabel errichtet werden.

Elastic Cloud Server

Mein Elastic Cloud Server hat folgende Konfiguration:

Konfiguration meines Elastic Cloud Servers (ECS) in der OTC.

Wie zu sehen, können die wichtigen Systemparameter sehr einfach eingestellt werden. Bei der Konfiguration zeigt ein Preisrechner sofort an, was der Server pro Monat kosten wird:

Initiale Konfiguration eines ECS mitsamt Kostenanzeige pro Monat.

In der kleinsten Ausprägung kostet der ECS also 10,50 € pro Monat und Instanz. Wem eine Instanz reicht, der zahlt eben genau diesen Betrag. Dann sind wir aber noch nicht beim ausfallsicheren, hochverteilten Cloud Computing. Dazu gleich mehr. red Hat Linux ist übrigens um ein Vielfaches teurer als Open Linux.

Der ECS kann auf Knopfdruck gestartet, gestoppt oder umkonfiguriert werden. Das ganze sieht in der OTC so aus:

Ansicht der installierten Elastic Cloud Server in der OTC.

Workload

Die Workload definiert ein Arbeitspaket bzw. ein Programm, welches in der Cloud ausgeführt wird. In der Cloud kann es mehrere verschiedene Workloads geben. In der OTC entspricht die Workload einer Anwendung, die über Kubernetes läuft. Kubernetes ist ein Dienst zur Verwaltung und Skalierung von Container-Anwendungen.

Zu einer Workload wird definiert, wie viele Instanzen maximal gleichzeitig laufen dürfen. Eine Workload besteht aus einem Container, welcher das auszuführende Programm definiert. Container wurden durch Docker bekannt. Docker ist ein Dienst, um Software in Containern zu kapseln, um sie zu virtualisieren und verteilt ablaufen lassen zu können.

Mit Docker werden also Anwendungen in Form von Containern bereitgestellt und mit Kubernetes wird dafür gesorgt, dass diese Container in einer verteilten Umgebung, die wir hier als Cloud bezeichnen, bereitstehen und parallel ausgeführt werden können. Natürlich muss sich die jeweilige Workload selber darum kümmern, dass mehrere Workload-Instanzen sich nicht in die Quere kommen, wenn sie auf gemeinsame Ressourcen wie Datenbanken, Objektspeicher oder (Cloud-)Festplatten zugreifen.

Kubernetes erlaubt es, dass mehrere Container zusammen eine Einheit bilden und sich ein Netzwerk und Resourcen teilen. Diese Einheit wird Pod genannt. Pods sind in Kubernetes die kleinste verteilbare Einheit. Obwohl ich kein Kubernetes-Experte bin, gelang es mir sehr schnell und ohne Mühe, den Cluster zum Laufen zu bringen.

Image und Container

Mein Container besteht aus einem Node.js Programm, welches einige Node-Pakete verwendet. Das Programm habe ich selbst geschrieben bzw. das von meinem AWS Praxistest genommen.

Mit Hilfe von Docker habe ich aus einem sogenannten Image einen Container erzeugt. Ein Docker Image definiert, was zum Programm dazugehört, also die Quelldateien und auch die Laufzeitumgebung (Node.js in Version 16 beispielsweise). Auch enthält die Image-Datei Anweisungen für das Setup des Containers. Klingt kompliziert, ist aber in der Praxis mithilfe allgemeiner Vorlagen schnell erledigt.

Das Image wird in der OTC über einen etwas gewöhnungsbedürftigen, aber schnell erlernbaren Mechanismus auf die OTC hochgeladen. Danach steht es in der eigenen Cloud zur Verwendung zur Verfügung und kann mit einer Workload verknüpft werden. Über ein sogenanntes Deployment wird eine Workload auf mehreren Nodes in der Cloud bereitgestellt. Die Idee dahinter ist: Wenn man eine Workload aktualisiert, dann sollten alte Workloads nicht auf einmal aufhören zu existieren. Stattdessen wird wahlweise in einem „Rolling upgrade“ jede alte Workload nacheinander durch die neue Version ersetzt. Das ist gut für die Verfügbarkeit der Infrastruktur.

Nach alldem sieht mein Cluster in graphischer Darstellung so aus:

Cluster in der OTC (Übersicht).

Der Cluster besteht aus 2 Nodes. Ich hätte auch 10 oder eine andere Anzahl einstellen können. In der Praxis werden 2 gelegentlich ausreichend. Für höher belastete Workloads wird die Anzahl größer sein.

Elastic Load Balancer

Meine Cloud Computing soll von außen gut erreichbar und insbesondere ausfallsicher sein sowie zahlreiche Aufrufe gleichzeitig verkraften können. Daher nutze ich einen Elastic Load Balancer, den die OTC anbietet.

Trotz einiger Einstellmöglichkeiten ist der Load Balancer schnell konfiguriert. Ich weise dem Load Balancer eine Elastic IP Adresse zu, damit dieser über das Internet erreichbar ist. Diese Zugriffsmöglichkeit ist vergleichbar mit dem API Gateway bei AWS, wobei ein Teil des AWS API Gateways in der OTC durch die Docker-Konfiguration der jeweiligen Container bewerkstelligt wird.

Vergleich von AWS und OTC

In meinem Praxistest habe ich mir AWS Lambda-Funktionen herausgegriffen. Nur diese kann ich somit mit der OTC-Architektur aus meinem Praxistest vergleichen.

AWS Lambda ist eine schlanke, stromlinienförmige Lösung für hochskalierbare Serverless Anwendungen.

Die OTC Cluster Architektur ist verglichen damit schwergewichtiger. Das bedeutet einerseits etwas höhere Kosten. Andererseits kann der OTC Cluster aber auch viel mehr als eine zustandslose, in der Luft hängende Lambda-Funktion von AWS.

Folgende Tabelle zeigt zu ausgewählten Kriterien die Unterschiede:

KriteriumAWS LambdaOTC Cluster
SerververwaltungNein (Serverless)Ja
AbstraktionsgradSehr hochMittel
GewichtigkeitSehr schlankFett
AusfallsicherheitImplizit gegebenExplizit (Load Balancer optional)
EingriffsmöglichkeitenGeringHoch
Cloud ArchitekturKomplett weggekapseltKonfigurierbar
Farbe der Boxschwarz (Black Box)grau (Grey Box)
Nutzungsmöglichkeitennur spezifischbeliebig
Kostennur bei Aufrufsolange Server läuft (also immer)
Vergleich AWS Lambda zum OTC Cluster aus meiner Sicht.

Der OTC Cluster erfordert also mehr initiale Arbeit als eine AWS Lambda-Funktion. Dafür bietet der OTC Cluster dann aber auch eine vollwertige Cloud Computing Infrastruktur, wohingegen AWS Lambda nicht mehr kann als Funktionen auszuführen. Je nach Anwendungsfall kann die Leistungsfähigkeit der OTC ein Vorteil oder Nachteil sein. Ich würde sagen, eher ein Vorteil, der allerdings durch den höheren initialen Aufwand erkauft wird. Wenn in AWS Lambda etwas nicht funktioniert, ist es entweder nicht vorgesehen, oder der Fehler ist möglicherweise nicht so einfach zu finden. In einem OTC Cluster, würde ich allgemein formulieren, ist eigentlich alles machbar. Fehler sind dort eher zu finden oder können durch alternative Vorgehensweisen umgangen werden. Immerhin besteht auf Ebene des Elastic Cloud Servers ein Root Zugriff mit sämtlichen Eingriffsmöglichkeiten (bis auf Einstellungen, die auf Hardware-Ebene, etwa im BIOS, vorzunehmen sind).

Fazit

Die OTC basiert auf OpenStack, einer freien Architektur für Cloud-Computing, die übrigens auch von der Huawai-Cloud verwendet wird. Ich war recht überrascht, wie schnell man mit einer gewissen Vorkenntnis eine Cloud Computing-Infrastruktur errichten kann. Nicht verschwiegen werden darf, dass auch gewisse Linux-Kenntnisse und die Fähigkeit, bisher unbekannte Problemstellungen effektiv zu bearbeiten, wichtig sind.

Wer eine datenschutzfreundliche Cloud Computing-Infrastruktur sucht, muss nicht zu Amazon, Google oder Microsoft gehen. Hoffentlich hören die Ausreden bald auf, es gäbe ja nicht anderes. Auch der Umzug von AWS zur OTC sollte gut gelingen, wie ich selbst in meinem Praxistest festgestellt habe.

Die OTC Cluster Architektur ist sehr vielseitig nutzbar, wohingegen AWS Lambda-Funktionen nur als einer von vielen Diensten innerhalb der AWS Architektur verstanden werden dürfen, die oft auf andere Dienste zurückgreifen müssen. Die AWS Dienste sind eher lose gekoppelt, während die in einem OTC Cluster laufenden Dienste nach meiner Einschätzung eher enger gekoppelt sind. Man „sieht“ bei der OTC eher die Zusammenhänge als bei AWS. Abstraktion hat eben nicht nur Vorteile, sondern auch Nachteile.

Eine Black Box ist (hoffentlich) leicht bedienbar, aber wenn sie etwas nicht leisten kann oder etwas schiefläuft, wird es schwierig.

Fazit zu AWS Lambda als Black Box.

Bei Pay Per Use-Modellen wie bei AWS und OTC muss man aufpassen, was man tut. Ein falscher Klick kann schnell mal 249 Euro kosten, wie ich selbst herausfinden durfte. Testweise erstellte ich eine „Direct Connection“. Die Konfiguration bestand aus drei Teilen, von denen ich nur den ersten Teil erledigte. Man könnte meinen, dass eine objektiv nicht herstellbare Verbindung kein Geld kostet. Weit gefehlt. Bereits die Einrichtung dieser Verbindung schlägt mit 249 Euro zu Buche. Der 250 Euro Gutschein für Neukunden sorgte dafür, nicht vollständig in Kummer zu verfallen. Auch eine Fehlprogrammierung kann schnell mal zu immensen Kosten führen. Mir ist das nur einmal passiert. Da ich das Programm aber gut testete, konnte ich den Fehlversuch mit einem Verlust von nur wenigen Cent vorzeitig abbrechen.

Die OTC wird sich noch weiterentwickeln. An der ein oder anderen Stelle gibt es Verbesserungsbedarf. Das aktuelle Angebot würde ich allerdings schon als sehr ordentlich bezeichnen.

Wer schreibt hier?
Mein Name ist Klaus Meffert. Ich bin promovierter Informatiker und beschäftige mich seit über 30 Jahren professionell und praxisbezogen mit Informationstechnologie. In IT und Datenschutz bin ich auch als Sachverständiger tätig. Mir sind juristische Gegebenheiten nicht fremd. Meine Ergebnisse gewinne ich durch Betrachtung von Technik und Recht. Das scheint mir absolut notwendig, wenn es um digitalen Datenschutz geht. Über neue Beiträge werden Sie informiert, wenn Sie meinen Newsletter abonnieren. Über Ihre Unterstützung für meine Arbeit würde ich mich besonders freuen.
Bitte nutzen Sie bei Verwendung meiner Ergebnisse die Quellenangabe oder verlinken Sie gut wahrnehmbar auf diesen Artikel:
Einen Kurzlink oder eine Bestätigung für Ihre Quellenangabe erhalten Sie kurzfristig auf Anfrage. Ein Teilen oder Verteilen dieses Beitrags ist natürlich ohne weiteres möglich und gewünscht.

Schreiben Sie einen Kommentar

Ihre Mail-Adresse wird nicht veröffentlicht.

Nächster Beitrag

Datenschutz-Schulung: Kostenfreies online Training des Netzwerks 4.0