ਕਲਾਊਡ ਕੰਪਿਊਟਿੰਗ ਬਾਰੇ ਵਿਆਖਿਆ: 11 ਆਰਕੀਟੈਕਚਰ ਧਾਰਨਾਵਾਂ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ (4K ਮਾਸਟਰਕਲਾਸ)।

ਇਹ ਵੀਡੀਓ ਕੀ ਕਵਰ ਕਰਦਾ ਹੈ

• - ਆਰਕੀਟੈਕਚਰ ਵਾਲ ਅਤੇ ਮਾਸਟਰ ਬਲੂਪ੍ਰਿੰਟ
• - 01. ਵਰਟੀਕਲ ਬਨਾਮ ਹਰੀਜ਼ੋਂਟਲ ਸਕੇਲਿੰਗ
• - 02. ਲੋਡ ਬੈਲੈਂਸਿੰਗ ਆਰਕੀਟੈਕਚਰ (L4 ਬਨਾਮ L7 ਅਤੇ ਹੈਲਥ ਚੈੱਕ)
• - 03. ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਲਚਕੀਲਾਪਨ
• - 04. ਸਰਵਰ ਰਹਿਤ (FaaS ਅਤੇ ਫਾਇਰਕ੍ਰੈਕਰ ਮਾਈਕ੍ਰੋਵੀਐਮ)

ਅਨੁਵਾਦਿਤ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ

ਮੂਲ ਅੰਗਰੇਜ਼ੀ ਬਿਰਤਾਂਤ ਤੋਂ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ। ਉਪਲਬਧ ਆਡੀਓ ਅਤੇ ਕੈਪਸ਼ਨ YouTube ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

- ਆਰਕੀਟੈਕਚਰ ਵਾਲ ਅਤੇ ਮਾਸਟਰ ਬਲੂਪ੍ਰਿੰਟ

0:00 ਹਰ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਅੰਤ ਵਿੱਚ ਕਲਾਊਡ ਆਰਕੀਟੈਕਚਰ ਦੀ ਕੰਧ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਲੈਪਟਾਪ 'ਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਂਦੇ ਹੋ, ਇਸਨੂੰ ਉਤਪਾਦਨ 'ਤੇ ਧੱਕਦੇ ਹੋ, ਅਤੇ ਜਿਸ ਪਲ ਅਸਲ ਉਪਭੋਗਤਾ ਆਉਂਦੇ ਹਨ, ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡਾ AWS ਬਿੱਲ ਇੱਕ ਫੋਨ ਨੰਬਰ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ ਤਿੰਨ ਸੌ ਵੱਖ-ਵੱਖ AWS ਉਤਪਾਦ ਸੰਖੇਪ ਰੂਪਾਂ ਨੂੰ ਯਾਦ ਕਰਕੇ ਕਲਾਊਡ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਪਰ ਅਸਲ ਕਲਾਊਡ ਕੰਪਿਊਟਿੰਗ ਵਿਕਰੇਤਾ ਕੈਟਾਲਾਗਾਂ ਨੂੰ ਯਾਦ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ: ਇਹ ਗਿਆਰਾਂ ਬੁਨਿਆਦੀ ਆਰਕੀਟੈਕਚਰਲ ਪ੍ਰਾਈਮਿਟਿਵਜ਼ 'ਤੇ ਬਣੀ ਹੈ।

0:34 ਇਸ ਮਾਸਟਰਕਲਾਸ ਵਿੱਚ, ਅਸੀਂ ਪੂਰੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬਲੂਪ੍ਰਿੰਟ ਵਿੱਚੋਂ ਲੰਘਾਂਗੇ: ਸਕੇਲਿੰਗ ਅਤੇ ਲੋਡ ਬੈਲੈਂਸਿੰਗ ਤੋਂ ਲੈ ਕੇ ਸਰਵਰ ਰਹਿਤ, ਇਵੈਂਟ-ਡ੍ਰਾਈਵਨ ਡੀਕਪਲਿੰਗ, ਸਟੋਰੇਜ ਲੜੀ, ਅਤੇ ਕਲਾਊਡ ਨੈੱਟਵਰਕਿੰਗ ਤੱਕ। ਇਹਨਾਂ ਗਿਆਰਾਂ ਧਾਰਨਾਵਾਂ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ AWS, GCP, ਜਾਂ Azure 'ਤੇ ਕੋਈ ਵੀ ਬੈਕਐਂਡ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਪਰਦੇ ਦੇ ਪਿੱਛੇ The Daily Diff ਹੈ।

- 01. ਵਰਟੀਕਲ ਬਨਾਮ ਹਰੀਜ਼ੋਂਟਲ ਸਕੇਲਿੰਗ

0:57 ਧਾਰਨਾ ਨੰਬਰ ਇੱਕ: ਸਕੇਲਿੰਗ। ਜਦੋਂ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਵਾਧੇ ਦਾ ਅਨੁਭਵ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਲੋਡ ਨੂੰ ਸੰਭਾਲਣ ਦੇ ਦੋ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਤਰੀਕੇ ਹਨ: ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ, ਜਾਂ ਹਰੀਜ਼ੋਂਟਲ ਸਕੇਲਿੰਗ। ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ, ਜਾਂ ਸਕੇਲਿੰਗ ਅੱਪ, ਦਾ ਮਤਲਬ ਹੈ ਆਪਣੀ ਮੌਜੂਦਾ ਮਸ਼ੀਨ ਲੈਣਾ ਅਤੇ ਹੋਰ ਸਰੋਤ ਜੋੜਨਾ: ਚਾਰ CPU ਕੋਰ ਤੋਂ ਬੱਤੀ ਤੱਕ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ, ਜਾਂ ਬੱਤੀ ਗੀਗਾਬਾਈਟ ਰੈਮ ਨੂੰ ਇੱਕ ਸੌ ਅਠਾਈ ਨਾਲ ਬਦਲਣਾ। ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਲਈ ਜ਼ੀਰੋ ਆਰਕੀਟੈਕਚਰਲ ਬਦਲਾਅ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਤੁਹਾਡਾ ਕੋਡ ਅਤੇ ਡੇਟਾਬੇਸ ਬਿਲਕੁਲ ਉਹੀ ਰਹਿੰਦੇ ਹਨ।

1:28 ਪਰ ਇਹ ਇੱਕ ਬੇਰਹਿਮ ਹਾਰਡਵੇਅਰ ਸੀਲਿੰਗ ਨੂੰ ਮਾਰਦਾ ਹੈ। ਦੁਨੀਆ ਵਿੱਚ ਕੋਈ ਵੀ ਇੱਕ ਮਸ਼ੀਨ ਦਸ ਹਜ਼ਾਰ CPU ਕੋਰ ਨਹੀਂ ਰੱਖਦੀ, ਅਤੇ ਚੋਟੀ ਦੇ ਪੱਧਰ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਇੱਕ ਘਾਤਕ ਕੀਮਤ ਪ੍ਰੀਮੀਅਮ ਹੁੰਦਾ ਹੈ। ਹਰੀਜ਼ੋਂਟਲ ਸਕੇਲਿੰਗ, ਜਾਂ ਸਕੇਲਿੰਗ ਆਊਟ, ਦਾ ਮਤਲਬ ਹੈ ਤੁਹਾਡੇ ਸਰਵਰਾਂ ਨੂੰ ਛੋਟੇ ਅਤੇ ਸਧਾਰਨ ਕੀਮਤ ਵਾਲੇ ਰੱਖਣਾ, ਪਰ ਇੱਕ ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ ਸਮਾਂਤਰ ਵਿੱਚ ਕਈ ਉਦਾਹਰਣਾਂ ਚਲਾਉਣਾ। ਜੇ ਇੱਕ ਉਦਾਹਰਨ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਬਾਕੀ ਬਚੇ ਨੋਡ ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਨਾਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਜਜ਼ਬ ਕਰ ਲੈਂਦੇ ਹਨ। ਹਰੀਜ਼ੋਂਟਲ ਸਕੇਲਿੰਗ ਦਾ ਸੁਨਹਿਰੀ ਨਿਯਮ ਸਟੇਟਲੈੱਸਨੈੱਸ ਹੈ: ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨਾਂ, ਅੱਪਲੋਡ ਕੀਤੀਆਂ

2:01 ਫਾਈਲਾਂ, ਜਾਂ ਸਥਾਨਕ ਡਿਸਕਾਂ 'ਤੇ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਸਥਿਤੀ ਨੂੰ ਇੱਕ ਬਾਹਰੀ ਡੇਟਾਬੇਸ ਜਾਂ ਕੈਸ਼ ਵਿੱਚ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਸੇ ਵੀ ਨੋਡ ਨੂੰ ਕਿਸੇ ਵੀ ਉਪਭੋਗਤਾ ਬੇਨਤੀ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹੋਏ। ਧਾਰਨਾ ਨੰਬਰ ਦੋ: ਲੋਡ ਬੈਲੈਂਸਿੰਗ।

- 02. ਲੋਡ ਬੈਲੈਂਸਿੰਗ ਆਰਕੀਟੈਕਚਰ (L4 ਬਨਾਮ L7 ਅਤੇ ਹੈਲਥ ਚੈੱਕ)

2:17 ਹਰੀਜ਼ੋਂਟਲ ਸਕੇਲਿੰਗ ਕਾਗਜ਼ 'ਤੇ ਬਹੁਤ ਵਧੀਆ ਲੱਗਦੀ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਤੁਰੰਤ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੀ ਹੈ: ਜਦੋਂ ਦਸ ਹਜ਼ਾਰ ਉਪਭੋਗਤਾ ਤੁਹਾਡੇ ਡੋਮੇਨ ਨਾਮ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ, ਕਿਹੜਾ ਖਾਸ ਸਰਵਰ ਉਹਨਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ? ਇੱਕ ਲੋਡ ਬੈਲੈਂਸਰ ਜਨਤਕ ਇੰਟਰਨੈਟ ਅਤੇ ਤੁਹਾਡੇ ਪ੍ਰਾਈਵੇਟ ਬੈਕਐਂਡ ਕਲੱਸਟਰ ਦੇ ਵਿਚਕਾਰ ਬੈਠੇ ਇੱਕ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਆਉਣ ਵਾਲੇ TCP ਜਾਂ HTTP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀਆਂ ਸਿਹਤਮੰਦ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਬੇਨਤੀਆਂ ਨੂੰ ਵੰਡਦਾ ਹੈ। ਲੋਡ ਬੈਲੈਂਸਰ ਦੋ ਮੁੱਖ ਨੈੱਟਵਰਕ ਲੇਅਰਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ।

2:47 ਲੇਅਰ 4 ਨੈੱਟਵਰਕ ਲੋਡ ਬੈਲੈਂਸਰ ਟ੍ਰਾਂਸਪੋਰਟ ਲੇਅਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ ਲੇਟੈਂਸੀ ਅਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੱਖਾਂ ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ IP ਪਤੇ ਅਤੇ ਪੋਰਟ ਦੇ ਆਧਾਰ 'ਤੇ ਕੱਚੇ TCP ਅਤੇ UDP ਪੈਕੇਟ ਨੂੰ ਰੂਟ ਕਰਦੇ ਹਨ। ਲੇਅਰ 7 ਐਪਲੀਕੇਸ਼ਨ ਲੋਡ ਬੈਲੈਂਸਰ HTTP ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਖੁਦ ਜਾਂਚ ਕਰਦੇ ਹਨ: URL ਪਾਥ, ਬੇਨਤੀ ਹੈਡਰ, ਕੂਕੀਜ਼, ਅਤੇ HTTP ਵਿਧੀਆਂ ਨੂੰ ਪੜ੍ਹਦੇ ਹਨ। ਇਹ ਪਾਥ-ਅਧਾਰਿਤ ਰੂਟਿੰਗ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ: ਸਲੈਸ਼-ਏਪੀਆਈ ਬੇਨਤੀਆਂ ਨੂੰ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਕਲੱਸਟਰ 'ਤੇ ਭੇਜਣਾ ਅਤੇ ਸਲੈਸ਼-ਸਟੈਟਿਕ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਆਬਜੈਕਟ ਸਟੋਰ 'ਤੇ ਭੇਜਣਾ। ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ, ਲੋਡ ਬੈਲੈਂਸਰ ਸਰਗਰਮ ਹੈਲਥ

3:25 ਚੈੱਕ ਕਰਦੇ ਹਨ। ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ, ਬੈਲੈਂਸਰ ਹਰ ਉਦਾਹਰਨ 'ਤੇ ਇੱਕ ਹੈਲਥ ਐਂਡਪੁਆਇੰਟ ਨੂੰ ਪਿੰਗ ਕਰਦਾ ਹੈ। ਜੇ ਇੱਕ ਉਦਾਹਰਨ ਲਗਾਤਾਰ ਤਿੰਨ ਪੰਜ ਸੌ ਗਲਤੀਆਂ ਦਿੰਦੀ ਹੈ ਜਾਂ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਜ਼ੀਰੋ ਡ੍ਰੌਪ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ ਪੂਲ ਵਿੱਚੋਂ ਆਪਣੇ ਆਪ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਧਾਰਨਾ ਨੰਬਰ ਤਿੰਨ: ਆਟੋਸਕੇਲਿੰਗ।

- 03. ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਲਚਕੀਲਾਪਨ

3:45 ਜੇਕਰ ਤੁਹਾਡੀ ਵੈੱਬ ਐਪ ਨੂੰ ਸਵੇਰੇ ਤਿੰਨ ਵਜੇ ਦੋ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਦੁਪਹਿਰ ਦੇ ਲਾਂਚ ਦੌਰਾਨ ਵੀਹ ਸਰਵਰਾਂ ਦੀ, ਕਲਾਊਡ ਕੰਸੋਲ ਵਿੱਚ ਬਟਨਾਂ ਨੂੰ ਹੱਥੀਂ ਕਲਿੱਕ ਕਰਨਾ ਡਾਊਨਟਾਈਮ ਅਤੇ ਦੀਵਾਲੀਆਪਣ ਦਾ ਇੱਕ ਗਾਰੰਟੀਸ਼ੁਦਾ ਰਸਤਾ ਹੈ। ਆਟੋਸਕੇਲਿੰਗ ਹਰੀਜ਼ੋਂਟਲ ਸਰਵਰ ਪੂਲਾਂ ਵਿੱਚ ਗਤੀਸ਼ੀਲ ਲਚਕੀਲਾਪਨ ਲਿਆਉਂਦੀ ਹੈ। ਇੱਕ ਆਟੋ ਸਕੇਲਿੰਗ ਗਰੁੱਪ ਔਸਤ CPU ਉਪਯੋਗਤਾ, ਨੈੱਟਵਰਕ I-O, ਜਾਂ ਕਤਾਰ ਬੈਕਲਾਗ ਦੀ ਡੂੰਘਾਈ ਵਰਗੇ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਔਸਤ CPU ਇੱਕ ਨਿਰਧਾਰਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ — ਕਹੋ, ਲਗਾਤਾਰ ਤਿੰਨ ਮਿੰਟਾਂ ਲਈ ਸੱਤਰ ਪ੍ਰਤੀਸ਼ਤ — ਤਾਂ ਆਟੋਸਕੇਲਰ ਆਪਣੇ ਆਪ ਨਵੀਆਂ

4:19 ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਲਾਂਚ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਲੋਡ ਬੈਲੈਂਸਰ ਨਾਲ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਉਸੇ ਤਰ੍ਹਾਂ ਹੀ ਸਕੇਲਿੰਗ ਇਨ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਵੇਵ ਘੱਟ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਆਟੋਸਕੇਲਰ ਵਾਧੂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵਿਹਲੀ ਕੰਪਿਊਟ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿਓ। ਫਲੈਪਿੰਗ ਨੂੰ ਰੋਕਣ ਲਈ — ਜਿੱਥੇ ਸਰਵਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਖਤਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਬੇਅੰਤ ਥ੍ਰੈਸ਼ਿੰਗ ਲੂਪ ਵਿੱਚ ਨਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ - ਕਲਾਉਡ ਆਰਕੀਟੈਕਟ ਕੌਂਫਿਗਰ ਕਰਦੇ ਹਨ ਕੂਲਡਾਊਨ ਪੀਰੀਅਡ। ਸੰਕਲਪ ਨੰਬਰ ਚਾਰ: ਸਰਵਰ ਰਹਿਤ।

- 04. ਸਰਵਰ ਰਹਿਤ (FaaS ਅਤੇ ਫਾਇਰਕ੍ਰੈਕਰ ਮਾਈਕ੍ਰੋਵੀਐਮ)

4:53 ਸਾਲਾਂ ਤੋਂ, ਮਾਰਕੀਟਿੰਗ ਟੀਮਾਂ ਨੇ ਸਰਵਰ ਰਹਿਤ ਨੂੰ ਜਾਦੂਈ ਕੋਡ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਅਸਮਾਨ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਹੈ। ਅਸਲੀਅਤ ਵਿੱਚ, ਸਰਵਰ ਰਹਿਤ ਅਜੇ ਵੀ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ - ਪਰ ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਮਾਲਕ ਨਹੀਂ ਹੋ, ਪੈਚ ਕਰੋ, ਜਾਂ ਜਦੋਂ ਕੋਈ ਕੋਡ ਨਹੀਂ ਚੱਲ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਉਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰੋ। AWS Lambda ਜਾਂ Google Cloud Functions ਵਰਗੀਆਂ ਫੰਕਸ਼ਨ-ਏਜ਼-ਏ-ਸਰਵਿਸ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਇੱਕ ਸਟੈਂਡਅਲੋਨ ਹੈਂਡਲਰ ਫੰਕਸ਼ਨ ਲਿਖਦੇ ਹੋ। ਜਦੋਂ ਇੱਕ HTTP ਬੇਨਤੀ, S3 ਫਾਈਲ ਅੱਪਲੋਡ, ਜਾਂ ਡੇਟਾਬੇਸ ਤਬਦੀਲੀ ਹੁੰਦਾ ਹੈ, ਕਲਾਉਡ ਰਨਟਾਈਮ ਇੱਕ ਅਸਥਾਈ ਬੂਟ ਕਰਦਾ ਹੈ

5:23 ਮਾਈਕ੍ਰੋ-ਵਰਚੁਅਲ-ਮਸ਼ੀਨ ਜਿਵੇਂ ਕਿ ਫਾਇਰਕ੍ਰੈਕਰ ਪੰਜ ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ। ਤੁਹਾਡਾ ਕੋਡ ਐਗਜ਼ੀਕਿਊਟ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਤਿੰਨ ਮਹੀਨਿਆਂ ਲਈ ਕੋਈ ਵੀ ਤੁਹਾਡੀ ਵੈੱਬਸਾਈਟ 'ਤੇ ਨਹੀਂ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਕੰਪਿਊਟ ਬਿੱਲ ਬਿਲਕੁਲ ਜ਼ੀਰੋ ਡਾਲਰ ਅਤੇ ਜ਼ੀਰੋ ਸੈਂਟ। ਜੇਕਰ ਇੱਕ ਮਿਲੀਅਨ ਉਪਭੋਗਤਾ ਇਸਨੂੰ ਇੱਕੋ ਸਮੇਂ 'ਤੇ ਹਿੱਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਪ੍ਰਦਾਤਾ ਇੱਕ ਮਿਲੀਅਨ ਸਪਿਨ ਕਰਦਾ ਹੈ ਸਮਕਾਲੀ ਮਾਈਕ੍ਰੋਵੀਐਮ। ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਵਪਾਰ-ਬੰਦ ਅਸਲੀ ਹਨ: ਠੰਡੀ ਸ਼ੁਰੂਆਤ ਨਵੇਂ ਰਨਟਾਈਮ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ ਲੇਟੈਂਸੀ, ਲੈਂਬਡਾ 'ਤੇ ਸਖ਼ਤ ਪੰਦਰਾਂ ਮਿੰਟ ਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੀਮਾ ਅਤੇ ਸਖਤ ਅਵਸਥਾਹੀਣਤਾ।

5:55 ਈਵੈਂਟ ਪਾਈਪਲਾਈਨਾਂ ਅਤੇ ਕਦੇ-ਕਦਾਈਂ APIs ਲਈ ਸਰਵਰ ਰਹਿਤ ਅਜੇਤੂ ਹੈ, ਪਰ ਸਥਾਈ ਵੈੱਬਸਾਕੇਟ ਜਾਂ ਕਈ ਘੰਟਿਆਂ ਦੇ ਸਿਖਲਾਈ ਦੌਰਿਆਂ ਲਈ ਮਾੜਾ ਹੈ।

- 05. ਇਵੈਂਟ-ਡ੍ਰਾਈਵਨ ਆਰਕੀਟੈਕਚਰ (EDA ਅਤੇ ਡੀਕਪਲਿੰਗ)

6:05 ਸੰਕਲਪ ਨੰਬਰ ਪੰਜ: ਈਵੈਂਟ-ਡ੍ਰਾਈਵਨ ਆਰਕੀਟੈਕਚਰ, ਜਾਂ EDA। ਰਵਾਇਤੀ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਸੇਵਾਵਾਂ ਸਮਕਾਲੀ ਢੰਗ ਨਾਲ ਸੰਚਾਰ ਕਰਦੀਆਂ ਹਨ। ਤੁਹਾਡੀ ਚੈੱਕਆਉਟ ਸੇਵਾ ਭੁਗਤਾਨ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਭੁਗਤਾਨ ਵਸਤੂ ਸੂਚੀ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਵਸਤੂ ਸੂਚੀ ਧੋਖਾਧੜੀ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਅਤੇ ਧੋਖਾਧੜੀ ਈਮੇਲ ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ। ਇਹ ਬਰਬਾਦੀ ਦਾ ਸਮਕਾਲੀ ਕੈਸਕੇਡ ਬਣਾਉਂਦਾ ਹੈ। ਜੇਕਰ ਤੀਜੀ-ਧਿਰ ਈਮੇਲ ਪ੍ਰਦਾਤਾ ਇੱਕ ਨੈੱਟਵਰਕ ਰੁਕਾਵਟ ਦਾ ਅਨੁਭਵ ਕਰਦਾ ਹੈ ਅਤੇ ਦਸ ਲੈਂਦਾ ਹੈ ਸਕਿੰਟਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ, ਤੁਹਾਡੇ ਗਾਹਕ ਦੀ ਪੂਰੀ ਚੈੱਕਆਉਟ ਬੇਨਤੀ ਦਾ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ ਗਲਤੀ. ਇੱਕ ਈਵੈਂਟ-ਡ੍ਰਾਈਵਨ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਸੇਵਾਵਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡੀਕਪਲਡ ਹੁੰਦੀਆਂ ਹਨ।

6:37 ਜਦੋਂ ਕੋਈ ਗਾਹਕ ਖਰੀਦੋ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਚੈੱਕਆਉਟ ਸੇਵਾ ਡਾਊਨਸਟ੍ਰੀਮ ਨੂੰ ਕਾਲ ਨਹੀਂ ਕਰਦੀ ਸੇਵਾਵਾਂ. ਇਹ ਸਿਰਫ਼ ਇੱਕ ਇਵੈਂਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਆਰਡਰਪਲੇਸਡ ਇੱਕ ਕੇਂਦਰੀ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਈਵੈਂਟ ਬੱਸ ਜਿਵੇਂ ਕਿ ਐਮਾਜ਼ਾਨ ਈਵੈਂਟਬ੍ਰਿਜ ਜਾਂ ਇੱਕ SNS ਵਿਸ਼ਾ। ਚੈੱਕਆਉਟ ਪੰਜਾਹ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਭੁਗਤਾਨ, ਵਸਤੂ ਸੂਚੀ ਦੀ ਕਟੌਤੀ, ਅਤੇ ਈਮੇਲ ਰਸੀਦਾਂ ਲਈ ਡਾਊਨਸਟ੍ਰੀਮ ਵਰਕਰ ਆਪਣੇ ਖੁਦ ਦੇ ਸਮਰਪਿਤ SQS ਕਤਾਰਾਂ ਤੋਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਖਿੱਚੋ। ਜੇਕਰ ਈਮੇਲ ਸੇਵਾ ਇੱਕ ਘੰਟੇ ਲਈ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸੁਨੇਹੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਉਡੀਕ ਕਰਦੇ ਹਨ ਇੱਕ ਵੀ ਡ੍ਰੌਪ ਕੀਤੇ ਆਰਡਰ ਤੋਂ ਬਿਨਾਂ ਕਤਾਰ ਵਿੱਚ ਬਫਰ ਕੀਤਾ ਗਿਆ।

- 06. ਕੰਟੇਨਰ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ (ਡੌਕਰ ਅਤੇ ਕੂਬਰਨੇਟਸ)

7:13 ਸੰਕਲਪ ਨੰਬਰ ਛੇ: ਕੰਟੇਨਰ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ। ਡੌਕਰ ਨੇ ਪੈਕੇਜਿੰਗ ਨੂੰ ਹੱਲ ਕੀਤਾ: ਇਹ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਸਮੇਟਦਾ ਹੈ, ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਸੰਰਚਨਾ, ਅਤੇ ਰਨਟਾਈਮ ਇੱਕ ਅਟੱਲ ਵਿੱਚ ਤਸਵੀਰ ਜੋ ਤੁਹਾਡੇ ਮੈਕਬੁੱਕ ਅਤੇ ਕਲਾਉਡ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀ ਚੱਲਦੀ ਹੈ। ਪਰ ਇੱਕ ਕੰਟੇਨਰ ਨੂੰ ਪੈਕੇਜ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਪੰਜਾਹ ਭੌਤਿਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਪੰਜ ਸੌ ਕੰਟੇਨਰ ਚਲਾਉਣਾ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੰਜੀਨੀਅਰਿੰਗ ਟੁੱਟ ਜਾਂਦੀ ਹੈ। ਇਸੇ ਕਰਕੇ Kubernetes ਅਤੇ AWS ECS ਵਰਗੇ ਕੰਟੇਨਰ ਆਰਕੈਸਟ੍ਰੇਟਰ

