Andy Jassy ਦਾ AWS ਖੇਲ-ਪੁਸਤਕ: ਭਾਰੀ ਕੰਮ ਨੂੰ ਮੁੱਲ ਵਿੱਚ ਬਦਲਣਾ

“ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ” ਦਾ ਅਸਲ ਮਤਲਬ

“ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ” ਇੱਕ ਸਧਾਰਨ ਪਰ ਤੇਜ਼-ਸੂਚਕ ਵਿਚਾਰ ਹੈ: ਇਹ ਉਹ ਕੰਮ ਹਨ ਜੋ ਤੁਹਾਡੇ ਸੋਫਟਵੇਅਰ ਨੂੰ ਚਲਾਉਣ ਲਈ ਜ਼ਰੂਰੀ ਹਨ, ਪਰ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਤੁਹਾਨੂੰ ਚੁਣਣ ਲਈ ਪ੍ਰੇਰਿਤ ਨਹੀਂ ਕਰਦੇ।

ਇਨ੍ਹਾਂ ਵਿੱਚ ਸਰਵਰ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ, ਡੇਟਾਬੇਸ ਪੈਚਿੰਗ, ਕ੍ਰੈਡੈਂਸ਼ਲ ਰੋਟੇਸ਼ਨ, ਮਾਨੀਟਰੀੰਗ ਸੈਟਅੱਪ, ਫੇਲਓਵਰ ਹੈਂਡਲਿੰਗ, ਕੈਪੇਸਿਟੀ ਸਕੇਲਿੰਗ ਅਤੇ ਉਤਪਾਦੀ ਸਮੱਸਿਆਵਾਂ ਬਜਾਏ ਨਲ-ਜੁੜਾਈ (plumbing) ਕਾਰਨਾਂ ਵਾਲੇ ਪ੍ਰੋਡਕਸ਼ਨ ਇਨਿਸਿਡੈਂਟਾਂ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਰਗੇ ਕੰਮ ਆਉਂਦੇ ਹਨ। ਇਹ ਕੰਮ ਅਹੰਕਾਰ ਯੋਗ ਨਹੀਂ—ਪਰ ਅਕਸਰ ਜ਼ਰੂਰੀ ਅਤੇ ਤੁਰੰਤ ਹੋ ਸਕਦੇ ਹਨ।

ਸਧਾਰਨ-ਭਾਸ਼ਾ ਵਿ਷ੇਸ਼ ਪਰਿਭਾਸ਼ਾ

ਜੇ ਕੋਈ ਕੰਮ:

• ਜ਼ਰੂਰੀ ਹੈ (ਭਰੋਸੇਯੋਗਤਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਹ ਤੋਂ ਬਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ)
• ਦੋਹਰਾਇਆ ਜਾਣ ਵਾਲਾ ਹੈ (ਹਰ ਟੀਮ ਇਸਦਾ ਸਮਾਨ ਵਰਜਨ ਕਰਦੀ ਹੈ)
• ਕੋਈ ਮੁਕਾਬਲਾਤਮਕ ਫਾਇਦਾ ਨਹੀਂ ਦਿੰਦਾ (ਗਾਹਕ ਇਸ ਲਈ ਵਧੇਰੇ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰਨਗੇ ਕਿ ਤੁਸੀਂ ਇਹ ਖੁਦ ਕੀਤਾ)

…ਤਾਂ ਇਹ ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ ਹੈ।

ਕਿਉਂ ਇਹ ਵਾਕ ਯੂਜਰਾਂ ਅਤੇ ਐਗਜ਼ੀਕਿਊਟਿਵਾਂ ਨੂੰ ਭਾਇਆ

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

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

ਇਹ ਵਿਚਾਰ ਕਿਸ ਬਿਜ਼ਨਸ ਪੈਟਰਨ ਦੀ ਨਿਰਦੇਸ਼ਨਾ ਕਰਦਾ ਹੈ

AWS ਨੇ ਇਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਪਲੇਬੁੱਕ ਪ੍ਰਚਲਿਤ ਕੀਤਾ:

1. ਟੌਇਲ ਹਟਾਓ—ਕਮਜ਼ੋਰ, ਟੀਮ-ਦਰ-ਟੀਮ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਇੱਕ ਸੇਵਾ ਵਿੱਚ ਬਦਲੋ।
2. ਮਿਆਰੀਕਰਨ—ਆਮ ਹਿੱਸਿਆਂ ਨੂੰ ਸਟੈਂਡਰਡ ਬਣਾਓ ਤਾਂ ਕਿ ਗੁਣਵੱਤਾ ਲਗਾਤਾਰ ਹੋਵੇ।
3. ਸਕੇਲ—ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਸਾਂਝੀ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਰਾਹੀਂ ਵਧੋ।
4. ਮੁੜ-ਨਿਵੇਸ਼—ਬਚਤ ਕਰਕੇ ਚੰਗੇ ਉਤਪਾਦ ਅਤੇ ਤੇਜ਼ ਡਿਲਿਵਰੀ ਵਿੱਚ ਲਾਉ।

ਇਹ ਕਲਾਉਡ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਤੋਂ ਵੱਡਾ ਹੈ—ਇਹ ਕਿਸੇ ਵੀ ਸੋਫਟਵੇਅਰ ਬਿਜ਼ਨਸ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਗਈ “ਪਲੇਟਫਾਰਮ ਸੋਚ” ਹੈ।

ਇਸ ਲੇਖ ਤੋਂ ਉਮੀਦ ਕੀ ਕਰੋ

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

Andy Jassy ਦੀ ਮੁੱਖ ਸੋਚ: ਗਾਹਕ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਨਿਗਰਾਨੀ ਨਹੀਂ

Andy Jassy ਉਹਨਾਂ ਪਹਿਲੇ ਨੇਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ Amazon ਦੀਆਂ ਆਂਤਰਿਕ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਯੋਗਤਾਵਾਂ ਨੂੰ AWS ਵਜੋਂ ਬਦਲਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕੀਤੀ। ਉਹਨਾਂ ਦੀ ਨੌਕਰੀ ਸਿਰਫ਼ “ਇੰਟਰਨੈੱਟ ਉੱਤੇ ਸਰਵਰ ਵੇਚਣਾ” ਨਹੀਂ ਸੀ। ਉਹ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਗਾਹਕ ਸਮੱਸਿਆ ਨੂੰ ਨੋਟਿਸ ਕਰਕੇ ਉਹਦਾ ਹੱਲ ਪੈਕੇਜ ਕਰਕੇ ਹਜ਼ਾਰਾਂ ਟੀਮਾਂ 'ਤੇ ਸਕੇਲ ਕਰਨ ਯੋਗ ਬਣਾਉਣ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ।

ਅਸਲ ਦਰਦ: ਓਪਰੇਸ਼ਨਸ ਪ੍ਰੋਡਕਟ ਤੋਂ ਧਿਆਨ ਚੁਰਾ ਲੈਂਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਸੋਫਟਵੇਅਰ ਟੀਮਾਂ OS ਪੈਚ ਕਰਨ, ਕੈਪੇਸਿਟੀ ਪ੍ਰੋਵਾਈਜਨ ਕਰਨ, ਕ੍ਰੈਡੈਂਸ਼ਲ ਰੋਟੇਟ ਕਰਨ ਜਾਂ ਫੇਲਡ ਡਿਸਕ ਤੋਂ ਬਹਾਲ ਕਰਨ ਲਈ ਉਤਸ਼ਾਹ ਨਾਲ ਨਹੀਂ ਉਠਦੀਆਂ। ਉਹ ਇਹ ਕੰਮ ਇਸ ਲਈ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਲਾਜ਼ਮੀ ਹੈ—ਨਹੀਂ ਤਾਂ ਐਪ ਨਹੀਂ ਚਲੇਗੀ।

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

ਇਸ ਲਈ ਢਾਂਚੇ ਦੀ “ਬੇਬਿਸਿਟਿੰਗ” ਇੱਕ ਟੈਕਸ ਬਣ ਜਾਂਦੀ ਹੈ:

• ਇਹ ਉਹ ਸਮਾਂ ਖਾਂਦਾ ਹੈ ਜੋ ਸੁਧਾਰ ਭੇਜਣ ਵਿੱਚ ਲੱਗ ਸਕਦਾ ਸੀ।
• ਇਹ ਟੀਮਾਂ ਨੂੰ ਉਹਨੀਂ ਕੁਸ਼ਲਤਾਵਾਂ ਲਈ ਭਰਤੀ ਕਰਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਵਿਸ਼ੇਸ਼ਤਾਪੂਰਵਕ ਤਿਆਰ ਨਹੀਂ ਹੋਣਾ ਚਾਹੁੰਦੇ।
• ਇਹ ਖਤਰਾ ਵਧਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕੰਪਨੀ ਨੂੰ ਇੱਕੋ ਜਿਹੀਆਂ ਓਪਰੇਸ਼ਨਲ ਸਿੱਖਿਆਵਾਂ ਦੁਬਾਰਾ ਸਿੱਖਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ।

ਕਿਉਂ ਸਮਾਂਠ (ਟਾਈਮਿੰਗ) ਮਾਇਨੀ ਰਿਹਾ

