സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് പ്രക്രിയ – ഭാഗം 2        

ലല്ലു ആന്തൂര്‍

എന്തൊക്കെ സവിശേഷതകളാണ് ഒരു സോഫ്റ്റ്‌വെയറിനു വേണ്ടത് എന്നും അത് എങ്ങിനെയാണ് തിരിച്ചറിയുന്നത് എന്നും നമ്മൾ കഴിഞ്ഞ ലേഖനത്തിൽ മനസിലാക്കിയല്ലോ. ഇനി അതിനെ എങ്ങിനെ ഒരു സോഫ്റ്റ്‌വെയർ ആക്കി മാറ്റാം എന്ന് നോക്കാം. സോഫ്റ്റ്‌വെയർ റിക്വയർമെന്റ് തയ്യാറായിക്കഴിഞ്ഞാൽ അടുത്തതായി ചെയ്യേണ്ട കാര്യം നിർമിക്കാൻ പോകുന്ന സോഫ്റ്റ്‌വെയറിന്റെ ഡിസൈൻ രൂപകൽപന ചെയ്യുക എന്നതാണ്. ഒരു സോഫ്റ്റ്‌വെയർ കമ്പനി ഇതിനെ എങ്ങിനെ സമീപിക്കുന്നു എന്ന് നോക്കാം.

അതിനായി നമുക്ക് സൂപ്പർ മാർക്കറ്റിലെ ബില്ലിംഗ് കൗണ്ടറിൽ ഉപയോഗിക്കുന്ന ഒരു സോഫ്റ്റ്‌വെയർ എങ്ങിനെ ഇരിക്കണം എന്ന് ധാരണ വേണം. ഒരു ഉപഭോക്താവ് തന്റെ ഷോപ്പിംഗ് സഞ്ചി/ട്രോളിയുമായി ബില്ലിംഗ് കൗണ്ടറിൽ എത്തുമ്പോൾ അതിവേഗം സാധനങ്ങൾ നോക്കി അത് കമ്പ്യൂട്ടറിൽ ചേർത്ത് ബില്ല് തയാറാക്കുക എന്നതാണ് അവിടെ ആവശ്യം. അതിനായി ഉള്ള സംവിധാനമായിരിക്കും സ്‌ക്രീനിൽ കാണുക. സാധനങ്ങളുടെ പേര് കീബോർഡ് മുഖാന്തരം ടൈപ്പ് ചെയ്തു കൊടുക്കുമ്പോൾ സ്റ്റോക്കിലുള്ള സാധനങ്ങളുടെ പേര് സ്‌ക്രീനിൽ തെളിയണം. പിന്നീട് അളവ് കൂടി ചേർത്ത് കൊടുത്താൽ നികുതിയും തുകയും സ്വയം കണക്കാക്കണം. സാധനങ്ങൾ ചേർക്കുന്നതിന് കണക്കാക്കി ആകെ തുകയും സ്വയം കണക്കാക്കണം. ഒരു ബട്ടൺ അമർത്തിയാൽ ബില്ല് പ്രിന്റ് ചെയ്ത് കിട്ടണം. ഇത്രയുമാണ് പ്രാഥമിക ആവശ്യങ്ങൾ. സാധങ്ങളുടെ പേര് ടൈപ്പ് ചെയ്യുന്നതിന് പകരം ബാർ കോഡ് സ്കാൻ ചെയ്യാനുള്ള സംവിധാനവും ആവാം. ഇത് കൂടാതെ പ്രിന്റ് ചെയ്യുന്ന ഓരോ ബില്ലിന്റെയും വിവരങ്ങൾ സൂക്ഷിച്ചു വയ്ക്കാനും ബില്ലിലെ വിവരങ്ങൾ അനുസരിച്ച് സ്റ്റോക്ക് രജിസ്റ്ററിൽ നിന്നും സാധനങ്ങളുടെ സ്റ്റോക്ക് കുറയ്ക്കാനും സാധിക്കണം.

