Machine Learning Deployments im Jahr 2023

Das Deployment von Anwendungen und Infrastruktur ist ein komplexer Prozess und erfordert die Abstimmung zwischen Infra- und Anwendungsentwicklerteams. Eine interne Entwicklerplattform hilft beiden Teams, schneller und mit weniger Fehlern zu agieren – was zu höherer Produktivität bei gleichzeitig hoher Stabilität führt.

Wichtige Aspekte bei Deployment und Software-Lebenszyklus

1. Dockerisierung – Das Paketieren von Abhängigkeiten mit exakter Versionsfixierung ist wichtig für die Reproduzierbarkeit. Docker-Images mit unnötigen Abhängigkeiten können aufgebläht werden, was zu höheren Startzeiten führt.
2. Wahl der Deployment-Art: Es gibt viele Optionen für das Deployment – Webservices, Jobs, Serverless-Methoden, statische Websites. Jede Methode hat ihre eigenen Vor- und Nachteile und eignet sich am besten basierend auf Traffic-Mustern, Latenzanforderungen, Speicher- und CPU-Anforderungen.
3. Skalierbarkeit – Skalierung bringt viele Herausforderungen mit sich und erfordert die ordnungsgemäße Konfiguration von Skalierungsrichtlinien, das Konfigurieren von Autoscalern sowie die Sicherstellung, dass unsere Dienste zustandslos (stateless) sind – bei gleichzeitiger Kostenoptimierung.
4. Monitoring und Debuggbarkeit – Wie vergleicht man verschiedene Softwareversionen? Das Beobachten von Logs, Metriken sowie das Erfassen benutzerdefinierter Metriken und deren Visualisierung auf Dashboards sollte sehr einfach sein.
5. Secrets Management und Sicherheit – Es muss Unterstützung für ordnungsgemäßes Secret Management geben sowie die Möglichkeit, den Zugriff auf andere Systeme über Service Accounts bereitzustellen, anstatt Anmeldedaten im Umlauf zu haben.
6. Automatisierung und CI/CD – Eine gute CI/CD-Pipeline ist entscheidend für eine schnelle Entwicklung und das Erkennen von Fehlerbehebungen. Die Möglichkeit, neue Umgebungen nahtlos mit einem Klick zu erstellen, sowie der automatisierte Wechsel von Develop über Staging zu Production macht den Prozess wesentlich reibungsloser.
7. Versionierung, unveränderliche Deployments und Rollbacks – Es sollte einfach sein, Deployments zusammen mit den Secret-Werten zurückzurollen. In allen derzeitigen Systemen ist es heute fast unmöglich, ein Deployment mit dem letzten Satz an Umgebungsvariablen oder Secret-Werten zurückzusetzen.
8. Multiple Umgebungen: Das Verwalten mehrerer Umgebungen oder das dynamische Hoch- und Herunterfahren von Umgebungen hilft Entwicklern, isolierter zu testen, und beschleunigt den Gesamtfortschritt bei geringeren Kosten.
9. API-Sicherheit und Authentifizierung – Authentifizierung von APIs sowohl extern als auch intern – einfache Benutzername-Passwort-Authentifizierung, OIDC-Authentifizierung, Service Account oder Bearer Token?
10. Rate Limiting und Load-Balancer-Konfiguration – Allgemeine Best Practices, die für jede API integriert werden sollten (Load-Balancer-Konfiguration).
11. Geschwindigkeit und Autonomie beim Deployment – Entwickler sollten die Kontrolle über die Deployments behalten, anstatt davon abstrahiert zu werden. Ein Kernziel der Plattform ist es, sie einzubinden und autonom zu machen, während sichergestellt wird, dass die Kern-Infrastruktur nicht durch menschliche Fehler beschädigt wird.
12. Kostenoptimierung – Die Auswahl der besten Hardware und der besten Deployment-Art hilft bei der Optimierung.
13. Koordination von Infra- und Anwendungsänderungen: Beim Wechsel von einer Umgebung in eine andere müssen oft auch Infrastrukturänderungen ausgerollt werden – werden diese übersehen, führt dies zu Anwendungsfehlern in der Produktion.
14. A/B-Testing / Traffic Shaping

Vorstellung von TrueFoundry