7:41 ਮੌਜੂਦ ਹਨ. ਇੱਕ ਆਰਕੈਸਟ੍ਰੇਟਰ ਇੱਕ ਕੰਟਰੋਲ ਪਲੇਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: ਇੱਕ API ਸਰਵਰ, ਇੱਕ etcd ਸਟੇਟ ਸਟੋਰ, ਅਤੇ ਇੱਕ ਬੁੱਧੀਮਾਨ ਸਮਾਂ-ਸੂਚੀ। ਤੁਸੀਂ ਆਪਣੀ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਦਾ ਐਲਾਨ ਕਰਦੇ ਹੋ: ਮੈਂ ਆਪਣੇ ਪ੍ਰਮਾਣੀਕਰਨ ਦੇ ਦਸ ਪ੍ਰਤੀਰੂਪ ਚਾਹੁੰਦਾ ਹਾਂ ਹਰੇਕ ਵਿੱਚ ਦੋ ਗੀਗਾਬਾਈਟ ਰੈਮ ਦੇ ਨਾਲ ਸੇਵਾ। ਸ਼ਡਿਊਲਰ ਕਲੱਸਟਰ ਦਾ ਨਿਰੀਖਣ ਕਰਦਾ ਹੈ, ਖਾਲੀ ਮੈਮੋਰੀ ਵਾਲੇ ਨੋਡਾਂ 'ਤੇ ਪੌਡ ਰੱਖਦਾ ਹੈ, ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕਿੰਗ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਲਗਾਤਾਰ ਅਸਲੀਅਤ ਨੂੰ ਸੁਲਝਾਉਂਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਨੋਡ ਨੂੰ ਹਾਰਡਵੇਅਰ ਅਸਫਲਤਾ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ Kubernetes ਇਸਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਨੁਕਸਾਨ ਅਤੇ ਤੁਰੰਤ ਸਾਰੇ ਵਿਸਥਾਪਿਤ ਪੌਡਾਂ ਨੂੰ ਮੁੜ-ਸਮਾਂਬੱਧ ਕਰਦਾ ਹੈ

- 07. 4 ਕਲਾਊਡ ਸਟੋਰੇਜ ਪਿੱਲਰ (S3, EBS, DBs ਅਤੇ Redis)

8:16 ਸਿਹਤਮੰਦ ਨੋਡ। ਸੰਕਲਪ ਨੰਬਰ ਸੱਤ: ਕਲਾਉਡ ਸਟੋਰੇਜ ਲੜੀ। ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੇ ਅਕਸਰ ਕਲਾਉਡ ਸਟੋਰੇਜ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਬਾਲਟੀ ਮੰਨਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਡੰਪ ਕਰਦੇ ਹੋ ਫਾਈਲਾਂ. ਉਤਪਾਦਨ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਸਟੋਰੇਜ ਨੂੰ ਚਾਰ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਐਕਸੈਸ ਪੈਟਰਨਾਂ ਅਤੇ ਲੇਟੈਂਸੀ 'ਤੇ ਆਧਾਰਿਤ ਥੰਮ੍ਹ। ਪਹਿਲਾ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਹੈ, ਜਿਵੇਂ ਕਿ ਐਮਾਜ਼ਾਨ S3 ਜਾਂ ਗੂਗਲ ਕਲਾਉਡ ਸਟੋਰੇਜ. ਤੁਸੀਂ HTTP REST API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫਾਈਲਾਂ ਨੂੰ ਐਕਸੈਸ ਕਰਦੇ ਹੋ ਸਧਾਰਨ PUT ਅਤੇ GET ਕਾਲਾਂ। ਇਹ ਪ੍ਰਤੀ ਮਹੀਨਾ ਪ੍ਰਤੀ ਗੀਗਾਬਾਈਟ ਦੋ ਸੈਂਟ 'ਤੇ ਅਸੀਮਤ ਹਰੀਜੱਟਲ ਸਮਰੱਥਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ,

8:49 ਇਸਨੂੰ ਵੀਡੀਓ, ਉਪਭੋਗਤਾ ਅੱਪਲੋਡ, ਲੌਗਸ, ਅਤੇ ਬੈਕਅੱਪ ਲਈ ਆਦਰਸ਼ ਬਣਾਉਣਾ। ਦੂਜਾ ਬਲਾਕ ਸਟੋਰੇਜ ਹੈ, ਜਿਵੇਂ ਕਿ ਐਮਾਜ਼ਾਨ EBS। ਇਹ ਵਰਚੁਅਲ ਹਾਰਡ ਡਰਾਈਵ ਹਨ ਜੋ ਸਿੱਧੇ ਇੱਕ ਖਾਸ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਮਾਊਂਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਉੱਚ-ਸਪੀਡ ਇੰਟਰਕਨੈਕਟਾਂ 'ਤੇ। ਉਹ ext4 ਵਰਗੀਆਂ ਮਿਆਰੀ ਫਾਈਲਸਿਸਟਮਾਂ ਵਿੱਚ ਫਾਰਮੈਟ ਕਰਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਦੁਆਰਾ ਲੋੜੀਂਦੀ ਤੇਜ਼ ਰੈਂਡਮ ਰੀਡ ਅਤੇ ਰਾਈਟ ਐਕਸੈਸ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਇੰਜਣ. ਤੀਜਾ ਪ੍ਰਬੰਧਿਤ ਡੇਟਾਬੇਸ ਹਨ: PostgreSQL ਵਰਗੇ ਰਿਲੇਸ਼ਨਲ ਇੰਜਣ RDS 'ਤੇ ACID ਲੈਣ-ਦੇਣ ਅਤੇ ਗੁੰਝਲਦਾਰ ਜੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਨਾ,

9:21 ਅਤੇ DynamoDB ਵਰਗੇ NoSQL ਇੰਜਣ ਸਿੰਗਲ-ਅੰਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਮਿਲੀਸਕਿੰਟ ਲੇਟੈਂਸੀ। ਅਤੇ ਚੌਥੇ ਰੈਮ ਵਿੱਚ ਕੈਚੇ ਹਨ ਜਿਵੇਂ ਕਿ Redis। ਰੈਮ ਤੋਂ ਡਾਟਾ ਪੜ੍ਹਨ ਵਿੱਚ ਮਿਲੀਸਕਿੰਟ ਦੀ ਬਜਾਏ ਮਾਈਕ੍ਰੋਸਕਿੰਟ ਲੱਗਦੇ ਹਨ। ਕੈਚੇ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਦੇ ਸਾਹਮਣੇ ਬੈਠਦੇ ਹਨ, ਇਸਨੂੰ ਵਾਰ-ਵਾਰ ਪੜ੍ਹਨ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ ਅਤੇ ਅਸਥਿਰ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਟੋਕਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ।

- 08. ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਦ ਨਾਈਨਜ਼ (ਮਲਟੀ-AZ ਫੇਲਓਵਰ)

9:44 ਸੰਕਲਪ ਨੰਬਰ ਅੱਠ: ਉੱਚ ਉਪਲਬਧਤਾ, ਜਾਂ HA। ਉਪਲਬਧਤਾ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਤੁਹਾਡਾ ਕਿੰਨੇ ਪ੍ਰਤੀਸ਼ਤ ਸਮਾਂ ਹੈ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਜਸ਼ੀਲ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਪਹੁੰਚਯੋਗ ਹੈ? ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੰਟਰੈਕਟਾਂ ਵਿੱਚ, ਉਪਲਬਧਤਾ ਨੂੰ ਨੌਂ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ। ਦੋ ਨੌਂ, ਜਾਂ ਨੱਬੇ-ਨੌ ਪ੍ਰਤੀਸ਼ਤ ਉਪਲਬਧਤਾ, ਤਿੰਨ ਅਤੇ ਡੇਢ ਦਿਨ ਤੋਂ ਵੱਧ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ ਹਰ ਸਾਲ ਡਾਊਨਟਾਈਮ। ਚਾਰ ਨੌਂ ਬਾਅਦ ਬਚੇ ਡਾਊਨਟਾਈਮ ਨੂੰ ਬਵੰਜਾ ਮਿੰਟਾਂ ਤੱਕ ਘਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਪੰਜ ਨੌਂ ਪ੍ਰਤੀ ਪੂਰੇ ਡਾਊਨਟਾਈਮ ਦੇ ਮੁਸ਼ਕਿਲ ਨਾਲ ਪੰਜ ਮਿੰਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ

10:15 ਸਾਲ. ਉੱਚ ਉਪਲਬਧਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਅਸਫਲਤਾ ਦੇ ਇੱਕਲੇ ਬਿੰਦੂਆਂ ਨੂੰ ਖਤਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਦੋਸ਼ ਡੋਮੇਨਾਂ ਵਿੱਚ। ਕਲਾਉਡ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਈ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨਾ। ਇੱਕ ਉਪਲਬਧਤਾ ਜ਼ੋਨ ਇੱਕ ਸਿੰਗਲ ਰੈਕ ਨਹੀਂ ਹੈ: ਇਹ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਵੱਖਰਾ ਹੈ ਆਜ਼ਾਦ ਬਿਜਲੀ ਅਤੇ ਕੂਲਿੰਗ ਵਾਲੇ ਮੀਲਾਂ ਦੂਰ ਭੌਤਿਕ ਡੇਟਾ ਸੈਂਟਰ। ਜ਼ੋਨ A ਅਤੇ ਜ਼ੋਨ B ਵਿੱਚ ਸਮਕਾਲੀ ਨਾਲ ਸਰਗਰਮ ਉਦਾਹਰਣਾਂ ਚਲਾ ਕੇ ਡੇਟਾਬੇਸ ਪ੍ਰਤੀਰੂਪ, ਇੱਕ ਬਿਜਲੀ ਦੀ ਹੜਤਾਲ ਜਾਂ ਫਾਈਬਰ ਕੱਟ ਜੋ ਲੈਂਦਾ ਹੈ ਇੱਕ ਪੂਰੀ ਭੌਤਿਕ ਸਹੂਲਤ ਨੂੰ ਹੇਠਾਂ ਲਿਆਉਣਾ ਇੱਕ ਸਵੈਚਾਲਿਤ ਫੇਲਓਵਰ ਵਿੱਚ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ

10:50 ਤੀਹ ਸਕਿੰਟਾਂ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਮਨੁੱਖੀ ਦਖਲ ਦੇ।

- 09. ਡਿਊਰੇਬਿਲਟੀ ਬਨਾਮ ਉਪਲਬਧਤਾ (ਕਿਉਂ 11 ਨਾਈਨਜ਼ ਅਪਟਾਈਮ ਨਹੀਂ ਹੈ)

10:53 ਸੰਕਲਪ ਨੰਬਰ ਨੌ: ਟਿਕਾਊਤਾ ਬਨਾਮ ਉਪਲਬਧਤਾ। ਕਲਾਉਡ ਆਰਕੀਟੈਕਚਰ ਇੰਟਰਵਿਊਆਂ ਵਿੱਚ ਇਹ ਸਭ ਤੋਂ ਆਮ ਸੰਕਲਪਿਕ ਜਾਲ ਹੈ। ਇੰਜੀਨੀਅਰ ਅਕਸਰ ਸ਼ਬਦਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਦੇ ਬਦਲੇ ਵਰਤਦੇ ਹਨ, ਪਰ ਉਹ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਮਾਪਦੇ ਹਨ। ਉਪਲਬਧਤਾ ਅੱਪਟਾਈਮ ਨੂੰ ਮਾਪਦੀ ਹੈ: ਕੀ ਮੈਂ ਇਸ ਸਮੇਂ ਆਪਣਾ ਡਾਟਾ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਲਈ ਇੱਕ API ਕਾਲ ਕਰ ਸਕਦਾ ਹਾਂ? Durability measures preservation: will my data survive without permanent ਟਿਕਾਊਤਾ ਸੰਭਾਲ ਨੂੰ ਮਾਪਦੀ ਹੈ: ਕੀ ਮੇਰਾ ਡਾਟਾ ਦਸ ਸਾਲਾਂ ਵਿੱਚ ਸਥਾਈ ਬਿੱਟ ਰੋਟ, ਭ੍ਰਿਸ਼ਟਾਚਾਰ, ਜਾਂ ਵਿਨਾਸ਼ ਤੋਂ ਬਚੇਗਾ? ਦਸ ਸਾਲਾਂ ਵਿੱਚ ਬਿੱਟ ਰੋਟ, ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਜਾਂ ਵਿਨਾਸ਼ ਹੋਏ ਬਿਨਾਂ ਮੇਰਾ ਡਾਟਾ ਬਚੇਗਾ?

11:24 ਐਮਾਜ਼ਾਨ S3 ਸਟੈਂਡਰਡ ਵੇਖੋ। ਇਸਦਾ ਸਰਵਿਸ ਲੈਵਲ ਐਗਰੀਮੈਂਟ ਨੱਬੇ ਪ੍ਰਤੀਸ਼ਤ ਉਪਲਬਧਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਹਰ ਮਹੀਨੇ ਲਗਭਗ ਤਾਲੀ ਮਿੰਟ ਦੇ ਡਾਊਨਟਾਈਮ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕ API ਬੇਨਤੀ ਪੰਜ ਸੌ ਦੀ ਗਲਤੀ ਵਾਪਸ ਕਰ ਸਕਦੀ ਹੈ। ਪਰ S3 ਟਿਕਾਊਤਾ ਦੇ ਗਿਆਰਾਂ ਨਾਈਨ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ: ਨੱਬੇ-ਨੱਬੇ ਪੁਆਇੰਟ ਨੌ ਨੌ ਨੌ ਨੌ ਨੌ ਨੌ ਨੌ ਨੌ ਨੌ ਨੌ ਪ੍ਰਤੀਸ਼ਤ। ਜੇਕਰ ਤੁਸੀਂ S3 ਵਿੱਚ ਦਸ ਮਿਲੀਅਨ ਫਾਈਲਾਂ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅੰਕੜਾ ਅਨੁਸਾਰ ਹਰ ਦਸ ਹਜ਼ਾਰ ਸਾਲਾਂ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਗੁਆਉਣ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ।

