14 ਨਵੰ 2025·8 ਮਿੰਟ
Craig McLuckie ਅਤੇ ਕਲਾਉਡ-ਨੇਟਿਵ: ਪਲੇਟਫਾਰਮ ਸੋਚ ਦੀ ਜਿੱਤ
Craig McLuckie ਦੀ ਭੂਮਿਕਾ ਅਤੇ ਕਿਵੇਂ ਪਲੇਟਫਾਰਮ ਸੋਚ ਨੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਬਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕੀਤੀ, ਇਸਦੀ ਪ੍ਰਯੋਗਿਕ ਸਮੀਖਿਆ।
Craig McLuckie ਦੀ ਭੂਮਿਕਾ ਅਤੇ ਕਿਵੇਂ ਪਲੇਟਫਾਰਮ ਸੋਚ ਨੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਪ੍ਰੋਡਕਸ਼ਨ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਬਣਾਉਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕੀਤੀ, ਇਸਦੀ ਪ੍ਰਯੋਗਿਕ ਸਮੀਖਿਆ।
ਟੀਮਾਂ ਇਸ ਲਈ ਸੰਘਰਸ਼ ਨਹੀਂ ਕਰਦੀਆਂ ਕਿ ਉਹ ਇੱਕ ਕੰਟੇਨਰ शुरू ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਉਹ ਇਸ ਲਈ ਮੁਸ਼ਕਿਲ ਵਿਚ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਸੈਂਕੜੇ ਕੰਟੇਨਰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਣੇ ਪੈਂਦੇ, ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਦੇ ਅਪਡੇਟ ਕਰਨਾ, ਜਦੋਂ ਕੁਝ ਖਰਾਬ ਹੋਵੇ ਠੀਕ ਕਰਨਾ, ਅਤੇ ਫਿਰ ਵੀ ਨਿਰਧਾਰਿਤ ਸਮੇਂ 'ਤੇ ਫੀਚਰ ਰਿਲੀਜ਼ ਕਰਨੇ ਹੁੰਦੇ ਹਨ।
Craig McLuckie ਦੀ “cloud-native” ਕਹਾਣੀ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕੋਈ ਸ਼ੋ-ਬਾਜ਼ੀ ਵਾਲੇ ਡੈਮੋ ਦੀ ਜਿੱਤ ਨਹੀਂ। ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਕਿਵੇਂ ਕੰਟੇਨਰ ਹਕੀਕਤੀ ਮਾਹੌਲਾਂ ਵਿੱਚ ਚਲਾਉਣਯੋਗ ਬਣੇ—ਜਿੱਥੇ ਘਟਨਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਾਰੋਬਾਰ ਨੂੰ ਭਰੋਸੇਯੋਗ ਡਿਲੀਵਰੀ ਚਾਹੀਦੀ ਹੈ।
“ਕਲਾਉਡ-ਨੇਟਿਵ” ਦਾ ਮਤਲਬ ਸਿਰਫ਼ “ਕਲਾਉਡ ਵਿੱਚ ਚਲਾਉਣਾ” ਨਹੀਂ ਹੈ। ਇਹ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਅਤੇ ਚਲਾਉਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਅਕਸਰ ਡਿਪਲੋਯ ਹੋ ਸਕੇ, ਮੰਗ ਬਦਲਣ 'ਤੇ ਸਕੇਲ ਹੋ ਸਕੇ, ਅਤੇ ਹਿੱਸਿਆਂ ਦੇ ਫੇਲ ਹੋਣ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਹੀ ਕੀਤਾ ਜਾ ਸਕੇ।
ਅਮਲ ਵਿੱਚ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ:
ਸ਼ੁਰੂਆਤੀ ਕੰਟੇਨਰ ਅਪਣਾਉਣ ਅਕਸਰ ਇੱਕ ਸੰਦਾਂ ਦੇ ਡੱਬੇ ਵਾਂਗ ਲੱਗਦੇ ਸਨ: ਟੀਮਾਂ Docker ਚੁੱਕਦੀਆਂ, ਸਕ੍ਰਿਪਟਾਂ ਜੋੜਦੀਆਂ, ਅਤੇ ਉਮੀਦ ਕਰਦੀਆਂ ਕਿ ਓਪਰੇਸ਼ਨਸ ਨਾਲ ਹਰ ਚੀਜ਼ ਠੀਕ ਰਹੇਗੀ। ਪਲੇਟਫਾਰਮ ਸੋਚ ਇਸਨੂੰ ਉਲਟ ਕਰ ਦਿੰਦੀ ਹੈ। ਹਰ ਟੀਮ ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਨਾਹ ਜਾਵੇ—ਇਸ ਦੀ ਬਜਾਏ ਇਕ ਸਾਂਝਾ “paved road” ਬਣਾਇਆ ਜਾਵੇ—ਇਕ ਪਲੇਟਫਾਰਮ ਜੋ ਸੁਰੱਖਿਅਤ, ਅਨੁਕੂਲ ਅਤੇ ਨਿਗਰਾਨੀਯੋਗ ਰਾਹ ਨੂੰ ਸੌਖਾ ਵੀ ਬਣਾਉਂਦਾ ਹੈ।
ਇਹ ਤਬਦੀਲੀ “ਅਸੀਂ ਕੰਟੇਨਰ ਚਲਾ ਸਕਦੇ ਹਾਂ” ਤੋਂ “ਅਸੀਂ ਉਨ੍ਹਾਂ ਤੇ ਕਾਰੋਬਾਰ ਚਲਾ ਸਕਦੇ ਹਾਂ” ਵੱਲ ਪੁਲ ਹੈ।
ਇਹ ਉਨ੍ਹਾਂ ਲਈ ਹੈ ਜਿੰਨਾਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਤੀਜਿਆਂ ਲਈ ਹੈ, ਸਿਰਫ਼ ਆਰਕੀਟੈਕਚਰ ਡਾਇਆਂਗ੍ਰਾਮਾਂ ਲਈ ਨਹੀਂ:
ਜੇ ਤੁਹਾਡਾ ਲਕੜ ਭਰੋਸੇਯੋਗ ਡਿਲੀਵਰੀ ਸਕੇਲ 'ਤੇ ਹੈ, ਤਾਂ ਇਹ ਇਤਿਹਾਸ ਪ੍ਰਯੋਗਿਕ ਸਬਕ ਦਿੰਦਾ ਹੈ।
Craig McLuckie ਉਹਨਾਂ ਨਾਮਾਂ ਵਿੱਚੋਂ ਹੈ ਜੋ ਆਰੰਭਿਕ ਕਲਾਉਡ-ਨੇਟਿਵ ਮੂਵਮੈਂਟ ਨਾਲ ਘਨ੍ਹੀ ਤਰ੍ਹਾਂ ਜੁੜੇ ਹਨ। ਤੁਸੀਂ ਉਹਨਾ ਦਾ ਜ਼ਿਕਰ Kubernetes, Cloud Native Computing Foundation (CNCF), ਅਤੇ ਇਸ ਵਿਚਾਰ ਨਾਲ ਜੁੜੇ ਗੱਲਬਾਤਾਂ ਵਿੱਚ ਦੇਖੋਂਗੇ ਕਿ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਉਤਪਾਦ ਵਾਂਗ ਵਰਤਿਆ ਜਾਵੇ—ਨਾ ਕਿ ਟਿਕਟਾਂ ਅਤੇ ਮੌਖਿਕ ਗਿਆਨ ਦਾ ਢੇਰ।
ਸਪੱਸ਼ਟ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ: McLuckie ਨੇ ਇਕੱਲੇ ਹੀ “ਕਲਾਉਡ-ਨੇਟਿਵ ਦਾ ਆਵਿਸ਼ਕਾਰ” ਨਹੀਂ ਕੀਤਾ, ਅਤੇ Kubernetes ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਸੀ। Kubernetes Google ਦੀ ਇੱਕ ਟੀਮ ਵੱਲੋਂ ਬਣਿਆ, ਅਤੇ McLuckie ਉਸ ਸ਼ੁਰੂਆਤੀ ਯਤਨ ਦਾ ਹਿੱਸਾ ਸੀ।
ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਉਸਨੂੰ ਇਸ ਲਈ ਸਹਿਯੋਗੀ ਮੰਨਦੇ ਹਨ ਕਿ ਉਸਨੇ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਖਿਆਲ ਨੂੰ ਉਦਯੋਗ ਲਈ ਗ੍ਰਹਣਯੋਗ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ: ਕਮਿਊਨਿਟੀ ਬਿਲਡਿੰਗ, ਸਪੱਸ਼ਟ ਪੈਕੇਜਿੰਗ, ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਆਪਰੇਸ਼ਨ ਪ੍ਰਥਾਵਾਂ ਵੱਲ ਧੱਕਾ।
Kubernetes ਅਤੇ CNCF ਦੇ ਯੁੱਗ ਦੌਰਾਨ, McLuckie ਦਾ ਸੁਨੇਹਾ ਵਿਚਾਰਾਂ ਵਾਲੀ ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਘੱਟ ਅਤੇ ਉਤਪਾਦ ਨੂੰ ਪੈਦਾ ਕਰਨ ਯੋਗ ਬਣਾਉਣ 'ਤੇ ਜ਼ਿਆਦਾ ਰਿਹਾ। ਇਸਦਾ ਅਰਥ ਹੈ:
ਜੇ ਤੁਸੀਂ “paved roads”, “golden paths”, ਜਾਂ “platform as a product” ਵਰਗੇ ਸ਼ਬਦ ਸੁਣੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਹੀ ਖਿਆਲ ਦੇ ਨੇੜੇ ਹੋ: ਟੀਮਾਂ ਲਈ ਸਹੀ ਚੀਜ਼ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ।
ਇਹ ਪੋਸਟ ਜੀਵਨੀ ਨਹੀਂ ਹੈ। McLuckie ਇੱਕ ਸੰਦ ਸੰਦੇਸ਼ ਬਿੰਦੂ ਹੈ ਕਿਉਂਕਿ ਉਸਦਾ ਕੰਮ ਤਿੰਨ ਤਾਕਤਾਂ ਦੇ ਇੰਟਰਸੈਕਸ਼ਨ 'ਤੇ ਬੈਠਦਾ ਹੈ ਜਿਸਨੇ ਸਾਫਟਵੇਅਰ ਡਿਲਿਵਰੀ ਬਦਲੀ: ਕੰਟੇਨਰ, orchestration, ਅਤੇ ਇਕੋਸਿਸਟਮ ਨਿਰਮਾਣ। ਇਥੇ ਸਬਕ ਵਿਅਕਤੀਗਤ ਨਹੀਂ—ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਪਲੇਟਫਾਰਮ ਸੋਚ ਕੰਟੇਨਰਾਂ ਨੂੰ ਅਸਲੀ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਖੋਲ੍ਹਣ ਵਾਲਾ ਕਾਰਕ ਬਣੀ।
ਕੰਟੇਨਰ ਇੱਕ ਦਮ ਪਹਿਲਾਂ ਹੀ ਦਿਲਚਸਪ ਵਿਚਾਰ ਸਨ। ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇੱਕ ਕੰਟੇਨਰ ਐਪ ਨੂੰ ਉਹਨਾਂ ਫਾਇਲਾਂ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਪੈਕੇਜ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ ਜੋ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਇੱਕਸਾਰ ਚਲਾਉਂਦੀਆਂ ਹਨ—ਜਿਵੇਂ ਇੱਕ ਉਤਪਾਦ ਨੂੰ ਸੀਲ ਕੀਤੇ ਡੱਬੇ ਵਿੱਚ ਭੇਜਣਾ ਜਿਸ ਵਿੱਚ ਸਾਰੇ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ, ਕਈ ਟੀਮਾਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਸਾਈਡ ਪ੍ਰੋਜੈਕਟਾਂ, ਡੈਮੋ, ਅਤੇ ਡਿਵੈਲਪਰ ਵਰਕਫਲੋ ਲਈ ਵਰਤਦੀਆਂ ਸਨ। ਉਹ ਨਵੇਂ ਸਰਵਿਸ ਤੇਜ਼ੀ ਨਾਲ ਟ੍ਰਾਇ ਕਰਨ, ਟੈਸਟ ਮਾਹੌਲ ਬਣਾਉਣ, ਅਤੇ “ਮੇਰੇ ਲੈਪਟਾਪ ਤੇ ਚੰਗਾ ਚੱਲਦਾ ਸੀ” ਵਾਲੀਆਂ ਸਮਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਲਈ ਵਧੀਆ ਸਨ।
ਪਰ ਕੁਝ ਕੰਟੇਨਰਾਂ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਜੋ 24/7 ਚਲਦਾ ਹੈ ਤੱਕ ਜਾਣਾ ਵੱਖਰੀ ਨੌਕਰੀ ਹੈ। ਟੂਲਿੰਗ ਹਕੀਕਤੀ ਸੀ, ਪਰ ਆਪਰੇਸ਼ਨਲ ਕਹਾਣੀ ਅਧੂਰੀ ਸੀ।
ਆਮ ਮੁਸ਼ਕਿਲਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆਈਆਂ:
ਕੰਟੇਨਰਾਂ ਨੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਪੋਰ੍ਟਬਿਲ ਬਣਾਇਆ, ਪਰ ਸਿਰਫ਼ ਪੋਰ੍ਟਬਿਲਟੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ। ਟੀਮਾਂ ਨੂੰ ਫਿਰ ਵੀ ਲੋੜ ਸੀ ਲਗਾਤਾਰ ਡਿਪਲੋਯ ਪ੍ਰਥਾਵਾਂ, ਸਪੱਸ਼ਟ ਮਾਲਕੀਅਤ, ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਗਾਰਡਰੇਲ—ਤਾਂ ਜੋ ਕੰਟੇਨਰਾਇਜ਼ਡ ਐਪ ਸਿਰਫ਼ ਇੱਕ ਵਾਰੀ ਨਹੀਂ ਚੱਲਣ, ਪਰ ਹਰ ਰੋਜ਼ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚੱਲਣ।
ਪਲੇਟਫਾਰਮ ਸੋਚ ਉਹ ਮੋੜ ਹੈ ਜਦੋਂ ਇੱਕ ਕੰਪਨੀ ਇੰફਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਇਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਅੰਦਰੂਨੀ ਉਤਪਾਦ ਵਜੋਂ ਵੇਖਣ ਲੱਗਦੀ ਹੈ। “ਗਾਹਕ” ਤੁਹਾਡੇ ਡਿਵੈਲਪਰ, ਡੇਟਾ ਟੀਮਾਂ, ਅਤੇ ਕੋਈ ਵੀ ਜੋ ਸਾਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰਦਾ ਹੈ। ਉਤਪਾਦ ਦਾ ਲਕੜ ਸਰਵਰਾਂ ਜਾਂ YAML ਤੋਂ ਬਹੁਤ ਵੱਧ ਹੈ—ਇਹ ਏਕ ਸਕੂਨ ਰਾਹ ਹੈ ਵਿਚਾਰ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ।
ਅਸਲ ਪਲੇਟਫਾਰਮ ਦਾ ਵਾਅਦਾ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ: “ਜੇ ਤੁਸੀਂ ਇਹ ਰਾਹ ਅਪਨਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਭਰੋਸੇਯੋਗਤਾ, ਸੁਰੱਖਿਆ, ਅਤੇ ਨਿਰਧਾਰਿਤ ਡਿਲੀਵਰੀ ਮਿਲੇਗੀ।” ਇਹ ਵਾਅਦਾ product habits ਮੰਗਦਾ ਹੈ—ਡਾਕਯੂਮੈਂਟੇਸ਼ਨ, ਸਹਿਯੋਗ, ਵਰਜਨਿੰਗ, ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ। ਇਹ ਇੱਕ ਸੋਚ-ਵਿਚਾਰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਵੀ ਮੰਗਦਾ ਹੈ: ਸਮਝਦਾਰ ਡੀਫਾਲਟ, paved roads, ਅਤੇ ਜੇ ਟੀਮਾਂ ਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਐਸਕੇਪ ਹੈਚ।
ਮਿਆਰੀਕਰਨ ਫੈਸਲਿਆਂ ਦੀ ਥਕਾਵਟ ਦੂਰ ਕਰਦਾ ਅਤੇ ਅਣਚਾਹੀ ਜਟਿਲਤਾ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਜਦੋ ਟੀਮਾਂ ਇੱਕੋ deployment pattern, ਲੌਗਿੰਗ, ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਸਾਂਝੇ ਕਰਦੀਆਂ ਹਨ, ਸਮੱਸਿਆਵਾਂ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ। ਓਨ-ਕਾਲ ਰੋਟੇਸ਼ਨ ਸੁਧਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਨਸੀਡੈਂਟ ਜਾਣਨਯੋਗ ਦਿਖਦੇ ਹਨ। ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਪਲੇਟਫਾਰਮ ਗਾਰਡਰੇਲਜ਼ ਨੂੰ ਬੇਕ ਕਰਦਾ ਹੈ ਨ ਕਿ ਹਰ ਟੀਮ ਨੂੰ ਨਵਾਂ ਬਣਾਉਣ 'ਤੇ ਛੱਡਦਾ ਹੈ।
ਇਹ ਸਾਰੇ ਲੋਕਾਂ ਨੂੰ ਇਕੋ ਬਕਸੇ ਵਿੱਚ ਧੱਕਣ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਉਸ 80% ਬਾਰੇ ਹੈ ਜੋ ਬੋਰਿੰਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਜੋ ਟੀਮਾਂ ਵਪਾਰ ਨੂੰ ਵੱਖਰਾ ਕਰਨ ਵਾਲੇ 20% 'ਤੇ ਆਪਣੀ ਊਰਜਾ ਲਗਾ ਸਕਣ।
ਜਦੋਂ ਤੱਕ ਪਲੇਟਫਾਰਮ ਸੋਚ ਨਹੀਂ ਆਈ, ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਅਕਸਰ ਖ਼ਾਸ ਗਿਆਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਸੀ: ਕੁਝ ਲੋਕ ਜਾਣਦੇ ਸਨ ਕਿ ਕਿਹੜੇ ਸਰਵਰ ਪੈਚ ਹਨ, ਕਿਹੜੇ ਸੈਟਿੰਗ ਸੁਰੱਖਿਅਤ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਸਕ੍ਰਿਪਟਾਂ “ਠੀਕ” ਹਨ। ਪਲੇਟਫਾਰਮ ਸੋਚ ਇਸਨੂੰ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪੈਟਰਨ ਨਾਲ ਬਦਲ ਦਿੰਦੀ: ਟੈੰਪਲੇਟਸ, ਆਟੋਮੇਟਿਕ ਪ੍ਰੋਵਿਜਨਿੰਗ, ਅਤੇ ਵਿਕਾਸ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਇੱਕਸਾਰ ਮਾਹੌਲ।
ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਗਿਆ, ਪਲੇਟਫਾਰਮ ਘੱਟ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ ਨਾਲ ਬਿਹਤਰ ਗਵਰਨੈਂਸ ਬਣਾਉਂਦਾ ਹੈ। ਨੀਤੀਆਂ ਆਟੋਮੈਟਿਕ ਚੈਕ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਅਨੁਮਤੀਆਂ ਲਾਗੂ ਰਿਹਾ workflow ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਦੇ ਸਬੂਤ deployment ਦੇ ਸਮੇਂ ਸੰਜੋਏ ਜਾਂਦੇ ਹਨ—ਜਿਸ ਨਾਲ ਸੰਸਥਾ ਨੂੰ ਨਿਯੰਤਰਣ ਮਿਲਦਾ ਹੈ ਬਗੈਰ ਹਰ ਕਿਸੇ ਨੂੰ ਹੌਲੀ ਕਰਨ ਦੇ।
ਕੰਟੇਨਰ ਐਪ ਪੈਕੇਜ ਅਤੇ ਭੇਜਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਮੁਸ਼ਕਲ ਹਿੱਸਾ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਭੇਜਣ ਤੋਂ ਬਾਦ ਕਰਦੇ ਹੋ: ਕਿੱਥੇ ਚਲਾਉਣਾ, ਕਿਵੇਂ ਉਸਨੂੰ ਸਿਹਤਮੰਦ ਰੱਖਣਾ, ਅਤੇ ਲੋਡ ਜਾਂ ਸਰਵਰ ਬਦਲਣ 'ਤੇ ਕਿਵੇਂ ਢਾਲਣਾ।
ਇਹੀ ਖੇਤਰ Kubernetes ਨੇ ਭਰਿਆ। ਇਸਨੇ “ਕੰਟੇਨਰਾਂ ਦਾ ਢੇਰ” ਨੂੰ ਇਕ ਐਸਾ ਚੀਜ਼ ਬਣਾ ਦਿੱਤਾ ਜੋ ਤੁਸੀਂ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਚਲਾ ਸਕੋ, ਭਾਵੇਂ ਸਰਵਰ ਫੇਲ ਹੋਣ, ਰਿਲੀਜ਼ ਹੋਣ, ਜਾਂ ਮੰਗ spike ਹੋਣ।
Kubernetes ਨੂੰ ਅਕਸਰ “container orchestration” ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਵਿਹਾਰਕ ਸਮੱਸਿਆਵਾਂ ਜ਼ਿਆਦਾ ਵਿਸ਼ੇਸ਼ ਹਨ:
ਬਿਨਾਂ orchestrator ਦੇ, ਟੀਮਾਂ ਇਹਨਾਂ ਵਿਵਹਾਰਾਂ ਨੂੰ ਸਕ੍ਰਿਪਟ ਕਰਦੀਆਂ ਅਤੇ exceptions ਨੂੰ ਹੱਥੋਂ ਹੱਥ ਮੈਨੇਜ ਕਰਦੀਆਂ—ਜਦ ਤੱਕ ਉਹ ਸਕ੍ਰਿਪਟ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।
Kubernetes ਨੇ ਇੱਕ ਸਾਂਝੇ control plane ਦਾ ਵਿਚਾਰ ਲੋਕਪ੍ਰਿਯ ਬਣਾਇਆ: ਇਕ ਥਾਂ ਜਿੱਥੇ ਤੁਸੀਂ ਆਪਣੀ ਇਛਾ ਦਰਸਾਉਂਦੇ ਹੋ ("ਇਸ ਸਰਵਿਸ ਦੇ 3 ਕਾਪੀਆਂ ਚਲਾਓ") ਅਤੇ ਪਲੇਟਫਾਰਮ ਲਗਾਤਾਰ ਇਸ ਨੂੰ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਖਾਤਾ ਰੱਖਦਾ ਹੈ।
ਇਹ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵਿੱਚ ਵੱਡਾ ਬਦਲਾਅ ਲਿਆਉਂਦਾ ਹੈ:
Kubernetes ਇਸ ਲਈ ਨਹੀਂ ਆਇਆ ਕਿ ਕੰਟੇਨਰ ਫੈਸ਼ਨ ਵਿੱਚ ਸਨ। ਇਹ ਵੱਡੇ fleets ਚਲਾਉਣ ਦੇ ਸਬਕਾਂ ਤੋਂ ਵਧਿਆ: ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਫੀਡਬੈਕ ਲੂਪਾਂ ਵਾਲੀ ਪ੍ਰਣਾਲੀ ਮੰਨੋ, ਨਾ ਕਿ ਇਕ-ਵਾਰੀ ਸਰਵਰ ਟਾਸਕ। ਇਹ ਆਪਰੇਸ਼ਨਲ ਸੋਚ ਇਸਲਈ ਬਣੀ ਕਿ ਇਹ "ਅਸੀਂ ਕੰਟੇਨਰ ਚਲਾ ਸਕਦੇ ਹਾਂ" ਤੋਂ "ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹਾਂ" ਤੱਕ ਪੁੱਜਣ ਵਿੱਚ ਪੁਲ ਬਣਾਉਂਦੀ ਹੈ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਸਿਰਫ਼ ਨਵੇਂ ਟੂਲ ਨਹੀਂ ਲਿਆਇਆ—ਇਸਨੇ ਸੌਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰਨ ਦੀ ਰੋਜ਼ਾਨਾ ਰਿਥਮ ਬਦਲੀ। ਟੀਮਾਂ "ਹਥ ਤੋਂ ਬਣੇ ਸਰਵਰ ਅਤੇ ਮੈਨੂਅਲ ਰਨਬੁਕ" ਤੋਂ ਓਹਨਾਂ ਸਿਸਟਮਾਂ ਵੱਲ ਗਈਆਂ ਜੋ APIs, ਆਟੋਮੇਸ਼ਨ, ਅਤੇ ਡੈਕ੍ਲੇਰਟਿਵ ਕੰਫਿਗ ਦੇ ਨਾਲ ਚਲਦੇ ਹਨ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਸੈਟਅਪ ਇਹ ਧਾਰਨਾ ਰੱਖਦਾ ਹੈ ਕਿ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਪ੍ਰੋਗਰਾਮੇਬਲ ਹੈ। ڈੀਟੇਬੇਸ, ਲੋਡ ਬੈਲੈਂਸਰ, ਜਾਂ ਨਵਾਂ ਮਾਹੌਲ ਚਾਹੀਦਾ? ਹੱਥ ਦੀ ਉਡੀਕ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਆਪਣੀ ਚਾਹਤ ਵੇਰਵਾ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਉਹ ਬਣਾਉਂਦੀ ਹੈ।
ਮੁੱਖ ਤਬਦੀਲੀ ਹੈ ਡੈਕਲੇਰਟਿਵ ਕੰਫਿਗ: ਤੁਸੀਂ ਚਾਹੀਦਾ ਹਾਲਤ ਦਰਸਾਉਂਦੇ ਹੋ ("ਇਸ ਸਰਵਿਸ ਦੀ 3 ਕਾਪੀਆਂ ਚਲਾਓ, ਇਸ ਪੋਰਟ 'ਤੇ експੋਜ਼ ਕਰੋ, ਮੈਮੋਰੀ X ਤੱਕ ਸੀਮਤ ਕਰੋ") ਅਤੇ ਪਲੇਟਫਾਰਮ ਲਗਾਤਾਰ ਇਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਬਦਲਾਅ reviewable, repeatable, ਅਤੇ rollback ਲਈ ਆਸਾਨ ਹੁੰਦੇ ਹਨ।
ਰਿਵਾਇਤੀ ਡਿਲਿਵਰੀ ਵਿੱਚ ਲਾਈਵ ਸਰਵਰਾਂ ਨੂੰ ਪੈਚ ਕਰਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਸੀ। ਸਮੇਂ ਦੇ ਨਾਲ, ਹਰ ਮਸ਼ੀਨ ਥੋੜ੍ਹੀ ਵੱਖਰੀ ਬਣ ਜਾਂਦੀ—configuration drift ਜੋ ਸਿਰਫ਼ ਕਿਸੇ ਘਟਨਾ ਦੀ ਵਖਰੈ ਹੋਣ 'ਤੇ ਸਾਹਮਣੇ ਆਉਂਦਾ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਡਿਲਿਵਰੀ ਟੀਮਾਂ ਨੂੰ ਅਪਰਿਵਰਤਨੀ ਡਿਪਲੋਯਮੈਂਟ ਵੱਲ ਧਕਦਾ: ਇੱਕ ਆਰਟੀਫੈਕਟ ਇਕ ਵਾਰੀ ਬਣਾਉ, ਉਹੀ ਡਿਪਲੋਯ ਕਰੋ, ਅਤੇ ਜੇ ਤਬਦੀਲੀ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ ਨਵਾਂ ਵਰਜਨ ਧਰੋ। ਆਟੋਮੇਟਿਕ ਰੋਲਆਊਟ ਅਤੇ ਹੈਲਥ ਚੈਕ ਨਾਲ, ਇਹ ਇੱਕ-ਆਫ ਫਿਕਸਾਂ ਕਾਰਨ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ “ਰਹਸਮੀ ਬੰਦੀਆਂ” ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਕੰਟੇਨਰ ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਇਕਸਾਰ ਪੈਕੇਜ ਅਤੇ ਚਲਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਵਧੀ। ਮਾਈਕ੍ਰੋਸਰਵਿਸਜ਼, ਬਦਲੇ ਵਿੱਚ, ਨਿਰੰਤਰ ਡਿਪਲੋਯ, ਸਕੇਲ, ਅਤੇ ਸੇਵਾ ਖੋਜ ਦੀ ਲੋੜ ਵਧਾਉਂਦੀਆਂ ਹਨ—ਉਹ ਖੇਤਰ ਜਿੱਥੇ container orchestration ਚਮਕਦੀ ਹੈ।
ਸਮਝੌਤਾ: ਵੱਧ ਸੇਵਾਵਾਂ ਦਾ ਮਤਲਬ ਹੋਰ ਆਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ (ਮਾਨੀਟਰਿੰਗ, ਨੈਟਵਰਕਿੰਗ, ਵਰਜਨਿੰਗ, ਇਨਸੀਡੈਂਟ ਰਿਸਪਾਂਸ)। ਕਲਾਉਡ-ਨੇਟਿਵ ਇਸ ਜਟਿਲਤਾ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦਾ।
ਪੋਰ੍ਟਬਿਲਟੀ ਸੁਧਰੀ ਕਿਉਂਕਿ ਟੀਮਾਂ ਆਮ deployment primitives ਅਤੇ APIs 'ਤੇ ਮਿਆਰਕਰਨ ਕਰਦੀਆਂ। ਫਿਰ ਵੀ, “ਕਿੱਥੇ ਵੀ ਚਲਾਉ” ਅਕਸਰ ਕੰਮ ਮੰਗਦਾ—ਸੁਰੱਖਿਆ, ਸਟੋਰੇਜ, ਨੈਟਵਰਕ, ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਵਿੱਚ ਫਰਕ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਕਲਾਉਡ-ਨੇਟਿਵ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਯਾਦ ਰੱਖੋ: ਇਹ ਬੰਦਨ ਘਟਾਉਂਦਾ ਅਤੇ friction ਘਟਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਓੁਹਨੂੰ ਖਤਮ ਕਰਦਾ।
Kubernetes ਸਿਰਫ਼ ਤਾਕਤਵਰ ਹੋਣ ਕਰਕੇ ਨਹੀਂ ਫੈਲਿਆ। ਇਹ ਇਸ ਲਈ ਫੈਲਿਆ ਕਿ ਇਸਨੂੰ ਇਕ ਨਿਰਪੱਖ ਘਰ ਮਿਲਿਆ, ਸਪੱਸ਼ਟ ਗਵਰਨੈਂਸ ਮਿਲੀ, ਅਤੇ ਇੱਕ ਥਾਂ ਮਿਲੀ ਜਿੱਥੇ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲੀਆਂ ਕੰਪਨੀਆਂ ਬਿਨਾਂ ਕਿਸੇ ਇਕ ਵੇਂਡਰ ਦੇ ਨਿਯਮਾਂ ਨੂੰ ਆਪਣੇ ਹੱਕ ਵਿੱਚ ਕਰਦੇ ਹੋਏ ਸਹਿਯੋਗ ਕਰ ਸਕਦੀਆਂ ਹਨ।
Cloud Native Computing Foundation (CNCF) ਨੇ ਸਾਂਝੀ ਗਵਰਨੈਂਸ ਬਣਾਈ: ਖੁੱਲੇ ਫੈਸਲੇ, ਅਨੁਮਾਨਤ ਪ੍ਰੋਜੈਕਟ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਅਤੇ ਸਰਵਜਨਿਕ ਰੋਡਮੈਪ। ਜਦੋਂ ਟੀਮਾਂ ਕੋਰ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ 'ਤੇ ਦਾਅਵ ਜਾਂਦੇ ਹਨ, ਇਹ ਗੱਲ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਨਿਯਮ ਪਾਰਦਰਸ਼ੀ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਇਕ ਕੰਪਨੀ ਦੇ ਕਾਰੋਬਾਰ ਮਾਡਲ ਨਾਲ ਜੁੜੇ ਨਹੀਂ ਹੁੰਦੇ, ਅਪਨਾਉਣ ਘੱਟ ਖਤਰਨਾਕ ਲੱਗਦਾ—ਅਤੇ ਯੋਗਦਾਨ ਦੇਣਾ ਵੀ ਆਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ।
Kubernetes ਅਤੇ ਸਬੰਧਤ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਕੇ, CNCF ਨੇ “ਲੋਕਪ੍ਰਿਯ open-source ਟੂਲ” ਨੂੰ ਇਕ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਬਦਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। ਇਸਨੇ ਮੁਹੱਈਆ ਕੀਤਾ:
ਬਹੁਤ ਸਾਰੇ ਯੋਗਦਾਨਕਾਰ (ਕਲਾਉਡ ਪ੍ਰੋਵਾਈਡਰ, ਸਟਾਰਟਅੱਪ, ਐਂਟਰਪ੍ਰਾਈਜ਼, ਅਤੇ ਸੁਤੰਤਰ ਇੰਜੀਨੀਅਰ) ਨਾਲ, Kubernetes ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਹਕੀਕਤੀ ਜੀਵਨ-ਉਤਪਾਦ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵਿਕਸਿਤ ਹੋਇਆ: ਨੈਟਵਰਕਿੰਗ, ਸਟੋਰੇਜ, ਸੁਰੱਖਿਆ, ਅਤੇ day-2 آپਰੇਸ਼ਨਸ। ਖੁੱਲ੍ਹੇ APIs ਅਤੇ ਮਿਆਰ ਨੇ ਟੂਲਸ ਲਈ ਇੰਟեգ੍ਰੇਸ਼ਨ ਆਸਾਨ ਕਰ ਦਿੱਤੀ, ਜਿਸ ਨਾਲ ਬੰਦਨ ਘਟਿਆ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਤੋਂ ਲਈ ਭਰੋਸਾ ਵਧਿਆ।
CNCF ਨੇ ਇਕੋਸਿਸਟਮ ਉਤਪੰਨ ਕੀਤਾ: service meshes, ingress controllers, CI/CD ਟੂਲ, policy engines, observability stacks, ਅਤੇ ਹੋਰ। ਇਹ ਪ੍ਰਚੁਰਤਾ ਇੱਕ ਤਾਕਤ ਹੈ—ਪਰ ਇਹ overlap ਵੀ ਪੈਦਾ ਕਰਦੀ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ, ਸਫਲਤਾ ਉਹਨਾਂ ਕੰਪੋਨੈਂਟਾਂ ਦੇ ਚੋਣ ਵਿੱਚ ਹੈ ਜੋ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਰਥਿਤ ਹਨ, ਅੰਤਰਇਕ੍ਰਿਆ ਨੂੰ ਤਰਜੀਹ ਦੇਣ, ਅਤੇ ਮਾਲਕੀਅਤ ਸਪੱਸ਼ਟ ਰੱਖਣ। “ਹਰ ਚੀਜ਼ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ” ਤਰੀਕਾ ਅਕਸਰ ਰਖ-ਰਖਾਵ ਬੋਝ ਵਧਾਉਂਦਾ ਹੈ ਨਾ ਕਿ ਡਿਲਿਵਰੀ ਸੁਧਾਰਦਾ।
ਕੰਟੇਨਰ ਅਤੇ Kubernetes "ਕਿਵੇਂ ਅਸੀਂ ਸਾਫਟਵੇਅਰ ਚਲਾਈਏ" ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੱਲ ਕਰਦੇ ਹਨ। ਉਹ ਖੁਦ ਨਹੀਂ ਸਵਾਲ ਦਾ ਗੁੰਝਲਦਾਰ ਹਿੱਸਾ ਹੱਲ ਕਰਦੇ: "ਜਦੋਂ ਅਸਲ ਯੂਜ਼ਰ ਆਉਂਦੇ ਹਨ ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਰੱਖਦੇ ਹਾਂ?" ਮਿਸਿੰਗ ਲੇਅਰ ਹੈ ਆਪਰੇਸ਼ਨਲ ਭਰੋਸੇਯੋਗਤਾ—ਸਪੱਸ਼ਟ ਉਮੀਦਾਂ, ਸਾਂਝੇ ਅਭਿਆਸ, ਅਤੇ ਇਕ ਐਸੀ ਪ੍ਰਣਾਲੀ ਜੋ ਸਹੀ ਵਰਤਾਰਿਆਂ ਨੂੰ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਦਰਜ ਕਰੇ।
ਜੇ ਪ੍ਰੋਡਕਸ਼ਨ ਬੇਸਲਾਈਨ ਅਸਪੱਸ਼ਟ ਹੈ, ਤਾਂ ਇੱਕ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੀ ਹੈ ਪਰ ਇੱਕ ਖਰਾਬ ਡਿਪਲੋਯ ਦੁਆਰਾ ਕੈਂਧੀ ਹੋ ਸਕਦੀ ਹੈ। ਘੱਟੋ-ਘੱਟ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ:
ਬਿਨਾਂ ਇਸ ਬੇਸਲਾਈਨ ਦੇ, ਹਰ ਸੇਵਾ ਆਪਣੀਆਂ ਨਿਯਮ ਬਣਾਏਗੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਕਿਸੇ ਨਸੀਬ ਦੀ ਗੱਲ ਬਣ ਜਾਏਗੀ।
DevOps ਅਤੇ SRE ਨੇ ਮਹਤ੍ਵਪੂਰਨ ਆਦਤਾਂ ਜਿਵੇਂ ਮਾਲਕੀਅਤ, ਆਟੋਮੇਸ਼ਨ, ਮਾਪੀ ਭਰੋਸੇਯੋਗਤਾ, ਅਤੇ ਘਟਨਾਵਾਂ ਤੋਂ ਸਿੱਖਣਾ ਲਿਆਏ। ਪਰ ਇਹ ਆਦਤਾਂ ਸੈਂਕੜਿਆਂ ਟੀਮਾਂ ਅਤੇ ਸੇਵਾਵਾਂ 'ਤੇ ਸਕੇਲ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਪਲੇਟਫਾਰਮ ਉਹ ਆਦਤਾਂ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। SRE ਲਕੜ ਦਰਸਾਉਂਦਾ ਹੈ (ਜਿਵੇਂ SLOs) ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ; ਪਲੇਟਫਾਰਮ ਉਨ੍ਹਾਂ ਨੂੰ ਮਿਲਣ ਲਈ paved roads ਦਿੰਦਾ ਹੈ।
ਭਰੋਸੇਯੋਗ ਡਿਲਿਵਰੀ ਲਈ ਆਮ ਤੌਰ ਤੇ ਇੱਕਸਾਰ ਸਮਰੱਥਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:
ਇੱਕ ਚੰਗਾ ਪਲੇਟਫਾਰਮ ਇਹ ਡੀਫੌਲਟ ਟੈਮਪਲੇਟ, ਪਾਈਪਲਾਈਨ, ਅਤੇ ਰਨਟਾਇਮ ਨੀਤੀਆਂ ਵਿੱਚ ਬੇਕ ਕਰਦਾ ਹੈ: ਸਾਂਝੇ ਡੈਸ਼ਬੋਰਡ, ਆਮ ਅਲਰਟ ਨਿਯਮ, ਡਿਪਲੋਯਮੈਂਟ ਗਾਰਡਰੇਲ, ਅਤੇ ਰੋਲਬੈਕ ਮਕੈਨਿਜ਼ਮ। ਇਸ ਤਰ੍ਹਾਂ ਭਰੋਸੇਯੋਗਤਾ ਵਿਕਲਪਿਕ ਨਹੀਂ ਰਹਿੰਦੀ—ਇਹ ਸਾਫਟਵੇਅਰ ਸ਼ਿਪ ਕਰਨ ਦਾ ਤੁਸੀਂ ਪੈਦਾ ਕੀਤਾ ਨਤੀਜਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਟੂਲ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੋ ਸਕਦੇ ਹਨ ਪਰ ਅਕਸਰ ਜ਼ਿਆਦਾ ਟੀਮਾਂ ਲਈ "ਬਹੁਤ ਜ਼ਿਆਦਾ" ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰਿੰਗ ਇਸ ਖਾਈ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ। ਮਿਸ਼ਨ ਸਧਾਰਣ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਟੀਮਾਂ ਲਈ cognitive load ਘਟਾਓ ਤਾਂ ਜੋ ਉਹ ਫੀਚਰ ਸ਼ਿਪ ਕਰ ਸਕਣ ਬਿਨਾਂ ਅਧ-ਕਾਲੀਨ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਵਿਸ਼ੇਸ਼ਜ੍ਞ ਬਣਨ ਦੇ।
ਇੱਕ ਚੰਗੀ ਪਲੇਟਫਾਰਮ ਟੀਮ ਅੰਦਰੂਨੀ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਉਤਪਾਦ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਸਪੱਸ਼ਟ ਯੂਜ਼ਰ (ਡਿਵੈਲਪਰ), ਸਪੱਸ਼ਟ ਨਤੀਜੇ (ਸੁਰੱਖਿਅਤ, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਡਿਲਿਵਰੀ), ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ। Kubernetes primitives ਦੀ ਥੋੜ੍ਹੀ ਦੇਣ ਦੀ ਬਜਾਏ, ਪਲੇਟਫਾਰਮ ਸੋਚ ਦਾ ਕਾਰਜ opinionated ਤਰੀਕੇ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਸਰਵਿਸ ਬਣਾਈ ਜਾਂਦੀ, ਡਿਪਲੋਯ ਹੁੰਦੀ ਅਤੇ ਚਲਾਈ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਿਜ਼ਮ ਇਹ ਪੁੱਛਣਾ ਹੈ: “ਕੀ ਇੱਕ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਦਸ ਟਿਕਟ ਖੋਲ੍ਹੇ ਵਿਚਾਰ ਤੋਂ ਚਲਦੀ ਸਰਵਿਸ ਤੱਕ ਜਾ ਸਕਦਾ ਹੈ?” ਉਹ ਟੂਲ ਜੋ ਇਸ ਵਰਕਫਲੋ ਨੂੰ ਸੰਕੋਚਿਤ ਕਰਦੇ ਹਨ—ਜਦੋਂ ਉਹ ਗਾਰਡਰੇਲ ਰੱਖਦੇ ਹਨ—ਉਹ cloud-native ਪਲੇਟਫਾਰਮ ਦੇ ਲਕੜ ਨਾਲ ਮੈਚ ਕਰਦੇ ਹਨ।
ਅਕਸਰ ਪਲੇਟਫਾਰਮ ਇੱਕ ਸੈੱਟ ਮੁੜ-ਵਰਤਣਯੋਗ “paved roads” ਹੁੰਦੇ ਹਨ ਜੋ ਟੀਮਾਂ ਡਿਫੌਲਟ ਵਜੋਂ ਚੁਣ ਸਕਦੀਆਂ ਹਨ:
ਮਕਸਦ Kubernetes ਨੂੰ ਛੁਪਾਉਣਾ ਨਹੀਂ—ਇਸਨੂੰ sensible defaults ਵਿੱਚ ਪੈਕੇਜ ਕਰ ਕੇ ਇੱਕਸੀਡੈਂਟਲ ਜਟਿਲਤਾ ਰੋਕਣੀ ਹੈ।
ਇਸ ਰੂਹ ਵਿੱਚ, Koder.ai ਨੂੰ “DX accelerator” ਲੇਅਰ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇ ਟੀਮਾਂ ਚਾਹੁੰਦੀਆਂ ਹਨ ਕਿ ਅੰਦਰੂਨੀ ਟੂਲ ਜਾਂ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਚੈਟ ਰਾਹੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਏ ਜਾਣ, ਫਿਰ ਜਦੋਂ ਸਮਾਂ ਆਵੇ ਤਾਂ ਸਰੋਤ ਕੋਡ export ਕੀਤਾ ਜਾਵੇ। ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਲਈ, ਇਸ ਦੀ planning mode ਅਤੇ ਨਿਰਮਿਤ snapshots/rollback ਵੀ ਉਹੀ ਰਿਲਾਈਬਿਲਟੀ-ਪਹਿਲੀ ਰਵੱਈਆ ਦਰਸਾ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਉਤਪਾਦਕਸ਼ਨ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਚਾਹੁੰਦੇ ਹੋ।
ਹਰ paved road ਇੱਕ ਸਮਝੌਤਾ ਹੈ: ਵੱਧ ਇਕਸਾਰਤਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਆਪਰੇਸ਼ਨ, ਪਰ ਘੱਟ ਇਕ-ਆਫ ਵਿਕਲਪ। ਪਲੇਟਫਾਰਮ ਟੀਮ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਮੁਹੱਈਆ ਕਰਦੀਆਂ ਹਨ:
ਪਲੇਟਫਾਰਮ ਦੀ ਸਫਲਤਾ ਮਾਪਣ ਯੋਗ ਤਰੀਕਿਆਂ ਵਿੱਚ ਦਿੱਸਦੀ ਹੈ: ਨਵੇਂ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਤੇਜ਼ onboarding, ਘੱਟ bespoke deployment ਸਕ੍ਰਿਪਟ, ਘੱਟ “snowflake” ਕਲਸਟਰ, ਅਤੇ ਇਨਸੀਡੈਂਟ ਸਮੇਂ ਸਪੱਸ਼ਟ ਮਾਲਕੀਅਤ। ਜੇ ਟੀਮ ਬਿਨਾਂ ਮੀਟਿੰਗ ਦਿੱਤੇ ਇਹ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ “ਕੌਣ ਇਸ ਸਰਵਿਸ ਦਾ ਮਾਲਕ ਹੈ ਅਤੇ ਅਸੀਂ ਕਿਵੇਂ ship ਕਰਦੇ ਹਾਂ?” ਤਾਂ ਪਲੇਟਫਾਰਮ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਡਿਲਿਵਰੀ ਤੇਜ਼ ਅਤੇ ਆਪਰੇਸ਼ਨ ਸ਼ਾਂਤ ਕਰ ਸਕਦਾ ਹੈ—ਪਰ ਸਿਰਫ਼ ਜਦੋਂ ਟੀਮ ਉਹਨਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਸਪੱਸ਼ਟ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਉਹ ਸੁਧਾਰਨਾ ਚਾਹੁੰਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਧੀਰੇ ਪੈਦੇ ਤਾਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ Kubernetes ਅਤੇ ਉਸਦਾ ਇਕੋਸਿਸਟਮ ਲਕੜੇ ਹੋਏ ਲਕੜੇ ਵਾਂਗ ਟੀਚੇ ਬਣ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਮਾਧਿਅਮ।
ਇੱਕ ਆਮ ਗਲਤੀ Kubernetes ਨੂੰ ਅਪਣਾਉਣਾ ਹੈ ਕਿਉਂਕਿ ਇਹ "ਅਧੁਨਿਕ ਟੀਮਾਂ ਦੀ ਚੀਜ਼" ਹੈ, ਬਿਨਾਂ ਸੰਖੇਪ ਟੀਚੇ ਜਿਵੇਂ ਘੱਟ lead time, ਘੱਟ incidents, ਜਾਂ ਇੱਕਸਾਰ environment consistency ਦੇ। ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ ਕਾਫ਼ੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੰਮ ਪਰ ਕੋਈ ਵੱਖਰਾ ਲਾਭ ਨਹੀਂ।
ਜੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਹਨ, ਤਾਂ ਹਰ ਫੈਸਲਾ ਵਿਸ਼ੇਸ਼ਤ: ਕਿਹੜਾ ਟੂਲ ਚੁਣਨਾ, ਕਿੰਨਾ ਮਿਆਰੀਕਰਨ ਕਰਨਾ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਕਦੋਂ "ਪੂਰਾ" ਹੋਵੇਗਾ।
Kubernetes ਇੱਕ ਬੁਨਿਆਦ ਹੈ, ਨਾ ਕਿ ਪੂਰਾ ਪਲੇਟਫਾਰਮ। ਟੀਮਾਂ ਅਕਸਰ ਤੁਰੰਤ add-ons ਲਗਾਉਂਦੀਆਂ—service mesh, ਕਈ ingress controllers, custom operators, policy engines—ਬਿਨਾਂ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਜਾਂ ਮਾਲਕੀਅਤ ਦੇ।
ਓਵਰ-ਕਸਟਮਾਈਜੇਸ਼ਨ ਇੱਕ ਹੋਰ ਫੰਦਾ ਹੈ: bespoke YAML ਪੈਟਰਨ, ਹੱਥ-ਲਿਖੀਆਂ ਟੈੰਪਲੇਟ, ਅਤੇ ਇਕ-ਆਫ ਐਕਸੈਪਸ਼ਨਾਂ ਜੋ ਸਿਰਫ਼ ਮੂਲ ਲੇਖਕਾਂ ਨੂੰ ਸਮਝ ਆਉਂਦੀਆਂ। ਜਟਿਲਤਾ ਵਧਦੀ ਹੈ, onboarding ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਅਪਗਰੇਡ ਖਤਰਨਾਕ ਬਣ ਜਾਂਦੇ ਹਨ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਸ_resources_ ਬਣਾਉਣਾ ਆਸਾਨ ਕਰ ਦਿੰਦਾ—ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਭੁੱਲ ਜਾਣਾ ਵੀ ਆਸਾਨ। ਕਲਸਟਰ ਫੈਲਾਅ, ਅਣਉਪਯੋਗ ਨੇਮਸਪੇਸ, ਅਤੇ ਜ਼ਿਆਦਾ ਪ੍ਰੋਵਿਜਨ ਕੀਤੇ workloads ਖਰਚ ਵਧਾ ਸਕਦੇ ਹਨ।
ਸੁਰੱਖਿਆ ਖਾਮੀਆਂ ਵਿੱਖੇ ਵੀ ਆਮ ਹਨ:
ਇੱਕ ਜਾਂ ਦੋ ਵਧੀਕ-ਸੰਘਣੇ ਸਰਵਿਸਾਂ ਨਾਲ ਛੋਟੇ ਸ਼ੁਰੂ ਕਰੋ। ਸ਼ੁਰੂ ਵਿੱਚ ਮਿਆਰ (golden paths, ਮਨਜ਼ੂਰਕਿੱਤੇ ਬੇਸ images, ਅਪਗਰੇਡ ਨਿਯਮ) ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਪਲੇਟਫਾਰਮ ਦੀ ਸਰਫੇਸ ਏਰੀਆ ਨੂੰ ਜਾਣ-ਬੂਝ ਕੇ ਸੀਮਿਤ ਰੱਖੋ।
ਨਤੀਜੇ ਮਾਪੋ ਜਿਵੇਂ deployment frequency, mean time to recovery, ਅਤੇ developer time-to-first-deploy—ਅਤੇ ਜੋ ਕੁਝ ਉਹ ਨੰਬਰ ਨਹੀਂ ਸੁਧਾਰਦਾ, ਉਸਨੂੰ ਵਿਕਲਪਿਕ ਸਮਝੋ।
ਤੁਸੀਂ ਕਦੇ ਵੀ "ਕਲਾਉਡ-ਨੇਟਿਵ ਅਪਣਾਉ" ਨਹੀਂ ਕਰਦੇ ਇੱਕ ਵਾਰ ਵਿੱਚ। ਜਿਹੜੀਆਂ ਟੀਮਾਂ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ ਉਹ ਉਸੇ ਮੱਤ ਦਾ ਅਨੁਸਰਣ ਕਰਦੀਆਂ ਹਨ ਜੋ McLuckie ਦੇ ਯੁੱਗ ਨਾਲ ਜੁੜਿਆ ਸੀ: ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਣਾਓ ਜੋ ਸਹੀ ਰਸਤੇ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਜੋ ਚੰਗਾ ਲੱਗੇ ਉਸ ਨੂੰ ਕੋਡਾਈਫੀ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਨਵੀਂ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਉਪਯੋਗੀ ਪੈਟਰਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ “golden path” ਤਜਰਬਾ end-to-end prototype ਕਰ ਲਵੋ ਪਹਿਲਾਂ ਉਸਨੂੰ ਮਿਆਰੀਕਰਨ ਕਰੋ। ਉਦਾਹਰਣ ਲਈ, ਟੀਮਾਂ Koder.ai ਵਰਤ ਕੇ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਵੈੱਬ ਐਪ (React), ਬੈਕਐਂਡ (Go), ਅਤੇ ਡੇਟਾਬੇਸ (PostgreSQL) ਨੂੰ ਚੈਟ ਰਾਹੀਂ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉ ਸਕਦੀਆਂ ਹਨ, ਫਿਰ ਉਸ ਕੋਡਬੇਸ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੇ ਟੈੰਪਲੇਟ ਅਤੇ CI/CD ਰੀਤਾਂ ਲਈ ਆਰੰਭ ਬਿੰਦੂ ਵਜੋਂ ਵਰਤ ਸਕਦੀਆਂ ਹਨ।
ਟੂਲ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ:
ਨਤੀਜਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰੋ, ਨਾ ਕਿ ਟੂਲ ਦੀ ਵਰਤੋਂ:
ਜੇ ਤੁਸੀਂ ਚੰਗੇ "platform MVP" ਪੈਕੇਜਾਂ ਦੇ ਉਦਾਹਰਣ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਦੇਖੋ /blog. ਬਜਟਿੰਗ ਅਤੇ ਰੋਲਆਊਟ ਯੋਜਨਾ ਲਈ, ਤੁਸੀਂ /pricing ਨੂੰ ਵੀ ਵੇਖ ਸਕਦੇ ਹੋ।
ਪਿਛਲੇ ਦਹਾਕੇ ਤੋਂ ਵੱਡਾ ਸਬਕ ਸਧਾਰਨ ਹੈ: ਕੰਟੇਨਰਾਂ ਨੇ "ਜਿੱਤ" ਨਹੀਂ ਕੀਤੀ ਕਿਉਂਕਿ ਉਹ ਚਤੁਰ ਪੈਕੇਜਿੰਗ ਸਨ। ਉਹ ਜੀਤੇ ਕਿਉਂਕਿ ਪਲੇਟਫਾਰਮ ਸੋਚ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਇਆ—ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਡਿਪਲੋਯਮੈਂਟ, ਸੁਰੱਖਿਅਤ ਰੋਲਆਊਟ, ਇੱਕਸਾਰ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ, ਅਤੇ ਨਿਰਧਾਰਿਤ ਆਪਰੇਸ਼ਨ।
ਅਗਲਾ ਅਧਿਆਇ ਕਿਸੇ ਇਕ ਵੱਡੇ ਟੂਲ ਬਾਰੇ ਨਹੀਂ ਹੋਵੇਗਾ। ਇਹ ਇਸ ਬਾਰੇ ਹੋਵੇਗਾ ਕਿ ਕਿਵੇਂ ਕਲਾਉਡ-ਨੇਟਿਵ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ "ਬੋਰਿੰਗ" ਬਣਾਇਆ ਜਾਵੇ: ਘੱਟ ਅਚਨਚੇਤਾਂ, ਘੱਟ ਇਕ-ਆਫ ਫਿਕਸ, ਅਤੇ ਕੋਡ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਇੱਕ ਸਫਾ ਰਸਤਾ।
Policy-as-code ਇੱਕ ਡੀਫੌਲਟ ਬਣੇਗਾ। ਹਰ ਡਿਪਲੋਯ ਨੂੰ ਮੈਨੂਅਲ ਸਮੀਖਿਆ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਸੁਰੱਖਿਆ, ਨੈਟਵਰਕਿੰਗ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਲਈ ਨਿਯਮ ਕੋਡ ਕਰਦੀ ਹਾਂ, ਤਾਂ ਗਾਰਡਰੇਲ ਆਟੋਮੈਟਿਕ ਅਤੇ ਅਡਿਟੇਬਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
Developer experience (DX) ਨੂੰ ਉਤਪਾਦ ਵਜੋਂ ਟ੍ਰੀਟ ਕੀਤਾ ਜਾਵੇਗਾ। ਜ਼ਿਆਦਾ ਧਿਆਨ paved roads, ਟੈੰਪਲੇਟ, self-service environments, ਅਤੇ ਸਪੱਸ਼ਟ golden paths 'ਤੇ ਮਿਲੇਗਾ ਜੋ cognitive load ਘਟਾਉਂਦੇ ਹਨ ਬਿਨਾਂ autonomy ਘਟਾਏ।
ਸਧਾਰਨ ops, ਨਾ ਕਿ ਹੋਰ ਡੈਸ਼ਬੋਰਡ। ਸਭ ਤੋਂ ਵਧੀਆ ਪਲੇਟਫਾਰਮ complexity ਨੂੰ ਛੁਪਾਉਣਗੇ: opinionated defaults, ਘੱਟ ਹਿਲਦਾ-ਡੁੱਲਦਾ ਹਿੱਸਾ, ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਪੈਟਰਨ ਜੋ ਬਿਲਟ-ਇਨ ਹੋਣਗੇ ਨਾ ਕਿ ਬੋਲਟ-ਔਨ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਤਰੱਕੀ ਉਸ ਵੇਲੇ ਹੌਲੀ ਪੈਂਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਫੀਚਰ ਦੀ ਪਿੱਛੇ ਭੱਜਦੀਆਂ ਹਨ ਨਾ ਕਿ ਨਤੀਜਿਆਂ ਦੇ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਨਵੇਂ ਟੂਲ ਨੂੰ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ ਕਿ ਇਹ lead time ਘਟਾਉਂਦਾ, incident ਦਰ ਘਟਾਉਂਦਾ, ਜਾਂ ਸੁਰੱਖਿਆ ਦਰ ਸੁਧਾਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਪ੍ਰਾਇਓਰਿਟੀ ਨਹੀਂ ਹੈ।
ਆਪਣੇ ਮੌਜੂਦਾ ਡਿਲਿਵਰੀ ਦਰਦ ਨੁਕਸਾਨਾਂ ਦਾ ਅੰਕੜਾ ਲਓ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਮੈਪ ਕਰੋ:
ਇਨ੍ਹਾਂ ਜਵਾਬਾਂ ਨੂੰ ਆਪਣੇ ਪਲੇਟਫਾਰਮ ਬੈਕਲਾਗ ਵਜੋਂ ਲਓ—ਅਤੇ ਹਫ਼ਤੇ ਦਰ ਹਫ਼ਤੇ ਉਹ ਨਤੀਜੇ ਮਾਪੋ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਟੀਮ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ।
Cloud-native ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਵੇਂ ਸਾਫਟਵੇਅਰ ਬਣਾਇਆ ਅਤੇ چلਾਇਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਕਸਰ ਡਿਪਲੋਯ ਕਰ ਸਕੋ, ਡਿਮਾਂਡ ਬਦਲਣ 'ਤੇ ਸਕੇਲ ਕਰ ਸਕੋ, ਅਤੇ ਫੇਲ ਹੋਣ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਹੀ ਕਰ ਸਕੋ।
ਵਰਤੋਂ ਵਿੱਚ ਇਹ ਆਮ ਤੌਰ 'ਤੇ containers, automation, ਛੋਟੀ ਸੇਵਾਵਾਂ, ਅਤੇ ਚੱਲ ਰਹੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਨਿਗਰਾਨੀ, ਸੁਰੱਖਿਆ ਅਤੇ ਗਵਰਨੈਂਸ ਦੇ ਸਟੈਂਡਰਡ ਤਰੀਕਿਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ।
ਇੱਕ container ਤੁਹਾਨੂੰ ਸਾਫਟਵੇਅਰ ਨੂੰ ਇੱਕਸਾਰ ਭੇਜਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਅਕਸਮਾਤ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਦੇ ਮੁਸ਼ਕਲ ਮਸਲਿਆਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦਾ—ਜਿਵੇਂ ਸੁਰੱਖਿਅਤ ਅਪਗਰੇਡ, ਸੇਵਾ ਖੋਜ (service discovery), ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ, ਅਤੇ ਟਿਕਾਉ ਨਿਗਰਾਨੀ।
ਗੈਪ ਉਹਨੀਂ ਉੱਥੇ ਨਿਕਲਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਹੀ containers ਤੋਂ ਲੈ ਕੇ ਸੈਂਕੜਿਆਂ ਨੂੰ 24/7 ਚਲਾਉਣ 'ਤੇ ਜਾਦੇ ਹੋ।
“Platform thinking” ਦਾ ਮਤਲਬ ਹੈ ਅੰਦਰੂਨੀ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਇੱਕ ਅੰਦਰੂਨੀ ਉਤਪਾਦ ਵਜੋਂ ਦੇਖਣਾ — ਜਿਸਦੇ ਸਪੱਸ਼ਟ ਯੂਜ਼ਰ (ਡਿਵੈਲਪਰ) ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਵਾਅਦਾ (ਸੁਰੱਖਿਅਤ, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਡਿਲੀਵਰੀ) ਹੁੰਦੇ ਹਨ।
ਹਰ ਟੀਮ ਆਪਣਾ ਰਸਤਾ ਤਾਂ ਤਿਆਰ ਨਾ ਕਰੇ, ਸਗੋਂ ਸੰਸਥਾ ਸਾਂਝੇ paved roads (golden paths) ਤਿਆਰ ਕਰੇ ਜੋ sensible defaults ਅਤੇ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹਨ।
Kubernetes ਉਹ ਆਪਰੇਸ਼ਨਲ ਲੇਅਰ ਦਿੰਦਾ ਹੈ ਜੋ “containers ਦੇ ਢੇਰ” ਨੂੰ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਬਨਾ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰੋਜ਼ ਚਲਾ ਸਕਦੇ ਹੋ:
ਇਸਦੇ ਨਾਲ ਇਕ ਸਾਂਝਾ ਆਉਂਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚਾਹੋ ਉਹ ਹਾਲਤ ਘੋਸ਼ਿਤ ਕਰਦੇ ਹੋ ਤੇ ਸਿਸਟਮ ਉਸਨੂੰ ਮਿਲਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ।
Declarative config ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਇਹ ਵੇਰਵਾ ਦਿੰਦੇ ਹੋ ਬਜਾਏ ਕਿ ਕਦਮ-ਬ-ਕਦਮ ਪ੍ਰੋਸੀਜਰ ਲਿਖਣ ਦੇ।
ਪ੍ਰਯੋਗਕ ਫਾਇਦੇ:
Immutable deployments ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਲਾਈਵ ਸਰਵਰਾਂ 'ਤੇ ਪੈਚ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ ਇੱਕ ਆਰਟੀਫੈਕਟ ਇੱਕ ਵਾਰੀ ਬਣਾਉਂਦੇ ਹੋ (ਅਕਸਰ container image) ਅਤੇ ਉਹੀ ਆਰਟੀਫੈਕਟ ਡਿਪਲੋਯ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਕਿਸੇ ਬਦਲਾਵ ਲਈ, ਤੁਸੀਂ ਨਵੀਂ ਵਰਜਨ ਭੇਜਦੇ ਹੋ ਨਾ ਕਿ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਨੂੰ ਸੋਧਦੇ ਹੋ। ਇਹ configuration drift ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਇਨਸਿਡੈਂਟ ਨੂੰ ਦੁਹਰਾਉਣ ਅਤੇ ਰੋਲਬੈਕ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
CNCF ਨੇ Kubernetes ਅਤੇ ਸਬੰਧਤ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਇੱਕ ਤਟਸਥ ਗਵਰਨੈਂਸ ਘਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਕੋਰ ਇੰਫਰਾਸਟ੍ਰੱਕਚਰ 'ਤੇ ਦांव ਲਾਉਣਾ ਘੱਟ ਖਤਰਨਾਕ ਹੋ ਗਿਆ।
ਇਸ ਨੇ ਮਦਦ ਕੀਤੀ:
ਉਤਪਾਦਿਕਤਾ ਦਾ ਢਾਂਚਾ (production baseline) ਉਹ ਘੱਟੋ-ਘੱਟ ਸਮਰੱਥਾ ਅਤੇ ਅਭਿਆਸ ਹਨ ਜੋ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਪੂਰਵ ਨਿਯਤ ਬਣਾਉਂਦੇ ਹਨ, ਜਿਵੇਂ:
ਇਨ੍ਹਾਂ ਦੇ ਬਿਨਾਂ ਹਰ ਸੇਵਾ ਆਪਣੀਆਂ ਨਿਯਮ ਬਣਾਏਗੀ ਅਤੇ ਵਿਸ਼ਵਾਸ ਯਾਦਾਸ਼ਤ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇਗਾ।
Platform engineering ਦਾ ਮਕਸਦ ਹੈ ਡਿਵੈਲਪਰਾਂ ਦਾ cognitive load ਘਟਾਉਣਾ ਅਤੇ cloud-native ਪ੍ਰਿਮਿਟਿਵਜ਼ ਨੂੰ opinionated defaults ਵਿੱਚ ਪੈਕੇਜ ਕਰਨਾ:
ਮਕਸਦ Kubernetes ਨੂੰ ਛੁਪਾਉਣਾ ਨਹੀਂ, ਬਲਕਿ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਸਭ ਤੋਂ ਆਸਾਨ ਬਣਾਉਣਾ ਹੈ।
ਆਮ pitfalls ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਰੋਕਥਾਮ ਲਈ: