Visie van TrueFoundry

Overkoepelende visie: Een ontwikkelaarsplatform dat het maken en beheren van services volgens alle best practices vereenvoudigt en een compleet totaalbeeld geeft van de infrastructuur, inclusief monitoring van systemen, data, kosten en impact, met een initiële focus op Machine Learning!

Visie voor TrueFoundry (5–10 jaar)

TrueFoundry heeft in de kern als doel om de ervaring van ontwikkelaars naadloos te maken voor het uitvoeren en beheren van MicroServices — waar ontwikkelaars zich, met het juiste niveau van abstracties, volledig kunnen richten op het schrijven van de bedrijfslogica op zeer hoge iteratiesnelheden.

Stel je een proces voor waarin ik, na het schrijven van de code, een genie kan aanroepen en mijn vereisten kan doorgeven, zoals het type service (Serverless, CronJob, Database, een API-service), resourcevereisten zoals CPU, geheugen, enz., waarna de genie de service aanmaakt volgens best practices zoals Gitops en Infrastructure as Code (IAC) en vervolgens een dashboard toont met alle gegenereerde metrieken.

We willen het volgende kunnen bereiken met servicefoundry:

Gecentraliseerde infrastructuurprovisioning met behulp van IAC

ServiceFoundry zal de meest gebruikte open-source infrastructuurcomponenten provisioneren en hosten in de cloud van de gebruiker. Enkele voorbeelden hiervan zijn:

1. Kubernetes-cluster starten geconfigureerd volgens de nieuwste veiligheidsnormen.
2. Gecentraliseerde infrastructuurcomponenten installeren (of beheerde services gebruiken) zoals Kafka, Spark, Redis, Prometheus, Grafana, enz.
3. Voor sommige componenten kunnen we Cloud Managed services gebruiken, zoals AWS Elastic Search.
4. Databases en opslaglagen starten (gebruik voorlopig beheerde versies).
5. Pipeline-orchestratiesystemen zoals Airflow, Argo, enz.
6. CI / CD (Github Actions, Gitlab, AWS Code pipelines)
7. Logaggregatie (ELK, EFK)
8. Monitoring (Standaard en aangepaste metrieken)
9. Alerting

Service aanmaken

1. Bouw en deploy services op basis van configureerbare templates. ServiceFoundry zal een meninghebbende set principes zijn om het volgende te automatiseren via infrastructure-as-code:

• Dependency-beheer en verpakking (Docker, Zip)
• Testen
• Configuratiebeheer (Statische en dynamisch veranderende configuraties)
• Infrastructuurprovisioning (bovenop de eerder geprovisioneerde gecentraliseerde infra)
• Autoscaling-configuratie
• CI/CD
• Logaggregatie
• Dashboardgeneratie met standaardmetrieken (Gebruikers kunnen aangepaste metrieken toevoegen)
• Alerting

Vergelijkbaar met het bovenstaande willen we hetzelfde doen voor ML Models en Databases.

ServiceFoundry richt zich op het stroomlijnen van de deployment en monitoring van de standaardtypen services:

1. LoadBalanced API-service (met autoscaling op verschillende parameters)
2. Job Service (Cron jobs, jobs getriggerd door gebeurtenissen)
3. Serverless
4. Stateful Services
5. Statische website

Servicecatalogus en -grafiek

Alle services die met ServiceFoundry zijn aangemaakt, kunnen op één plek worden bekeken, samen met hun volledige metadata. Deze catalogus toont ook alle omgevingen voor elke applicatie, zoals dev, staging en prod. Dit leidt tot een portal voor ontwikkelaarsplatforms waar ontwikkelaars en bedrijfsleiders de services kunnen bekijken die binnen de organisatie draaien. Enkele van de belangrijkste metadata die aan elke service zijn gekoppeld, zijn:

1. Link naar Github Repository
2. Configuratie
3. Monitoring-links
4. Team en eigenaren
5. Mogelijkheid om leden toe te voegen met verschillende toegangsrechten
6. Kosten

