ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਭਾਸ਼ਾਵਾਂ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ, ਬੇਹਤਰ ਕੁਸ਼ਲਤਾ, ਸੁਰੱਖਿਅਤ concurrency ਅਤੇ ਪੇਸ਼ਗੀ-ਪਦਾਰਥਿਕ ਲਾਗਤ ਕਾਰਨ ਕਲਾਉਡ ਬੈਕਐਂਡਸ 'ਚ ਮੁੜ ਆ ਰਹੀਆਂ ਹਨ। ਜਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਨੋ।
ਇੱਕ ਕੰਪਾਇਲ ਕੀਤੀ ਭਾਸ਼ਾ ਉਹ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡਾ ਸੋਰਸ ਕੋਡ (ਜੋ ਤੁਸੀਂ ਲਿਖਦੇ ਹੋ) ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਐਸੇ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਕੰਪਿ●ਯੂਟਰ ਸਿੱਧਾ ਚਲਾ ਸਕੇ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਐਕਸੀਕਿਊਟੇਬਲ ਜਾਂ ਡਿਪਲੋਏਬਲ ਆਰਟੀਫੈਕਟ ਪਾਉਂਦੇ ਹੋ ਜੋ ਮਸ਼ੀਨ-ਤਯਾਰ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਰਨਟਾਈਮ ਨੂੰ ਹਰ ਲਾਈਨ ਦੌਰਾਨ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਕੰਪਾਇਲ = "ਕੋਈ runtime ਨਹੀਂ"। ਉਦਾਹਰਨ ਲਈ, Java ਅਤੇ .NET ਬਾਈਟਕੋਡ ਤਿਆਰ ਕਰਦੇ ਹਨ ਅਤੇ JVM ਜਾਂ CLR 'ਤੇ ਚੱਲਦੇ ਹਨ, ਜਦਕਿ Go ਅਤੇ Rust ਆਮ ਤੌਰ 'ਤੇ ਨੈਟਿਵ ਮਸ਼ੀਨ ਕੋਡ 'ਚ ਕੰਪਾਇਲ ਹੁੰਦੇ ਹਨ। ਸਾਂਝਾ ਧਾਗਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਬਿਲਡ ਸਟੈਪ ਕੁਝ ਐਸਾ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਚੱਲਣ ਲਈ ਅਪਟੀਮਾਈਜ਼ ਕੀਤਾ ਹੁੰਦਾ ਹੈ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਗਾਇਬ ਨਹੀਂ ਹੋਈਆਂ। ਤਬਦੀਲੀ ਇਹ ਹੈ ਕਿ ਹੋਰ ਟੀਮਾਂ ਹੁਣ ਨਵੇਂ ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ ਲਈ ਫਿਰ ਤੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਚੁਣ ਰਹੀਆਂ ਹਨ, ਖਾਸ ਕਰਕੇ ਕਲਾਉਡ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ।
ਇੱਕ ਦਹਾਕਾ ਪਹਿਲਾਂ, ਕਈ ਵੈੱਬ ਬੈਕਐਂਡ ਕੁਦਰਤੀ ਭਾਸ਼ਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਸਨ ਕਿਉਂਕਿ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰਨ ਲਈ ਸਹੂਲਤ ਦਿੰਦੀਆਂ ਸਨ। ਅੱਜ, ਜਦੋਂ ਟੀਮਾਂ tighter ਪ੍ਰਦਰਸ਼ਨ, ਵਧੀਕ ਪੇਸ਼ਗੀ-ਪਦਾਰਥਿਕਤਾ ਅਤੇ ਵੱਧ ਓਪਰੇਸ਼ਨਲ ਕੰਟਰੋਲ ਚਾਹੁੰਦੀਆਂ ਹਨ, ਉਹੀ ਓਰ ਵੀ ਕਈ ਜਗ੍ਹਾਂ ਤੇ compiled ਵਿਕਲਪਾਂ ਨੂੰ ਮਿਲਾ ਰਹੀਆਂ ਹਨ।
ਕੁਝ ਮੁੱਖ ਥੀਮਾਂ ਮੁੜ ਮੁੜ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ:
ਇਹ ਕੋਈ "ਕੰਪਾਇਲ ਸਭ ਕੁਝ ਹਰਾ ਦਿੰਦੀ ਹੈ" ਦੀ ਕਹਾਣੀ ਨਹੀਂ ਹੈ। ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਫਿਰ ਵੀ ਤੇਜ਼ ਇਤਰਾਤੀ, ਡੇਟਾ ਟਾਸਕ ਅਤੇ glue ਕੋਡ ਲਈ ਬੜੀਆ ਹਨ। ਵਧੀਆ ਪ੍ਰਵਿਰਤੀ ਇਹ ਹੈ ਕਿ ਟੀਮ ਹਰ ਸੇਵਾ ਲਈ ਠੀਕ ਟੂਲ ਚੁਣੇ—ਅਕਸਰ ਇੱਕੋ ਸਿਸਟਮ ਵਿੱਚ ਦੋਹਾਂ ਮਿਲਕੇ।
ਕਈ ਸਾਲਾਂ ਲਈ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਸੁਖੀ ਨਾਲ ਡਾਇਨੈਮਿਕ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਵੈੱਬ ਬੈਕਐਂਡ ਬਣਾਉਂਦੀਆਂ ਸਨ। ਹਾਰਡਵੇਅਰ ਕਾਫ਼ੀ ਸਸਤਾ ਸੀ, ਟ੍ਰੈਫਿਕ ਹੌਲੀ-ਹੌਲੀ ਵਧਦਾ ਸੀ, ਅਤੇ ਕਾਫ਼ੀ ਸਾਰਾ “ਪੇਰਫਾਰਮੈਂਸ ਕੰਮ” ਇੱਕ ਹੋਰ ਸਰਵਰ ਠੂਕ ਕੇ ਅਗੇ ਲੰਘਾਇਆ ਜਾ ਸਕਦਾ ਸੀ। ਡਿਵੈਲਪਰ ਗਤੀ ਮਿਲਦੀ ਸੀ ਅਤੇ ਮਿਲੀ-ਸੇਕੰਡ ਬਚਾਅ ਤੋਂ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰਨਾ ਮਾਇਨੇ ਰੱਖਦਾ ਸੀ।
ਕਲਾਉਡ ਨੇ ਫੀਡਬੈਕ ਲੂਪ ਬਦਲ ਦਿੱਤਾ। ਜਿਵੇਂ-ਜਿਵੇਂ ਸੇਵਾਵਾਂ ਵਧੀਆਂ, ਪ੍ਰਦਰਸ਼ਨ ਇੱਕ ਇਕ-ਵਾਰ ਦੀ ਟਿ੍ਯੂਨਿੰਗ ਨਹੀਂ ਰਹਿ ਗਿਆ—ਇਹ ਲਗਾਤਾਰ ਓਪਰੇਸ਼ਨਲ ਲਾਗਤ ਬਣ ਗਿਆ। ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਥੋੜ੍ਹੀ ਜ਼ਿਆਦਾ CPU ਜਾਂ ਹਰ ਪ੍ਰੋਸੈਸ 'ਤੇ ਕੁਝ ਜ਼ਿਆਦਾ MB ਲਗਣ ਤੱਕ ਵਿਚਕਾਰ ਨਹੀਂ ਲੱਗਦਾ—ਪਰ ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਮਿਲੀਅਨ ਰਿਕਵੇਸਟਾਂ ਅਤੇ ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਇੰਸਟੈਂਸਾਂ ਨਾਲ ਗੁਣਾ ਕਰੋ ਤਾਂ ਇਹ ਗੰਭੀਰ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕਲਾਉਡ ਪੈਮਾਨੇ ਨੇ ਉਨ੍ਹਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਵੀ ਉਮੀਦੋਂ ਬਾਹਰ ਲਿਆਇਆ ਜੋ ਇੱਕ ਲੰਬੇ ਚੱਲਦੇ ਸਰਵਰ 'ਤੇ ਅਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਸਨ:
ਕਨਟੇਨਰ ਅਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਨੇ ਡਿਪਲੋਏ ਹੋਏ ਪ੍ਰੋਸੈਸਾਂ ਦੀ ਗਿਣਤੀ ਨਾਤੀਕ ਰੂਪ ਵਿੱਚ ਵਧਾ ਦਿੱਤੀ। ਇੱਕ ਵੱਡੇ ਐਪ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਦਰਜਨੋਂ ਜਾਂ ਸੈਂਕੜੇ ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਚਲਾਉਂਦੀਆਂ ਹਨ—ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਰਨਟਾਈਮ ਓਵਰਹੈੱਡ, ਮੈਮੋਰੀ ਬੇਸਲਾਈਨ, ਅਤੇ ਸਟਾਰਟਅਪ ਵਿਹਾਰ ਹੁੰਦਾ ਹੈ।
ਇਕ ਵਾਰੀ ਪ੍ਰੋਡਕਸ਼ਨ ਲੋਡ ਉੱਚਾ ਹੋ ਜਾਵੇ, ਛੋਟੀਆਂ ਅਣਫਾਇਦੀਆਂ ਵੱਡੇ ਬਿਲ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਉਹ ਸੰਦਰਭ ਹੈ ਜਿਸ ਵਿੱਚ ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਮੁੜ ਆਕਰਸ਼ਕ ਲੱਗਣ ਲੱਗਦੀਆਂ ਹਨ: ਪੇਸ਼ਗੀ-ਪਦਾਰਥਿਕਤਾ, ਘੱਟ ਪ੍ਰਤੀ-ਇੰਸਟੈਂਸ ਓਵਰਹੈੱਡ, ਅਤੇ ਤੇਜ਼ ਸਟਾਰਟਅਪ ਘੱਟ ਇੰਸਟੈਂਸ, ਛੋਟੇ ਨੋਡ ਅਤੇ ਸਥਿਰ ਰਿਸਪਾਂਸ ਟਾਈਮਾਂ 'ਚ ਤਰਜਮਾ ਕਰ ਸਕਦੇ ਹਨ।
ਪੇਰਫਾਰਮੈਂਸ ਦੀ ਗੱਲ ਮੁੜ-ਮੁੜ ਗੁੰਝਲਦਾਰ ਬਣਦੀ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਵੱਖ-ਵੱਖ ਮੈਟਰਿਕਸ ਨੂੰ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਦੋ ਟੀਮਾਂ ਦੋਹਾਂ ਕਹਿ ਸਕਦੀਆਂ ਹਨ “ਇਹ ਤੇਜ਼ ਹੈ” ਪਰ ਦੋਹਾਂ ਦਾ ਮਤਲਬ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ।
ਲੈਟੈਂਸੀ ਉਹ ਸਮਾਂ ਹੈ ਜੋ ਇੱਕ ਇਕੱਲੀ ਰਿਕਵੇਸਟ ਲੈਂਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਚੈਕਆਉਟ API 120 ms 'ਚ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਉਹ ਲੈਟੈਂਸੀ ਹੈ।
ਥਰੂਪੁੱਟ ਉਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਕਿੰਨੀ ਰਿਕਵੇਸਟਾਂ ਸੰਭਾਲ ਸਕਦੇ ਹੋ। ਜੇ ਉਹੀ ਸੇਵਾ ਲੋਡ 'ਤੇ 2,000 ਰਿਕਵੇਸਟ/ਸੈਕੰਡ ਪ੍ਰੋਸੈਸ ਕਰ ਸਕਦੀ ਹੈ, ਉਹ ਥਰੂਪੁੱਟ ਹੈ।
ਤੁਸੀਂ ਇੱਕ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਦੂਜੇ ਨੂੰ ਸੁਧਾਰੇ। ਇੱਕ ਸੇਵਾ ਦੀ ਔਸਤ ਲੈਟੈਂਸੀ ਘੱਟ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਸਪਾਈਕ ਤੇ ਡਾਊਨ ਹੋ ਸਕਦੀ ਹੈ (ਚੰਗੀ ਲੈਟੈਂਸੀ, ਘੱਟ ਥਰੂਪੁੱਟ)। ਜਾਂ ਉੱਚ ਵਾਲਿਊਮ ਨੂੰ ਹੈਂਡਲ ਕਰ ਸਕਦੀ ਹੈ ਪਰ ਹਰ ਰਿਕਵੇਸਟ ਦੇਖਣ ਵਿੱਚ ਹੌਲੀ ਹੋ (ਚੰਗਾ ਥਰੂਪੁੱਟ, ਮੰਦ ਲੈਟੈਂਸੀ)।
ਜ਼ਿਆਦਾਤਰ ਯੂਜ਼ਰ ਤੁਹਾਡੇ “ਔਸਤ” ਦਾ ਅਨੁਭਵ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਸਭ ਤੋਂ ਹੌਲੀਆਂ ਰਿਕਵੇਸਟਾਂ ਦੇ ਅਨੁਭਵ ਕਰਦੇ ਹਨ।
ਟੇਲ ਲੈਟੈਂਸੀ—ਮੇਨ ਤੌਰ 'ਤੇ p95 ਜਾਂ p99 (ਸਭ ਤੋਂ ਹੌਲੀ 5% ਜਾਂ 1% ਰਿਕਵੇਸਟ)—ਉਹ ਹੈ ਜੋ SLOs ਤੋੜਦਾ ਹੈ ਅਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ “ਐਕਸਪੇਚਨਲ ਹੌਲੀ” ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਪੇਮੈਂਟ ਕਾਲ ਜੋ ਆਮ ਤੌਰ 'ਤੇ 80 ms ਲੈਂਦੀ ਹੈ ਪਰ ਕੁਝ ਵਾਰੀ 1.5 ਸਕਿੰਟ ਲੈਂਦੀ ਹੈ, retry, timeout ਅਤੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਵਿੱਚ cascading delays ਪੈਦਾ ਕਰੇਗੀ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਇੱਥੇ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਜ਼ਿਆਦਾ ਪੇਸ਼ਗੀ-ਪਦਾਰਥੀ ਦਬਾਅ ਹੇਠਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ: ਘੱਟ ਅਚਾਨਕ ਰੁਕਾਵਟਾਂ, ਐਲੋਕੇਸ਼ਨਾਂ 'ਤੇ ਕਾਰਗਰ ਨਿਯੰਤਰਣ, ਅਤੇ ਹੌਟ ਪਾਥਾਂ ਵਿੱਚ ਘੱਟ ਰਨਟਾਈਮ ਓਵਰਹੈੱਡ। ਇਹ ਨਹੀਂ ਕਹਿ ਰਿਹਾ ਕਿ ਹਰ compiled ਰਨਟਾਈਮ ਆਪਣੇ ਆਪ consistent ਹੈ, ਪਰ ਜਦੋਂ ਐਕਜ਼ਿਕਿਊਸ਼ਨ ਮਾਡਲ ਸਧਾਰਨ ਅਤੇ ਮਸ਼ੀਨ ਦੇ ਨਜ਼ਦੀਕ ਹੁੰਦਾ ਹੈ ਤਾਂ p99 ਰੱਖਣਾ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਇੱਕ ਬੈਕਐਂਡ ਦੇ ਕੋਲ ਇੱਕ “ਹੌਟ ਪਾਥ” ਹੁੰਦਾ ਹੈ (JSON ਪਾਰਸ ਕਰਨਾ, auth ਟੋਕਨਾਂ ਦੀ ਜਾਂਚ, ਰਿਸਪਾਂਸ encode ਕਰਨਾ, IDs hash ਕਰਨਾ), ਛੋਟੀ ਅਣਫਾਇਦੀਆਂ ਗੁਣਾ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਕੰਪਾਇਲ ਕੋਡ ਅਕਸਰ ਪ੍ਰਤੀ CPU ਕੋਰ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ—ਘੱਟ ਨਿਰਦੇਸ਼ ਪ੍ਰਤੀ ਰਿਕਵੇਸਟ, ਘੱਟ ਐਲੋਕੇਸ਼ਨ, ਅਤੇ runtime bookkeeping 'ਚ ਘੱਟ ਸਮਾਂ।
ਇਹ ਤਰਜਮੇ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਥਰੂਪੁੱਟ 'ਤੇ ਘੱਟ ਲੈਟੈਂਸੀ ਜਾਂ ਉਹੀ ਫਲੀਟ ਸਾਈਜ਼ 'ਤੇ ਵੱਧ ਥਰੂਪੁੱਟ ਬਣ ਸਕਦਾ ਹੈ।
ਇੱਕ ਤੇਜ਼ compiled ਭਾਸ਼ਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਆਰਕੀਟੈਕਚਰ ਫਿਰ ਵੀ ਜਿੱਤਦੀ ਹੈ:
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਟੇਲ ਵਿਹਾਰ ਨੂੰ ਮੈਨੇਜ਼ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਧਾਰਮਿਕ ਪ੍ਰਣਾਲੀ ਡਿਜ਼ਾਈਨ ਨਾਲ ਜੋੜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਕਲਾਉਡ ਬਿੱਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਸਮੇਂ ਦੇ ਰਿਸੋर्सਾਂ ਦਾ ਪ੍ਰਤਿਬਿੰਬ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਲੰਮੇ ਸਮੇਂ ਲਈ ਵਰਤਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਸੇਵਾ ਹਰ ਰਿਕਵੇਸਟ ਲਈ ਘੱਟ CPU ਚਾਹੁੰਦੀ ਹੈ ਅਤੇ ਹਰ ਇੰਸਟੈਂਸ 'ਤੇ ਘੱਟ ਮੈਮੋਰੀ ਰੱਖਦੀ ਹੈ, ਤੁਸੀਂ ਸਿਰਫ਼ "ਤੇਜ਼" ਨਹੀਂ ਹੋ ਦੇਖਦੇ—ਸਮਰਥਨ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਘੱਟ ਸਕੇਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਘੱਟ ਬਰਬਾਦੀ ਹੁੰਦੀ ਹੈ।
ਆਟੋਸਕੇਲਰ ਆਮ ਤੌਰ 'ਤੇ CPU ਯੂਟਿਲਾਈਜੇਸ਼ਨ, ਰਿਕਵੇਸਟ ਲੈਟੈਂਸੀ ਜਾਂ ਕਤਾਰ ਦੀ ਡੈਪਥ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਸੇਵਾ ਚੜ੍ਹਦੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ CPU ਸਪਾਈਕ ਕਰਦੀ ਹੈ (ਜਾਂ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਦੌਰਾਨ), ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗ ਵਧੇਰੇ ਹੈੱਡਰੂਮ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਉਹ ਹੈੱਡਰੂਮ ਭੁਗਤਾਨ ਵਾਲਾ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਖਾਲੀ ਬੈਠਾ ਹੋਵੇ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਭਾਰਤ ਹੇਠਾਂ CPU ਵਰਤੋਂ ਨੂੰ ਹੋਰ ਸਥਿਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਸਕੇਲਿੰਗ ਵਿਹਾਰ ਪ੍ਰਭਾਸ਼ਿਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਭਰੋਸਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ ਕਿ 60% CPU ਸੁਰੱਖਿਅਤ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਓਵਰਪ੍ਰੋਵਿਜ਼ਨ ਘਟਾ ਸਕਦੇ ਹੋ ਅਤੇ “ਸਿਰਫ਼ ਇਸਲਈ” ਹੋਰ ਇੰਸਟੈਂਸ ਨਾ ਜੋੜੋ।
ਮੈਮੋਰੀ ਬਹੁਤ ਵਾਰ ਕਨਟੇਨਰ ਕਲੱਸਟਰ ਵਿੱਚ ਪਹਿਲੀ ਪਾਬੰਦੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸੇਵਾ ਜੋ 800MB ਵਰਤਦੀ ਹੈ ਬਜਾਏ 250MB ਦੇ, ਤੁਹਾਨੂੰ ਇੱਕ ਨੋਡ 'ਤੇ ਘੱਟ ਪੌਡ ਚਲਾਉਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ CPU ਸਮਰਥਨ ਬੇਕਾਰ ਰਹਿ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਜਦੋਂ ਹਰ ਇੰਸਟੈਂਸ ਦਾ ਫੁੱਟਪ੍ਰਿੰਟ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਇੱਕੋ ਨੋਡ 'ਤੇ ਜ਼ਿਆਦਾ ਨਕਲਾਂ ਪੈਕ ਕਰ ਸਕਦੇ ਹੋ, ਨੋਡ ਗਿਣਤੀ ਘਟਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਕਲੱਸਟਰ ਸਕੇਲਿੰਗ ਨੂੰ ਦਿਲਾ ਸਕਦੇ ਹੋ। ਇਹ ਪ੍ਰਭਾਵ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ 'ਚ ਹੋਰ ਵੀ ਵਧਦਾ ਹੈ: ਦਰਜਨੋਂ ਸੇਵਾਵਾਂ 'ਤੇ 50–150MB ਬਚਤ ਭਿੰਨ ਨੋਡਾਂ ਨੂੰ ਬਚਾਉਣ ਵਿੱਚ ਫਲਦਾਈ ਹੋ ਸਕਦੀ ਹੈ।
ਲਾਗਤ ਜਿੱਤਨਾ ਅਸਾਨੀ ਨਾਲ ਬਚਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਇਹ ਮਾਪਿਆ ਗਿਆ ਹੋਵੇ। ਭਾਸ਼ਾ ਬਦਲਣ ਜਾਂ ਕਿਸੇ ਹੌਟ ਪਾਥ ਨੂੰ ਰੀਰਾਈਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ ਲਓ:
ਫਿਰ ਉਹੀ ਬੈਂਚਮਾਰਕ ਬਦਲ ਦੇ ਬਾਅਦ ਦੁਹਰਾਓ। ਭਲਕੇ ਇਕ ਨਮੂਨਾ ਸੁਧਾਰ—ਮਾਨ ਲੋ 15% ਘੱਟ CPU ਜਾਂ 30% ਘੱਟ ਮੈਮੋਰੀ—ਜਦੋਂ ਉਹ 24/7 ਚਲੇ ਤਾਂ ਵੱਡਾ ਅੰਸ ਹੋ ਸਕਦਾ ਹੈ।
ਹਰ ਵਾਰੀ ਜਦੋਂ ਇੱਕ ਕੰਟੇਨਰ ਫਿਰ ਚੱਲਣਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇੱਕ ਬੈਚ ਜੌਬ ਚਲਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਸਰਵਰਲੈਸ ਫੰਕਸ਼ਨ ਲੰਮੇ ਸਮੇਂ ਬਾਅਦ ਰੁੱਕ ਕੇ ਫਿਰ ਨੂੰ ਘੁੰਮਾਇਆ ਜਾਂਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਸਟਾਰਟਅਪ ਟੈਕਸ ਦੇਣਾ ਪੈਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਲਗਾਤਾਰ ਵਰਕਲੋਡ ਨੂੰ ਸ਼ੁਰੂ ਅਤੇ ਰੋਕਦਾ ਰਹਿੰਦਾ ਹੈ (ਆਟੋਸਕੇਲਿੰਗ, ਡਿਪਲੋਏਮੈਂਟ, ਜਾਂ ਟ੍ਰੈਫਿਕ ਸਪਾਈਕ) ਤਾਂ "ਇਹ ਚੀਜ਼ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵਰਕਬਲ ਬਣ ਸਕਦੀ ਹੈ?" ਇੱਕ ਅਸਲੀ ਪ੍ਰਸ਼ਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਕੋਲਡ ਸਟਾਰਟ ਸਿਰਫ਼ "ਸਟਾਰਟ" ਤੋਂ "ਰੇਡੀ" ਤੱਕ ਦਾ ਸਮਾਂ ਹੈ: ਪਲੇਟਫਾਰਮ ਇੱਕ ਨਵਾਂ ਇੰਸਟੈਂਸ ਬਣਾਉਂਦਾ ਹੈ, ਤੁਹਾਡਾ ਐਪ ਪ੍ਰੋਸੈਸ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਇਹ ਰਿਕਵੇਸਟਸ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਜੌਬ ਚਲਾ ਸਕਦਾ ਹੈ। ਇਹ ਸਮਾਂ ਰਨਟਾਈਮ ਲੋਡ ਕਰਨ, ਸੰਰਚਨਾ ਪੜ੍ਹਨ, ਡੀਪੈਂਡੇਸੀਜ਼ ਇਨੀਸ਼ੀਅਲਾਈਜ਼ ਕਰਨ, ਅਤੇ ਜੋ ਕੁਝ ਕੋਡ ਨੂੰ ਚਾਹੀਦਾ ਹੈ ਉਹ ਸਭ ਵਾਰਮ-ਅਪ ਕਰਨ 'ਤੇ ਖਰਚ ਹੁੰਦਾ ਹੈ।
ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਅਕਸਰ ਇਹ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ ਕਿ ਓਹ ਸਿੰਗਲ ਐਕਸੀਕਿਊਟੇਬਲ ਵਜੋਂ ਭੇਜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ ਜਿਸ ਨਾਲ ਘੱਟ ਰਨਟਾਈਮ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ। ਘੱਟ ਬੂਟਸਟਰੈਪਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਹੈਲਥ ਚੈੱਕ ਪਾਸ ਕਰਨ ਅਤੇ ਟ੍ਰੈਫਿਕ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਤੱਕ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।
ਅਨੇਕ ਕੰਪਾਇਲ-ਭਾਸ਼ਾ ਡਿਪਲੋਏਮੈਂਟ ਇੱਕ ਛੋਟੀ ਕਨਟੇਨਰ ਦੇ ਤੌਰ 'ਤੇ ਪੈਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਜਿਸ 'ਚ ਇੱਕ ਮੁੱਖ ਬਾਈਨਰੀ ਅਤੇ ਕੁਝ OS-ਲੈਵਲ ਡੀਪੈਂਡੇਸੀਜ਼ ਹੁੰਦੀਆਂ ਹਨ। ਓਪਰੇਸ਼ਨਲ ਤੌਰ 'ਤੇ, ਇਹ ਰੀਲਿਜ਼ਾਂ ਸਧਾਰਨ ਕਰ ਸਕਦਾ ਹੈ:
ਹਰ ਤੇਜ਼ ਸਿਸਟਮ ਇੱਕ ਛੋਟੀ ਬਾਈਨਰੀ ਨਹੀਂ ਹੁੰਦਾ। JVM (Java/Kotlin) ਅਤੇ .NET ਸੇਵਾਵਾਂ ਵੱਡੇ ਰਨਟਾਈਮ ਤੇ ਜਸਟ-ਇਨ-ਟਾਈਮ ਕੰਪਾਇਲੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਕਾਰਨ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਹੌਲੀ ਹੋਵੇ, ਪਰ ਜਦ ਉਹ ਗਰਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਉਹ ਬਹੁਤ ਅੱਤਿਕਾਰਕ ਤਰੀਕੇ ਨਾਲ ਚੱਲ ਸਕਦੀਆਂ ਹਨ—ਖਾਸ ਕਰਕੇ ਲੰਬੇ-ਚਲਦੇ ਸੇਵਾਵਾਂ ਲਈ।
ਜੇ ਤੁਹਾਡਾ ਵਰਕਲੋਡ ਘੰਟਿਆਂ ਤੱਕ ਚੱਲਦਾ ਹੈ ਅਤੇ ਰੀਸਟਾਰਟ ਕਮ ਹੁੰਦੇ ਹਨ, ਤਾਂ steady-state throughput ਕਦੇ-ਕਦੇ cold-start speed ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਅਹਮ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਰਵਰਲੈਸ ਜਾਂ ਬਰ੍ਸਟੀ ਕੰਟੇਨਰ ਲਈ ਭਾਸ਼ਾ ਚੁਣ ਰਹੇ ਹੋ, ਤਾਂ ਸਟਾਰਟਅਪ ਟਾਈਮ ਨੂੰ ਪਹਿਲਾ-ਕਲਾਸ ਮੈਟਰਿਕ ਮੰਨੋ, ਨਾ ਕਿ ਇਕ ਬਾਅਦ ਦੀ ਚੀਜ਼।
ਆਧੁਨਿਕ ਬੈਕਐਂਡ ਆਮ ਤੌਰ 'ਤੇ ਇਕ-ਰਿਕਵੇਸਟ-ਇੱਕ-ਸਮਾਂ ਨਹੀਂ ਸੰਭਾਲਦੇ। ਇੱਕ ਚੈੱਕਆਉਟ ਫਲੋ, ਫੀਡ ਰਿਫਰੇਸ਼, ਜਾਂ API ਗੇਟਵੇਅ ਜ਼ਿਆਦਾ ਕੇਸਾਂ ਵਿੱਚ ਅੰਦਰੂਨੀ ਕਾਲਾਂ ਨੂੰ ਫੈਨ-ਆਊਟ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਹਜ਼ਾਰਾਂ ਯੂਜ਼ਰ ਇੱਕੋ ਸਮੇਂ ਸਿਸਟਮ 'ਤੇ ਹਿੱਟ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਇਹConcurrency ਹੈ: ਬਹੁਤ ਸਾਰੇ ਟਾਸਕ ਇੱਕੋ ਸਮੇਂ ਢਿਗੀ 'ਤੇ ਹੋਣ, ਜਿੰਨ੍ਹਾਂ ਨੂੰ CPU, ਮੈਮੋਰੀ, ਡੇਟਾਬੇਸ ਕਨੇਕਸ਼ਨ ਅਤੇ ਨੈਟਵਰਕ ਟਾਇਮ ਲਈ ਮੁਕਾਬਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਲੋਡ ਹੇਠਾਂ ਛੋਟੀ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀਆਂ ਗਲਤੀਆਂ ਵੱਡੀਆਂ ਇੰਸੀਡੈਂਟ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਸਾਂਝਾ ਕੈਸ਼ ਮੈਪ ਜਿਸ ਨੂੰ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਦੇ ਅਪਡੇਟ ਕੀਤਾ ਗਿਆ, ਇੱਕ ਰਿਕਵੇਸਟ ਹੈਂਡਲਰ ਜੋ ਵਰਕਰ ਥਰੇਡ ਨੂੰ ਬਲਾਕ ਕਰਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਜੋ ਪ੍ਰਾਇਮਰੀ API ਨੂੰ ਸਤਣ ਕਰਦਾ ਹੈ।
ਇਹ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਅੰਤਰਾਲੀ ਹੁੰਦੀਆਂ ਹਨ—ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਪੀਕ ਟ੍ਰੈਫਿਕ 'ਤੇ—ਜੋ ਉਹਨਾਂ ਨੂੰ ਦਰੁਸਤ ਤੌਰ 'ਤੇ ਦੁਹਰਾਉਣਾ ਮੁਸ਼ਕਿਲ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ concurrency ਨੂੰ ਆਸਾਨ ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ, ਪਰ ਕੁਝ ਪ੍ਰੈਕਟਿਸਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀਆਂ ਹਨ।
Go ਵਿੱਚ, ਹਲਕੇ goroutines ਨਾਲ ਪ੍ਰਤੀ-ਰਿਕਵੇਸਟ ਕੰਮ ਨੂੰ ਆਈਸੋਲੇਟ ਕਰਨਾ ਅਤੇ channels ਨਾਲ ਹੱਥ-ਬਦਲੀ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕਰਨੀ ਆਸਾਨ ਹੁੰਦੀ ਹੈ। ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਦੀ context propagation (ਟਾਈਮਆਊਟ, ਰੱਦ) ਗਾਹਕ ਜੁੜਨ ਜਾਂ ਡੈਡਲਾਈਨ ਖਤਮ ਹੋਣ 'ਤੇ runaway ਕੰਮ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
Rust ਵਿੱਚ, ਕੰਪਾਇਲਰ ownership ਅਤੇ borrowing ਨਿਯਮ ਲਗਾਤਾਰ ਡੇਟਾ ਰੇਸਾਂ ਨੂੰ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਦਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਸਾਂਝੇ state ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹੋ (ਉਦਾਹਰਨ ਵਜੋਂ, message passing ਜਾਂ synchronized types), ਜਿਸ ਨਾਲ subtle thread-safety ਬੱਗ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਛੁੱਟਣ ਦੇ ਚਾਂਸੇ ਘੱਟ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ concurrency ਬੱਗ ਅਤੇ ਮੈਮੋਰੀ ਮੁੱਦੇ ਪਹਿਲਾਂ (ਕੰਪਾਇਲ ਟਾਈਮ ਜਾਂ ਕਠੋਰ ਡਿਫਾਲਟਾਂ ਰਾਹੀਂ) ਫੜ ਲਈ ਜਾਂਦੇ ਹਨ, ਤੁਹਾਨੂੰ ਅਕਸਰ ਘੱਟ crash loops ਅਤੇ ਘੱਟ ਅਜਿਹੇ ਅਲਰਟਜ਼ ਮਿਲਦੇ ਹਨ। ਇਸ ਨਾਲ ਸਿੱਧਾ on-call ਲੋਡ ਘਟਦਾ ਹੈ।
ਸੁਰੱਖਿਅਤ ਕੋਡ ਫਿਰ ਵੀ ਸੁਰੱਖਿਆ ਨੈਟ ਦੀ ਲੋੜ ਹੈ। ਲੋਡ ਟੈਸਟਿੰਗ, ਚੰਗੇ ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਟ੍ਰੇਸਿੰਗ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ concurrency ਮਾਡਲ ਅਸਲ ਯੂਜ਼ਰ ਵਿਹਾਰ ਹੇਠਾਂ ਕਿਵੇਂ ਟਿਕਦਾ ਹੈ। ਮਾਨੀਟਰਿੰਗ correctness ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦੀ—ਪਰ ਇਹ ਛੋਟੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਲੰਬੇ outage ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕ ਸਕਦੀ ਹੈ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਸੇਵਾ ਨੂੰ “ਸੁਰੱਖਿਅਤ” ਨਹੀਂ ਬਣਾਂਦੀਆਂ, ਪਰ ਉਹ ਬਹੁਤ ਸਾਰੇ ਫੇਲਿਆਂ ਨੂੰ ਉਤਪਾਦਨ ਘਟਨਾ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਖੋਜ ਕਰਨ ਵੱਲ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ—ਕੰਪਾਈਲ ਟਾਈਮ ਅਤੇ CI ਵਿੱਚ।
ਜੋ ਕਲਾਉਡ ਬੈਕਐਂਡ ਹਮੇਸ਼ਾ ਅਣਟ੍ਰਸਟਡ ਇਨਪੁਟ ਦੇ ਸਾਹਮਣੇ ਹੁੰਦੇ ਹਨ, ਉਥੇ ਇਹ ਪਹਿਲਾਂ ਦੀ ਫੀਡਬੈਕ ਅਕਸਰ ਘੱਟ outage, ਘੱਟ ਐਮਰਜੈਂਸੀ ਪੈਚ ਅਤੇ ਘੱਟ ਸਮਾਂ ਲੈ ਕੇ ਹਾਰਡ-ਟੂ-ਰੀਪ੍ਰੋਡਿਊਸ ਬੱਗਾਂ ਦਾ ਕਾਰਨ ਹੁੰਦੀ ਹੈ।
ਕਈ ਕੰਪਾਇਲ ਇਕੋਸਿਸਟਮ ਸਟੈਟਿਕ ਟਾਇਪਸ ਅਤੇ ਕਠੋਰ ਕੰਪਾਇਲ ਨਿਯਮਾਂ 'ਤੇ ਭਾਰੀ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ। ਇਹ ਅਕਾਦਮਿਕ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਪ੍ਰਯੋਗਿਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇਹ ਸੁਰੱਖਿਆ ਦੇ ਤੌਰ 'ਤੇ ਨਿਕਲਦਾ ਹੈ:
ਇਹ validation, rate limiting, ਜਾਂ safe parsing ਦੀ ਬਦਲੀ ਨਹੀਂ—ਪਰ ਇਹ edge-case ਕੋਡ ਪਾਥਾਂ ਦੀ ਸੰਖਿਆ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਕੁਝ ਹੀ ਟ੍ਰੈਫਿਕ ਹਾਲਤਾਂ ਹੇਠਾਂ ਹੀ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਕਿ ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਮੁੜ ਬੈਕਐਂਡ ਪද්ਧਤੀਆਂ ਵਿੱਚ ਆ ਰਹੀਆਂ ਹਨ ਉਹ ਇਹ ਹੈ ਕਿ ਹੁਣ ਕੁਝ ਭਾਸ਼ਾਵ ਉੱਚੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਜ਼ਬੂਤ ਸੁਰੱਖਿਆ ਗਾਰੰਟੀਜ਼ ਨਾਲ ਮਿਲਾ ਰਹੀਆਂ ਹਨ। ਮੈਮੋਰੀ ਸੁਰੱਖਿਆ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਡ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਆਪਣੇ ਅਧਿਕਾਰਤ ਮੈਮੋਰੀ ਤੋਂ ਬਾਹਰ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋਵੇ।
ਜਦੋਂ ਮੈਮੋਰੀ ਬੱਗ ਇੰਟਰਨੈਟ-ਫੇਸਿੰਗ ਸੇਵਾਵਾਂ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਉਹ ਸਿਰਫ਼ crashes ਹੀ ਨਹੀਂ ਹੁੰਦੇ: ਉਹ ਗੰਭੀਰ kwetsabilities ਬਣ ਸਕਦੇ ਹਨ। ਕੁਝ ਭਾਸ਼ਾਵਾਂ (ਜਿਵੇਂ Rust) ਬਹੁਤ ਸਾਰੇ ਮੈਮੋਰੀ ਮੁੱਦਿਆਂ ਨੂੰ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਰੋਕਣ ਲਈ ڈਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਹੋਰ ਭਾਸ਼ਾਵਾਂ runtime ਚੈੱਕ ਜਾਂ managed runtimes (ਜਿਵੇਂ JVM ਜਾਂ .NET) 'ਤੇ ਨਿਰਭਰ ਹਨ ਜੋ ਮੈਮੋਰੀ ਕਰਪਸ਼ਨ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਅਧੁਨਿਕ ਬੈਕਐਂਡ ਜੋਖਮ ਬਹੁਤ ਵਾਰੀ ਡਿਪੈਂਡੇਸੀਜ਼ ਤੋਂ ਆਉਂਦਾ ਹੈ—ਨਾਹ ਕਿ ਹੱਥੋਂ ਲਿਖੇ ਕੋਡ ਤੋਂ। ਕੰਪਾਇਲ ਪ੍ਰੋਜੈਕਟ ਵੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਖਿੱਚਦੇ ਹਨ, ਇਸ ਲਈ ਡਿਪੈਂਡੇਸੀ ਨਿਯੰਤਰਣ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ:
ਚੰਗੀ ਟੂਲਚੇਨ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਇੱਕ compromised package ਜਾਂ out-of-date transitive dependency ਸਾਰੇ ਫਾਇਦੇ ਖਤਮ ਕਰ ਸਕਦੀ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਭਾਸ਼ਾ ਬੱਗ ਘਣਤਾ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਕਰ ਸਕਦੀ:
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਗਲਤੀਆਂ ਪਹਿਲੇ ਹੀ ਫੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਬਲਾਕ-ਵਧੀਆ ਸੁਰੱਖਿਆ ਫਿਰ ਵੀ ਉਸ ਆਦਤਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜੋ ਕੋਡ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹਨ—ਤੁਸੀਂ ਕਿਵੇਂ ਬਿਲਡ, ਡਿਪਲੋਏ, ਮੋਨੀਟਰ ਅਤੇ ਰੀਸਪਾਂਡ ਕਰਦੇ ਹੋ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਸਿਰਫ਼ ਰਨਟਾਈਮ ਲਛਣ ਨਹੀਂ ਬਦਲਦੀਆਂ—ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਓਪਰੇਸ਼ਨਜ਼ ਕਹਾਣੀ ਨੂੰ ਵੀ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ। ਕਲਾਉਡ ਬੈਕਐਂਡਸ ਵਿੱਚ, "ਇਹ ਤੇਜ਼ ਹੈ" ਅਤੇ "ਇਹ ਭਰੋਸੇਯੋਗ ਹੈ" ਵਿਚਕਾਰ ਦਾ ਫਰਕ ਆਮ ਤੌਰ 'ਤੇ ਬਿਲਡ ਪਾਈਪਲਾਈਨਾਂ, ਡਿਪਲੋਏਮੈਂਟ ਆਰਟੀਫੈਕਟ ਅਤੇ ਇੱਕੋ ਜਿਹੇ ਨਿਰੀਖਣ ਵਿੱਚ ਮਿਲਦਾ ਹੈ ਜੋ ਦਰਜਨੋਂ (ਜਾਂ ਸੈਂਕੜੇ) ਸੇਵਾਵਾਂ 'ਤੇ ਲਾਗੂ ਰਹਿੰਦਾ ਹੈ।
ਜਦੋਂ ਸਿਸਟਮ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹਨ, ਤੁਹਾਨੂੰ ਲੋਗਿੰਗ, ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਟ੍ਰੇਸਿੰਗ ਨੂੰ ਇੱਕਸਾਰ ਅਤੇ ਆਸਾਨ ਤਰ੍ਹਾਂ correlate ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Go, Java, ਅਤੇ .NET ਇਕੋਸਿਸਟਮ ਇੱਥੇ ਪਰਿਪੱਕਵ ਹਨ: structured logging ਆਮ ਹੈ, OpenTelemetry ਸਹਿਯੋਗ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੈ, ਅਤੇ ਆਮ ਫਰੇਮਵਰਕ request IDs, context propagation, ਅਤੇ exporter ਇੰਟੇਗਰੇਸ਼ਨਾਂ ਲਈ sensible defaults ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ।
ਪ੍ਰਯੋਗਿਕ ਜਿੱਤ ਇੱਕ singular ਟੂਲ ਨਹੀਂ—ਇਹ ਹੈ ਕਿ ਟੀਮ instrumentation ਪੈਟਰਨ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਕਿ on-call ਇੰਜੀਨੀਅਰ 2AM 'ਤੇ bespoke log ਫਾਰਮੈਟ ਡੀਕੋਡ ਨਾ ਕਰਨ।
ਕਈ ਕੰਪਾਇਲ ਸੇਵਾਵਾਂ ਸਾਫ਼-ਸੁਥਰੇ ਤਰੀਕੇ ਨਾਲ ਕਨਟੇਨਰਾਂ ਵਿੱਚ ਪੈਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ:
ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡ ਕਲਾਊਡ ਓਪਰੇਸ਼ਨਜ਼ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਜਿਸ ਆਰਟੀਫੈਕਟ ਨੂੰ ਤੁਸੀਂ ਟੈਸਟ ਕੀਤਾ ਹੈ ਉਹੀ ਆਰਟੀਫੈਕਟ ਡਿਪਲੋਏ ਹੋਵੇ, ਟ੍ਰੇਸੇਬਲ ਇਨਪੁਟਸ ਅਤੇ ਨਿਰਧਾਰਤ ਵਰਜਨਿੰਗ ਦੇ ਨਾਲ।
ਕੰਪਾਇਲ ਕਰਨ ਨਾਲ ਪਾਈਪਲਾਈਨਾਂ 'ਚ ਕਈ ਮਿੰਟ ਜੋੜ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਟੀਮਾਂ caching (dependencies ਅਤੇ ਬਿਲਡ outputs) ਅਤੇ incremental builds 'ਚ ਨਿਵੇਸ਼ ਕਰਦੀਆਂ ਹਨ।
ਮਲਟੀ-ਆਰਚ ਇਮੇਜਜ਼ (amd64/arm64) ਵਧ ਰਹੀਆਂ ਨੇ, ਅਤੇ ਕੰਪਾਇਲ ਟੂਲਚੇਨ ਆਮ ਤੌਰ 'ਤੇ cross-compilation ਜਾਂ multi-target builds ਦਾ ਸਹਿਯੋਗ ਕਰਦੇ ਹਨ—ਜੋ ARM ਇੰਸਟੈਂਸਾਂ 'ਤੇ ਵਰਕਲੋਡਾਂ ਨੂੰ ਸ਼ਿਫਟ ਕਰਕੇ ਲਾਗਤ ਘਟਾਉਣ ਦੇ ਲਈ ਉਪਯੋਗੀ ਹਨ।
ਕੁੱਲ ਮਿਲਾ ਕੇ ਪ੍ਰਭਾਵ ਇਹ ਹੈ ਕਿ ਓਪਰੇਸ਼ਨਲ ਹਾਈਜੀਨ ਵਧਦੀ ਹੈ: ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡ, ਸਾਫ਼ ਡਿਪਲੋਏਮੈਂਟ ਅਤੇ ਜਦੋਂ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਵਧਦਾ ਹੈ ਤਾਂ coherent observability।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਆਪਣੀ ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਦਿੰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਬੈਕਐਂਡ ਉਨ੍ਹਾਂ ਹੀ ਕਿਸਮਾਂ ਦੇ ਕੰਮ ਨੂੰ بار-ਬਾਰ ਕਰਦਾ ਹੈ, ਪੈਮਾਨਾ ਵੱਡਾ ਹੈ, ਅਤੇ ਛੋਟੀਆਂ ਅਣਫਾਇਦੀਆਂ ਕਈ ਇੰਸਟੈਂਸਾਂ 'ਤੇ ਗੁਣਾ ਹੁੰਦੀਆਂ ਹਨ।
ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਅਕਸਰ ਇੱਕ ਫਲੀਟ ਵਜੋਂ ਚਲਦੀਆਂ ਹਨ: ਦਰਜਨ (ਜਾਂ ਸੈਂਕੜੇ) ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ, ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਕਨਟੇਨਰ, ਆਟੋਸਕੇਲਿੰਗ ਨਿਯਮ ਅਤੇ CPU/ਮੈਮੋਰੀ ਸੀਮਾ। ਇਸ ਮਾਡਲ ਵਿੱਚ, ਪ੍ਰਤੀ-ਸੇਵਾ ਓਵਰਹੈੱਡ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
Go ਅਤੇ Rust ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟਾ ਮੈਮੋਰੀ ਫੁੱਟਪ੍ਰਿੰਟ ਅਤੇ ਨਿਰਧਾਰਤ CPU ਵਰਤੋਂ ਦਿੰਦੀਆਂ ਹਨ, ਜੋ ਤੁਹਾਨੂੰ ਇੱਕੋ ਨੋਡ 'ਤੇ ਜ਼ਿਆਦਾ ਰਿਪਲਿਕਾ ਪੈਕ ਕਰਨ ਅਤੇ ਬਿਨਾਂ ਅਚਾਨਕ ਰਿਸੋਰਸ ਸਪਾਈਕਸ ਦੇ ਸਕੇਲ ਬਾਹਰ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ।
JVM ਅਤੇ .NET ਸੇਵਾਵਾਂ ਵੀ ਇੱਕ ਵਾਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਟਿ੍ਯੂਨ ਕੀਤੀਆਂ ਜਾਣ ਤਾਂ ਉਤਕ੍ਰਿਸ਼ਟ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਸਕਦੀਆਂ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਵਰਕਫ਼ਲੋਜ਼ ਅਤੇ ਮੈਚਚੁਅਲ ਇਕੋਸਿਸਟਮ ਦੀ ਲੋੜ ਹੋਵੇ—ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਰਨਟਾਈਮ ਸੈਟਿੰਗਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਦੇਖਣ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਉਹਨਾਂ ਰਿਕਵੇਸਟ-ਭਰੀ ਕੰਪੋਨੈਂਟਾਂ ਲਈ ਬਹੁਤ ਚੰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਲੈਟੈਂਸੀ ਅਤੇ ਥਰੂਪੁੱਟ ਸਿੱਧੇ ਯੂਜ਼ਰ ਅਨੁਭਵ ਅਤੇ ਕਲਾਉਡ ਖਰਚ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ:
ਇਨ੍ਹਾਂ ਪਾਥਾਂ ਵਿੱਚ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ concurrency ਅਤੇ ਘੱਟ ਪ੍ਰਤੀ-ਰਿਕਵੇਸਟ ਓਵਰਹੈੱਡ ਘੱਟ ਇੰਸਟੈਂਸ ਅਤੇ ਸੁમਤ ਆਟੋਸਕੇਲਿੰਗ 'ਚ ਤਰਜਮਾ ਕਰ ਸਕਦੇ ਹਨ।
ETL ਕਦਮ, ਸ਼ੈਡੂਲਰ ਅਤੇ ਡੇਟਾ ਪ੍ਰੋਸੈਸਰ ਅਕਸਰ ਤੰਗ ਸਮੇਂ ਦੀਆਂ ਖਿੜਕੀਆਂ 'ਤੇ ਚੱਲਦੇ ਹਨ। ਤੇਜ਼ ਐਕਸੀਕਿਊਟੇਬਲ ਵਾਲੇ ਨੌਕਰੀਆਂ ਦੀ ਕੰਮ ਕਰਨ ਦੀ ਵਾਲ-ਕਲੌਕ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕਮਪਿਊਟ ਬਿੱਲ ਘਟ ਸਕਦੇ ਹਨ ਅਤੇ ਨੌਕਰੀਆਂ downstream ਡੈਡਲਾਈਨਾਂ ਤੋਂ ਪਹਿਲਾਂ ਖਤਮ ਹੋ ਸਕਦੀਆਂ ਹਨ।
Rust ਅਕਸਰ ਉਹਨਾਂ ਥਾਵਾਂ ਲਈ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ ਦੋਹਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ; Go ਓਹਲੇਕਵੇਲੇ ਜਦੋਂ ਸਾਦਗੀ ਅਤੇ ਤੇਜ਼ iteration ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ।
ਕਈ ਕਲਾਉਡ ਬੈਕਐਂਡ ਉਹ ਹੇਲਪਰ ਕੰਪੋਨੈਂਟ ਵਰਤਦੇ ਹਨ ਜਿੱਥੇ ਵੰਡ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸਾਦਗੀ ਮੁੱਖ ਹੈ:
ਇੱਕ-ਸਵੈ-ਸ਼ਾਮਿਲ ਬਾਈਨਰੀਆਂ ਨੂੰ ਭੇਜਣਾ, ਵਰਜਨ ਕਰਨਾ ਅਤੇ ਵੱਖ-ਵੱਖ ਮਾਹੌਲਾਂ 'ਤੇ ਲਗਾਤਾਰ ਚਲਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਹਾਈ-ਥਰੂਪੁੱਟ ਸੇਵਾਵਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਆ ਰਹਿੰਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਹਰ ਬੈਕਐਂਡ ਸਮੱਸਿਆ ਲਈ ਸਵੈ-ਚਾਲਿਤ ਤੌਰ 'ਤੇ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਕੁਝ ਕੰਮ iteration ਦੀ ਗਤੀ, ਇਕੋਸਿਸਟਮ ਫਿੱਟ, ਜਾਂ ਟੀਮ ਦੀ ਹਕੀਕਤ ਲਈ ਜ਼ਿਆਦਾ موزੂਨ ਹੁੰਦੇ ਹਨ ਨਾ ਕਿ ਸਿਰਫ਼ ਕੁੱਲ ਪ੍ਰਦਰਸ਼ਨ ਲਈ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਿਚਾਰ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਵਰਕਫਲੋ ਦੀ ਪੜਤਾਲ ਕਰ ਰਹੇ ਹੋ, ਜਾਂ اندرੂਨੀ ਆਟੋਮੇਸ਼ਨ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੂਪ peak ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ।
ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ admin ਟਾਸਕ, ਸਿਸਟਮਾਂ ਦਰਮਿਆਨ glue ਕੋਡ, ਇੱਕ-ਵਾਰੀ ਡੇਟਾ ਫਿਕਸ, ਅਤੇ ਤੇਜ਼ ਪ੍ਰਯੋਗਾਂ ਲਈ ਜਿੱਤਦੀਆਂ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦ ਕੋਡ ਅਕਸਰ ਸੰਖੇਪ ਜਾਂ ਬਾਰ-ਬਾਰ ਲਿਖਿਆ/ਦੁਹਰਾਇਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।
ਭਾਸ਼ਾ ਬਦਲਣਾ ਹਕੀਕਤ ਵਿੱਚ ਲਾਗਤ ਰੱਖਦਾ ਹੈ: ਟ੍ਰੇਨਿੰਗ ਸਮਾਂ, ਭਰਤੀ ਦੀ ਮੁਸ਼ਕਲ, ਕੋਡ ਰਿਵਿਊ ਨਾਰਮਾਂ ਵਿੱਚ ਤਬਦੀਲੀ, ਅਤੇ ਬਿਲਡ/रਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਅਪਡੇਟ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦਾ ਸਟੈਕ (ਉਦਾਹਰਨ ਲਈ ਇਕ ਪਰਿਪੱਕਵ Java/JVM ਜਾਂ .NET ਬੈਕਐਂਡ) 'ਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਡਿਲਿਵਰ ਕਰ ਰਹੀ ਹੈ, ਇੱਕ ਨਵੀਂ compiled ਭਾਸ਼ਾ ਅਪਣਾਉਣ ਨਾਲ ਤੇਜ਼ੀ ਘਟ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਸਾਫ਼ ਫਾਇਦੇ ਦੇ। ਕਈ ਵਾਰੀ ਸਭ ਤੋਂ ਵਧੀਆ ਕਦਮ ਮੌਜੂਦਾ ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਪ੍ਰਯੋਗਾਂ—ਪ੍ਰਥਮਿਕਤਾ ਕਰਨਾਂ—ਹੋ ਸਕਦੀ ਹੈ।
ਭਾਸ਼ਾ ਚੋਣ ਅਕਸਰ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਇੰਟੇਗ੍ਰੇਸ਼ਨਾਂ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਟੂਲਿੰਗ 'ਤੇ ਟਿਕਦੀ ਹੈ। ਕੁਝ ਡੋਮੇਨਾਂ—ਡੇਟਾ ਸਾਇੰਸ ਵਰਕਫਲੋਜ਼, ਵਿਸ਼ੇਸ਼ ML ਟੂਲਿੰਗ, ਖਾਸ SaaS SDKs ਜਾਂ ਨਿਊਚ ਪ੍ਰੋਟੋਕੋਲ—ਕਈ ਵਾਰੀ compiled-ਭਾਸ਼ਾ ਦੁਨੀਆ ਤੋਂ ਬਾਹਰ ਵਧੇਰੇ ਸਹਿਯੋਗ ਰੱਖਦੇ ਹਨ।
ਜੇ ਜ਼ਰੂਰੀ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਕਮਜ਼ੋਰ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਕੀਤੀ ਬਚਤ ਨੂੰ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਕਾਰਜ 'ਤੇ ਖਰਚ ਕਰਾਂਗੇ।
ਇੱਕ ਤੇਜ਼ ਭਾਸ਼ਾ ਧੀਮੀਆਂ ਕਵੈਰੀਆਂ, ਚੱਟੀ-ਚੈਟੈ ਸੇਵਾ-ਸੇਵਾ ਕਾਲਾਂ, ਵੱਡੇ payloads, ਜਾਂ ਗੈਰ-ਮੌਜੂਦਾ caching ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਪਹਿਲਾਂ ਮਾਪੋ ਅਤੇ ਉਹਨਾਂ ਮੁੱਲਾਂ ਨੂੰ ਹੱਲ ਕਰੋ ਜਿਹੜੇ ਸੱਚਮੁੱਚ ਰੋਕ ਰਹੇ ਹਨ—ਵੇਖੋ: /blog/performance-budgeting ਇਕ ਪ੍ਰਯੋਗਿਕ ਪਹੁੰਚ ਲਈ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਅਪਨਾਉਣਾ "ਮੂੜੀ ਭਰੀ ਰੀਰਾਈਟ" ਮਤਲਬ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਾਹ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ੍ਹੀ ਵਰਤੋਂ: ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਮਾਪੋ, ਅਤੇ ਕੇਵਲ ਜਦੋਂ ਨਤੀਜੇ ਅਸਲ ਹੋਣ ਤਾਂ ਵਧੋ।
ਇੱਕ ਐਸੀ ਸੇਵਾ ਚੁਣੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਸਪੱਸ਼ਟ ਬੌਤਲਨੈਕ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੇ ਹੋ—ਉੱਚ CPU ਬਰਨ, ਮੈਮੋਰੀ ਦਬਾਅ, ਬੁਰਡਨ p95 ਲੈਟੈਂਸੀ, ਜਾਂ ਦਰਦਨਾਕ ਕੋਲਡ ਸਟਾਰਟ।
ਇਸ ਨਾਲ ਸਫਲਤਾ ਦੀ ਛੇਤੀ ਘੇਰਾ ਛੋਟਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਬਸ ਜਾਂਚਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਭਾਸ਼ਾ ਬਦਲਣ ਸਹੀ ਵਿੱਚ ਮਦਦ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ (ਬਜਾਏ ਕਿ ਕੋਈ ਡੇਟਾਬੇਸ ਕਵੈਰੀ ਜਾਂ upstream ਡੀਪੈਂਡੈਂਸੀ)।
ਤੈਅ ਕਰੋ ਕਿ “ਵਧੀਆ” ਦਾ ਮਤਲਬ ਕੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਮਾਪੋਂਗੇ। ਆਮ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਮੈਟਰਿਕ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਟ੍ਰੇਸਿੰਗ ਨਹੀਂ, ਤਾਂ ਪਹਿਲਾਂ ਉਹ ਗੱਡੇ (ਜਾਂ ਇਕੱਠੇ) ਕਰੋ—ਇੱਕ ਬੇਸਲਾਈਨ ਬਿਨਾਂ ਵਿਚਾਰ-ਵਿਵਾਦ ਦੇ ਹਫ਼ਤੇ ਬਚਾ ਸਕਦੀ ਹੈ। /blog/observability-basics ਨੂੰ ਵੇਖੋ।
ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਮੌਜੂਦਾ ਇਕੋਸਿਸਟਮ 'ਚ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਥਿਰ contracts—gRPC ਜਾਂ HTTP APIs, ਸ਼ੇਅਰ ਕੀਤੇ schema, ਅਤੇ ਵਰਜ਼ਨਿੰਗ ਨਿਯਮ ਤੈਅ ਕਰੋ—ਤਾਂ ਕਿ ਹੋਰ ਟੀਮਾਂ ਬਿਨਾਂ ਕੋਆਰਡੀਨੇਟ ਕੀਤੇ ਰਿਲੀਜ਼ਾਂ ਦੇ ਉਪਯੋਗ ਕਰ ਸਕਣ।
ਨਵੀਂ ਸੇਵਾ ਨੂੰ ਇੱਕ ਕੈਨਰੀ ਡਿਪਲੌਯ ਹੇਠਾਂ ਸ਼ਿਪ ਕਰੋ ਅਤੇ ਇੱਕ ਛੋਟਾ ਪ੍ਰਤੀਸ਼ਤ ਟ੍ਰੈਫਿਕ ਉਸਨੂੰ ਰਾਖੋ। ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ, ਫੀਚਰ ਫਲੈਗ ਵਪਾਰੋ ਅਤੇ ਇੱਕ ਸਿੱਧਾ ਰੋਲਬੈਕ ਰਾਹ ਰੱਖੋ।
ਮਕਸਦ ਅਸਲ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਸਿੱਖਣਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਬੈਂਚਮਾਰਕ ਜਿੱਤਣਾ।
ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਡਾਇਨੈਮਿਕ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਟੀਮਾਂ ਇਸ ਲਈ ਪਸੰਦ ਕਰਦੀਆਂ ਸਨ ਕਿ iteration ਤੇਜ਼ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ Go ਜਾਂ ਹੋਰ compiled ਵਿਕਲਪ ਲਿਆ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿ templates, build tooling ਅਤੇ deployment defaults ਸਟੈਂਡਰਡ ਕਰ ਦਿਓ ਤਾਂ ਕਿ “ਨਵੀਂ ਸੇਵਾ” ਦਾ ਮਤਲਬ “ਨਵਾਂ ਕਈ ਯਕ ਸ਼ੇਅਰ” ਨਾ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ prototype ਅਤੇ ਸੇਵਾ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਪਰ ਅੰਤ ਵਿੱਚ आधुनिक compiled ਬੈਕਐਂਡ 'ਤੇ ਲੈਂਡ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਮਦਦਗਾਰ ਹੋ ਸਕਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਐਪ ਦਾ ਵਰਣਨ ਕਰੋ, Planning Mode ਵਿੱਚ ਇੰਟਰੇਟ ਕਰੋ, ਅਤੇ deployable ਸੋర్స్ ਕੋਡ ਜੈਨਰੇਟ/ਐਕਸਪੋਰਟ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇ frontend 'ਤੇ React ਅਤੇ backend 'ਤੇ Go + PostgreSQL)। ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਡਿਸੀਪਲਿਨ ਦਾ ਬਦਲ ਨਹੀਂ, ਪਰ ਇਹ ਪਹਿਲੀ ਚੱਲਣ-ਯੋਗ ਸੇਵਾ ਬਣਾਉਣ ਦਾ ਸਮਾਂ ਘਟਾ ਸਕਦਾ ਹੈ।
Waqt ਦੇ ਨਾਲ, ਤੁਸੀਂ ਉਹ ਰੂਪ-ਰੇਖਾ, ਲਾਈਬ੍ਰੇਰੀਆਂ ਅਤੇ CI defaults ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਅਗਲੀ compiled ਸੇਵਾ ਨੂੰ ਸਸਤੀ ਤਰ੍ਹਾਂ ਡਿਲਿਵਰ ਕਰਨ ਬਣਾਉਂਦੀਆਂ ਹਨ—ਅਤੇ ਇੱਥੇ ਹੀ compounding returns ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।
ਬੈਕਐਂਡ ਭਾਸ਼ਾ ਚੁਣਨਾ ਇਡੀਓਲੋਜੀ ਦੀ ਗੱਲ ਨਹੀਂ, ਬਲਕਿ ਫਿੱਟ ਦੀ ਗੱਲ ਹੈ। compiled ਭਾਸ਼ਾ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਲਈ ਚੰਗਾ ਡਿਫੌਲਟ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਫੈਸਲਾ ਹਮੇਸ਼ਾ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਟਰੇਡ-ਆਫ਼ ਹੈ।
ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਚਲਾਓ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ-ਮਿਸਲ ਟ੍ਰੈਫਿਕ ਵਰਗਾ ਹੋਵੇ: CPU, ਮੈਮੋਰੀ, ਸਟਾਰਟਅਪ ਸਮਾਂ, ਅਤੇ p95/p99 ਲੈਟੈਂਸੀ ਮਾਪੋ।
ਆਪਣੇ ਅਸਲ ਐਂਡਪੌਇੰਟਸ ਅਤੇ ਡਿਪੈਂਡੇਸੀਜ਼ ਨੂੰ ਬੈਂਚਮਾਰਕ ਕਰੋ—ਸਿੰਥੇਟਿਕ ਲੂਪਾਂ ਨੂੰ ਨਹੀਂ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਮੋਡਰਨ ਕਲਾਉਡ ਬੈਕਐਂਡਸ ਲਈ ਇੱਕ ਵਧੀਆ ਵਿਕਲਪ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਲਾਗਤ ਦੀ ਪੇਸ਼ਗੀ-ਪਦਾਰਥਿਕਤਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੋਵੇ—ਪਰ ਸਹੀ ਚੋਣ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸ਼ਿਪ, ਓਪਰੇਟ ਅਤੇ ਵਿਕਸਤ ਕਰ ਸਕੇ।
ਕੰਪਾਇਲ ਕੀਤਾ ਕੋਡ ਅੱਗੇ ਤੋਂ ਤਿਆਰ ਕੀਤਾ ਹੁੰਦਾ ਹੈ—ਇੱਕ ਐਯਕਸੀਕਿਊਟੇਬਲ ਜਾਂ ਡਿਪਲੋਏਬਲ ਆਰਟੀਫੈਕਟ ਬਣਦਾ ਹੈ ਜੋ ਸਿੱਧਾ ਚੱਲ ਸਕਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਬਿਲਡ ਸਟੈਪ ਕੁਝ ਅਜਿਹਾ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਚੱਲਣ ਲਈ ਅਪਟੀਮਾਈਜ਼ ਕੀਤਾ ਗਿਆ ਹੁੰਦਾ ਹੈ, ਪਰ ਕਈ “ਕੰਪਾਇਲ” ਪਰਿਸਰਾਂ ਵਿੱਚ ਫਿਰ ਵੀ ਇੱਕ ਰuntime ਹੋ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, JVM ਜਾਂ CLR)।
ਹਮੇਸ਼ਾ ਨਹੀਂ। ਕੁਝ ਕੰਪਾਇਲ ਪਰਿਸਰ ਨੈਟਿਵ ਬਾਈਨਰੀ ਬਣਾਉਂਦੇ ਹਨ (ਅਕਸਰ Go/Rust), ਜਦਕਿ ਹੋਰ ਬਾਈਟਕੋਡ ਤਿਆਰ ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਮੈਨੇਜਡ ਰuntime (Java/.NET) 'ਤੇ ਚੱਲਦੇ ਹਨ। ਪ੍ਰੈਕਟੀਕਲ ਫਰਕ ਸਟਾਰਟਅਪ ਵਿਹਾਰ, ਮੈਮੋਰੀ ਮਾਡਲ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਪੈਕੇਜਿੰਗ 'ਚ ਦਿੱਖਦਾ ਹੈ—ਸਿਰਫ “ਕੰਪਾਇਲ ਵਿਰੁੱਧ ਇੰਟਰਪ੍ਰੀਟ” ਨਹੀਂ।
ਕਲਾਉਡ ਛੋਟੀਆਂ ਅਣਫ਼ਾਇਦਿਆਂ ਨੂੰ ਲਗਾਤਾਰ ਖਰਚ ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ। ਪ੍ਰਤੀ-ਰਿਕਵੇਸਟ CPU ਓਵਰਹੈੱਡ ਜਾਂ ਪ੍ਰਤੀ ਇੰਸਟੈਂਸ ਵਧੀਕ ਮੈਮੋਰੀ ਮਿਲੀਅਨਾਂ ਰਿਕਵੇਸਟਾਂ ਅਤੇ ਕਈ ਨਕਲਾਂ 'ਤੇ ਗੁਣਾ ਹੋਣ 'ਤੇ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ। ਟੀਮਾਂ ਪਿਆਰ ਪੱਖੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਅਤੇ ਪੇਸ਼ਗੀ-ਪਦਾਰਥਕ ਲੈਟੈਂਸੀ (ਖਾਸ ਕਰਕੇ p95/p99) 'ਤੇ ਹੋਰ ਧਿਆਨ ਦਿੰਦੀ ਹਨ।
ਟੇਲ ਲੈਟੈਂਸੀ (p95/p99) ਉਹ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਨੁਭਵ ਤੇ ਇੱਕੱਠੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀ ਹੈ ਅਤੇ SLOs ਨੂੰ ਭੰਜਨ ਕਰਦੀ ਹੈ। ਇਹ ਉਸ ਸਮੇਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਸੇਵਾ ਦੀਆਂ ਸਭ ਤੋਂ ਧੀਮੀ 1%–5% ਰਿਕਵੇਸਟਾਂ ਵੱਡੇ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਹੌਟ ਪਾਥਾਂ 'ਚ ਰਨਟਾਈਮ ਓਵਰਹੈੱਡ ਘਟਾ ਕੇ ਟੇਲ ਵਿਹਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਸਮੇਂ-ਆਊਟ ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹਨ।
ਆਟੋਸਕੇਲਰ ਅਕਸਰ CPU, ਲੈਟੈਂਸੀ ਜਾਂ ਕਤਾਰ ਦੀ ਲੰਬਾਈ ਦੇ ਅਧਾਰ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦੇ ਹਨ। ਜੇ ਸੇਵਾ ਤੀਬਰ CPU ਸਪਾਈਕ ਕਰਦੀ ਹੈ ਜਾਂ ਰਨਟਾਈਮ ਬਰਦਾਸ਼ਤ ਉੱਚੀ ਹੈ, ਤਾਂ ਅਤਿ-ਸੁਰੱਖਿਆ ਲਈ ਵਾਧੂ ਹੈੱਡਰੂਮ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ—ਜਿਸਦਾ ਭੁਗਤਾਨ ਤੁਸੀਂ ਕਰਦੇ ਹੋ। CPU-ਪਰ-ਰਿਕਵੇਸਟ ਨੂੰ ਸੁਧਾਰਨਾ ਅਤੇ ਯੂਟਿਲਾਈਜੇਸ਼ਨ ਨੂੰ ਸਥਿਰ ਰੱਖਣਾ ਇੰਸਟੈਂਸ ਗਿਣਤੀ ਅਤੇ ਓਵਰਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਘਟਾ ਸਕਦਾ ਹੈ।
ਕੰਟੇਨਰ ਕਲੱਸਟਰਾਂ 'ਚ ਮੈਮੋਰੀ ਅਕਸਰ ਪਹਿਲੀ ਪਾਬੰਦੀ ਹੁੰਦੀ ਹੈ—ਜੇ ਹਰ ਇੰਸਟੈਂਸ ਵੱਧ ਬੇਸਲਾਈਨ ਮੈਮੋਰੀ ਲੈਂਦਾ ਹੈ ਤਾਂ ਨੋਡ 'ਤੇ ਘੱਟ ਪੌਡ ਫਿੱਟ ਹੁੰਦੇ ਹਨ ਅਤੇ CPU ਅਣਉਪਯੋਗ ਰਹਿ ਸਕਦਾ ਹੈ। ਘੱਟ ਮੈਮੋਰੀ ਫੁੱਟਪ੍ਰਿੰਟ ਵਾਲੇ ਇੰਸਟੈਂਸ ਨਾਲ ਤੁਸੀਂ ਜ਼ਿਆਦਾ ਨਕਲਾਂ ਇਕੱਠੀਆਂ ਕਰ ਸਕਦੇ ਹੋ, ਨੋਡ ਗਿਣਤੀ ਘਟਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਕਲੱਸਟਰ ਵਧਾਉਣ ਨੂੰ ਟਾਲ ਸਕਦੇ ਹੋ—ਇਹ ਪ੍ਰਭਾਵ ਮਾਈਕ੍ਰੋਸਰਵਿਸز 'ਚ ਗੁਣਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕੋਲਡ ਸਟਾਰਟ ਉਹ ਸਮਾਂ ਹੈ ਜੋ “ਸ਼ੁਰੂ” ਤੋਂ “ਰੇਡੀ” ਹੋਣ ਤੱਕ ਲੱਗਦਾ ਹੈ—ਇਸ ਵਿੱਚ ਰਨਟਾਈਮ ਲੋਡ ਹੋਣਾ, ਸੰਰਚਨਾ ਪੜ੍ਹਨਾ, ਡੀਪੈਂਡੇਸੀਜ਼ ਇਨੀਸ਼ੀਅਲਾਈਜ਼ ਹੋਣਾ ਅਤੇ ਜਰੂਰੀ ਵਾਰਮਅਪ ਸ਼ਾਮਿਲ ਹੁੰਦੇ ਹਨ। ਸਿੰਗਲ-ਬਾਈਨਰੀ ਸੇਵਾਵਾਂ ਭੇਜਣ ਤੇ ਛੋਟੀ ਇਮੇਜਾਂ ਨਾਲ ਅਤੇ ਘੱਟ ਬੂਟਸਟਰੈਪਿੰਗ ਨਾਲ ਇਨ੍ਹਾਂ ਨੂੰ ਘਟਾ ਸਕਦੀਆਂ ਹਨ।
ਲਾਈਵ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਛੋਟੀ ਕੋਆਰਡੀਨੇਸ਼ਨ ਦੀਆਂ ਗਲਤੀਆਂ ਵੱਡੀਆਂ ਘਟਨਾਵਾਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ: ਸਾਂਝਾ ਕੈਸ਼ ਮੈਪ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਦੇ ਅਪਡੇਟ ਹੋਣਾ, ਹਥਿਆਰਬੰਦ ਰਿਕਵੇਸਟ ਹੈਂਡਲਰ ਜੋ ਵਰਕਰ ਥਰੇਡ ਬਲਾਕ ਕਰਦਾ ਹੈ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਜੋ ਪ੍ਰਾਇਮਰੀ ਏਪੀਆਈ ਨੂੰ ਭੁੱਖਾ ਰੱਖਦਾ ਹੈ। ਇਹ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਔਚੁਕ ਹੁੰਦੀਆਂ ਹਨ—ਕੇਵਲ ਪੀਕ ਟ੍ਰੈਫਿਕ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ concurrency ਨੂੰ ਆਸਾਨ ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ, ਪਰ ਕੁਝ ਪ੍ਰੈਟਿਸ ਪਾਸੇ ਧੱਕ ਦਿੰਦੀਆਂ ਹਨ। Go ਦੇ ਹਲਕੇ goroutines ਨਾਲ ਹਰ ਰਿਕਵੇਸਟ ਲਈ ਕੰਮ ਨੂੰ ਆਇਸੋਲੇਟ ਕਰਨਾ ਆਸaan ਹੈ ਅਤੇ channels ਹਥਿਆਰਬੰਦ ਹੱਥ ਲੈਣ ਹਨ; ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ context ਪ੍ਰਾਪਗੇਸ਼ਨ (ਟਾਈਮਆਊਟ, ਰੱਦ) runaway ਕੰਮ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। Rust ਦੇ ਕੰਪਾਇਲਰ ownership ਅਤੇ borrowing ਨਿਯਮ ਲਗਾਤਾਰ ਡੇਟਾ ਰੇਸਾਂ ਨੂੰ ਤਿਆਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਦਿੰਦੇ ਹਨ।
ਕੰਪਾਇਲ-ਟਾਈਮ ਚੈੱਕ ਅਤੇ ਫ਼ਿਕਸਡ ਡਿਫਾਲਟਾਂ ਬਹੁਤ ਸਾਰੇ ਬੱਗ ਪਹਿਲੇ ਹੀ ਪਕੜ ਲੈਂਦੀਆਂ ਹਨ—ਟਾਇਪ ਚੈੱਕ, ਨੱਲ ਹੈਂਡਲਿੰਗ, ਅਤੇ ਕੁਝ ਬਾਊਂਡ/ਓਵਰਫਲੋ ਚੈੱਕ ਹਨ ਜੋ ਅਜਿਹੇ ਖੇਤਰਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ। ਇਹ ਸੁਰੱਖਿਆ ਮੈਕੈਨਿਜ਼ਮ ਪੂਰੀ ਸੁਰੱਖਿਆ ਦਾ ਬਦਲ ਨਹੀਂ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਨਾਲ ਐਜ-ਕੇਸ ਬੱਗ ਘਟਦੇ ਹਨ ਜੋ ਸਿਰਫ ਏਜ-ਕੇਸ ਟ੍ਰੈਫਿਕ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਬੈਕਐਂਡ ਖ਼ਤਰੇ ਡਿਪੈਂਡੇਸੀਆਂ ਤੋਂ ਆਉਂਦੇ ਹਨ। ਕੰਪਾਇਲ ਪ੍ਰੋਜੈਕਟ ਵੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਖਿੱਚਦੇ ਹਨ—ਇਸ ਲਈ lockfiles ਰੱਖੋ, CI ਵਿੱਚ vuln ਸਕੈਨ ਚਲਾਓ, ਅਤੇ ਛੋਟੇ ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਿਭਾਇਆ ਗਿਆ ਡਿਪੈਂਡੈਂਸੀ ਗ੍ਰਾਫ ਤਰਜੀਹ ਦਿਓ। ਭਾਸ਼ਾ ਚੰਗੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਇੱਕ ਸਮਝੌਤਾ ਪੈਕੇਜ ਜਾਂ ਅਪ-ਟੂ-ਡੇਟ ਟਰਾਂਜ਼ੇਟਿਵ ਡਿਪੈਂਡੈਂਸੀ ਫਾਇਦੇ ਖਤਮ ਕਰ ਸਕਦੀ ਹੈ।
ਟੂਲਚੇਨ ਬਦਲਣ ਨਾਲ ਰਨਟਾਈਮ ਵਿਹਾਰ ਹੀ ਨਹੀਂ ਬਦਲਦੇ—ਬਿਲਡ ਪਾਈਪਲਾਈਨ, ਡਿਪਲੋਏਮੈਂਟ ਆਰਟੀਫੈਕਟ ਅਤੇ ਆਬਜ਼ਰਵੇਬਿਲਟੀ ਵੀ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ 'ਚ ਸਧਾਰਨ, ਏਕਸਾਰ ਲੌਗਿੰਗ/ਮੈਟ੍ਰਿਕਸ/ਟ੍ਰੇਸਿੰਗ ਪੈਟਰਨ ਨੇ 2AM ਤੇ ਆਨ-ਕਾਲ ਇੰਜੀਨੀਅਰ ਦੀ ਜ਼ਿੰਦਗੀ ਆਸਾਨ ਕਰ ਦਿੱਤੀ ਹੈ।
ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਕੰਮ ਬਾਰ-ਬਾਰ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਪੈਮਾਨਾ ਵੱਡਾ ਹੋਵੇ ਅਤੇ ਛੋਟੀਆਂ ਅਣਫ਼ਾਇਦੀਆਂ ਕਈ ਨਕਲਾਂ 'ਤੇ ਗੁਣਾ ਹੋਣ। ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼, ਹਾਈ-ਥਰੂਪੁੱਟ APIs, ਬੈਚ ਨੌਕਰੀਆਂ ਅਤੇ ਪਲੇਟਫਾਰਮ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਟੂਲਿੰਗ ਉਹਨਾਂ ਖੇਤਰਾਂ ਹਨ ਜਿੱਥੇ ਲਾਭ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਿਚਾਰ ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਰਖ ਰਹੇ ਹੋ ਤਾਂ iteration ਦੀ ਤੇਜ਼ੀ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ—ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਲਈ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ ਬਿਹਤਰ ਹੁੰਦੀਆਂ ਹਨ। ਟੀਮ ਦੀ ਮੌਜੂਦਾ ਖੋਜ-ਕੋਭ, ਭਰਤੀ ਅਤੇ ਬਿਲਡ/ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਦੇ ਖਰਚੇ ਨੂੰ ਤੋੜਨਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ।
ਇੱਕ ਸਲੋ-ਭਾਸ਼ਾ ਤੁਹਾਡੇ ਡੀਟੇਬੇਸ ਦੀਆਂ ਸੁਲਝੀਆਂ ਕੀਤੀਆਂ ਕਵੈਰੀਆਂ, ਨੈਟਵਰਕ ਚੱਲਣ/ਹਾਈ ਲੈਟੈਨਸੀ ਵਾਲੇ ਬਾਹਰਲੇ API ਜਾਂ ਅਣਯੋਜਿਤ ਚੈੱਟੀ ਕੰਮਾਂ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਪਹਿਲਾਂ ਮਾਪੋ ਅਤੇ ਅਸਲ ਬੌਤਲਨੈਕ ਨੂੰ ਹੱਲ ਕਰੋ। ਵੇਖੋ: /blog/performance-budgeting (ਪ੍ਰਾਇਕਟਿਕਲ ਰੂਪ)।
ਸੰਪੂਰਨ ਰੀਰਾਈਟ ਕਰਨ ਦੇ ਬਜਾਏ ਇੱਕ ਛੋਟੀ ਸ਼ੁਰੂਆਤ ਕਰੋ: ਇੱਕ ਸੇਵਾ ਚੁਣੋ ਜਿਸ 'ਚ ਸਪਸ਼ਟ ਦਰਦ-ਬਿੰਦੂ ਹੋਵੇ, ਨਤੀਜਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਅਤੇ ਫਿਰ ਕੈਨਰੀ ਰੋਲਆਉਟ ਵਰਤ ਕੇ ਟ੍ਰੈਫਿਕ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਨਵੇਂ ਇੰਪਲਿਮੈਂਟੇਸ਼ਨ ਨੂੰ ਭੇਜੋ। ਵਾਸਤਵਿਕ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਸਿੱਖਣਾ ਮੁੱਖ ਹੈ—ਬੇਨਚਮਾਰਕ ਜਿੱਤਣ ਲਈ ਨਹੀਂ।
ਅੰਤ ਵਿੱਚ, ਉਹ ਚੋਣ ਸਹੀ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਤੇ ਦਫਤਰ-ਪਰਦੇਸ਼ ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਾਂ ਚਲਾ ਸਕੇ, ਓਪਰੇਟ ਕਰ ਸਕੇ ਅਤੇ ਵਿਕਸਿਤ ਕਰ ਸਕੇ। ਕੰਪਾਇਲ ਭਾਸ਼ਾਵਾਂ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਵਿਕਲਪ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਲਾਗਤ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਪੂਰਵ ਅਨੁਮਾਨਤਾ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ।