11:56 ਹਜ਼ਾਰ ਸਾਲਾਂ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਗੁਆਉਣ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ। S3 ਇਰੇਜ਼ਰ-ਕੋਡਿੰਗ ਆਬਜੈਕਟਾਂ ਦੁਆਰਾ ਇਹ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਘੱਟੋ ਘੱਟ ਤਿੰਨ ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਵੱਖ ਕੀਤੀਆਂ ਡਾਟਾ ਸਹੂਲਤਾਂ ਵਿੱਚ ਖੰਡਾਂ ਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਰਦਾ ਹੈ। ਘੱਟੋ ਘੱਟ ਤਿੰਨ ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਵੱਖ ਕੀਤੀਆਂ ਡਾਟਾ ਸਹੂਲਤਾਂ ਵਿੱਚ ਖੰਡਾਂ ਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਰਦਾ ਹੈ। ਇੱਕ ਵੱਡੇ ਖੇਤਰੀ ਨੈੱਟਵਰਕ ਆਊਟੇਜ ਦੌਰਾਨ, S3 ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਣਉਪਲਬਧ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡਾ ਡਾਟਾ ਕਦੇ ਵੀ ਨਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ।

- 10. ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਐਜ਼ ਕੋਡ (ਟੈਰਾਫਾਰਮ ਬਨਾਮ ਕੰਸੋਲ ਡ੍ਰਿਫਟ)

12:14 ਸੰਕਲਪ ਨੰਬਰ ਦਸ: ਇਨਫਰਾਸਟਰਕਚਰ ਐਜ਼ ਕੋਡ, ਜਾਂ IaC। ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਦੇ ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਵਿੱਚ, ਇੰਜੀਨੀਅਰ AWS ਵੈੱਬ ਪ੍ਰਬੰਧਨ ਕੰਸੋਲ ਵਿੱਚ ਲੌਗਇਨ ਕਰਦੇ ਸਨ ਅਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬਣਾਉਣ, ਸਬਨੈੱਟਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਹੱਥੀਂ ਕਲਿੱਕ ਕਰਦੇ ਸਨ। ਸਬਨੈੱਟਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ, ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਨੂੰ ਜੋੜਨ ਲਈ ਹੱਥੀਂ ਕਲਿੱਕ ਕਰਦੇ ਸਨ। ਉਦਯੋਗ ਇਸਨੂੰ ClickOps ਕਹਿੰਦਾ ਹੈ, ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ, ਇਹ ਇੱਕ ਪੂਰਨ ਤਬਾਹੀ ਹੈ। ਮੈਨੂਅਲ ਕੰਸੋਲ ਬਦਲਾਵਾਂ ਵਿੱਚ ਕੋਈ ਆਡਿਟ ਟ੍ਰੇਲ ਨਹੀਂ ਹੁੰਦਾ, ਕੋਈ ਰੋਲਬੈਕ ਵਿਧੀ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਨਾਟਕੀ ਤੌਰ 'ਤੇ ਸਟੇਜਿੰਗ ਅਤੇ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਵਿਚਕਾਰ ਸੰਰਚਨਾ ਵਿੱਚ ਬਦਲਾਅ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ। ਟੈਰਾਫਾਰਮ, ਓਪਨਟੋਫੂ, ਪੁਲੂਮੀ, ਜਾਂ AWS CDK ਵਰਗੇ ਕੋਡ ਟੂਲਜ਼ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਾਲ,

12:48 ਓਪਨਟੋਫੂ, ਪੁਲੂਮੀ, ਜਾਂ AWS CDK ਵਰਗੇ ਕੋਡ ਟੂਲਜ਼ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਪਣੀ ਪੂਰੀ ਕਲਾਉਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ Git ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਘੋਸ਼ਣਾਤਮਕ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਆਪਣੀ ਪੂਰੀ ਕਲਾਉਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ Git ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਘੋਸ਼ਣਾਤਮਕ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ। ਇੱਕ ਓਪਨ ਪੋਰਟ ਜਾਂ ਡੇਟਾਬੇਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਹਰ ਬਦਲਾਅ ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਅਤੇ ਪੀਅਰ ਸਮੀਖਿਆ ਦੁਆਰਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਪੁੱਲ ਬੇਨਤੀ ਅਤੇ ਪੀਅਰ ਸਮੀਖਿਆ ਦੁਆਰਾ ਜਾਂਦਾ ਹੈ। terraform plan ਚਲਾਉਣ ਨਾਲ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ API ਅੰਤਰ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਉਤਪਾਦਨ ਸਟੈਕ ਦੀ ਇੱਕ ਸਮਾਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਚਾਲੂ ਕਰਨ ਵਿੱਚ ਚਾਰ ਹਫ਼ਤਿਆਂ ਦੀ ਬਜਾਏ ਚਾਰ ਮਿੰਟ ਲੱਗਦੇ ਹਨ। ਸਟੈਕ ਨੂੰ ਚਾਲੂ ਕਰਨ ਵਿੱਚ ਚਾਰ ਹਫ਼ਤਿਆਂ ਦੀ ਬਜਾਏ ਚਾਰ ਮਿੰਟ ਲੱਗਦੇ ਹਨ।

- 11. ਕਲਾਊਡ ਨੈੱਟਵਰਕਿੰਗ (VPC, ਸਬਨੈੱਟ, NAT ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੂਹ)

