Gehostete Jupyter Notebooks und VS Code auf Kubernetes

Jupyter Notebooks sind ein leistungsstarkes und beliebtes Tool, das eine interaktive Computing-Umgebung bietet. Es kombiniert Code, Datenvisualisierung und erklärenden Text, was die Arbeit mit Daten und das Teilen von Erkenntnissen erleichtert. Data Scientists nutzen Jupyter Notebooks für verschiedene Aufgaben im gesamten Data-Analysis- und Machine-Learning-Lebenszyklus, wie z. B. explorative Datenanalyse (EDA), Datenvorverarbeitung, Visualisierung, Modellentwicklung, Evaluierung und Validierung etc. Für viele dieser Anwendungsfälle reicht es aus, Jupyter Notebook auf Ihrem Laptop zu installieren, um loszulegen. Für viele Unternehmen und Organisationen ist dies jedoch keine Option, und wir benötigen gehostete Jupyter Notebooks.

Warum benötigen wir gehostete Jupyter Notebooks?

1. Zugriff auf Ressourcen: Viele Data-Science-Workloads erfordern eine hohe Rechenleistung, die von den lokalen Maschinen der DS oder MLEs nicht bereitgestellt werden kann. Gehostete Jupyter Notebooks können DS/MLEs Zugriff auf leistungsstarke Maschinen und GPUs bieten.
2. Datenzugriff und Sicherheit: In vielen Unternehmen arbeiten DS/MLEs an Projekten mit sensiblen Daten, die nicht auf den Laptop des Mitarbeiters heruntergeladen werden dürfen. Mit gehosteten Jupyter Notebooks können Unternehmen DS/MLEs Zugriff gewähren, um an sensiblen Projekten zu arbeiten.
3. Reproduzierbarkeit und Zusammenarbeit: Gehostete Jupyter Notebooks sind eine hervorragende Möglichkeit, ausführbaren Code und Ergebnisse innerhalb eines Teams zu teilen. Da die Entwicklungsumgebung identisch ist, sind die Ergebnisse zu 100 % reproduzierbar und Teammitglieder können gemeinsam an Projekten arbeiten.

Wie kann ein Unternehmen seinen Data Scientists gehostete Notebooks zur Verfügung stellen?

Hier sind die Optionen, die ein Unternehmen heute hat, um seinen Ingenieuren Zugriff auf Jupyter Notebook zu gewähren:

Bereitstellung einer VM für jeden Data Scientist:

DS/MLEs können die Umgebung einrichten und einen Jupyter-Server auf einer VM ausführen, der für die Ausführung der Workloads genutzt werden kann. Hier ist eine einfache Anleitung, wie Sie JupyterLab auf einer EC2-Instanz ausführen können.

👍 Vorteile:
- Gibt dem DS die vollständige Kontrolle über die Maschine
- Die gesamte Umgebung ist persistent. Die VM kann gestoppt und im selben Zustand neu gestartet werden.

👎 Nachteile:
- Hohe Cloud-Computing-Kosten – Es gibt keine Auto-Stop-Funktion. Ein DS kann eine VM starten, die dann für einen Großteil der Zeit ungenutzt bleibt, was die Kosten erhöht.
- Schwierig, eine große Anzahl von VMs zentral zu verwalten und zu verfolgen.
- Der DS muss viele Dinge konfigurieren, um die Workbench für den Start von Experimenten einzurichten.
- Schwierigkeiten bei der Reproduzierbarkeit – Der DS hat möglicherweise eine Reihe von Paketen installiert, die nicht mehr nachverfolgt werden, was die Überführung des auf dieser VM laufenden Codes in die Produktion sehr zeitaufwendig macht.

Nutzung einer verwalteten Lösung:

Eine weitere Option ist die Nutzung einer verwalteten Lösung wie AWS SageMaker, Vertex AI Notebooks oder Azure ML Notebooks. Während jede dieser Methoden ihre Vorteile hat, sind hier einige allgemeine Pro- und Kontra-Punkte.

Lassen Sie uns besprechen, was jedes dieser Felder bedeutet:

• Persistente Umgebungen: Dies bezieht sich auf die Persistenz der Python-Umgebung (ob Pip-Paketinstallationen und vom Benutzer erstellte Umgebungen über Notebook-Neustarts hinweg gespeichert werden oder nicht).
• Persistente Root-Installationen: Wenn dem Benutzer Root-Zugriff gewährt wird, ob Root-Paketinstallationen (z. B. apt install pkgs) über Notebook-Neustarts hinweg bestehen bleiben oder nicht.
• Monitor für Ressourcennutzung: Ob der Benutzer die CPU-/Speicherauslastung direkt aus dem Notebook heraus auf dem Notebook-Bildschirm überwachen kann oder nicht.
• Code-Server-Unterstützung: Ob die Notebook-Instanz mit einem gehosteten VS Code Server verbunden werden kann.
• SSH in den Container: Möglichkeit, sich per SSH in ein laufendes Notebook einzuloggen und eine Verbindung von der lokalen Maschine aus herzustellen.
• Auto-Stop: Funktion zum Stoppen des Notebooks nach einer "Inaktivitätsperiode". Vertex bietet diese Funktion in seiner Version "Managed Notebooks" an. SageMaker bietet eine Möglichkeit, Notebooks nach einer gewissen Inaktivitätszeit zu stoppen, aber der Benutzer muss dafür ein "Init-Skript" konfigurieren, anstatt eine einfache Bereitstellungsoption zu nutzen, was eine kleine Hürde darstellt.
• Cross-Cloud-Unterstützung: Diese Funktion gibt es exklusiv bei TrueFoundry, da Sie das Notebook bei jedem der drei Cloud-Anbieter mit exakt derselben Benutzererfahrung ausführen können.
• Anpassung von Images: Starten des Notebooks mit einem vorgegebenen Satz vorinstallierter Pakete.
• Einbinden eines gemeinsam genutzten Volumes im Notebook: Notebooks der einzelnen Cloud-Anbieter (AWS/Azure/Vertex) ermöglichen das Erstellen eines separaten Volumes für jedes Notebook, bieten jedoch keine Möglichkeit, ein gemeinsam genutztes Volume einzubinden. Nehmen wir beispielsweise an, ein Unternehmen verfügt über einen Datensatz von 500 GB, der von mehreren Data Scientists für verschiedene Anwendungsfälle genutzt wird. Nun muss jeder DS diese Daten duplizieren und für die Kosten mehrerer Volumes bezahlen, selbst wenn die Notebooks gar nicht laufen. Dies könnte potenziell Hunderte und Tausende von Dollar an Cloud-Kosten verschlingen!
  Mit TrueFoundry können Sie ein Volume vom Typ NFS im schreibgeschützten Modus (Read-Only) in mehrere Notebooks einbinden und so Kosten durch Datenduplizierung sparen!

Gehostete Notebooks über Kubernetes:

Eine weitere Option ist das Hosten von Notebooks über Kubernetes. Dies bringt jedoch eigene Herausforderungen mit sich, da Data Scientists nicht direkt mit Kubernetes interagieren können und eine Software dazwischen benötigen, die eine einfache Schnittstelle zum Starten von Jupyter Notebooks bietet. Werfen wir einen Blick auf die verfügbaren Optionen:

Kubeflow Notebook Operator:
Kubeflow hilft dabei, Deployments von Machine-Learning-Workflows (ML) auf Kubernetes einfach, übertragbar und skalierbar zu gestalten. Es verfügt über eine Notebook-Funktion, die das Verwalten und Ausführen von Notebooks erleichtert.
Obwohl Kubeflow ein großes Open-Source-Projekt ist, das viele Funktionen für Machine-Learning-Anwendungsfälle bietet, ist es sehr schwierig, Kubeflow selbst zu installieren und zu verwalten.

👍 Vorteile:
- Einfaches Starten und Verwalten von Notebooks für DS
- Persistentes Home-Verzeichnis, abgesichert durch eine Festplatte
- Option für vordefinierte Images für Scikit-learn, PyTorch und TensorFlow, die mit allen installierten Abhängigkeiten geliefert werden
- Open-Source-Codebasis
- Culling-Funktion, die Notebooks nach einer gewissen Zeit der Inaktivität stoppt