ਇਹ ਵਿਚਾਰ ਉਸ ਸਮੇਂ ਉਠਿਆ ਜਦੋਂ ਮੰਗ ਹਰ ਪਾਸੇ ਵਧ ਰਹੀ ਸੀ:

• ਇੰਟਰਨੈੱਟ ਸਕੇਲ ਨੇ ਟ੍ਰੈਫਿਕ ਅਣਪਛਾਤਾ ਬਣਾ ਦਿੱਤਾ; ਪੀਕ ਲਈ ਯੋਜਨਾ ਬਣਾਉਣਾ ਮਹਿੰਗਾ ਸੀ।
• ਸਟਾਰਟਅਪਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧਣਾ ਸੀ ਬਿਨਾਂ ਡੇਟਾ ਸੈਂਟਰ ਟੀਮ ਬਣਾਉਣ ਦੇ।
• ਐਂਟਰਪ੍ਰਾਈਜ਼ IT ਨੂੰ ਸੁਰੱਖਿਆ ਅਤੇ ਕੰਪਲਾਇੰਸ ਦੇ ਨਾਲ ਤੇਜ਼ ਲਗੇ ਕੰਮ ਦੇਣ ਦਾ ਦਬਾਅ ਸੀ।

ਸਿਧਾਂਤ ਇਹ ਨਹੀਂ ਸੀ ਕਿ “ਹਰ ਚੀਜ਼ ਨੂੰ ਕਲਾਉਡ 'ਤੇ ਲੈ ਜਾਓ।” ਇਹ ਸਾਦਾ ਸੀ: ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਓਪਰੇਸ਼ਨਲ ਭਾਰ ਨੂੰ ਹਟਾਓ ਤਾਂ ਜੋ ਗਾਹਕ ਆਪਣੀ ਉਰਜਾ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਖ਼ਰਚ ਸਕਣ ਜੋ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਬਦਲਾਅ—ਬਣਾਉਣ ਵੱਲ ਵਾਪਸ ਸਮਾਂ ਅਤੇ ਧਿਆਨ—ਪਲੇਟਫਾਰਮ ਬਿਜ਼ਨਸ ਦੀ ਬੁਨਿਆਦ ਬਣ ਗਿਆ।

ਆਪਣੇ ਉਤਪਾਦ ਅਤੇ ਟੀਮ ਵਿੱਚ ਭਾਰੀ ਕੰਮ ਕਿਵੇਂ ਪਛਾਣੀਏ

ਪہਲਾ ਕਦਮ ਹੈ ਟੇਬਲ-ਸਟੇਕਸ ਕੰਮ (ਇੱਕ ਭਰੋਸੇਯੋਗ ਉਤਪਾਦ ਚਲਾਉਣ ਲਈ ਲਾਜ਼ਮੀ) ਨੂੰ ਵੱਖ ਕਰਨ ਤੋਂ ਵੱਖਤਾ (ਉਹ ਕਾਰਨ ਜੋ ਗਾਹਕ ਤੁਹਾਨੂੰ ਚੁਣਦੇ ਹਨ) ਤੋਂ ਵੱਖ ਕਰਨਾ।

ਟੇਬਲ-ਸਟੇਕਸ ਅਦੀਕ ਮਹੱਤਵਪੂਰਨ ਨਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਕਸਰ ਭਰੋਸੇ ਅਤੇ ਦਾਇਤਵ ਲਈ ਆਵਸ਼ਯਕ ਹੁੰਦੇ ਹਨ। ਪਰ ਉਹ ਆਪੇ-ਚੋਹਣ ਪ੍ਰਤੀਕਸ਼ਾ ਨੂੰ ਆਪਣਾ ਅਲੱਗ ਫੈਸਲਾ ਨਹੀਂ ਦਿੰਦੇ—ਖਾਸ ਕਰਕੇ ਜੀਹੜੇ ਮੁੱਖ ਮੁਕਾਬਲੇ ਵਾਲੇ ਵੀ ਇਸਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦੇ ਹਨ।

ਆਮ “ਭਾਰੀ ਕੰਮ” ਦੇ ਸੰਕੇਤ

ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕੀ ਕਿੰਨੇ ਕਾਮ ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਕੰਮ ਲੱਭੋ ਜੋ:

• ਜ਼ਰੂਰੀ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਅਤੇ ਗੱਲ-ਬਾਤ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ
• ਟੁੱਟਣ 'ਤੇ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਠੀਕ ਕੰਮ ਕਰਦੇ ਹਨ ਤਾਂ ਅਦ੍ਰਿਸ਼੍ਯ ਰਹਿੰਦੇ ਹਨ
• ਕੰਪਨੀਆਂ ਵਿੱਚ ਲਗਭਗ ਇੱਕੋ ਜਿਹਾ ਤਰੀਕਾ ਨਾਲ ਹੱਲ ਹੁੰਦੇ ਹਨ

ਸੋਫਟਵੇਅਰ ਟੀਮਾਂ ਵਿੱਚ ਇਹ ਅਕਸਰ ਸ਼ਾਮِل ਹੁੰਦਾ ਹੈ:

• ਸਰਵਰ ਜਾਂ ਕਲੱਸਟਰਾਂ ਦਾ ਪ੍ਰਬੰਧ
• ਸੁਰੱਖਿਆ ਪੈਚਿੰਗ ਅਤੇ ਡੀਪੇਂਡੇੰਸੀ ਅਪਡੇਟ
• ਬੈਕਅੱਪ ਅਤੇ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਡਰਿਲਾਂ
• ਆਟੋ-ਸਕੇਲਿੰਗ ਅਤੇ ਕੈਪੇਸਿਟੀ ਯੋਜਨਾ
• ਬੇਸਿਕ ਮਾਨੀਟਰੀੰਗ, ਲੌਗਿੰਗ ਅਤੇ ਅਲਰਟਿੰਗ
• ਆਨ-ਕੋਲ ਰੋਟੇਸ਼ਨਜ਼ ਆਮ ਫੇਲਿਓਵਰ ਮੋਡਸ ਲਈ

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ “ਖ਼ਰਾਬ” ਨਹੀਂ ਹੈ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਇਹ ਕੰਮ ਖੁਦ ਕਰਨ ਨਾਲ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦਾ ਮੁੱਲ ਬਣ ਰਿਹਾ ਹੈ—ਜਾਂ ਇਹ ਸਿਰਫ਼ ਦਾਖਲਾ ਦੀ ਕੀਮਤ ਹੈ।

ਸਭ ਤੋਂ ਸਧਾਰਨ ਟੈਸਟ: ਕੀ ਗਾਹਕ ਇਸ ਲਈ ਭੁਗਤਾਨ ਕਰਨਗੇ?

ਇੱਕ ਵਿਹਾਰਤਮਕ ਨਿਯਮ ਹੈ:

“ਕੀ ਗਾਹਕ ਇਸ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਭੁਗਤਾਨ ਕਰਨਗੇ, ਜਾਂ ਉਹ ਸਿਰਫ਼ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਸ਼ਾਮਿਲ ਹੋਵੇ?”

ਜੇ ਜਵਾਬ ਹੈ “ਉਹ ਸਿਰਫ਼ ਗੁੱਸੇ ਹੋਣਗੇ ਜੇ ਇਹ ਮੌਜੂਦ ਨਾ ਹੋਵੇ,” ਤਾਂ ਤੁਸੀਂ ਸੰਭਵਤ: ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ ਵੱਲ ਦੇਖ ਰਹੇ ਹੋ।

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

“ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ” ਮਾਰਕੀਟ ਵਗੈਰੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ

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

ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ ਰੋਡਮੇਪ ਅਤੇ ਓਪਸ ਕੰਮ ਨੂੰ ਇਸ ਨਜ਼ਰੀਏ ਨਾਲ ਨਕਸ਼ੇ 'ਤੇ ਲਿਆਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਕਿ ਸਮਾਂ, ਹੁਨਰ, ਅਤੇ ਧਿਆਨ ਕਿੱਥੇ ਚੱਲ ਰਹੇ ਹਨ ਸਿਰਫ਼ ਖੜੇ ਰਹਿਣ ਲਈ।

ਕਿਉਂ ਇਹ ਵਿਚਾਰ ਵੱਡਾ ਵਪਾਰਕ ਮੁੱਲ ਪੈਦਾ ਕਰਦਾ ਹੈ

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

ਆਮ ਕਰਦਿਆਂ ਸਮੱਸਿਆਵਾਂ ਪਲੇਟਫਾਰਮ ਲਈ ਇੰਧਣ ਹਨ

