Déploiements de machine learning en 2023

Le déploiement des applications et de l'infrastructure est un processus complexe qui nécessite la coordination des équipes d'Infra et de développeurs d'applications. Une plateforme de développement interne aide les deux équipes à agir rapidement avec moins d'erreurs, ce qui se traduit par une productivité accrue et une plus grande stabilité.

Principaux éléments à prendre en compte lors du déploiement et du cycle de vie des logiciels

1. Dockerisation — L'empaquetage des dépendances avec épinglage de version est important pour la reproductibilité. Les images Docker présentant des dépendances inutiles peuvent gonfler les images Docker, ce qui entraîne des temps de démarrage plus longs.
2. Choix du mode de déploiement : Il existe de nombreuses options de déploiement (services Web, tâches, méthodes sans serveur, site Web statique), chacune d'entre elles a ses avantages et ses inconvénients et peut constituer la meilleure méthode en fonction des modèles de trafic, des exigences de latence, de la mémoire et des besoins en processeur.
3. Évolutivité — La mise à l'échelle pose de nombreux problèmes et nécessite une configuration appropriée des politiques de dimensionnement, la configuration des autoscalers, la garantie de l'état de nos services, tout en optimisant les coûts.
4. Surveillance et débogage — Comment comparer les différentes versions d'un logiciel ? L'observation des journaux, des métriques, la journalisation des métriques personnalisées et leur observation sur des tableaux de bord devraient être très faciles.
5. Gestion des secrets et sécurité — Il est nécessaire de prendre en charge une gestion adéquate des secrets et de fournir un accès à d'autres systèmes à l'aide de comptes de service plutôt que de diffuser des informations d'identification.
6. Automatisation et CI/CD — Il est essentiel de disposer d'un bon pipeline CI/CD pour un développement rapide et la détection des bogues. Pouvoir créer de nouveaux environnements de manière fluide en un clic. Le fait de pouvoir passer du développement à la mise en scène et à la production de manière automatisée rend le processus beaucoup plus fluide.
7. Versionnage, déploiements immuables et rollbacks — Il devrait être facile d'annuler les déploiements ainsi que les valeurs secrètes. Dans tous les systèmes actuels, il devient quasiment impossible d'annuler un déploiement avec le dernier ensemble de variables d'environnement ou de valeurs secrètes.
8. Environnements multiples : Le fait de pouvoir gérer plusieurs environnements ou de lancer ou de désactiver des environnements dynamiques permet aux développeurs de tester de manière plus isolée et de progresser globalement beaucoup plus rapidement à moindre coût.
9. Sécurité et authentification des API — Authentification des API à la fois en externe et en interne — authentification simple par nom d'utilisateur et mot de passe, authentification OIDC, compte de service, jeton porteur ?
10. Configuration de la limitation de débit et de l'équilibreur de charge — Bonnes pratiques générales à intégrer pour chaque API (configuration Load Balancer)
11. Rapidité et autonomie de déploiement — Les développeurs doivent avoir le sentiment de contrôler les déploiements au lieu de s'en éloigner. Les tenir informés et les rendre autonomes tout en s'assurant que l'infrastructure centrale ne se brise pas à cause d'erreurs humaines est l'un des principaux objectifs de la plateforme.
12. Optimisation des coûts — Le choix du meilleur matériel et du meilleur type de déploiement permet d'optimiser cela.
13. Coordination des modifications apportées à l'infrastructure et aux applications : Lors du passage d'un environnement à un autre, des modifications d'infrastructure doivent souvent également être déployées, ce qui, en cas d'échec, entraînera une interruption de la production de l'application.
14. AB Testing/Traffic Shaping

Vous vous présentez TrueFoundry ?

Plateforme de déploiement pouvant servir de plateforme de développement interne à une entreprise. L'objectif ici est de permettre aux développeurs de déployer et de maintenir leurs applications très facilement sans connaissances détaillées de l'infrastructure et de permettre également aux équipes infra/devops de créer facilement des politiques visant à appliquer les meilleures pratiques d'ingénierie et de sécurité.

Quels sont les principes de conception clés de la plateforme TrueFoundry ?

1. Architecture entièrement pilotée par API — TrueFoundry suit une architecture entièrement pilotée par API très similaire à Kubernetes. Cela permet aux utilisateurs de créer des interfaces, des interfaces utilisateur et des automatisations en plus de cela.
2. PAAS extensible sur Kubernetes — peut être personnalisé à l'aide de plusieurs plugins selon les principales fonctionnalités autorisées par Kubernetes.
3. piloté par Gitops (prend également en charge un mode non Gitops)
4. Contrôle d'accès précis dès le premier jour
5. Infrastructure en tant que code (Terraform) : peut être déployée sur n'importe quel compte cloud en un rien de temps.
6. Sécurité par défaut — Truefoundry suit le principe POLP (Principe du moindre privilège) et utilise les meilleures pratiques de sécurité, telles que l'utilisation de comptes de service, le protocole TLS, le chiffrement des données au repos et la prise en charge d'environnements isolés.
7. Cloud Native par conception — Nous choisissons délibérément des composants conçus pour le cloud et disponibles chez tous les fournisseurs de cloud.