Eine Deployment-Plattform, die als internes Entwicklerportal (Internal Developer Platform) für ein Unternehmen dienen kann. Das Ziel besteht darin, es Entwicklern sehr einfach zu machen, ihre Anwendungen ohne detaillierte Infrastrukturkenntnisse zu deployen und zu warten, sowie es Infra-/DevOps-Teams zu erleichtern, Richtlinien zur Durchsetzung von Engineering- und Sicherheits-Best-Practices zu erstellen.

Was sind die zentralen Designprinzipien hinter der TrueFoundry-Plattform?

1. Vollständig API-getriebene Architektur – TrueFoundry folgt einer vollständig API-getriebenen Architektur, sehr ähnlich wie Kubernetes. Dies ermöglicht es Benutzern, Schnittstellen, UIs und Automatisierungen darauf aufzubauen.
2. Erweiterbare PaaS auf Kubernetes – Kann mit mehreren Plugins für die Kernfunktionen von Kubernetes angepasst werden.
3. GitOps-getrieben (unterstützt auch einen Nicht-GitOps-Modus)
4. Feingranulare Zugriffskontrolle von Tag 1 an
5. Infrastructure as Code (Terraform) – Kann in kürzester Zeit in jedem Cloud-Konto bereitgestellt werden.
6. Security by Default – TrueFoundry folgt dem POLP-Prinzip (Principle of Least Privilege) und nutzt Sicherheits-Best-Practices wie Service Accounts, TLS, Datenverschlüsselung im Ruhezustand (Data at Rest) und Unterstützung für Air-Gapped-Umgebungen.
7. Cloud-Native by Design – Wir entscheiden uns bewusst für Komponenten, die von Grund auf Cloud-Native sind und bei allen Cloud-Providern zur Verfügung stehen.

In TrueFoundry unterstützte Hauptfunktionen

Verschiedene Deployment-Methoden über mehrere Clouds hinweg:

Verschiedene Workloads können je nach Traffic-Muster, CPU- und Speicherverbrauch für unterschiedliche Deployment-Methoden geeignet sein. Das Ziel ist es, eine einzige Schnittstelle für das Deployment über mehrere Systeme hinweg bereitzustellen – wie Services auf Kubernetes, Jobs auf Kubernetes, AWS Lambda, Serverless auf Kubernetes (Knative), Google Cloud Run, Model Server. TrueFoundry integriert sich mit Git-Repositories, um das Deployment direkt aus jedem Git-Repo zu ermöglichen.

Protokollierung und Visualisierung von Metriken und Grafiken über Jobs hinweg

TrueFoundry ermöglicht es Entwicklern, detaillierte Metriken, Parameter, Images, Plots und Artefakte zu protokollieren, sodass sie Job-Läufe mithilfe detaillierter Dashboards vergleichen können.

Software Canary / Shadow Testing

TrueFoundry macht es sehr einfach, neue Softwareversionen mit Livedaten zu testen, ohne die bestehende Produktion zu beeinträchtigen – durch Shadow Testing. Es ermöglicht auch das Canary-Rollout von Software durch schrittweise Verlagerung des Traffic auf die neuen Versionen.

Secrets Management

Entwickler können Secrets erstellen und in ihren Anwendungen darauf verweisen. Wichtige Funktionen des Secret Managements:

1. Der Secret-Speicher wird durch Secret Stores wie Vault, AWS Secrets Manager, Google Secrets Manager, AWS Parameter Store etc. gesichert. Keiner der eigentlichen Secret-Werte wird auf der Plattform selbst gespeichert.
2. Die Plattform verfolgt, welches Secret in welcher Anwendung verwendet wird – sodass Benutzer bei einer Änderung eines Secrets aufgefordert werden können, die entsprechenden Dienste neu zu deployen.
3. Die Plattform verwaltet Secret-Versionen, was das Rollback von Anwendungen zusammen mit den entsprechenden Secret-Versionen ermöglicht.

Zugriffskontrolle für Secrets – Betrachter können die Schlüssel (Keys) der Secrets sehen, jedoch nicht die Werte der Secrets. Auf diese Weise kann das DevOps-/Infra-Team die Schlüssel mit den Entwicklern teilen, ohne sich Sorgen machen zu müssen, dass die Werte offengelegt werden.

Multi-Cluster-Management und Deployment