Notepad/GEdit പോലുള്ള ഒരു സോഫ്റ്റ്‌വെയർ ആണ് ഇതിനായി നിർമിക്കുന്നതെങ്കിൽ എന്താവും അവസ്ഥ? ബില്ലിംഗ് കൗണ്ടറുകളിലെ കംപ്യൂട്ടറുകളിൽ അതാതു കൗണ്ടറിലെ വില്പന കണക്കുകൾ രേഖപ്പെടുത്താനാവും. എന്നാൽ പിന്നീട് ഇവ ക്രോഡീകരിക്കാൻ പെൻഡ്രൈവോ മറ്റോ ഉപയോഗിച്ച്  ഇവയെല്ലാം കോപ്പി ചെയ്ത് ഒരു കമ്പ്യൂട്ടറിൽ എത്തിക്കണം. എന്നിട്ട് ഈ ഫയലുകൾ എല്ലാം തുറന്ന് വിവരങ്ങൾ ക്രോഡീകരിക്കണം. ഇത് വളരെ ശ്രമകരമായ ജോലിയാണ്. ഏതെങ്കിലും ഒരു ബില്ലിംഗ് കൗണ്ടറിലെ കമ്പ്യൂട്ടർ കേടായിപ്പോയാൽ അന്നത്തെ വില്പന കണക്കുകൾ നഷ്ടമാവുകയും ചെയ്യും. അതിനാൽ അതാതു കംപ്യൂട്ടറുകളിൽ വിവരങ്ങൾ സൂക്ഷിക്കുന്ന സോഫ്റ്റ്‌വെയർ ഇവിടെ അഭികാമ്യമല്ല. ഓട്ടോമാറ്റിക് ആയി വിവരങ്ങൾ എല്ലാം മറ്റൊരു സുരക്ഷിത സ്ഥാനത്തേക്ക് മാറ്റുന്ന ഒരു സോഫ്റ്റ്‌വെയർ ആണ് ഇവിടെ ആവശ്യം. കമ്പ്യൂട്ടർ ശൃംഖല മുഖാന്തരം ഇത്തരം ജോലി ചെയ്യുന്ന സോഫ്റ്റ്‌വെയറുകളെ ക്ലയന്റ്-സെർവർ സോഫ്റ്റ്‌വെയർ എന്ന് പറയുന്നു. ഉപഭോക്താക്കൾ ക്ലയന്റ് കംപ്യൂട്ടറുകളിൽ നിന്നും സോഫ്റ്റ്‌വെയറുമായി സംവദിക്കുന്നു. സോഫ്റ്റ്‌വെയറിന്റെ കാതലായ പ്രവർത്തനവും വിവരങ്ങളുടെ ക്രോഡീകരണവും സെർവർ കമ്പ്യൂട്ടറിൽ നടക്കുന്നു. വളരെ സുരക്ഷിതവും ഉയർന്ന ശേഷിയുമുള്ള ഒരു കംപ്യൂട്ടറാണ് സെർവർ കമ്പ്യൂട്ടർ. ചില ഭാഗങ്ങൾ പ്രവർത്തന രഹിതമായാലും സോഫ്റ്റ്‌വെയറിന്റെ പ്രവർത്തനം നിലച്ചു പോവാത്ത രീതിയിലുള്ള fail-safe സൗകര്യങ്ങളും ഇതിൽ ലഭ്യമാണ്. ക്ലയന്റ് കംപ്യൂട്ടറുകളിൽ നിന്നും ഫയർഫോക്സ്, ക്രോമിയം തുടങ്ങിയ ഒരു വെബ് ബ്രൗസർ വഴി നമുക്ക് ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ ഉപയോഗിക്കാം. ക്ലയന്റ് കംപ്യൂട്ടറുകൾ അത്ര ഉയർന്ന നിലവാരമുള്ളത് വേണ്ട എന്ന് സാരം.

ഈ സെർവർ കമ്പ്യൂട്ടർ ആരാണ് നോക്കി നടത്തുന്നത് എന്നതിനനുസരിച്ച് ക്ലയന്റ്-സെർവർ സോഫ്റ്റ്‌വെയറുകളെ on-premise സോഫ്റ്റ്‌വെയർ എന്നും on-cloud സോഫ്റ്റ്‌വെയർ എന്നും തരംതിരിക്കാം. ഉപഭോക്താവിന്റെ പരിസരത്താണ് സെർവർ കമ്പ്യൂട്ടർ എങ്കിൽ (ഉപഭോക്താവാണ് അത് നോക്കി നടത്തുന്നത് എങ്കിൽ) അതിനെ on-premise സോഫ്റ്റ്‌വെയർ എന്ന് വിളിക്കും. മറിച്ച് സോഫ്റ്റ്‌വെയർ ദാതാക്കളാണ് ഈ സെർവർ കമ്പ്യൂട്ടർ വാങ്ങുന്നതും നോക്കി നടത്തുന്നതും എങ്കിൽ അതിനെ on-cloud സോഫ്റ്റ്‌വെയർ (സോഫ്റ്റ്‌വെയർ ആസ് എ സർവീസ്) എന്ന് വിളിക്കും. ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ ഉപയോഗിക്കാൻ ഇന്റർനെറ്റ് സൗകര്യം അത്യാവശ്യമാണ്. അതുപോലെ നമ്മുടെ സൂപ്പർ മാർക്കറ്റിൽ ഇത്തരം ഒരു സോഫ്റ്റ്‌വെയർ വാങ്ങിയാൽ അതിൽ ചേർക്കുന്ന സ്റ്റോക്ക് , വില്പന തുടങ്ങിയ എല്ലാ വിവരങ്ങളും ഇന്റർനെറ്റ് വഴി സോഫ്റ്റ്‌വെയർ സേവന ദാതാക്കളുടെ സെർവർ കമ്പ്യൂട്ടറിൽ എത്തുകയും അവിടെ സൂക്ഷിക്കപ്പെടുകയും ചെയ്യും. ഈ വിവരങ്ങളുടെ സുരക്ഷിതത്വത്തിന് (വിവര ചോർച്ചയിൽ നിന്നും പ്രകൃതി ദുരന്തങ്ങളിൽ നിന്നും മറ്റു നാശനഷ്ടങ്ങളിൽ നിന്നും) സോഫ്റ്റ്‌വെയർ ദാതാക്കൾക്കാണ് പൂർണ ഉത്തരവാദിത്തം. വിവര സുരക്ഷിതത്വത്തെക്കുറിച്ചുള്ള ഈ ലേഖന പരമ്പര വായിക്കുമല്ലോ!

ഇത്തരം ഒരു സംവിധാനത്തിന് സാങ്കേതികപരമായി എന്തൊക്കെ വേണം എന്ന് നോക്കാം. കണക്കുകൾ ചിട്ടയായി രേഖപ്പെടുത്താൻ തുടങ്ങിയ നാൾ മുതൽ നമ്മൾ ഉപയോഗിക്കുന്ന ഒരു “ടെക്നോളജി” ആണ് പട്ടികകൾ. വില വിവര പട്ടിക, വരവ് ചിലവ് പട്ടിക, ഹാജർ പട്ടിക, തുടങ്ങി ഒരുപാട് പട്ടികകൾ നമുക്ക് സുപരിചിതമാണ്. സൂപ്പർ മാർക്കറ്റിലും സ്ഥിതി വ്യത്യസ്തമല്ല. സ്റ്റോക്ക് സൂക്ഷിക്കാനുള്ള സ്റ്റോക്ക് രജിസ്റ്ററും ബില്ലും ബില്ലിന്റെ വിവരങ്ങൾ രേഖപ്പെടുത്തി വയ്ക്കുന്ന വില്പന കണക്കും എല്ലാം പട്ടികകൾ തന്നെ. കമ്പ്യൂട്ടർ ലോകത്തും ഈ രീതിയിൽ വിവരങ്ങൾ പട്ടികകളായി സൂക്ഷിക്കാനുള്ള സംവിധാനം ഉണ്ട്. അതിനെ റിലേഷണൽ ഡാറ്റാബേസ് ^[1] എന്നാണ് വിളിക്കുക. ചുരുക്കിപ്പറഞ്ഞാൽ ഏത് വിധേനയുള്ള പട്ടികകൾ തയാറാക്കാനും അതിൽ വിവരങ്ങൾ ചേർത്ത് വയ്ക്കാനും കൂടാതെ ആവശ്യാനുസരണം വിവരങ്ങൾ വായിച്ചെടുക്കുവാനും കഴിവുള്ള ഒരു സംവിധാനമാണ് റിലേഷണൽ ഡാറ്റാബേസ്. എന്നാൽ കമ്പ്യൂട്ടർവത്കരിക്കുന്നത് കൊണ്ട് മറ്റു ചില സൗകര്യങ്ങൾ കൂടി ഇതിനോട് ചേർത്ത് വയ്ക്കപ്പെട്ടിട്ടുണ്ട്. ഒരു പട്ടികയിൽ നിന്ന് ആവശ്യമുള്ള വരി (row) അല്ലെങ്കിൽ നിര (column) മാത്രം തിരഞ്ഞെടുക്കാനുള്ള സൗകര്യം, വിവിധ പട്ടികകളിലെ വിവരങ്ങൾ കോർത്തിണക്കി ഒറ്റ പട്ടികയായി കാണാനുള്ള സൗകര്യം, ആർക്കൊക്കെ ഏതൊക്കെ വിവരങ്ങൾ കാണാൻ അല്ലെങ്കിൽ മാറ്റുവാൻ പറ്റും എന്ന് നിയന്ത്രിക്കാൻ പറ്റുന്ന സൗകര്യം, വേഗത്തിൽ വേണ്ട വിവരങ്ങൾ വായിച്ചെടുക്കാൻ വിവര സൂചിക (index) (പുസ്തകത്തിന്റെ ഉള്ളടക്ക സൂചിക പോലെ) തുടങ്ങിയവ ഡാറ്റാബേസ് സോഫ്റ്റ്‌വെയറുകളിൽ ലഭ്യമാണ്. എന്നാൽ ഇത്തരം ഒരു ഡാറ്റാബസിന്റെ പ്രത്യേകത എന്ന് പറയുന്നത് ഇതിലേക്ക് വിവരങ്ങൾ ചേർക്കാനോ ഇതിൽ നിന്നും വിവരങ്ങൾ ശേഖരിക്കാനോ ഒരു പ്രത്യേക തരം കമ്പ്യൂട്ടർ ഭാഷ (SQL) ഉപയോഗിക്കേണ്ടി വരും എന്നതാണ്.

