ਮੋਨੋਲਿਥਸ ਤੋਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤੱਕ: M.Video-Eldorado ਅਤੇ MegaFon ਦਾ ਅਨੁਭਵ

25 ਅਪ੍ਰੈਲ ਨੂੰ, ਅਸੀਂ Mail.ru ਗਰੁੱਪ 'ਤੇ ਬੱਦਲਾਂ ਅਤੇ ਆਲੇ-ਦੁਆਲੇ ਬਾਰੇ ਇੱਕ ਕਾਨਫਰੰਸ ਰੱਖੀ - mailto: Cloud. ਕੁਝ ਹਾਈਲਾਈਟਸ:

• ਮੁੱਖ ਰੂਸੀ ਪ੍ਰਦਾਤਾ — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center ਅਤੇ Yandex.Cloud ਨੇ ਸਾਡੇ ਕਲਾਉਡ ਮਾਰਕੀਟ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ;
• Bitrix24 ਦੇ ਸਾਥੀਆਂ ਨੇ ਦੱਸਿਆ ਕਿ ਉਹ ਕਿਵੇਂ ਮਲਟੀਕਲਾਉਡ 'ਤੇ ਆਇਆ;
• Leroy Merlin, Otkritie, Burger King ਅਤੇ Schneider ਇਲੈਕਟ੍ਰਿਕ ਨੇ ਦਿਲਚਸਪ ਜਾਣਕਾਰੀ ਦਿੱਤੀ ਕਲਾਉਡ ਖਪਤਕਾਰਾਂ ਤੋਂ ਦ੍ਰਿਸ਼ — ਉਹਨਾਂ ਦਾ ਕਾਰੋਬਾਰ IT ਲਈ ਕਿਹੜੇ ਕੰਮ ਸੈੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਤਕਨੀਕਾਂ, ਕਲਾਊਡ ਸਮੇਤ, ਉਹ ਸਭ ਤੋਂ ਹੋਨਹਾਰ ਵਜੋਂ ਦੇਖਦੇ ਹਨ।

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

ਪੈਨਲਿਸਟ

• ਸਰਗੇਈ ਸਰਜੀਵ, ਸਮੂਹ ਸੀ.ਆਈ.ਓ "ਐਮ. ਵੀਡੀਓ-ਏਲਡੋਰਾਡੋ";
• ਅਲੈਗਜ਼ੈਂਡਰ ਡਿਉਲਿਨ, ਵਪਾਰ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਖੋਜ ਅਤੇ ਵਿਕਾਸ ਲਈ ਕੇਂਦਰ ਦਾ ਮੁਖੀ ਮੈਗਾਫੋਨ;
• ਸੰਚਾਲਕ - ਦਿਮਿਤਰੀ ਲਾਜ਼ਾਰੇਂਕੋ, PaaS ਦਿਸ਼ਾ ਦੇ ਮੁਖੀ Mail.ru ਕਲਾਉਡ ਹੱਲ.

ਅਲੈਗਜ਼ੈਂਡਰ ਡਿਉਲਿਨ ਦੇ ਭਾਸ਼ਣ ਤੋਂ ਬਾਅਦ "ਕਿਵੇਂ ਮੈਗਾਫੋਨ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਪਲੇਟਫਾਰਮ ਦੁਆਰਾ ਆਪਣੇ ਕਾਰੋਬਾਰ ਨੂੰ ਵਧਾ ਰਿਹਾ ਹੈ" ਉਹ M.Video-Eldorado ਤੋਂ Sergey Sergeev ਅਤੇ ਚਰਚਾ ਸੰਚਾਲਕ Dmitry Lazarenko, Mail.ru Cloud Solutions ਦੁਆਰਾ ਚਰਚਾ ਲਈ ਸ਼ਾਮਲ ਹੋਇਆ ਹੈ।

ਹੇਠਾਂ ਅਸੀਂ ਤੁਹਾਡੇ ਲਈ ਚਰਚਾ ਦਾ ਇੱਕ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਤਿਆਰ ਕੀਤਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਵੀਡੀਓ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ:

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਤਬਦੀਲੀ ਬਾਜ਼ਾਰ ਦੀਆਂ ਲੋੜਾਂ ਦਾ ਜਵਾਬ ਹੈ

ਦਮਿੱਤਰੀ:

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

ਸਰਗੇਈ:

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

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

ਪਹਿਲੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ, ਸਭ ਤੋਂ ਵੱਧ ਲੋਡ ਹੋਈ, ਕੀਮਤ ਗਣਨਾ ਸੇਵਾ ਸੀ। ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਚੈਨਲ 'ਤੇ ਆਉਂਦੇ ਹੋ, ਕੰਪਨੀਆਂ ਦੇ M.Video-Eldorado ਸਮੂਹ ਵਿੱਚ, ਭਾਵੇਂ ਇਹ ਇੱਕ ਵੈਬਸਾਈਟ ਹੋਵੇ ਜਾਂ ਇੱਕ ਪ੍ਰਚੂਨ ਸਟੋਰ, ਉੱਥੇ ਇੱਕ ਉਤਪਾਦ ਚੁਣੋ, ਵੈਬਸਾਈਟ 'ਤੇ ਜਾਂ "ਟੋਕਰੀ" ਵਿੱਚ ਕੀਮਤ ਵੇਖੋ, ਲਾਗਤ ਆਪਣੇ ਆਪ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਸੇਵਾ ਦੁਆਰਾ ਗਣਨਾ ਕੀਤੀ ਗਈ। ਇਹ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ: ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਹਰੇਕ ਪ੍ਰਣਾਲੀ ਦੇ ਤਰੱਕੀਆਂ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਆਪਣੇ ਸਿਧਾਂਤ ਸਨ - ਛੋਟਾਂ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਨਾਲ. ਸਾਡਾ ਬੈਕ ਆਫਿਸ ਕੀਮਤ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ; ਛੂਟ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕਿਸੇ ਹੋਰ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਇੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਵਿਲੱਖਣ, ਵੱਖ ਕਰਨ ਯੋਗ ਸੇਵਾ ਜੋ ਸਾਨੂੰ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗੀ। ਇਹ ਬਹੁਤ ਕੁਝ ਹੈ ਕਿ ਅਸੀਂ ਕਿਵੇਂ ਸ਼ੁਰੂ ਕੀਤਾ.