TrueFoundry ermöglicht die Integration mehrerer Cluster und die Verwaltung der Zugriffskontrolle über diese hinweg. TrueFoundry speichert die Cluster-Anmeldedaten nirgendwo bei sich selbst, was es für verschiedene Benutzer im Unternehmen sicher macht.

Zugriffskontrolle auf Kubernetes für verschiedene Teams

TrueFoundry macht es einfach, die Zugriffskontrolle auf Kubernetes-Namespaces anzuwenden und diese verschiedenen Teams mit Ressourcen-Quotas zuzuweisen. Dies ermöglicht Entwicklern mehr Autonomie, während sichergestellt wird, dass die Infrastruktur stabil, kostenkontrolliert und sicher bleibt.

Grundlegende Monitoring- und Logging-UIs direkt auf der Plattform einsehbar

TrueFoundry schreibt Ihnen nicht vor, welche Logging- oder Metrik-Plattform Sie verwenden müssen. Das Ziel besteht stattdessen darin, sich mit einigen gängigen Logging- und Monitoring-Lösungen zu integrieren, damit wir einen schnellen Überblick direkt auf der Plattform anzeigen können. Für detailliertere und anpassbare Ansichten empfehlen wir die Verwendung bestehender Monitoring-Lösungen wie Prometheus, Loki, ELK, Datadog oder NewRelic.

Einheitliche Ansicht aller deployten und laufenden Dienste (Service Catalog)

Kostenschätzung und -optimierung pro Dienst / Team / Entwickler.

Wir möchten die Nachverfolgung von Kostenschätzungen und -optimierungen auf Dienst- oder Teamebene ermöglichen. Allein das Aufzeigen der Kostentransparenz für jeden einzelnen Ingenieur schafft das Bewusstsein, Kosten zu optimieren und ein einzelnes Team zu entlasten.

Jedes Terraform-Modul deployen (wodurch das Deployment von verwalteten Datenbanken, Queues oder Caching-Diensten ermöglicht wird)

Wir möchten das Deployment von Cloud-Diensten unter Verwendung von Terraform-Modulen ermöglichen, die vom DevOps- oder Infra-Team geschrieben wurden. Beispielsweise kann das DevOps-Team ein Terraform-Modul zum Erstellen einer Datenbank erstellen, und Entwickler können über die Benutzeroberfläche eine Datenbank basierend auf dem Terraform-Modul für RDS bereitstellen. Dies basiert auf dem unten genannten Plugin-Framework und einem Terraform-Controller auf Kubernetes.

Wird TrueFoundry mit meinem bestehenden Stack funktionieren?

Bei TrueFoundry wollen wir das Rad nicht neu erfinden und nutzen so weit wie möglich bestehende Systeme. Deshalb integrieren wir uns in viele bestehende Infrastruktur-Tools, sodass Benutzer ihre eigene Infrastruktur mitbringen oder TrueFoundry nach ihren eigenen Bedürfnissen anpassen können.

1. Cloud-Konten (AWS, GCP, Azure) – hilft uns, Cluster automatisch bereitzustellen, Lambda zu erstellen und verwaltete Dienste zu deployen.
2. Git-Integration (GitHub, Bitbucket, Azure) – hilft Entwicklern, ihre Anwendung direkt aus ihren Git-Repositories zu deployen.
3. Secret Stores (AWS Secrets Manager, Google Secrets Manager, HashiCorp Vault) – auf diese Weise werden die tatsächlichen Werte der Secrets in den Secret Stores und nicht auf der Plattform gespeichert.
4. Docker Registry – Docker Hub, Google GCR, Amazon ECR, GitHub Docker Registry.
5. Terraform-Integration.
6. Monitoring-Integrationen: Prometheus, Grafana, Datadog, NewRelic.
7. Logging-Infrastruktur-Integrationen – Loki, Datadog, ELK-Stack.
8. CI/CD-Integration – TrueFoundry kann mit bestehenden CI/CD-Pipelines wie GitHub Actions, Jenkins, AWS CodeBuild, Google Cloud Build usw. integriert werden.

Wenn Sie hier keinen Namen auf der Liste sehen, arbeiten wir gerne mit Ihnen zusammen, um weitere Integrationen hinzuzufügen.

Wie erhöht TrueFoundry die Sicherheit?

POLP-Prinzip