👎 Nachteile:
- Schwierige Einrichtung von Kubeflow auf Kubernetes. Die Installation und Wartung von Kubeflow nimmt viel Zeit in Anspruch.
- Um Notebooks in mehreren Regionen bereitzustellen, müssen verschiedene Kubernetes-Cluster erstellt werden, und Kubeflow muss auf jedem einzelnen Cluster installiert werden – was zu hohen Infrastruktur- und Wartungskosten führt.
- Python-Pakete sind standardmäßig nicht persistent, was bedeutet, dass Sie Pakete bei jedem Neustart neu installieren müssen.
- Kein direkter Weg, um Root-Zugriff auf den Container zu erhalten [kann für mehrere Anwendungsfälle nützlich sein].
- Das Stoppen von Notebooks kann nicht pro Notebook konfiguriert werden und ist eine globale Einstellung.

Hosten von JupyterHub auf Kubernetes:
JupyterHub ist ein hervorragendes Setup für Mehrbenutzer-Anwendungsfälle, das bei der optimalen Nutzung von Ressourcen hilft. Das Deployment von JupyterHub auf Kubernetes kann mit einem Open-Source-Projekt namens Zero to JupyterHub mit Kubernetes durchgeführt werden:

👍 Vorteile:
 - Mehrere Benutzer können dank Authentifizierungsunterstützung problemlos zusammenarbeiten
 - Einfaches Einrichten von Auto-Stop für Notebooks
 - Einfache Verwaltung von Umgebungen

👎 Nachteile:
- Schwierig einzurichten und zu verwalten. Wir müssen Networking, Persistent Volumes, Skalierung und Load Balancing konfigurieren, damit JupyterHub korrekt funktioniert.
- Schwierig, GPU-Workloads auf verschiedenen GPU-Typen in JupyterHub auszuführen. Lesen Sie dazu beispielsweise diesen Beitrag.
- Umgebungen sind nicht persistent.

Obwohl derzeit viele Lösungen verfügbar sind, bringt jede Lösung ihre eigenen Einschränkungen mit sich. Bei TrueFoundry haben wir versucht, diese Lücke zu schließen und eine Notebook-Lösung zu entwickeln, die alle Anforderungen eines DS erfüllt und gleichzeitig die Kosten im Rahmen hält. Im nächsten Abschnitt beschreiben wir unseren Ansatz zur Entwicklung der Notebook-Lösung und die Herausforderungen, mit denen wir dabei konfrontiert waren.

TrueFoundrys Ansatz zur Entwicklung einer Notebook-Lösung

TrueFoundry ist eine Entwicklerplattform für ML-Teams, die beim Deployment von Modellen, Services, Jobs und jetzt auch Notebooks auf Kubernetes hilft. Sie können hier mehr darüber lesen, was wir tun. Unsere Motivation für den Bau einer Notebook-Lösung bestand schlicht darin, das Experimentieren und Entwickeln auf unserer Plattform zu ermöglichen. Nach dem Studium aller verfügbaren Lösungen haben wir uns entschieden, die Schwachstellen und fehlenden Funktionen anderer Plattformen zu beheben, damit Data Scientists die beste Erfahrung machen können, ohne hohe Kosten zu verursachen. Einige Dinge, die wir ermöglichen wollten, sind:

1. Persistente Umgebungen
2. Die Möglichkeit für den Benutzer, Root-Abhängigkeiten dynamisch zu installieren und nicht auf eine kleine Auswahl an Abhängigkeiten beschränkt zu sein
3. Die Möglichkeit, in bestimmten Fällen auf Spot-Instanzen zu laufen, da deren Preise drastisch niedriger sein können. Das Benutzererlebnis kann in einigen Fällen beeinträchtigt werden, da die VM zurückgefordert werden kann. Wir haben jedoch festgestellt, dass dies in der Praxis recht selten vorkommt und der Kostenvorteil gelegentliche Unterbrechungen rechtfertigt.
4. Die Möglichkeit, automatisches Stoppen zu konfigurieren, um Kosten zu sparen.

Aufbau auf Kubeflow Notebooks

Kubeflow unterstützt das Ausführen von Notebooks auf Kubernetes. Es bietet von Haus aus eine Reihe von Funktionen für Notebooks. Wir wollten jedoch die oben genannten Probleme in Kubeflow Notebooks beheben und Data Scientists sowie Entwicklern eine nahtlose Erfahrung bieten.

Daher mussten wir Änderungen am Notebook-Controller vornehmen, ihn mit dem Backend von TrueFoundry integrieren und die Notebooks auf unserer Benutzeroberfläche bereitstellen.

Wir haben den Notebook-Controller installiert, stießen jedoch auf einige Probleme, weshalb wir Änderungen am kubeflow-notebook-controller vornehmen mussten:

1. Culling (Auto-Stop-Funktion für Notebooks) funktioniert nicht mit benutzerdefinierten Endpunkten. Der Kubeflow Notebook Controller verließ sich auf bestimmte Endpunktformate, damit Culling funktionierte. Dies schränkt den Benutzer darin ein, den Endpunkt seiner Wahl zu definieren.
2. Gleicher Cull-Timeout im gesamten Cluster. Das bedeutet, dass Sie ein "Inaktivitäts-Timeout" für Notebooks nur auf Cluster-Ebene festlegen können. Sie können keine unterschiedlichen Cull-Timeout-Werte für verschiedene Notebooks festlegen.
3. Die Standard-Python-Umgebung ist nicht persistent.

Wir haben die beiden obigen Probleme gelöst und tfy-notebook-controller gestartet
und es als Helm-Chart im Public Charts Repository von TrueFoundry veröffentlicht. Sie finden das Chart hier.

UI zum Erstellen, Starten und Stoppen von Notebooks:

Wir haben eine leicht verständliche Benutzeroberfläche für Data Scientists zum Starten von Notebooks erstellt. Der Benutzer kann das Idle Timeout (Inaktivitätszeit, nach der das Notebook gestoppt wird), die Persistent Volume Size (Größe der Festplatte, auf der der Datensatz und die Codedateien gespeichert werden) und die Ressourcen (CPU-, Speicher- und GPU-Anforderungen) anpassen und das Notebook starten!

Mit all diesen Änderungen haben wir die v0 unserer Notebooks gestartet.

Aber wir sind immer noch weit von einer optimalen Benutzererfahrung entfernt. Werfen wir einen Blick auf die Vor- und Nachteile dieses Ansatzes:

👍 Vorteile:
- Persistentes Home-Verzeichnis [alle Dateien und Pakete bleiben erhalten]
- Inaktivitäts-Timeout (Cull-Timeout) pro Notebook konfigurierbar
- Starten von Notebooks mit wenigen Klicks
- Einfaches Starten von Notebooks mit GPUs

👎 Einschränkungen:
- Python-Umgebung ist nicht persistent (alle installierten Pakete gehen bei einem Pod-Neustart verloren)
- Keine Möglichkeit, Pakete zu installieren, die Root-Zugriff erfordern
- Keine ordnungsgemäße Möglichkeit zur Verwaltung mehrerer Umgebungen für Experimente
- Kein Endpunkt für das Notebook konfigurierbar [in der nächsten Version hinzugefügt]

Diese Einschränkungen müssen unbedingt behoben werden, da sie viele Data-Science-Workflows blockieren, die so einfach sein können wie die Installation von 'apt-Paketen' wie ffmpeg.

Lösung kritischer Probleme im Benutzer-Workflow

Bis zu diesem Punkt haben wir die von Kubeflow bereitgestellten vorgefertigten Images für JupyterLab verwendet. Da wir jedoch das Problem der nicht-persistenten Umgebungen lösen, Root-Zugriff gewähren und apt-Pakete installieren müssen, benötigen wir eigene Docker-Images.
Schauen wir uns also an, wie wir diese Probleme gelöst haben!

• Nicht-persistente Umgebungen: Ziel war es, die Basis-Python-Umgebung persistent zu machen, damit Benutzer Notebooks problemlos für ihre Anwendungsfälle nutzen können.

- Das Init-Skript des Docker-Image wurde modifiziert, die Basis-Conda-Umgebung in das Home-Verzeichnis kloniert und mit dem Namen jupyter-base benannt
- Eine .condarc-Datei hinzugefügt und das Verzeichnis $HOME als Standardumgebungspfad festgelegt
- Die .bashrc-Datei modifiziert, um die Umgebung jupyter-base standardmäßig zu aktivieren

• Apt-Pakete installieren
  Der Benutzer hat die Option, eine Liste von apt-Paketen anzugeben, die vorab mit dem Image installiert werden sollen.
  Wir fügen dann eine Build-Stufe hinzu und erstellen ein benutzerdefiniertes Image, das mit allen angegebenen Paketen vorinstalliert im Notebook geliefert wird!

• Bereitstellung von Root-Zugriff
  In vielen Fällen benötigt der Benutzer Root-Zugriff, um einige Pakete zu installieren und Dinge schnell auszuprobieren. Dafür haben wir für jeden Image-Typ zwei Images erstellt:
  truefoundrycloud/jupyter:latest und truefoundrycloud/jupyter:latest-sudo, wobei die Images mit sudo dem Benutzer passwortlosen sudo-Zugriff gewähren.
  Dies wurde erreicht, indem die sudo-Binärdatei installiert und der Benutzer zur Sudoers-Liste hinzugefügt wurde, wie unter diesem Link beschrieben.

Hinweis: Da wir Notebooks auf Kubernetes mit eingebundenem Home-Verzeichnis ausführen, ist nur das Home-Verzeichnis persistent. Die Installationen von Root-Paketen bleiben über Pod-Neustarts hinweg nicht bestehen. Bitte lesen Sie dies für ein besseres Verständnis.

Durch die Lösung dieser Probleme haben wir die meisten Hürden für Benutzer beseitigt und ein solides Notebook-Erlebnis bereitgestellt. Im Laufe der Zeit stellten wir jedoch fest, dass Benutzer vor einigen Herausforderungen standen, die wir im nächsten Abschnitt beschreiben.

Benutzerfreundlichkeitsprobleme bei Notebooks

• Schwierige Überwachung der Ressourcennutzung (CPU und Speicher für ein Notebook): Der Kernel stürzt sehr häufig aufgrund von Out-Of-Memory-Problemen (OOM) ab. Wir stoßen oft auf Szenarien, in denen wir ein Notebook ausführen und der Kernel aus dem einen oder anderen Grund abstürzt, was schwierig zu debuggen sein kann.

• Änderungen an der Python-Umgebung können manchmal zu einem fehlerhaften Zustand führen, in dem der Notebook-Server nicht neu startet. Dies kann mehrere Ursachen haben, z. B. wenn jemand das Paket jupyterlab deinstalliert. Da die Umgebung persistent ist, startet das Notebook nicht mehr (sobald das aktuelle Notebook gestoppt ist).
• Die Verwaltung mehrerer Umgebungen ist möglich. Der Benutzer muss jedoch die Conda-Umgebung manuell zu kernelspec hinzufügen und sicherstellen, dass kernelspec korrekt konfiguriert ist, was zu Problemen führen kann.

Lösung der Benutzerfreundlichkeitsprobleme

Hinzufügen von Metriken zur Ressourcennutzung im Notebook:
Wir haben Metriken zur Ressourcennutzung im Notebook hinzugefügt, indem wir die Erweiterung jupyterlab-system-monitor==0.8.0 installiert und ihre Einstellungen im Init-Skript durch Übergabe von Argumenten beim Starten des JupyterLab-Servers konfiguriert haben.

...


jupyter lab \
   ...
   --ResourceUseDisplay.mem_limit=${mem_limit} \
   --ResourceUseDisplay.cpu_limit=${cpu_limit} \
   --ResourceUseDisplay.track_cpu_percent=True \
   --ResourceUseDisplay.mem_warning_threshold=0.8


So sieht es auf der Benutzeroberfläche aus:

Trennung des Kernels, der den JupyterLab-Server ausführt, vom Ausführungskernel

Wir müssen sicherstellen, dass das Notebook unabhängig von den Änderungen des Benutzers im Home-Verzeichnis immer ohne Probleme neu startet. Dafür haben wir die 'base'-Anaconda-Umgebung aus dem Verzeichnis /opt/conda verwendet, um den JupyterLab-Server zu starten.
Zusätzlich haben wir eine separate Umgebung im Verzeichnis $HOME erstellt, wodurch jedoch ein Kernel der Conda-Umgebung base zur Kernel-Liste hinzugefügt wird.

Um dies zu lösen, haben wir nb_conda_kernels zur Verwaltung von Jupyter-Kerneln installiert. Wir haben das Init-Skript so konfiguriert, dass nur die persistenten Python-Umgebungen in der Kernel-Liste angezeigt werden.

