Aperture Venture Studio ഒരേസമയം ഒന്നിലധികം സ്വതന്ത്ര കമ്പനികൾക്ക് സേവനം നൽകാൻ കഴിയുന്ന, AI-അധിഷ്ഠിത IoT (AIoT) പ്ലാറ്റ്ഫോമുകൾ നിർമ്മിക്കുന്നതിനായി ഒരു മൂന്ന് ഘട്ടങ്ങളുള്ള ആർക്കിടെക്ചർ അവതരിപ്പിച്ചു.
ഒരു പങ്കിട്ട (shared) AIoT പ്ലാറ്റ്ഫോം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
മിക്ക എഞ്ചിനീയറിംഗ് ഗ്രൂപ്പുകളും ഒരു പ്ലാറ്റ്ഫോം രൂപകൽപ്പന ചെയ്യുന്നത് ഒരു ഉൽപ്പന്നത്തിന് ചുറ്റുമാണ്, തുടർന്ന് അതിന്റെ ചില ഭാഗങ്ങൾ പിൽക്കാല റിലീസുകൾക്കായി വീണ്ടും ഉപയോഗിക്കുന്നു. എന്നാൽ, ഒരു വെഞ്ചർ സ്റ്റുഡിയോ വ്യത്യസ്ത ഉപഭോക്താക്കളെ ലക്ഷ്യം വെക്കുന്നതും, വ്യത്യസ്ത ഹാർഡ്വെയറുകളിൽ പ്രവർത്തിക്കുന്നതും, വ്യത്യസ്ത സമയക്രമങ്ങളിൽ മുന്നോട്ട് പോകുന്നതുമായ ഒന്നിലധികം സ്റ്റാർട്ടപ്പുകളെ ഒരേസമയം കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്. ഏകോപിതമല്ലാത്ത ഒരു സമീപനം ഇല്ലാതെയാണെങ്കിൽ, ഓരോ വെഞ്ചറും ഒരേ ഡാറ്റാ പൈപ്പ്ലൈനുകളും, മോഡൽ-ട്രെയിനിംഗ് സ്റ്റാക്കുകളും, ഡിവൈസ്-മാനേജ്മെന്റ് സേവനങ്ങളും ആദ്യം മുതൽ വീണ്ടും നിർമ്മിക്കേണ്ടി വരും. ഈ ആവർത്തനം സമയം പാഴാക്കുന്നു.
മൂന്ന് ഘട്ടങ്ങളുള്ള മോഡൽ
Aperture-ന്റെ സമീപനം ഇതിന്റെ ജീവിതചക്രം (lifecycle) മൂന്ന് വ്യക്തമായ ഘട്ടങ്ങളായി തിരിക്കുന്നു:
- ഒരു ഒറ്റ ഉപഭോക്താവിനുള്ള പ്രവർത്തനക്ഷമമായ പരിഹാരം (Working solution) – ടീമുകൾ യഥാർത്ഥ ലോക ആവശ്യങ്ങൾ നിറവേറ്റുന്ന ഒരു ഫങ്ഷണൽ AIoT സേവനം നൽകുന്നു, ഇത് ഒരു കൃത്യമായ ഉപയോഗക്രമവും (use case) ആവശ്യകതകളും നിശ്ചയിക്കുന്നു.
- പങ്കിട്ട പ്ലാറ്റ്ഫോമിലെ ആവർത്തനക്ഷമമായ മോഡ്യൂൾ (Repeatable module) – ഈ പരിഹാരത്തെ ഒരു പൊതു പ്ലാറ്റ്ഫോമിലെ മറ്റ് മോഡ്യൂളുകൾക്കൊപ്പം പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന രീതിയിൽ ഒരു പുനരുപയോഗിക്കാവുന്ന ഘടകമായി (reusable component) മാറ്റുന്നു. അസറ്റ് ട്രാക്കിംഗ്, വർക്ക്ഫോഴ്സ് സേഫ്റ്റി അല്ലെങ്കിൽ എൻവയോൺമെന്റൽ മോണിറ്ററിംഗ് എന്നിങ്ങനെയുള്ള വ്യത്യസ്ത മേഖലകളെ പിന്തുണയ്ക്കാൻ കോഡ് ആവശ്യത്തിന് അബ്സ്ട്രാക്റ്റ് (abstract) ആയിരിക്കണം എന്നതിനാൽ ഈ ഘട്ടം ഏറ്റവും കഠിനമാണ്.
- സ്പിൻ-ഔട്ടിനുള്ള (spin-out) യോഗ്യതയുള്ള ഘട്ടം – ഒരു വെഞ്ചർ സ്വന്തമായി ഒരു കമ്പനിയാകാൻ തയ്യാറാകുമ്പോൾ, അത് പങ്കിട്ട ഇൻഫ്രാസ്ട്രക്ചറിന് പകരം ഒരേ ഇന്റർഫേസുകൾ നടപ്പിലാക്കുന്ന ഒരു സ്വകാര്യ ഇൻസ്റ്റൻസ് (private instance) ഉപയോഗിക്കുന്നു, ഇത് കോഡിനെ മാറ്റമില്ലാതെ പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്നു.
രണ്ടാമത്തെ ഘട്ടമാണ് ഏറ്റവും കൂടുതൽ അധ്വാനം ആവശ്യമായത്. ഓരോ പുതിയ വെഞ്ചറിനും വേണ്ടി പൂജ്യത്തിൽ നിന്ന് പരിശീലിപ്പിക്കുന്നതിന് പകരം, ഫൈൻ ട്യൂൺ ചെയ്യാൻ കഴിയുന്ന ഒരു അടിസ്ഥാന AI മോഡൽ ലെയർ ടീമുകൾ നിർമ്മിക്കുന്നു. കോർ മോഡലുകളെ പങ്കിട്ട ആസ്തികളായി (shared assets) പരിഗണിക്കുന്നത് വഴി, അടിസ്ഥാന മോഡലിൽ വരുത്തുന്ന ഏതൊരു മെച്ചപ്പെടുത്തലും അതിനെ ആശ്രയിക്കുന്ന എല്ലാ വെഞ്ചറുകൾക്കും ഉടനടി പ്രയോജനപ്പെടുന്നു.
പൂർണ്ണമായ ഐസൊലേഷൻ ഇല്ലാതെ പങ്കിട്ട ഡാറ്റാ പൈപ്പ്ലൈനുകൾ
ഓരോ ടെനന്റിന്റെയും (tenant) ഡാറ്റാ പൈപ്പ്ലൈൻ പൂർണ്ണമായും വേർതിരിച്ചു നിർത്തുന്നത് വെഞ്ചറുകളെ വൃത്തിയായി വേർതിരിച്ചു നിർത്താൻ സഹായിക്കുമെന്ന് കരുതി പലരും ചെയ്യാറുള്ള ഒരു കാര്യമാണ്. എന്നാൽ പൂർണ്ണമായ ഐസൊലേഷൻ മെച്ചപ്പെടുത്തലുകളുടെ ഒഴുക്കിനെ തടയുമെന്ന് Aperture മുന്നറിയിപ്പ് നൽകുന്നു: ഒരു പൈപ്പ്ലൈനിൽ നടത്തുന്ന ബഗ് ഫിക്സോ പുതിയ ഡാറ്റാ ക്ലീനിംഗ് രീതിയോ മറ്റുള്ളവയിലേക്ക് എത്തുന്നില്ല. അവരുടെ ഹൈബ്രിഡ് സമീപനം ഇത് പരിഹരിക്കുന്നു:
- പ്രത്യേക ടെനന്റ് ഡാറ്റ – ഓരോ വെഞ്ചറിന്റെയും റോ ഡാറ്റ (raw data) അതിന്റെ സ്വന്തം സ്റ്റോറേജ് ബക്കറ്റിൽ തന്നെ ഇരിക്കുന്നു, ഇത് സ്വകാര്യതയും നിയമപരമായ മാനദണ്ഡങ്ങളും (compliance) സംരക്ഷിക്കുന്നു.
- പങ്കിട്ട പ്രോസസ്സിംഗ് ലോജിക് – ഡാറ്റ ക്ലീൻ ചെയ്യുകയും നോയിസ് ഒഴിവാക്കുകയും ഘടന നൽകുകയും ചെയ്യുന്ന പൊതുവായ കോഡ് ഒരു സിംഗിൾ ലൈബ്രറിയിൽ സൂക്ഷിക്കുന്നു. ആ ലൈബ്രറി അപ്ഡേറ്റ് ചെയ്യുന്നത് എല്ലാ വെഞ്ചറുകൾക്കും സ്വയമേവ പ്രയോജനപ്പെടുന്നു.
- വെഞ്ചർ-സ്പെസിഫിക് റൂളുകൾ – എഡ്ജ് കേസുകൾ (edge cases) കൈകാര്യം ചെയ്യാൻ പങ്കിട്ട ലോജിക്കിന് മുകളിൽ പ്രവർത്തിക്കുന്ന ചെറിയ പ്ലഗ്-ഇൻ ശൈലിയിലുള്ള റൂൾ സെറ്റുകൾ ഉപയോഗിക്കുന്നു. ഇത് കോറിന്റെ സ്ഥിരത നിലനിർത്തുന്നതോടൊപ്പം കസ്റ്റമൈസേഷനും അനുവദിക്കുന്നു.
ഈ ഡിസൈൻ പങ്കിട്ട പ്രോസസ്സിംഗ് ലോജിക് ഉപയോഗപ്പെടുത്തുന്നതോടൊപ്പം ഡാറ്റാ സോവറിന്റിയും (data sovereignty) ഉറപ്പാക്കുന്നു.
എളുപ്പത്തിലുള്ള സ്പിൻ-ഔട്ടിനായി ഡീകപ്പിളിംഗ് (Decoupling)
ടീമുകൾ സ്റ്റുഡിയോയുടെ ഇക്കോസിസ്റ്റത്തിൽ മാത്രം നിലനിൽക്കുന്ന ഇന്റേണൽ API-കളെ ആശ്രയിക്കുമ്പോൾ ടൈറ്റ് കപ്ലിംഗ് (tight coupling) ഉണ്ടാകുന്നു. എല്ലാ ഡിപെൻഡൻസികൾക്കും കർശനമായ ഇന്റർഫേസുകൾ നിർബന്ധമാക്കുന്നതിലൂടെ Aperture ഇതിനെ പ്രതിരോധിക്കുന്നു. ഓരോ മോഡ്യൂളും അതിന്റെ ആവശ്യമായ കരാറുകൾ (contracts) പ്രഖ്യാപിക്കുന്നു—അത് ഡിവൈസ് കമ്മ്യൂണിക്കേഷൻ, മോഡൽ ഇൻഫറൻസ് അല്ലെങ്കിൽ ബില്ലിംഗ് എന്നിവയാകട്ടെ—അതിലപ്പുറം ഒന്നുമല്ല.
ഒരു വെഞ്ചർ സ്പിൻ-ഔട്ട് ഘട്ടത്തിൽ എത്തുമ്പോൾ, അത് ആ ഇന്റർഫേസുകളെ അതിന്റെ സ്വന്തം ഇംപ്ലിമെന്റേഷനുകളിലേക്ക് തിരിച്ചുവിടുന്നു. കോഡ് ഒരിക്കലും ഒരു ഇന്റേണൽ സർവീസിനെ നേരിട്ട് വിളിക്കാത്തതിനാൽ, മാറ്റം എന്നത് ഒരു പൂർണ്ണമായ റീ-റൈറ്റിംഗിന് പകരം ഒരു കോൺഫിഗറേഷൻ പ്രശ്നം മാത്രമായി മാറുന്നു. ഈ ഡീകപ്പിളിംഗ് നേരത്തെ പ്ലാൻ ചെയ്യുന്നത് പിന്നീട് വലിയ ചിലവുള്ള റീ-ആർക്കിടെക്ചർ ഒഴിവാക്കാൻ സഹായിക്കുന്നു.
റിസ്കുകളും പ്രതിവാദങ്ങളും
പങ്കിട്ട ഇൻഫ്രാസ്ട്രക്ചർ മോഡൽ എല്ലാ പ്രശ്നങ്ങൾക്കും ഒരു പരിഹാരമല്ല (silver bullet).
ഇനി ശ്രദ്ധിക്കേണ്ടവ
Takeaway: വ്യക്തമായ ഇന്റർഫേസുകൾ, ഒരു പൊതു മോഡൽ ബേസ്, ഒരു ഹൈബ്രിഡ് ഡാറ്റാ-പൈപ്പ്ലൈൻ സ്ട്രാറ്റജി എന്നിവയുള്ള ഒരു പങ്കിട്ട AIoT പ്ലാറ്റ്ഫോം നിർമ്മിക്കുന്നത് വെഞ്ചർ സ്റ്റുഡിയോകൾക്ക് ഒന്നിലധികം സ്റ്റാർട്ടപ്പുകൾ വേഗത്തിൽ ആരംഭിക്കാനും അവയെ വൃത്തിയായി സ്പിൻ-ഔട്ട് ചെയ്യാനും സഹായിക്കുന്നു.