வணக்கம், ஹப்ர்! உங்கள் கவனத்திற்கு முன்வைக்கிறேன் கட்டுரையின் ஆசிரியரின் மொழிபெயர்ப்பு .
ஐடி உலகம் படிப்படியாக மைக்ரோ சர்வீஸ்கள் மற்றும் குபெர்னெட்ஸ் போன்ற கருவிகளை நோக்கி நகர்ந்து கொண்டிருக்கும் நேரத்தில், ஒரே ஒரு பிரச்சனை மட்டும் அதிகமாக கவனிக்கப்படுகிறது. இந்த பிரச்சனை - மைக்ரோ சர்வீஸ் பதிப்புகள். இருப்பினும், தற்போதைய நிலைமை அதை விட சிறப்பாக இருப்பதாக ஐடி சமூகம் நம்புகிறது முந்தைய தலைமுறை தொழில்நுட்பம். இருப்பினும், மைக்ரோ சர்வீஸ்களை பதிப்பிப்பது மிகவும் சிக்கலான பிரச்சனை. போன்ற கட்டுரைகள் இதற்கு ஒரு சான்று .
இந்த உரையைப் படித்து உங்களுக்கு இன்னும் சிக்கல் புரியவில்லை என்றால், நான் விளக்குகிறேன். உங்கள் தயாரிப்பு 10 மைக்ரோ சர்வீஸ்களைக் கொண்டுள்ளது என்று வைத்துக்கொள்வோம். இப்போது இந்த மைக்ரோ சர்வீஸ்கள் ஒவ்வொன்றிற்கும் 1 புதிய பதிப்பு வெளியிடப்பட்டது என்று வைத்துக் கொள்வோம். 1 பதிப்பு மட்டுமே - இது மிகவும் அற்பமான மற்றும் முக்கியமற்ற உண்மை என்பதை நாம் அனைவரும் ஏற்றுக்கொள்ள முடியும் என்று நம்புகிறேன். எவ்வாறாயினும், இப்போது எங்கள் தயாரிப்பைப் பற்றி இன்னொரு முறை பார்க்கலாம். ஒவ்வொரு கூறுகளின் ஒரு புதிய பதிப்புடன், இப்போது எங்களிடம் 2^10 - அல்லது 1024 வரிசைமாற்றங்கள் உள்ளன.
இன்னும் ஏதேனும் தவறான புரிதல் இருந்தால், கணிதத்தை உடைக்கிறேன். எனவே எங்களிடம் 10 மைக்ரோ சர்வீஸ்கள் உள்ளன, ஒவ்வொன்றும் ஒரு புதுப்பிப்பைப் பெறுகின்றன. அதாவது, ஒவ்வொரு மைக்ரோ சர்வீஸுக்கும் 2 சாத்தியமான பதிப்புகளைப் பெறுகிறோம் (பழைய அல்லது புதியது). இப்போது, ஒவ்வொரு தயாரிப்பு கூறுகளுக்கும், இந்த இரண்டு பதிப்புகளில் ஒன்றை நாம் பயன்படுத்தலாம். கணித ரீதியாக, 10 இலக்கங்களின் பைனரி எண்ணைக் கொண்டிருப்பது போன்றது. எடுத்துக்காட்டாக, 1 என்பது புதிய பதிப்பு என்றும், 0 என்பது பழைய பதிப்பு என்றும் வைத்துக் கொள்வோம் - பின்னர் ஒரு சாத்தியமான வரிசைமாற்றத்தை 1001000000 எனக் குறிப்பிடலாம் - இதில் 1வது மற்றும் 4வது கூறுகள் புதுப்பிக்கப்படுகின்றன, மற்றவை அனைத்தும் இல்லை. 10-இலக்க பைனரி எண் 2^10 அல்லது 1024 மதிப்புகளைக் கொண்டிருக்கலாம் என்பதை கணிதத்திலிருந்து நாம் அறிவோம். அதாவது, நாங்கள் கையாளும் எண்ணின் அளவை உறுதிப்படுத்தியுள்ளோம்.
நமது நியாயத்தை மேலும் தொடர்வோம் - நம்மிடம் 100 மைக்ரோ சர்வீஸ்கள் இருந்தால், ஒவ்வொன்றும் 10 சாத்தியமான பதிப்புகளைக் கொண்டிருந்தால் என்ன நடக்கும்? முழு சூழ்நிலையும் மிகவும் விரும்பத்தகாததாகிறது - இப்போது எங்களிடம் 10^100 வரிசைமாற்றங்கள் உள்ளன - இது ஒரு பெரிய எண். இருப்பினும், இந்த சூழ்நிலையை இந்த வழியில் லேபிளிட விரும்புகிறேன், ஏனென்றால் இப்போது நாம் "குபெர்னெட்ஸ்" போன்ற வார்த்தைகளுக்குப் பின்னால் ஒளிந்து கொள்ளவில்லை, மாறாக பிரச்சனையை அப்படியே எதிர்கொள்கிறோம்.
இந்த பிரச்சனையில் நான் ஏன் மிகவும் ஈர்க்கப்பட்டேன்? ஒரு காரணம், முன்பு NLP மற்றும் AI உலகில் பணியாற்றியதால், நாங்கள் 5-6 ஆண்டுகளுக்கு முன்பு காம்பினேடோரியல் வெடிப்பின் சிக்கலைப் பற்றி நிறைய விவாதித்தோம். பதிப்புகளுக்குப் பதிலாக எங்களிடம் தனிப்பட்ட சொற்கள் இருந்தன, தயாரிப்புகளுக்குப் பதிலாக வாக்கியங்கள் மற்றும் பத்திகள் இருந்தன. NLP மற்றும் AI இன் சிக்கல்கள் பெரும்பாலும் தீர்க்கப்படாமல் இருந்தாலும், கடந்த சில ஆண்டுகளில் குறிப்பிடத்தக்க முன்னேற்றம் ஏற்பட்டுள்ளது என்பதை ஒப்புக் கொள்ள வேண்டும். (என் கருத்துப்படி, முன்னேற்றம் அடைய முடியும்оதொழில்துறையில் உள்ளவர்கள் இயந்திரக் கற்றலில் கொஞ்சம் குறைவாகவும் மற்ற நுட்பங்களில் இன்னும் கொஞ்சம் கவனம் செலுத்தினால் நன்றாக இருக்கும் - ஆனால் இது ஏற்கனவே தலைப்புக்கு அப்பாற்பட்டது).
DevOps மற்றும் microservices உலகிற்கு திரும்புவோம். குன்ஸ்ட்கமேராவில் யானை வேடமிட்டு, ஒரு பெரிய சிக்கலை எதிர்கொள்கிறோம் - ஏனென்றால் நான் அடிக்கடி கேட்பது "குபர்னெட்ஸை எடுத்துக் கொள்ளுங்கள், எல்லாம் சரியாகிவிடும்!" ஆனால் இல்லை, எல்லாவற்றையும் அப்படியே விட்டால் எல்லாம் சரியாகாது. மேலும், இந்த சிக்கலுக்கான பகுப்பாய்வு தீர்வு அதன் சிக்கலான தன்மை காரணமாக ஏற்றுக்கொள்ளத்தக்கதாகத் தெரியவில்லை. NLP இல் உள்ளதைப் போலவே, இந்தச் சிக்கலை நாம் முதலில் தேடல் நோக்கத்தைக் குறைப்பதன் மூலம் அணுக வேண்டும் - இந்த விஷயத்தில், காலாவதியான வரிசைமாற்றங்களை நீக்குவதன் மூலம்.
உதவக்கூடிய விஷயங்களில் ஒன்று நான் கடந்த ஆண்டு எழுதியது . நன்கு வடிவமைக்கப்பட்ட CI/CD செயல்முறை மாறுபாட்டைக் குறைக்க பெரிதும் உதவுகிறது என்பதையும் கவனத்தில் கொள்ள வேண்டும். இருப்பினும், CI/CD உடனான தற்போதைய நிலை, கணக்கியல் மற்றும் கண்காணிப்பு கூறுகளுக்கான கூடுதல் கருவிகள் இல்லாமல் வரிசைமாற்றங்களின் சிக்கலைத் தீர்க்க போதுமானதாக இல்லை.
நமக்குத் தேவையானது ஒருங்கிணைப்பு கட்டத்தில் ஒரு சோதனை முறை, அங்கு ஒவ்வொரு கூறுக்கும் ஆபத்து காரணியை நாம் தீர்மானிக்க முடியும், மேலும் பல்வேறு கூறுகளைப் புதுப்பிப்பதற்கும் ஆபரேட்டர் தலையீடு இல்லாமல் சோதனை செய்வதற்கும் ஒரு தானியங்கு செயல்முறை உள்ளது - எது வேலை செய்கிறது மற்றும் எது செய்யாது என்பதைப் பார்க்க.
அத்தகைய சோதனை அமைப்பு இப்படி இருக்கலாம்:
- டெவலப்பர்கள் சோதனைகளை எழுதுகிறார்கள் (இது ஒரு முக்கியமான கட்டம் - இல்லையெனில் எங்களிடம் மதிப்பீட்டு அளவுகோல் இல்லை - இது இயந்திர கற்றலில் தரவை லேபிளிடுவது போன்றது).
- ஒவ்வொரு கூறுகளும் (திட்டம்) அதன் சொந்த CI அமைப்பைப் பெறுகின்றன - இந்த செயல்முறை இப்போது நன்கு வளர்ச்சியடைந்துள்ளது, மேலும் ஒரு கூறுக்கான CI அமைப்பை உருவாக்கும் சிக்கல் பெரும்பாலும் தீர்க்கப்பட்டுள்ளது.
- "ஸ்மார்ட் ஒருங்கிணைப்பு அமைப்பு" பல்வேறு CI அமைப்புகளின் முடிவுகளைச் சேகரித்து, இறுதித் தயாரிப்பில் கூறு திட்டங்களைச் சேகரித்து, சோதனையை இயக்குகிறது மற்றும் இறுதியாக இருக்கும் கூறுகள் மற்றும் ஆபத்து காரணிகளின் அடிப்படையில் விரும்பிய தயாரிப்பு செயல்பாட்டைப் பெறுவதற்கான குறுகிய பாதையைக் கணக்கிடுகிறது. புதுப்பிப்பு சாத்தியமில்லை என்றால், இந்த அமைப்பு டெவலப்பர்களுக்கு ஏற்கனவே உள்ள கூறுகள் மற்றும் அவற்றில் எது பிழையை ஏற்படுத்துகிறது என்பதைப் பற்றி தெரிவிக்கிறது. மீண்டும் ஒருமுறை, சோதனை முறைமை இங்கு முக்கியமானதாகும் - ஒருங்கிணைப்பு அமைப்பு சோதனைகளை ஒரு மதிப்பீட்டு அளவுகோலாகப் பயன்படுத்துவதால்.
- சிடி சிஸ்டம், பின்னர் ஸ்மார்ட் இன்டக்ரேஷன் சிஸ்டத்திலிருந்து தரவைப் பெற்று நேரடியாக புதுப்பிப்பைச் செய்கிறது. இந்த நிலை சுழற்சியை முடிக்கிறது.
சுருக்கமாகச் சொல்வதென்றால், ஒரு தயாரிப்பில் பல்வேறு கூறுகளை இணைத்து, ஒட்டுமொத்தமாக தயாரிப்பு எவ்வாறு ஒன்றாக இணைக்கப்பட்டுள்ளது என்பதைக் கண்காணிக்க உங்களை அனுமதிக்கும் "ஸ்மார்ட் ஒருங்கிணைப்பு அமைப்பு" இல்லாதது எனக்கு இப்போது மிகப்பெரிய பிரச்சனைகளில் ஒன்றாகும். இதைப் பற்றிய சமூகத்தின் எண்ணங்களில் நான் ஆர்வமாக இருப்பேன் (ஸ்பாய்லர் - நான் தற்போது ஒரு திட்டப்பணியில் இருக்கிறேன் , இது ஒரு ஸ்மார்ட் ஒருங்கிணைப்பு அமைப்பாக மாறும்).
கடைசியாக நான் குறிப்பிட விரும்புவது என்னவென்றால், நடுத்தர அளவிலான எந்தவொரு திட்டத்திற்கும் ஒரு ஒற்றைக்கல் ஏற்றுக்கொள்ளப்படாது. என்னைப் பொறுத்தவரை, ஒரு ஒற்றைப்பாதைக்குத் திரும்புவதன் மூலம் செயல்படுத்தும் நேரத்தையும் வளர்ச்சியின் தரத்தையும் விரைவுபடுத்தும் முயற்சிகள் பெரும் சந்தேகத்தை ஏற்படுத்துகின்றன. முதலாவதாக, ஒரு மோனோலித் கூறுகளை நிர்வகிப்பதில் இதேபோன்ற சிக்கலைக் கொண்டுள்ளது - இது கொண்டிருக்கும் பல்வேறு நூலகங்களில், இருப்பினும், இவை அனைத்தும் அவ்வளவு கவனிக்கத்தக்கவை அல்ல மற்றும் முதன்மையாக டெவலப்பர்கள் செலவழித்த நேரத்தில் வெளிப்படுகின்றன. மோனோலித் சிக்கலின் விளைவு, குறியீட்டில் மாற்றங்களைச் செய்வதற்கான மெய்நிகர் இயலாமை - மற்றும் மிகவும் மெதுவான வளர்ச்சி வேகம்.
மைக்ரோ சர்வீஸ்கள் நிலைமையை மேம்படுத்துகின்றன, ஆனால் மைக்ரோ சர்வீஸ் கட்டிடக்கலை ஒருங்கிணைப்பு கட்டத்தில் ஒருங்கிணைந்த வெடிப்பின் சிக்கலை எதிர்கொள்கிறது. ஆம், பொதுவாக, அதே பிரச்சனையை வளர்ச்சி நிலையிலிருந்து ஒருங்கிணைப்பு நிலைக்கு நகர்த்தியுள்ளோம். இருப்பினும், என் கருத்துப்படி, மைக்ரோ சர்வீஸ் அணுகுமுறை இன்னும் சிறந்த முடிவுகளுக்கு வழிவகுக்கிறது, மேலும் குழுக்கள் விரைவாக முடிவுகளை அடைகின்றன (அநேகமாக முக்கியமாக மேம்பாட்டு அலகு அளவு குறைவதால் - அல்லது தொகுதி அளவு) இருப்பினும், மோனோலித்தில் இருந்து மைக்ரோ சர்வீஸுக்கு நகர்வது இன்னும் செயல்முறையை போதுமான அளவு மேம்படுத்தவில்லை - மைக்ரோ சர்வீஸ் பதிப்புகளின் ஒருங்கிணைந்த வெடிப்பு ஒரு பெரிய பிரச்சனையாகும், மேலும் நாங்கள் அதைத் தீர்க்கும்போது நிலைமையை மேம்படுத்துவதற்கு நிறைய சாத்தியங்கள் உள்ளன.
ஆதாரம்: www.habr.com