DevOps ഉം കുഴപ്പവും: വികേന്ദ്രീകൃത ലോകത്ത് സോഫ്റ്റ്‌വെയർ ഡെലിവറി

ഇസ്രായേലിലെ ആദ്യത്തെ DevOps സർട്ടിഫിക്കേഷന്റെ തുടക്കക്കാരിലും ഇൻസ്ട്രക്ടർമാരിലൊരാളായ ഓട്ടോമാറ്റോ സോഫ്റ്റ്‌വെയറിന്റെ സ്ഥാപകനും ഡയറക്ടറുമായ ആന്റൺ വെയ്‌സ് കഴിഞ്ഞ വർഷം സംസാരിച്ചു. DevOpsDays മോസ്കോ കുഴപ്പ സിദ്ധാന്തത്തെക്കുറിച്ചും ചാവോസ് എഞ്ചിനീയറിംഗിന്റെ പ്രധാന തത്വങ്ങളെക്കുറിച്ചും, കൂടാതെ ഭാവിയിലെ അനുയോജ്യമായ DevOps ഓർഗനൈസേഷൻ എങ്ങനെ പ്രവർത്തിക്കുമെന്നും വിശദീകരിച്ചു.

റിപ്പോർട്ടിന്റെ ഒരു വാചക പതിപ്പ് ഞങ്ങൾ തയ്യാറാക്കിയിട്ടുണ്ട്.

സുപ്രഭാതം

തുടർച്ചയായി രണ്ടാം വർഷവും മോസ്കോയിൽ DevOpsDays, ഈ സ്റ്റേജിൽ ഇത് എന്റെ രണ്ടാം തവണയാണ്, നിങ്ങളിൽ പലരും ഈ മുറിയിൽ രണ്ടാം തവണയാണ്. എന്താണ് ഇതിനർത്ഥം? ഇതിനർത്ഥം റഷ്യയിലെ DevOps പ്രസ്ഥാനം വളരുകയും പെരുകുകയും ചെയ്യുന്നു, ഏറ്റവും പ്രധാനമായി, 2018 ൽ DevOps എന്താണെന്നതിനെക്കുറിച്ച് സംസാരിക്കേണ്ട സമയം അതിക്രമിച്ചിരിക്കുന്നു എന്നാണ്.

2018-ൽ DevOps ഇതിനകം ഒരു പ്രൊഫഷനാണെന്ന് കരുതുന്ന നിങ്ങളുടെ കൈകൾ ഉയർത്തണോ? അത്തരം ഉണ്ട്. "DevOps എഞ്ചിനീയർ" എന്ന് ജോലി വിവരണത്തിൽ പറയുന്ന ഏതെങ്കിലും DevOps എഞ്ചിനീയർമാർ മുറിയിലുണ്ടോ? റൂമിൽ DevOps മാനേജർമാരുണ്ടോ? അങ്ങനെയൊന്ന് ഇല്ല. DevOps ആർക്കിടെക്റ്റുകൾ? കൂടാതെ ഇല്ല. പോരാ. അവർ ഒരു DevOps എഞ്ചിനീയർ ആണെന്ന് ആരും പറയുന്നില്ല എന്നത് ശരിക്കും ശരിയാണോ?

അപ്പോൾ നിങ്ങളിൽ ഭൂരിഭാഗവും ഇത് ഒരു വിരുദ്ധ പാറ്റേണാണെന്ന് കരുതുന്നുണ്ടോ? അങ്ങനെയൊരു തൊഴിൽ ഉണ്ടാകാൻ പാടില്ലെന്നോ? നമുക്ക് എന്ത് വേണമെങ്കിലും ചിന്തിക്കാം, പക്ഷേ നമ്മൾ ചിന്തിക്കുമ്പോൾ, വ്യവസായം DevOps കാഹളത്തിന്റെ ശബ്ദത്തിലേക്ക് ഗൗരവമായി മുന്നോട്ട് പോകുന്നു.

DevDevOps എന്ന പുതിയ വിഷയത്തെക്കുറിച്ച് ആരാണ് കേട്ടിട്ടുള്ളത്? ഡെവലപ്പർമാരും ഡിവോപ്പുകളും തമ്മിലുള്ള ഫലപ്രദമായ സഹകരണം അനുവദിക്കുന്ന ഒരു പുതിയ സാങ്കേതികതയാണിത്. പിന്നെ അത്ര പുതിയതല്ല. ട്വിറ്റർ വിലയിരുത്തുമ്പോൾ, അവർ 4 വർഷം മുമ്പ് ഇതിനെക്കുറിച്ച് സംസാരിച്ചു തുടങ്ങിയിരുന്നു. ഇപ്പോൾ വരെ, ഇതിൽ താൽപ്പര്യം വളരുകയും വളരുകയും ചെയ്യുന്നു, അതായത് ഒരു പ്രശ്നമുണ്ട്. പ്രശ്നം പരിഹരിക്കേണ്ടതുണ്ട്.

ഞങ്ങൾ ക്രിയേറ്റീവ് ആളുകളാണ്, ഞങ്ങൾ വിശ്രമിക്കുന്നില്ല. ഞങ്ങൾ പറയുന്നു: DevOps വേണ്ടത്ര സമഗ്രമായ പദമല്ല; അതിന് ഇപ്പോഴും എല്ലാത്തരം വ്യത്യസ്തവും രസകരവുമായ ഘടകങ്ങളില്ല. ഞങ്ങൾ ഞങ്ങളുടെ രഹസ്യ ലബോറട്ടറികളിൽ പോയി രസകരമായ മ്യൂട്ടേഷനുകൾ നിർമ്മിക്കാൻ തുടങ്ങുന്നു: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

യുക്തി ഇരുമ്പുമൂടി, അല്ലേ? ഞങ്ങളുടെ ഡെലിവറി സിസ്റ്റം പ്രവർത്തനക്ഷമമല്ല, ഞങ്ങളുടെ സിസ്റ്റങ്ങൾ അസ്ഥിരമാണ്, ഞങ്ങളുടെ ഉപയോക്താക്കൾ അസംതൃപ്തരാണ്, കൃത്യസമയത്ത് സോഫ്‌റ്റ്‌വെയർ പുറത്തിറക്കാൻ ഞങ്ങൾക്ക് സമയമില്ല, ഞങ്ങൾ ബജറ്റുമായി പൊരുത്തപ്പെടുന്നില്ല. ഇതെല്ലാം നമ്മൾ എങ്ങനെ പരിഹരിക്കും? ഞങ്ങൾ ഒരു പുതിയ വാക്ക് കൊണ്ടുവരും! ഇത് "ഓപ്‌സ്" എന്നതിൽ അവസാനിക്കും, പ്രശ്നം പരിഹരിക്കപ്പെടും.

അതിനാൽ ഞാൻ ഈ സമീപനത്തെ വിളിക്കുന്നു - "ഓപ്‌സ്, പ്രശ്നം പരിഹരിച്ചു."

എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഇതെല്ലാം കൊണ്ടുവന്നതെന്ന് സ്വയം ഓർമ്മിപ്പിച്ചാൽ ഇതെല്ലാം പശ്ചാത്തലത്തിലേക്ക് മങ്ങുന്നു. സോഫ്റ്റ്‌വെയർ ഡെലിവറിയും ഈ പ്രക്രിയയിൽ ഞങ്ങളുടെ സ്വന്തം ജോലിയും തടസ്സമില്ലാത്തതും വേദനയില്ലാത്തതും കാര്യക്ഷമവും ഏറ്റവും പ്രധാനമായി കഴിയുന്നത്ര ആസ്വാദ്യകരവുമാക്കുന്നതിനാണ് ഞങ്ങൾ ഈ മുഴുവൻ DevOps കാര്യവും കൊണ്ടുവന്നത്.

DevOps വേദനയിൽ നിന്ന് വളർന്നു. ഞങ്ങൾ കഷ്ടപ്പാടുകളിൽ മടുത്തു. ഇതെല്ലാം സംഭവിക്കുന്നതിന്, ഞങ്ങൾ നിത്യഹരിത സമ്പ്രദായങ്ങളെ ആശ്രയിക്കുന്നു: ഫലപ്രദമായ സഹകരണം, ഫ്ലോ പ്രാക്ടീസുകൾ, ഏറ്റവും പ്രധാനമായി, സിസ്റ്റം ചിന്തകൾ, കാരണം ഇതില്ലാതെ ഒരു DevOps പ്രവർത്തിക്കില്ല.

