Aperture Venture Studio השיקה ארכיטקטורה בת שלושה שלבים לבניית פלטפורמות AIoT (IoT מבוסס בינה מלאכותית) שיכולות לשרת מספר חברות עצמאיות בו-זמנית.
למה פלטפורמת AIoT משותפת היא חשובה
רוב קבוצות ההנדסה מתכננות פלטפורמה סביב מוצר בודד, ואז משתמשות בחלקים ממנה עבור גרסאות עתידיות. לעומת זאת, venture studio חייב לנהל מספר סטארט-אפים שמטרתם לקוחות שונים, פועלים על חומרה שונה ומתקדמים בלוחות זמנים שונים. ללא גישה מתואמת, כל מיזם בונה מחדש את אותם צינורות נתונים (data pipelines), מחסניות אימון מודלים (model-training stacks) ושירותי ניהול מכשירים מאפס. הכפילות הזו מבזבזת זמן.
המודל בעל שלושת השלבים
הגישה של Aperture מחלקת את מחזור החיים לשלושה שלבים ברורים:
- פתרון עובד עבור לקוח בודד – צוותים מספקים שירות AIoT תפקודי שעונה על צורך בעולם האמיתי, תוך קביעת מקרה בוחן (use case) קונקרטי וסט של דרישות.
- מודול הניתן לשחזור בפלטפורמה משותפת – הפתרון עובר refactoring לרכיב שניתן לשימוש חוזר, השוכן לצד מודולים אחרים בפלטפורמה משותפת. שלב זה הוא הקשה ביותר מכיוון שהקוד חייב להיות מופשט מספיק כדי לתמוך בתחומים שונים כמו מעקב אחר נכסים, בטיחות כוח אדם או ניטור סביבתי.
- מועמד ל-spin-out – כאשר מיזם מוכן להפוך לחברה עצמאית, הוא מחליף את התשתית המשותפת במופע (instance) פרטי המיישם את אותם ממשקים (interfaces), מה שמאפשר לקוד לרוץ ללא שינוי.
השלב האמצעי הוא זה שמבצע את העבודה הקשה ביותר. צוותים יוצרים שכבת בסיס של מודלי AI שניתן לבצע להם fine-tuning במקום לאמן אותם מאפס עבור כל מיזם חדש. התייחסות למודלי ליבה כנכסים משותפים פירושה שכל שיפור במודל הבסיס יועיל באופן מיידי לכל המיזמים הנשענים עליו.
צינורות נתונים משותפים ללא בידוד מלא
פיתוי נפוץ הוא לבודד לחלוטין את צינור הנתונים של כל שוכר (tenant), מתוך הנחה שזה שומר על הפרדה נקייה בין המיזמים. Aperture מזהירה כי בידוד מלא חוסם את זרימת השיפורים: תיקון באג או שגרת ניקוי נתונים חדשה המיושמת על צינור אחד לעולם לא תגיע לאחרים. הגישה ההיברידית שלהם פותרת זאת:
- נתוני שוכר נפרדים – הנתונים הגולמיים של כל מיזם נשארים ב-storage bucket משלו, מה ששומר על פרטיות וציות (compliance).
- לוגיקת עיבוד משותפת – קוד משותף שמנקה, מסיר רעשים ומבנה נתונים חי בספרייה (library) אחת. עדכון הספרייה הזו מועיל לכל מיזם באופן אוטומטי.
- כללים ספציפיים למיזם – מקרי קצה מטופלים על ידי סטים קטנים של כללים בסגנון plug-in, היושבים מעל הלוגיקה המשותפת, מה ששומר על יציבות הליבה תוך אפשרות להתאמה אישית.
העיצוב מספק ריבונות נתונים (data sovereignty) תוך ניצול לוגיקת עיבוד משותפת.
Decoupling ל-spin-out ללא כאבים
צימוד הדוק (tight coupling) מתגנב כאשר צוותים מסתמכים על APIs פנימיים הקיימים רק בתוך האקוסיסטם של הסטודיו. Aperture נלחמת בכך על ידי אכיפת ממשקים (interfaces) קשיחים לכל התלויות (dependencies). כל מודול מצהיר על החוזים (contracts) שהוא זקוק להם — בין אם לתקשורת עם מכשירים, הסקה של מודלים (model inference) או חיוב — ושום דבר מעבר לכך.
כאשר מיזם מגיע לשלב ה-spin-out, הוא פשוט מכוון את הממשקים הללו למימושים (implementations) שלו עצמו. מכיוון שהקוד מעולם לא קרא ישירות לשירות פנימי קונקרטי, ההחלפה הופכת לעניין של קונפיגורציה ולא לכתיבה מחדש מלאה. תכנון ה-decoupling הזה בשלב מוקדם מונע ארכיטקטורה מחדש יקרה בהמשך.
סיכונים ונקודות נגד
מודל התשתית המשותפת אינו "כדור כסף" (פתרון קסם).
מה לצפות בהמשך
שורה תחתונה: בניית פלטפורמת AIoT משותפת עם ממשקים ברורים, בסיס מודלים משותף ואסטרטגיית צינור נתונים היברידית מאפשרת ל-venture studios להשיק מספר סטארט-אפים מהר יותר ולהוציא אותם (spin them out) בצורה נקייה.