Principales fonctionnalités prises en charge dans TrueFoundry

Différentes méthodes de déploiement dans les clouds :

Différentes charges de travail peuvent convenir à différentes méthodes de déploiement en fonction du modèle de trafic, du processeur et de la consommation de mémoire. L'objectif est de fournir une interface unique pour le déploiement sur plusieurs systèmes, tels que le service sur Kubernetes, les jobs sur Kubernetes, AWS Lambda, les serveurs sans serveur sur Kubernetes (Knative), Google Cloud Run, les serveurs modèles. Truefoundry s'intègre aux référentiels Git pour permettre le déploiement directement depuis n'importe quel dépôt Git.

Enregistrement et visualisation des mesures et des graphiques pour toutes les tâches

TrueFoundry permet aux développeurs d'enregistrer des statistiques détaillées, des paramètres, des images, des tracés et des artefacts, ce qui leur permet de comparer les exécutions de tâches à l'aide de tableaux de bord détaillés.

Logiciel Canary/Shadow Testing

TrueFoundry permet de tester très facilement de nouvelles versions du logiciel sur des données en temps réel sans nuire à la production existante, grâce à des tests parallèles. Il permet également le déploiement du logiciel Canary en transférant progressivement le trafic vers les nouvelles versions.

Gestion des secrets

Les développeurs pourront créer des secrets et les référencer dans leurs applications. Voici quelques-unes des principales caractéristiques de la gestion des secrets :

1. Le stockage secret est soutenu par des magasins de secrets tels que Vault, AWS Secrets Manager, Google Secrets Manager, AWS Parameter Store, etc. Aucune des valeurs secrètes réelles n'est stockée sur la plateforme elle-même.
2. La plateforme conserve une trace du secret utilisé dans chaque application, de sorte que chaque fois qu'un secret est modifié, elle peut inviter les utilisateurs à redéployer les services correspondants.
3. La plate-forme gère des versions secrètes qui permettent la restauration des applications ainsi que les versions secrètes correspondantes.

Contrôle d'accès aux secrets — Les spectateurs peuvent voir les clés des secrets mais pas les valeurs des secrets. De cette façon, l'équipe devops/infra peut partager les clés avec les développeurs sans se soucier d'exposer la valeur des secrets.

Gestion et déploiement de clusters multiples

Truefoundry permet l'intégration à plusieurs clusters et la gestion du contrôle d'accès entre eux. Truefoundry ne stocke les informations d'identification du cluster nulle part sur lui-même, ce qui le rend sécurisé pour les différents utilisateurs de l'entreprise.

Contrôle d'accès sur Kubernetes pour différentes équipes

Truefoundry permet de contrôler facilement l'accès aux espaces de noms Kubernetes et de les attribuer à différentes équipes avec des quotas de ressources, ce qui permet aux développeurs d'être plus autonomes tout en garantissant la stabilité, la maîtrise des coûts et la sécurité de l'infrastructure.

UI de surveillance et de journalisation de base directement consultables sur la plateforme

TrueFoundry ne donne aucune opinion sur la plateforme de journalisation ou de métriques que vous souhaitez utiliser. L'objectif ici est plutôt de l'intégrer à quelques solutions de journalisation et de surveillance courantes afin que nous puissions avoir un aperçu rapide de la plateforme elle-même. Pour des vues plus détaillées et personnalisables, nous vous recommandons d'utiliser les solutions de surveillance existantes telles que Prometheus, Loki, ELK, Datadog ou NewRelic.

Vue unifiée de tous les services déployés et en cours d'exécution (catalogue de services)

Estimation et optimisation des coûts par niveau de service, par équipe ou par ingénieur.

Nous voulons permettre de suivre l'estimation et l'optimisation des coûts au niveau du service ou de l'équipe. Le simple fait d'exposer la visibilité des coûts à chaque ingénieur permet de prendre conscience de la nécessité d'optimiser les coûts et d'alléger la charge de travail d'une seule équipe.

Déployez n'importe quel module Terraform (permettant ainsi le déploiement de n'importe quel service de base de données, de file d'attente ou de mise en cache géré)

Nous voulons permettre le déploiement de services cloud à l'aide de modules Terraform écrits par l'équipe DevOps ou Infra. Par exemple, l'équipe devops peut créer un module terraform pour créer une base de données et les développeurs peuvent fournir une base de données à partir de l'interface utilisateur basée sur le module terraform pour RDS. Cela s'appuiera sur le framework de plugins mentionné ci-dessous et sur un contrôleur Terraform sur Kubernetes.