എന്താണ് സംവിധാനം?

നമ്മൾ ഇതിനകം തന്നെ സിസ്റ്റം ചിന്തയെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, ഒരു സിസ്റ്റം എന്താണെന്ന് നമുക്ക് സ്വയം ഓർമ്മിപ്പിക്കാം.

നിങ്ങൾ ഒരു വിപ്ലവ ഹാക്കർ ആണെങ്കിൽ, നിങ്ങളെ സംബന്ധിച്ചിടത്തോളം സിസ്റ്റം വളരെ മോശമാണ്. ഇത് നിങ്ങളുടെ മേൽ തൂങ്ങിക്കിടക്കുന്ന ഒരു മേഘമാണ്, നിങ്ങൾ ചെയ്യാൻ ആഗ്രഹിക്കാത്ത കാര്യങ്ങൾ ചെയ്യാൻ നിങ്ങളെ പ്രേരിപ്പിക്കുന്നു.

സിസ്റ്റങ്ങളുടെ ചിന്തയുടെ വീക്ഷണകോണിൽ നിന്ന്, ഒരു സിസ്റ്റം എന്നത് ഭാഗങ്ങൾ ഉൾക്കൊള്ളുന്ന ഒരു മൊത്തമാണ്. ഈ അർത്ഥത്തിൽ, നമ്മൾ ഓരോരുത്തരും ഒരു സംവിധാനമാണ്. ഞങ്ങൾ പ്രവർത്തിക്കുന്ന സ്ഥാപനങ്ങൾ സംവിധാനങ്ങളാണ്. നിങ്ങളും ഞാനും നിർമ്മിക്കുന്നതിനെ സിസ്റ്റം എന്ന് വിളിക്കുന്നു.

ഇതെല്ലാം ഒരു വലിയ സാമൂഹിക-സാങ്കേതിക വ്യവസ്ഥയുടെ ഭാഗമാണ്. ഈ സാമൂഹിക-സാങ്കേതിക സംവിധാനം എങ്ങനെ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നുവെന്ന് മനസിലാക്കിയാൽ മാത്രമേ, ഈ വിഷയത്തിൽ എന്തെങ്കിലും ഒപ്റ്റിമൈസ് ചെയ്യാൻ നമുക്ക് കഴിയൂ.

ഒരു സിസ്റ്റത്തിന്റെ ചിന്താ വീക്ഷണകോണിൽ, ഒരു സിസ്റ്റത്തിന് വിവിധ രസകരമായ ഗുണങ്ങളുണ്ട്. ആദ്യം, അതിൽ ഭാഗങ്ങൾ അടങ്ങിയിരിക്കുന്നു, അതായത് അതിന്റെ സ്വഭാവം ഭാഗങ്ങളുടെ സ്വഭാവത്തെ ആശ്രയിച്ചിരിക്കുന്നു. മാത്രമല്ല, അതിന്റെ എല്ലാ ഭാഗങ്ങളും പരസ്പരാശ്രിതവുമാണ്. ഒരു സിസ്റ്റത്തിന് കൂടുതൽ ഭാഗങ്ങളുണ്ട്, അതിന്റെ സ്വഭാവം മനസ്സിലാക്കാനോ പ്രവചിക്കാനോ കൂടുതൽ ബുദ്ധിമുട്ടാണ്.

പെരുമാറ്റ കാഴ്ചപ്പാടിൽ, രസകരമായ മറ്റൊരു വസ്തുതയുണ്ട്. സിസ്റ്റത്തിന് അതിന്റെ വ്യക്തിഗത ഭാഗങ്ങൾക്കൊന്നും ചെയ്യാൻ കഴിയാത്തത് ചെയ്യാൻ കഴിയും.

ഡോ. റസ്സൽ അക്കോഫ് (സിസ്റ്റം ചിന്തയുടെ സ്ഥാപകരിൽ ഒരാൾ) പറഞ്ഞതുപോലെ, ഇത് ഒരു ചിന്താ പരീക്ഷണത്തിലൂടെ തെളിയിക്കാൻ വളരെ എളുപ്പമാണ്. ഉദാഹരണത്തിന്, മുറിയിലുള്ള ആർക്കൊക്കെ കോഡ് എഴുതണമെന്ന് അറിയാം? ധാരാളം കൈകളുണ്ട്, ഇത് സാധാരണമാണ്, കാരണം ഇത് ഞങ്ങളുടെ തൊഴിലിന്റെ പ്രധാന ആവശ്യകതകളിൽ ഒന്നാണ്. നിങ്ങൾക്ക് എങ്ങനെ എഴുതണമെന്ന് അറിയാമോ, എന്നാൽ നിങ്ങളുടെ കൈകൾക്ക് നിങ്ങളിൽ നിന്ന് പ്രത്യേകമായി കോഡ് എഴുതാൻ കഴിയുമോ? "കോഡ് എഴുതുന്നത് എന്റെ കൈകളല്ല, എന്റെ തലച്ചോറാണ് കോഡ് എഴുതുന്നത്" എന്ന് പറയുന്നവരുണ്ട്. നിങ്ങളുടെ തലച്ചോറിന് നിങ്ങളിൽ നിന്ന് പ്രത്യേകമായി കോഡ് എഴുതാൻ കഴിയുമോ? ശരി, ഒരുപക്ഷേ ഇല്ല.

മസ്തിഷ്കം ഒരു അത്ഭുതകരമായ യന്ത്രമാണ്, അത് അവിടെ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ 10% പോലും ഞങ്ങൾക്ക് അറിയില്ല, പക്ഷേ നമ്മുടെ ശരീരമായ സിസ്റ്റത്തിൽ നിന്ന് വേറിട്ട് പ്രവർത്തിക്കാൻ അതിന് കഴിയില്ല. ഇത് തെളിയിക്കാൻ എളുപ്പമാണ്: നിങ്ങളുടെ തലയോട്ടി തുറക്കുക, തലച്ചോറ് പുറത്തെടുക്കുക, കമ്പ്യൂട്ടറിന് മുന്നിൽ വയ്ക്കുക, ലളിതമായ എന്തെങ്കിലും എഴുതാൻ അവനെ അനുവദിക്കുക. ഉദാഹരണത്തിന്, പൈത്തണിലെ "ഹലോ, വേൾഡ്".

ഒരു സിസ്റ്റത്തിന് അതിന്റെ ഒരു ഭാഗത്തിനും വെവ്വേറെ ചെയ്യാൻ കഴിയാത്ത എന്തെങ്കിലും ചെയ്യാൻ കഴിയുമെങ്കിൽ, അതിന്റെ സ്വഭാവം നിർണ്ണയിക്കുന്നത് അതിന്റെ ഭാഗങ്ങളുടെ സ്വഭാവമല്ല എന്നാണ്. അപ്പോൾ അത് നിർണ്ണയിക്കുന്നത് എന്താണ്? ഈ ഭാഗങ്ങൾ തമ്മിലുള്ള ഇടപെടലാണ് ഇത് നിർണ്ണയിക്കുന്നത്. അതനുസരിച്ച്, കൂടുതൽ ഭാഗങ്ങൾ, കൂടുതൽ സങ്കീർണ്ണമായ ഇടപെടലുകൾ, സിസ്റ്റത്തിന്റെ സ്വഭാവം മനസ്സിലാക്കാനും പ്രവചിക്കാനും കൂടുതൽ ബുദ്ധിമുട്ടാണ്. ഇത് അത്തരമൊരു സിസ്റ്റത്തെ താറുമാറാക്കുന്നു, കാരണം സിസ്റ്റത്തിന്റെ ഏതെങ്കിലും ഭാഗത്തെ ഏറ്റവും നിസ്സാരമായ, അദൃശ്യമായ മാറ്റം പോലും പൂർണ്ണമായും പ്രവചനാതീതമായ ഫലങ്ങളിലേക്ക് നയിച്ചേക്കാം.

പ്രാരംഭ സാഹചര്യങ്ങളോടുള്ള ഈ സംവേദനക്ഷമത ആദ്യമായി കണ്ടെത്തുകയും പഠിക്കുകയും ചെയ്തത് അമേരിക്കൻ കാലാവസ്ഥാ നിരീക്ഷകനായ എഡ് ലോറൻസ് ആണ്. തുടർന്ന്, അതിനെ "ബട്ടർഫ്ലൈ ഇഫക്റ്റ്" എന്ന് വിളിക്കുകയും "ചോസ് തിയറി" എന്ന ശാസ്ത്രീയ ചിന്തയുടെ ഒരു പ്രസ്ഥാനത്തിന്റെ വികാസത്തിലേക്ക് നയിക്കുകയും ചെയ്തു. ഈ സിദ്ധാന്തം 20-ാം നൂറ്റാണ്ടിലെ ശാസ്ത്രത്തിലെ പ്രധാന മാതൃകാ വ്യതിയാനങ്ങളിൽ ഒന്നായി മാറി.

അരാജക സിദ്ധാന്തം

അരാജകത്വം പഠിക്കുന്ന ആളുകൾ സ്വയം ചാസോസോളജിസ്റ്റുകൾ എന്ന് വിളിക്കുന്നു.

യഥാർത്ഥത്തിൽ, ഈ റിപ്പോർട്ടിന്റെ കാരണം, സങ്കീർണ്ണമായ വിതരണ സംവിധാനങ്ങളുമായും വലിയ അന്താരാഷ്ട്ര ഓർഗനൈസേഷനുകളുമായും പ്രവർത്തിക്കുമ്പോൾ, ഒരു ഘട്ടത്തിൽ എനിക്ക് തോന്നിയത് ഇതാണ് എന്ന് ഞാൻ മനസ്സിലാക്കി. ഞാൻ ഒരു കുഴപ്പക്കാരനാണ്. ഇത് അടിസ്ഥാനപരമായി പറയാനുള്ള ഒരു സമർത്ഥമായ മാർഗമാണ്: "ഇവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് എനിക്ക് മനസ്സിലാകുന്നില്ല, അതിനെക്കുറിച്ച് എന്തുചെയ്യണമെന്ന് എനിക്കറിയില്ല."

നിങ്ങളിൽ പലർക്കും പലപ്പോഴും ഇങ്ങനെ തോന്നാറുണ്ടെന്ന് ഞാൻ കരുതുന്നു, അതിനാൽ നിങ്ങളും കുഴപ്പക്കാരാണ്. ഞാൻ നിങ്ങളെ ചാസോളജിസ്റ്റുകളുടെ സംഘത്തിലേക്ക് ക്ഷണിക്കുന്നു. നിങ്ങളും ഞാനും, പ്രിയ സഹ ചാവോളജിസ്റ്റുകൾ പഠിക്കുന്ന സംവിധാനങ്ങളെ "സങ്കീർണ്ണമായ അഡാപ്റ്റീവ് സിസ്റ്റങ്ങൾ" എന്ന് വിളിക്കുന്നു.

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

അത്തരം സംവിധാനങ്ങളുടെ മറ്റൊരു രസകരമായ സ്വത്ത് അവ സ്വതന്ത്രമായി അളക്കാവുന്നവയാണ്. കുഴപ്പശാസ്ത്രജ്ഞർ-എഞ്ചിനീയർമാർ എന്ന നിലയിൽ നമുക്ക് നിസ്സംശയമായും താൽപ്പര്യമുള്ളത് എന്താണ്. അതിനാൽ, സങ്കീർണ്ണമായ ഒരു സിസ്റ്റത്തിന്റെ സ്വഭാവം നിർണ്ണയിക്കുന്നത് അതിന്റെ ഭാഗങ്ങളുടെ പ്രതിപ്രവർത്തനമാണ് എന്ന് ഞങ്ങൾ പറഞ്ഞാൽ, നമുക്ക് എന്താണ് താൽപ്പര്യമുണ്ടാകേണ്ടത്? ഇടപെടൽ.

രസകരമായ രണ്ട് കണ്ടെത്തലുകൾ കൂടിയുണ്ട്.


ഒന്നാമതായി, ഒരു സങ്കീർണ്ണ സംവിധാനത്തെ അതിന്റെ ഭാഗങ്ങൾ ലളിതമാക്കുന്നതിലൂടെ ലളിതമാക്കാൻ കഴിയില്ലെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുന്നു. രണ്ടാമതായി, ഒരു സങ്കീർണ്ണ സംവിധാനത്തെ ലളിതമാക്കാനുള്ള ഒരേയൊരു മാർഗ്ഗം അതിന്റെ ഭാഗങ്ങൾ തമ്മിലുള്ള ഇടപെടലുകൾ ലളിതമാക്കുക എന്നതാണ്.

നമ്മൾ എങ്ങനെ ഇടപെടും? നിങ്ങളും ഞാനും എല്ലാം മനുഷ്യ സമൂഹം എന്ന ഒരു വലിയ വിവര സംവിധാനത്തിന്റെ ഭാഗമാണ്. ഞങ്ങൾ ഒരു പൊതു ഭാഷയിലൂടെ ഇടപെടുന്നു, അത് ഉണ്ടെങ്കിൽ, അത് കണ്ടെത്തുകയാണെങ്കിൽ.

എന്നാൽ ഭാഷ തന്നെ ഒരു സങ്കീർണ്ണമായ അഡാപ്റ്റീവ് സിസ്റ്റമാണ്. അതനുസരിച്ച്, കൂടുതൽ കാര്യക്ഷമമായും ലളിതമായും സംവദിക്കുന്നതിന്, ഞങ്ങൾ ഒരുതരം പ്രോട്ടോക്കോളുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്. അതായത്, നമ്മൾ തമ്മിലുള്ള വിവര കൈമാറ്റം ലളിതവും കൂടുതൽ പ്രവചിക്കാവുന്നതും കൂടുതൽ മനസ്സിലാക്കാവുന്നതുമാക്കുന്ന ചില ചിഹ്നങ്ങളുടെയും പ്രവർത്തനങ്ങളുടെയും ക്രമം.

സങ്കീർണ്ണതയിലേക്കുള്ള പ്രവണതകൾ, അഡാപ്റ്റബിലിറ്റി, വികേന്ദ്രീകരണം, അരാജകത്വം എന്നിവയിലേക്കുള്ള പ്രവണതകൾ എല്ലാത്തിലും കണ്ടെത്താനാകുമെന്ന് ഞാൻ പറയാൻ ആഗ്രഹിക്കുന്നു. ഞാനും നിങ്ങളും കെട്ടിപ്പടുക്കുന്ന സംവിധാനങ്ങളിലും ഞങ്ങൾ ഭാഗമാകുന്ന സംവിധാനങ്ങളിലും.

അടിസ്ഥാനരഹിതമാകാതിരിക്കാൻ, നമ്മൾ സൃഷ്ടിക്കുന്ന സിസ്റ്റങ്ങൾ എങ്ങനെ മാറുന്നുവെന്ന് നോക്കാം.

നിങ്ങൾ ഈ വാക്കിനായി കാത്തിരിക്കുകയായിരുന്നു, ഞാൻ മനസ്സിലാക്കുന്നു. ഞങ്ങൾ ഒരു DevOps കോൺഫറൻസിലാണ്, ഇന്ന് ഈ വാക്ക് ഏകദേശം നൂറായിരം തവണ കേൾക്കും, തുടർന്ന് ഞങ്ങൾ രാത്രിയിൽ അതിനെക്കുറിച്ച് സ്വപ്നം കാണും.

DevOps രീതികളോടുള്ള പ്രതികരണമായി ഉയർന്നുവന്ന ആദ്യത്തെ സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്ചറാണ് മൈക്രോസർവീസുകൾ, ഇത് ഞങ്ങളുടെ സിസ്റ്റങ്ങളെ കൂടുതൽ വഴക്കമുള്ളതും കൂടുതൽ സ്കെയിലബിൾ ആക്കാനും തുടർച്ചയായ ഡെലിവറി ഉറപ്പാക്കാനും രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്. അവൾ ഇത് എങ്ങനെ ചെയ്യുന്നു? സേവനങ്ങളുടെ അളവ് കുറയ്ക്കുന്നതിലൂടെ, ഈ സേവനങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്ന പ്രശ്നങ്ങളുടെ വ്യാപ്തി കുറയ്ക്കുന്നതിലൂടെ, ഡെലിവറി സമയം കുറയ്ക്കുന്നതിലൂടെ. അതായത്, ഞങ്ങൾ സിസ്റ്റത്തിന്റെ ഭാഗങ്ങൾ കുറയ്ക്കുകയും ലഘൂകരിക്കുകയും അവയുടെ എണ്ണം വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു, അതനുസരിച്ച്, ഈ ഭാഗങ്ങൾ തമ്മിലുള്ള ഇടപെടലുകളുടെ സങ്കീർണ്ണത സ്ഥിരമായി വർദ്ധിക്കുന്നു, അതായത്, നമ്മൾ പരിഹരിക്കേണ്ട പുതിയ പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നു.

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

സങ്കീർണ്ണത എവിടെയാണ്? ബുദ്ധിമുട്ട്, തീർച്ചയായും, ഇടപെടലുകളിലാണ്. ഒരു പ്രവർത്തനം സ്വന്തമായി എത്രത്തോളം ചെയ്യാൻ കഴിയും? മറ്റ് പ്രവർത്തനങ്ങളുമായി ഇത് എങ്ങനെ ഇടപെടുന്നു? സന്ദേശ ക്യൂകൾ, ഡാറ്റാബേസുകൾ, ബാലൻസറുകൾ. ഒരു പരാജയം സംഭവിക്കുമ്പോൾ ചില ഇവന്റ് എങ്ങനെ പുനർനിർമ്മിക്കാം? ധാരാളം ചോദ്യങ്ങളും കുറച്ച് ഉത്തരങ്ങളും.

മൈക്രോസർവീസുകളും സെർവർലെസ്സും ഞങ്ങൾ ഗീക്ക് ഹിപ്സ്റ്ററുകൾ ക്ലൗഡ് നേറ്റീവ് എന്ന് വിളിക്കുന്നു. ഇതെല്ലാം മേഘത്തെക്കുറിച്ചാണ്. എന്നാൽ മേഘം അതിന്റെ സ്കേലബിളിറ്റിയിൽ അന്തർലീനമായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ഒരു ഡിസ്ട്രിബ്യൂഡ് സിസ്റ്റമായി നമ്മൾ ചിന്തിക്കുന്നത് പതിവാണ്. വാസ്തവത്തിൽ, ക്ലൗഡ് ദാതാക്കളുടെ സെർവറുകൾ എവിടെയാണ് താമസിക്കുന്നത്? ഡാറ്റാ സെന്ററുകളിൽ. അതായത്, നമുക്ക് ഇവിടെ കേന്ദ്രീകൃതവും വളരെ പരിമിതവും വിതരണം ചെയ്തതുമായ ഒരു മാതൃകയുണ്ട്.

മിതമായ പ്രവചനങ്ങൾ അനുസരിച്ച് പോലും, ഇന്റർനെറ്റുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന കോടിക്കണക്കിന് ഉപകരണങ്ങൾ അടുത്ത അഞ്ച് മുതൽ പത്ത് വർഷത്തിനുള്ളിൽ നമ്മെ കാത്തിരിക്കുന്ന വലിയ വാക്കുകളല്ല ഇന്റർനെറ്റ് ഓഫ് തിംഗ്സ് എന്ന് ഇന്ന് നമ്മൾ മനസ്സിലാക്കുന്നു. ക്ലൗഡിലേക്ക് ലയിപ്പിച്ച് ക്ലൗഡിൽ നിന്ന് അപ്‌ലോഡ് ചെയ്യുന്ന ഉപയോഗപ്രദവും ഉപയോഗശൂന്യവുമായ ഡാറ്റയുടെ ഒരു വലിയ തുക.

ക്ലൗഡ് നിലനിൽക്കില്ല, അതിനാൽ നമ്മൾ എഡ്ജ് കംപ്യൂട്ടിംഗിനെ കുറിച്ച് കൂടുതൽ സംസാരിക്കുന്നു. അല്ലെങ്കിൽ "ഫോഗ് കമ്പ്യൂട്ടിംഗ്" എന്നതിന്റെ അത്ഭുതകരമായ നിർവചനവും ഞാൻ ഇഷ്ടപ്പെടുന്നു. റൊമാന്റിസിസത്തിന്റെയും നിഗൂഢതയുടെയും മിസ്റ്റിസിസത്തിൽ ഇത് മൂടപ്പെട്ടിരിക്കുന്നു.

ഫോഗ് കമ്പ്യൂട്ടിംഗ്. വെള്ളം, നീരാവി, ഐസ്, കല്ലുകൾ എന്നിവയുടെ കേന്ദ്രീകൃത കൂട്ടങ്ങളാണ് മേഘങ്ങൾ എന്നതാണ് കാര്യം. അന്തരീക്ഷത്തിൽ നമുക്ക് ചുറ്റും ചിതറിക്കിടക്കുന്ന വെള്ളത്തുള്ളികളാണ് മൂടൽമഞ്ഞ്.

മൂടൽമഞ്ഞിന്റെ മാതൃകയിൽ, ഈ തുള്ളികൾ പൂർണ്ണമായും സ്വയംഭരണാധികാരത്തോടെയോ മറ്റ് തുള്ളികളുമായി സഹകരിച്ചോ ആണ് മിക്ക ജോലികളും ചെയ്യുന്നത്. ശരിക്കും അമർത്തിയാൽ മാത്രമേ അവ മേഘത്തിലേക്ക് തിരിയുകയുള്ളൂ.

അതായത്, വീണ്ടും വികേന്ദ്രീകരണം, സ്വയംഭരണം, കൂടാതെ, ഇതെല്ലാം എവിടേക്കാണ് പോകുന്നതെന്ന് നിങ്ങളിൽ പലരും ഇതിനകം മനസ്സിലാക്കിയിട്ടുണ്ട്, കാരണം ബ്ലോക്ക്ചെയിൻ പരാമർശിക്കാതെ നിങ്ങൾക്ക് വികേന്ദ്രീകരണത്തെക്കുറിച്ച് സംസാരിക്കാൻ കഴിയില്ല.

വിശ്വസിക്കുന്നവരുണ്ട്, ഇവർ ക്രിപ്‌റ്റോകറൻസിയിൽ നിക്ഷേപിച്ചവരാണ്. എന്നെപ്പോലെ വിശ്വസിക്കുകയും ഭയപ്പെടുകയും ചെയ്യുന്നവരുണ്ട്, ഉദാഹരണത്തിന്. വിശ്വസിക്കാത്തവരുമുണ്ട്. ഇവിടെ നിങ്ങൾക്ക് വ്യത്യസ്തമായി ചികിത്സിക്കാം. സാങ്കേതികവിദ്യയുണ്ട്, ഒരു പുതിയ അജ്ഞാത കാര്യം, പ്രശ്നങ്ങളുണ്ട്. ഏതൊരു പുതിയ സാങ്കേതികവിദ്യയും പോലെ, അത് ഉത്തരം നൽകുന്നതിനേക്കാൾ കൂടുതൽ ചോദ്യങ്ങൾ ഉയർത്തുന്നു.

ബ്ലോക്ക്ചെയിനിനെ ചുറ്റിപ്പറ്റിയുള്ള ഹൈപ്പ് മനസ്സിലാക്കാവുന്നതേയുള്ളൂ. സ്വർണ്ണ തിരക്ക് മാറ്റിനിർത്തിയാൽ, സാങ്കേതികവിദ്യ തന്നെ ശോഭനമായ ഒരു ഭാവിക്കായി ശ്രദ്ധേയമായ വാഗ്ദാനങ്ങൾ നൽകുന്നു: കൂടുതൽ സ്വാതന്ത്ര്യം, കൂടുതൽ സ്വയംഭരണം, വിതരണം ചെയ്ത ആഗോള വിശ്വാസം. എന്താണ് ആഗ്രഹിക്കാത്തത്?

അതനുസരിച്ച്, ലോകമെമ്പാടുമുള്ള കൂടുതൽ കൂടുതൽ എഞ്ചിനീയർമാർ വികേന്ദ്രീകൃത ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കാൻ തുടങ്ങുന്നു. "ഓ, ബ്ലോക്ക്‌ചെയിൻ മോശമായി നടപ്പിലാക്കിയ വിതരണം ചെയ്ത ഡാറ്റാബേസ് മാത്രമാണ്" എന്ന് പറഞ്ഞുകൊണ്ട് തള്ളിക്കളയാൻ കഴിയാത്ത ഒരു ശക്തിയാണിത്. അല്ലെങ്കിൽ സന്ദേഹവാദികൾ പറയാൻ ഇഷ്ടപ്പെടുന്നതുപോലെ: "ബ്ലോക്ക്ചെയിനിനായി യഥാർത്ഥ ആപ്ലിക്കേഷനുകളൊന്നുമില്ല." ചിന്തിച്ചാൽ 150 വർഷം മുമ്പ് അവർ വൈദ്യുതിയെ കുറിച്ച് ഇതേ കാര്യം പറഞ്ഞിരുന്നു. അവർ ചില വഴികളിൽ പോലും ശരിയായിരുന്നു, കാരണം ഇന്ന് വൈദ്യുതി സാധ്യമാക്കുന്നത് 19-ാം നൂറ്റാണ്ടിൽ ഒരു തരത്തിലും സാധ്യമല്ലായിരുന്നു.

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

ചാവോസ് എഞ്ചിനീയറിംഗ്

അതിനാൽ, ഞങ്ങൾ വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്ന സിസ്റ്റം കൂടുതൽ കൂടുതൽ സങ്കീർണ്ണവും കൂടുതൽ കൂടുതൽ കുഴപ്പവും കൂടുതൽ കൂടുതൽ അനുയോജ്യവുമാണ്. മൈക്രോ സർവീസ് സിസ്റ്റങ്ങളുടെ തുടക്കക്കാരാണ് നെറ്റ്ഫ്ലിക്സ്. ഇത് ആദ്യം മനസ്സിലാക്കിയവരിൽ അവരായിരുന്നു, അവർ സിമിയൻ ആർമി എന്ന് വിളിക്കുന്ന ഒരു കൂട്ടം ഉപകരണങ്ങൾ വികസിപ്പിച്ചെടുത്തു, അവയിൽ ഏറ്റവും പ്രശസ്തമായത് ചാവോസ് മങ്കി. അറിയപ്പെടുന്നത് എന്താണെന്ന് അദ്ദേഹം നിർവചിച്ചു "അരാജകത്വ എഞ്ചിനീയറിംഗിന്റെ തത്വങ്ങൾ".

വഴിയിൽ, റിപ്പോർട്ടിൽ പ്രവർത്തിക്കുന്ന പ്രക്രിയയിൽ, ഞങ്ങൾ ഈ വാചകം റഷ്യൻ ഭാഷയിലേക്ക് വിവർത്തനം ചെയ്തു, അതിനാൽ പോകുക ലിങ്ക്, വായിക്കുക, അഭിപ്രായം പറയുക, ശകാരിക്കുക.

ചുരുക്കത്തിൽ, അരാജക എഞ്ചിനീയറിംഗിന്റെ തത്വങ്ങൾ ഇനിപ്പറയുന്നവ പറയുന്നു. സങ്കീർണ്ണമായ വിതരണ സംവിധാനങ്ങൾ അന്തർലീനമായി പ്രവചനാതീതവും അന്തർലീനമായി ബഗ്ഗിയുമാണ്. പിശകുകൾ അനിവാര്യമാണ്, അതിനർത്ഥം ഞങ്ങൾ ഈ പിശകുകൾ അംഗീകരിക്കുകയും ഈ സിസ്റ്റങ്ങളുമായി തികച്ചും വ്യത്യസ്തമായ രീതിയിൽ പ്രവർത്തിക്കുകയും വേണം.

ഈ അഡാപ്റ്റബിലിറ്റി, സ്വയം-ഓർഗനൈസേഷനുള്ള ഈ കഴിവ്, നിലനിൽപ്പിനായി ഞങ്ങളുടെ സിസ്റ്റങ്ങളെ പരീക്ഷിക്കുന്നതിന്, ഈ പിശകുകൾ ഞങ്ങളുടെ ഉൽപ്പാദന സംവിധാനങ്ങളിൽ അവതരിപ്പിക്കാൻ നമ്മൾ തന്നെ ശ്രമിക്കണം.

അത് എല്ലാം മാറ്റുന്നു. ഉൽ‌പാദനത്തിലേക്ക് ഞങ്ങൾ എങ്ങനെ സിസ്റ്റങ്ങൾ സമാരംഭിക്കുന്നു എന്നത് മാത്രമല്ല, അവ എങ്ങനെ വികസിപ്പിക്കുന്നു, എങ്ങനെ പരീക്ഷിക്കുന്നു. കോഡ് സ്ഥിരപ്പെടുത്തുന്നതിനോ മരവിപ്പിക്കുന്നതിനോ ഉള്ള ഒരു പ്രക്രിയയും ഇല്ല; നേരെമറിച്ച്, സ്ഥിരതയുള്ള അസ്ഥിരീകരണ പ്രക്രിയയുണ്ട്. ഞങ്ങൾ ഈ വ്യവസ്ഥിതിയെ കൊല്ലാനും അതിജീവിക്കുന്നത് കാണാനും ശ്രമിക്കുന്നു.

ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റം ഇന്റഗ്രേഷൻ പ്രോട്ടോക്കോളുകൾ

അതനുസരിച്ച്, ഇതിന് നമ്മുടെ സംവിധാനങ്ങൾ എങ്ങനെയെങ്കിലും മാറേണ്ടതുണ്ട്. അവ കൂടുതൽ സുസ്ഥിരമാകുന്നതിന്, അവയുടെ ഭാഗങ്ങൾ തമ്മിലുള്ള ആശയവിനിമയത്തിന് ചില പുതിയ പ്രോട്ടോക്കോളുകൾ ആവശ്യമാണ്. അതിനാൽ ഈ ഭാഗങ്ങൾ അംഗീകരിക്കാനും ഏതെങ്കിലും തരത്തിലുള്ള സ്വയം-സംഘടനയിലേക്ക് വരാനും കഴിയും. എല്ലാത്തരം പുതിയ ടൂളുകളും, പുതിയ പ്രോട്ടോക്കോളുകൾ ഉണ്ടാകുന്നു, അതിനെ ഞാൻ "വിതരണ സംവിധാനങ്ങളുടെ ഇടപെടലിനുള്ള പ്രോട്ടോക്കോളുകൾ" എന്ന് വിളിക്കുന്നു.

ഞാൻ എന്തിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്? ആദ്യം, പദ്ധതി ഓപ്പൺട്രേസിംഗ്. ഒരു പൊതു വിതരണം ചെയ്ത ട്രാക്കിംഗ് പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കാൻ ചിലർ ശ്രമിക്കുന്നു, ഇത് സങ്കീർണ്ണമായ വിതരണ സംവിധാനങ്ങൾ ഡീബഗ്ഗിംഗ് ചെയ്യുന്നതിനുള്ള തികച്ചും അനിവാര്യമായ ഉപകരണമാണ്.

കൂടുതൽ - പോളിസി ഏജന്റ് തുറക്കുക. സിസ്റ്റത്തിന് എന്ത് സംഭവിക്കുമെന്ന് നമുക്ക് പ്രവചിക്കാൻ കഴിയില്ലെന്ന് ഞങ്ങൾ പറയുന്നു, അതായത്, അതിന്റെ നിരീക്ഷണക്ഷമത, നിരീക്ഷണക്ഷമത വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്. ഓപ്പൺട്രേസിംഗ് എന്നത് ഞങ്ങളുടെ സിസ്റ്റങ്ങൾക്ക് നിരീക്ഷണക്ഷമത നൽകുന്ന ഉപകരണങ്ങളുടെ ഒരു കുടുംബത്തിന്റേതാണ്. എന്നാൽ സിസ്റ്റം നമ്മൾ പ്രതീക്ഷിക്കുന്നത് പോലെ പ്രവർത്തിക്കുന്നുണ്ടോ ഇല്ലയോ എന്ന് നിർണ്ണയിക്കാൻ നമുക്ക് നിരീക്ഷണം ആവശ്യമാണ്. പ്രതീക്ഷിക്കുന്ന പെരുമാറ്റം എങ്ങനെ നിർവചിക്കാം? ഏതെങ്കിലും തരത്തിലുള്ള നയം, ചില നിയമങ്ങൾ എന്നിവ നിർവചിക്കുന്നതിലൂടെ. ആക്‌സസ് മുതൽ റിസോഴ്‌സ് അലോക്കേഷൻ വരെയുള്ള സ്പെക്‌ട്രത്തിലുടനീളം ഈ നിയമങ്ങളുടെ കൂട്ടം നിർവചിക്കാൻ ഓപ്പൺ പോളിസി ഏജന്റ് പ്രോജക്റ്റ് പ്രവർത്തിക്കുന്നു.

