ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് വിശദീകരിക്കുന്നു: നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട 11 ആർക്കിടെക്ചർ ആശയങ്ങൾ (4K മാസ്റ്റർക്ലാസ്).

ഈ വീഡിയോയിൽ ഉൾപ്പെടുന്ന കാര്യങ്ങൾ

• - ആർക്കിടെക്ചർ വാൾ & മാസ്റ്റർ ബ്ലൂപ്രിന്റ്
• - 01. വെർട്ടിക്കൽ വേർസസ് ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ്
• - 02. ലോഡ് ബാലൻസിംഗ് ആർക്കിടെക്ചർ (L4 വേർസസ് L7 & ഹെൽത്ത് ചെക്കുകൾ)
• - 03. ഓട്ടോസ്കെയിലിംഗ് & ഇലാസ്തികത
• - 04. സെർവർലെസ് (FaaS & Firecracker MicroVMs)

വിവർത്തനം ചെയ്ത ട്രാൻസ്ക്രിപ്റ്റ്

യഥാർത്ഥ ഇംഗ്ലീഷ് ആഖ്യാനത്തിൽ നിന്ന് വിവർത്തനം ചെയ്തത്. ലഭ്യമായ ഓഡിയോയും അടിക്കുറിപ്പുകളും YouTube നിയന്ത്രിക്കുന്നു.

- ആർക്കിടെക്ചർ വാൾ & മാസ്റ്റർ ബ്ലൂപ്രിന്റ്

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

0:34 ഈ മാസ്റ്റർക്ലാസ്സിൽ, ഞങ്ങൾ മുഴുവൻ എന്റർപ്രൈസ് ബ്ലൂപ്രിന്റിലൂടെയും കടന്നുപോകും: സ്കെയിലിംഗും ലോഡ് ബാലൻസിംഗും മുതൽ സെർവർലെസ്, ഇവന്റ്-ഡ്രിവൺ ഡീകപ്ലിംഗ്, സ്റ്റോറേജ് ഹയരാർക്കികൾ, ക്ലൗഡ് നെറ്റ്‌വർക്കിംഗ് എന്നിവ വരെ. ഈ പതിനൊന്ന് ആശയങ്ങളിൽ പ്രാവീണ്യം നേടുക, നിങ്ങൾക്ക് AWS-ൽ ഏതൊരു ബാക്കെൻഡും രൂപകൽപ്പന ചെയ്യാൻ കഴിയും, GCP, അല്ലെങ്കിൽ Azure. GCP, അല്ലെങ്കിൽ Azure. ഇത് ദി ഡെയിലി ഡിഫ് ആണ്, അണ്ടർ ദ ഹുഡ്.

- 01. വെർട്ടിക്കൽ വേർസസ് ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ്

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

1:28 ഡാറ്റാബേസും അതേപടി നിലനിൽക്കുന്നു. എന്നാൽ ഇത് കഠിനമായ ഹാർഡ്‌വെയർ പരിധിയിൽ എത്തുന്നു. ലോകത്ത് ഒരു മെഷീനിലും പതിനായിരം സിപിയു കോറുകളില്ല, ഉന്നത ശ്രേണിയിലുള്ള ഇൻസ്റ്റൻസുകൾക്ക് ഉയർന്ന വില നൽകേണ്ടിവരും. ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ്, അല്ലെങ്കിൽ സ്കെയിലിംഗ് ഔട്ട്, എന്നാൽ നിങ്ങളുടെ സെർവറുകൾ ചെറുതും സാധാരണ വിലയുള്ളതുമാക്കി നിലനിർത്തുക, എന്നാൽ ഒരു റൂട്ടറിന് പിന്നിൽ നിരവധി ഇൻസ്റ്റൻസുകൾ സമാന്തരമായി പ്രവർത്തിപ്പിക്കുക എന്നതാണ്. ഒരു ഇൻസ്റ്റൻസ് തകർന്നാൽ, ശേഷിക്കുന്ന നോഡുകൾ ട്രാഫിക് ഉൾക്കൊള്ളുന്നു ഒരു തടസ്സവുമില്ലാതെ. ഹൊറിസോണ്ടൽ സ്കെയിലിംഗിന്റെ സുവർണ്ണ നിയമം

2:01 സ്റ്റേറ്റ്‌ലെസ്നെസ്സ് ആണ്: നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സെർവറുകൾക്ക് ഉപയോക്തൃ സെഷനുകൾ അപ്‌ലോഡ് ചെയ്ത ഫയലുകൾ, അല്ലെങ്കിൽ ലോക്കൽ ഡിസ്കുകളിൽ സ്റ്റേറ്റ് എന്നിവ സൂക്ഷിക്കാൻ കഴിയില്ല. സ്റ്റേറ്റ് ഒരു ബാഹ്യ ഡാറ്റാബേസിലോ കാഷെയിലോ ആയിരിക്കണം, ഏത് നോഡിനും ഏത് ഉപയോക്തൃ അഭ്യർത്ഥനയും കൈകാര്യം ചെയ്യാൻ ഇത് അനുവദിക്കുന്നു.

- 02. ലോഡ് ബാലൻസിംഗ് ആർക്കിടെക്ചർ (L4 വേർസസ് L7 & ഹെൽത്ത് ചെക്കുകൾ)

2:17 രണ്ടാമത്തെ ആശയം: ലോഡ് ബാലൻസിംഗ്. ഹൊറിസോണ്ടൽ സ്കെയിലിംഗ് കടലാസിൽ മികച്ചതായി തോന്നുന്നു, പക്ഷേ ഇത് പെട്ടെന്ന് ഒരു പ്രശ്നം സൃഷ്ടിക്കുന്നു: പതിനായിരം ഉപയോക്താക്കൾ നിങ്ങളുടെ ഡൊമെയ്ൻ നാമത്തിൽ എത്തുമ്പോൾ, ഏത് പ്രത്യേക സെർവറാണ് അവരുടെ ട്രാഫിക് സ്വീകരിക്കുന്നത്? ഒരു ലോഡ് ബാലൻസർ പബ്ലിക് ഇന്റർനെറ്റിനും നിങ്ങളുടെ പ്രൈവറ്റ് ബാക്കെൻഡ് ക്ലസ്റ്ററിനും ഇടയിൽ ഇരിക്കുന്ന ഒരു റിവേഴ്സ് പ്രോക്സി ആയി പ്രവർത്തിക്കുന്നു. ഇത് ഇൻകമിംഗ് TCP അല്ലെങ്കിൽ HTTP കണക്ഷനുകൾ സ്വീകരിച്ച് നിങ്ങളുടെ ആരോഗ്യകരമായ ഇൻസ്റ്റൻസുകളിലേക്ക് അഭ്യർത്ഥനകൾ വിതരണം ചെയ്യുന്നു.

2:47 ലോഡ് ബാലൻസറുകൾ രണ്ട് പ്രാഥമിക നെറ്റ്‌വർക്ക് ലെയറുകളിൽ പ്രവർത്തിക്കുന്നു. ലെയർ 4 നെറ്റ്‌വർക്ക് ലോഡ് ബാലൻസറുകൾ ട്രാൻസ്പോർട്ട് ലെയറിൽ പ്രവർത്തിക്കുന്നു, മൈക്രോസെക്കൻഡ് ലേറ്റൻസിയും സെക്കൻഡിൽ ദശലക്ഷക്കണക്കിന് അഭ്യർത്ഥനകളോടും കൂടി IP വിലാസവും പോർട്ടും അടിസ്ഥാനമാക്കി റോ TCP, UDP പാക്കറ്റുകൾ റൂട്ട് ചെയ്യുന്നു. ലെയർ 7 ആപ്ലിക്കേഷൻ ലോഡ് ബാലൻസറുകൾ HTTP പ്രോട്ടോക്കോൾ പരിശോധിക്കുന്നു: URL പാതകൾ, അഭ്യർത്ഥന ഹെഡറുകൾ, കുക്കികൾ, HTTP മെത്തേഡുകൾ എന്നിവ വായിക്കുന്നു. ഇത് പാത്ത്-ബേസ്ഡ് റൂട്ടിംഗ് പ്രാപ്തമാക്കുന്നു: സ്ലാഷ്-എപിഐ അഭ്യർത്ഥനകൾ നിങ്ങളുടെ ബാക്കെൻഡ് ക്ലസ്റ്ററിലേക്കും സ്ലാഷ്-സ്റ്റാറ്റിക് അഭ്യർത്ഥനകൾ ഒരു

3:25 ഒബ്ജക്റ്റ് സ്റ്റോറിലേക്കും അയയ്ക്കുന്നു. പ്രധാനമായി, ലോഡ് ബാലൻസറുകൾ ആക്ടീവ് ഹെൽത്ത് ചെക്കുകൾ നടത്തുന്നു. ഓരോ ഏതാനും സെക്കൻഡുകളിലും, ബാലൻസർ ഓരോ ഇൻസ്റ്റൻസിലെയും ഹെൽത്ത് എൻഡ്പോയിന്റിലേക്ക് ഒരു പിംഗ് അയയ്ക്കുന്നു. ഒരു ഇൻസ്റ്റൻസ് തുടർച്ചയായി മൂന്ന് അഞ്ഞൂറ് പിഴവുകൾ വരുത്തുകയോ പ്രതികരിക്കുന്നതിൽ പരാജയപ്പെടുകയോ ചെയ്താൽ, അത് പൂളിൽ നിന്ന് യാന്ത്രികമായി പുറത്താക്കപ്പെടുന്നു ഒരു അഭ്യർത്ഥനയും നഷ്ടപ്പെടാതെ.

- 03. ഓട്ടോസ്കെയിലിംഗ് & ഇലാസ്തികത

3:45 മൂന്നാമത്തെ ആശയം: ഓട്ടോസ്കെയിലിംഗ്. നിങ്ങളുടെ വെബ് ആപ്പിന് രാവിലെ മൂന്ന് മണിക്ക് രണ്ട് സെർവറുകൾ വേണമെങ്കിൽ, എന്നാൽ ഉച്ചസമയത്തെ ലോഞ്ചിനിടെ ഇരുപത് സെർവറുകൾ വേണമെങ്കിൽ, ക്ലൗഡ് കൺസോളിലെ ബട്ടണുകളിൽ സ്വമേധയാ ക്ലിക്കുചെയ്യുന്നത് ഡൗൺടൈമിലേക്കും പാപ്പരത്തത്തിലേക്കും നയിക്കുന്ന ഒരു ഉറപ്പായ വഴിയാണ്. ഓട്ടോസ്കെയിലിംഗ് ഹൊറിസോണ്ടൽ സെർവർ പൂളുകൾക്ക് ഡൈനാമിക് ഇലാസ്തികത നൽകുന്നു. ഒരു ഓട്ടോ സ്കെയിലിംഗ് ഗ്രൂപ്പ് ശരാശരി സിപിയു ഉപയോഗം, നെറ്റ്‌വർക്ക് I-O, അല്ലെങ്കിൽ ക്യൂ ബാക്ക്ലോഗ് ഡെപ്ത് പോലുള്ള പ്രകടന മെട്രിക്സ് നിരീക്ഷിക്കുന്നു. ശരാശരി സിപിയു ഒരു നിർവചിക്കപ്പെട്ട പരിധി കടക്കുമ്പോൾ — ഉദാഹരണത്തിന്,

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

- 04. സെർവർലെസ് (FaaS & Firecracker MicroVMs)

4:53 വർഷങ്ങളായി, മാർക്കറ്റിംഗ് ടീമുകൾ സെർവർലെസ്സിനെ ആകാശത്ത് പ്രവർത്തിക്കുന്ന മാജിക് കോഡായി വിപണനം ചെയ്തു. വാസ്തവത്തിൽ, സെർവർലെസ് ഇപ്പോഴും സെർവറുകൾ ഉപയോഗിക്കുന്നു — എന്നാൽ കോഡ് പ്രവർത്തിക്കാത്തപ്പോൾ നിങ്ങൾക്ക് അവ സ്വന്തമാക്കാനോ പാച്ച് ചെയ്യാനോ പണം നൽകാനോ കഴിയില്ല. AWS ലാംഡ അല്ലെങ്കിൽ Google ക്ലൗഡ് ഫംഗ്ഷനുകൾ പോലുള്ള ഫംഗ്ഷൻ-ആസ്-എ-സർവീസ് ഉപയോഗിച്ച്, നിങ്ങൾ ഒരു സ്റ്റാൻഡ്അലോൺ ഹാൻഡ്ലർ ഫംഗ്ഷൻ എഴുതുന്നു. ഒരു HTTP അഭ്യർത്ഥന, S3 ഫയൽ അപ്‌ലോഡ്, അല്ലെങ്കിൽ ഡാറ്റാബേസ് മാറ്റം സംഭവിക്കുമ്പോൾ, ക്ലൗഡ് റൺടൈം അഞ്ച് മില്ലിസെക്കൻഡിനുള്ളിൽ Firecracker പോലുള്ള

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

5:55 ഇവന്റ് പൈപ്പ്ലൈനുകൾക്കും ഇടയ്ക്കിടെയുള്ള API-കൾക്കും സെർവർലെസ്സ് തോൽപ്പിക്കാനാവാത്തതാണ്, എന്നാൽ സ്ഥിരമായ വെബ്സോക്കറ്റുകൾക്കോ മണിക്കൂറുകൾ നീണ്ട പരിശീലന റണ്ണുകൾക്കോ മോശമാണ്.

- 05. ഇവന്റ്-ഡ്രിവൺ ആർക്കിടെക്ചർ (EDA & ഡീകപ്ലിംഗ്)

6:05 അഞ്ചാമത്തെ ആശയം: ഇവന്റ്-ഡ്രിവൺ ആർക്കിടെക്ചർ, അഥവാ EDA. പരമ്പരാഗത വാസ്തുവിദ്യകളിൽ, സേവനങ്ങൾ സമന്വയിതമായി ആശയവിനിമയം നടത്തുന്നു. നിങ്ങളുടെ ചെക്ക്ഔട്ട് സേവനം പേയ്മെന്റിനെ വിളിക്കുന്നു, പേയ്മെന്റ് ഇൻവെന്ററിയെ വിളിക്കുന്നു, ഇൻവെന്ററി ഫ്രോഡിനെ വിളിക്കുന്നു, ഫ്രോഡ് ഇമെയിലിനെ വിളിക്കുന്നു. ഇത് സമന്വയിത തകർച്ചയുടെ ഒരു കാസ്കേഡ് സൃഷ്ടിക്കുന്നു. മൂന്നാം കക്ഷി ഇമെയിൽ പ്രൊവൈഡർക്ക് ഒരു നെറ്റ്‌വർക്ക് തടസ്സമുണ്ടാവുകയും പ്രതികരിക്കാൻ പത്ത് സെക്കൻഡ് എടുക്കുകയും ചെയ്താൽ, നിങ്ങളുടെ ഉപഭോക്താവിന്റെ മുഴുവൻ ചെക്ക്ഔട്ട് അഭ്യർത്ഥനയും ഒരു പിശകോടെ ടൈം ഔട്ടാകും. ഒരു ഇവന്റ്-ഡ്രിവൺ ആർക്കിടെക്ചറിൽ, സേവനങ്ങൾ പൂർണ്ണമായും വിഘടിപ്പിക്കപ്പെടുന്നു.

6:37 ഒരു ഉപഭോക്താവ് വാങ്ങൽ ക്ലിക്ക് ചെയ്യുമ്പോൾ, ചെക്ക്ഔട്ട് സേവനം താഴേക്കുള്ള സേവനങ്ങളെ വിളിക്കുന്നില്ല. അത് ഒരു കേന്ദ്രീകൃത ഇവന്റ് ബസിലേക്ക് (Amazon EventBridge അല്ലെങ്കിൽ ഒരു SNS ടോപ്പിക് പോലെ) OrderPlaced എന്ന് പേരുള്ള ഒരു ഇവന്റ് പ്രസിദ്ധീകരിക്കുന്നു. ചെക്ക്ഔട്ട് അമ്പത് മില്ലിസെക്കൻഡിനുള്ളിൽ പൂർത്തിയാക്കുന്നു. പേയ്മെന്റ്, ഇൻവെന്ററി കുറവ്, ഇമെയിൽ രസീതുകൾ എന്നിവയ്ക്കായുള്ള താഴേക്കുള്ള വർക്കറുകൾ അവരുടെ സ്വന്തം സമർപ്പിത SQS ക്യൂകളിൽ നിന്ന് സ്വതന്ത്രമായി സന്ദേശങ്ങൾ എടുക്കുന്നു. ഇമെയിൽ സേവനം ഒരു മണിക്കൂർ പ്രവർത്തനരഹിതമായാൽ, സന്ദേശങ്ങൾ സുരക്ഷിതമായി ക്യൂവിൽ സംഭരിക്കപ്പെടും, ഒരു ഓർഡറും നഷ്ടപ്പെടില്ല.