TrueFoundry fonctionnera-t-il avec ma pile existante ?

Chez TrueFoundry, nous ne voulons pas réinventer la roue et utiliser autant que possible les systèmes existants. C'est pourquoi nous intégrons de nombreux outils d'infrastructure existants afin que les utilisateurs puissent apporter leur propre infrastructure ou personnaliser Truefoundry en fonction de leurs propres besoins.

1. Comptes cloud (AWS, GCP, Azure) : cela nous permet de provisionner automatiquement des clusters, de créer des Lambda et de déployer des services gérés.
2. Intégration à Git (Github, Bitbucket, Azure) : elle permet aux développeurs de déployer leur application directement à partir de leurs référentiels Git.
3. Magasins secrets (AWS Secrets Manager, Google Secrets Manager, Hashicorp Vault) : de cette façon, les valeurs réelles des secrets seront stockées dans les magasins secrets et non sur la plateforme.
4. Registre Docker — Dockerhub, Google GCR, Amazon ECR, registre Github Docker
5. Intégration à Terraform
6. Intégrations de supervision : Promethues Grafana, Datadog, NewRelic
7. Intégrations à l'infrastructure de journalisation : Loki, Datadog, ELK stack.
8. Intégration CI/CD — Truefoundry peut s'intégrer aux pipelines CI/CD existants tels que Github Actions, Jenkins, AWS Codebuild, Google Codebuild, etc.

Si aucun nom ne figure dans la liste, nous serons heureux de travailler avec vous et d'ajouter d'autres intégrations à la liste.

Comment TrueFoundry renforce-t-il la sécurité ?

Principe POLP

Nous suivons et permettons aux équipes d'infrastructure d'appliquer facilement le principe POLP à l'ensemble du stack. Les développeurs peuvent être ajoutés à tous les espaces de travail auxquels ils ont besoin d'accéder, et leurs modifications seront limitées à ces espaces de travail.

Pas de secrets, mots de passe stockés sur la plateforme Truefoundry

Truefoundry ne stocke aucune information sensible sur elle-même, comme les informations d'identification Kubernetes ou les secrets. Toutes les données sont cryptées au format REST. Nous vous recommandons de fournir tous les accès via des comptes de service

Nous prévoyons également de fournir des journaux d'audit complets qui aideront les équipes à comprendre toutes les actions entreprises sur toutes les plateformes.

Comment TrueFoundry est-il ouvert et personnalisable ?

Kubernetes Cluster est sous votre contrôle