ਪਹਿਲੇ ਨਤੀਜਿਆਂ ਦਾ ਮੁੱਲ ਬਹੁਤ ਵਧੀਆ ਸੀ. ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਵੱਖ ਕਰਨ ਯੋਗ ਇਕਾਈਆਂ ਬਣਾਉਣ ਦੇ ਯੋਗ ਸੀ ਜੋ ਸਾਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਅਤੇ ਇੱਕਤਰ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ। ਦੂਜਾ, ਅਸੀਂ ਹੋਰ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਦੇ ਰੂਪ ਵਿੱਚ ਮਲਕੀਅਤ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾ ਦਿੱਤਾ ਹੈ.

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮਾਪਣਾ ਹੈ

ਦਮਿੱਤਰੀ:

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਵਿੱਚ ਸਫਲਤਾ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ? ਹਰੇਕ ਕੰਪਨੀ ਵਿੱਚ "ਪਹਿਲਾਂ" ਕੀ ਸੀ? ਪਰਿਵਰਤਨ ਦੀ ਸਫਲਤਾ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਤੁਸੀਂ ਕਿਹੜੀ ਮੈਟ੍ਰਿਕ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਇਸਨੂੰ ਕਿਸ ਨੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਸੀ?

ਸਰਗੇਈ:

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

ਸਿਕੰਦਰ:

ਸਫਲਤਾ ਇੱਕ ਅੰਦਰੂਨੀ ਭਾਵਨਾ ਹੈ। ਵਪਾਰ ਹਮੇਸ਼ਾ ਹੋਰ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਡੇ ਬੈਕਲਾਗ ਦੀ ਡੂੰਘਾਈ ਸਫਲਤਾ ਦਾ ਸਬੂਤ ਹੈ। ਇਹ ਮੈਨੂੰ ਅਜਿਹਾ ਲੱਗਦਾ ਹੈ.

ਸਰਗੇਈ:

ਹਾਂ, ਮੈਂ ਸਹਿਮਤ ਹਾਂ। ਤਿੰਨ ਸਾਲਾਂ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਦੋ ਸੌ ਤੋਂ ਵੱਧ ਸੇਵਾਵਾਂ ਅਤੇ ਬੈਕਲਾਗ ਹਨ। ਟੀਮ ਦੇ ਅੰਦਰ ਸਰੋਤਾਂ ਦੀ ਜ਼ਰੂਰਤ ਸਿਰਫ ਵਧ ਰਹੀ ਹੈ - 30% ਸਾਲਾਨਾ ਦੁਆਰਾ. ਇਹ ਇਸ ਲਈ ਹੋ ਰਿਹਾ ਹੈ ਕਿਉਂਕਿ ਲੋਕਾਂ ਨੇ ਮਹਿਸੂਸ ਕੀਤਾ: ਇਹ ਤੇਜ਼ ਹੈ, ਇਹ ਵੱਖਰਾ ਹੈ, ਵੱਖ-ਵੱਖ ਤਕਨਾਲੋਜੀਆਂ ਹਨ, ਇਹ ਸਭ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ।

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਆਉਣਗੇ, ਪਰ ਕੋਰ ਬਣੇ ਰਹਿਣਗੇ

ਦਮਿੱਤਰੀ:

ਇਹ ਇੱਕ ਕਦੇ ਨਾ ਖਤਮ ਹੋਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਤਰ੍ਹਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਵਿਕਾਸ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਦੇ ਹੋ। ਕੀ ਕਾਰੋਬਾਰ ਲਈ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਤਬਦੀਲੀ ਪਹਿਲਾਂ ਹੀ ਖਤਮ ਹੋ ਗਈ ਹੈ ਜਾਂ ਨਹੀਂ?

ਸਰਗੇਈ:

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

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

ਦਮਿੱਤਰੀ:

ਜ਼ਿੰਦਗੀ ਚੰਗੀ ਹਾਲਤ ਵਿਚ ਹੈ। (ਹੱਸਦਾ ਹੈ)

ਸਿਕੰਦਰ:

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

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

ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਕਿਵੇਂ ਵੇਚਣੇ ਹਨ

ਦਮਿੱਤਰੀ:

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

ਸਰਗੇਈ:

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

ਦਮਿੱਤਰੀ:

ਕੀ ਤੁਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਪਹਿਲੇ ਪੜਾਅ ਦਾ ਸਮਾਂ ਰਿਕਾਰਡ ਕੀਤਾ ਸੀ?

ਸਰਗੇਈ:

ਜੀ ਬਿਲਕੁਲ. ਅਸੀਂ ਕੋਰ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੇ ਤੌਰ 'ਤੇ ਬਣਾਉਣ ਅਤੇ ਪਾਇਲਟ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ 6 ਮਹੀਨੇ ਨਿਰਧਾਰਤ ਕੀਤੇ ਹਨ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਅਸੀਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਿਸ 'ਤੇ ਪਾਇਲਟ ਸਕੇਟਿੰਗ ਕਰਨ ਲਈ. ਫਿਰ ਪਰਿਕਲਪਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਕਿਉਂਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਾਂ. ਉਹਨਾਂ ਨੇ ਟੀਮ ਨੂੰ ਦੁਹਰਾਉਣਾ ਅਤੇ ਮਜ਼ਬੂਤ ​​ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ - ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੀ ਡਿਵੀਜ਼ਨ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਜੋ ਅਜਿਹਾ ਹੀ ਕਰਦਾ ਹੈ।

ਅੱਗੇ ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ, ਮੌਕਿਆਂ, ਸਰੋਤਾਂ ਦੀ ਉਪਲਬਧਤਾ ਅਤੇ ਹਰ ਚੀਜ਼ ਜੋ ਇਸ ਸਮੇਂ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਦੇ ਅਧਾਰ ਤੇ ਯੋਜਨਾਬੱਧ ਕੰਮ ਆਉਂਦਾ ਹੈ।

ਦਮਿੱਤਰੀ:

ਠੀਕ ਹੈ. ਸਿਕੰਦਰ, ਤੁਸੀਂ ਕੀ ਕਹਿੰਦੇ ਹੋ?

ਸਿਕੰਦਰ:

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

ਦਮਿੱਤਰੀ:

ਕੀ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੋਈ ਕਾਰੋਬਾਰ ਤੁਹਾਨੂੰ ਗੂਗਲ ਵਰਗੇ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ - ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਮੁਫ਼ਤ ਦਿਨ? ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹੀ ਦਿਸ਼ਾ ਹੈ?

ਸਿਕੰਦਰ:

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

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼: ਹਾਈਪ ਜਾਂ ਲੋੜ?

ਦਮਿੱਤਰੀ:

ਨੰਬਰ ਨੰਬਰ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਮਾਲੀਆ ਜਾਂ ਬਚਾਇਆ ਪੈਸਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਤੁਸੀਂ ਦੂਜੇ ਪਾਸੇ ਦੇਖਦੇ ਹੋ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਇੱਕ ਰੁਝਾਨ, ਇੱਕ ਹਾਈਪ ਹੈ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਇਸਦਾ ਦੁਰਵਿਵਹਾਰ ਕਰ ਰਹੀਆਂ ਹਨ? ਤੁਸੀਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨ ਅਤੇ ਨਾ ਕਰਨ ਦੇ ਵਿਚਕਾਰ ਕਿੰਨੀ ਸਪਸ਼ਟਤਾ ਨਾਲ ਫਰਕ ਕਰਦੇ ਹੋ? ਜੇਕਰ ਹੁਣ ਵਿਰਾਸਤ ਹੈ, ਤਾਂ ਕੀ ਤੁਹਾਡੇ ਕੋਲ 5 ਸਾਲਾਂ ਵਿੱਚ ਵੀ ਵਿਰਾਸਤ ਹੋਵੇਗੀ? M.Video-Eldorado ਅਤੇ MegaFon 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਉਮਰ 5 ਸਾਲਾਂ ਵਿੱਚ ਕੀ ਹੋਵੇਗੀ? ਕੀ ਦਸ ਸਾਲ, ਪੰਦਰਾਂ ਸਾਲ ਪੁਰਾਣੀ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀ ਹੋਵੇਗੀ ਜਾਂ ਨਵੀਂ ਪੀੜ੍ਹੀ ਹੋਵੇਗੀ? ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਿਵੇਂ ਦੇਖਦੇ ਹੋ?

ਸਰਗੇਈ:

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

ਸਾਡੀਆਂ ਕੰਪਨੀਆਂ ਸਮੂਹਿਕ ਤੌਰ 'ਤੇ 25 ਸਾਲ ਪੁਰਾਣੀਆਂ ਹਨ, ਕਲਾਸਿਕ ERP ਸਿਸਟਮ ਲੈਂਡਸਕੇਪ ਵਿੱਚ ਬਹੁਤ ਡੂੰਘੇ ਹਨ। ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਅਸੀਂ ਉੱਥੋਂ ਕੁਝ ਟੁਕੜੇ ਲੈ ਰਹੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਕੋਰ ਰਹੇਗਾ। ਮੇਰੇ ਲਈ ਹੁਣ ਇਹ ਕਲਪਨਾ ਕਰਨਾ ਔਖਾ ਹੈ ਕਿ ਅਸੀਂ ਉੱਥੇ ਸਾਰੇ ਕੋਰ ਸਿਸਟਮਾਂ ਨੂੰ ਬਦਲ ਦੇਵਾਂਗੇ ਅਤੇ ਛੇਤੀ ਹੀ ਨਵੇਂ ਸਿਸਟਮਾਂ ਦੇ ਦੂਜੇ, ਚਮਕਦਾਰ ਪਾਸੇ ਵੱਲ ਚਲੇ ਜਾਵਾਂਗੇ।

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

ਅਸੀਂ ਇਹ ਵਿਕਾਸ ਦੇਖਦੇ ਹਾਂ:

• ਕੋਰ ਇਨਫਰਮੇਸ਼ਨ ਸਿਸਟਮ (ਜ਼ਿਆਦਾਤਰ ਬੈਕ ਆਫਿਸ);
• ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਮੱਧ ਪਰਤਾਂ ਕੋਰ ਨੂੰ ਜੋੜਦੀਆਂ ਹਨ, ਇਕੱਠੀਆਂ ਕਰਦੀਆਂ ਹਨ, ਇੱਕ ਕੈਸ਼ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੀ;
• ਫਰੰਟ-ਲਾਈਨ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਉਦੇਸ਼ ਖਪਤਕਾਰਾਂ ਲਈ ਹੈ;
• ਇੱਕ ਏਕੀਕਰਣ ਪਰਤ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਬਾਜ਼ਾਰਾਂ, ਹੋਰ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਵਾਤਾਵਰਣ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੀ ਹੈ। ਇਹ ਪਰਤ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਹਲਕਾ, ਸਰਲ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਵਪਾਰਕ ਤਰਕ ਸ਼ਾਮਲ ਹਨ।

ਪਰ ਇਸ ਦੇ ਨਾਲ ਹੀ, ਮੈਂ ਪੁਰਾਣੇ ਸਿਧਾਂਤਾਂ ਦੀ ਵਰਤੋਂ ਜਾਰੀ ਰੱਖਣ ਦਾ ਸਮਰਥਕ ਹਾਂ ਜੇਕਰ ਉਨ੍ਹਾਂ ਦੀ ਸਹੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇ।

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਲਾਸਿਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਿਸਟਮ ਹੈ। ਇਹ ਇੱਕ ਵਿਕਰੇਤਾ ਦੇ ਲੈਂਡਸਕੇਪ ਵਿੱਚ ਸਥਿਤ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਦੋ ਮੋਡੀਊਲ ਹੁੰਦੇ ਹਨ ਜੋ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ ਮਿਆਰੀ ਏਕੀਕਰਣ ਇੰਟਰਫੇਸ ਵੀ ਹੈ. ਇਸਨੂੰ ਦੁਬਾਰਾ ਕਿਉਂ ਕਰੋ ਅਤੇ ਉੱਥੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਲਿਆਓ?

ਪਰ ਜਦੋਂ ਬੈਕ ਆਫਿਸ ਵਿੱਚ 5 ਮੌਡਿਊਲ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਤੋਂ ਜਾਣਕਾਰੀ ਦੇ ਟੁਕੜੇ ਇੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਇਕੱਤਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਫਿਰ 8-10 ਫਰੰਟ-ਲਾਈਨ ਪ੍ਰਣਾਲੀਆਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਲਾਭ ਤੁਰੰਤ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਪੰਜ ਬੈਕ-ਆਫਿਸ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਲੈਂਦੇ ਹੋ ਅਤੇ ਇੱਕ ਸੇਵਾ ਬਣਾਉਂਦੇ ਹੋ, ਇੱਕ ਅਲੱਗ-ਥਲੱਗ, ਜੋ ਕਿ ਕਾਰੋਬਾਰੀ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ। ਸੇਵਾ ਨੂੰ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਉੱਨਤ ਬਣਾਓ - ਤਾਂ ਜੋ ਇਹ ਜਾਣਕਾਰੀ ਨੂੰ ਕੈਸ਼ ਕਰੇ ਅਤੇ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਹੋਵੇ, ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਜਾਂ ਵਪਾਰਕ ਸੰਸਥਾਵਾਂ ਨਾਲ ਵੀ ਕੰਮ ਕਰੇ। ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਰੇ ਫਰੰਟ-ਲਾਈਨ ਉਤਪਾਦਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ ਜੋੜਦੇ ਹੋ। ਉਹਨਾਂ ਨੇ ਫਰੰਟ-ਲਾਈਨ ਉਤਪਾਦ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ - ਉਹਨਾਂ ਨੇ ਸਿਰਫ਼ ਏਕੀਕਰਣ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ. ਕੱਲ੍ਹ ਤੁਹਾਨੂੰ ਇੱਕ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਲਿਖਣ ਜਾਂ ਇੱਕ ਛੋਟੀ ਵੈਬਸਾਈਟ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਹਿੱਸਾ ਪਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ: ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਕੰਸਟਰਕਟਰ ਵਾਂਗ ਇਕੱਠਾ ਕੀਤਾ ਹੈ। ਮੈਂ ਇਸ ਦਿਸ਼ਾ ਵਿੱਚ ਵਧੇਰੇ ਵਿਕਾਸ ਦੇਖਦਾ ਹਾਂ - ਘੱਟੋ ਘੱਟ ਸਾਡੇ ਦੇਸ਼ ਵਿੱਚ.

ਸਿਕੰਦਰ:

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

ਦਮਿੱਤਰੀ:

ਇੱਥੇ ਪ੍ਰਮਾਣੀਕਰਣ ਇੱਕ ਕਹਾਣੀ ਹੈ। ਸ਼ਾਇਦ ਹੋਰ ਸਮਰਥਨ. ਜੇ ਤੁਸੀਂ ਸਹਾਇਤਾ 'ਤੇ ਬਹੁਤ ਘੱਟ ਖਰਚ ਕਰਦੇ ਹੋ ਜਾਂ ਸਿਸਟਮ ਨੂੰ ਸਹਾਇਤਾ ਅਤੇ ਸੋਧ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਛੂਹਣਾ ਬਿਹਤਰ ਨਹੀਂ ਹੈ। ਇੱਕ ਵਾਜਬ ਸਮਝੌਤਾ.

ਭਰੋਸੇਮੰਦ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਵਿਕਸਿਤ ਕਰਨਾ ਹੈ

ਦਮਿੱਤਰੀ:

ਜੁਰਮਾਨਾ. ਪਰ ਮੈਨੂੰ ਅਜੇ ਵੀ ਦਿਲਚਸਪੀ ਹੈ. ਹੁਣ ਤੁਸੀਂ ਇੱਕ ਸਫ਼ਲਤਾ ਦੀ ਕਹਾਣੀ ਦੱਸ ਰਹੇ ਹੋ: ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਸਵਿਚ ਕੀਤਾ, ਕਾਰੋਬਾਰ ਲਈ ਵਿਚਾਰ ਦਾ ਬਚਾਅ ਕੀਤਾ, ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੋ ਗਿਆ। ਪਰ ਮੈਂ ਹੋਰ ਕਹਾਣੀਆਂ ਸੁਣੀਆਂ ਹਨ।

ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਇੱਕ ਸਵਿਸ ਕੰਪਨੀ ਜਿਸਨੇ ਬੈਂਕਾਂ ਲਈ ਇੱਕ ਨਵਾਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਪਲੇਟਫਾਰਮ ਵਿਕਸਤ ਕਰਨ ਵਿੱਚ ਦੋ ਸਾਲ ਦਾ ਨਿਵੇਸ਼ ਕੀਤਾ ਸੀ, ਆਖਰਕਾਰ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਢਹਿ-ਢੇਰੀ ਹੋ ਗਿਆ। ਲੱਖਾਂ ਸਵਿਸ ਫ੍ਰੈਂਕ ਖਰਚੇ ਗਏ ਸਨ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਟੀਮ ਖਿੰਡ ਗਈ ਸੀ - ਇਹ ਕੰਮ ਨਹੀਂ ਹੋਇਆ।

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

ਸਿਕੰਦਰ:

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਸਾਡੇ ਕੋਲ ਕੋਈ ਗਲੋਬਲ ਅਸਫਲਤਾ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਸ਼ਾਂਤੀ ਨਾਲ ਸੌਂਦੇ ਹਾਂ, ਸਾਡੇ ਕੋਲ 24/7 ਡਿਊਟੀ ਸ਼ਿਫਟ ਹੈ ਜੋ ਪੂਰੇ BSS [ਬਿਜ਼ਨਸ ਸਪੋਰਟ ਸਿਸਟਮ] ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ।

ਅਤੇ ਇੱਕ ਹੋਰ ਗੱਲ - ਅਸੀਂ ਬਾਕਸਡ ਉਤਪਾਦਾਂ 'ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਨਿਯਮਾਂ ਦੇ ਅਨੁਸਾਰ ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼ ਕਿਰਾਏ 'ਤੇ ਦਿੰਦੇ ਹਾਂ। ਸਫਲਤਾ ਦੀ ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਟੀਮ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਉਤਪਾਦਨ ਲਈ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕਰੇਗੀ। ਵਿਕਾਸ ਆਪਣੇ ਆਪ ਵਿੱਚ, ਸ਼ਰਤ ਅਨੁਸਾਰ, 40% ਹੈ. ਬਾਕੀ ਵਿਸ਼ਲੇਸ਼ਣ, DevSecOps ਕਾਰਜਪ੍ਰਣਾਲੀ, ਸਹੀ ਏਕੀਕਰਣ ਅਤੇ ਸਹੀ ਆਰਕੀਟੈਕਚਰ ਹੈ। ਅਸੀਂ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਦੇ ਸਿਧਾਂਤਾਂ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦਿੰਦੇ ਹਾਂ। ਸੂਚਨਾ ਸੁਰੱਖਿਆ ਪ੍ਰਤੀਨਿਧੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਯੋਜਨਾਬੰਦੀ ਦੇ ਪੜਾਅ ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਹਰੇਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ। ਉਹ ਕਮਜ਼ੋਰੀਆਂ ਲਈ ਕੋਡ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਸਿਸਟਮਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਵੀ ਕਰਦੇ ਹਨ।

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

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

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਅਤੇ ਐਚ.ਆਰ

ਸਰਗੇਈ:

ਮੈਂ ਸਹਾਇਤਾ ਲਈ ਤਬਾਦਲੇ ਬਾਰੇ ਆਪਣੇ ਸਹਿਯੋਗੀ ਨਾਲ ਸਹਿਮਤ ਹਾਂ - ਕਿ ਕੰਮ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਰ ਮੈਂ ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਦੱਸਾਂਗਾ ਜੋ ਬੇਸ਼ੱਕ ਮੌਜੂਦ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤਕਨਾਲੋਜੀ ਨਵੀਂ ਹੈ. ਇਹ ਇੱਕ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਹਾਈਪ ਹੈ, ਅਤੇ ਇੱਕ ਮਾਹਰ ਲੱਭਣਾ ਜੋ ਇਸਨੂੰ ਸਮਝੇਗਾ ਅਤੇ ਬਣਾ ਸਕਦਾ ਹੈ ਇੱਕ ਵੱਡੀ ਚੁਣੌਤੀ ਹੈ। ਸਰੋਤਾਂ ਲਈ ਮੁਕਾਬਲਾ ਪਾਗਲ ਹੈ, ਇਸਲਈ ਮਾਹਰ ਸੋਨੇ ਵਿੱਚ ਆਪਣੇ ਭਾਰ ਦੇ ਯੋਗ ਹਨ.

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

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

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

ਨਿਗਰਾਨੀ ਦੇ ਸਬੰਧ ਵਿੱਚ. ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਸੇਵਾਵਾਂ ਜਾਂ ਉਦਯੋਗਿਕ ਨਿਗਰਾਨੀ ਸਾਧਨ ਪਹਿਲਾਂ ਹੀ ਸਿੱਖ ਰਹੇ ਹਨ ਜਾਂ ਇੱਕ ਵੱਖਰੇ, ਗੈਰ-ਸਟੈਂਡਰਡ ਮੋਡ ਵਿੱਚ ਡੌਕਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਦੋਵਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹਨ. ਇਸ ਲਈ, ਉਦਾਹਰਣ ਵਜੋਂ, ਤੁਸੀਂ 500 ਜਾਵਾ ਮਸ਼ੀਨਾਂ ਦੇ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੁੰਦੇ ਜਿਸ ਦੇ ਅਧੀਨ ਇਹ ਸਭ ਚੱਲ ਰਿਹਾ ਹੈ, ਅਰਥਾਤ, ਇਹ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ. ਪਰ ਇਹਨਾਂ ਉਤਪਾਦਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਪਰਿਪੱਕਤਾ ਦੀ ਘਾਟ ਹੈ; ਉਹਨਾਂ ਨੂੰ ਇਸ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪੈਂਦਾ ਹੈ. ਵਿਸ਼ਾ ਅਸਲ ਵਿੱਚ ਨਵਾਂ ਹੈ, ਇਹ ਵਿਕਾਸ ਹੁੰਦਾ ਰਹੇਗਾ।

ਦਮਿੱਤਰੀ:

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

ਸਰਗੇਈ:

ਹਾਂ, ਬਿਲਕੁਲ।

ਸਿਕੰਦਰ:

HR ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ: "ਬੈਕਐਂਡ ਅਤੇ ਫਰੰਟਐਂਡ ਦੇ ਵਿਚਕਾਰ ਤੁਹਾਡਾ ਗੁਲਾਬੀ ਯੂਨੀਕੋਰਨ ਕਿੱਥੇ ਹੈ?" HR ਇਹ ਨਹੀਂ ਸਮਝਦਾ ਕਿ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਕੀ ਹੈ। ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਰਾਜ਼ ਦੱਸਿਆ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਦੱਸਿਆ ਕਿ ਬੈਕਐਂਡ ਨੇ ਸਭ ਕੁਝ ਕੀਤਾ, ਅਤੇ ਕੋਈ ਯੂਨੀਕੋਰਨ ਨਹੀਂ ਹੈ. ਪਰ HR ਬਦਲ ਰਿਹਾ ਹੈ, ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਰਿਹਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਲੋਕਾਂ ਨੂੰ ਭਰਤੀ ਕਰ ਰਿਹਾ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਬੁਨਿਆਦੀ IT ਗਿਆਨ ਹੈ।

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦਾ ਵਿਕਾਸ

ਦਮਿੱਤਰੀ:

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

ਸਰਗੇਈ:

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

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

ਸੁਰੱਖਿਆ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸੇਵਾ ਹੁੰਦੀ ਹੈ ਜਿਸ ਰਾਹੀਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਬਹੁਤ ਜਲਦੀ, ਇੱਕ ਸਪਲਿਟ ਸਕਿੰਟ ਵਿੱਚ, ਤਦ ਇਸ ਨੂੰ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇੱਛਾ ਹੁੰਦੀ ਹੈ. ਇਸ ਤੋਂ ਦੂਰ ਹੋਣ ਲਈ, ਸਾਨੂੰ ਟੈਸਟਿੰਗ ਅਤੇ ਨਿਗਰਾਨੀ ਲਈ ਪਹੁੰਚ ਬਦਲਣੇ ਪਏ। ਸਾਨੂੰ ਟੀਮ, ਡਿਲਿਵਰੀ ਪ੍ਰਬੰਧਨ ਢਾਂਚਾ, CI/CD ਨੂੰ ਬਦਲਣਾ ਪਿਆ।

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

ਦੁਹਰਾਓ, ਤਕਨਾਲੋਜੀ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਪ੍ਰਤੀ ਸਾਲ ਕੁਝ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਬੈਕਲਾਗ ਅਤੇ ਲੋੜਾਂ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕੁਝ ਹੋਰ। ਅਸੀਂ ਇੱਕ ਚੀਜ਼ ਨੂੰ ਦੂਜੀ ਨਾਲ ਜੋੜਦੇ ਹਾਂ। ਟੀਮ 20% ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਅਤੇ ਟੀਮ ਲਈ ਤਕਨੀਕੀ ਸਹਾਇਤਾ 'ਤੇ ਖਰਚ ਕਰਦੀ ਹੈ, 80% ਵਪਾਰਕ ਇਕਾਈ 'ਤੇ। ਅਤੇ ਅਸੀਂ ਇਸ ਗੱਲ ਦੀ ਸਮਝ ਨਾਲ ਅੱਗੇ ਵਧਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਇਹ ਕਿਉਂ ਕਰ ਰਹੇ ਹਾਂ, ਅਸੀਂ ਇਹ ਤਕਨੀਕੀ ਸੁਧਾਰ ਕਿਉਂ ਕਰ ਰਹੇ ਹਾਂ, ਉਹ ਕਿਸ ਵੱਲ ਲੈ ਜਾਣਗੇ। ਓਸ ਵਾਂਗ.

ਦਮਿੱਤਰੀ:

ਠੰਡਾ. MegaFon ਵਿੱਚ ਕੀ ਹੈ?

ਸਿਕੰਦਰ:

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

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

ਦਮਿੱਤਰੀ:

ਸੋਨੇ ਦੇ ਸ਼ਬਦ! ਅਜਿਹੀਆਂ ਚੁਣੌਤੀਆਂ ਟੀਮ ਅਤੇ ਕਾਰੋਬਾਰ ਨੂੰ ਆਪਣੇ ਪੈਰਾਂ 'ਤੇ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਭਵਿੱਖ ਦਾ ਨਿਰਮਾਣ ਕਰਦੀਆਂ ਹਨ। GDPR ਨੇ ਮੁੱਖ ਡਾਟਾ ਸੁਰੱਖਿਆ ਅਫਸਰ ਬਣਾਏ, ਅਤੇ ਮੌਜੂਦਾ ਚੁਣੌਤੀਆਂ ਮੁੱਖ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਅਫਸਰ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਅਤੇ ਇਹ ਖੁਸ਼ ਹੁੰਦਾ ਹੈ.

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

ਸਾਰੇ ਭਾਗੀਦਾਰਾਂ ਦਾ ਧੰਨਵਾਦ, ਸਰਗੇਈ ਅਤੇ ਅਲੈਗਜ਼ੈਂਡਰ ਦਾ ਧੰਨਵਾਦ!

ਸਰੋਤਿਆਂ ਦੇ ਸਵਾਲ

ਸਰੋਤਿਆਂ ਤੋਂ ਸਵਾਲ (1):

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

ਸਰਗੇਈ:

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

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

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ, ਇੱਕ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ, ਇੱਕ ਟੀਕੇ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਟੀਕਾ ਜਿਸ ਨੇ ਦਿਖਾਇਆ: ਤੁਸੀਂ ਇਸਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਬੇਸ਼ੱਕ, ਕਰਮਚਾਰੀਆਂ ਵਿੱਚ, ਯੋਗਤਾਵਾਂ ਵਿੱਚ, ਗਿਆਨ ਵਿੱਚ, ਵਿਰੋਧ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ.

ਸਰੋਤਿਆਂ ਤੋਂ ਸਵਾਲ (2):

ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਆਲੋਚਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਟੈਸਟਿੰਗ ਅਤੇ ਵਿਕਾਸ ਮੁਸ਼ਕਲ ਹਨ। ਇਹ ਤਰਕਪੂਰਨ ਹੈ ਜਿੱਥੇ ਚੀਜ਼ਾਂ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਕਿਹੜੀਆਂ ਚੁਣੌਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਅਤੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਵੇਂ ਪਾਰ ਕੀਤਾ? ਹਰ ਕਿਸੇ ਲਈ ਸਵਾਲ.

ਸਿਕੰਦਰ:

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤੋਂ ਪਲੇਟਫਾਰਮ 'ਤੇ ਜਾਣ ਵੇਲੇ ਮੁਸ਼ਕਲਾਂ ਆਉਂਦੀਆਂ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਉਤਪਾਦ ਬਣਾ ਰਹੇ ਹਾਂ ਜਿਸ ਵਿੱਚ 5-7 ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਸ਼ਾਮਲ ਹਨ। ਸਾਨੂੰ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਜਾਣ ਲਈ ਹਰੀ ਰੋਸ਼ਨੀ ਦੇਣ ਲਈ ਸਮੁੱਚੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਸਟੈਕ ਵਿੱਚ ਏਕੀਕਰਣ ਟੈਸਟ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਕੰਮ ਸਾਡੇ ਲਈ ਨਵਾਂ ਨਹੀਂ ਸੀ: ਅਸੀਂ BSS 'ਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਅਜਿਹਾ ਕਰ ਰਹੇ ਸੀ, ਜਦੋਂ ਵਿਕਰੇਤਾ ਨੇ ਸਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਭੇਜੇ ਗਏ ਹੱਲਾਂ ਨਾਲ ਸਪਲਾਈ ਕੀਤਾ ਸੀ।

ਅਤੇ ਸਾਡੀ ਸਮੱਸਿਆ ਸਿਰਫ ਛੋਟੀ ਟੀਮ ਵਿੱਚ ਹੈ. ਇੱਕ ਕੰਡੀਸ਼ਨਲ ਉਤਪਾਦ ਲਈ ਇੱਕ QA ਇੰਜੀਨੀਅਰ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਸ ਲਈ, ਅਸੀਂ 5-7 ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦਾ ਇੱਕ ਉਤਪਾਦ ਭੇਜਦੇ ਹਾਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ 2-3 ਨੂੰ ਤੀਜੀ ਧਿਰ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਉਤਪਾਦ ਹੈ ਜਿਸ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਸਾਡੇ ਬਿਲਿੰਗ ਸਿਸਟਮ ਵਿਕਰੇਤਾ, Mail.ru ਸਮੂਹ ਅਤੇ MegaFon R&D ਹਿੱਸਾ ਲੈਂਦੇ ਹਨ। ਸਾਨੂੰ ਇਸਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟਾਂ ਨਾਲ ਕਵਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। QA ਇੰਜੀਨੀਅਰ ਡੇਢ ਮਹੀਨੇ ਤੋਂ ਇਸ ਉਤਪਾਦ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਟੀਮ ਉਸਦੇ ਸਮਰਥਨ ਤੋਂ ਬਿਨਾਂ ਰਹਿ ਗਈ ਹੈ।

