ਹਰ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਚਾਹੁੰਦੀ ਹੈ ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਮੁਸ਼ਕਲ ਦੇ ਵਧੇ। ਅਸੀਂ ਕਲਪਨਾ ਕਰਦੇ ਹਾਂ ਕਿ ਟ੍ਰੈਫਿਕ ਸੁਚਾਰੂ ਰੂਪ ਵਿੱਚ ਵਧ ਰਿਹਾ ਹੈ, ਸਰਵਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੱਲ ਰਹੇ ਹਨ, ਅਤੇ ਮਾਲੀਆ (revenue) ਲਗਾਤਾਰ ਵਧ ਰਿਹਾ ਹੈ। ਫਿਰ ਅਸਲੀਅਤ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਇੱਕ ਵਾਇਰਲ ਮਾਰਕੀਟਿੰਗ ਕੈਂਪੇਨ ਯੂਜ਼ਰਾਂ ਦੀ ਲਹਿਰ ਭੇਜ ਦਿੰਦੀ ਹੈ, ਡਾਟਾਬੇਸ ਲਾਕ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਰਾਤ ਦੇ ਤਿੰਨ ਵਜੇ ਜਲਦੀ-ਜਲਦੀ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਸਾਡਾ ਪਹਿਲਾ ਜਵਾਬ ਸਾਧਨਾਂ (tools) ਨੂੰ ਦੋਸ਼ ਦੇਣਾ ਹੁੰਦਾ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਦੱਸਦੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਹੋਰ ਕੋਰਸ, ਤੇਜ਼ ਡਿਸਕਾਂ, ਜਾਂ ਇੱਕ ਹੋਰ ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਦੀ ਲੋੜ ਸੀ। ਪਰ ਵਿਕਾਸ (growth) ਹਾਰਡਵੇਅਰ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਢਾਂਚੇ (structure) ਤੋਂ ਆਉਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ ਨੀਂਹ ਭਾਰ ਨੂੰ ਵੰਡਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ, ਤਾਂ ਹਰ ਨਵਾਂ ਯੂਜ਼ਰ ਜਿੱਤ ਦੀ ਬਜਾਏ ਇੱਕ ਬੋਝ ਬਣ ਜਾਂਦਾ ਹੈ।
ਟੂਲ ਇੱਕ ਟੁੱਟੇ ਹੋਏ ਅਧਾਰ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਬਚਾ ਸਕਦੇ
ਤੁਸੀਂ ਸੌ ਕਲਾਊਡ ਇੰਸਟੈਂਸ (cloud instances) ਚਲਾ ਸਕਦੇ ਹੋ, ਵੱਖ-ਵੱਖ ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਦੇ ਵਿਚਕਾਰ ਲੋਡ ਬੈਲੇਂਸਰ ਜੋੜ ਸਕਦੇ ਹੋ, ਅਤੇ ਹਰ ਸਟੈਟਿਕ ਐਸੇਟ ਨੂੰ ਗਲੋਬਲ ਕੰਟੈਂਟ ਡਿਲੀਵਰੀ ਨੈੱਟਵਰਕ ਵਿੱਚ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਸਭ ਫੋਰਸ ਮਲਟੀਪਲਾਈਅਰ ਹਨ। ਫਿਰ ਵੀ, ਜ਼ੀਰੋ ਨੂੰ ਗੁਣਾ ਕਰਨ ਨਾਲ ਵੀ ਤੁਹਾਨੂੰ ਜ਼ੀਰੋ ਹੀ ਮਿਲਦਾ ਹੈ। ਗੁੰਝਲਦਾਰ ਨਿਰਭਰਤਾਵਾਂ (dependencies) ਵਾਲੀ ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੇ ਹੀ ਭਾਰ ਹੇਠ ਦਬ ਜਾਵੇਗੀ, ਚਾਹੇ ਉਸ ਦੇ ਹੇਠਾਂ ਕਿੰਨਾ ਵੀ ਮੈਟਲ (hardware) ਕਿਉਂ ਨਾ ਹੋਵੇ।
ਇੱਕ ਆਨਲਾਈਨ ਸਟੋਰ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿੱਥੇ ਪ੍ਰੋਡਕਟ ਕੈਟਾਲਾਗ, ਭੁਗਤਾਨ ਪ੍ਰੋਸੈਸਿੰਗ, ਅਤੇ ਯੂਜ਼ਰ ਅਥੈਂਟੀਕੇਸ਼ਨ ਸਭ ਇੱਕ ਸਿੰਗਲ ਕੋਡਬੇਸ ਵਿੱਚ ਹਨ। ਜਦੋਂ ਚੈੱਕਆਊਟ ਪ੍ਰਕਿਰਿਆ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪੂਰੀ ਸਾਈਟ ਬਹੁਤ ਹੌਲੀ ਚੱਲਣ ਲੱਗਦੀ ਹੈ। ਲੌਗਇਨ ਪੇਜ ਅਟਕਣ ਲੱਗਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਿੰਗ ਦਾ ਅਨੁਭਵ ਖਰਾਬ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਬਾਕੀ ਸਭ ਕੁਝ ਸਕੇਲ ਕੀਤੇ ਬਿਨਾਂ ਬੋਟਲਨੇਕ (bottleneck) ਨੂੰ ਸਕੇਲ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਹ ਮਹਿੰਗਾ, ਅਕੁਸ਼ਲ ਅਤੇ ਨਾਜ਼ੁਕ ਹੈ। ਤੁਸੀਂ ਅਜਿਹੀ ਕੰਪਿਊਟ ਪਾਵਰ ਲਈ ਪੈਸੇ ਖਰਚਦੇ ਹੋ ਜਿਸਦਾ ਕਿਸੇ ਨੂੰ ਫਾਇਦਾ ਨਹੀਂ ਹੁੰਦਾ, ਜਦੋਂ ਕਿ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਉਨ੍ਹਾਂ ਪੇਜਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਰੰਤ ਲੋਡ ਹੋਣੇ ਚਾਹੀਦੇ ਸਨ।
ਆਰਕੀਟੈਕਚਰ ਇਸ ਜਾਲ ਦਾ ਹੱਲ ਹੈ। ਇਹ ਉਹ ਅਦਿੱਖ ਢਾਂਚਾ ਹੈ ਜੋ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟੂਲ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਰਹੇ ਹਨ ਜਾਂ ਨੁਕਸਾਨ।
ਇੱਕ ਮਜ਼ਬੂਤ ਆਰਕੀਟੈਕਚਰ ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ
ਇੱਕ ਮਜ਼ਬੂਤ ਆਰਕੀਟੈਕਚਰ ਸਿਰਫ਼ ਇਸ ਗੱਲ ਦੀ ਯੋਜਨਾ ਹੈ ਕਿ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਕਿੱਥੇ ਹੋਣੀਆਂ ਹਨ। ਇਹ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਅਸੁਖਾਵਾਂ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਹਿੱਸਾ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਕੀ ਤੁਸੀਂ ਰਿਕਾਰਮੈਂਡੇਸ਼ਨ ਇੰਜਣ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਬਿਲਿੰਗ ਲੌਜਿਕ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ? ਕੀ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਇੱਕ ਕੋਨੇ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਦਾ ਵਾਧਾ ਬਾਕੀ ਸਿਸਟਮ ਨੂੰ ਆਮ ਤਰੀਕੇ ਨਾਲ ਚੱਲਣ ਦੇਣ ਦੇ ਯੋਗ ਹੈ? ਇਹ ਸਵਾਲ ਤੁਹਾਡੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ, ਫਰੇਮਵਰਕ, ਜਾਂ ਕਲਾਊਡ ਪ੍ਰੋਵਾਈਡਰ ਦੀ ਚੋਣ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹਨ।
ਚੰਗਾ ਆਰਕੀਟੈਕਚਰ ਤੁਹਾਨੂੰ ਆਪਣੇ ਫੈਸਲੇ ਬਦਲਣ ਦੀ ਥਾਂ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਇੱਕ ਟੀਮ ਦਾ ਪ੍ਰਯੋਗ ਦੂਜੀ ਟੀਮ ਦੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਲੋਡ ਨੂੰ ਅਸਥਿਰ ਨਾ ਕਰ ਦੇਵੇ। ਇਹ ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਹੈਰਾਨੀ ਦੀ ਬਜਾਏ ਇੱਕ ਆਮ ਸੰਚਾਲਨ ਸਥਿਤੀ ਵਜੋਂ ਲੈਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਅਸਫਲਤਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕੱਚ ਦੇ ਘਰ ਬਣਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਅਜਿਹੇ ਢਾਂਚੇ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਜੋ ਲਚਕਦਾਰ ਹੁੰਦੇ ਹਨ।
ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਇੱਕ ਵਿਵਹਾਰਕ ਪੈਟਰਨ ਵਜੋਂ
ਉਸ ਤਰ੍ਹਾਂ ਦੇ ਢਾਂਚੇ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਇੱਕ ਵਿਵਹਾਰਕ ਤਰੀਕਾ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਵੰਡਣਾ ਹੈ। ਇੱਕ ਵਿਸ਼ਾਲ ਕੋਡਬੇਸ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਐਪ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹੋ। ਹਰ ਹਿੱਸਾ ਇੱਕ ਖਾਸ ਕੰਮ ਸੰਭਾਲਦਾ ਹੈ। ਪੇਮੈਂਟ ਸਰਵਿਸ ਲੈਣ-ਦੇਣ (transactions) ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦੀ ਹੈ। ਇਨਵੈਂਟਰੀ ਸਰਵਿਸ ਸਟਾਕ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੀ ਹੈ। ਨੋਟੀਫਿਕੇਸ਼ਨ ਸਰਵਿਸ ਈਮੇਲ ਅਤੇ ਟੈਕਸਟ ਮੈਸੇਜ ਭੇਜਦੀ ਹੈ। ਉਹ ਡਾਇਰੈਕਟ ਮੈਮੋਰੀ ਐਕਸੈਸ ਜਾਂ ਸਾਂਝੇ ਡਾਟਾਬੇਸ ਟੇਬਲਾਂ ਦੀ ਬਜਾਏ ਨਿਰਧਾਰਤ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਆਪਸ ਵਿੱਚ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ।
ਇਹ ਵੱਖਰੇਵੇਂ ਤਕਨੀਕੀ ਅਤੇ ਸੰਗਠਨਾਤਮਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਅਸਲ ਮੌਕਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।
ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਛੋਟੇ ਹਿੱਸਿਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ
ਜਦੋਂ ਸਰਵਿਸਿਜ਼ ਛੋਟੀਆਂ ਅਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਕੈਸਕੇਡ ਫੇਲ੍ਹਅਰ (cascade failure) ਦੇ ਜੋਖਮ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਪੈਚ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਸ਼ਿਪਿੰਗ ਕੈਲਕੂਲੇਸ਼ਨ ਐਲਗੋਰਿਦਮ ਵਿੱਚ ਕੋਈ ਬੱਗ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਸਰਵਿਸ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਡਿਪਲੋਏ ਕਰਦੇ ਹੋ। ਬਾਕੀ ਐਪਲੀਕੇਸ਼ਨ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ। ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਪ੍ਰੋਡਕਟ ਦੇਖ ਸਕਦੇ ਹਨ, ਲੌਗਇਨ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਆਪਣੇ ਕਾਰਟ ਵਿੱਚ ਚੀਜ਼ਾਂ ਜੋੜ ਸਕਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਇੱਕ ਬਦਲਾਅ ਦਾ ਪ੍ਰਭਾਵ (blast radius) ਬਹੁਤ ਘੱਟ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਦੀ ਤੁਲਨਾ ਇੱਕ ਮੋਨੋਲਿਥ ਨਾਲ ਕਰੋ ਜਿੱਥੇ ਇੱਕ ਹੈਲਪਰ ਫੰਕਸ਼ਨ ਵਿੱਚ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਗਲਤੀ ਚੈੱਕਆਊਟ, ਰਜਿਸਟ੍ਰੇਸ਼ਨ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਸਭ ਨੂੰ ਇੱਕੋ ਵਾਰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਵਧਦਾ ਹੈ ਤਾਂ ਖਾਸ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਸਕੇਲ ਕਰੋ
ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਕਦੇ ਵੀ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਫਲੈਸ਼ ਸੇਲ ਦੌਰਾਨ, ਤੁਹਾਡੀ ਆਰਡਰ ਪਾਈਪਲਾਈਨ 'ਤੇ ਦਬਾਅ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ ਕੰਟੈਂਟ ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮ ਲਗਭਗ ਵਿਹਲਾ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਟਾਈਟਲੀ ਕਪਲਡ ਸਿਸਟਮ ਵਿੱਚ, ਤੁਸੀਂ ਜਾਂ ਤਾਂ ਸਭ ਕੁਝ ਸਕੇਲ ਕਰਦੇ ਹੋ ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ। ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਪਣੇ ਸਰੋਤਾਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਨਿਸ਼ਾਨਾ ਬਣਾ ਸਕਦੇ ਹੋ। ਚੈੱਕਆਊਟ ਸਰਵਿਸ ਦੇ ਹੋਰ ਇੰਸਟੈਂਸ ਚਲਾਓ। ਪ੍ਰੋਡਕਟ ਕੈਟਾਲਾਗ ਨੂੰ ਉਸਦੇ ਆਮ ਪੱਧਰ 'ਤੇ ਚੱਲਣ ਦਿਓ। ਕਿਸੇ ਉਤਪਾਦ ਦੀ ਲਾਂਚਿੰਗ ਦੌਰਾਨ, ਤੁਹਾਡੇ ਇਮੇਜ ਪ੍ਰੋਸੈਸਿੰਗ ਵਰਕਰ ਹਜ਼ਾਰਾਂ ਥੰਬਨੇਲ ਬਣਾ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ ਸਰਚ ਇੰਡੈਕਸ ਸ਼ਾਂਤ ਰਹੇਗਾ। ਸਿਰਫ਼ ਇਮੇਜ ਵਰਕਰਾਂ ਦੀ ਲੋੜ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਸਰਚ ਕਲੱਸਟਰ ਨੂੰ ਵਧਾਉਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਉੱਥੇ ਪੈਸਾ ਖਰਚਦੇ ਹੋ ਜਿੱਥੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਸਿਸਟਮ ਦਬਾਅ ਹੇਠ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਲੰਬੇ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਨਵਾਂ ਕੋਡ ਡਿਪਲੋਏ ਕਰੋ
ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਅਜਿਹੇ ਡਿਪਲੋਏਮੈਂਟ ਪੈਟਰਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਮੇਨਟੇਨੈਂਸ ਵਿੰਡੋਜ਼ (maintenance windows) ਦੀ ਲੋੜ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਰੋਲਿੰਗ ਡਿਪਲੋਏਮੈਂਟਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਬਾਕੀ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਭਾਲਦੇ ਹੋਏ ਕੁਝ ਇੰਸਟੈਂਸਾਂ 'ਤੇ ਨਵਾਂ ਕੋਡ ਪੁਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਪਣੀਆਂ ਗਲਤੀਆਂ ਦੀ ਦਰ (error rates) 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ, ਅਤੇ ਜੇਕਰ ਕੁਝ ਗਲਤ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਹੀ ਸਕਿੰਟਾਂ ਵਿੱਚ ਰਿਕੁਐਸਟਾਂ ਨੂੰ ਪਿਛਲੇ ਵਰਜ਼ਨ 'ਤੇ ਵਾਪਸ ਭੇਜ ਦਿਓ। ਬਲੂ-ਗ੍ਰੀਨ ਡਿਪਲੋਏਮੈਂਟਸ ਤੁਹਾਨੂੰ ਇੱਕ ਬਿਲਕੁਲ ਨਵਾਂ ਮਾਹੌਲ (environment) ਤਿਆਰ ਕਰਨ, ਉਸਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਬਹੁਤ ਘੱਟ ਜੋਖਮ ਨਾਲ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਵੱਲ ਮੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਸਿਸਟਮ ਨੂੰ ਘੰਟਿਆਂ ਲਈ ਬੰਦ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ ਜਦੋਂ ਕੋਈ ਮੈਨੂਅਲੀ ਡਾਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਨਵੀਆਂ ਫੀਚਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਓ
ਵੱਡੇ ਕੋਡਬੇਸ ਸਾਵਧਾਨੀ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਇੱਕੋ ਬਦਲਾਅ ਲਈ ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਦੇ ਅਸੰਬੰਧਿਤ ਲੌਜਿਕ ਨੂੰ ਸਮਝਣ, ਘੰਟਿਆਂ ਲੱਗਣ ਵਾਲੇ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟਾਂ, ਅਤੇ ਅਜਿਹੇ ਡਿਪਲੋਏਮੈਂਟ ਸ਼ਡਿਊਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਰਾਕੇਟ ਲਾਂਚ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਉਸ ਡਰ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਟੀਮ ਉਸ ਸੇਵਾ ਵਿੱਚ ਕੁਝ ਸੌ ਲਾਈਨਾਂ ਨੂੰ ਬਦਲ ਕੇ ਨਵਾਂ ਫੀਚਰ ਬਣਾ ਸਕਦੀ ਹੈ ਜਿਸ ਨੂੰ ਉਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦੇ ਹਨ। ਉਹ ਉਸੇ ਦਿਨ ਕਮਿਟ, ਟੈਸਟ ਅਤੇ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹਨ। ਉਹ ਗਤੀ ਵਧਦੀ ਜਾਂਦੀ ਹੈ। ਜਦੋਂ ਸੇਵਾਵਾਂ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨਾਲ ਬੱਝੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਟੀਮਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਕੰਮ ਵਿੱਚ ਦਖਲ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਉਹ ਆਪਣੇ ਡੋਮੇਨ ਦੇ ਪੂਰੇ ਪ੍ਰਬੰਧ ਦੇ ਮਾਲਕ ਹੁੰਦੇ ਹਨ।
ਸੁਤੰਤਰਤਾ ਵੱਡੀਆਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ
ਹਰ ਸੇਵਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ। ਉਹ ਸੁਤੰਤਰਤਾ ਸਿਰਫ਼ ਇੱਕ ਸੰਗਠਨਾਤਮਕ ਸਹੂਲਤ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਸੰਰਚਨਾਤਮਕ ਬੀਮਾ (structural insurance) ਹੈ। ਜੇਕਰ ਰਿਕਾਰਮੈਂਡੇਸ਼ਨ ਇੰਜਣ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵੀ ਸਟੋਰ ਨੂੰ ਉਤਪਾਦ ਵੇਚਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇਕਰ ਐਨਾਲਿਟਿਕਸ ਪਾਈਪਲਾਈਨ ਕਿਸੇ ਗਲਤ ਈਵੈਂਟ ਕਾਰਨ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਲੌਗਇਨ ਸੇਵਾ ਨੂੰ ਅਜੇ ਵੀ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਪਛਾਣ (authenticate) ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਤੁਸੀਂ ਸੇਵਾਵਾਂ ਦੇ ਵਿਚਕਾਰ ਸਰਕਟ ਬ੍ਰੇਕਰ ਅਤੇ ਫਾਲਬੈਕ ਪਾਥ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ ਇੱਕ ਅਸਫਲਤਾ ਪੂਰੇ ਸਿਸਟਮ ਦੇ ਬੰਦ ਹੋਣ ਦਾ ਕਾਰਨ ਨਾ ਬਣੇ। ਸਿਸਟਮ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨਾਲ ਵਧਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟੁੱਟੇ ਬਿਨਾਂ ਤਣਾਅ ਨੂੰ ਸਹਿ ਸਕਦਾ ਹੈ।
ਇੱਕ ਚੇਤਾਵਨੀ: ਅੰਨ੍ਹੇਵਾਹ ਵੰਡ ਨਾ ਕਰੋ
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਹੀ ਆਪਣੇ ਕੋਡਬੇਸ ਨੂੰ ਵੰਡ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਲਈ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀਆਂ ਟੀਮਾਂ ਨੂੰ ਅਜੇ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਇੱਕ ਡੋਮੇਨ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਿਸਟਮ ਦੀ ਬਜਾਏ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਮੈੱਸ (ਗੜਬੜ) ਬਣਾ ਦੇਣਗੇ। ਤੁਸੀਂ ਕੋਡ ਦੀ ਗੁੰਝਲਤਾ ਦੇ ਬਦਲੇ ਸੰਚਾਲਨ (operational) ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਅਪਣਾ ਲਵੋਗੇ, ਅਤੇ ਅਚਾਨਕ ਤੁਸੀਂ ਦਰਜਨਾਂ ਲੌਗ ਸਟ੍ਰੀਮਜ਼ ਵਿੱਚ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ, ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਟ੍ਰਾਂਜੈਕਸ਼ਨ, ਰੀਟ੍ਰਾਈ ਸਟੋਰਮਜ਼ ਅਤੇ ਓਬਜ਼ਰਵੇਬਿਲਟੀ ਦਾ ਪ੍ਰਬੰਧ ਕਰ ਰਹੇ ਹੋਵੋਗੇ। ਹੁਣ ਇੱਕ ਸੁਸਤ ਚੈੱਕਆਊਟ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਦਾ ਮਤਲਬ ਚਾਰ ਨੈੱਟਵਰਕ ਹੌਪਸ ਅਤੇ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਡਾਟਾ ਸਟੋਰਜ਼ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਰਿਕੁਐਸਟ ਨੂੰ ਟਰੇਸ ਕਰਨਾ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇਕਰ ਤੁਹਾਡੀ ਟੀਮ ਉਸ ਵਾਧੂ ਬੋਝ (tax) ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਲਾਜ ਬਿਮਾਰੀ ਨਾਲੋਂ ਵੀ ਮਾੜਾ ਹੋਵੇਗਾ। ਕਈ ਵਾਰ ਸਮਝਦਾਰੀ ਵਾਲਾ ਕਦਮ ਇੱਕ ਮੋਡਿਊਲਰ ਮੋਨੋਲਿਥ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਕੋਡਬੇਸ ਦੇ ਅੰਦਰ ਭੁਗਤਾਨ (payment) ਲੌਜਿਕ ਨੂੰ ਇਨਵੈਂਟਰੀ ਲੌਜਿਕ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਭਾਵੇਂ ਉਹ ਇਕੱਠੇ ਡਿਪਲੋਏ ਹੁੰਦੇ ਹੋਣ। ਇੰਟਰਨਲ APIs ਅਤੇ ਇੱਕੋ ਇੰਜਣ ਦੇ ਅੰਦਰ ਵੱਖ-ਵੱਖ ਡਾਟਾਬੇਸ ਸਕੀਮਾ ਨਾਲ ਸੀਮਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰੋ। ਜਦੋਂ ਉਹ ਸੀਮਾਵਾਂ ਸਥਿਰ ਸਾਬਤ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ ਓਵਰਹੈੱਡ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਸੇਵਾ ਨੂੰ ਵੱਖ ਕਰੋ। ਆਰਕੀਟੈਕਚਰ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਏ ਗਏ ਦਰਵਾਜ਼ਿਆਂ ਦੀ ਇੱਕ ਲੜੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਉਹ ਕੰਧਾਂ ਜੋ ਕਿਸੇ ਬਲੌਗ ਪੋਸਟ ਨੂੰ ਪੜ੍ਹ ਕੇ ਰਾਤੋ-ਰਾਤ ਬਣਾਈਆਂ ਗਈਆਂ ਹੋਣ।
ਇਰਾਦੇ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ
ਮਜ਼ਬੂਤ ਆਰਕੀਟੈਕਚਰ ਦਾ ਮਤਲਬ ਅੱਜ ਤੋਂ ਪੰਜ ਸਾਲ ਬਾਅਦ ਦੇ ਟ੍ਰੈਫਿਕ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਇਹ ਆਪਣੇ ਆਪ ਨੂੰ ਵਿਕਲਪ ਦੇਣ ਬਾਰੇ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਵੈੱਬ ਐਪ ਨੂੰ ਵਧਾਉਣ ਲਈ ਸਿਰਫ਼ ਟੂਲਜ਼ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਤੁਸੀਂ ਦਬਾਅ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁਸੀਬਤ ਤੋਂ ਬਚਣ ਲਈ ਸੋਚ ਸਕਦੇ ਹੋ। ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਵਿਚਕਾਰ ਸੀਮਾਵਾਂ ਦਾ ਸਤਿਕਾਰ ਕਰੋ। ਛੋਟੇ, ਕੇਂਦ੍ਰਿਤ ਹਿੱਸੇ ਬਣਾਓ ਜੋ ਆਪਣੇ ਭਵਿੱਖ ਦੇ ਮਾਲਕ ਹੋਣ। ਟੀ