13:20 ਸੰਕਲਪ ਨੰਬਰ ਗਿਆਰਾਂ: ਕਲਾਉਡ ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਕਲਾਉਡ। ਜਦੋਂ ਤੁਸੀਂ ਸਰਵਰਾਂ ਨੂੰ ਕਲਾਉਡ 'ਤੇ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਕੱਚੇ ਜਨਤਕ ਇੰਟਰਨੈਟ 'ਤੇ ਖੁੱਲ੍ਹੇ ਨਹੀਂ ਬੈਠਦੇ। ਉਹ ਇੱਕ VPC ਨਾਮਕ ਸੌਫਟਵੇਅਰ-ਪਰਿਭਾਸ਼ਿਤ ਅਲੱਗ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦੇ ਹਨ। VPC ਨਾਮਕ ਸੌਫਟਵੇਅਰ-ਪਰਿਭਾਸ਼ਿਤ ਅਲੱਗ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰਹਿੰਦੇ ਹਨ। ਤੁਹਾਡੇ VPC ਦੇ ਅੰਦਰ, ਤੁਸੀਂ ਇੱਕ ਨਿੱਜੀ IP ਪਤਾ ਸਪੇਸ ਜਿਵੇਂ ਕਿ ਟੈਨ-ਡੌਟ-ਜ਼ੀਰੋ-ਡੌਟ-ਜ਼ੀਰੋ-ਡੌਟ-ਜ਼ੀਰੋ ਸਲੈਸ਼ ਸਿਕਸਟੀਨ ਅਲੋਕੇਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਇਸਨੂੰ ਜਨਤਕ ਅਤੇ ਨਿੱਜੀ ਸਬਨੈੱਟਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹੋ। ਅਤੇ ਇਸਨੂੰ ਜਨਤਕ ਅਤੇ ਨਿੱਜੀ ਸਬਨੈੱਟਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹੋ। ਇੱਕ ਜਨਤਕ ਸਬਨੈੱਟ ਦਾ ਇੰਟਰਨੈਟ ਗੇਟਵੇ ਲਈ ਸਿੱਧਾ ਰੂਟ ਹੁੰਦਾ ਹੈ।

13:51 ਇਸ ਵਿੱਚ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਲੋਡ ਬੈਲੈਂਸਰ ਅਤੇ NAT ਗੇਟਵੇਜ਼ ਵਰਗੀਆਂ ਜਨਤਕ-ਮੁਖੀ ਸੰਪਤੀਆਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਦਾ ਇੱਕੋ ਇੱਕ ਹਿੱਸਾ ਹੈ ਜਿਸ ਕੋਲ ਜਨਤਕ IP ਪਤੇ ਹਨ। ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਅਤੇ ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਸਿਰਫ਼ ਨਿੱਜੀ ਸਬਨੈੱਟਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਕੋਈ ਜਨਤਕ IP ਨਹੀਂ ਹੁੰਦੇ ਅਤੇ ਇੰਟਰਨੈਟ ਤੋਂ ਜ਼ੀਰੋ ਇਨਬਾਉਂਡ ਰੂਟ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਸਰਵਰਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਅਪਡੇਟਾਂ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਦਾ ਆਊਟਬਾਉਂਡ ਟ੍ਰੈਫਿਕ ਜਨਤਕ ਸਬਨੈੱਟ ਵਿੱਚ NAT ਗੇਟਵੇ ਰਾਹੀਂ ਰੂਟ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਉਦਾਹਰਣ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਹਨ: ਸਟੇਟਫੁੱਲ ਵਰਚੁਅਲ ਫਾਇਰਵਾਲ ਜੋ ਘੱਟ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ ਦੇ ਸਿਧਾਂਤ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਵਰਚੁਅਲ ਫਾਇਰਵਾਲ ਜੋ ਘੱਟ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰ ਦੇ ਸਿਧਾਂਤ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ।

- 12. ਪੂਰਾ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬਲੂਪ੍ਰਿੰਟ ਅਤੇ ਫੈਸਲਾ

14:28 ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸੁਰੱਖਿਆ ਸਮੂਹ ਸਿਰਫ਼ ਪੋਰਟ 5432 'ਤੇ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰਾਂ ਦੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਤੋਂ ਸਖ਼ਤੀ ਨਾਲ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਬਾਹਰੀ ਪ੍ਰਵੇਸ਼ ਨੂੰ ਗਣਿਤਿਕ ਤੌਰ 'ਤੇ ਅਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਜ਼ੂਮ ਆਊਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਗਿਆਰਾਂ ਮੁੱਢਲੇ ਇੱਕ ਇਕਸਾਰ ਸਿਸਟਮ ਵਿੱਚ ਜੁੜ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਡਾ DNS ਇੱਕ ਜਨਤਕ ਸਬਨੈੱਟ ਵਿੱਚ ਇੱਕ ਲੋਡ ਬੈਲੈਂਸਰ ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ, ਆਟੋਸਕੇਲਿੰਗ ਸਮੂਹ ਕਈ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਵਾਧੇ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ, ਇਵੈਂਟ ਬੱਸਾਂ ਬੈਕਐਂਡ ਵਰਕਰਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਹਾਡਾ ਪੂਰਾ ਸਟੈਕ ਇਨਫਰਾਸਟਰਕਚਰ ਐਜ਼ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗਿੱਟ ਤੋਂ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

15:02 ਅੱਜ ਦੇ ਮਾਸਟਰਕਲਾਸ ਦਾ ਫੈਸਲਾ: SHIP IT. ਸੈਂਕੜੇ ਕਲਾਉਡ ਮਾਰਕੀਟਿੰਗ ਸੰਖੇਪ ਰੂਪਾਂ ਨੂੰ ਯਾਦ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਇਹਨਾਂ ਗਿਆਰਾਂ ਆਰਕੀਟੈਕਚਰ ਪੈਟਰਨਾਂ ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰੋ, ਆਪਣੀ ਸਥਿਤੀ ਨੂੰ ਵੱਖ ਕਰੋ, ਅਤੇ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਓ ਜੋ ਅਸਫਲ ਨਹੀਂ ਹੋ ਸਕਦੇ। ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲੀ ਵਾਰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਤਾਂ ਕਿਹੜੇ ਕਲਾਉਡ ਸੰਕਲਪ ਨੇ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਸਿਰਦਰਦ ਦਿੱਤਾ ਸੀ ਟਿੱਪਣੀਆਂ ਵਿੱਚ। ਅਤੇ ਪੂਰੀ ਆਰਕੀਟੈਕਚਰ ਚੀਟ ਸ਼ੀਟ ਨੂੰ ਫੜਨ ਲਈ, ਦ ਡੇਲੀ ਡਿਫ ਡਾਟ ਡੇਵ 'ਤੇ ਨਿਊਜ਼ਲੈਟਰ ਦੀ ਗਾਹਕੀ ਲਓ,

15:28 ਹੇਠਾਂ ਲਿੰਕ। ਅਤੇ ਅੱਜ ਲਈ ਇਹ ਫਰਕ ਹੈ। ਮੈਂ Axrisi ਤੋਂ ਨਿਕੋ ਹਾਂ। ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਮਿਲਾਓ।

ਸਰੋਤ

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