Wir folgen dem POLP-Prinzip und machen es Infra-Teams leicht, dieses im gesamten Stack durchzusetzen. Entwickler können zu den Workspaces hinzugefügt werden, auf die sie Zugriff benötigen – und ihre Änderungen werden auf diese Workspaces beschränkt.

Keine Secrets oder Passwörter auf der TrueFoundry-Plattform gespeichert

TrueFoundry speichert keine sensiblen Informationen wie Kubernetes-Zugangsdaten oder Secrets bei sich selbst. Alle Daten sind im Ruhezustand (at REST) verschlüsselt. Wir empfehlen, jeglichen Zugriff über Service Accounts bereitzustellen.

Wir planen außerdem die Bereitstellung vollständiger Audit-Logs, die Teams helfen, alle plattformübergreifend durchgeführten Aktionen nachzuvollziehen.

Wie ist TrueFoundry offen und anpassbar?

Kubernetes-Cluster bleibt unter Ihrer Kontrolle

TrueFoundry legt den rohen Kubernetes-Cluster offen, auf dem Workloads deployt werden, und bietet Kunden vollen Zugriff (einschließlich kubectl mit entsprechenden Berechtigungen). Dies ermöglicht es jedem, praktisch alles zusätzlich zu TrueFoundry zu tun, ohne jemals blockiert zu werden.

Darüber hinaus unterstützen wir ein Plugin-Framework, mit dem sich ganz einfach weitere Plugins erstellen lassen – ähnlich wie CRDs auf Kubernetes.

Erstellung benutzerdefinierter Plugins auf TrueFoundry

TrueFoundry unterstützt jede Deployment-Methodik als benutzerdefiniertes Plugin:

Um ein Plugin zu erstellen, muss der Benutzer 3 Teile schreiben:

1. Eine Eingabe-Cue-Datei, die die Spezifikation des Eingabeschemas definiert.
2. Einen Processor, der definiert, wie die Eingabespezifikation in eine Ausgabespezifikation umgewandelt wird.
3. Eine Ausgabespezifikation, die an Kubernetes gesendet wird.

Derzeit müssen die Eingabe- und Ausgabespezifikationen in Cue Lang geschrieben sein und der Processor in Go. In Zukunft können wir jedoch auch Eingabe- und Ausgabeschemas in JSON Schema sowie Processors in jeder beliebigen Sprache zulassen.

Wir generieren die Benutzeroberfläche und die Python-Schnittstellen automatisch aus den Eingabe-Cue-Dateien.

Wie erfolgt das Onboarding auf TrueFoundry?

Einrichtung der Infrastruktur durch Infra-/DevOps-Teams:

1. Erstellen von Kubernetes-Clustern mit Terraform. TrueFoundry bietet Beispiel-Terraform-Code, der Cluster mit 1 Klick bereitstellen kann, während der Terraform-Code in ein GitHub-Repo committet wird. DevOps-/Infra-Teams können den Terraform-Code nach eigener Wahl anpassen und neu anwenden.
2. Erstellen von Service Accounts über Terraform, um Zugriff auf andere Infrastrukturen aus Kubernetes-Namespaces bereitzustellen.
3. Hinzufügen der Service Accounts zu Workspaces auf der TrueFoundry-Plattform und Zuweisen von Workspaces zu verschiedenen Teams.
4. TrueFoundry bootstrappt den Kubernetes-Cluster mit einem Standard-Monitoring-Stack (Kube-Prometheus-Loki-Grafana-Stack), Istio (Ingress) und ArgoCD (Infra-Deployment). TrueFoundry legt die Manifest-Dateien in einem GitHub-Repository ab, das dann vom Infra-Team nach Bedarf geändert werden kann.
5. Für das Deployment von verwalteter Infrastruktur können Infra-Teams die Terraform-Module für DB, Queue, Cache usw. bereitstellen. Entwickler können diese Infrastruktur dann über die vom Infra-Team bereitgestellten Module instanziieren.
6. Onboarding von Entwicklern auf die Plattform.
7. Zuweisen von Workspaces zu Teams / Anwendungen.
8. Entwickler können dann anhand der Dokumentation in kürzester Zeit mit dem Deployment beginnen.

Wie funktioniert TrueFoundry?

TrueFoundry besteht aus 2 Komponenten – der Control Plane und einem Workload-Cluster-Agenten. Dies ermöglicht TrueFoundry die Orchestrierung von Workloads über mehrere Cluster hinweg.

Abgrenzung zu anderen Plattformen

Architektur

1. Multi-Cluster von Tag 1 an: TrueFoundry unterstützt Multi-Cluster von Tag 1 an, wobei Cluster über Regionen und VPCs hinweg verteilt sowie privat/öffentlich sein können. Dies ist in der aktuellen Architektur von Porter und Northflank sehr schwierig. Die Architektur von Komodor kann dies zwar, konzentriert sich jedoch mehr auf Kubernetes-Visualisierung und -Monitoring, was auf unserer Plattform standardmäßig enthalten ist.
2. Multi-Cloud von Tag 1 an: Dies trifft auf Porter, Northflank und Qovery zu, allerdings nur auf der Kubernetes-Ebene. Unsere Architektur unterstützt aufgrund ihrer Offenheit die Integration mit viel mehr Cloud-Native-Komponenten. Argonaut tut dies auf derselben breiteren Ebene wie wir.
3. Vollständige Transparenz und GitOps – Wir folgen einem Modell vollständiger Transparenz, bei dem der Benutzer die volle Kontrolle über seine Architektur hat und zu keinem Zeitpunkt von TrueFoundry blockiert wird. Im Fall von Porter, Northflank und Qovery werden größere Unternehmen aufgrund der geschlossenen Architektur irgendwann an die Grenzen der Funktionen stoßen. Wir ermöglichen außerdem sowohl einen GitOps- als auch einen Nicht-GitOps-Modus, was bisher niemand anbietet – Porter, Northflank und Qovery sind nicht-GitOps-push-basiert, während CoSphere vollständig Git-basiert ist.

Einheitliches Deployment von Anwendung und Infrastruktur

Wir integrieren uns sehr tief in Anwendungen, Jobs und ML-Deployments. Dies übersetzt viel Infrastrukturwissen in Entwickler-Begrifflichkeiten. Viele andere Plattformen tun dies, indem sie Abstraktionen aufbauen und Infrastrukturkonzepte reduzieren – während wir versuchen, Dinge zu vereinfachen, anstatt sie zu verbergen.

Argonaut verfolgt diesen Ansatz, sowohl Infrastruktur als auch Anwendungs-Deployment zusammenzubringen – dies ist jedoch ein 2–3-jähriger Produktzyklus. Sie haben mehr auf der Infrastrukturseite begonnen.

Plugins

Unsere plugin-basierte Architektur basiert auf dem Kubernetes-CRD-Framework mit unserer eigenen Note von CueLang. Dies gibt uns die Möglichkeit, Plugins auf CLI, UI und allen Sprachen sehr schnell bereitzustellen. Dies wurde vom Design von KubeVela (einem Open-Source-Repo) inspiriert – wir kennen keinen anderen Akteur, der dieses Muster gelöst hat. Dies ist eine unserer proprietären Entwicklungen, die es uns ermöglicht, viel schneller als andere Anbieter zu bauen.

Transparenz

Wir versuchen so transparent wie möglich zu sein, indem wir den vollständigen Quellcode bereitstellen – was eine Migration von uns weg sehr einfach macht. Nur Porter und purple.sh scheinen dies zu garantieren – alle anderen sind sehr geschlossene Systeme.

Einblicke (Insights)

Wir zeigen bereits einzigartige Einblicke und verhindern die häufigsten Fehler beim Software-Deployment, wie das Nicht-Ändern von Umgebungsvariablen beim Deployment. Wir kennen keine andere Plattform, die dies tut oder tun kann wie wir, da wir sowohl die Secret-Historie als auch die Deployment-Historie kennen. Wir können auch viele Einblicke in Kosten, Stabilität und Entwicklerproduktivität generieren, da wir die Code-Pipeline vom Quellcode bis zur Produktion sehen.

Ersatz für Plattform-Teams

Unsere Plattform ist so konzipiert, dass sie eher dem gleicht, was Plattform-Teams intern aufbauen. Sie adressiert die zentralen Probleme der Ressourcenzuweisung, Sicherheit und Abstraktionen für Entwickler. Porter und Northflank ähneln eher Heroku. Qovery und Argonaut sind eher ein Ersatz für DevOps in kleineren Unternehmen. Humanitec und Shipa sind eher für Plattform-Teams konzipiert, aber wir fanden ihre Abstraktionen recht schwer nachzuvollziehen und zu verstehen.