ഞങ്ങൾ പറഞ്ഞതുപോലെ, ഞങ്ങളുടെ സിസ്റ്റങ്ങൾ കൂടുതലായി ഇവന്റ്-ഡ്രൈവ് ആണ്. ഇവന്റ്-ഡ്രൈവ് സിസ്റ്റങ്ങളുടെ മികച്ച ഉദാഹരണമാണ് സെർവർലെസ്സ്. സിസ്റ്റങ്ങൾക്കിടയിൽ ഇവന്റുകൾ കൈമാറുന്നതിനും അവ ട്രാക്ക് ചെയ്യുന്നതിനും, ഞങ്ങൾക്ക് ചില പൊതുവായ ഭാഷ ആവശ്യമാണ്, ഇവന്റുകളെ എങ്ങനെ സംസാരിക്കുന്നു, അവ എങ്ങനെ പരസ്പരം കൈമാറുന്നു എന്നതിന് ചില പൊതുവായ പ്രോട്ടോക്കോൾ. ഇതിനെയാണ് ഒരു പ്രോജക്ട് എന്ന് വിളിക്കുന്നത് ക്ലൗഡ് ഇവന്റുകൾ.

ഞങ്ങളുടെ സിസ്റ്റങ്ങളെ നിരന്തരം അസ്ഥിരപ്പെടുത്തുന്ന മാറ്റങ്ങളുടെ നിരന്തരമായ സ്ട്രീം സോഫ്റ്റ്വെയർ ആർട്ടിഫാക്റ്റുകളുടെ തുടർച്ചയായ പ്രവാഹമാണ്. മാറ്റങ്ങളുടെ ഈ നിരന്തരമായ ഒഴുക്ക് നിലനിർത്തുന്നതിന്, ഒരു സോഫ്‌റ്റ്‌വെയർ ആർട്ടിഫാക്‌റ്റ് എന്താണെന്നും അത് എങ്ങനെ പരീക്ഷിക്കപ്പെടുന്നു, എന്ത് സ്ഥിരീകരണം പാസായി എന്നതിനെക്കുറിച്ചും സംസാരിക്കാൻ കഴിയുന്ന ചില പൊതുവായ പ്രോട്ടോക്കോൾ ഞങ്ങൾക്ക് ആവശ്യമാണ്. ഇതിനെയാണ് ഒരു പ്രോജക്ട് എന്ന് വിളിക്കുന്നത് ഗ്രാഫിയകൾ. അതായത്, സോഫ്റ്റ്‌വെയർ ആർട്ടിഫാക്‌റ്റുകൾക്കായുള്ള ഒരു പൊതു മെറ്റാഡാറ്റ പ്രോട്ടോക്കോൾ.

അവസാനമായി, ഞങ്ങളുടെ സംവിധാനങ്ങൾ പൂർണ്ണമായും സ്വതന്ത്രവും അഡാപ്റ്റീവ്, സ്വയം-സംഘടിതവും ആയിരിക്കണമെങ്കിൽ, അവർക്ക് സ്വയം തിരിച്ചറിയാനുള്ള അവകാശം നൽകണം. പദ്ധതി വിളിച്ചു spiffe ഇതുതന്നെയാണ് അവൻ ചെയ്യുന്നത്. ക്ലൗഡ് നേറ്റീവ് കംപ്യൂട്ടിംഗ് ഫൗണ്ടേഷന്റെ കീഴിലുള്ള പദ്ധതി കൂടിയാണിത്.

ഈ പ്രോജക്‌ടുകളെല്ലാം ചെറുപ്പമാണ്, അവയ്‌ക്കെല്ലാം നമ്മുടെ സ്‌നേഹവും സാധൂകരണവും ആവശ്യമാണ്. ഇതെല്ലാം ഓപ്പൺ സോഴ്‌സ്, ഞങ്ങളുടെ ടെസ്റ്റിംഗ്, ഞങ്ങളുടെ നടപ്പിലാക്കൽ എന്നിവയാണ്. സാങ്കേതികവിദ്യ എവിടേക്കാണ് പോകുന്നതെന്ന് അവർ നമുക്ക് കാണിച്ചുതരുന്നു.

എന്നാൽ DevOps ഒരിക്കലും സാങ്കേതികവിദ്യയെക്കുറിച്ചല്ല, അത് എല്ലായ്പ്പോഴും ആളുകൾ തമ്മിലുള്ള സഹകരണത്തെക്കുറിച്ചാണ്. അതനുസരിച്ച്, നമ്മൾ വികസിപ്പിക്കുന്ന സംവിധാനങ്ങൾ മാറണമെങ്കിൽ, നമ്മൾ തന്നെ മാറണം. വാസ്തവത്തിൽ, ഞങ്ങൾ എന്തായാലും മാറുകയാണ്; ഞങ്ങൾക്ക് കൂടുതൽ തിരഞ്ഞെടുക്കാനില്ല.

ഒരു അത്ഭുതം ഉണ്ട് ഒരു പുസ്തകം ബ്രിട്ടീഷ് എഴുത്തുകാരി റേച്ചൽ ബോട്സ്മാൻ, അതിൽ മനുഷ്യചരിത്രത്തിലുടനീളം വിശ്വാസത്തിന്റെ പരിണാമത്തെക്കുറിച്ച് എഴുതുന്നു. തുടക്കത്തിൽ, പ്രാകൃത സമൂഹങ്ങളിൽ, വിശ്വാസം പ്രാദേശികമായിരുന്നു, അതായത്, ഞങ്ങൾക്ക് വ്യക്തിപരമായി അറിയാവുന്നവരെ മാത്രമേ ഞങ്ങൾ വിശ്വസിച്ചിരുന്നുള്ളൂ.

പിന്നീട് വളരെ നീണ്ട ഒരു കാലഘട്ടം ഉണ്ടായിരുന്നു - വിശ്വാസം കേന്ദ്രീകൃതമായ ഒരു ഇരുണ്ട സമയം, ഞങ്ങൾ ഒരേ പൊതു അല്ലെങ്കിൽ സംസ്ഥാന സ്ഥാപനത്തിൽ പെട്ടവരാണ് എന്ന വസ്തുതയുടെ അടിസ്ഥാനത്തിൽ നമുക്ക് അറിയാത്ത ആളുകളെ വിശ്വസിക്കാൻ തുടങ്ങിയപ്പോൾ.

നമ്മുടെ ആധുനിക ലോകത്ത് നമ്മൾ കാണുന്നത് ഇതാണ്: വിശ്വാസം കൂടുതൽ കൂടുതൽ വിതരണം ചെയ്യപ്പെടുകയും വികേന്ദ്രീകൃതമാവുകയും ചെയ്യുന്നു, കൂടാതെ അത് വിവരങ്ങളുടെ ഒഴുക്കിന്റെ സ്വാതന്ത്ര്യത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, വിവരങ്ങളുടെ ലഭ്യത.

നിങ്ങൾ അതിനെക്കുറിച്ച് ചിന്തിക്കുകയാണെങ്കിൽ, ഈ വിശ്വാസ്യത സാധ്യമാക്കുന്ന ഈ പ്രവേശനക്ഷമത തന്നെയാണ് നിങ്ങളും ഞാനും നടപ്പിലാക്കുന്നത്. ഇതിനർത്ഥം ഞങ്ങൾ സഹകരിക്കുന്ന രീതിയും അത് ചെയ്യുന്ന രീതിയും മാറണം, കാരണം പഴയ കാലത്തെ കേന്ദ്രീകൃതവും ശ്രേണിയിലുള്ളതുമായ ഐടി ഓർഗനൈസേഷനുകൾ ഇപ്പോൾ പ്രവർത്തിക്കുന്നില്ല. അവർ മരിക്കാൻ തുടങ്ങുന്നു.

DevOps ഓർഗനൈസേഷൻ അടിസ്ഥാനകാര്യങ്ങൾ