ਸਭ ਤੋਂ ਵਧੀਆ ਉਮੀਦਵਾਰ ਉਹ ਹਨ ਜੋ ਲਾਜ਼ਮੀ ਹਨ ਪਰ ਰਣਨੀਤੀਕ दृष्टਿਕੋण ਤੋਂ ਵੱਖ ਨਹੀਂ: ਸਰਵਰ ਪ੍ਰੋਵਾਈਜ਼ਨਿੰਗ, ਡੇਟਾਬੇਸ ਪੈਚਿੰਗ, ਕ੍ਰੈਡੈਂਸ਼ਲ ਰੋਟੇਸ਼ਨ, ਕਿਊਜ਼ ਨੂੰ ਸਕੇਲ ਕਰਨਾ, ਬੈਕਅੱਪ ਮੈਨੇਜ ਕਰਨਾ। ਹਰ ਟੀਮ ਨੂੰ ਇਹਨਾਂ ਦੀ ਲੋੜ ਹੈ, ਜ਼ਿਆਦਾਤਰ ਟੀਮ ਚਾਹੁੰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਇਨ੍ਹਾਂ ਨੂੰ ਖੁਦ ਨਾ ਬਣਾਉਣ, ਅਤੇ “ਸਹੀ ਜਵਾਬ” ਇੱਕੋ ਜਿਹਾ ਹੋਣ ਦਾ ਰੁਝਾਨ ਕੰਪਨੀਆਂ ਵਿੱਚ ਆਕਰਸ਼ਿਤ ਮੰਗ ਬਣਾਉਂਦਾ ਹੈ।

ਇਹ ਮਿਲਾਪ ਇੱਕ ਪੇਸ਼ਕਸ਼ ਬਨਾਉਂਦਾ ਹੈ: ਉੱਚ ਮੰਗ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੀਆਂ ਮੰਗਾਂ, ਅਤੇ ਸਪਸ਼ਟ ਸਫਲਤਾ ਮੈਟਰਿਕ (uptime, latency, compliance, recovery time)। ਇੱਕ ਪਲੇਟਫਾਰਮ ਇਹ ਹੱਲ ਮਿਆਰੀਕਰਨ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਇਸਨੂੰ ਬਿਹਤਰ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।

ਆਰਥਿਕਤਾਂ ਦਾ ਫਾਇਦਾ: ਫਿਕਸ ਖਰਚਾਂ ਨੂੰ ਗਾਹਕਾਂ 'ਤੇ ਵੰਡਣਾ

ਓਪਰੇਸ਼ਨਲ ਮਹਾਨਤਾ ਦੇ ਵੱਡੇ ਫਿਕਸ ਖਰਚ ਹੁੰਦੇ ਹਨ—SREs, ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਗਿਆ, ਆਨ-ਕਾਲ ਰੋਟੇਸ਼ਨ, ਆਡੀਟ, ਇੰਸੀਡੈਂਟ ਟੂਲਿੰਗ, ਅਤੇ 24/7 ਮਾਨੀਟਰੀੰਗ। ਜਦੋਂ ਹਰ ਕੰਪਨੀ ਇਹ ਸਭ ਖੁਦ ਬਣਾਉਂਦੀ ਹੈ, ਉਹ ਖਰਚ ਹਜ਼ਾਰਾਂ ਵਾਰੀ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਪਲੇਟਫਾਰਮ ਇਹਨਾਂ ਨਿਵੇਸ਼ਾਂ ਨੂੰ ਕਈ ਗਾਹਕਾਂ 'ਤੇ ਵੰਡਦਾ ਹੈ। ਗ੍ਰਹਾਕ ਪ੍ਰਤੀ ਲਾਗਤ ਘੱਟ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ ਅਪਨਾਵਟ ਵਧਦੀ ਹੈ, ਜਦਕਿ ਗੁਣਵੱਤਾ ਵੱਧ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਦਾਤਾ ਡੂੰਘੀ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ।

ਭਰੋਸੇਯੋਗਤਾ ਲੂਪ: ਵਿਸ਼ੇਸ਼ਤਾ uptime ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਸੰਚਿਤ ਕਰਦੀ ਹੈ

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

ਸੁਰੱਖਿਆ ਵੀ ਐਸੇ ਹੀ ਲਾਭਾਂਦੇਹ ਹੁੰਦੀ ਹੈ। ਸਮਰਪਿਤ ਟੀਮਾਂ ਖ਼ਤਰਾ ਮਾਡਲਿੰਗ, ਲਗਾਤਾਰ ਪੈਚਿੰਗ, ਅਤੇ ਕੰਪਲਾਇੰਸ ਕੰਟਰੋਲ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜੋ ਇੱਕ ਇਕੱਲੀ ਪ੍ਰੋਡਕਟ ਟੀਮ ਲਈ ਔਖਾ ਹੋਵੇਗਾ।

ਕੀਮਤ-ਤਾਕਤ: ਉਪਭੋਗ-ਆਧਾਰਿਤ + ਭਰੋਸਾ + ਸਵਿੱਚਿੰਗ ਲਾਗਤ (ਸਾਵਧਾਨ)

ਪਲੇਟਫਾਰਮ ਅਕਸਰ ਉਪਭੋਗ-ਆਧਾਰਿਤ ਕੀਮਤ ਰਾਹੀਂ ਕੀਮਤ ਦੀ ਤਾਕਤ ਜਮਾਉਂਦੇ ਹਨ: ਗਾਹਕ ਜੋ ਵਰਤਦੇ ਹਨ ਉਹ ਅਨੁਪਾਤੀ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, ਭਰੋਸਾ ਇੱਕ ਫਰਕ ਬਣਦਾ ਹੈ—ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਸੇਵਾ ਨੂੰ “ਡਿਫਾਲਟ ਸੇਫ” ਬਣਾਦੇਂ।

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

AWS ਨਮੂਨਾ: ਪ੍ਰਿਮਿਟਿਵ ਤੋਂ ਮੈਨੇਜਡ ਸਰਵਿਸਜ਼ ਤੱਕ

AWS ਨੇ “ਇੰਟਰਨੈੱਟ ਉੱਤੇ ਸਰਵਰ” ਪੇਸ਼ ਕਰ ਕੇ ਜਿੱਤ ਨਹੀਂ ਹਾਸਲ ਕੀਤੀ। ਇਸ ਨੇ ਹਰ ਵਾਰੀ ਕਿਸੇ ਸਖ਼ਤ ਓਪਰੇਸ਼ਨਲ ਸਮੱਸਿਆ ਨੂੰ ਲੈ ਕੇ ਉਸਨੂੰ ਨਿੱਕੇ ਬਲਾਕਾਂ ਵਿੱਚ ਤਕਸੀਮ ਕੀਤਾ, ਅਤੇ ਫਿਰ ਉਹ ਬਲਾਕ ਇਕੱਠੇ ਕਰਕੇ ਇਹਨਾਂ ਸਰਵਿਸਜ਼ 'ਚ ਰੀ-ਬੰਡਲ ਕੀਤਾ ਜਿੱਥੇ AWS ਤੁਹਾਡੇ ਲਈ day-2 ਦਾ ਕੰਮ ਚਲਾਂਦਾ ਹੈ।

ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਸੀੜੀ: primitive → service → managed service → platform

ਇਸਨੂੰ ਇੱਕ ਮਚਰੇਟੀ ਲੈਡਰ ਵਜੋਂ ਸੋਚੋ:

• Primitive: ਕੱਚੇ ਘਟਕ ਜੋ ਤੁਸੀਂ ਖੁਦ ਜੋੜ ਸਕਦੇ ਹੋ (VMs, ਡਿਸਕ, ਨੈੱਟਵਰਕ)
• Service: ਇੱਕ ਜ਼ਿਆਦਾ ਰਾਏਵਾਦੀ API ਕਿਸੇ ਸਮਰੱਥਾ ਲਈ (object storage, load balancing)
• Managed service: AWS ਸਕੇਲਿੰਗ, ਪੈਚਿੰਗ, ਬੈਕਅੱਪ ਅਤੇ ਫੇਲਿਊਰ ਰੀਕਵਰੀ ਚਲਾਉਂਦਾ ਹੈ (databases, queues)
• Platform: ਇੱਕ ਪੋਰਟਫੋਲਿਓ ਜਿੱਥੇ ਸਰਵਿਸਜ਼ ਚੰਗੀ ਤਰ੍ਹਾਂ ਰਚਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਸਾਂਝੀ identity, billing, monitoring ਅਤੇ policy ਨਾਲ

ਹਰ ਕਦਮ ਗਾਹਕ ਤੋਂ ਫੈਸਲਿਆਂ, ਰਖ-ਰਖਾਅ, ਅਤੇ “ਜੇ ਇਹ 3 ਵਜੇ ਫੇਲ ਹੋ ਗਿਆ ਤਾਂ ਕੀ?” ਦੀ ਯੋਜਨਾ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ।

AWS ਉਦਾਹਰਣ (ਧਾਰਨਾਤਮਕ ਨਕਸ਼ਾ)

AWS ਨੇ ਇਹੀ ਪੈਟਰਨ ਮੁੱਖ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ:

• Compute: ਵਿਰਚੁਅਲ ਮਸ਼ੀਨਾਂ (EC2) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਚ-ਪੱਧਰੀ ਕੰਪਿਊਟ ਉੱਤੇ ਜਿਥੇ ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਸਕੇਲਿੰਗ ਡਿਫਾਲਟ ਬਣ ਜਾਂਦੇ ਹਨ (managed container/serverless ਰੂਪ), ਗਾਹਕ ਕੋਡ ਅਤੇ ਕੈਪੇਸਿਟੀ ਇਰਾਦੇ 'ਤੇ ਧਿਆਨ ਕਰਦਾ ਹੈ, ਹੋਸਟ ਦੀ ਸੰਭਾਲ ਨਹੀਂ ਕਰਨੀ ਪੈਂਦੀ।