jupyter lab \
   ...
   --CondaKernelSpecManager.conda_only=True \
   --CondaKernelSpecManager.name_format={environment} \
   --CondaKernelSpecManager.env_filter=/opt/conda/*"


Damit garantieren wir, dass der Notebook-Server immer startet, unabhängig davon, welche Änderungen ein Benutzer im Notebook vornimmt.
Es vereinfacht auch die Verwaltung mehrerer Kernel. Sie müssen lediglich eine neue Conda-Umgebung mit dem Befehl conda create -n myenv erstellen, und sie erscheint automatisch in der Kernel-Liste.

Hinzufügen von Code-Server-Unterstützung

Während Jupyter Notebooks viele Probleme lösen, gibt es eine Reihe von Aufgaben, bei denen sie an ihre Grenzen stoßen:

1. Entwicklung eines Service wie einer einfachen Gradio- oder Streamlit-App. Benutzer können den Code in Jupyter Notebook schreiben und ausführen, den Service jedoch nicht im Browser anzeigen.
2. Wenn ein Benutzer an einem Projekt arbeitet, dessen Code auf mehrere Dateien verteilt ist, ist die JupyterLab-Umgebung für diese Entwicklung nicht gut geeignet.

Angesichts dieser Einschränkungen haben wir uns entschieden, Abhilfe zu schaffen. Wir haben Code-Server-Unterstützung hinzugefügt, um den Benutzern eine vollständige IDE-Erfahrung im Browser zu bieten.

Durch das Hinzufügen von VS Code-Unterstützung ermöglichen wir Benutzern Folgendes:

1. Entwickeln und Testen von Services direkt in Ihrem Browser mit dem Port-Forwarding-Proxy von VS Code. Das bedeutet, dass Ihre bereitgestellten Services localhost:8000 unter ${NOTEBOOK_URL}/proxy/8000 verfügbar gemacht werden können.
2. Einfache Codeverwaltung mit ordnungsgemäßen Paketen, da dies eine vollständige IDE-Erfahrung bietet.
3. Nutzung aller bekannten VS Code-Erweiterungen zur Steigerung der Produktivität.
4. Einfaches Debuggen von Anwendungen, indem sie im Debug-Modus ausgeführt und Breakpoints gesetzt werden.

Dies wurde durch Hinzufügen eines weiteren Docker-Image erreicht. Hier ist ein Diagramm, das die Docker-Images von TrueFoundry zeigt.

SSH-Zugriff auf Ihr Notebook/VS Code:

In den meisten Fällen kann gehostetes VS Code das Problem lösen. Es gibt jedoch Fälle (insbesondere bei Jupyter Notebooks), in denen der Benutzer nicht weiterkommt und direkten Zugriff auf den Container benötigt, auf dem sein Jupyter Notebook / VS Code Server läuft.
Deshalb haben wir dies vereinfacht, indem wir in jedem Notebook einen SSH-Server installiert haben. Um sich mit Ihrem Container zu verbinden, müssen Sie lediglich einen einfachen Befehl ausführen und Ihr Passwort eingeben:

ssh -p 2222 jovyan@test-notebook.ctl.truefoundry.tech


Die Leistungsfähigkeit dieses Tools kann mit der VS Code-Erweiterung namens Remote Explorer erweitert werden, mit der Sie alle Dateien direkt in Ihrem VS Code öffnen können!
Klicken Sie hier, um mehr darüber zu lesen.

Die finale Benutzererfahrung:

Nachdem alle Funktionen in unsere Notebook-Lösung integriert wurden, sieht unser Notebook-Deployment-Formular wie folgt aus:

Preisvergleich

Vergleichen wir abschließend die Preise der einzelnen verwalteten Lösungen mit TrueFoundry.

Da TrueFoundry durch das Deployment in der Cloud des Kunden über die Anbindung seines Kubernetes-Clusters funktioniert, finden Sie hier die Preise für TrueFoundry bei verschiedenen Cloud-Anbietern.

Im Fall von TrueFoundry können Sie tatsächlich erhebliche Kosten sparen, da:

• Wir keine Aufschläge auf die Kosten der virtuellen Maschinen berechnen.
• Wir die Ausführung von Notebooks auf Spot-Instanzen für Nicht-Produktions-Workloads unterstützen, was zusätzlich 50–60 % an Cloud-Kosten einspart.

Fazit

Dies war ein kurzer Überblick über unsere Arbeit an der Entwicklung der Notebook-Lösung. Sie können unserem Slack-Kanal Friends of TrueFoundry beitreten, wenn Sie unseren Ansatz eingehend diskutieren möchten oder Vorschläge haben.

Wenn Sie unsere Plattform ausprobieren möchten, können Sie sich hier registrieren!