சேவை பட்டியல் (service catalog) தரவு மாதிரி மற்றும் golden path டெம்ப்ளேட்டுகளை வடிவமைத்தல்

அறிமுகம்

கட்டமைக்கப்பட்ட பட்டியல் (catalog) எதுவும் இல்லாதபோது AI குழுக்கள் தற்காலிக (ad-hoc) provisioning-க்கு இயல்பாகத் திரும்புவதை பொறியாளர்கள் அடிக்கடி காண்கிறார்கள்—GPU செலவு கட்டுப்பாடின்றி வளர்கிறது, மாடல் deployment-கள் monitoring instrumentation-ஐத் தவிர்க்கின்றன, மேலும் connection string-கள் டஜன் கணக்கான சேவைகளில் hardcode செய்யப்பட்டு, அவற்றுக்கிடையே தானியங்கி wiring எதுவும் இல்லாமல் இருக்கின்றன. golden path-களுடன் இணைந்த ஒரு சேவை பட்டியல் (service catalog) இந்தப் பிரச்சினையைத் தீர்க்கிறது—சரிபார்க்கப்பட்ட சேவைகள் மற்றும் முன்கூட்டியே தொகுக்கப்பட்ட பணிப்பாய்வுகளின் தேர்ந்தெடுக்கப்பட்ட பதிவேட்டை (registry) குழுக்களுக்கு வழங்குவதன் மூலம், platform முடிவுகளை முதலிலிருந்து மீண்டும் கண்டுபிடிக்காமல் அவற்றை அவர்கள் ஏற்றுக்கொள்ள முடியும். இந்தப் பாடத்தின் முடிவில், பதிவு (registration) நேரத்திலேயே governance கொள்கைகளை அமல்படுத்தும் ஒரு catalog தரவு மாதிரியை (data model) வடிவமைக்கவும், அந்தச் சேவைகளை end-to-end AI பணிப்பாய்வுகளாகத் தொகுக்கும் golden path படி வரிசைகளை (step sequences) வரையறுக்கவும், மற்றும் provisioning orchestrator சேவைகளுக்கு இடையிலான configuration-ஐ platform control plane வழியாக எவ்வாறு தானாகப் பரப்புகிறது என்பதைப் புரிந்துகொள்ளவும் உங்களால் முடியும்.

முக்கிய சொற்கள்

• Service Catalog (சேவை பட்டியல்): platform வழங்கும் சேவைகளின் தேர்ந்தெடுக்கப்பட்ட பதிவேடு; ஒவ்வொன்றும் அதன் திறன்கள், SLA-க்கள், dependency-கள் மற்றும் provisioning interface-ஐ விவரிக்கும் metadata-வுடன் இருக்கும்.
• Golden Path: ஒரு குறிப்பிட்ட பயன்பாட்டு நிகழ்வுக்காக (use case) பல catalog சேவைகளை ஒரு end-to-end pipeline-ஆகத் தொகுக்கும், முன்கூட்டியே சரிபார்க்கப்பட்ட, திட்டவட்டமான (opinionated) பணிப்பாய்வு template.
• Service Template (சேவை வார்ப்புரு): ஒரு குறிப்பிட்ட சேவை instance-க்கான infrastructure-as-code மற்றும் configuration-ஐ உருவாக்கும் parameter-ஆக்கப்பட்ட blueprint.
• Platform Control Plane: platform முழுவதும் சேவை lifecycle, configuration பரப்புதல் (propagation) மற்றும் health monitoring-ஐ நிர்வகிக்கும் API-கள் மற்றும் controller-களின் தொகுப்பு.
• Catalog Entry (பட்டியல் உள்ளீடு): catalog-க்குள் உள்ள ஒரு தனிச் சேவை வரையறை; அதன் schema, பதிப்பு வரலாறு (version history), உரிமையாளர் metadata மற்றும் dependency graph ஆகியவற்றை உள்ளடக்கியது.

கருத்துகள்

Platform Configuration Management-உடன் இணைத்தல்

சேவை பட்டியலும் golden path பதிவேடும் தனித்து இயங்குவதில்லை—அவை தொடர்புடைய lab நோக்கத்தில் விவரிக்கப்பட்ட platform configuration management சேவைக்கு நேரடியாக உள்ளீடு அளிக்கின்றன. provisioning orchestrator ஒரு golden path படியிலிருந்து (step) ஒரு சேவையை deploy செய்யும்போது, அதன் விளைவாக உருவாகும் configuration-ஐ (endpoint-கள், credential குறிப்புகள், வள ஒதுக்கீடுகள்) Redis caching-உடன் PostgreSQL-இல் எழுதுகிறது. golden path-இல் அடுத்து வரும் சேவைகள் தங்களுக்கு முந்தைய சேவைகளின் configuration-ஐ இந்த store-இலிருந்து படிக்கின்றன; இதன் மூலம் தானியங்கி wiring சாத்தியமாகிறது.

உதாரணமாக, golden path படி 1-இல் ஒரு vector database-ஐ provision செய்யும்போது, orchestrator அந்த database-இன் connection string மற்றும் collection schema-வை platform/team-alpha/vector-db/qdrant/connection போன்ற namespace-ஆக்கப்பட்ட key-இன் கீழ் configuration store-இல் எழுதுகிறது. படி 2 ஒரு model serving endpoint-ஐ provision செய்யும்போது, serving framework-இன் startup configuration அதே key-ஐப் படித்து embedding lookup-களை எங்கு அனுப்ப வேண்டும் என்பதைக் கண்டறிகிறது. இந்த pattern hardcode செய்யப்பட்ட connection string-களை நீக்குகிறது; மேலும் consumer code மாற்றங்கள் தேவையின்றி credential-களைச் சுழற்றவோ (rotate) அல்லது சேவைகளை இடம்பெயர்க்கவோ (migrate) platform-க்கு வழி செய்கிறது.

configuration management சேவை, catalog lifecycle நிகழ்வுகளுடன் ஒத்துப்போகும் பின்வரும் செயல்பாடுகளைக் கொண்ட gRPC அல்லது REST API-ஐ வெளிப்படுத்த வேண்டும்:

• PUT /config/{namespace}/{service_id}/{key} — provisioning-இன் போது ஒரு configuration மதிப்பை எழுதுகிறது; Redis cache தானாக invalidate செய்யப்படுகிறது.
• GET /config/{namespace}/{service_id}/{key} — ஒரு configuration மதிப்பைப் படிக்கிறது; Redis cache-இலிருந்து வழங்கப்படுகிறது, PostgreSQL fallback-உடன்.
• DELETE /config/{namespace}/{service_id} — decommission செய்யப்பட்ட சேவைக்கான அனைத்து configuration-ஐயும் நீக்குகிறது; ஒரு golden path படி rollback செய்யப்படும்போது தூண்டப்படுகிறது.
• LIST /config/{namespace} — ஒரு குழுவின் namespace-க்குள் configure செய்யப்பட்ட அனைத்துச் சேவைகளையும் பட்டியலிடுகிறது; platform health dashboard-இன் சேவை inventory காட்சிக்கு ஆதாரமாக அமைகிறது.

AI-க்கே உரிய Golden Path-களுக்கான வடிவமைப்புக் கொள்கைகள்

AI பணிப்பாய்வுகளுக்கான golden path-களை உருவாக்குவதற்கு, பாரம்பரிய microservice platform-களில் எழாத சில கவலைகளில் கவனம் தேவை:

1. GPU lifecycle நிர்வாகத்தை உள்ளடக்குங்கள் — GPU workload-களை provision செய்யும் ஒவ்வொரு golden path-இலும் quota சரிபார்ப்பு, node pool தேர்வு மற்றும் தானியங்கி scale-down கொள்கைகளுக்கான படிகள் இருக்க வேண்டும். catalog entry-இல் உள்ள GPURequirement மாதிரி அறிவிப்பை (declaration) கட்டாயமாக்குகிறது; ஆனால் provisioning-ஐத் தொடங்கும் முன் இலக்கு cluster-இல் போதுமான GPU திறன் உள்ளதா என்பதையும் golden path சரிபார்க்க வேண்டும். திறன் போதுமானதாக இல்லையென்றால், deployment நடுவில் தோல்வியடைவதற்குப் பதிலாக, capacity கோரிக்கை பணிப்பாய்வுக்கான இணைப்புடன் தெளிவான பிழையை path திருப்பித் தர வேண்டும்.

2. மாடல் artifact-களை infrastructure-உடன் சேர்த்து பதிப்பிடுங்கள் (version) — model serving-க்கான golden path-கள், provisioning parameter-களில் மாடல் artifact பதிப்பை (எ.கா., குறிப்பிட்ட run ID கொண்ட MLflow model URI) pin செய்ய வேண்டும். இது infrastructure மற்றும் மாடல் பதிப்புகள் atomic-ஆக deploy செய்யப்படுவதையும், ஒன்றாக rollback செய்யப்பட முடிவதையும் உறுதி செய்கிறது. மாடல் பதிப்பை configuration management சேவையின் PostgreSQL backend-இல் சேமிப்பது, எந்த மாடல் பதிப்பு எந்த infrastructure-இல் எந்த நேரத்தில் இயங்கியது என்பதற்கான audit செய்யக்கூடிய வரலாற்றை உருவாக்குகிறது.

3. இயல்பாகவே observability-ஐ உள்ளடக்குங்கள் — ஒவ்வொரு golden path-இலும், deploy செய்யப்பட்ட சேவைகளுக்கான Prometheus scrape target-கள் மற்றும் Grafana dashboard வரையறைகளை provision செய்யும் ஒரு monitoring படி இருக்க வேண்டும். AI workload-களுக்கு request latency-ஐத் தாண்டிய சிறப்பு metric-கள் தேவை—token throughput, batch queue depth, GPU பயன்பாட்டு சதவீதம் மற்றும் inference drift score-கள். monitoring படி catalog-இன் MONITORING சேவை வகையைப் பயன்படுத்தி, Grafana operator தானாக reconcile செய்யும் முன்கூட்டியே கட்டப்பட்ட dashboard JSON-ஐ inject செய்ய வேண்டும்.

4. experiment-இலிருந்து production-க்கு promotion-ஐ ஆதரியுங்கள் — data scientist-கள் அடிக்கடி experiment tracking சூழல்களில் மாடல்களை உருவாக்குகிறார்கள்; சரிபார்க்கப்பட்ட ஒரு experiment-ஐ production serving deployment-ஆக promote செய்ய அவர்களுக்குத் தெளிவான பாதை தேவை. நன்கு வடிவமைக்கப்பட்ட golden path ஒரு promote செயலை வழங்குகிறது—அது feature store-இலிருந்து experiment-இன் metadata-வைப் படித்து, platform-இன் நிலையான container image builder-ஐப் பயன்படுத்தி மாடலை package செய்து, அனைத்து production சேவைகளுக்கும் பயன்படுத்தப்படும் அதே ArgoCD pipeline வழியாக deploy செய்கிறது. பெரும்பாலான ML திட்டங்கள் தேங்கிப்போகக் காரணமான, experimentation-க்கும் production-க்கும் இடையிலான இடைவெளியை இது நீக்குகிறது.

இந்தக் கொள்கைகள், golden path-கள் வெறும் Helm chart-களைச் சுற்றிய வசதி wrapper-கள் மட்டுமல்ல, AI workload-களை பெரிய அளவில் நம்பகமாக இயக்குவது பற்றிய platform குழுவின் திரட்டப்பட்ட செயல்பாட்டு அறிவை உள்ளடக்கியவை என்பதை உறுதி செய்கின்றன. ஒவ்வொரு path-ம் semantic versioning-ஐப் பயன்படுத்தி பதிப்பிடப்பட வேண்டும், ArgoCD கண்காணிக்கும் Git repository-இல் சேமிக்கப்பட வேண்டும், மேலும் developer portal-இன் catalog-இல் வெளியிடப்படும் முன் platform-இன் சொந்த CI pipeline வழியாகச் சோதிக்கப்பட வேண்டும்.

குறியீடு விளக்கம் (Code Walkthrough)

ServiceCatalogEntry, GoldenPathDefinition மற்றும் Platform Control Plane ஆகியவற்றுக்கான முக்கிய சொற்கள் வரையறைகளின் அடிப்படையில், பின்வரும் செயலாக்கம் (implementation) இந்தக் கட்டமைப்புகளை Pydantic மாதிரிகளாக encode செய்கிறது; எந்தச் சேவையையும் deploy செய்யும் முன் provisioning orchestrator இவற்றைச் சரிபார்க்கிறது.