• Storage: ਡਿਸਕਾਂ ਅਤੇ ਫਾਇਲ ਸਿਸਟਮਾਂ ਤੋਂ object storage (S3) ਵੱਲ। ਅਭਿਵਿੱਤੀ ਇਹ ਹੋ ਗਈ ਕਿ “ਵੋਲਯੂਮ ਪ੍ਰਬੰਧ ਕਰੋ” ਦੀ ਥਾਂ “ਆਈਟਮ ਰੱਖੋ/ਲਵੋ” ਹੈ, ਜਦਕਿ durability, replication ਅਤੇ ਸਕੇਲਿੰਗ AWS ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਬਣ ਗਈ।

• Databases: VM 'ਤੇ ਡੇਟਾਬੇਸ ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ managed databases (RDS, DynamoDB) ਵੱਲ। ਬੈਕਅੱਪ, ਪੈਚਿੰਗ, ਰੀਡ ਰੀਪਲਿਕਾ ਅਤੇ ਫੇਲਓਵਰ ਇੱਕ ਕਸਟਮ ਰਨਬੁਕ ਨਾ ਰਹਿ ਕੇ ਇੱਕ ਕਨਫਿਗਰੇਸ਼ਨ ਬਣ ਜਾਂਦੇ ਹਨ।

• Messaging: ਹੱਥ-ਰੇਖੀ ਕਿਊਜ਼ ਅਤੇ ਵਰਕਰਾਂ ਤੋਂ managed messaging (SQS/SNS) ਵੱਲ। ਡਿਲਿਵਰੀ ਸੈਮੈਂਟਿਕਸ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ throughput ਟਿੂਨਿੰਗ ਸਟੈਂਡਰਡ ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਟੀਮਾਂ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਦੀ ਥਾਂ ਵਰਕਫਲੋਜ਼ ਬਣਾਉਣ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਣ।

ਕਿਉਂ ਅਬਸਟ੍ਰੈਕਸ਼ਨਜ਼ ਮਾਨਸਿਕ ਭਾਰ ਘਟਾਉਂਦੀਆਂ ਹਨ

ਮੈਨੇਜਡ ਸਰਵਿਸਜ਼ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਮਾਨਸਿਕ ਭਾਰ ਘਟਾਉਂਦੀਆਂ ਹਨ:

1. ਸੋਚਣ ਲਈ ਘੱਟ ਚੱਲਦੀਆਂ ਹਿੱਸੇ। ਤੁਹਾਡਾ ਆਰਕੀਟੈਕਚਰ ਡਾਇਗਰਾਮ “ਇੰਸਟੈਂਸ + ਸਕ੍ਰਿਪਟ + ਕ੍ਰੋਨ + ਅਲਰਟਿੰਗ + ਬੈਕਅੱਪ” ਤੋਂ “ਸਰਵਿਸ + ਸੈਟਿੰਗਸ” ਵਿੱਚ ਘੱਟ ਹੋ ਜਾਂਦਾ ਹੈ।
2. ਉਹਨਾਂ ਫੇਲ੍ਹ ਮੋਡਾਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਜਿਹਨਾਂ ਦੀ ਤੁਸੀਂ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਣੀ ਪੈਂਦੀ ਹੈ। ਤੁਸੀਂ ਅਜੇ ਵੀ ਰੇਜ਼ਿਲੀਅੰਸ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ, ਪਰ ਪੈਚਿੰਗ, ਕਲੱਸਟਰਿੰਗ ਅਤੇ ਰੁਟੀਨ ਰਿਕਵਰੀ ਦੀ ਮਕੈਨਿਕਸ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਹੁੰਦੀ।

ਨਤੀਜਾ ਤੇਜ਼ੀ ਨਾਲ ਓਨਬੋਰਡਿੰਗ, ਘੱਟ bespoke ਰਨਬੁਕਸ, ਅਤੇ ਟੀਮਾਂ ਵਿੱਚ ਹੋਰ ਲਗਾਤਾਰ ਓਪਰੇਸ਼ਨ ਹੁੰਦੇ ਹਨ।

ਲੈਣਾ-ਦੇਣਾ ਚੈੱਕਲਿਸਟ (ਆਪਣੇ ਉਤਪਾਦ ਵਿੱਚ ਦੁਹਰਾਓ)

• ਗਾਹਕ ਕੀ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਜ਼ਰੂਰੀ ਪਰ ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਹੈ?
• ਕੀ ਤੁਸੀਂ ਉਹਨਾਂ ਦੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਰਨਬੁਕਸ ਨੂੰ ਇੱਕ ਹੀ, ਸਥਿਰ API ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ?
• ਕਿਹੜੇ ਕੰਮ ਤੁਸੀਂ ਡਿਫਾਲਟ (ਬੈਕਅੱਪ, ਸਕੇਲਿੰਗ, ਅੱਪਗਰੇਡ) ਬਣਾਕੇ ਵਿਕਲਪ ਦੀ ਥਾਂ ਕਰ ਸਕਦੇ ਹੋ?
• ਕੀ “ਤੇਜ਼ ਕੰਢੇ” ਸਮਰੱਥ ਸੀਮਾ ਅਤੇ ਗਾਰਡਰੇਲ ਦੇ ਪਿੱਛੇ ਮੋੜ ਦਿੱਤੇ ਗਏ ਹਨ?
• ਕੀ ਕਈ ਟੀਮ ਬਿਨਾਂ ਮਾਹਿਰ ਗਿਆਨ ਦੇ ਇਸਨੂੰ ਮੁੜ ਵਰਤ ਸਕਦੀਆਂ ਹਨ?
• ਕੀ ਇਹ ਤੁਹਾਡੇ ਸਿਸਟਮ (identity, monitoring, billing, policies) ਨਾਲ ਰਚਾਉਂਦਾ ਹੈ?

ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਉਤਪਾਦ ਵਜੋਂ ਪੈਕ ਕਰਨਾ

AWS ਨੂੰ ਪੜ੍ਹਨ ਦਾ ਇੱਕ ਲਾਭਦਾਇਕ ਢੰਗ ਇਹ ਹੈ: ਇਹ ਸਿਰਫ਼ ਟੈਕਨੋਲੋਜੀ ਨਹੀਂ ਵੇਚਦਾ, ਇਹ ਓਪਰੇਸ਼ਨਜ਼ ਵੇਚਦਾ ਹੈ। “ਉਤਪਾਦ” ਸਿਰਫ਼ ਇੱਕ API endpoint ਨਹੀਂ—ਇਹ ਉਸ ਸਮੇਤ ਸਭ ਕੁਝ ਹੈ ਜੋ ਉਸ ਸਮਰੱਥਾ ਨੂੰ ਸੁਰੱਖਿਅਤ, ਪੇਸ਼ਗੋਈਯੋਗ ਅਤੇ ਸਕੇਲ 'ਤੇ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦਾ ਹੈ।

APIs vs. ਸੈੱਲਫ-ਸਰਵਿਸ vs. ਪੂਰਾ ਮੈਨੇਜਮੈਂਟ

ਇੱਕ API ਤੁਹਾਨੂੰ ਬਿਲਡਿੰਗ ਬਲਾਕ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਰਿਸੋਰਸ ਪ੍ਰੋਵਾਇਜ਼ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਅਜੇ ਵੀ ਗਾਰਡਰੇਲ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ, ਫੇਲਿਅਰ ਮਾਨੀਟਰ ਕਰਦੇ ਹੋ, ਅੱਪਗਰੇਡ ਸੰਭਾਲਦੇ ਹੋ, ਅਤੇ “ਕਿਸਨੇ ਕੀ ਬਦਲਿਆ?” ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੁੰਦਾ ਹੈ।

ਸੈੱਲਫ-ਸਰਵਿਸ ਇੱਕ ਲੇਅਰ ਜੁੜਦਾ ਹੈ ਜਿਸ ਨੂੰ ਗਾਹਕ ਟਿਕਟ ਭਰੇ ਬਿਨਾਂ ਵਰਤ ਸਕਦੇ ਹਨ: ਕਨਸੋਲ, ਟੈਮਪਲੇਟ, ਸਮਝਦਾਰ ਡਿਫਾਲਟ, ਅਤੇ ਆਟੋਮੈਟਿਕ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ। ਗਾਹਕ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੇ day-2 ਕੰਮਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਘੱਟ ਮੈਨੁਅਲ ਹੁੰਦਾ ਹੈ।

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

ਉਹ “ਉਦਾਸੀ” ਫੀਚਰ ਜਿਨ੍ਹਾਂ ਦਾ ਗਾਹਕ ਨਿਰਭਰ ਰਹਿੰਦਾ ਹੈ

ਲੋਕ ਦਿਨ-ਰੋਜ਼ਾਨਾ ਜੋ ਯੋਗਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਉਹ ਅਕਸਰ ਚਮਕਦਾਰ ਨਹੀਂ ਹੁੰਦੀਆਂ:

• IAM ਅਤੇ permissions: ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਐਕਸੈੱਸ ਕਿਵੇਂ ਆਡਿਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
• ਬਿਲਿੰਗ ਅਤੇ ਲਾਗਤ ਦਿੱਖ: ਬਜਟ, ਇਨਵਾਇਸ, ਟੈਗਸ, ਅਤੇ ਅਲਰਟ
• ਕੋਟਾ ਅਤੇ ਰੇਟ ਲਿਮਿਟਸ: ਹਾਦਸਿਆਂ ਨੂੰ ਰੋਕਣ ਵਾਲੇ ਸੁਰੱਖਿਆ ਪ੍ਰੋਟੈਕਸ਼ਨ ਅਤੇ ਅਸਪੱਸ਼ਟ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰਨ ਵਾਲੇ

ਇਹ ਸਾਈਡ-ਕੁਐਸਟ ਨਹੀਂ ਹਨ। ਇਹ ਉਹ ਵਾਅਦਾ ਹਨ ਜੋ ਗਾਹਕ ਖਰੀਦਦੇ ਹਨ।

ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਪਹਿਲ-ਕ੍ਰਮ ਫੀਚਰ ਬਣਾਉਣਾ

ਇੱਕ ਮੈਨੇਜਡ ਸਰਵਿਸ ਨੂੰ “ਅਸਲ” ਮਹਿਸੂਸ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਇਸ ਦੇ ਆਸ-ਪਾਸ ਦਾ ਓਪਰੇਸ਼ਨਲ ਪੈਕੇਜ ਹੈ: ਸਾਫ਼ ਦਸਤਾਵੇਜ਼, ਪੇਸ਼ਗੀ ਤੌਰ 'ਤੇ ਉਮੀਦ ਕੀਤੇ ਸਹਾਇਤਾ ਚੈਨਲ, ਅਤੇ ਸਪਸ਼ਟ ਸਰਵਿਸ ਸੀਮਾਵਾਂ। ਚੰਗਾ ਡੌਕਸ ਸਪੋਰਟ ਲੋਡ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਸ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਇਹ ਗਾਹਕਾਂ ਦੀ ਚਿੰਤਾ ਘਟਾਉਂਦਾ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਸੀਮਾਵਾਂ ਅਤੇ ਕੋਟਾ ਪ੍ਰਕਿਰਿਆਆਂ ਚੁੱਕਸੇ ਤੌਰ 'ਤੇ ਹੈਰਾਨੀਆਂ ਨੂੰ ਜਾਣੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।

ਜਦੋਂ ਤੁਸੀਂ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਜੋਂ ਪੈਕੇਜ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਸਿਰਫ਼ ਫੀਚਰ ਨਹੀਂ ਭੇਜ ਰਹੇ—ਤੁਸੀਂ ਭਰੋਸਾ ਭੇਜ ਰਹੇ ਹੋ।

ਉਹ ਆਰਗਨਾਈਜੇਸ਼ਨਲ ਡਿਜ਼ਾਈਨ ਜੋ ਪਲੇਟਫਾਰਮ ਕੰਮ ਬਣਾਉਂਦਾ ਹੈ

ਇੱਕ ਪਲੇਟਫਾਰਮ ਦੀ ਸਫਲਤਾ ਆਰਕੀਟੈਕਚਰ ਡਾਇਗਰਾਮ ਤੋਂ ਘੱਟ ਅਤੇ ਆਰਗ ਡਿਜ਼ਾਈਨ ਤੋਂ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜੇ ਟੀਮਾਂ ਕੋਲ ਸਪਸ਼ਟ ਗਾਹਕ, ਪ੍ਰੇਰਣਾ ਅਤੇ ਫੀਡਬੈਕ ਲੂਪ ਨਹੀਂ ਹਨ, ਤਾਂ “ਪਲੇਟਫਾਰਮ” ਰਾਇਆਂ ਦੇ ਬੈਕਲੌਗ ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਵੇਗਾ।

ਆਂਤਰਿਕ ਟੀਮਾਂ ਪਹਿਲੇ ਗਾਹਕ ਬਣਨ (dogfooding)

ਪਲੇਟਫਾਰਮ ਨੂੰ ਸਚਾਈ ਵਿੱਚ ਰੱਖਣ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਇਹ ਹੈ ਕਿ ਆਂਤਰਿਕ ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਪਹਿਲੀਆਂ—ਅਤੇ ਸਭ ਤੋਂ ਤੇਜ਼—ਗਾਹਕ ਬਣਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ:

• ਪਲੇਟਫਾਰਮ ਟੀਮਾਂ ਉਦੋਂ API ਅਤੇ ਡੌਕਸ ਰਾਹੀਂ ਆਂਤਰਿਕ ਟੀਮਾਂ ਨੂੰ ਉਤਾਰਦੀਆਂ ਹਨ ਜਿਹੜੇ ਬਾਹਰੀ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਮਿਲਦੇ
• ਅਪਨਾਉਣਾ ਯੂਜ਼ਫੁਲਨੈਸ ਰਾਹੀਂ ਕਮਾਇਆ ਜਾਂਦਾ ਹੈ, ਨਾਹ ਕਿ ਨੀਤੀ ਰਾਹੀਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ
• ਸਹਾਇਤਾ ਟਿਕਟਸ, ਇਨਸੀਡੈਂਟ ਸਮੀਖਿਆਵਾਂ ਅਤੇ ਰੋਡਮੇਪ ਫੈਸਲੇ ਆਂਤਰਿਕ ਟੀਮਾਂ ਨੂੰ ਅਸਲੀ ਗਾਹਕਾਂ ਵਾਂਗ ਵਰਤਦੇ ਹਨ, ਸਪਸ਼ਟ SLA ਦੇ ਨਾਲ

dogfooding ਸੁਧਾਰ ਲਈ ਜ਼ਰੂਰੀ ਹੈ: ਜੇ ਤੁਹਾਡੀ ਆਪਣੀ ਟੀਮ ਪਲੇਟਫਾਰਮ ਨੂੰ ਟਾਲਦੀ ਹੈ, ਬਾਹਰੀ ਗਾਹਕ ਵੀ ਤਦ ਤੋਮੁੜ੍ਹ ਦੇਖਣਗੇ।

ਕੇਂਦਰੀ ਵਿਰੁੱਧ ਫੈਡਰੇਟਡ ਪਲੇਟਫਾਰਮ ਮਾਡਲ

ਦੋ ਆਰਗ ਮਾਡਲ ਆਮਤੌਰ 'ਤੇ ਮਿਲਦੇ ਹਨ:

ਕੇਂਦਰੀ ਪਲੇਟਫਾਰਮ ਟੀਮ: ਇੱਕ ਟੀਮ ਮੁੱਖ ਬਿਲਡਿੰਗ ਬਲਾਕ (CI/CD, identity, observability, runtime, data primitives) ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦੀ ਹੈ। ਇਹ ਅਨੁਕੂਲਤਾ ਅਤੇ ਆਰਥਿਕ ਹਿੱਸੇ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਜ਼ਿਆਦਾ ਬੋਤਲਨੇਕ ਬਣ ਸਕਦੀ ਹੈ।

ਫੈਡਰੇਟਡ ਮਾਡਲ: ਇੱਕ ਛੋਟੀ ਕੇਂਦਰੀ ਟੀਮ ਮਿਆਰ ਅਤੇ ਸਾਂਝੇ primitive ਸੈੱਟ ਕਰਦੀ ਹੈ, ਜਦਕਿ ਡੋਮੇਨ ਟੀਮਾਂ "ਪਲੇਟਫਾਰਮ ਸਲਾਈਸ" ਦੀ ਮਾਲਕੀ ਲੈਂਦੀਆਂ ਹਨ (ਉਦਾਹਰਣ ਲਈ ਡੇਟਾ ਪਲੇਟਫਾਰਮ, ML ਪਲੇਟਫਾਰਮ)। ਇਹ ਤੇਜ਼ੀ ਅਤੇ ਡੋਮੇਨ-ਫਿੱਟ ਲਈ ਚੰਗਾ ਹੈ, ਪਰ ਫਰਗਮੈਂਟੇਸ਼ਨ ਤੋਂ بچਣ ਲਈ ਮਜ਼ਬੂਤ ਗਵਰਨੈਂਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਮਹੱਤਵਪੂਰਨ ਮੈਟਰਿਕਸ (ਅਤੇ ਪਲੇਟਫਾਰਮ ਪਿੱਟਫਾਲ)

ਲਾਹੇਦਾਰ ਪਲੇਟਫਾਰਮ ਮੈਟਰਿਕਸ ਐਕਟਿਵਿਟੀ ਨਹੀਂ ਬਲਕਿ ਨਤੀਜੇ ਹਨ:

• ਚਿੱਤਰ ਤੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਲੀਡ ਟਾਈਮ (ਟੀਮ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੀ ਹੈ)
• ਪਲੇਟਫਾਰਮ ਸਰਵਿਸਜ਼ ਦੀ ਉਪਲਬਧਤਾ ਅਤੇ ਇਨਸੀਡੈਂਟ ਦਰ
• ਵਰਕਲੋਡ ਪ੍ਰਤੀ ਲਾਗਤ (ਯੂਨਿਟ ਅਰਥਸ਼ਾਸਤਰ, ਕੁੱਲ ਖਰਚ ਨਹੀਂ)

ਆਮ ਪਿੱਟਫਾਲ ਵਿੱਚ ਗਲਤ ਪ੍ਰੇਰਣਾ (ਪਲੇਟਫਾਰਮ ਨੂੰ ਫੀਚਰ ਗਿਣਤੀ 'ਤੇ ਅੰਕਣ), ਓਵਰ-ਡਿਜ਼ਾਈਨ (ਕਲਪਿਤ ਸਕੇਲ ਲਈ ਬਣਾਉਣਾ), ਅਤੇ ਸਫਲਤਾ ਨੂੰ ਮੰਡੇਟ ਬਜਾਏ ਸਵੈਖਚਾਰਿਕ ਵਰਤੋਂ ਦੇ ਨਾਲ ਮੋਜੂਦ ਅੰਕਣਾ ਸ਼ਾਮਿਲ ਹਨ।

ਪਲੇਟਫਾਰਮ ਵਾਧੇ ਪਿੱਛੇ ਕੰਪਾਉਂਡਿੰਗ ਫਲਾਈਵ੍ਹੀਲ

ਪਲੇਟਫਾਰਮ ਇਕ-ਵਾਰਗੀ ਉਤਪਾਦਾਂ ਤੋਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਧਦੇ ਹਨ। ਉਹਨਾਂ ਦਾ ਫਾਇਦਾ ਸਿਰਫ਼ “ਅਧਿਕ ਫੀਚਰ” ਨਹੀਂ—ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਹੈ ਜਿੱਥੇ ਹਰ ਨਵਾੰ ਗਾਹਕ ਪਲੇਟਫਾਰਮ ਨੂੰ ਚਲਾਉਣਾ, ਸੁਧਾਰਨਾ, ਅਤੇ ਨਾ-ਨਜਰਅੰਦਾਜ਼ ਕਰਨ ਲਾਇਕ ਬਣਾਉਂਦਾ ਹੈ।

ਫਲਾਈਵ੍ਹੀਲ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ

ਵਧੇਰੇ ਗਾਹਕ → ਵਧੇਰਾ ਰੀਅਲ-ਵਰਲਡ ਉਪਯੋਗ ਡਾਟਾ → ਕਿਹੜਾ ਟੁੱਟਦਾ ਹੈ, ਕੀ ਮੰਦ ਹੈ, ਕੀ ਗੁੰਭਿਰ ਹੈ ਇਸ ਬਾਰੇ ਸਾਫ਼ ਪੈਟਰਨ → ਵਧੀਆ ਡਿਫਾਲਟ ਅਤੇ ਆਟੋਮੇਸ਼ਨ → ਹਰ ਕਿਸੇ ਲਈ ਬੇਹਤਰ ਸੇਵਾ → ਹੋਰ ਗਾਹਕ।

AWS ਇਸ ਤੋਂ ਲਾਭਾਨਵਿਤ ਰਹੀ ਕਿਉਂਕਿ ਮੈਨੇਜਡ ਸਰਵਿਸਜ਼ ਓਪਰੇਸ਼ਨਲ ਟੌਇਲ ਨੂੰ ਸਾਂਝੇ, ਦੁਹਰਾਏ ਯੋਗ ਸਮਰੱਥਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜਦੋੲਂ ਇੱਕੋ ਹੀ ਸਮੱਸਿਆ ਹਜ਼ਾਰਾਂ ਟੀਮਾਂ 'ਚ ਦੋਹਰਾਈ ਜਾਵੇ (ਮਾਨੀਟਰੀੰਗ, ਪੈਚਿੰਗ, ਸਕੇਲਿੰਗ, ਬੈਕਅੱਪ), ਪ੍ਰਦਾਤਾ ਉਸਨੂੰ ਇੱਕ ਵਾਰੀ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸੁਧਾਰ ਸਾਰੇ ਗਾਹਕਾਂ ਨੂੰ ਵੰਡ ਸਕਦਾ ਹੈ।

ਕਿਉਂ ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਨਵੀਨਤਾ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ

ਸਟੈਂਡਰਡਾਈਜ਼ੇਸ਼ਨ ਅਕਸਰ “ਘੱਟ ਲਚੀਲਾਪਣ” ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਇਹ ਇੱਕ ਗਤੀ ਗੁਣਾ ਹੈ। ਜਦੋਂ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਅਤੇ ਓਪਰੇਸ਼ਨਸconsistent—ਇੱਕ API ਸੈੱਟ, ਇੱਕ identity ਢੰਗ, ਇੱਕ ਤਰੀਕਾ ਪ੍ਰਣਾਲੀ—ਬਿਲਡਰ ਸਿਤੰਭਾਂ ਨੂੰ ਮੁੜ-ਰਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ।

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

ਲੰਬੇ ਸਮੇਂ ਦੀ ਸ਼ਰਤ: ਸਕੇਲ 'ਤੇ ਕੰਪਾਉਂਡਿੰਗ

ਛੋਟੇ ਸੁਧਾਰ ਜਦੋਂ ਮਿਲੀਅਨਾਂ ਰੀਕਵੇਸਟਾਂ ਅਤੇ ਹਜ਼ਾਰਾਂ ਗਾਹਕਾਂ 'ਤੇ ਲਾਗੂ ਹੋਂਦੇ ਹਨ ਤਾਂ ਸੰਚਿਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਘਟੇ ਭਾਗ ਦੀ ਘਟਾਓ, ਇੱਕ ਚੰਗਾ ਆਟੋ-ਸਕੇਲਿੰਗ ਐਲਗੋਰਿਦਮ, ਜਾਂ ਸਪਸ਼ਟ ਡਿਫਾਲਟ ਕਨਫਿਗਰੇਸ਼ਨ ਇਕ ਕੰਪਨੀ ਦੀ ਸੇਵਾ ਦੀ ਬੇਸਲਾਈਨ ਨੂੰ ਅਪਗ੍ਰੇਡ ਕਰ ਦਿੰਦਾ ਹੈ।

ਭਾਰੀ ਕੰਮ ਹਟਾਉਣਾ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪਿੰਗ ਵਿੱਚ ਕਿਵੇਂ ਤਬਦੀਲ ਹੁੰਦਾ ਹੈ

ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ ਹਟਾਉਣਾ ਸਿਰਫ ਘੰਟਿਆਂ ਨੂੰ ਬਚਾਉਂਦਾ ਨਹੀਂ—ਇਹ ਟੀਮਾਂ ਦੇ ਵਿਹਾਰ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ “ਲਾਈਟਾਂ ਬਚਾਉਣ” ਵਾਲਾ ਕੰਮ ਘਟਦਾ ਹੈ, ਰੋਡਮੇਪ ਰੱਖ-ਰੱਖਾਅ ਦੇ ਕੰਮਾਂ (ਸਰਵਰ ਪੈਚਿੰਗ, ਕੀ ਰੋਟੇਸ਼ਨ, 큐ਜ਼ ਦੀ ਬੇਬਿਸਿਟਿੰਗ) ਨਾਲ ਭਰਪੂਰ ਰਹਿਣ ਦੇ ਬਜਾਏ ਨਵੇਂ ਫੀਚਰ, ਚੰਗੀ UX, ਅਤੇ ਹੋਰ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਦੂਜੇ-ਕ੍ਰਮ ਦੇ ਪ੍ਰਭਾਵ ਜੋ ਸੰਚਿਤ ਹੁੰਦੇ ਹਨ

ਘੱਟ ਟੌਇਲ ਇੱਕ ਲੜੀਵਾਰ ਪ੍ਰਭਾਵ ਪੈਦਾ ਕਰਦਾ ਹੈ:

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

ਗਤੀ vs. ਝੜਪ: ਸ਼ਿਪਿੰਗ vs. ਫਾਇਰਫਾਈਟਿੰਗ

ਅਸਲੀ ਗਤੀ ਇੱਕ ਲਗਾਤਾਰ ਰਿਥਮ ਹੈ ਛੋਟੇ, ਪੇਸ਼ਗੀ-ਜਾਣੇ-ਯੋਗ ਰਿਲੀਜ਼ਾਂ ਦੀ। ਝੜਪ ਉਹ ਗਤੀ ਹੈ ਜੋ ਤਰੱਕੀ ਨਹੀਂ ਲਿਆਉਂਦੀ: ਤੁਰੰਤ ਬੱਗ ਫਿਕਸ, ਐਮਰਜੈਂਸੀ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਕੰਮ, ਅਤੇ “ਤੁਰੰਤ” ਬਦਲਾਅ ਜੋ ਹੋਰ ਕਰਜ਼ੇ ਬਣਾਉਂਦੇ ਹਨ।

ਭਾਰੀ ਕੰਮ ਹਟਾਉਣਾ ਝੜਪ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹ ਸਾਰੇ ਵਰਗ ਦੇ ਕੰਮ ਹਟਾਉਂਦਾ ਹੈ ਜੋ ਯੋਜਿਤ ਡਿਲਿਵਰੀ ਨੂੰ ਦਰਮਿਆਨੀ ਰੋਕਦੇ ਹਨ। ਜੇਕਰ ਇੱਕ ਟੀਮ ਪਹਿਲਾਂ 40% ਸਮਾਂ ਰੀਐਕਟ ਕਰਕੇ ਬਿਤਾਂਦੀ ਸੀ, ਉਹ ਸਮਰੱਥਾ ਹੁਣ ਫੀਚਰ-ਵਰਕ ਵਿੱਚ ਮੁੜ ਚਲੇ ਜਾਣ ਲਈ ਉਪਲਬਧ ਹੋ ਜਾਂਦੀ ਹੈ।

ਪ੍ਰਾਇਕਟਿਕ SaaS ਉਦਾਹਰਣ

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

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

ਅਬਜ਼ਰਵੇਬਿਲਟੀ: ਘਰੇਲੂ ਡੈਸ਼ਬੋਰਡਾਂ ਦੀ ਥਾਂ ਇੱਕ ਮੈਨੇਜਡ ਲੌਗਿੰਗ/ਮੈਟ੍ਰਿਕਸ/ਟ੍ਰੇਸਿੰਗ ਸਟੈਕ 'ਤੇ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰੋ। ਨਤੀਜਾ: ਤੇਜ਼ ਡੀਬੱਗਿੰਗ, ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਸਪਸ਼ਟ ਮਾਲਿਕੀਅਤ, ਅਤੇ ਵੱਧ ਭਰੋਸੇ ਨਾਲ ਵੱਧ ਰਿਲੀਜ਼।

ਨਮੂਨਾ ਸਧਾਰਨ ਹੈ: ਜਦੋਂ ਓਪਰੇਸ਼ਨਜ਼ ਇੱਕ ਖਪਤ-ਯੋਗ ਉਤਪਾਦ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਵਾਪਸ ਉਸ ਬਣਾਉਣ 'ਤੇ ਆ ਜਾਂਦਾ ਹੈ ਜਿਸ ਲਈ ਗਾਹਕ ਅਸਲ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ।

ਟਰੇਡਆਫ: ਲੌਕ-ਇਨ, ਕੰਟਰੋਲ, ਅਤੇ ਲਾਗਤ

ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ ਹਟਾਉਣਾ ਮੁਫ਼ਤ ਦੋਪਿਹਰ ਨਹੀਂ ਹੈ। AWS-ਸ਼ੈਲੀ ਦੀਆਂ ਮੈਨੇਜਡ ਸਰਵਿਸਜ਼ ਅਕਸਰ ਦਿਨ-ਦਿਨ ਦੀ ਮਹਨਤ ਦੇ ਬਦਲੇ ਨਜ਼ਦੀਕੀ ਕੁਨੈਕਸ਼ਨ, ਘੱਟ ਨਾਬ-ਨਕਸ਼ੇ, ਅਤੇ ਅਚਾਨਕ ਬਿੱਲਾਂ ਦਾ ਵਪਾਰ ਕਰਦੀਆਂ ਹਨ।

ਤਿੰਨ ਵੱਡੇ ਟਰੇਡਆਫ

ਵੈਨਡਰ ਲੌਕ-ਇਨ। ਜਿੰਨਾਂ ਵਧੇਰੇ ਤੁਸੀਂ proprietary APIs (queues, IAM policies, workflow engines) 'ਤੇ ਨਿਰਭਰ ਹੋਵੋਗੇ, ਉਨਾਂ ਵਧੇਰੇ ਮੂਵ ਕਰਨਾ ਔਖਾ ਹੋਵੇਗਾ। ਲੌਕ-ਇਨ ਹਮੇਸ਼ਾ ਬੁਰਾ ਨਹੀਂ—ਇਹ ਤੇਜ਼ੀ ਦੀ ਕੀਮਤ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਸੋਚ-ਵਿਚਾਰ ਕੇ ਚੁਣੋ।

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

ਲਾਗਤ ਦੇ ਹੈਰਾਨੀਆਂ। ਖਪਤ-ਆਧਾਰਿਤ ਕੀਮਤ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਹ ਵਿਕਾਸ, ਚੈਟੀ ਆਰਕੀਟੈਕਚਰ, ਅਤੇ “ਸੈਟ-ਅੰਡ-ਭੁੱਲ ਜਾਓ” ਡਿਫਾਲਟ ਲਈ ਸਜ਼ਾ ਦੇ ਸਕਦੀ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਸਲੇਟੀ ਬਾਅਦ ਹੀ ਲਾਗਤਾਂ ਨੂੰ ਪਤਾ ਲਗਦੀਆਂ ਹਨ।

ਕਦੋਂ ਬਣਾਉਣਾ ਵਾਜਬ ਹੈ

ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਅਨੋਖੇ ਲੋੜਾਂ ਹਨ (ਖਾਸ ਲੈਟੈਂਸੀ, ਵਿਲੱਖਣ ਡਾਟਾ ਮਾਡਲ), ਵਡੇ ਸਕੇਲ ਜਿਸ 'ਤੇ ਯੂਨਿਟ ਅਰਥਸ਼ਾਸਤਰ ਵੱਕਰੀ ਹੋ ਜਾਵੇ, ਜਾਂ ਕੰਪਲਾਇੰਸ/ਡੇਟਾ ਰਿਹਾਇਸ਼ੀ ਸੀਮਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮੈਨੇਜਡ ਸਰਵਿਸਜ਼ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ—ਤਾਂ ਬਿਲਡ/ਸੈਲਫ-ਹੋਸਟ ਕਰਨਾ ਸਹੀ ਫੈਸਲਾ ਹੋ ਸਕਦਾ ਹੈ।

ਗਾਰਡਰੇਲ ਜੋ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਰੱਖਦੀਆਂ ਹਨ ਬਿਨਾਂ ਫਸਾਏ

ਸੇਵਾ ਬ੍ਰਾਹਾ: ਪ੍ਰਦਾਤਾ ਕਾਲਾਂ ਨੂੰ ਆਪਣੇ ਇੰਟਰਫੇਸ ਪਿੱਛੇ ਰੈਪ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਨੂੰ ਬਦਲ ਸਕੋ।

ਪੋਰਟੇਬਿਲਟੀ ਯੋਜਨਾ: ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਸਭ ਤੋਂ ਔਖਾ ਕੀ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਹੋਵੇਗਾ, ਅਤੇ ਇੱਕ “ਘਟੋ-ਵੀਐਮ ਐਕਜ਼ਿਟ” ਰਸਤਾ ਰੱਖੋ (ਭਾਵੇਂ ਉਹ ਧੀਮਾ ਹੋਵੇ)।

ਲਾਗਤ ਮਾਨੀਟਰਿੰਗ ਜਲਦੀ ਸ਼ੁਰੂ ਕਰੋ: ਬਜਟ, ਅਲਰਟ, ਟੈਗਿੰਗ, ਅਤੇ ਮੁੱਖ ਖਰਚਕਾਰਾਂ ਦੀ ਨਿਯਮਤ ਸਮੀਖਿਆ।

ਨਕਲ ਕਰਨ ਯੋਗ ਫੈਸਲਾ ਮੈਟ੍ਰਿਕਸ

ਕਿਸੇ ਵੀ ਸੋਫਟਵੇਅਰ ਬਿਜ਼ਨਸ ਵਿੱਚ ਪੈਟਰਨ ਲਾਗੂ ਕਰਨ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਫਰੇਮਵਰਕ

ਤੁਹਾਨੂੰ ਹਾਇਪਰਸਕੇਲ ਕਲਾਉਡ ਚਲਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ “ਅਣ-ਪ੍ਰਤੀਭਾਸ਼ੀ ਭਾਰੀ ਕੰਮ” ਪਲੇਬੁੱਕ ਵਰਤੋਂ। ਕੋਈ ਵੀ ਸੋਫਟਵੇਅਰ ਟੀਮ—SaaS, ਆਂਤਰਿਕ ਪਲੇਟਫਾਰਮ, ਡੇਟਾ ਉਤਪਾਦ, ਇੱਥੇ ਤੱਕ ਕਿ ਸਪੋਰਟ-ਭਾਰੀਆ ਟੂਲ—ਦੋਹਰਾਏ ਜਾਣ ਵਾਲਾ ਕੰਮ ਰੱਖਦੀ ਹੈ ਜੋ ਮਹਿੰਗਾ, ਗਲਤ-ਪ੍ਰਵਣ, ਅਤੇ ਸੱਚਮੁੱਚ ਵੱਖਰਾ ਨਹੀਂ ਹੁੰਦਾ।

ਇਕ ਕਦਮ-ਬ-ਕਦਮ ਵਿਧੀ (ਟੌਇਲ ਤੋਂ ਉਤਪਾਦ ਤੱਕ)

1. ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੀ ਟੌਇਲ ਦੀ ਸੂਚੀ ਬਣਾਓ: ਦੋਹਰਾਏ ਜਾਂਦੇ ਕੰਮ ਲਿਖੋ ਜਿਹੜੇ ਚੀਜ਼ਾਂ ਚਲਾਈ ਰੱਖਣ ਲਈ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ—ਮੈਨੁਅਲ ਡਿਪਲੋਇਮੈਂਟ, ਟਿਕਟ ਟਰਾਇਏਜ, ਡੇਟਾ ਬੈਕਫਿਲ, ਐਕਸੈੱਸ ਅਨੁਰੋਧ, ਇਨਸੀਡੈਂਟ ਹੈਂਡਓਵਰ, ਨਾਜੁਕ ਸਕ੍ਰਿਪਟਸ, “ਟ੍ਰਾਇਬਲ ਨੌलेज” ਚੈੱਕਲਿਸਟ।

2. ਇਸ ਦਾ ਮਾਤਰਾ ਕਰੋ: ਹਰ আইਟਮ ਲਈ ਅੰਦੇਜਾ ਲਗਾਓ—ਫ੍ਰੀਕਵੈਂਸੀ, ਸਮਾਂ ਖਪਤ, ਅਤੇ ਫੇਲ੍ਹ ਦੀ ਲੱਗਤ। ਇੱਕ ਸਧਾਰਨ ਸਕੋਰ ਵਰਕ: ਘੰਟੇ/ਹਫ਼ਤਾ + ਗਲਤੀਆਂ ਦੀ ਗੰਭੀਰਤਾ + ਪ੍ਰਭਾਵਿਤ ਟੀਮਾਂ ਦੀ ਗਿਣਤੀ। ਇਹ ਲਿਊਦਾਂ ਨੂੰ ਇੱਕ ਰੈਂਕਿੰਗ ਬੈਕਲੌਗ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

3. ਵਰਕਫਲੋ ਨੂੰ ਮਿਆਰੀਕਰਨ ਕਰੋ: ਆਟੋਮੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ “ਇੱਕ ਸਭ ਤੋਂ ਚੰਗਾ ਤਰੀਕਾ” ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਇੱਕ ਟੈਮਪਲੇਟ, ਗੋਲਡਨ ਪਾਥ, ਜਾਂ ਸਮਰੱਥ ਕੀਤਾ ਹੋਇਆ ਚੋਣ ਸੈੱਟ ਬਣਾਓ। ਵੈਰੀਏਸ਼ਨ ਘੱਟ ਕਰਨਾ ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ ਹੁੰਦੀ ਹੈ।

4. ਆਟੋਮੇਟ ਅਤੇ ਪੈਕੇਜ ਕਰੋ: ਸੈਲਫ-ਸਰਵ ਹੋਮਗੋਲੀ ਟੂਲਿੰਗ (APIs, UI, runbooks-as-code) ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਉਤਪਾਦ ਵਾਂਗੋਂ ਟ੍ਰੀਟ ਕਰੋ: ਸਪਸ਼ਟ ਮਾਲਕੀ, ਵਰਜ਼ਨਿੰਗ, ਡੌਕਸ, ਅਤੇ ਸਹਾਇਤਾ ਮਾਡਲ।

ਇਸ ਤਰੀਕੇ ਦਾ ਇੱਕ ਆਧੁਨਿਕ ਰੂਪ “vibe-coding” ਪਲੇਟਫਾਰਮ ਹਨ ਜੋ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਸਕੈਫੋਲਡਿੰਗ ਅਤੇ day-1 ਸੈਟਅੱਪ ਨੂੰ ਇੱਕ ਗਾਈਡਡ ਵਰਕਫਲੋ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਉਦਾਹਰਣ ਵਜੋਂ, Koder.ai ਟੀਮਾਂ ਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਵੈਬ, ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ (React ਵੈਬ ਲਈ, Go + PostgreSQL ਬੈਕਐਂਡ ਲਈ, Flutter ਮੋਬਾਈਲ ਲਈ) ਅਤੇ ਫਿਰ ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਜਾਂ ਡਿਪਲੋਇ/ਹੋਸਟ ਕਰਨ ਦੀ ਸੁਵਿਧਾ ਦਿੰਦਾ—ਉਹ ਸਮਾਂ ਕਦਰਯੋਗ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਰੋਕਟਹੀਨਤਾ ਪਹਿਲੀ ਸਥਿਰ ਬੇਸਲਾਈਨ ਤੱਕ ਪਹੁੰਚਣ 'ਚ ਹੈ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਇੱਕੋ ਜਿਹਾ ਪ੍ਰੋਜੈਕਟ ਵਾਇਰਿੰਗ ਦੁਹਰਾਏ।

ਇੱਕ ਵਰਕਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ (ਅਤੇ ਲੂਪ ਸਾਬਤ ਕਰੋ)

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

ਲੜੀ-ਬੱਧੀ: ਪਹਿਲਾਂ ਕੀ ਕਰੋ

• ਭਰੋਸੇਯੋਗਤਾ ਪਹਿਲਾਂ: ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੁਚਿਤ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਓ।
• ਫੀਚਰਸ ਦੂਜੇ ਨੰਬਰ 'ਤੇ: ਉਪਭੋਗਤਾਵਾਂ ਵਾਸਤੇ ਵਾਸਤਵਿਕ ਕਾਬਲੀਆਂ ਸ਼ਾਮਿਲ ਕਰੋ।
• ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੀਜੇ ਨੰਬਰ 'ਤੇ: ਵਰਤੋਂ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਲਾਗਤ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨ ਕਰੋ।

ਮੁੱਖ ਸਿੱਖਣ ਅਤੇ ਅਗਲੇ ਕਦਮ

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

ਸਾਹਮਣੇ ਰੱਖਣ ਲਈ ਮੁੱਖ ਸਿੱਖਣ

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

ਇਸ ਕਤਰ ਵਿੱਚ ਇਕ ਚੀਜ਼ ਹਟਾਓ

ਗਰਾਂਡ ਪਲੇਟਫਾਰਮ ਰੀਰਾਈਟ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਇੱਕ ਦੋਹਰਾਇਆ ਹੋਇਆ ਦਰਦ ਚੁਣੋ ਜੋ ਟਿਕਟਾਂ, ਆਨ-ਕਾਲ ਪੇਜਾਂ, ਜਾਂ ਸਪ੍ਰਿੰਟ ਸਪੀਲਓਵਰ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਚੰਗੇ ਉਮੀਦਵਾਰ ਹਨ:

• ਟੀਮਾਂ ਵੱਲੋਂ ਵੱਖ-ਵੱਖ ਇਨਵਾਇਰਨਮੈਂਟ ਸੈਟਅੱਪ
• ਮੈਨੁਅਲ ਰਿਲੀਜ਼ ਅਤੇ ਰੋਲਬੈਕ
• ਇੱਕੋ ਜਿਹੇ ਨੈਮ patterns ਲਈ ਦੁਹਰਾਉਂਦੇ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ
• ਸਕੇਲ/ਮਾਨੀਟਰੀੰਗ ਡਿਫਾਲਟ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰ ਕੋਈ ਮੁਸ਼ਕਲ ਤਰੀਕੇ ਨਾਲ ਦੁਬਾਰਾ ਖੋਜਦਾ ਹੈ

ਇੱਕ ਚੁਣੋ, ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ “ਡਨ” ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, “ਨਵੀਂ ਸਰਵਿਸ 15 ਮਿੰਟਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਡਿਪਲੋਇ ਹੋ ਸਕੇ”), ਅਤੇ ਸਭ ਤੋਂ ਛੋਟੀ ਵਰਜਨ ਨੂੰ ਭੇਜੋ ਜੋ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਕੰਮ ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇ।