- 06. കണ്ടെയ്‌നർ ഓർക്കസ്ട്രേഷൻ (Docker & Kubernetes)

7:13 ആറാമത്തെ ആശയം: കണ്ടെയ്‌നർ ഓർക്കസ്ട്രേഷൻ. ഡോക്കർ പാക്കേജിംഗ് പരിഹരിച്ചു: അത് നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ്, സിസ്റ്റം ലൈബ്രറികൾ, കോൺഫിഗറേഷൻ, റൺടൈം എന്നിവയെ മാറ്റാൻ കഴിയാത്ത ഒരു ചിത്രമാക്കി മാറ്റുന്നു, അത് നിങ്ങളുടെ മാക്ബുക്കിലും ക്ലൗഡിലും ഒരുപോലെ പ്രവർത്തിക്കുന്നു. എന്നാൽ ഒരു കണ്ടെയ്‌നർ പാക്കേജിംഗ് എളുപ്പമാണ്. അമ്പത് ഫിസിക്കൽ വെർച്വൽ മെഷീനുകളിലായി അഞ്ഞൂറ് കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ എഞ്ചിനീയറിംഗ് തകരുന്നു. അതുകൊണ്ടാണ് Kubernetes, AWS ECS പോലുള്ള കണ്ടെയ്‌നർ ഓർക്കസ്ട്രേറ്ററുകൾ

7:41 നിലവിലുള്ളത്. ഒരു ഓർക്കസ്ട്രേറ്റർ ഒരു കൺട്രോൾ പ്ലെയ്ൻ നൽകുന്നു: ഒരു API സെർവർ, ഒരു etcd സ്റ്റേറ്റ് സ്റ്റോർ, ഒരു ബുദ്ധിമാനായ ഷെഡ്യൂളർ. നിങ്ങൾ നിങ്ങളുടെ ആവശ്യമുള്ള അവസ്ഥ പ്രഖ്യാപിക്കുന്നു: എനിക്ക് എന്റെ ഓതന്റിക്കേഷൻ സർവീസിന്റെ പത്ത് റെപ്ലിക്കകൾ വേണം, ഓരോന്നിനും രണ്ട് ജിഗാബൈറ്റ് റാം. ഷെഡ്യൂളർ ക്ലസ്റ്റർ പരിശോധിക്കുന്നു, സ്വതന്ത്ര മെമ്മറിയുള്ള നോഡുകളിൽ പോഡുകൾ സ്ഥാപിക്കുന്നു, ആന്തരിക നെറ്റ്‌വർക്കിംഗ് ക്രമീകരിക്കുന്നു, യാഥാർത്ഥ്യം തുടർച്ചയായി അനുരഞ്ജിപ്പിക്കുന്നു. ഒരു നോഡിന് ഹാർഡ്‌വെയർ തകരാർ സംഭവിച്ചാൽ, Kubernetes നഷ്ടം കണ്ടെത്തുകയും എല്ലാ സ്ഥാനഭ്രഷ്ടരായ പോഡുകളെയും ആരോഗ്യകരമായ നോഡുകളിലേക്ക്

- 07. 4 ക്ലൗഡ് സ്റ്റോറേജ് പില്ലറുകൾ (S3, EBS, DBs & Redis)

8:16 ഉടനടി പുനഃക്രമീകരിക്കുകയും ചെയ്യുന്നു. ഏഴാമത്തെ ആശയം: ക്ലൗഡ് സ്റ്റോറേജ് ഹയരാർക്കി. തുടക്കക്കാർ പലപ്പോഴും ക്ലൗഡ് സ്റ്റോറേജിനെ ഫയലുകൾ വലിച്ചെറിയുന്ന ഒരു സിംഗിൾ ബക്കറ്റായി കണക്കാക്കുന്നു. പ്രൊഡക്ഷൻ ആർക്കിടെക്ചറിൽ, സ്റ്റോറേജ് ആക്സസ് പാറ്റേണുകളെയും ലേറ്റൻസിയെയും അടിസ്ഥാനമാക്കി നാല് വ്യത്യസ്ത തൂണുകളായി തിരിച്ചിരിക്കുന്നു. ആദ്യം ഒബ്ജക്റ്റ് സ്റ്റോറേജ് ആണ്, Amazon S3 അല്ലെങ്കിൽ Google Cloud സ്റ്റോറേജ് പോലെ. നിങ്ങൾ HTTP REST API-കൾ വഴി ഫയലുകൾ ആക്സസ് ചെയ്യുന്നു, ലളിതമായ PUT, GET കോളുകൾ ഉപയോഗിച്ച്. ഇത് പ്രതിമാസം ഒരു ജിഗാബൈറ്റിന് രണ്ട് സെന്റ് നിരക്കിൽ അനന്തമായ തിരശ്ചീന ശേഷി വാഗ്ദാനം ചെയ്യുന്നു,

8:49 ഇത് വീഡിയോ, ഉപയോക്തൃ അപ്‌ലോഡുകൾ, ലോഗുകൾ, ബാക്കപ്പുകൾ എന്നിവയ്ക്ക് അനുയോജ്യമാക്കുന്നു. രണ്ടാമത്തേത് ബ്ലോക്ക് സ്റ്റോറേജ് ആണ്, Amazon EBS പോലെ. ഇവ അതിവേഗ ഇന്റർകണക്റ്റുകൾ വഴി ഒരു പ്രത്യേക വെർച്വൽ മെഷീനിൽ നേരിട്ട് മൗണ്ട് ചെയ്ത വെർച്വൽ ഹാർഡ് ഡ്രൈവുകളാണ്. അവ ext4 പോലുള്ള സ്റ്റാൻഡേർഡ് ഫയൽസിസ്റ്റങ്ങളായി ഫോർമാറ്റ് ചെയ്യുന്നു, ഡാറ്റാബേസ് എഞ്ചിനുകൾക്ക് ആവശ്യമായ വേഗതയേറിയ റാൻഡം റീഡ്, റൈറ്റ് ആക്സസ് പിന്തുണയ്ക്കുന്നു. മൂന്നാമത്തേത് മാനേജ്ഡ് ഡാറ്റാബേസുകളാണ്: RDS-ലെ PostgreSQL പോലുള്ള റിലേഷണൽ എഞ്ചിനുകൾ ACID ട്രാൻസാക്ഷനുകളും സങ്കീർണ്ണമായ ജോയിനുകളും നൽകുന്നു,

9:21 കൂറ്റൻ സ്കെയിലിൽ സിംഗിൾ-ഡിജിറ്റ് മില്ലിസെക്കൻഡ് ലേറ്റൻസി നൽകുന്ന DynamoDB പോലുള്ള NoSQL എഞ്ചിനുകൾ. കൂറ്റൻ സ്കെയിലിൽ സിംഗിൾ-ഡിജിറ്റ് മില്ലിസെക്കൻഡ് ലേറ്റൻസി നൽകുന്ന DynamoDB പോലുള്ള NoSQL എഞ്ചിനുകൾ. നാലാമത്തേത് Redis പോലുള്ള ഇൻ-മെമ്മറി കാഷെകളാണ്. റാമിൽ നിന്ന് ഡാറ്റ വായിക്കാൻ മില്ലിസെക്കൻഡിന് പകരം മൈക്രോസെക്കൻഡുകൾ എടുക്കുന്നു. കാഷെകൾ നിങ്ങളുടെ ഡാറ്റാബേസിന്റെ മുന്നിൽ ഇരിക്കുന്നു, ആവർത്തിച്ചുള്ള റീഡ് ട്രാഫിക്കിൽ നിന്ന് അതിനെ സംരക്ഷിക്കുകയും ക്ഷണികമായ ഉപയോക്തൃ സെഷൻ ടോക്കണുകൾ കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു.

- 08. ഉയർന്ന ലഭ്യത & ദ നയൻസ് (Multi-AZ Failover)

9:44 എട്ടാമത്തെ ആശയം: ഉയർന്ന ലഭ്യത, അഥവാ HA. ലഭ്യത ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: നിങ്ങളുടെ ആപ്ലിക്കേഷൻ എത്ര ശതമാനം സമയമാണ് പ്രവർത്തനക്ഷമവും ഉപയോക്താക്കൾക്ക് ലഭ്യവും? എന്റർപ്രൈസ് കരാറുകളിൽ, ലഭ്യത അളക്കുന്നത് നയൻസിൽ ആണ്. രണ്ട് നയൻസ്, അഥവാ തൊണ്ണൂറ്റൊമ്പത് ശതമാനം ലഭ്യത, ഓരോ വർഷവും മൂന്നര ദിവസത്തിൽ കൂടുതൽ ഡൗൺടൈം അനുവദിക്കുന്നു. നാല് നയൻസ് അനുവദനീയമായ ഡൗൺടൈം അമ്പത്തിരണ്ട് മിനിറ്റായി കുറയ്ക്കുന്നു, അഞ്ച് നയൻസ് ഓരോ വർഷവും ആകെ അഞ്ച് മിനിറ്റ് ഡൗൺടൈം മാത്രമേ അനുവദിക്കൂ.

10:15 ഉയർന്ന ലഭ്യത കൈവരിക്കാൻ, നിങ്ങൾ ഫault ഡൊമെയ്‌നുകളിലുടനീളമുള്ള സിംഗിൾ പോയിന്റ് ഓഫ് ഫെയിലിയറുകൾ ഒഴിവാക്കണം. ക്ലൗഡിൽ, അതിനർത്ഥം ഒന്നിലധികം അവൈലബിലിറ്റി സോണുകളിലായി വിന്യസിക്കുക എന്നതാണ്. ഒരു അവൈലബിലിറ്റി സോൺ ഒരു റാക്ക് മാത്രമല്ല: ഇത് ഒന്നോ അതിലധികമോ വ്യത്യസ്ത കിലോമീറ്ററുകൾ അകലെയുള്ള ഫിസിക്കൽ ഡാറ്റാ സെന്ററുകളാണ്, സ്വതന്ത്രമായ പവറും കൂളിംഗും ഉണ്ട്. സിൻക്രണസ് ഡാറ്റാബേസ് റെപ്ലിക്കേഷനോടുകൂടി സോൺ A-യിലും സോൺ B-യിലും ആക്ടീവ് ഇൻസ്റ്റൻസുകൾ പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ, ഒരു മിന്നലാക്രമണമോ ഫൈബർ മുറിയലോ ഒരു മുഴുവൻ ഫിസിക്കൽ ഫെസിലിറ്റിയെ തകർത്താൽ യാന്ത്രിക ഫെയിലോവറിന് കാരണമാകുന്നു.