അതുകൊണ്ട് ഉപഭോക്താക്കളുടെ പണി എളുപ്പമാക്കാൻ മേൽപ്പറഞ്ഞ പ്രകാരമുള്ള വളരെ ലഘുവായ ഒരു interfafce ആവശ്യമാണ്. അപ്പോൾ അടുത്ത ചോദ്യം ഇതാണ്. കീബോർഡും മൗസും (ചിലപ്പോൾ ടച്ച് സ്ക്രീനും) വഴി ഉപഭോക്താക്കൾ നടത്തുന്ന interactions ആരാണ് SQL ആയി മാറ്റുന്നത്? SQL വഴി ലഭിക്കുന്ന ഉത്തരങ്ങൾ ആരാണ് തിരിച്ചു മോണിറ്ററിൽ നിശ്ചിത സ്ഥാനങ്ങളിൽ പ്രദർശിപ്പിക്കുന്നത്? മോണിറ്ററിൽ ഏത് ഭാഗത്ത് എന്ത് വിവരങ്ങൾ കാണിക്കണം എന്ന് ആരാണ് തീരുമാനിക്കുന്നത്? ഇവിടെയാണ് നമ്മൾ മുൻകൂട്ടി തയ്യാറാക്കിയ persona കളുടെ ഉപയോഗം വരുന്നത്. ഓരോ persona യുടേയും ആവശ്യങ്ങൾ വായിച്ചു മനസിലാക്കി അവർക്കു വേണ്ടിയുള്ള interface തയ്യാറാക്കുന്നത് UI Designer അല്ലെങ്കിൽ UX Engineer ആണ്. അതാതു persona-കളുടെ ജോലി എളുപ്പമാക്കുന്ന രീതിയിൽ സ്‌ക്രീനിൽ വിവരങ്ങൾ സജ്ജീകരിക്കുന്നതാണ് ഇവരുടെ ജോലി. ജിമെയിൽ എന്ന cloud സോഫ്റ്റ്‌വെയറിനു വന്ന രൂപമാറ്റങ്ങൾ നോക്കിക്കഴിഞ്ഞാൽ തന്നെ നമുക്ക് ഒരു UI ഡിസൈനർ അല്ലെങ്കിൽ UX എഞ്ചിനീയർ എന്ത് ചെയ്യുന്നു എന്ന് മനസിലാക്കാം. ഇവർ പൊതുവെ അഡോബിയുടെ ഫോട്ടോഷോപ്പ്, എക്സ് ഡി തുടങ്ങിയ സോഫ്റ്റ്‌വെയറുകളാണ് ഇങ്ങനെ ഡിസൈൻ തയ്യാറാക്കാൻ ഉപയോഗിക്കുന്നത്. അതായത്, interface ഡിസൈൻ എന്നത് ഒരു ചിത്രം ആണെന്ന് ചുരുക്കം. ഒരു UX എഞ്ചിനീയർ ഇങ്ങനെ ഒരു interface തയ്യാറക്കി എന്നിരിക്കട്ടെ. അപ്പോഴാണ് അടുത്ത പ്രശ്നം. ഒരു ചിത്രവുമായി interaction സാധ്യമല്ല. അതിനു പറ്റുന്ന രീതിയിൽ ബ്രൗസറിൽ കാണാൻ വെബ് പേജുകൾ തയ്യാറാക്കണം. എന്നാൽ ബ്രൗസറിനാകട്ടെ അകെ 3 ഭാഷകളെ അറിയൂ – HTML, CSS, JavaScript. SQL ഉപയോഗിച്ച് വെബ് പേജ് തയ്യാറാക്കാൻ പറ്റില്ല. HTML ഉപയോഗിച്ച് വെബ് പേജിന്റെ ഘടനയും (structure) CSS ഉപയോഗിച്ച് അതിന്റെ വർണ്ണനയും (style) നമുക്ക് വിവരിക്കാം. JavaScript ഉപയോഗിക്കുന്നത് പേജുകൾക്ക് ജീവൻ (dynamicity) നൽകാനാണ്. സാഹചര്യങ്ങൾക്കനുസരിച്ച് ഘടനയും വർണ്ണനയും തീരുമാനിക്കാൻ JavaScript സഹായിക്കുന്നു. കമ്പ്യൂട്ടറിൽ ഒരു രീതിയിൽ കാണുന്ന പേജുകൾ മൊബൈലിൽനോക്കുമ്പോൾ മറ്റൊരു രീതിയിൽ കാണുന്നത് JavaScript ഉപയോഗിച്ചുള്ള മാന്ത്രികവിദ്യകളാണ്.