Code snippetpython
1from pydantic import BaseModel, Field, field_validator
2from enum import Enum
3from typing import Optional
4from datetime import datetime
5
6class ServiceType(str, Enum):
7    MODEL_SERVING = "model-serving"
8    TRAINING_JOB = "training-job"
9    VECTOR_DB = "vector-db"
10    FEATURE_STORE = "feature-store"
11    MONITORING = "monitoring"
12
13class GPURequirement(BaseModel):
14    gpu_type: str
15    min_count: int = Field(ge=0, default=0)
16    max_count: int = Field(ge=0, default=8)
17    memory_gb: int = Field(ge=0, default=40)
18
19class ServiceDependency(BaseModel):
20    service_id: str
21    version_constraint: str
22    optional: bool = False
23
24class ServiceCatalogEntry(BaseModel):
25    service_id: str = Field(min_length=3, max_length=64)
26    name: str
27    service_type: ServiceType
28    version: str = Field(pattern=r"^\d+\.\d+\.\d+$")
29    owner_team: str
30    description: str = Field(min_length=20)
31    gpu_requirements: Optional[GPURequirement] = None
32    dependencies: list[ServiceDependency] = Field(default_factory=list)
33    helm_chart_ref: Optional[str] = None
34    created_at: datetime = Field(default_factory=datetime.utcnow)
35    deprecated: bool = False
36
37    @field_validator("gpu_requirements")
38    @classmethod
39    def gpu_required_for_compute_services(cls, v, info):
40        stype = info.data.get("service_type")
41        gpu_types = {ServiceType.MODEL_SERVING, ServiceType.TRAINING_JOB}
42        if stype in gpu_types and v is None:
43            raise ValueError(f"gpu_requirements mandatory for {stype}")
44        return v

ServiceType platform நிர்வகிக்கும் AI workload வகைகளைப் பட்டியலிடுகிறது; Kubernetes label மரபுகளுடன் ஒத்துப்போகும் kebab-case மதிப்புகளைப் பயன்படுத்துகிறது. GPURequirement துணை-மாதிரி ஒவ்வொரு entry-யிலும் வெளிப்படையான hardware அறிவிப்புகளைக் கட்டாயமாக்குகிறது. ServiceCatalogEntry-இல் உள்ள field_validator, GPU தேவைகளைத் தவிர்க்கும் எந்த model-serving அல்லது training-job entry-ஐயும் நிராகரிக்கிறது; இதன் மூலம் deploy நேரத்தில் அல்லாமல் schema சரிபார்ப்பு நேரத்திலேயே செலவு governance அமல்படுத்தப்படுகிறது—திட்டமிடப்படாத GPU ஒதுக்கீடுகள் budget மீறல்களை உருவாக்கும் platform-களுக்கு இது ஒரு முக்கியமான கொள்கை.

orchestrator ஒவ்வொரு golden path படியையும் provision செய்யும்போது, அதன் விளைவாக உருவாகும் connection விவரங்களை configuration store-இல் எழுதுகிறது; இதனால் downstream படிகள் அவற்றைத் தானாகக் கண்டறிய முடியும், hardcode செய்யப்பட்ட string-கள் நீக்கப்படுகின்றன. பின்வரும் helper-கள் கருத்துகள் பிரிவில் விவரிக்கப்பட்ட PUT மற்றும் GET செயல்பாடுகளைச் செயல்படுத்துகின்றன:

Code snippetpython
1import httpx
2
3def write_service_config(
4    namespace: str,
5    service_id: str,
6    key: str,
7    value: str,
8    config_api_base: str = "http://platform-config:8080",
9) -> None:
10    """Write a provisioned service's config for downstream golden path steps."""
11    url = f"{config_api_base}/config/{namespace}/{service_id}/{key}"
12    response = httpx.put(url, json={"value": value}, timeout=10.0)
13    response.raise_for_status()
14
15def read_service_config(
16    namespace: str,
17    service_id: str,
18    key: str,
19    config_api_base: str = "http://platform-config:8080",
20) -> str:
21    """Read a predecessor step's config during golden path provisioning."""
22    url = f"{config_api_base}/config/{namespace}/{service_id}/{key}"
23    response = httpx.get(url, timeout=10.0)
24    response.raise_for_status()
25    return response.json()["value"]

vector database படி முடிந்த பிறகு, orchestrator write_service_config("team-alpha", "vector-db/qdrant", "connection", connection_string) என்பதை அழைக்கிறது. பின்னர் model-serving படி endpoint-ஐக் கண்டறிய read_service_config("team-alpha", "vector-db/qdrant", "connection") என்பதை அழைக்கிறது—இது கருத்துகள் பிரிவில் விவரிக்கப்பட்ட namespace-ஆக்கப்பட்ட key pattern-உடன் பொருந்துகிறது, மேலும் consumer code மாற்றங்கள் இன்றி தானியங்கி credential rotation-ஐ சாத்தியமாக்குகிறது.

service_type=ServiceType.MODEL_SERVING மற்றும் gpu_requirements=None உடன் ஒரு ServiceCatalogEntry-ஐ instantiate செய்து சரிபாருங்கள்—validator ஒரு ValueError-ஐ raise செய்ய வேண்டும்; இது எந்த infrastructure-ம் தொடப்படும் முன், catalog பதிவு நேரத்திலேயே governance கொள்கை அமல்படுத்தப்படுவதை உறுதிப்படுத்துகிறது.

