ਅਸਲ ਦੁਨੀਆ ਵਿੱਚ ਟਿਕਣ ਵਾਲਾ Azure ਬਣਾਉਣਾ — Mike Martin [MVP] ਨਾਲ

Azure ਆਰਕੀਟੈਕਚਰ ਉਦੋਂ ਆਸਾਨ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਸਭ ਕੁਝ ਠੀਕ ਚੱਲ ਰਿਹਾ ਹੋਵੇ। ਅਸਲ ਪਰਖ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਡਿਪੈਂਡੈਂਸੀਆਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ, ਰੀਜਨ ਉਪਲਬਧ ਨਹੀਂ ਰਹਿੰਦੇ, ਟ੍ਰੈਫਿਕ ਅਚਾਨਕ ਵਧਦਾ ਹੈ, ਧਾਰਨਾਵਾਂ ਗਲਤ ਸਾਬਤ ਹੁੰਦੀਆਂ ਹਨ, ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਕੋਈ ਨਾ ਕੋਈ ਆਖ਼ਰਕਾਰ ਇਹ ਅਸਹਿਜ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ: ਅਸੀਂ ਇਹ ਡਿਜ਼ਾਈਨ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਕਿਉਂ ਚੁਣਿਆ ਸੀ? M365.FM ਦੇ ਇਸ ਐਪੀਸੋਡ ਵਿੱਚ Mirko Peters ਅਤੇ Mike Martin [MVP] ਗੱਲ ਕਰਦੇ ਹਨ ਕਿ ਜਦੋਂ Azure ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਿਰਫ਼ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਚੰਗਾ ਦਿਖਣ ਦੀ ਬਜਾਏ ਅਸਲ ਉਤਪਾਦਨ ਹਾਲਾਤਾਂ ਵਿੱਚ ਟਿਕਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਕਿਹੋ ਜਿਹਾ ਦਿਖਦਾ ਹੈ। Mike ਕੋਲ ਡਿਵੈਲਪਮੈਂਟ, ਇਨਫਰਾਸਟ੍ਰਕਚਰ, ਆਰਕੀਟੈਕਚਰ, ਲੀਡਰਸ਼ਿਪ, ਕੋਚਿੰਗ, ਟ੍ਰੇਨਿੰਗ ਅਤੇ Microsoft Azure ਵਿੱਚ ਦਹਾਕਿਆਂ ਦਾ ਤਜਰਬਾ ਹੈ। ਉਨ੍ਹਾਂ ਦੀ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਟਿੱਪਣੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਆਰਕੀਟੈਕਟਾਂ ਨੂੰ ਅੱਜ ਜੋ ਸਮੱਸਿਆਵਾਂ ਆਉਂਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਈ ਅਸਲ ਵਿੱਚ ਨਵੀਆਂ ਨਹੀਂ ਹਨ। DNS ਅੱਜ ਵੀ ਟੁੱਟਦਾ ਹੈ। IP ਡਿਪੈਂਡੈਂਸੀਆਂ ਅੱਜ ਵੀ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ। ਲਾਗਤਾਂ ਅੱਜ ਵੀ ਸਮੱਸਿਆ ਬਣਦੀਆਂ ਹਨ। ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਅੱਜ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ। ਅਤੇ ਡਿਪੈਂਡੈਂਸੀਆਂ ਅੱਜ ਵੀ ਸਭ ਤੋਂ ਮਾੜੇ ਸਮੇਂ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਬਦਲਿਆ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕਿੰਨੀ ਗੁੰਝਲਤਾ ਬਣਾਉਂਦੇ ਹਾਂ। ਪੁਰਾਣੇ Visual Basic ਤੋਂ ਆਧੁਨਿਕ Azure ਆਰਕੀਟੈਕਚਰ ਤੱਕ Mike ਲਗਭਗ ਤਿੰਨ ਦਹਾਕਿਆਂ ਦੇ IT ਸਫ਼ਰ ਨੂੰ ਯਾਦ ਕਰਦੇ ਹਨ, ਜੋ 1990 ਦੇ ਦਹਾਕੇ ਵਿੱਚ Visual Basic ਡਿਵੈਲਪਰ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਅਤੇ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਸਿਸਟਮ, ਨੈੱਟਵਰਕਿੰਗ, ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਾਫ਼ਟਵੇਅਰ, ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਅਤੇ ਆਖ਼ਰਕਾਰ Azure ਤੱਕ ਪਹੁੰਚਿਆ। ਉਨ੍ਹਾਂ ਦੀ ਮੁੱਖ ਨਿਰੀਖਣ ਸਧਾਰਨ ਹੈ: ਇੰਡਸਟਰੀ ਉਹੀ ਬੁਨਿਆਦੀ ਸਮੱਸਿਆਵਾਂ ਵਾਰ-ਵਾਰ ਹੱਲ ਕਰਦੀ ਆ ਰਹੀ ਹੈ, ਪਰ ਉਨ੍ਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੇ ਆਰਕੀਟੈਕਚਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹੋ ਗਏ ਹਨ। ਆਧੁਨਿਕ ਸਿਸਟਮ ਕਲਾਇੰਟ-ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਆਰਕੀਟੈਕਚਰ, ਕਲਾਊਡ ਪਲੇਟਫਾਰਮ, ਕੰਟੇਨਰ, ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼, Kubernetes, ਹਾਈਬ੍ਰਿਡ ਵਾਤਾਵਰਣ ਅਤੇ ਹੁਣ AI-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਡਿਵੈਲਪਮੈਂਟ ਤੱਕ ਪਹੁੰਚ ਗਏ ਹਨ। ਇਸ ਨਾਲ ਬੇਅੰਤ ਸੰਭਾਵਨਾਵਾਂ ਬਣਦੀਆਂ ਹਨ, ਪਰ ਇੱਕ ਨਵਾਂ ਖ਼ਤਰਾ ਵੀ ਆਉਂਦਾ ਹੈ: ਓਵਰ-ਇੰਜੀਨੀਅਰਿੰਗ। Mike ਦਲੀਲ ਦਿੰਦੇ ਹਨ ਕਿ ਅੱਜ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਸਧਾਰਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਬੇਲੋੜਾ ਗੁੰਝਲਦਾਰ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ। ਚੰਗਾ ਆਰਕੀਟੈਕਚਰ ਅਕਸਰ ਹੋਰ ਤਕਨਾਲੋਜੀ ਜੋੜਨ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਜਾਣਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਨਹੀਂ ਜੋੜਨਾ ਚਾਹੀਦਾ। ਇੱਕ Azure ਆਰਕੀਟੈਕਟ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ? Mike ਲਈ ਆਰਕੀਟੈਕਚਰ ਦਾ ਮਤਲਬ ਸਭ ਤੋਂ ਵੱਧ Azure ਸਰਵਿਸਾਂ ਚੁਣਨਾ ਜਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਡਾਇਗ੍ਰਾਮ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਸਮਝਣ ਬਾਰੇ ਹੈ ਕਿ ਕਿਹੜੇ ਕੰਪੋਨੈਂਟ ਇਕੱਠੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਹੜੇ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਹੜੇ ਜ਼ਰੂਰੀ ਹਨ, ਅਤੇ ਅਜਿਹਾ ਕੁਝ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਜੋ ਸੰਭਾਲਣਯੋਗ, ਸਕੇਲੇਬਲ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਲਚਕੀਲਾ ਹੋਵੇ। ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਕੰਪਿਊਟ ਤੋਂ ਕਿਤੇ ਵੱਧ ਸ਼ਾਮਲ ਹੈ: - ਪਛਾਣ (Identity) - ਨੈੱਟਵਰਕਿੰਗ - ਡੇਟਾ ਫਲੋ - ਸੁਰੱਖਿਆ - ਮਾਨੀਟਰਿੰਗ - ਇੰਟੀਗ੍ਰੇਸ਼ਨ - ਡਿਪੈਂਡੈਂਸੀਆਂ - ਸਕੇਲੇਬਿਲਟੀ - ਓਪਰੇਸ਼ਨ - ਰਿਕਵਰੀ - ਡਿਪਲਾਇਮੈਂਟ - ਲਾਗਤ Mike ਇਸ ਧਾਰਨਾ ਨੂੰ ਵੀ ਚੁਣੌਤੀ ਦਿੰਦੇ ਹਨ ਕਿ cloud-native ਦਾ ਮਤਲਬ ਆਪਣੇ-ਆਪ Kubernetes ਜਾਂ ਕੰਟੇਨਰ ਹੈ। Azure ਕਈ ਮੈਨੇਜਡ ਅਤੇ ਨੇਟਿਵ ਸਰਵਿਸਾਂ ਦਿੰਦਾ ਹੈ ਜੋ ਬਿਨਾਂ ਬੇਲੋੜੇ ਓਪਰੇਸ਼ਨਲ ਬੋਝ ਦੇ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਆਰਕੀਟੈਕਟ ਦੀ ਭੂਮਿਕਾ ਪੂਰੇ ਹੱਲ ਨੂੰ ਸਮਝਣਾ ਅਤੇ ਸਭ ਤੋਂ ਸਧਾਰਨ ਆਰਕੀਟੈਕਚਰ ਚੁਣਨਾ ਹੈ ਜੋ ਫਿਰ ਵੀ ਅਸਲ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰੇ। ਤਕਨਾਲੋਜੀ ਨਾਲ ਨਹੀਂ, ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਇਸ ਐਪੀਸੋਡ ਦਾ ਇੱਕ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਬਕ ਸਧਾਰਨ ਹੈ: ਤਕਨਾਲੋਜੀ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। Azure Kubernetes Service, App Service, Azure Functions, ਕੰਟੇਨਰ, Service Bus ਜਾਂ ਕਿਸੇ ਹੋਰ ਪਲੇਟਫਾਰਮ ਵਿੱਚੋਂ ਚੋਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟੀਮਾਂ ਨੂੰ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹੱਲ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪੁੱਛਣ ਯੋਗ ਸਵਾਲ: - ਕੀ ਇਹ ਅੰਦਰੂਨੀ ਹੈ ਜਾਂ ਗਾਹਕਾਂ ਲਈ? - ਕਿੰਨੇ ਉਪਭੋਗਤਾ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੋਣਗੇ? - ਕੀ ਇਸਨੂੰ ਗਲੋਬਲੀ ਸਕੇਲ ਕਰਨਾ ਪਵੇਗਾ? - ਇਹ ਕਿੰਨੀ ਦੇਰ ਬੰਦ ਰਹਿ ਸਕਦਾ ਹੈ? - ਕਾਰੋਬਾਰ ਕਿੰਨਾ ਡੇਟਾ ਗੁਆਉਣਾ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ? - ਕਿਹੜੀਆਂ ਪਾਲਣਾ (compliance) ਲੋੜਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ? - ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਕਈ ਘੰਟਿਆਂ ਲਈ ਗਾਇਬ ਹੋ ਜਾਵੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? - ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੋਵੇਗਾ? - ਕਿੰਨੇ ਪੱਧਰ ਦੀ ਓਪਰੇਸ਼ਨਲ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਹੈ? ਇਹ ਸਵਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ SLA, SLO, RTO ਅਤੇ RPO ਵਰਗੀਆਂ ਧਾਰਨਾਵਾਂ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ। ਇਹ ਇਹ ਵੀ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਆਰਕੀਟੈਕਚਰ ਸਿੰਗਲ-ਰੀਜਨ, ਮਲਟੀ-ਰੀਜਨ, ਐਕਟਿਵ-ਐਕਟਿਵ, ਐਕਟਿਵ-ਪੈਸਿਵ ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਸਰਲ ਹੋਵੇ। RTO ਅਤੇ RPO, ਬਿਨਾਂ ਜਟਿਲ ਸ਼ਬਦਾਵਲੀ ਦੇ RTO ਅਤੇ RPO ਨੂੰ ਅਕਸਰ ਤਕਨੀਕੀ ਸੰਖੇਪ ਰੂਪਾਂ ਵਜੋਂ ਚਰਚਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਨ੍ਹਾਂ ਦਾ ਅਸਲ ਅਰਥ ਕਾਰੋਬਾਰੀ ਹੈ। - RTO (Recovery Time Objective): ਕਿਸੇ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਸਿਸਟਮ ਕਿੰਨੀ ਜਲਦੀ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ? - RPO (Recovery Point Objective): ਕਿੰਨਾ ਡੇਟਾ ਨੁਕਸਾਨ ਸਵੀਕਾਰਯੋਗ ਹੈ? ਗੈਰ-ਮਹੱਤਵਪੂਰਨ ਮਾਨੀਟਰਿੰਗ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਸਿਸਟਮ ਕਈ ਘੰਟਿਆਂ ਦਾ ਡਾਊਨਟਾਈਮ ਜਾਂ ਡੇਟਾ ਨੁਕਸਾਨ ਬਰਦਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਪਹਿਲੇ ਜਵਾਬਦਾਤਾਵਾਂ (first responders), ਵਿੱਤੀ ਕਾਰਜਾਂ, ਈ-ਕਾਮਰਸ ਜਾਂ ਮਹੱਤਵਪੂਰਨ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸਹਾਇਤਾ ਦੇਣ ਵਾਲੇ ਸਿਸਟਮ ਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਰਿਕਵਰ ਹੋਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਅੰਕੜੇ ਆਰਕੀਟੈਕਟ ਆਪਣੇ ਮਨ ਤੋਂ ਨਹੀਂ ਬਣਾਉਣੇ ਚਾਹੀਦੇ। ਇਹ ਅਸਫਲਤਾ ਦੇ ਅਸਲ ਕਾਰੋਬਾਰੀ ਪ੍ਰਭਾਵ ਤੋਂ ਆਉਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਲੋੜਾਂ ਸਮਝਣ ਤੋਂ ਬਾਅਦ, ਇਨ੍ਹਾਂ ਨੂੰ ਤਕਨੀਕੀ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਰੈਜ਼ੀਲੀਅੰਸ ਹਾਈ ਅਵੇਲੇਬਿਲਟੀ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ Mike ਅਵੇਲੇਬਿਲਟੀ ਅਤੇ ਰੈਜ਼ੀਲੀਅੰਸ ਦਾ ਅੰਤਰ ਸਮਝਾਉਣ ਲਈ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ ਵਰਤਦੇ ਹਨ। ਇੱਕ ਹਾਈਲੀ ਅਵੇਲੇਬਲ ਸਿਸਟਮ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਕੰਪੋਨੈਂਟ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਕੋਈ ਹੋਰ ਕੰਪੋਨੈਂਟ ਕੰਮ ਸੰਭਾਲਣ ਲਈ ਤਿਆਰ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਰੈਜ਼ੀਲੀਅੰਟ ਸਿਸਟਮ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸੋਖਣ, ਕੰਮ ਜਾਰੀ ਰੱਖਣ, ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਰਿਕਵਰ ਹੋਣ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਿੱਗਣ ਦੀ ਬਜਾਏ ਸਧਾਰਨ ਹਾਲਤ ਵਿੱਚ ਵਾਪਸ ਆਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਮਾੜਾ ਅਨੁਭਵ ਦੇ ਸਕਦੀ ਹੈ। ਉਹ ਹੌਲੀ ਹੋ ਸਕਦੀ ਹੈ, ਥ੍ਰੋਟਲ ਹੋ ਸਕਦੀ ਹੈ, ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਬੰਦ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਸੇ ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਬੈਕਐਂਡ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੀ ਹੈ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਸਮੱਸਿਆ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਖੇਤਰੀ ਦਬਾਅ ਹੇਠ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਅਸਲ ਰੈਜ਼ੀਲੀਅੰਸ ਲਈ ਸਿਰਫ਼ ਅੱਪਟਾਈਮ ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਲਈ ਅਜਿਹਾ ਆਰਕੀਟੈਕਚਰ ਚਾਹੀਦਾ ਹੈ ਜੋ ਲੋਡ, ਐਪਲੀਕੇਸ਼ਨ ਗਲਤੀਆਂ, ਅੰਸ਼ਕ ਅਸਫਲਤਾਵਾਂ, ਖੇਤਰੀ ਸਮੱਸਿਆਵਾਂ, ਟੁੱਟੀਆਂ ਡਿਪੈਂਡੈਂਸੀਆਂ, ਓਪਰੇਸ਼ਨਲ ਘਟਨਾਵਾਂ ਅਤੇ ਘਟਨਾ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਰਿਕਵਰੀ ਨਾਲ ਨਜਿੱਠ ਸਕੇ। Azure ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਆਪਣੇ-ਆਪ ਰੈਜ਼ੀਲੀਅੰਟ ਨਹੀਂ ਬਣਾਉਂਦਾ ਇੱਕ ਖ਼ਤਰਨਾਕ ਧਾਰਨਾ ਇਹ ਹੈ ਕਿ ਚੂੰਕਿ Azure ਆਪਣੇ-ਆਪ ਵਿੱਚ ਬਹੁਤ ਉਪਲਬਧ ਹੈ, ਇਸ 'ਤੇ ਚੱਲ ਰਹੀ ਕੋਈ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਇਹ ਰੈਜ਼ੀਲੀਅੰਸ ਆਪਣੇ-ਆਪ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦੀ ਹੈ। ਇਹ ਸੱਚ ਨਹੀਂ ਹੈ। Microsoft ਉਹ ਸਰਵਿਸਾਂ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਦਿੰਦਾ ਹੈ ਜੋ ਰੈਜ਼ੀਲੀਅੰਟ ਆਰਕੀਟੈਕਚਰ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਪਰ ਰੈਜ਼ੀਲੀਅੰਸ ਲਈ ਡਿਜ਼ਾਈਨ ਗਾਹਕ ਨੂੰ ਖੁਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇੱਥੇ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨ ਮਹੱਤਵਪੂਰਨ ਬਣਦੇ ਹਨ: - ਸਰਕਟ ਬ੍ਰੇਕਰ (Circuit breakers) - ਲੂਜ਼ ਕਪਲਿੰਗ (Loose coupling) - ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰੋਸੈਸਿੰਗ - ਸੁਤੰਤਰ ਸਕੇਲਿੰਗ - ਮਲਟੀਪਲ ਐਵੇਲੇਬਿਲਟੀ ਜ਼ੋਨ - ਮਲਟੀਪਲ ਰੀਜਨ - ਫੇਲਓਵਰ ਮਕੈਨਿਜ਼ਮ - ਮਾਨੀਟਰਿੰਗ - Infrastructure as Code - ਟੈਸਟ ਕੀਤੀਆਂ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ Microsoft ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਬਲਾਕ ਦਿੰਦਾ ਹੈ। ਆਰਕੀਟੈਕਚਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਬਲਾਕ ਅਸਲ ਵਿੱਚ ਰੈਜ਼ੀਲੀਅੰਟ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹਨ। ਅਸਿੰਕ੍ਰੋਨਸ ਡਿਜ਼ਾਈਨ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਐਪੀਸੋਡ ਦੀਆਂ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਉਦਾਹਰਣਾਂ ਉਨ੍ਹਾਂ ਸਿਸਟਮਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਅਨੁਮਾਨਯੋਗ ਟ੍ਰੈਫਿਕ ਸਪਾਈਕ ਝੱਲਦੇ ਹਨ, ਜਿਵੇਂ ਸਰਕਾਰੀ ਟੈਕਸ ਪੋਰਟਲ। ਇੱਕ ਆਮ ਡਿਜ਼ਾਈਨ ਸਮੱਸਿਆ ਉਦੋਂ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਹਰ ਕਾਰਵਾਈ ਇੱਕ ਸਿੰਕ੍ਰੋਨਸ ਬੈਕਐਂਡ ਓਪਰੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀ ਹੈ। ਉਪਭੋਗਤਾ ਬਟਨ ਦਬਾਉਂਦਾ ਹੈ। ਫ੍ਰੰਟਐਂਡ ਬੈਕਐਂਡ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਬੈਕਐਂਡ ਕਿਸੇ ਹੋਰ ਸਰਵਿਸ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਕੋਈ ਡਿਪੈਂਡੈਂਸੀ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਆਖ਼ਰਕਾਰ ਪੂਰਾ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ। Mike ਦੱਸਦੇ ਹਨ ਕਿ ਲੂਜ਼ਲੀ ਕਪਲਡ ਸਿਸਟਮ ਅਕਸਰ ਵਧੇਰੇ ਰੈਜ਼ੀਲੀਅੰਟ ਕਿਉਂ ਹੁੰਦੇ ਹਨ। ਹਰ ਬੈਕਐਂਡ ਓਪਰੇਸ਼ਨ ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ ਫ੍ਰੰਟਐਂਡ ਨੂੰ ਮਜਬੂਰ ਕਰਨ ਦੀ ਬਜਾਏ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਕੰਮ ਨੂੰ ਕਿਊਜ਼ ਜਾਂ ਇਵੈਂਟ-ਡਰਿਵਨ ਸਿਸਟਮਾਂ ਵਿੱਚ ਰੱਖ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੰਮ ਪ੍ਰੋਸੈਸ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ। ਇਸ ਦੇ ਕਈ ਫ਼ਾਇਦੇ ਹਨ: - ਵੱਖ-ਵੱਖ ਕੰਪੋਨੈਂਟ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸਕੇਲ ਹੋ ਸਕਦੇ ਹਨ - ਇੱਕ ਸਰਵਿਸ ਦੇ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਪੂਰਾ ਪਲੇਟਫਾਰਮ ਨਹੀਂ ਡਿੱਗਦਾ - ਬੈਕਐਂਡ ਕੰਮ ਅਸਿੰਕ੍ਰੋਨਸ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸ ਕਰ ਸਕਦੇ ਹਨ - ਟ੍ਰੈਫਿਕ ਸਪਾਈਕ ਸੋਖਣੇ ਆਸਾਨ ਹੁੰਦੇ ਹਨ - ਉਪਭੋਗਤਾ-ਸਾਹਮਣੇ ਵਾਲੇ ਕੰਪੋਨੈਂਟ ਬੈਕਐਂਡ ਦੇ ਸਮੇਂ 'ਤੇ ਘੱਟ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ - ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ 100 ਪ੍ਰਤੀਸ਼ਤ ਅੱਪਟਾਈਮ ਦਾ ਮਿੱਥ ਚਰਚਾ ਦਾ ਇੱਕ ਹੋਰ ਵੱਡਾ ਵਿਸ਼ਾ 100 ਪ੍ਰਤੀਸ਼ਤ ਉਪਲਬਧਤਾ ਦਾ ਜਨੂੰਨ ਹੈ। Mike ਸਾਫ਼ ਹਨ: 100 ਪ੍ਰਤੀਸ਼ਤ ਅੱਪਟਾਈਮ ਕੋਈ ਯਥਾਰਥਕ ਆਰਕੀਟੈਕਚਰ ਟੀਚਾ ਨਹੀਂ ਹੈ। ਇੱਕ ਹੱਲ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਸਰਵਿਸਾਂ ਤੋਂ ਬਣਦਾ ਹੈ। ਹਰ ਸਰਵਿਸ ਦਾ ਆਪਣਾ SLA ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕਈ ਡਿਪੈਂਡੈਂਸੀਆਂ ਨੂੰ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ...