Machine Learning Deployments in 2023

Deployment van applicaties en infrastructuur is een complex proces dat coördinatie vereist tussen Infra- en applicatieontwikkelingsteams. Een intern developer platform helpt beide teams om snel te bewegen met minder fouten — wat resulteert in een hogere productiviteit en een grotere stabiliteit.

Belangrijke zaken om rekening mee te houden bij Deployment en de Software Lifecycle

1. Dockerization — Het verpakken van afhankelijkheden met vastgelegde versies is belangrijk voor de reproduceerbaarheid. Docker images met onnodige afhankelijkheden kunnen de images te groot maken, wat leidt tot langere opstarttijden.
2. Keuze van het type deployment: Er zijn veel opties voor deployment — webservices, jobs, serverless methoden, statische websites —label elk met hun eigen voor- en nadelen. De beste methode is afhankelijk van verkeerspatronen, latency-vereisten, geheugen- en cpu-eisen.
3. Schaalbaarheid — Schaal brengt veel uitdagingen met zich mee en vereist een juiste configuratie van scaling-beleid, het configureren van autoscalers en het zorgen dat services stateless zijn — terwijl tegelijkertijd de kosten worden geoptimaliseerd.
4. Monitoring en Debuggability — Hoe vergelijk je verschillende softwareversies? Het inzien van logs, metrics, het vastleggen van custom metrics en deze bekijken op dashboards moet zeer eenvoudig zijn.
5. Secrets Management en Beveiliging — Er moet ondersteuning zijn voor goed secret-beheer, evenals het verlenen van toegang tot andere systemen via service accounts in plaats van het rondsturen van inloggegevens.
6. Automatisering en CI/CD — Een goede CI/CD-pipeline is cruciaal voor snelle ontwikkeling en het vroegtijdig opsporen van bugs. Het naadloos kunnen aanmaken van nieuwe omgevingen met één klik, en het geautomatiseerd overstappen van develop naar staging en production maakt het proces aanzienlijk soepeler.
7. Versioning, Immutable Deployments en rollbacks —label Het moet eenvoudig zijn om deployments samen met de secret-waarden terug te draaien (rollback). In vrijwel alle huidige systemen is het bijna onmogelijk om een deployment terug te draaien met de laatst gebruikte omgevingsvariabelen of secret-waarden.
8. Meerdere Omgevingen: Het kunnen beheren van meerdere omgevingen of het dynamisch opzetten/afbreken van omgevingen helpt ontwikkelaars om meer geïsoleerd te testen, wat de algehele voortgang versnelt tegen lagere kosten.
9. API Security en authenticatie — Authenticatie van API's, zowel extern als intern —label eenvoudige gebruikersnaam-wachtwoord authenticatie, OIDC-authenticatie, service account, bearer token?
10. Rate Limiting en load balancer-configuratie —label Algemene best practices die voor elke API geïncorporeerd moeten worden (Load Balancer-configuratie).
11. Snelheid en autonomie van deployment —label Ontwikkelaars moeten de controle voelen over de deployments in plaats van er volledig van te worden afgeschermd. Ze in de loop houden en autonoom maken, terwijl er voor wordt gezorgd dat de kerninfrastructuur niet breekt door menselijke fouten, is een van de hoofddoelen van het platform.
12. Kostenoptimalisatie —label Het kiezen van de beste hardware en het meest geschikte type deployment helpt bij het optimaliseren van de kosten.
13. Coördinatie van Infra- en Applicatiewijzigingen: Bij de overgang van de ene naar de andere omgeving moeten vaak ook infrastructuurwijzigingen worden doorgevoerd. Als deze worden vergeten, leidt dit tot storingen van de applicatie in productie.
14. A/B Testing / Traffic Shaping

Maak kennis met TrueFoundry

Een deployment platform dat kan dienen als het intern developer platform voor een bedrijf. Het doel is om het voor ontwikkelaars heel eenvoudig te maken om hun applicaties te deployen en te onderhouden zonder gedetailleerde kennis van infrastructuur, en om het voor infra-/DevOps-teams eenvoudig te maken om beleid op te stellen waarmee engineering- en security-best-practices worden afgedwongen.

Wat zijn de belangrijkste ontwerpprincipes achter het TrueFoundry-platform?

1. Volledig API-gedreven architectuur —label TrueFoundry volgt een volledig API-gedreven architectuur, vergelijkbaar met Kubernetes. Hiermee kunnen gebruikers zelf interfaces, UI's en automatiseringen bovenop het platform bouwen.
2. Uitbreidbare PaaS bovenop Kubernetes —label kan worden aangepast met meerdere plugins bovenop de kernfunctionaliteiten die Kubernetes biedt.
3. GitOps-gedreven (ondersteunt ook een niet-GitOps-modus)
4. Fijnmazig toegangsbeheer (RBAC) vanaf dag 1
5. Infrastructure as Code (Terraform) —label kan in korte tijd op elk cloudaccount worden opgezet.
6. Security by default —label TrueFoundry volgt het POLP-principe (Principle of least privilege) en gebruikt security best practices zoals service accounts, TLS, data-encryptie in rust en ondersteuning voor air-gapped omgevingen.
7. Cloud Native by design —label We kiezen bewust voor componenten die van nature cloud native zijn en beschikbaar zijn bij alle cloudproviders.

Belangrijkste functionaliteiten ondersteund in TrueFoundry

Verschillende deployment-methoden over meerdere clouds:

Verschillende workloads kunnen geschikt zijn voor verschillende deployment-methoden, afhankelijk van het verkeerspatroon en het CPU- en geheugenverbruik. Het doel is om één enkele interface te bieden voor deployment over meerdere systemen —label zoals services op Kubernetes, jobs op Kubernetes, AWS Lambda, serverless op Kubernetes (Knative), Google Cloud Run en model servers. TrueFoundry integreert met Git-repositories om deployment rechtstreeks vanuit elke Git-repo mogelijk te maken.

Logging en visualisatie van metrics en grafieken over jobs heen

Met TrueFoundry kunnen ontwikkelaars gedetailleerde metrics, parameters, afbeeldingen, plots en artefacten loggen, waardoor ze job-runs kunnen vergelijken via gedetailleerde dashboards.

Software Canary / Shadow Testing

TrueFoundry maakt het heel eenvoudig om nieuwe softwareversies te testen op live data zonder de bestaande productie te verstoren —label via shadow testing. Het maakt ook canary rollouts van software mogelijk door het verkeer geleidelijk te verplaatsen naar de nieuwe versies.

Secrets Management

Ontwikkelaars kunnen secrets aanmaken en erin refereren binnen hun applicaties. Enkele van de belangrijkste functies van secrets management:

1. De secret-opslag wordt ondersteund door secretstores zoals Vault, AWS Secrets Manager, Google Secrets Manager, AWS Parameter Store, enz. Er worden geen daadwerkelijke secret-waarden op het platform zelf opgeslagen.
2. Het platform houdt bij welk secret in welke applicatie wordt gebruikt —label zodat wanneer een secret verandert, gebruikers worden gevraagd om de bijbehorende services opnieuw te deployen.
3. Het platform bewaart secret-versies, wat het terugdraaien van applicaties samen met de bijbehorende secret-versies mogelijk maakt.

Toegangsbeheer op secrets —label Kijkers kunnen de keys van secrets zien, maar niet de waarden ervan. Op deze manier kan het DevOps-/infra-team keys delen met ontwikkelaars zonder bang te hoeven zijn dat gevoelige waarden worden blootgesteld.

Multi-Cluster Management en Deployment

TrueFoundry maakt integratie met meerdere clusters en het beheer van toegangscontrole daarover mogelijk. TrueFoundry slaat de clusterinloggegevens nergens zelf op, wat het veilig maakt voor verschillende gebruikers binnen het bedrijf.

Toegangsbeheer op Kubernetes voor verschillende teams

TrueFoundry maakt het eenvoudig om toegangsbeheer in te stellen op Kubernetes namespaces en deze toe te wijzen aan verschillende teams met resource quotas. Dit stelt ontwikkelaars in staat autonomer te werken, terwijl de infrastructuur stabiel, kostenefficiënt en veilig blijft.

Basis Monitoring en Logging UI's rechtstreeks zichtbaar op het platform

TrueFoundry dringt geen specifieke mening op over het logging- of metricsplatform dat u wilt gebruiken. Het doel is juist te integreren met enkele veelgebruikte logging- en monitoringoplossingen, zodat we een snelle weergave op het platform zelf kunnen tonen. Voor meer gedetailleerde en aanpasbare weergaven raden we aan bestaande monitoringoplossingen te gebruiken zoals Prometheus, Loki, ELK, Datadog of NewRelic.

Geïntegreerd overzicht van alle gedeployde en actieve services (Service Catalog)

Kostenschatting en -optimalisatie op service-, team- of engineersniveau.

We willen het mogelijk maken om kostenschattingen en -optimalisaties bij te houden per service of team. Alleen al het inzichtelijk maken van de kosten voor elke afzonderlijke engineer creëert bewustzijn om kosten te optimaliseren en neemt de druk weg bij één enkel team.

Deploy elke Terraform-module (waarmee de deployment van beheerde databases, queues of caching-services mogelijk wordt)

We willen de deployment van cloudservices mogelijk maken met behulp van Terraform-modules die zijn geschreven door het DevOps- of infra-team. Het DevOps-team kan bijvoorbeeld een Terraform-module maken voor het aanmaken van een database, waarna ontwikkelaars vanuit de UI een database kunnen provisionen op basis van de Terraform-module voor RDS. Dit maakt gebruik van het onderstaande plugin-framework en een Terraform-controller op Kubernetes.

Werkt TrueFoundry met mijn bestaande stack?

Bij TrueFoundry willen we het wiel niet opnieuw uitvinden en maken we zoveel mogelijk gebruik van bestaande systemen. Daarom integreren we met veel bestaande infrastructuurtools, zodat gebruikers hun eigen infrastructuur kunnen meenemen of TrueFoundry kunnen aanpassen aan hun eigen behoeften.

1. Cloudaccounts (AWS, GCP, Azure) —label helpt ons automatisch clusters te provisionen, Lambda's aan te maken en beheerde services te deployen.
2. Git-integratie (GitHub, Bitbucket, Azure) —label helpt ontwikkelaars hun applicatie rechtstreeks vanuit hun Git-repositories te deployen.
3. Secret Stores (AWS Secrets Manager, Google Secrets Manager, HashiCorp Vault) —label hierdoor worden de daadwerkelijke waarden van de secrets opgeslagen in de secret stores en niet op het platform.
4. Docker Registry —label Docker Hub, Google GCR, Amazon ECR, GitHub Docker Registry.
5. Terraform-integratie
6. Monitoring-integraties: Prometheus, Grafana, Datadog, NewRelic.
7. Logging-infrastructuur-integraties —label Loki, Datadog, ELK-stack.
8. CI/CD-integratie —label TrueFoundry kan integreren met bestaande CI/CD-pipelines zoals GitHub Actions, Jenkins, AWS CodeBuild, Google Cloud Build, enz.

Staat uw specifieke tool hier niet tussen? We werken graag met u samen om nieuwe integraties aan de lijst toe te voegen.

Hoe verhoogt TrueFoundry de veiligheid?

POLP-principe

We volgen het POLP-principe (Principle of Least Privilege) en maken het voor infra-teams eenvoudig om dit door de gehele stack af te dwingen. Ontwikkelaars kunnen worden toegevoegd aan de workspaces waarvoor ze toegang nodig hebben —label en hun wijzigingen blijven beperkt tot die specifieke workspaces.

Geen secrets of wachtwoorden opgeslagen op het TrueFoundry-platform

TrueFoundry slaat zelf geen gevoelige informatie op, zoals Kubernetes-inloggegevens of secrets. Alle data is geëncripteerd in rust (at REST). We raden aan om alle toegang via service accounts te verlenen.

We zijn ook van plan om volledige audit logs te bieden, waarmee teams inzicht krijgen in alle acties die op het platform zijn uitgevoerd.

Hoe is TrueFoundry open en aanpasbaar?

Kubernetes-cluster blijft onder uw controle

TrueFoundry biedt toegang tot het ruwe Kubernetes-cluster waarop het workloads deployt en geeft klanten volledige toegang (inclusief kubectl met de juiste machtigingen). Dit stelt iedereen in staat om vrijwel alles te doen wat ze willen naast TrueFoundry, zonder ooit geblokkeerd te worden.

Daarnaast ondersteunen we een plugin-framework waarmee eenvoudig aanvullende plugins gebouwd kunnen worden —label vergelijkbaar met CRD's op Kubernetes.

Custom Plugins bouwen op TrueFoundry

TrueFoundry ondersteunt elke deployment-methodologie als een custom plugin:

Om een plugin te maken, schrijft de gebruiker 3 onderdelen:

1. Een input Cue-bestand dat de specificatie van het input-schema definieert.
2. Een processor die definieert hoe de input-specificatie wordt omgezet naar een output-specificatie.
3. Een output-specificatie die naar Kubernetes wordt gestuurd.

Momenteel moeten de input- en output-specificaties geschreven zijn in Cue Lang en moet de processor geschreven zijn in Go. In de toekomst willen we echter ook input- en output-schema's in JSON Schema toestaan en het mogelijk maken dat processoren in elke taal worden geschreven.

We genereren de UI en de Python-interfaces automatisch op basis van de input Cue-bestanden.

Hoe onboardt u op TrueFoundry?

Inrichten van infrastructuur door infra-/DevOps-teams:

1. Maak Kubernetes-clusters aan met Terraform. TrueFoundry biedt voorbeeld-Terraform-code waarmee clusters met 1 klik kunnen worden gestart terwijl de Terraform-code naar een GitHub-repo wordt gepusht. DevOps-/infra-teams kunnen de Terraform-code naar wens aanpassen en opnieuw toepassen.
2. Maak service accounts aan via Terraform om toegang te verlenen tot andere infrastructuur vanuit Kubernetes namespaces.
3. Voeg de service accounts toe aan workspaces op het TrueFoundry-platform en wijs workspaces toe aan verschillende teams.
4. TrueFoundry bootstrapt het Kubernetes-cluster met een standaard monitoring stack (Kube-prometheus-loki-grafana stack), Istio (ingress) en ArgoCD (infra deployment). TrueFoundry plaatst de manifestbestanden in een GitHub-repository, die vervolgens door het infra-team naar behoefte kan worden aangepast.
5. Voor het deployen van beheerde infrastructuur kunnen infra-teams Terraform-modules leveren voor DB, queue, cache, enz. Ontwikkelaars kunnen deze infrastructuur vervolgens provisionen met de modules die door het infra-team zijn aangeleverd.
6. Onboard ontwikkelaars op het platform.
7. Wijs workspaces toe aan teams / applicaties.
8. Ontwikkelaars kunnen vervolgens direct beginnen met deployen aan de hand van de documentatie.

Hoe werkt TrueFoundry?

TrueFoundry bestaat uit 2 componenten —label een control plane en een workload cluster agent. Dit stelt TrueFoundry in staat om workloads over meerdere clusters te orchestreren.

Verschil met andere platformen

Architectuur

1. Multi-Cluster vanaf Dag 1: TrueFoundry ondersteunt multi-cluster vanaf dag 1, waarbij clusters verspreid kunnen zijn over regio's, VPC's en privé of publiek kunnen zijn. Dit is erg moeilijk in de huidige architectuur van Porter en Northflank. De architectuur van Komodor kan dit wel, maar zij richten zich meer op Kubernetes-visualisatie en -monitoring, wat bij ons platform standaard is inbegrepen.
2. Multi-Cloud vanaf Dag 1: Dit geldt ook voor Porter, Northflank en Qovery, maar alleen op de Kubernetes-laag. Onze architectuur ondersteunt het bouwen van integraties met veel meer cloud native-componenten vanwege de openheid van het systeem. Argonaut doet dit op dezelfde bredere laag als wij.
3. Volledige transparantie en GitOps —label We volgen een model van volledige transparantie waarbij de gebruiker de volledige controle behoudt over zijn architectuur en op geen enkel punt door TrueFoundry wordt geblokkeerd. In het geval van Porter, Northflank en Qovery zullen grotere bedrijven de functionaliteiten ontgroeien vanwege de gesloten architectuur. We ondersteunen ook zowel een GitOps- als een niet-GitOps-modus, wat momenteel niemand anders doet —label Porter, Northflank en Qovery zijn niet-GitOps push-based, terwijl CoSphere volledig Git-based is.

Uniforme deployment van Applicatie en Infrastructuur

We integreren diep met applicaties, jobs en ML-deployments. Dit vertaalt veel infrastructuurkennis naar terminologie voor ontwikkelaars. Veel andere platformen doen dit door abstracties te bouwen en infrastructuurconcepten te verbergen —label terwijl wij dit proberen te doen door vereenvoudiging, zonder zaken te verbergen.

Argonaut gebruikt deze benadering om de deployment van infrastructuur en applicaties samen te brengen —label maar dit is een productcyclus van 2 tot 3 jaar. Zij zijn meer aan de infrastructuurzijde begonnen.

Plugins

Onze op plugins gebaseerde architectuur is gebaseerd op het Kubernetes CRD-framework met onze eigen CueLang-implementatie. Dit geeft ons de mogelijkheid om erg snel plugins uit te brengen op CLI, UI en in alle talen. Dit is geïnspireerd op het ontwerp van KubeVela (een open-source repository) —label we kennen geen enkele andere speler die dit patroon heeft geïmplementeerd. Dit is een van onze eigen ontwikkelingen waarmee we sneller kunnen bouwen dan andere spelers.

Transparantie

We proberen zo transparant mogelijk te zijn door de volledige broncode beschikbaar te stellen —label wat het heel eenvoudig maakt om eventueel van ons platform te migreren. Alleen Porter en purple.sh lijken dit te garanderen —label de rest zijn zeer gesloten systemen.

Inzichten

We tonen nu al unieke inzichten en voorkomen de meest voorkomende fouten bij software-deployments, zoals het niet aanpassen van omgevingsvariabelen bij een deployment. We kennen geen enkel ander platform dat dit doet of kan doen zoals wij, doordat wij zicht hebben op zowel de history van secrets als de history van deployments. We kunnen ook veel inzichten genereren over kosten, stabiliteit en productiviteit van ontwikkelaars, omdat we de volledige code-pipeline zien van source control tot productie.

Vervanging voor het Platform Team

Ons platform is ontworpen om te fungeren zoals wat platformteams intern bouwen. Het pakt de belangrijkste vraagstukken aan rondom toewijzing van middelen, beveiliging en abstracties voor ontwikkelaars. Porter en Northflank lijken meer op Heroku. Qovery en Argonaut zijn meer een vervanging voor DevOps bij kleinere bedrijven. Humanitec en Shipa zijn meer ontworpen voor platformteams, maar we vonden hun abstracties vrij lastig te begrijpen en te verantwoorden.