ஒவ்வொரு பொறியியல் குழுவும் சிரமமின்றி வளரக்கூடிய ஒரு அமைப்பை விரும்புகிறது. போக்குவரத்து சீராக அதிகரிப்பதையும், சர்வர்கள் தடையின்றி இயங்குவதையும், வருவாய் படிப்படியாக உயருவதையும் நாம் கற்பனை செய்கிறோம். ஆனால் யதார்த்தம் முகம் காட்டும் போது நிலைமை மாறுகிறது. ஒரு வைரல் மார்க்கெட்டிங் பிரச்சாரத்தால் பயனர்களின் எண்ணிக்கை திடீரென அதிகரிக்கும் போது, தரவுத்தளம் (database) முடங்குகிறது, மேலும் அதிகாலை மூன்று மணி அளவில் யாரோ ஒருவர் பதற்றத்துடன் சேவைகளை மீண்டும் தொடங்கிக் கொண்டிருக்கிறார்கள். இதற்கு கருவிகளையே நாம் குற்றம் சாட்டுகிறோம். நமக்கு இன்னும் அதிக கோர்கள் (cores), வேகமான டிஸ்க்குகள் அல்லது மற்றொரு கேச்சிங் லேயர் (caching layer) தேவை என்று நாம் நமக்குள் சொல்லிக்கொள்கிறோம். ஆனால் வளர்ச்சி என்பது வன்பொருளிலிருந்து (hardware) வருவதல்ல; அது கட்டமைப்பிலிருந்து (structure) வருகிறது. உங்கள் அடித்தளம் எடையைப் பகிர்ந்து அளிக்கத் தெரியவில்லை என்றால், ஒவ்வொரு புதிய பயனரும் ஒரு வெற்றியாக இல்லாமல் ஒரு சுமையாகவே மாறிவிடுவார்.
சிதைந்த கட்டமைப்பை கருவிகளால் காப்பாற்ற முடியாது
நீங்கள் நூற்றுக்கணக்கான கிளவுட் இன்ஸ்டன்ஸ்களை (cloud instances) உருவாக்கலாம், புவியியல் ரீதியாகப் பிரிக்கப்பட்ட பகுதிகளுக்கு இடையே லோட் பேலன்சர்களை (load balancers) சேர்க்கலாம் மற்றும் உலகளாவிய உள்ளடக்க விநியோக வலையமைப்பில் (CDN) ஒவ்வொரு நிலையான சொத்தையும் கேச் (cache) செய்யலாம். இவை செயல்பாட்டைத் துரிதப்படுத்தும் காரணிகள் மட்டுமே. ஆனால் பூஜ்ஜியத்தை எதைக் கொண்டு பெருக்கினாலும் விடை பூஜ்ஜியம் தான். சிக்கலான சார்புகளைக் (dependencies) கொண்ட ஒரு மோனோலிதிக் அப்ளிகேஷன் (monolithic application), அதன் அடியில் எவ்வளவு வன்பொருள் இருந்தாலும், அதன் சொந்த எடையிலேயே நசுங்கிவிடும்.
தயாரிப்பு பட்டியல் (product catalog), கட்டணச் செயலாக்கம் (payment processing) மற்றும் பயனர் அங்கீகாரம் (user authentication) ஆகிய அனைத்தும் ஒரே கோட்பாட்டில் (codebase) இருக்கும் ஒரு ஆன்லைன் ஸ்டோரை கற்பனை செய்து பாருங்கள். செக்அவுட் செயல்முறை மெதுவானால், முழு தளமும் மந்தமாகிவிடும். லாகின் பக்கம் தடுமாறும். உலாவல் அனுபவம் பாதிக்கப்படும். மற்ற அனைத்தையும் மாற்றியமைக்காமல், அந்தத் தடையூற்றை (bottleneck) மட்டும் தனியாக அளவிட (scale) முடியாது. இது செலவு மிக்கது, திறமையற்றது மற்றும் பலவீனமானது. உங்கள் பயனர்கள் உடனடியாகத் திறக்க வேண்டிய பக்கங்களுக்காகக் காத்திருக்கும் போது, யாருக்கும் பயனளிக்காத கணினித் திறனுக்காக (compute power) நீங்கள் பணம் செலுத்த வேண்டியிருக்கும்.
இந்தத் தடையிலிருந்து கட்டமைப்பே (Architecture) தீர்வாகும். உங்கள் கருவிகள் உங்களுக்கு உதவப் போகின்றனவா அல்லது இடையூறு செய்யப் போகின்றனவா என்பதைத் தீர்மானிக்கும் கண்ணுக்குத் தெரியாத எலும்புக்கூடு இதுவாகும்.
ஒரு வலுவான கட்டமைப்பு என்பது உண்மையில் எதைக் குறிக்கிறது
ஒரு வலுவான கட்டமைப்பு என்பது எளிமையாகச் சொன்னால், பொறுப்புகள் எங்கு இருக்க வேண்டும் என்பதற்கான ஒரு திட்டமே ஆகும். இது ஆரம்பத்திலேயே கடினமான கேள்விகளைக் கேட்கிறது. ஒரு பகுதி உடைந்தால் என்ன நடக்கும்? பரிந்துரை இயந்திரத்தை (recommendation engine) தொடாமல் கட்டண முறையை (billing logic) மாற்ற முடியுமா? உங்கள் அப்ளிகேஷனின் ஒரு பகுதியில் ஏற்படும் போக்குவரத்து அதிகரிப்பு, மற்ற பகுதிகளைப் பாதிக்காமல் இயல்பாக இருக்க முடியுமா? உங்கள் நிரலாக்க மொழி (programming language), பிரேம்வொர்க் (framework) அல்லது கிளவுட் வழங்குநரை விட இந்த கேள்விகளே மிக முக்கியமானவை.
நல்ல கட்டமைப்பு உங்கள் முடிவுகளை மாற்றிக்கொள்ள இடமளிக்கிறது. ஒரு குழுவின் சோதனை மற்ற குழுவின் உற்பத்திப் பணியை (production workload) சீர்குலைக்காதவாறு தெளிவான எல்லைகளை இது வரையறுக்கிறது. தோல்வியைத் தற்செயலான ஒரு அதிர்ச்சியாகப் பார்க்காமல், அதை ஒரு இயல்பான செயல்பாட்டு நிலையாக இது கருதுகிறது. தோல்வியைக் கருத்தில் கொண்டு நீங்கள் வடிவமைக்கும்போது, நீங்கள் கண்ணாடி வீடுகளைக் கட்டாமல், வளையும் தன்மை கொண்ட கட்டமைப்புகளைக் கட்டத் தொடங்குவீர்கள்.
ஒரு நடைமுறை முறையாக மைக்ரோசர்வீஸ்கள் (Microservices)
அத்தகைய கட்டமைப்பைப் பெறுவதற்கான ஒரு நடைமுறை வழி உங்கள் அப்ளிகேஷனை மைக்ரோசர்வீஸ்களாகப் பிரிப்பதாகும். ஒரு பெரிய கோட்பாட்டிற்குப் பதிலாக, செயலியைச் சிறிய பகுதிகளாகப் பிரிக்கலாம். ஒவ்வொரு பகுதியும் ஒரு குறிப்பிட்ட வேலையைச் செய்யும். பேமெண்ட் சேவை பரிவர்த்தனைகளைச் செய்யும். இன்வென்டரி சேவை இருப்பைக் கண்காணிக்கும். நோட்டிஃபிகேஷன் சேவை மின்னஞ்சல்கள் மற்றும் குறுஞ்செய்திகளை அனுப்பும். அவை நேரடி மெமரி அணுகல் அல்லது பகிரப்பட்ட தரவுத்தள அட்டவணைகளுக்குப் பதிலாக, வரையறுக்கப்பட்ட இடைமுகங்கள் (interfaces) மூலம் தொடர்பு கொள்கின்றன.
இந்தத் தனிமைப்படுத்தல் தொழில்நுட்ப ரீதியாகவும் நிறுவன ரீதியாகவும் செயல்பட உண்மையான இடவசதியை உருவாக்குகிறது.
முழு அமைப்பையும் பாதிக்காமல் சிறிய பகுதிகளைப் புதுப்பிக்கலாம்
சேவைகள் சிறியதாகவும் குறிப்பிட்ட பணிகளுக்காகவும் இருக்கும்போது, ஒரு பகுதி தோல்வியடையும் அபாயமின்றி மற்றொரு பகுதியை நீங்கள் சரிசெய்ய முடியும். உங்கள் குழு ஷிப்பிங் கணக்கீட்டு அல்காரிதத்தில் ஒரு பிழையைக் கண்டறிந்தால், அந்தச் சேவையை மட்டும் சரிசெய்து தனியாகப் பயன்படுத்தலாம் (deploy). மீதமுள்ள அப்ளிகேஷன் தொடர்ந்து இயங்கும். பயனர்கள் தொடர்ந்து தயாரிப்புகளைப் பார்க்கலாம், லாகின் செய்யலாம் மற்றும் பொருட்களைத் தங்கள் கூடையில் சேர்க்கலாம். எந்தவொரு மாற்றமும் மிகச்சிறிய பாதிப்பு எல்லையிலேயே (blast radius) இருக்கும். ஒரு சிறிய பிழை கூட செக்அவுட், பதிவு மற்றும் அறிக்கையிடல் ஆகிய அனைத்தையும் ஒரே நேரத்தில் முடக்கும் மோனோலிதிக் அமைப்போடு இதை ஒப்பிட்டுப் பாருங்கள்.
போக்குவரத்து அதிகரிக்கும் போது குறிப்பிட்ட செயல்பாடுகளை மட்டும் அளவிடலாம்
ஒரு அப்ளிகேஷனில் போக்குவரத்து எப்போதும் சீராக இருப்பதில்லை. ஒரு ஃபிளாஷ் சேல் (flash sale) காலத்தின் போது, உங்கள் ஆர்டர் செயல்முறை அதிக அழுத்தத்திற்கு உள்ளாகலாம், அதே நேரத்தில் உங்கள் உள்ளடக்க மேலாண்மை அமைப்பு (content management system) கிட்டத்தட்ட பயன்பாட்டில்லாமல் இருக்கலாம். ஒரு நெருக்கமான அமைப்பில் (tightly coupled system), நீங்கள் அனைத்தையும் அளவிட வேண்டும் அல்லது எதையும் அளவிட முடியாது. மைக்ரோசர்வீஸ்கள் மூலம், உங்கள் வளங்களை (resources) துல்லியமாகப் பயன்படுத்தலாம். செக்அவுட் சேவையின் இன்ஸ்டன்ஸ்களை மட்டும் அதிகப்படுத்தலாம். தயாரிப்பு பட்டியலை அதன் வழக்கமான அளவில் இயக்கலாம். ஒரு தயாரிப்பு அறிமுகத்தின் போது, உங்கள் தேடல் குறியீடு (search index) அமைதியாக இருக்கும் அதே வேளையில், உங்கள் இமேஜ் ப்ராசஸிங் பணியாளர்கள் ஆயிரக்கணக்கான தம்ப்நெயில்களை உருவாக்க வேண்டியிருக்கலாம். இமேஜ் பணியாளர்களின் தேவையை மட்டும் பூர்த்தி செய்ய தேடல் கிளஸ்டரை (search cluster) விரிவாக்க வேண்டிய அவசியமில்லை. பயனர்கள் எங்கு உணர்கிறார்களோ அங்கு நீங்கள் பணத்தைச் செலவிடுகிறீர்கள், மேலும் உங்கள் அமைப்பு அழுத்தத்திலும் சிறப்பாக இயங்குகிறது.
நீண்ட நேர முடக்கம் இன்றி புதிய குறியீட்டை வெளியிடலாம்
சிறிய சேவைகள் (Small services) பராமரிப்பு கால இடைவெளிகளை (maintenance windows) தேவையற்றதாக்கும் deployment முறைகளை அனுமதிக்கின்றன. நீங்கள் rolling deployments முறையைப் பயன்படுத்தலாம், அதாவது மற்றவை போக்குவரத்தைத் (traffic) தொடர்ந்து வழங்கும் அதே வேளையில், புதிய குறியீட்டை (code) சில குறிப்பிட்ட instances-களுக்கு மட்டும் அனுப்பலாம். உங்கள் பிழை விகிதங்களைக் (error rates) கவனியுங்கள், ஏதேனும் தவறு என்று தோன்றினால், சில நொடிகளில் கோரிக்கைகளை (requests) முந்தைய பதிப்பிற்குத் திருப்பி விடலாம். Blue-green deployments மூலம் நீங்கள் முற்றிலும் புதிய சூழலை (environment) உருவாக்கி, அதைச் சரிபார்த்து, மிகக் குறைந்த அபாயத்துடன் போக்குவரத்தை மாற்றலாம். யாராவது கைமுறையாக database migrations செய்வதற்காகத் தளம் பல மணிநேரம் காணாமல் போக வேண்டிய அவசியமில்லை.
புதிய அம்சங்களை விரைவாக உருவாக்குங்கள்
பெரிய codebase-கள் எச்சரிக்கையைத் தூண்டுகின்றன. ஒரு சிறிய மாற்றம் கூட ஆயிரக்கணக்கான தொடர்பில்லாத தர்க்கங்களை (logic) புரிந்துகொள்வதையும், பல மணிநேரம் எடுக்கும் regression tests மற்றும் ராக்கெட் ஏவுதல் போலத் தோன்றும் deployment கால அட்டவணைகளையும் கோருகிறது. சிறிய சேவைகள் அந்த அச்சத்தைப் போக்குகின்றன. ஒரு குழு, தாங்கள் நன்கு அறிந்த ஒரு சேவையில் சில நூறு வரிகளை மாற்றுவதன் மூலம் புதிய அம்சத்தை உருவாக்க முடியும். அவர்கள் அன்றைய தினமே commit செய்து, test செய்து, ship செய்துவிடலாம். அந்த வேகம் (velocity) பெருகிக்கொண்டே செல்லும். சேவைகள் தெளிவான பொறுப்புகளால் பிணைக்கப்படும்போது, குழுக்கள் ஒருவருக்கொருவர் வேலையில் குறுக்கிடுவதை நிறுத்துகிறார்கள். அவர்கள் தங்கள் களத்தை (domain) ஆரம்பம் முதல் இறுதி வரை சொந்தமாக நிர்வகிக்கிறார்கள்.
சுதந்திரம் பெரிய இடையூறுகளைத் தடுக்கிறது
ஒவ்வொரு சேவையும் தனியாகச் செயல்படுகிறது. அந்தச் சுதந்திரம் என்பது வெறும் நிர்வாக வசதி மட்டுமல்ல; அது ஒரு கட்டமைப்பு ரீதியான காப்பீடு (structural insurance). பரிந்துரை இயந்திரம் (recommendation engine) செயலிழந்தாலும், ஸ்டோர் தொடர்ந்து பொருட்களை விற்க வேண்டும். ஒரு தவறான நிகழ்வினால் (malformed event) analytics pipeline முடங்கினாலும், login service பயனர்களைத் தொடர்ந்து அங்கீகரிக்க வேண்டும் (authenticate). ஒரு தோல்வி முழுமையான செயலிழப்பாக (outage) மாறாமல் இருக்க, சேவைகளுக்கு இடையே circuit breakers மற்றும் fallback paths ஆகியவற்றை நீங்கள் வடிவமைக்க வேண்டும். உங்கள் பயனர்களுடன் சேர்ந்து அமைப்பும் வளர்கிறது, ஏனெனில் அது சிதறாமல் அழுத்தத்தைத் தாங்கும் திறன் கொண்டது.
ஒரு எச்சரிக்கை: கண்மூடித்தனமாக பிரிக்காதீர்கள்
இதற்கெல்லாம் நீங்கள் முதல் நாளிலேயே உங்கள் codebase-ஐ உடைக்க வேண்டும் என்று அர்த்தமல்ல. Microservices தெளிவான எல்லைகளைக் கோருகின்றன. ஒரு துறை எங்கு முடிந்து மற்றொன்று எங்கு தொடங்குகிறது என்பதை உங்கள் குழுக்கள் இன்னும் அறியவில்லை என்றால், அவர்கள் ஒரு distributed system-க்கு பதிலாக ஒரு distributed mess-ஐ உருவாக்குவார்கள். நீங்கள் குறியீட்டுச் சிக்கலை (code complexity) செயல்பாட்டுச் சிக்கலாக (operational complexity) மாற்றிக்கொள்வீர்கள், திடீரென்று நீங்கள் network latency, distributed transactions, retry storms மற்றும் டஜன் கணக்கான log streams හරහා observability ஆகியவற்றை நிர்வகிக்க வேண்டியிருக்கும். மெதுவான checkout-ஐ debug செய்வது என்பது இப்போது நான்கு network hops மற்றும் மூன்று வெவ்வேறு data stores හරහා ஒரு ஒற்றைக் கோரிக்கையைத் (single request) தேடுவதாக இருக்கலாம்.
உங்கள் குழு அந்தச் சுமையைச் சுமக்கத் தயாராக இல்லை என்றால், அதற்கான தீர்வை விட நோயே சிறந்தது. சில நேரங்களில் ஒரு modular monolith-உடன் தொடங்குவதே புத்திசாலித்தனமான செயலாகும். அவை ஒன்றாக deploy செய்யப்பட்டாலும், codebase உள்ளே payment logic-ஐ inventory logic-லிருந்து தனித்துப் பிரியுங்கள். ஒரே engine உள்ளே internal APIs மற்றும் தனித்த database schemas மூலம் எல்லைகளைக் கட்டாயப்படுத்துங்கள். அந்தப் பிரிவுகள் நிலையானவை என்று நிரூபிக்கப்பட்டு, போக்குவரத்து முறைகள் (traffic patterns) அந்த கூடுதல் சுமையைத் தாங்கும் நிலையில் இருக்கும்போது, ஒரு சேவையைத் தனியாகப் பிரியுங்கள். கட்டமைப்பு (Architecture) என்பது ஒரு தொடர்ச்சியான திட்டமிட்ட கதவுகளாக இருக்க வேண்டுமே தவிர, ஒரு வலைப்பதிவைப் படித்ததால் ஒரே இரவில் கட்டப்பட்ட சுவர்களாக இருக்கக்கூடாது.
நோக்கத்துடன் தொடங்குங்கள்
வலுவான கட்டமைப்பு (Solid architecture) என்பது ஐந்து ஆண்டுகளுக்குப் பிறகு போக்குவரத்து எப்படி இருக்கும் என்று கணிப்பதைப் பற்றியது அல்ல. அது உங்களுக்குத் தேர்வுகள் (options) கிடைப்பதை உறுதி செய்வதாகும். உங்கள் web app-ஐ வளர்க்க கருவிகளை (tools) மட்டும் நீங்கள் நம்பியிருக்க முடியாது, ஆனால் அழுத்தம் அதிகரிக்கும் முன்பே சிக்கலில் இருந்து வெளியேற நீங்கள் சிந்திக்க முடியும். பொறுப்புகளுக்கு இடையிலான எல்லைகளை மதியுங்கள். தங்கள் விதியைத் தாங்களே தீர்மானிக்கும் சிறிய, கவனம் செலுத்திய பகுதிகளை உருவாக்குங்கள். முழு அமைப்பையும் உடைக்காமல் வேகமாகச் செயல்பட குழுக்களுக்குத் தன்னாட்சியை (autonomy) வழங்குங்கள். நீங்கள் ஒரு வலுவான கட்டமைப்போடு தொடங்கும் போது, பின்னர் நேரத்தையும் முயற்சியையும் மிச்சப்படுத்துவீர்கள், ஏனெனில் தளம் நெருக்கடியில் இருக்கும்போது நீங்கள் முக்கிய தர்க்கங்களை (core logic) மீண்டும் எழுத வேண்டியிருக்காது.
உண்மையான கருத்து
Scalability என்பது வளர்ச்சி வரும்போது இணைக்கப்படும் ஒரு அம்சம் அல்ல. அது உங்கள் அமைப்பில் பொறுப்புகள் எவ்வாறு பாய்கின்றன என்பது குறித்து நீங்கள் ஆரம்பத்திலேயே எடுத்த முடிவுகளின் இயற்கையான விளைவாகும். சரியான பிரிவுகளைத் தேர்ந்தெடுங்கள். தோல்வியைத் தனிமைப்படுத்துங்கள். பாதிப்பை ஏற்படுத்தும் பகுதிகளை மட்டும் அளவிடுங்கள் (scale), வேலை செய்யும் பகுதிகளை அப்படியே விட்டுவிடுங்கள். அதைச் செய்யுங்கள், அப்போது நீங்கள் பின்னர் சேர்க்கும் கருவிகள் உண்மையில் ஒரு வலுவான அடித்தளத்தின் மீது செயல்படும்.