Applicatieontwikkeling Met Kubernetes

Kubernetes wordt algemeen beschouwd als het ideale platform voor teams in grote en middelgrote organisaties met hoge eisen op het gebied van hoge beschikbaarheid en autoscaling. Het heeft echter ook gezorgd voor frictie in bestaande workflows van ontwikkelaars. Deze verandering kan worden gezien als onderdeel van een bredere verschuiving naar de omarming van het microservices-paradigma en de toenemende complexiteit van de manier waarop software draait. In dit artikel onderzoeken we hoe het probleem van softwareontwikkeling is geëvolueerd met deze paradigmaverschuiving.

Dev-loop

Laten we beginnen met het concept van een dev-loop en de rol ervan in ontwikkelworkflows. De ontwikkelingsloop voor elk softwareproject bestaat uit twee afzonderlijke loops die samenkomen op Git.

Dit zijn -

• Inner dev-loop - Dit proces omvat het schrijven, compileren en testen van een stuk code op het eigen workstation van een ontwikkelaar. Deze loop gaat door totdat een bevredigend stuk code naar Git wordt verplaatst.
• Outer dev-loop - Deze loop wordt geactiveerd nadat de code van het workstation van de ontwikkelaar naar Git is verplaatst. Het omvat het uitvoeren van tests en het uitrollen van het eindproduct. Idealiter is dit proces ingericht als een continue loop, waarbij deployments plaatsvinden bij elke code-push die de tests doorstaat.

Deze loops voeden elkaar en vormen samen een complete software development lifecycle.

Opkomst van de microservice

De komst van microservices heeft gezorgd voor kleine, onafhankelijke en losgekoppelde softwarecomponenten die een betere schaalbaarheid en betrouwbaarheid bieden. We zullen de voordelen hier niet bespreken aangezien deze al breed bekend zijn, maar onze aandacht gaat uit naar de daaruit voortvloeiende toegenomen operationele complexiteit.

Laten we kijken naar een eenvoudige opzet waarbij de frontend de api aanroept, die op zijn beurt communiceert met twee andere services genaamd identity en db. In dit scenario werkt onze ontwikkelaar op de api-laag, die zowel downstream- (frontend) als upstream-afhankelijkheden (identity, db) heeft. Laten we onderzoeken hoe het ontwikkelproces voor de api-service verandert in de twee verschillende dev-loops  -

Inner dev-loop

• Toegang tot upstream-afhankelijkheden - De api-service moet met zowel de identity- als de db-services kunnen communiceren om succesvol te draaien.
• Toegang tot downstream-afhankelijkheden - Om te testen of de wijzigingen die in de api-service worden aangebracht compatibel zijn met de downstream-afhankelijkheden, is het ook belangrijk om downstream-verzoeken om te leiden naar deze service.

Outer dev-loop

• Upstream-afhankelijkheden - Om een e2e-test uit te voeren voor de api-service, is er toegang nodig tot een draaiende kopie van de identity- en db-services.
• Downstream-afhankelijkheden - Er is ook een manier nodig om de frontend toegang te verlenen tot deze service voor testdoeleinden.
• Gehost endpoint - Naast de bovengenoemde vereisten moeten we deze kopie van de api-service ook hosten, zodat deze direct getest kan worden.

Het probleem van de inner dev-loop is iets wat Telepresence van Ambassador Labs heeft opgelost. Wij hebben geprobeerd het probleem van de outer dev-loop op te lossen op het TrueFoundry-platform met Intercepts.

Introductie van TrueFoundry Intercepts

Het concept van TrueFoundry Intercepts werkt door de drie outer dev-loop-problemen op te lossen die in de vorige secties zijn beschreven. We hanteren de volgende strategie om dit aan te pakken -

• Preview URL's - Met het platform zelf is het eenvoudig om een kopie van een bestaande service uit te rollen op een specifieke commit-SHA. Hiermee kun je preview URL's maken die speciaal zijn gewijd aan een specifieke commit of pull request.
• Header-gebaseerde intercepts - Intercepts maken het mogelijk voor een service om dezelfde URL te blijven gebruiken, terwijl er een extra header wordt toegevoegd die omleidt naar de preview-kopie. We kunnen bijvoorbeeld een intercept koppelen aan de api-service die omleidt naar een preview-kopie op basis van een header die wordt meegegeven. Dit betekent dat frontend kan blijven werken met dezelfde URL, simpelweg door een extra header mee te sturen tijdens het testen.

💡

Lees onze documentatie voor meer informatie over TrueFoundry intercepts - https://docs.truefoundry.com/docs/intercepts

Conclusie

We hebben de veranderingen in de ontwikkelworkflow besproken die zijn ontstaan door de opkomst van microservices, en hoe we deze proberen aan te pakken. Dit blijft een open vraagstuk en we kunnen in de toekomst nog meer innovatieve oplossingen op dit gebied verwachten.

Chat met ons

Als je het maximale rendement uit je LLM-projecten wilt halen en je organisatie in staat wilt stellen om AI op de juiste manier in te zetten, gaan we graag met je in gesprek om ervaringen uit te wisselen.

Drink een ☕️ met ons

Ontdek hoe TrueFoundry je helpt om binnen 5 minuten LLM's uit te rollen:

Deploy en fine-tune open-source LLM's met slechts een paar klikken!

TrueFoundry biedt een intuïtieve oplossing voor LLM-deployment en fine-tuning. Met onze Model Catalogue kunnen bedrijven zelf LLM's hosten op Kubernetes, wat de inference-kosten met 10x verlaagt in slechts één klik. Ontdek in ons blog hoe je een Dolly-v2-3b-model uitrolt en een Pythia-70m fine-tuned met TrueFoundry.

TrueFoundry Blog Truefoundry