10:50 മുപ്പത് സെക്കൻഡിനുള്ളിൽ ഒരു മനുഷ്യന്റെയും ഇടപെടലില്ലാതെ.

- 09. ഡ്യൂറബിലിറ്റി വേർസസ് അവൈലബിലിറ്റി (എന്തുകൊണ്ട് 11 നയൻസ് അപ്‌ടൈം അല്ല)

10:53 ഒൻപതാമത്തെ ആശയം: ഡ്യൂറബിലിറ്റിയും അവയ്ലബിലിറ്റിയും. ക്ലൗഡ് ആർക്കിടെക്ചർ അഭിമുഖങ്ങളിൽ ഇത് ഏറ്റവും സാധാരണമായ ആശയക്കുഴപ്പമാണ്. എഞ്ചിനീയർമാർ ഈ വാക്കുകൾ പരസ്പരം മാറ്റുവാൻ ഉപയോഗിക്കുന്നു, എന്നാൽ അവ തികച്ചും വ്യത്യസ്തമായ കാര്യങ്ങളാണ് അളക്കുന്നത്. അവയ്ലബിലിറ്റി അളക്കുന്നത് അപ്‌ടൈം ആണ്: എനിക്ക് API കോൾ ഉപയോഗിച്ച് എൻ്റെ ഡാറ്റ ഇപ്പോൾ വായിക്കാനോ എഴുതാനോ കഴിയുമോ? ഈ നിമിഷം? ഡ്യൂറബിലിറ്റി അളക്കുന്നത് സംരക്ഷണമാണ്: എൻ്റെ ഡാറ്റ പത്ത് വർഷത്തിനുള്ളിൽ സ്ഥിരമായ ബിറ്റ് റോട്ട്, കേടുപാടുകൾ, അല്ലെങ്കിൽ നാശം എന്നിവയില്ലാതെ നിലനിൽക്കുമോ?

11:24 Amazon S3 സ്റ്റാൻഡേർഡ് നോക്കുക. അതിൻ്റെ സർവീസ് ലെവൽ എഗ്രിമെന്റ് തൊണ്ണൂറ്റി ഒൻപത് ദശാംശം ഒൻപത് ശതമാനം അവയ്ലബിലിറ്റി വാഗ്ദാനം ചെയ്യുന്നു, ഇത് ഓരോ മാസവും ഏകദേശം നാൽപ്പത്തിമൂന്ന് മിനിറ്റ് ഡൗൺടൈം അനുവദിക്കുന്നു അവിടെ ഒരു API അഭ്യർത്ഥന 500 പിശക് നൽകിയേക്കാം. എന്നാൽ S3 പതിനൊന്ന് ഒൻപതുകൾ ഡ്യൂറബിലിറ്റി വാഗ്ദാനം ചെയ്യുന്നു: തൊണ്ണൂറ്റി ഒൻപത് ദശാംശം ഒൻപത് ഒൻപത് ഒൻപത് ഒൻപത് ഒൻപത് ഒൻപത് ഒൻപത് ഒൻപത് ഒൻപത് ശതമാനം. നിങ്ങൾ S3-യിൽ ഒരു കോടി ഫയലുകൾ സൂക്ഷിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഓരോ പതിനായിരം വർഷത്തിലും ഒരു ഫയൽ നഷ്ടപ്പെടുമെന്ന് സ്ഥിതിവിവരക്കണക്കനുസരിച്ച് പ്രതീക്ഷിക്കാം.

11:56 ഓരോ പതിനായിരം വർഷത്തിലും ശരാശരി ഒരു ഫയൽ. കുറഞ്ഞത് മൂന്ന് ഭൂമിശാസ്ത്രപരമായി വേർപെടുത്തിയ ഡാറ്റാ സൗകര്യങ്ങളിലുടനീളം ഇറേസർ-കോഡിംഗ് ഒബ്ജക്റ്റുകളും റെപ്ലിക്കേറ്റിംഗ് ചങ്കുകളും ഉപയോഗിച്ച് S3 ഇത് നേടുന്നു. കുറഞ്ഞത് മൂന്ന് ഭൂമിശാസ്ത്രപരമായി വേർപെടുത്തിയ ഡാറ്റാ സൗകര്യങ്ങളിലുടനീളം. ഒരു വലിയ പ്രാദേശിക നെറ്റ്‌വർക്ക് തകരാറിനിടയിൽ, S3 താൽക്കാലികമായി ലഭ്യമല്ലാതായേക്കാം, പക്ഷേ നിങ്ങളുടെ ഡാറ്റ ഒരിക്കലും നശിപ്പിക്കപ്പെടുന്നില്ല.

- 10. ഇൻഫ്രാസ്ട്രക്ചർ ആസ് കോഡ് (Terraform വേർസസ് Console Drift)