துறைசார் பயன்பாடு

செய்ய வேண்டியவை மற்றும் செய்யக்கூடாதவை

catalog மாதிரி, golden path configuration பரப்புதல் மற்றும் மேலே உள்ள துறைசார் பயன்பாடு ஆகியவற்றை நாம் பார்த்த நிலையில், பின்வரும் கட்டளைகள் governance மற்றும் wiring pattern-களை, உங்கள் சொந்த catalog entry-கள் மற்றும் golden path-களை வடிவமைக்கும்போது நேரடியாகப் பயன்படுத்தக்கூடிய விதிகளாகச் சுருக்குகின்றன.

செய்ய வேண்டியவை

1. ஒவ்வொரு model-serving மற்றும் training-job catalog entry-யிலும் gpu_requirements-ஐ அறிவிக்கவும் — gpu_requirements None ஆக இருக்கும்போது ServiceCatalogEntry-இல் உள்ள field_validator இந்தச் சேவை வகைகளை நிராகரிக்கிறது; இதன் மூலம் எந்த infrastructure-ம் provision செய்யப்படும் முன் schema சரிபார்ப்பு நேரத்திலேயே செலவு governance அமல்படுத்தப்பட்டு, திட்டமிடப்படாத GPU budget மீறல்கள் தடுக்கப்படுகின்றன.
2. நிலையான namespace-ஆக்கப்பட்ட key pattern-உடன் (எ.கா., "team-alpha" / "vector-db/qdrant" / "connection") write_service_config / read_service_config-ஐப் பயன்படுத்தவும் — இது சேவைகளில் connection string-களை hardcode செய்வதற்குப் பதிலாக, ஒவ்வொரு golden path படியும் முந்தைய படிகளின் output-களை platform control plane-இலிருந்து தானாகக் கண்டறிய உதவுகிறது.
3. semver-க்கு (^\d+\.\d+\.\d+$) கட்டுப்படுத்தப்பட்ட version field மற்றும் deprecated flag உடன் catalog entry-களை மாதிரியாக்கவும் — entry-களை பதிப்பிடப்பட்டதாகவும் deprecation-ஐ அறிந்ததாகவும் வைத்திருப்பது, orchestrator ServiceDependency.version_constraint சரிபார்ப்புகளை அமல்படுத்த உதவுகிறது; மேலும் இருக்கும் golden path படி வரிசைகளை உடைக்காமல் குழுக்களுக்கு ஒரு migration பாதையை வழங்குகிறது.

செய்யக்கூடாதவை

1. gpu_requirements-ஐத் தவிர்த்துவிட்டு orchestrator இயல்புநிலை மதிப்புகளை வழங்கும் என்று கருத வேண்டாம் — ServiceType.MODEL_SERVING மற்றும் ServiceType.TRAINING_JOB-க்கு GPURequirement ஒரு கட்டாய துணை-மாதிரி; அதைத் தவிர்ப்பது பதிவு நேரத்தில் ValueError-ஐ raise செய்கிறது, மேலும் platform இயல்புநிலைகளை அமைதியாக நம்பியிருப்பது, catalog நீக்க வடிவமைக்கப்பட்ட அந்த ad-hoc provisioning pattern-ஐத்தான் குறிக்கிறது.
2. golden path படி code-இல் connection string-களை hardcode செய்ய வேண்டாம் — write_service_config / read_service_config-ஐத் தவிர்ப்பது தானியங்கி credential-பரப்புதல் ஒப்பந்தத்தை உடைக்கிறது; அதாவது endpoint மாற்றங்களுக்கு (credential rotation-கள் உட்பட) config-store-இல் ஒரே ஒரு எழுத்துக்குப் பதிலாக, பயன்படுத்தும் ஒவ்வொரு சேவையிலும் கைமுறையாகப் புதுப்பிப்புகள் தேவைப்படும்.
3. ServiceType enum-க்கு வெளியே ஒரு ad-hoc service_type string-இன் கீழ் புதிய AI workload-ஐப் பதிவு செய்ய வேண்டாம் — enum-இன் kebab-case மதிப்புகள் (model-serving, vector-db, முதலியன) Kubernetes label மரபுகளுடன் ஒத்துப்போகின்றன, மேலும் governance validator-ம் GPU-தேவை சரிபார்ப்பும் இவற்றின் அடிப்படையிலேயே கிளைக்கின்றன; அங்கீகரிக்கப்படாத வகை field_validator மற்றும் orchestrator-இன் resource-quota logic ஆகிய இரண்டையும் தவிர்த்துவிடுகிறது.