ഭാവിയിലെ അനുയോജ്യമായ DevOps ഓർഗനൈസേഷൻ എന്നത് സ്വയംഭരണാധികാരമുള്ള ടീമുകൾ ഉൾക്കൊള്ളുന്ന ഒരു വികേന്ദ്രീകൃതവും അഡാപ്റ്റീവ് സിസ്റ്റവുമാണ്, ഓരോന്നും സ്വയംഭരണാധികാരമുള്ള വ്യക്തികൾ ഉൾപ്പെടുന്നു. ഈ ടീമുകൾ ലോകമെമ്പാടും ചിതറിക്കിടക്കുന്നു, വളരെ സുതാര്യമായ ആശയവിനിമയ പ്രോട്ടോക്കോളുകൾ ഉപയോഗിച്ച്, അസിൻക്രണസ് ആശയവിനിമയം ഉപയോഗിച്ച് പരസ്പരം ഫലപ്രദമായി സഹകരിക്കുന്നു. വളരെ മനോഹരം, അല്ലേ? വളരെ മനോഹരമായ ഒരു ഭാവി.

തീർച്ചയായും, സാംസ്കാരിക മാറ്റമില്ലാതെ ഇതൊന്നും സാധ്യമല്ല. നമുക്ക് പരിവർത്തനാത്മക നേതൃത്വം, വ്യക്തിപരമായ ഉത്തരവാദിത്തം, ആന്തരിക പ്രചോദനം എന്നിവ ഉണ്ടായിരിക്കണം.

ഇതാണ് DevOps ഓർഗനൈസേഷനുകളുടെ അടിസ്ഥാനം: വിവര സുതാര്യത, അസമന്വിത ആശയവിനിമയങ്ങൾ, പരിവർത്തന നേതൃത്വം, വികേന്ദ്രീകരണം.

പൊള്ളൽ

നമ്മൾ ഭാഗവും നിർമ്മിക്കുന്ന സംവിധാനങ്ങളും കൂടുതൽ കുഴപ്പത്തിലാണ്, ഈ ചിന്തയെ നേരിടാൻ മനുഷ്യരായ നമുക്ക് ബുദ്ധിമുട്ടാണ്, നിയന്ത്രണത്തിന്റെ മിഥ്യാധാരണ ഉപേക്ഷിക്കാൻ പ്രയാസമാണ്. ഞങ്ങൾ അവരെ നിയന്ത്രിക്കുന്നത് തുടരാൻ ശ്രമിക്കുന്നു, ഇത് പലപ്പോഴും പൊള്ളലേറ്റതിലേക്ക് നയിക്കുന്നു. എന്റെ സ്വന്തം അനുഭവത്തിൽ നിന്നാണ് ഞാൻ ഇത് പറയുന്നത്, എനിക്കും പൊള്ളലേറ്റു, പ്രൊഡക്ഷനിലെ അപ്രതീക്ഷിത പരാജയങ്ങളാൽ ഞാൻ അപ്രാപ്തനായി.

സ്വാഭാവികമായി നിയന്ത്രിക്കാൻ കഴിയാത്ത എന്തെങ്കിലും നിയന്ത്രിക്കാൻ ശ്രമിക്കുമ്പോഴാണ് പൊള്ളൽ സംഭവിക്കുന്നത്. നമ്മൾ കത്തിത്തീരുമ്പോൾ, എല്ലാത്തിനും അതിന്റെ അർത്ഥം നഷ്ടപ്പെടും, കാരണം പുതിയ എന്തെങ്കിലും ചെയ്യാനുള്ള ആഗ്രഹം നഷ്ടപ്പെടും, നമ്മൾ പ്രതിരോധിക്കുകയും ഉള്ളതിനെ പ്രതിരോധിക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു.

എഞ്ചിനീയറിംഗ് തൊഴിൽ, ഞാൻ പലപ്പോഴും എന്നെത്തന്നെ ഓർമ്മിപ്പിക്കാൻ ഇഷ്ടപ്പെടുന്നതുപോലെ, ഒന്നാമതായി, ഒരു സർഗ്ഗാത്മക തൊഴിലാണ്. എന്തെങ്കിലും സൃഷ്ടിക്കാനുള്ള ആഗ്രഹം നഷ്ടപ്പെട്ടാൽ, നമ്മൾ ചാരമായി മാറുന്നു, ചാരമായി മാറുന്നു. ആളുകൾ കത്തുന്നു, മുഴുവൻ സംഘടനകളും കത്തുന്നു.

എന്റെ അഭിപ്രായത്തിൽ, അരാജകത്വത്തിന്റെ സൃഷ്ടിപരമായ ശക്തിയെ മാത്രം അംഗീകരിക്കുക, അതിന്റെ തത്വങ്ങൾക്കനുസൃതമായി സഹകരണം കെട്ടിപ്പടുക്കുക എന്നതാണ് നമ്മുടെ തൊഴിലിലെ നല്ലത് നഷ്ടപ്പെടാതിരിക്കാൻ നമ്മെ സഹായിക്കുന്നത്.

ഇതാണ് ഞാൻ നിങ്ങളോട് ആഗ്രഹിക്കുന്നത്: നിങ്ങളുടെ ജോലിയെ സ്നേഹിക്കുക, ഞങ്ങൾ ചെയ്യുന്നതിനെ സ്നേഹിക്കുക. ഈ ലോകം വിവരങ്ങളെ പോഷിപ്പിക്കുന്നു, അത് പോഷിപ്പിക്കാനുള്ള ബഹുമതി നമുക്കുണ്ട്. അതിനാൽ നമുക്ക് കുഴപ്പങ്ങൾ പഠിക്കാം, നമുക്ക് കുഴപ്പക്കാരാകാം, നമുക്ക് മൂല്യം കൊണ്ടുവരാം, പുതിയ എന്തെങ്കിലും സൃഷ്ടിക്കാം, ശരി, പ്രശ്നങ്ങൾ, ഞങ്ങൾ ഇതിനകം കണ്ടെത്തിയതുപോലെ, അനിവാര്യമാണ്, അവ പ്രത്യക്ഷപ്പെടുമ്പോൾ, ഞങ്ങൾ “ഓപ്സ്!” എന്ന് പറയും, പ്രശ്നം പരിഹരിച്ചു.

ചാവോസ് മങ്കി അല്ലാതെ മറ്റെന്താണ്?

വാസ്തവത്തിൽ, ഈ ഉപകരണങ്ങളെല്ലാം വളരെ ചെറുപ്പമാണ്. അതേ നെറ്റ്ഫ്ലിക്സ് അവർക്കായി ഉപകരണങ്ങൾ നിർമ്മിച്ചു. നിങ്ങളുടെ സ്വന്തം ഉപകരണങ്ങൾ നിർമ്മിക്കുക. മറ്റൊരാൾ ഇതിനകം നിർമ്മിച്ച മറ്റ് ഉപകരണങ്ങൾ കണ്ടെത്താൻ ശ്രമിക്കുന്നതിനുപകരം ചായോസ് എഞ്ചിനീയറിംഗിന്റെ തത്വങ്ങൾ വായിക്കുകയും ആ തത്വങ്ങൾക്കനുസരിച്ച് ജീവിക്കുകയും ചെയ്യുക.

നിങ്ങളുടെ സിസ്റ്റങ്ങൾ തകരുന്നത് എങ്ങനെയെന്ന് മനസിലാക്കാൻ ശ്രമിക്കുകയും അവ തകർക്കാൻ തുടങ്ങുകയും അവ എങ്ങനെ നിലനിൽക്കുമെന്ന് കാണുക. ഇത് ആദ്യം വരുന്നു. നിങ്ങൾക്ക് ഉപകരണങ്ങൾക്കായി തിരയാനും കഴിയും. എല്ലാത്തരം പദ്ധതികളും ഉണ്ട്.

സിസ്റ്റത്തിന്റെ ഘടകങ്ങൾ ലഘൂകരിച്ച് ലളിതവൽക്കരിക്കാൻ കഴിയില്ലെന്ന് നിങ്ങൾ പറഞ്ഞ നിമിഷം എനിക്ക് മനസ്സിലായില്ല, ഉടൻ തന്നെ മൈക്രോസർവീസുകളിലേക്ക് നീങ്ങി, അത് ഘടകങ്ങളെ തന്നെ ലളിതമാക്കിയും ഇടപെടലുകൾ സങ്കീർണ്ണമാക്കിയും സിസ്റ്റത്തെ ലളിതമാക്കുന്നു. ഇവ പ്രധാനമായും പരസ്പര വിരുദ്ധമായ രണ്ട് ഭാഗങ്ങളാണ്.