12:14 പത്താമത്തെ ആശയം: ഇൻഫ്രാസ്ട്രക്ചർ ആസ് കോഡ്, അഥവാ IaC. ക്ലൗഡ് കമ്പ്യൂട്ടിംഗിന്റെ ആദ്യകാലങ്ങളിൽ, എഞ്ചിനീയർമാർ AWS-ൽ ലോഗിൻ ചെയ്തു വെബ് മാനേജ്മെൻ്റ് കൺസോളിൽ ക്ലിക്ക് ചെയ്ത് വെർച്വൽ ഉണ്ടാക്കി മെഷീനുകൾ, സബ്‌നെറ്റുകൾ കോൺഫിഗർ ചെയ്യുക, സുരക്ഷാ ഗ്രൂപ്പുകൾ അറ്റാച്ച് ചെയ്യുക. ഈ രീതിയെ ഇൻഡസ്ട്രി ക്ലിക്ക്ഓപ്‌സ് എന്ന് വിളിക്കുന്നു, പ്രൊഡക്ഷനിൽ ഇതൊരു വലിയ ദുരന്തമാണ്. മാനുവൽ കൺസോൾ മാറ്റങ്ങൾക്ക് ഓഡിറ്റ് ട്രയൽ ഇല്ല, റോൾബാക്ക് മെക്കാനിസം ഇല്ല, ഇത് സ്റ്റേജിംഗും പ്രൊഡക്ഷൻ എൻവയോൺമെന്റുകളും തമ്മിൽ കോൺഫിഗറേഷൻ വ്യതിചലനത്തിന് കാരണമാകും. ഇൻഫ്രാസ്ട്രക്ചർ ആസ് കോഡ് ടൂളുകൾ ഉപയോഗിച്ച്

12:48 ടെറാഫോം, ഓപ്പൺടോഫു, പുലുമി, അല്ലെങ്കിൽ AWS CDK തുടങ്ങിയ ടൂളുകൾ ഉപയോഗിച്ച് നിങ്ങളുടെ മുഴുവൻ ക്ലൗഡ് ആർക്കിടെക്ചറും Git-ൽ സംഭരിച്ചിരിക്കുന്ന ഡിക്ലറേറ്റീവ് കോൺഫിഗറേഷൻ ഫയലുകളിൽ നിർവചിക്കാം. ഒരു തുറന്ന പോർട്ടിലോ ഡാറ്റാബേസ് റെപ്ലിക്കയിലോ ഉള്ള ഓരോ മാറ്റവും ഒരു പുൾ റിക്വസ്റ്റിലൂടെയും പിയർ റിവ്യൂവിലൂടെയും കടന്നുപോകുന്നു. terraform plan പ്രവർത്തിപ്പിക്കുന്നത്, എന്തെങ്കിലും ചെയ്യുന്നതിന് മുമ്പ് കൃത്യമായ API വ്യത്യാസം കാണിക്കുന്നു, നിങ്ങളുടെ പ്രൊഡക്ഷൻ സ്റ്റാക്കിന്റെ ഒരു തനിപ്പകർപ്പ് ഉണ്ടാക്കാൻ നാലാഴ്ചയ്ക്ക് പകരം നാല് മിനിറ്റ് മതി.

- 11. ക്ലൗഡ് നെറ്റ്‌വർക്കിംഗ് (VPC, സബ്‌നെറ്റുകൾ, NAT & സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ)

13:20 പതിനൊന്നാമത്തെ ആശയം: ക്ലൗഡ് നെറ്റ്‌വർക്കിംഗും വെർച്വൽ പ്രൈവറ്റ് ക്ലൗഡുകളും. നിങ്ങൾ സെർവറുകൾ ക്ലൗഡിൽ വിന്യസിക്കുമ്പോൾ, അവ പബ്ലിക് ഇൻ്റർനെറ്റിൽ തുറന്നുകിടക്കുകയില്ല. ഒരു VPC എന്ന് പേരുള്ള സോഫ്റ്റ്‌വെയർ നിർവചിക്കപ്പെട്ട ഒറ്റപ്പെട്ട അതിരുകൾക്കുള്ളിലാണ് അവ പ്രവർത്തിക്കുന്നത്. ഒരു VPC എന്ന് പേരുള്ള സോഫ്റ്റ്‌വെയർ നിർവചിക്കപ്പെട്ട ഒറ്റപ്പെട്ട അതിരുകൾക്കുള്ളിലാണ് അവ പ്രവർത്തിക്കുന്നത്. നിങ്ങളുടെ VPC-ക്കുള്ളിൽ, നിങ്ങൾ ഒരു പ്രൈവറ്റ് IP അഡ്രസ് സ്പേസ് നൽകുന്നു, ഉദാഹരണത്തിന് 10.0.0.0/16, എന്നിട്ട് അതിനെ പബ്ലിക്, പ്രൈവറ്റ് സബ്‌നെറ്റുകളായി വിഭജിക്കുന്നു. പബ്ലിക്, പ്രൈവറ്റ് സബ്‌നെറ്റുകളായി വിഭജിക്കുന്നു. ഒരു പബ്ലിക് സബ്‌നെറ്റിന് ഇൻ്റർനെറ്റ് ഗേറ്റ്‌വേയിലേക്ക് നേരിട്ടുള്ള റൂട്ടുണ്ട്.

13:51 അതിൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ലോഡ് ബാലൻസറുകൾ, NAT ഗേറ്റ്‌വേകൾ തുടങ്ങിയ പൊതുവായ ആസ്തികൾ ഉൾക്കൊള്ളുന്നു. നിങ്ങളുടെ നെറ്റ്‌വർക്കിൽ പബ്ലിക് IP വിലാസങ്ങളുള്ള ഒരേയൊരു ഭാഗമാണിത്. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സെർവറുകളും പ്രൊഡക്ഷൻ ഡാറ്റാബേസുകളും പൊതു IP-കളില്ലാതെയും ഇൻ്റർനെറ്റിൽ നിന്ന് ഇൻബൗണ്ട് റൂട്ടുകളില്ലാതെയും സ്വകാര്യ സബ്നെറ്റുകളിൽ കർശനമായി ജീവിക്കുന്നു. നിങ്ങളുടെ ബാക്കെൻഡ് സെർവറുകൾക്ക് സുരക്ഷാ അപ്‌ഡേറ്റുകൾ ഡൗൺലോഡ് ചെയ്യേണ്ടി വരുമ്പോൾ, സ്വകാര്യ സബ്നെറ്റുകളിൽ കർശനമായി ജീവിക്കുന്നു. നിങ്ങളുടെ ബാക്കെൻഡ് സെർവറുകൾക്ക് സുരക്ഷാ അപ്‌ഡേറ്റുകൾ ഡൗൺലോഡ് ചെയ്യേണ്ടി വരുമ്പോൾ, അവരുടെ ഔട്ട്ബൗണ്ട് ട്രാഫിക് പൊതു സബ്നെറ്റിലെ NAT ഗേറ്റ്‌വേയിലൂടെ റൂട്ട് ചെയ്യുന്നു. ഓരോ ഇൻസ്റ്റൻസിനും ചുറ്റും സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ ഉണ്ട്: സ്റ്റേറ്റ്ഫുൾ വെർച്വൽ ഫയർവാളുകൾ അവ ഏറ്റവും കുറഞ്ഞ പ്രിവിലേജ് തത്വം നടപ്പിലാക്കുന്നു.

- 12. ദി കംപ്ലീറ്റ് എന്റർപ്രൈസ് ബ്ലൂപ്രിന്റ് & വെർഡിക്റ്റ്

14:28 നിങ്ങളുടെ ഡാറ്റാബേസ് സുരക്ഷാ ഗ്രൂപ്പ് പോർട്ട് 5432-ൽ നിന്നുള്ള കണക്ഷനുകൾ മാത്രം നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സെർവറുകളുടെ സുരക്ഷാ ഗ്രൂപ്പിൽ നിന്ന് കർശനമായി സ്വീകരിക്കുന്നു, പുറത്ത് നിന്നുള്ള നുഴഞ്ഞുകയറ്റം ഗണിതശാസ്ത്രപരമായി അസാധ്യമാക്കുന്നു. നിങ്ങൾ സൂം ഔട്ട് ചെയ്യുമ്പോൾ, ഈ പതിനൊന്ന് പ്രിമിറ്റീവുകൾ ഒരു ഏകീകൃത സിസ്റ്റമായി ബന്ധിപ്പിക്കുന്നു. നിങ്ങളുടെ DNS ഒരു പബ്ലിക് സബ്‌നെറ്റിലെ ലോഡ് ബാലൻസറിലേക്ക് റൂട്ട് ചെയ്യുന്നു, ഓട്ടോസ്കേലിംഗ് ഗ്രൂപ്പുകൾ ഒന്നിലധികം അവയ്ലബിലിറ്റി സോണുകളിലുടനീളം ട്രാഫിക് വർദ്ധനവ് കൈകാര്യം ചെയ്യുന്നു, ഇവന്റ് ബസുകൾ ബാക്കെൻഡ് വർക്കറുകളെ വേർപെടുത്തുന്നു, നിങ്ങളുടെ മുഴുവൻ സ്റ്റാക്കും ഇൻഫ്രാസ്ട്രക്ചർ ആസ് കോഡ് ഉപയോഗിച്ച് Git-ൽ നിന്ന് വിന്യസിക്കപ്പെടുന്നു.

15:02 ഇന്നത്തെ മാസ്റ്റർക്ലാസ് വിധി: SHIP IT. നൂറുകണക്കിന് ക്ലൗഡ് മാർക്കറ്റിംഗ് ചുരുക്കപ്പേരുകൾ മനഃപാഠമാക്കുന്നത് നിർത്തുക. ഈ പതിനൊന്ന് ആർക്കിടെക്ചർ പാറ്റേണുകളിൽ വൈദഗ്ദ്ധ്യം നേടുക, നിങ്ങളുടെ സ്റ്റേറ്റ് വേർപെടുത്തുക, പരാജയപ്പെടാത്ത സിസ്റ്റങ്ങൾ നിർമ്മിക്കുക. നിങ്ങൾ ആദ്യമായി നിർമ്മാണം തുടങ്ങിയപ്പോൾ ഏത് ക്ലൗഡ് ആശയമാണ് നിങ്ങൾക്ക് ഏറ്റവും വലിയ തലവേദന നൽകിയതെന്ന് കമൻ്റുകളിൽ പറയുക. കൂടാതെ പൂർണ്ണമായ ആർക്കിടെക്ചർ ചീറ്റ് ഷീറ്റ് ലഭിക്കാൻ, thedailydiff.dev-ലെ വാർത്താക്കുറിപ്പ് സബ്സ്ക്രൈബ് ചെയ്യുക,

15:28 ലിങ്ക് താഴെ. ഇന്നത്തെ വ്യത്യാസം അതാണ്. ഞാൻ ആക്സിസിയിൽ നിന്നുള്ള നിക്കോ ആണ്. ഉത്തരവാദിത്തത്തോടെ ലയിപ്പിക്കുക.

ഉറവിടങ്ങൾ

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io