Développement d'applications avec Kubernetes

Kubernetes est largement considérée comme la plateforme idéale pour les équipes des grandes et moyennes entreprises ayant des exigences élevées en matière de disponibilité et de dimensionnement automatique. Cependant, cela a également ajouté des frictions aux flux de travail existants pour les développeurs. Ce changement peut être compris comme faisant partie d'une tendance plus large vers l'adoption du paradigme des microservices et de la complexité croissante de la façon dont les logiciels sont exécutés. Dans cet article, nous examinerons comment le problème du développement de logiciels a évolué avec ce changement de paradigme.

Boucle de développement

Commençons par le concept de boucle de développement et son rôle dans les flux de travail de développement. La boucle de développement de tout projet logiciel se compose de deux boucles distinctes qui se croisent sur git.

Ce sont les suivants :

• Boucle de développement interne - Le processus implique l'écriture, la compilation et le test d'un morceau de code sur le poste de travail du développeur. Cette boucle se poursuit jusqu'à ce qu'un morceau de code satisfaisant soit déplacé vers Git.
• Boucle de développement externe : cette boucle est déclenchée une fois que le code a été déplacé de la station de travail du développeur vers Git. Cela implique la réalisation de tests et le déploiement du produit final. Idéalement, ce processus devrait être configuré sous la forme d'une boucle continue, dans laquelle les déploiements ont lieu à chaque fois que le code passe les tests.

Ces boucles s'alimentent les unes les autres et constituent un cycle de vie complet de développement logiciel.

L'essor du microservice

L'avènement des microservices a donné naissance à de petits composants logiciels indépendants et faiblement couplés qui offrent une évolutivité et une fiabilité accrues. Nous n'aborderons pas les avantages ici car cela a été très médiatisé, mais nos préoccupations découlent de la complexité opérationnelle accrue qui en résulte.

Considérons une configuration simple où frontend appelle le api, qui communique à son tour avec deux autres services appelés identité et db. Dans ce scénario, notre développeur travaille sur api couche, qui possède à la fois des dépendances en aval (frontend) et en amont (identity, db). Explorons comment le processus de développement du api changements de service dans les deux boucles de développement différentes -

Boucle de développement interne

• Accès aux dépendances en amont - api le service doit communiquer à la fois avec les services d'identité et de base de données pour fonctionner correctement.
• Accès aux dépendances en aval - Afin de tester si les modifications apportées au api sont compatibles avec ses dépendances en aval, il est également important de rediriger les demandes en aval vers ce service.

Boucle de développement externe

• Dépendances en amont - Pour qu'un test e2e puisse s'exécuter pour api service, il doit y avoir accès à une copie en cours d'exécution de identité et db services
• Dépendances en aval - Il est également nécessaire de trouver un moyen d'autoriser les frontend pour accéder à ce service à des fins de test.
• Point de terminaison hébergé - Outre les exigences mentionnées ci-dessus, nous devons également héberger cette copie du api service afin qu'il puisse être testé directement

Le problème de la boucle de développement interne est quelque chose qui Téléprésence à partir de Ambassador Labs a résolu pour. Nous avons essayé de résoudre le problème de la boucle de développement externe sur le Plateforme TrueFoundry par Intercepte.

Présentation de TrueFoundry Intercepts

Le concept de TrueFoundry Intercepts fonctionne en résolvant les trois problèmes de boucle de développement externe décrits dans les sections précédentes. Pour y remédier, nous appliquons la stratégie suivante :

• URL de prévisualisation : à l'aide de la plateforme elle-même, il est facile de déployer une copie d'un service existant dans un SHA de validation spécifique. Cela vous permet de créer des URL d'aperçu dédiées à une demande de validation ou d'extraction particulière.
• Interceptions basées sur l'en-tête : les interceptions permettent à un service de continuer à utiliser la même URL tout en ajoutant un en-tête supplémentaire qui redirige vers la copie d'aperçu. Par exemple, nous pouvons joindre une interception au api service qui redirige vers une copie d'aperçu en fonction d'un en-tête qui lui est transmis. Cela signifie frontend peut continuer à fonctionner avec la même URL simplement en passant un en-tête supplémentaire lors des tests.

💡

Pour en savoir plus sur les interceptions TrueFoundry, veuillez consulter notre documentation - https://docs.truefoundry.com/docs/intercepts

Conclusion

Nous avons discuté des changements dans le flux de développement provoqués par l'avènement des microservices et de la manière dont nous essayons d'y faire face. Cela reste une question ouverte, et nous pouvons nous attendre à des solutions encore plus innovantes dans ce domaine à l'avenir.

Discutez avec nous

si vous souhaitez maximiser les rendements de vos projets de LLM et permettre à votre entreprise de tirer le meilleur parti de l'IA, nous serions ravis de discuter et d'échanger des notes.

Passez un ☕️ avec nous

Découvrez comment TrueFoundry vous aide à déployer des LLM en 5 minutes :

Deploy and Fine-tune Open Source LLMs With a Few Clicks!

TrueFoundry offers an intuitive solution for LLM deployment and fine-tuning. With our Model Catalogue, companies can self-host LLMs on Kubernetes, reducing inference costs by 10x in just one click. Discover how to deploy a Dolly-v2-3b model and fine-tune a Pythia-70m using TrueFoundry in our blog.

TrueFoundry Blog Truefoundry