ਇਹ ਗੁੰਝਲਤਾ ਸਿਰਫ ਸਕੇਲਿੰਗ ਕਾਰਨ ਹੁੰਦੀ ਹੈ। ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵੈਕਿਊਮ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ; ਪੂਰਨ ਅਲੱਗ-ਥਲੱਗ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਇੱਕ ਸੇਵਾ ਬਦਲਦੇ ਸਮੇਂ, ਅਸੀਂ ਹਮੇਸ਼ਾ API ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਜੇ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਕੁਝ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਸਾਹਮਣੇ ਸੇਵਾ ਰਹਿੰਦੀ ਹੈ. ਜੇਕਰ ਤਬਦੀਲੀਆਂ ਘਾਤਕ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਕਿਸੇ ਕਿਸਮ ਦਾ ਆਰਕੀਟੈਕਚਰਲ ਪਰਿਵਰਤਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੇ ਡੇਟਾ ਮੈਟਾਮੋਡਲ ਵਿੱਚ ਚਲੇ ਜਾਂਦੇ ਹਾਂ, ਜੋ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸੰਗਤ ਹੈ - ਕੇਵਲ ਤਦ ਹੀ ਅਸੀਂ v2 ਸੇਵਾ API ਨਿਰਧਾਰਨ ਦੇ ਪ੍ਰਗਟ ਹੋਣ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਇੱਕੋ ਸਮੇਂ ਪਹਿਲੇ ਅਤੇ ਦੂਜੇ ਸੰਸਕਰਣਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਸਾਰੇ ਖਪਤਕਾਰਾਂ ਦੇ ਦੂਜੇ ਸੰਸਕਰਣ 'ਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਸਿਰਫ਼ ਪਹਿਲੇ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ।

ਸਰਗੇਈ:

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

ਪਿਛਲੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਇਹ ਵਾਧੂ ਓਵਰਹੈੱਡ ਹੈ. ਜੇ ਤੁਸੀਂ ਇੱਕ ਤਕਨਾਲੋਜੀ ਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਉਦੋਂ ਤੱਕ ਦੁਬਾਰਾ ਲਿਖਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਨਹੀਂ ਕਰਦੇ.

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

ਸਿਕੰਦਰ:

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

ਸਰੋਤਿਆਂ ਤੋਂ ਸਵਾਲ (3):

ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਵੱਖਰੀ ਟੀਮ ਤੋਂ ਵਧੀਆਂ ਸਨ ਅਤੇ ਹੁਣ ਇਸ ਮਾਡਲ ਵਿੱਚ ਮੌਜੂਦ ਹਨ। ਇਸ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਕੀ ਹਨ?

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

ਇਸ ਅਨੁਸਾਰ, ਸਾਡਾ ਸੰਚਾਲਨ ਸਿਸਟਮਾਂ 'ਤੇ ਵੀ ਜਾਂਦਾ ਹੈ, ਯਾਨੀ ਅਸੀਂ ਇਸ ਵਿਸ਼ੇ ਦਾ ਵਿਕੇਂਦਰੀਕਰਨ ਕਰ ਰਹੇ ਹਾਂ। ਤੁਹਾਡੀ ਪਹੁੰਚ ਕੀ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਟੀਚਾ ਕਹਾਣੀ ਕੀ ਹੈ?

ਸਿਕੰਦਰ:

ਤੁਸੀਂ "ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼ ਫੈਕਟਰੀ" ਦਾ ਨਾਮ ਆਪਣੇ ਮੂੰਹੋਂ ਛੱਡ ਦਿੱਤਾ ਹੈ - ਅਸੀਂ ਵੀ ਸਕੇਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਪਹਿਲਾਂ, ਸਾਡੇ ਕੋਲ ਹੁਣ ਇੱਕ ਟੀਮ ਹੈ. ਅਸੀਂ ਉਹਨਾਂ ਸਾਰੀਆਂ ਵਿਕਾਸ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਜੋ MegaFon ਕੋਲ ਇੱਕ ਸਾਂਝੇ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦਾ ਮੌਕਾ ਹੈ। ਅਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਵਿਕਾਸ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਆਪਣੇ ਕੋਲ ਨਹੀਂ ਲੈਣਾ ਚਾਹੁੰਦੇ ਜੋ ਹੁਣ ਸਾਡੇ ਕੋਲ ਹੈ। ਸਥਾਨਕ ਕੰਮ ਸਕੇਲ ਕਰਨਾ ਹੈ, ਗਲੋਬਲ ਕੰਮ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਲੇਅਰ ਵਿੱਚ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ ਵਿਕਾਸ ਦੀ ਅਗਵਾਈ ਕਰਨਾ ਹੈ।

ਸਰਗੇਈ:

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

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

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

ਸਿਕੰਦਰ:

ਸਰਗੇਈ, ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਲਕ ਹੋ, ਠੀਕ ਹੈ? ਕੀ ਕੰਮ ਦਾ ਬੈਕਲਾਗ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਹੈ? ਇਸ ਦੀ ਵੰਡ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ?

ਸਰਗੇਈ:

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

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

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

ਚਰਚਾ ਦਾ ਅੰਤ, ਪਰ ਸਾਰੇ ਨਹੀਂ

ਮੇਲਟੋ: ਕਲਾਊਡ ਕਾਨਫਰੰਸ ਆਯੋਜਿਤ ਕੀਤੀ ਗਈ ਸੀ Mail.ru ਕਲਾਉਡ ਹੱਲ.

ਅਸੀਂ ਹੋਰ ਸਮਾਗਮ ਵੀ ਕਰਦੇ ਹਾਂ - ਉਦਾਹਰਨ ਲਈ @ਕੁਬਰਨੇਟਸ ਮੀਟਅੱਪ, ਜਿੱਥੇ ਅਸੀਂ ਹਮੇਸ਼ਾ ਵਧੀਆ ਸਪੀਕਰਾਂ ਦੀ ਤਲਾਸ਼ ਕਰਦੇ ਹਾਂ:

• ਸਾਡੇ ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲ ਵਿੱਚ @Kubernetes ਅਤੇ ਹੋਰ @Meetup ਖਬਰਾਂ ਦਾ ਪਾਲਣ ਕਰੋ t.me/k8s_mail
• @Meetups ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਬੋਲਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੈ? ਲਈ ਇੱਕ ਬੇਨਤੀ ਛੱਡੋ mcs.mail.ru/speak

ਸਰੋਤ: www.habr.com