ഒരു പ്രശ്നം ഇപ്പോഴും ബാക്കി. ബ്രൗസറിൽ നടക്കുന്ന interactions ആരാണ് SQL ആയി മാറ്റുന്നത്? ആരാണ് SQL തരുന്ന മറുപടി HTML/CSS/JavaScript ആയി മാറ്റുന്നത്. അതിനാണ് ഒരു വെബ് സർവീസ് (അല്ലെങ്കിൽ ഒരു കൂട്ടം വെബ് സർവീസുകൾ) ഉപയോഗിക്കുന്നത്. സർവീസുകൾ ഏതെങ്കിലും ഒരു കമ്പ്യൂട്ടർ ഭാഷയിൽ എഴുതിയ പ്രോഗ്രാമുകളാണ്. സിംപിളും പവർഫുള്ളും ആയ Java മുതൽ പുതുപുത്തൻ ഭാഷകളായ Go ഉം Rust ഉം വരെ ഏതും ഇതിനായി ഉപയോഗിക്കാം. ഇത്തരം സർവീസുകൾ സെർവർ കമ്പ്യൂട്ടറിൽ സ്ഥിരമായി പ്രവർത്തിച്ചുകൊണ്ടിരിക്കും. അവ ഒരു  അഡ്രസ് വഴി ഇന്റർനെറ്റുമായി ബന്ധിപ്പിച്ചിരിക്കും. തപാൽ സംവിധാനം വഴി കത്തുകൾ നമ്മുടെ വീട്ടിൽ എത്തുന്നതുപോലെ ഈ അഡ്രസ് ഉപയോഗിച്ച് വിവരങ്ങൾക്കായുള്ള റിക്വസ്റ്റുകൾ നമ്മുടെ സെർവറിൽ ഉള്ള സർവീസിൽ എത്തുന്നു. ക്ലയന്റ് കംപ്യൂട്ടറുകളിലെ ബ്രൗസറുകളിൽ  നിന്നാണ്  വിവരങ്ങൾക്കായുള്ള അഭ്യർത്ഥനകൾ (request) പുറപ്പെടുന്നത്. ഒരു ബില്ലിംഗ് കൗണ്ടറിൽ നിന്നും ഒരു സാധനത്തിന്റെ ആദ്യത്തെ കുറച്ച് അക്ഷരങ്ങൾ ടൈപ്പ് ചെയ്യുമ്പോൾ ആ അക്ഷരങ്ങൾ അടങ്ങുന്ന സാധങ്ങളുടെ ലിസ്റ്റ് ലഭിക്കാനുള്ള ഒരു റിക്വസ്റ് ബ്രൗസറിൽ നിന്നും സെർവറിലേക്ക് പുറപ്പെടുന്നു. സർവീസിൽ ഈ റിക്വസ്റ് ലഭിക്കുമ്പോൾ അത് ഇതിനെ SQL ഭാഷയിലേക്ക് മാറ്റുന്നു. പിന്നീട് ഡാറ്റാബേസുമായി SQL ഭാഷ വഴി സംസാരിച്ച് വിവരങ്ങൾ സ്വീകരിക്കുന്നു. അങ്ങനെ കിട്ടിയ വിവരങ്ങൾ പിന്നീട് ബ്രൗസറിന് മനസിലാകുന്ന രീതിയിലാക്കി ക്ലയന്റിന്റെ റിക്വസ്റ്റിന് മറുപടി കൊടുക്കുന്നു. ഇത്തരത്തിൽ മറുപടി കൊടുക്കുമ്പോൾ 2 രീതിയിലുള്ള മറുപടികൾ സാധ്യമാണ്. ഡാറ്റാബേസിൽ നിന്നും ലഭിച്ച വിവരങ്ങൾ ഉൾക്കൊള്ളിച്ച് ഒരു പുതിയ വെബ് പേജ് പൂർണമായും നിർമിച്ച് അത് ക്ലയന്റിലേക്ക് അയക്കാം. ഈ രീതിയെ SSR (Server Side Rendering) എന്ന് പറയുന്നു. ഈ രീതിയുടെ ഗുണം എന്ന് പറയുന്നത് ക്ലയന്റ് കമ്പ്യൂട്ടറിൽ വളരെ കുറച്ച് കാര്യങ്ങൾ മാത്രം ചെയ്താൽ മതി എന്നതാണ്. എന്നാൽ ഇതിന്റെ പരിമിതിയായി കരുതുന്നത് കൂടുതൽ വിവരങ്ങൾ ഇന്റർനെറ്റ് വഴി കൈമാറ്റം ചെയ്യേണ്ടിവരും എന്നതാണ്. വിവരം കൈമാറാനുള്ള മറ്റൊരു രീതിയാണ് CSR (Client Side Rendering). ഇവിടെ ഡാറ്റാബേസിൽ നിന്ന് ലഭിച്ച വിവരങ്ങൾ ഒരു machine readable format ൽ ക്ലയന്റ് കമ്പ്യൂട്ടറിലേക്ക് അയക്കുന്നു. JSON, XML തുടങ്ങിയവയാണ് ഏറെ പ്രചാരത്തിലുള്ള ഫോർമാറ്റുകൾ. ഇങ്ങനെ വിവരങ്ങൾ കിട്ടിയാൽ അതിനെ വെബ് പേജിന്റെ വ്യത്യസ്ത ഭാഗങ്ങളിൽ ചേർത്ത് വയ്‌ക്കേണ്ട ചുമതല ബ്രൗസറിനാണ്. ഈ രീതിയിൽ വിവരം കൈമാറ്റം ചെയ്യുമ്പോൾ ചുരുങ്ങിയ കാര്യങ്ങളേ ഇന്റർനെറ്റ് വഴി കൈമാറ്റം ചെയ്യേണ്ടതുള്ളൂ. എന്നാൽ ക്ലയന്റ് കംപ്യൂട്ടറിലെ ബ്രൗസറിന് കൂടുതൽ ജോലിയാവും.