ਸੰਬੰਧਿਤ ਆਂਤਰਿਕ ਪਾਠ

ਜੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ ਸੋਚ ਅਤੇ ਬਿਲਡ-ਵਿਰੁੱਧ-ਖਰੀਦ ਫੈਸਲਿਆਂ 'ਤੇ ਹੋਰ ਪ੍ਰਾਇਕਟਿਕ ਪੈਟਰਨ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog ਪੜ੍ਹੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ ਕਿ ਕੀ ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰਨਾ ਹੈ ਵਿਰੁੱਧ ਕੀ ਇੱਕ ਆਂਤਰਿਕ ਜਾਂ ਬਾਹਰੀ ਭੁਗਤਾਨ ਯੋਗ ਸਮਰੱਥਾ ਦੇਣੀ ਹੈ, ਤਾਂ /pricing ਪੈਕੇਜਿੰਗ ਅਤੇ ਟੀਅਰਜ਼ ਨੂੰ ਫਰੈਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਅਗਲਾ ਕੁਦਮ: ਇੱਕ ਸਧਾਰਣ ਪਲੇਟਫਾਰਮ ਬੈਕਲੌਗ

ਇਸ ਹਫ਼ਤੇ, ਤੀਨ ਕੰਮ ਕਰੋ: ਆਡਿਟ ਕਰੋ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੀ ਓਪਸ ਕੰਮ ਵਿੱਚ ਖ਼ਤਮ ਹੋ ਰਿਹਾ ਹੈ, ਤਰਜੀਹ ਦਿਓ ਫ੍ਰੀਕਵੈਂਸੀ × ਦਰਦ × ਖਤਰੇ ਦੇ ਆਧਾਰ 'ਤੇ, ਅਤੇ ਇੱਕ ਸਧਾਰਣ ਪਲੇਟਫਾਰਮ ਬੈਕਲੌਗ ਬਣਾਓ ਜਿਸ ਵਿੱਚ 3–5 ਆਈਟਮ ਹੋਣ ਜੋ ਤੁਸੀਂ ਕ੍ਰਮਿਕ ਤੌਰ 'ਤੇ ਡਿਲਿਵਰ ਕਰ ਸਕਦੇ ਹੋ।