TrueFoundry MLOps (ML First Platform)

De initiële focus van TrueFoundry zal liggen op het bieden van een naadloos MLOps-platform dat gericht is op de pipeline na het bouwen van het model en het voor data scientists heel eenvoudig maakt om hun modellen te deployen, monitoren en opnieuw te trainen.

Een machine learning-pipeline bestaat uit de volgende gecentraliseerde infrastructuur:

Een korte uitleg van de verschillende stappen die erbij betrokken zijn:

1. Data Pipeline en Feature Store: Dit is in essentie een bigdata-probleem waarbij we de features die in het model moeten worden gebruikt, moeten berekenen uit de datalake en beschikbaar moeten stellen binnen de tijdsbeperkingen die vereist zijn voor zowel training als productie, zonder verschillen. Het maakt meestal gebruik van een workflow-orchestratie-engine zoals Airflow, Argo of Kubeflow pipelines.
2. Model Training: Model training is in essentie een rekenintensieve, gedistribueerde taak die over meerdere machines kan draaien. Het moet ook ingebouwde veerkracht bieden via het opslaan en herstellen van checkpoints.
3. ModelServing: Dit is in feite een microservice die verzoeken ontvangt om modelvoorspellingen te doen en uiteenlopende vereisten kan hebben, zoals GPU, hoge rekenkracht en geheugenvereisten. Elk model wordt meestal gehost als een afzonderlijke microservice — wanneer een team dus opschaalt naar tientallen modellen, wordt het een kwestie van het beheren van tientallen microservices, wat op zichzelf al een groot probleem is.
4. ModelMonitoring: Dit omvat zowel het monitoren van systeemmetrieken als machine learning-specifieke monitoring met betrekking tot de prestaties en achteruitgang (decay) van het model. Dit vereist ook systemen om de gelogde data op te slaan, er aggregaties op uit te voeren en uiteindelijk de metrieken te berekenen.
5. Model Management: Dit houdt alle data bij met betrekking tot modellen en hun verschillende versies en experimenten. Het is uiterst nuttig om problemen later te debuggen en een rollback uit te voeren.

Vanwege de vele bewegende onderdelen en de verschillende technologieën die erbij betrokken zijn, zijn er meestal meerdere mensen betrokken bij een ML-project, zoals een DataEngineer, DataScientist, ML engineer, DevOps en Product Manager. Een succesvol project vereist afstemming tussen al deze verschillende persona's, wat leidt tot veel vertragingen en de snelheid van een data scientist belemmert.

Een typische workflow in bedrijven voor een machine learning-pipeline ziet er ongeveer zo uit:

Belangrijkste doel achter het ML-platform

We willen de onderdelen in de ML-pipeline automatiseren die geautomatiseerd kúnnen worden en de data scientist in staat stellen om hun modellen in productie te testen en snel te itereren met zo min mogelijk afhankelijkheden van andere teams. We halen onze inspiratie uit de producten die zijn gemaakt door Platform-teams in toptechnologiebedrijven, waarmee alle teams veel sneller kunnen bewegen en zelfstandig kunnen deployen en itereren.

We behandelen op dit moment geen van de datagerelateerde problemen — die sectie wordt later geïntroduceerd.

Een essentieel ML-platform bestaat uit de volgende services (naast de centrale infrastructuur):

1. Training (Een geplande Job met verschillende triggers)
2. Model Service (Een LoadBalanced API-service)
3. Opslag (Artifacts, datasets, model-inferencedata)
4. ML Monitoring Service (Een service om metrieken uit data te berekenen)
5. Feature Engineering Service

Als we deze services eenvoudig kunnen deployen, versieverloop kunnen bijhouden over verschillende fasen en monitoring kunnen genereren voor elk van hen, zal het MLOps-probleem een stuk eenvoudiger worden.

Deze blog is voor het eerst gepubliceerd op Medium op https://abhishekch09.medium.com/d8e159743a4b