ഈ രീതിയിൽ വിവരങ്ങൾ കൈകാര്യം ചെയ്യാൻ നമുക്ക് ഒരു സർവീസിനെയോ ഒന്നിലധികം സർവീസുകളേയോ ആശ്രയിക്കാം. ഒരു സർവീസ് ആണ് എല്ലാ ജോലിയും ചെയ്യുന്നത് എങ്കിൽ അതിന് ഒരുപാട് വലിയ ഒരു പ്രോഗ്രാം എഴുതേണ്ടി വരും. കൂടാതെ ഈ പ്രോഗ്രാമിൽ ഏതെങ്കിലും ഒരു ഭാഗത്ത് ഒരു തെറ്റ് വന്നാൽ അത് പ്രോഗ്രാമിന്റെ പ്രവർത്തനത്തെ പൂർണമായും ബാധിക്കുന്നു. ഇത്തരത്തിൽ എല്ലാ ആവശ്യങ്ങൾക്കും വേണ്ടി ഒരു വലിയ സോഫ്റ്റ്‌വെയർ/പ്രോഗ്രാം എഴുതുന്ന രീതിയെ monolithic architecture എന്ന് പറയുന്നു. ഇതിനു വിപരീതമായി ഓരോ ആവശ്യങ്ങൾക്കും പ്രത്യേകം സർവീസ് എഴുതുന്ന രീതിയെ micro service architecture എന്ന് പറയുന്നു. ഇതിലെ ഓരോ സർവീസും ഓരോ ജോലി ഭംഗിയായി ചെയ്യാൻ പ്രാപ്തിയുള്ളവയായിരിക്കും. വിവരങ്ങൾ തിരയാൻ ഒരു സർവീസ്, ബില്ല് സൂക്ഷിക്കാൻ ഒരു സർവീസ്, സ്റ്റോക്ക് നോക്കാൻ മറ്റൊരു സർവീസ്, എന്നിങ്ങനെ നമുക്ക് സൂപ്പർ മാർക്കറ്റ് സോഫ്റ്റ്‌വെയറിനെ വിഭജിക്കാം. ഇതിന്റെ പ്രത്യേകത എന്ന് പറയുന്നത് സ്റ്റോക്ക് നോക്കുന്ന ഭാഗത്തിന് ഒരു തകരാറു വന്നാൽ ബില്ല് തയ്യാറാക്കാൻ പറ്റാതെ വരില്ല എന്നുള്ളതാണ്. അതായത് ഓരോ ഭാഗത്തിന്റെയും പ്രവർത്തനം സ്വതന്ത്രവും സ്വയം പര്യാപ്തവും ആണ് എന്നതാണ്.

എന്നാൽ ഇത്തരം സർവീസുകൾ തമ്മിലും വിവര വിനിമയം വേണ്ടിവരും. ഉദാഹരണത്തിന് ബില്ല് സൂക്ഷിക്കുന്ന സർവീസിന് സ്റ്റോക്ക് നോക്കുന്ന സർവീസിനോട് സ്റ്റോക്കിൽ നിന്നും സാധനങ്ങൾ കുറക്കാൻ പറയണം. ഇത്തരത്തിൽ വിവര വിനിമയം സാധ്യമാക്കാൻ പല രീതികളും ഉണ്ട്. ഒരു രീതി ബില്ലിംഗ് സർവീസ് നേരിട്ട് സ്റ്റോക്ക് സർവീസുമായി സംവദിക്കുക എന്നതാണ്. ഇതിനെ service-to-service communication എന്ന് പറയുന്നു. ഐസ് ക്രീം കഴിക്കാനായി ഐസ് ക്രീം പാർലറിൽ പോയി ഓർഡർ ചെയ്യുന്നതുമായി ഇതിനെ താരതമ്യം ചെയ്യാം. മറ്റൊരു രീതി ബില്ലിംഗ് സർവീസ് നേരിട്ട് സ്റ്റോക്ക് സർവീസിലെ ഒരു പ്രത്യേക ഭാഗവുമായി സംവദിക്കുക എന്നതാണ്. ഇതിനെ RPC (Remote Procedure Call) എന്ന് പറയുന്നു.