TrueFoundry expose le cluster Kubernetes brut sur lequel il déploie les charges de travail et fournit un accès complet (y compris kubectl avec les autorisations d'accès appropriées) aux clients. Cela permet à chacun de faire à peu près ce qu'il veut en plus de Truefoundry sans jamais le bloquer.

En outre, nous proposons également un framework de plugins à l'aide duquel il est facile de créer d'autres plugins, comme les CRD sur Kubernetes.

Création de plugins personnalisés sur TrueFoundry

TrueFoundry prend en charge chaque méthodologie de déploiement sous la forme d'un plugin personnalisé :

Pour créer un plugin, l'utilisateur doit écrire 3 parties :

1. Un fichier de repères d'entrée définissant les spécifications du schéma d'entrée
2. Processeur qui définit comment convertir la spécification d'entrée en spécification de sortie
3. Spécification de sortie qui sera envoyée à Kubernetes.

Actuellement, les spécifications d'entrée et de sortie doivent être dans Cue Lang et le processeur doit être en Go. Cependant, à l'avenir, nous pourrons autoriser les schémas d'entrée et de sortie également possibles dans JSON Schema et les processeurs pourront être écrits dans n'importe quel langage.

Nous générons automatiquement l'interface utilisateur et les interfaces python à partir des fichiers de repères d'entrée.

Comment intégrer TrueFoundry ?

Mise en place de l'infrastructure par les équipes infra/devops :

1. Créez des clusters Kubernetes à l'aide de Terraform. Truefoundry fournit un exemple de code terraform qui peut créer des clusters en un clic tout en validant le code terraform dans un dépôt github. Les équipes Devops/Infra peuvent personnaliser le code terraform selon leur choix et réappliquer le terraform.
2. Créez des comptes de service via Terraform pour accéder à d'autres infrastructures à partir des espaces de noms Kubernetes.
3. Ajoutez les comptes de service aux espaces de travail sur la plateforme Truefoundry et attribuez des espaces de travail aux différentes équipes.
4. Truefoundry démarre le cluster Kubernetes avec une pile de surveillance par défaut (pile KUBE-Prometheus-Loki-Grafana), Istio (entrée) et ArgoCD (déploiement infra). Truefoundry déposera les fichiers manifestes dans un référentiel Github qui pourra ensuite être modifié en fonction des besoins de l'équipe infra.
5. Pour déployer une infrastructure gérée, les équipes infra peuvent fournir les modules terraform pour la base de données, la file d'attente, le cache, etc. Les développeurs peuvent ensuite provisionner cette infrastructure à l'aide des modules fournis par l'équipe Infra.
6. Intégrez les développeurs à la plateforme.
7. Attribuez des espaces de travail aux équipes et aux applications.
8. Les développeurs peuvent alors commencer à déployer en un rien de temps en suivant la documentation.

Comment fonctionne TrueFoundry ?

TrueFoundry comprend deux composants : un plan de contrôle et un agent de cluster de charge de travail. Cela permet à TrueFoundry d'orchestrer les charges de travail sur plusieurs clusters.

Différenciation avec les autres plateformes

L'architecture

1. Multi-Cluster dès le premier jour: Truefoundry prend en charge le support multi-clusters dès le premier jour, où les clusters peuvent vivre dans plusieurs régions, dans des VPC et peuvent être privés/publics. Ce sera très difficile dans l'architecture actuelle de Porter et Northflank. L'architecture de Komodor peut le faire, mais elle se concentre davantage sur la visualisation et la surveillance de Kubernetes, qui sont intégrées par défaut à notre plateforme.
2. Multi-Cloud dès le premier jour: Cela sera vrai pour Porter, Northflank, Qovery mais uniquement pour la couche Kubernetes. Notre architecture permet de créer des intégrations avec un plus grand nombre de composants natifs du cloud en raison de son ouverture. Argonaut le fait sur la même couche plus large que nous.
3. Transparence totale et Gitops — Nous suivons un modèle de transparence totale dans lequel l'utilisateur a le contrôle total de son architecture et n'est bloqué par Truefoundry à aucun moment. Dans le cas de Porter, Northflank et Qovery, les grandes entreprises n'auront plus accès à l'ensemble des fonctionnalités en raison de l'architecture fermée. Nous autorisons également un mode Gitops et un mode non-gitops, ce que personne ne fait encore : Porter, Norhtflank, Qovery ne sont pas basés sur Gitops push alors que CoSphere est entièrement basé sur Git.

Déploiement uniforme des applications et de l'infrastructure

Nous nous intégrons très profondément dans les applications, les emplois et le déploiement du ML. Cela traduit une grande partie des connaissances infra en termes de terminologie pour les développeurs. De nombreuses autres plateformes le font en créant des abstractions et en réduisant les concepts d'infra, alors que nous essayons de le faire en simplifiant et en ne cachant pas les choses.

Argonaut adopte cette approche qui consiste à combiner le déploiement de l'infrastructure et celui des applications, mais le cycle de production sera de 2 à 3 ans. Ils ont commencé par s'intéresser davantage à l'infra-face.

Plug-ins

Notre architecture basée sur des plugins est basée sur le framework Kubernetes CRD avec notre propre version de CueLang. Cela nous permet de publier très rapidement des plugins sur la CLI, l'interface utilisateur et toutes les langues. Cela a été inspiré par le design de Kubevela (un dépôt open source) — nous ne connaissons aucun autre joueur qui ait découvert ce modèle. C'est l'une de nos fonctionnalités exclusives qui nous permettra également de construire beaucoup plus rapidement que les autres joueurs.

Transparence

Nous essayons d'être aussi transparents que possible en diffusant le code source complet, ce qui facilite grandement la migration hors de chez nous. Porter et purple.sh ne semblent que le garantir. Les autres sont tous des systèmes très fermés.

Perspectives

Nous présentons déjà des informations uniques et évitons les bogues les plus courants lors du déploiement de logiciels, tels que le fait de ne pas modifier les variables d'environnement lors du déploiement. Nous ne connaissons aucune autre plateforme qui le fasse ou qui puisse le faire comme nous le pouvons, car nous connaissons à la fois l'historique secret et l'historique des déploiements. Nous pouvons également générer de nombreuses informations sur les coûts, la stabilité et la productivité des développeurs car nous voyons le pipeline du code, du contrôle des sources à la production.

Suppléant de l'équipe de

Notre plateforme est conçue pour ressembler davantage à ce que les équipes conçoivent en interne. Il aborde les principaux problèmes liés à l'allocation des ressources, à la sécurité et aux abstractions pour les développeurs. Porter, Northflank ressemblent plus à Heroku. Qovery, Argonaut est plutôt un substitut à Devops pour les petites entreprises. Humanitec et Shipa sont davantage conçus pour les équipes de plateformes, mais nous avons eu du mal à raisonner et à comprendre leurs abstractions.