Aperture Venture Studio એ AI-સક્ષમ IoT (AIoT) પ્લેટફોર્મ બનાવવા માટે ત્રણ-તબક્કાનું આર્કિટેક્ચર રજૂ કર્યું છે, જે એકસાથે અનેક સ્વતંત્ર કંપનીઓને સેવા આપી શકે છે.
શા માટે શેર કરેલ AIoT પ્લેટફોર્મ મહત્વનું છે
મોટાભાગના એન્જિનિયરિંગ જૂથો એક સિંગલ પ્રોડક્ટને ધ્યાનમાં રાખીને પ્લેટફોર્મ ડિઝાઇન કરે છે, અને પછી તેને પછીના રિલીઝ માટે ફરીથી ઉપયોગમાં લે છે. જોકે, એક વેન્ચર સ્ટુડિયોએ એવા અનેક સ્ટાર્ટઅપ્સ સંભાળવા પડે છે જે અલગ-અલગ ગ્રાહકોને લક્ષ્ય બનાવે છે, અલગ-અલગ હાર્ડવેર પર ચાલે છે અને અલગ-અલગ સમયરેખા પર કામ કરે છે. સંકલિત અભિગમ વિના, દરેક વેન્ચર સમાન ડેટા પાઇપલાઇન્સ, મોડલ-ટ્રેનિંગ સ્ટેક્સ અને ડિવાઇસ-મેનેજમેન્ટ સેવાઓને ફરીથી શૂન્યથી બનાવે છે. આ ડુપ્લીકેશન સમયનો બગાડ કરે છે.
ત્રણ-તબક્કાનું મોડલ
Aperture નો અભિગમ જીવનચક્રને ત્રણ સ્પષ્ટ તબક્કાઓમાં વિભાજિત કરે છે:
- એક સિંગલ ગ્રાહક માટે કાર્યકારી સોલ્યુશન – ટીમો એક કાર્યરત AIoT સેવા પહોંચાડે છે જે વાસ્તવિક જરૂરિયાત પૂરી કરે છે, જેનાથી એક ચોક્કસ ઉપયોગનું કેસ (use case) અને જરૂરિયાતોનો સમૂહ સ્થાપિત થાય છે.
- શેર કરેલા પ્લેટફોર્મમાં પુનરાવર્તિત કરી શકાય તેવું મોડ્યુલ – સોલ્યુશનને ફરીથી ઉપયોગમાં લઈ શકાય તેવા ઘટકમાં (component) રિફેક્ટર કરવામાં આવે છે જે સામાન્ય પ્લેટફોર્મમાં અન્ય મોડ્યુલ્સની સાથે રહે છે. આ તબક્કો સૌથી અઘરો છે કારણ કે કોડ એટલો એબ્સ્ટ્રેક્ટ (abstract) હોવો જોઈએ કે જે એસેટ ટ્રેકિંગ, વર્કફોર્સ સેફ્ટી અથવા એન્વાયરમેન્ટલ મોનિટરિંગ જેવા વિવિધ ક્ષેત્રોને સપોર્ટ કરી શકે.
- સ્પિન-આઉટ માટે ઉમેદવાર – જ્યારે કોઈ વેન્ચર પોતાની અલગ કંપની બનવા માટે તૈયાર હોય, ત્યારે તે શેર કરેલા ઇન્ફ્રાસ્ટ્રક્ચરને ખાનગી ઇન્સ્ટન્સ (private instance) સાથે બદલી નાખે છે જે સમાન ઇન્ટરફેસનો ઉપયોગ કરે છે, જેનાથી કોડમાં કોઈ ફેરફાર કર્યા વિના તે ચલાવી શકાય છે.
મધ્ય તબક્કો સૌથી વધુ કામગીરી ધરાવે છે. ટીમો AI મોડલ્સનું એક બેઝ લેયર બનાવે છે જેને દરેક નવા વેન્ચર માટે શૂન્યથી તાલીમ આપવાને બદલે ફાઇન-ટ્યુન (fine-tune) કરી શકાય છે. મુખ્ય મોડલ્સને શેર કરેલી સંપત્તિ તરીકે ગણવાથી બેઝ મોડલમાં કરવામાં આવેલ કોઈપણ સુધારો તેના પર નિર્ભર તમામ વેન્ચર્સને તરત જ લાભ આપે છે.
સંપૂર્ણ અલગતા વિના શેર કરેલી ડેટા પાઇપલાઇન્સ
એક સામાન્ય લાલચ એ છે કે દરેક ટેનન્ટની ડેટા પાઇપલાઇનને સંપૂર્ણપણે અલગ કરી દેવી, એવું માનીને કે તેનાથી વેન્ચર્સ સ્પષ્ટ રીતે અલગ રહેશે. Aperture ચેતવણી આપે છે કે સંપૂર્ણ અલગતા સુધારાઓના પ્રવાહને અવરોધે છે: એક પાઇપલાઇન પર લાગુ કરવામાં આવેલ બગ ફિક્સ અથવા નવી ડેટા-ક્લીનિંગ રૂટિન ક્યારેય અન્ય સુધી પહોંચતી નથી. તેમનો હાઇબ્રિડ અભિગમ આ સમસ્યાનું સમાધાન કરે છે:
- અલગ ટેનન્ટ ડેટા – દરેક વેન્ચરનો કાચો ડેટા (raw data) તેના પોતાના સ્ટોરેજ બકેટમાં રહે છે, જે પ્રાઇવસી અને પાલન (compliance) જાળવી રાખે છે.
- શેર કરેલ પ્રોસેસિંગ લોજિક – ડેટાને ક્લીન, ડિનોઇઝ અને સ્ટ્રક્ચર કરતો કોમન કોડ એક સિંગલ લાઇબ્રેરીમાં રહે છે. તે લાઇબ્રેરીને અપડેટ કરવાથી દરેક વેન્ચરને આપમેળે ફાયદો થાય છે.
- વેન્ચર-સ્પેસિફિક નિયમો – એજ કેસ (edge cases) ને નાના, પ્લગ-ઇન-સ્ટાઇલ નિયમ સેટ દ્વારા સંભાળવામાં આવે છે જે શેર કરેલા લોજિકની ઉપર કામ કરે છે, જેનાથી મુખ્ય લોજિક સ્થિર રહે છે અને સાથે સાથે કસ્ટમાઇઝેશનની સુવિધા પણ મળે છે.
આ ડિઝાઇન શેર કરેલા પ્રોસેસિંગ લોજિકનો લાભ લેતી વખતે ડેટા સાર્વભૌમત્વ (data sovereignty) પ્રદાન કરે છે.
પીનલેસ સ્પિન-આઉટ માટે ડીકપલિંગ (Decoupling)
જ્યારે ટીમો એવા ઇન્ટરનલ API પર આધાર રાખે છે જે માત્ર સ્ટુડિયોના ઇકોસિસ્ટમમાં જ અસ્તિત્વ ધરાવે છે, ત્યારે ટાઇટ કપલિંગ (tight coupling) ઊભું થાય છે. Aperture તમામ ડિપેન્ડન્સીઝ માટે કડક ઇન્ટરફેસ લાગુ કરીને આનો સામનો કરે છે. દરેક મોડ્યુલ તેને જરૂરી કોન્ટ્રાક્ટ્સ જાહેર કરે છે—પછી તે ડિવાઇસ કોમ્યુનિકેશન, મોડલ ઇન્ફરન્સ અથવા બિલિંગ માટે હોય—અને તેનાથી વધુ કંઈ નહીં.
જ્યારે કોઈ વેન્ચર સ્પિન-આઉટ તબક્કે પહોંચે છે, ત્યારે તે ફક્ત તે ઇન્ટરફેસને તેના પોતાના ઇમ્પ્લીમેન્ટેશન તરફ નિર્દેશિત કરે છે. કારણ કે કોડ ક્યારેય સીધી રીતે કોઈ ચોક્કસ ઇન્ટરનલ સર્વિસને કોલ કરતો નથી, તેથી આ બદલાવ સંપૂર્ણ રીરાઇટ કરવાને બદલે માત્ર કોન્ફિગરેશનનો વિષય બની જાય છે. આ ડીકપલિંગનું વહેલું આયોજન કરવાથી પછીથી મોંઘા રી-આર્કિટેક્ચરથી બચી શકાય છે.
જોખમો અને વિરોધ પક્ષના મુદ્દાઓ
શેર કરેલ ઇન્ફ્રાસ્ટ્રક્ચર મોડલ એ દરેક સમસ્યાનું સરળ સમાધાન નથી.
આગળ શું જોવું
મુખ્ય વાત: સ્પષ્ટ ઇન્ટરફેસ, કોમન મોડલ બેઝ અને હાઇબ્રિડ ડેટા-પાઇપલાઇન વ્યૂહરચના સાથે શેર કરેલ AIoT પ્લેટફોર્મ બનાવવાથી વેન્ચર સ્ટુડિયોઝ અનેક સ્ટાર્ટઅપ્સ ઝડપથી લોન્ચ કરી શકે છે અને તેમને ચોખ્ખી રીતે સ્પિન-આઉટ કરી શકે છે.