ഒരു സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്ടിന്റെ ജോലി എന്നത് ഈ രീതിയിലുള്ള എല്ലാ കാര്യങ്ങളിലും ഒരു തീരുമാനം എടുക്കുക എന്നതാണ്. ആദ്യമായി സാധാരണ ഡെസ്ക്ടോപ്പ് സോഫ്റ്റ്‌വെയർ വേണോ ക്ലയന്റ്-സെർവർ സോഫ്റ്റ്‌വെയർ വേണോ എന്നുള്ള തീരുമാനമാണ്. ഒരു സൂപ്പർ മാർക്കറ്റിനെ സംബന്ധിച്ചിടത്തോളം ക്ലയന്റ്-സെർവർ സോഫ്റ്റ്‌വെയർ ആണ് കുറേക്കൂടെ ഉപയോഗപ്രദം. അടുത്ത ചോദ്യം അത് on-premise ആയാണോ on-cloud ആയാണോ നിർമ്മിക്കേണ്ടത് എന്നാണ്. ഒരു സൂപ്പർ മാർക്കറ്റിൽ സെർവർ കമ്പ്യൂട്ടർ സ്ഥാപിക്കുകയും നോക്കി നടത്തുകയും ചെയ്യുക വളരെ ബുദ്ധിമുട്ടാണ്. സൂപ്പർ മാർക്കറ്റ് ജീവനക്കാർക്ക് അതിനുള്ള പ്രായോഗിക പരിചയം ഇല്ലാത്തതും ചിലവ് കൂടുതലായതും കൊണ്ടാണ് അത്. അതുകൊണ്ട് നമ്മൾ on-cloud സോഫ്റ്റ്‌വെയർ നിർമിക്കുന്നു. Cloud സോഫ്റ്റ്‌വെയർ ആണെങ്കിൽ അത് പൊതുവെ micro service architecture ൽ ആയിരിക്കും ഉണ്ടാക്കുക. ഇത്രയും കാര്യങ്ങൾ തീരുമാനമായാൽ സാങ്കേതികവിദ്യകളെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാം.

ഏത് ഡാറ്റാബേസ് സോഫ്റ്റ്‌വെയർ ആണ് ഇതിനായി ഉപയോഗിക്കുക? PostgresSQL, MySQL, Oracle, SAP HANA തുടങ്ങി സൗജന്യവും paid ഉം ആയ നിരവധി ഡാറ്റാബേസ് സോഫ്റ്റ്‌വെയറുകൾ ലഭ്യമാണ്. അതിൽ ഒന്നിനെ തിരഞ്ഞെടുക്കുമ്പോൾ performance, scalability, disaster recovery, ചിലവ് തുടങ്ങി ഒരുപാട് കാര്യങ്ങൾ കണക്കിലെടുക്കണം. അടുത്ത ചോദ്യം ഏത് ഭാഷയിലാണ് സർവീസുകൾ എഴുതുക? നമ്മൾ തിരഞ്ഞെടുത്ത ഡാറ്റാബേസുമായി എളുപ്പത്തിൽ സംവദിക്കാൻ കഴിയുന്ന മറ്റു സർവീസുകളുമായി എളുപ്പത്തിൽ സംവദിക്കാൻ കഴിയുന്ന അത്യാവശ്യം നല്ല രീതിയിൽ performace ഉള്ള, ഒരുപാട് പേർ ഒന്നിച്ച് ഉപയോഗിച്ചാൽ തകരാത്ത, JSON/XML നല്ല രീതിയിൽ കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന, സോഫ്റ്റ്‌വെയർ നിർമിക്കുന്ന സംഘത്തിലെ എല്ലാവർക്കും (ഭൂരിഭാഗം ആളുകൾക്കും) അറിയുന്ന ഒരു ഭാഷയാവും ഇതിനായി തിരഞ്ഞെടുക്കുക. സർവീസുകൾ നമ്മൾ ഒന്നിൽ നിന്നും പ്രോഗ്രാം എഴുതി തയ്യാറാക്കേണ്ട ആവശ്യം ഇപ്പോൾ ഇല്ല. നിരവധി framework കൾ ഇതിനായി തയ്യാറാക്കപ്പെട്ടിട്ടുണ്ട്. സർവീസ് നിർമാണം എളുപ്പവും വേഗത്തിലും ആക്കാൻ ഇത്തരം framework കൾ സഹായിക്കുന്നു. Java യിൽ SpringBoot, NodeJS ൽ Express, Go യിൽ Gin Gonic തുടങ്ങി ഒരുവിധം എല്ലാ ഭാഷകളിലും ഇത്തരം framework കൾ ഉണ്ട്. Framework കളുടെ ലഭ്യതയും പക്വതയും പ്രായോഗികതയും ഒരു ഭാഷ തിരഞ്ഞെടുക്കുന്നതിൽ ഘടകമാണ്. അടുത്തതായി സർവീസുകൾ തമ്മിൽ ഏത് രീതിയിൽ സംസാരിക്കും എന്നുള്ള തീരുമാനമാണ്. Cloud സോഫ്റ്റ്‌വെയറിൽ പൊതുവെ RPCയോ messagingഓ ആണ് ഉപയോഗിക്കാറ്. അവസാനമായി വെബ് പേജുകൾ നിർമിക്കാൻ എന്ത് സാങ്കേതികവിദ്യ ഉപയോഗിക്കും എന്ന് തീരുമാനിക്കണം. ഇതിനായി HTML/CSS/JavaScript നേരിട്ടോ അല്ലെങ്കിൽ സർവീസുകൾ ഉണ്ടാക്കിയതുപോലെ framework കളോ ഉപയോഗിക്കാം. BootStrap, Material പോലുള്ള framework കൾ പൊതുവെ Server Side Rendering നും, Angular, React, Vue പോലുള്ള framework കൾ Client Side Rendering നും ഉപയോഗിക്കുന്നു. നമ്മുടെ സൂപ്പർ മാർക്കറ്റിനു വേണ്ടി നമുക്ക് MySQL ഡാറ്റാബേസും Java/SprintBoot ഉപയോഗിച്ചുള്ള സർവീസുകളും RPC ഉപയോഗിച്ചുള്ള ആശയവിനിമയവും Angular ഉപയോഗിച്ചുള്ള Client Side Rendering സംവിധാനവും ഉപയോഗിക്കാം.