അത് ശരിയാണ്, മൈക്രോസർവീസുകൾ പൊതുവെ വളരെ വിവാദപരമായ ഒരു വിഷയമാണ്. വാസ്തവത്തിൽ, ഭാഗങ്ങൾ ലളിതമാക്കുന്നത് വഴക്കം വർദ്ധിപ്പിക്കുന്നു. മൈക്രോസർവീസുകൾ എന്താണ് നൽകുന്നത്? അവ നമുക്ക് വഴക്കവും വേഗതയും നൽകുന്നു, പക്ഷേ അവ തീർച്ചയായും നമുക്ക് ലാളിത്യം നൽകുന്നില്ല. അവ ബുദ്ധിമുട്ട് വർദ്ധിപ്പിക്കുന്നു.

അതിനാൽ, DevOps തത്ത്വചിന്തയിൽ, മൈക്രോസർവീസുകൾ അത്ര നല്ല കാര്യമല്ലേ?

ഏതൊരു നന്മയ്ക്കും വിപരീത വശമുണ്ട്. പ്രയോജനം, അത് വഴക്കം വർദ്ധിപ്പിക്കുന്നു, വേഗത്തിൽ മാറ്റങ്ങൾ വരുത്താൻ ഞങ്ങളെ അനുവദിക്കുന്നു, പക്ഷേ ഇത് സങ്കീർണ്ണതയും അതിനാൽ മുഴുവൻ സിസ്റ്റത്തിന്റെയും ദുർബലതയും വർദ്ധിപ്പിക്കുന്നു.

എന്നിരുന്നാലും, എന്താണ് കൂടുതൽ ഊന്നൽ നൽകുന്നത്: ഇടപെടൽ ലളിതമാക്കുന്നതിനോ അല്ലെങ്കിൽ ഭാഗങ്ങൾ ലളിതമാക്കുന്നതിനോ?

തീർച്ചയായും ഊന്നൽ നൽകുന്നത് ഇടപെടലുകൾ ലളിതമാക്കുന്നതിലാണ്, കാരണം ഞങ്ങൾ നിങ്ങളുമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ വീക്ഷണകോണിൽ നിന്ന് ഇത് നോക്കുകയാണെങ്കിൽ, ഒന്നാമതായി, ഇടപെടലുകൾ ലളിതമാക്കുന്നതിലാണ് ഞങ്ങൾ ശ്രദ്ധിക്കേണ്ടത്, അല്ലാതെ ജോലി ലളിതമാക്കുന്നതിലല്ല. നമ്മിൽ ഓരോരുത്തരുടെയും പ്രത്യേകം. കാരണം ജോലി ലളിതമാക്കുക എന്നതിനർത്ഥം റോബോട്ടുകളായി മാറുക എന്നാണ്. ഇവിടെ മക്ഡൊണാൾഡിൽ നിങ്ങൾക്ക് നിർദ്ദേശങ്ങൾ ഉള്ളപ്പോൾ ഇത് സാധാരണയായി പ്രവർത്തിക്കുന്നു: ഇവിടെ നിങ്ങൾ ബർഗർ ഇട്ടു, ഇവിടെ നിങ്ങൾ സോസ് ഒഴിക്കുക. ഞങ്ങളുടെ ക്രിയേറ്റീവ് വർക്കിൽ ഇതൊന്നും പ്രവർത്തിക്കില്ല.

നിങ്ങൾ പറഞ്ഞതെല്ലാം മത്സരങ്ങളില്ലാത്ത ഒരു ലോകത്താണ് ജീവിക്കുന്നത്, അവിടെയുള്ള കുഴപ്പങ്ങൾ വളരെ ദയയുള്ളതാണ്, ഈ കുഴപ്പത്തിൽ വൈരുദ്ധ്യങ്ങളൊന്നുമില്ല, ആരും ആരെയും തിന്നാനോ കൊല്ലാനോ ആഗ്രഹിക്കുന്നില്ല എന്നത് ശരിയാണോ? മത്സരവും DevOps ഉം എങ്ങനെയായിരിക്കണം?

ശരി, നമ്മൾ ഏത് തരത്തിലുള്ള മത്സരത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നത് എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ജോലിസ്ഥലത്തെ മത്സരമാണോ അതോ കമ്പനികൾ തമ്മിലുള്ള മത്സരമാണോ?

സേവനങ്ങൾ നിരവധി കമ്പനികളല്ലാത്തതിനാൽ നിലവിലുള്ള സേവനങ്ങളുടെ മത്സരത്തെക്കുറിച്ച്. ഞങ്ങൾ ഒരു പുതിയ തരം വിവര പരിതസ്ഥിതി സൃഷ്ടിക്കുകയാണ്, ഒരു പരിതസ്ഥിതിക്കും മത്സരമില്ലാതെ ജീവിക്കാൻ കഴിയില്ല. എല്ലായിടത്തും മത്സരമുണ്ട്.

അതേ Netflix, ഞങ്ങൾ അവരെ ഒരു റോൾ മോഡലായി എടുക്കുന്നു. എന്തുകൊണ്ടാണ് അവർ ഇത് കൊണ്ടുവന്നത്? കാരണം അവർക്ക് മത്സരബുദ്ധി ആവശ്യമായിരുന്നു. ഈ വഴക്കവും ചലനത്തിന്റെ വേഗതയും വളരെ മത്സരപരമായ ആവശ്യകതയാണ്; ഇത് ഞങ്ങളുടെ സിസ്റ്റങ്ങളിൽ കുഴപ്പങ്ങൾ അവതരിപ്പിക്കുന്നു. അതായത്, കുഴപ്പം എന്നത് നമ്മൾ ബോധപൂർവ്വം ആഗ്രഹിക്കുന്നതുകൊണ്ട് ചെയ്യുന്ന ഒന്നല്ല, അത് ലോകം ആവശ്യപ്പെടുന്നതിനാൽ സംഭവിക്കുന്ന ഒന്നാണ്. നമ്മൾ ഇണങ്ങിയാൽ മതി. കുഴപ്പവും, ഇത് കൃത്യമായി മത്സരത്തിന്റെ ഫലമാണ്.

ഇതിനർത്ഥം അരാജകത്വം എന്നത് ലക്ഷ്യങ്ങളുടെ അഭാവമാണോ? അതോ നമ്മൾ കാണാൻ ആഗ്രഹിക്കാത്ത ലക്ഷ്യങ്ങളോ? ഞങ്ങൾ വീട്ടിലാണ്, മറ്റുള്ളവരുടെ ലക്ഷ്യങ്ങൾ മനസ്സിലാക്കുന്നില്ല. വാസ്തവത്തിൽ, മത്സരത്തിന് കാരണം, ഞങ്ങൾക്ക് വ്യക്തമായ ലക്ഷ്യങ്ങളുണ്ട്, ഓരോ അടുത്ത നിമിഷത്തിലും നമ്മൾ എവിടെ എത്തുമെന്ന് ഞങ്ങൾക്കറിയാം. ഇത്, എന്റെ കാഴ്ചപ്പാടിൽ, DevOps-ന്റെ സത്തയാണ്.

ചോദ്യത്തിലേക്കും ഒരു നോട്ടം. നമുക്കെല്ലാവർക്കും ഒരേ ലക്ഷ്യമുണ്ടെന്ന് ഞാൻ കരുതുന്നു: അതിജീവിക്കാനും അത് ചെയ്യാനും
ഏറ്റവും വലിയ സന്തോഷം. ഏതൊരു സംഘടനയുടെയും മത്സര ലക്ഷ്യം ഒന്നുതന്നെയാണ്. അതിജീവനം പലപ്പോഴും മത്സരത്തിലൂടെയാണ് സംഭവിക്കുന്നത്, അതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഒന്നും ചെയ്യാൻ കഴിയില്ല.

ഈ വർഷത്തെ സമ്മേളനം DevOpsDays മോസ്കോ ഡിസംബർ 7 ന് ടെക്നോപോളിസിൽ നടക്കും. നവംബർ 11 വരെ റിപ്പോർട്ടുകൾക്കായുള്ള അപേക്ഷകൾ ഞങ്ങൾ സ്വീകരിക്കുന്നു. എഴുതുക നിങ്ങൾക്ക് സംസാരിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ ഞങ്ങളോട്.

പങ്കെടുക്കുന്നവർക്കുള്ള രജിസ്ട്രേഷൻ തുറന്നിരിക്കുന്നു, ടിക്കറ്റിന്റെ വില 7000 റുബിളാണ്. ഞങ്ങൾക്കൊപ്പം ചേരുക!

അവലംബം: www.habr.com