അടുത്ത വലിയ ചോദ്യം cloud സംവിധാനം എങ്ങിനെ തരപ്പെടുത്തും എന്നുള്ളതാണ്. ഏതൊരു സോഫ്റ്റ്‌വെയർ കമ്പനിക്കും സ്വന്തമായി സെർവർ കംപ്യൂട്ടറുകൾ വാങ്ങി ഒരു cloud സോഫ്റ്റ്‌വെയർ നിർമിക്കാവുന്നതാണ്. എന്നാൽ അതിനായി പ്രാവീണ്യം ഉള്ള ഒരു കൂട്ടം ആളുകളെയും ആവശ്യമായി വരും. കൂടാതെ ഇത്തരം സെർവറുകൾ നോക്കിനടത്താനും അതിനു വേണ്ടരീതിയിൽ സുരക്ഷിതത്വം ഏർപ്പെടുത്താനും എല്ലാം ഒരുപാടു കാര്യങ്ങൾ ചെയ്യേണ്ടതുണ്ട്. അതുകൊണ്ടുതന്നെ cloud സൗകര്യം ഈ കാര്യത്തിൽ പ്രാവീണ്യമുള്ള ആളുകളുടെ കയ്യിൽ നിന്നും വാടകക്ക് എടുക്കാറാണ് പതിവ്. സോഫ്റ്റ്‌വെയറിന്റെ വില നിശ്ചയിക്കുമ്പോൾ ഈ വാടകയും അതിൽ ഒരു ഘടകമാണ്. ആമസോൺ (AWS), ഗൂഗിൾ (Google Cloud), മൈക്രോസോഫ്റ്റ് (Azure), SAP (SAP Cloud Platform), ആലിബാബ (Alibaba Cloud) തുടങ്ങിയവരാണ് ഈ രംഗത്ത് പ്രമുഖർ. നമ്മൾ മുകളിൽ തിരഞ്ഞെടുത്ത സാങ്കേതികവിദ്യകൾ എല്ലാം സപ്പോർട്ട് ചെയ്യുന്ന മികച്ച സൗകര്യങ്ങളുള്ള ഒരു cloud സേവന ദാതാവിനെയാവും തിരഞ്ഞെടുക്കുക. ഇത്രയും കാര്യങ്ങൾ തീരുമാനിച്ചാൽ ഡിസൈൻ ഘട്ടത്തിലെ ജോലി പകുതി പൂർത്തിയായി.

---

[1]: വരികളും നിരകളും പട്ടികകളും അല്ലാതെ വിവരങ്ങൾ സൂക്ഷിക്കുന്ന ഡാറ്റാബേസുകളും ഉണ്ട്. അവയെ NoSQL ഡാറ്റാബേസ് എന്ന് വിളിക്കുന്നു.

ലൂക്ക പ്രസിദ്ധീകരിച്ച മറ്റു ലേഖനങ്ങൾ

1. സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് പ്രക്രിയ – ഭാഗം 1
2. ഒരു സോഫ്റ്റ്‌വെയർ നിര്‍മ്മിക്കപ്പെടുന്നതെങ്ങിനെ?