ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼: ਆਕਾਰ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਕੁਬਰਨੇਟਸ ਹਨ

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

ਪੇਸ਼ ਹੈ ਰਿਪੋਰਟ ਦੀ ਵੀਡੀਓ (50 ਮਿੰਟ, ਲੇਖ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਾਣਕਾਰੀ ਭਰਪੂਰ), ਅਤੇ ਨਾਲ ਹੀ ਇਸ ਤੋਂ ਟੈਕਸਟ ਰੂਪ ਵਿੱਚ ਮੁੱਖ ਐਬਸਟਰੈਕਟ।

ਨੋਟ: ਇਸ ਪੋਸਟ ਦੇ ਅੰਤ ਵਿੱਚ ਵੀਡੀਓ ਅਤੇ ਪੇਸ਼ਕਾਰੀ ਵੀ ਉਪਲਬਧ ਹੈ।

ਜਾਣ ਪਛਾਣ

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

ਮੈਂ ਇਸ ਗ੍ਰਾਫ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗਾ, ਜਿਸਦਾ ਲੇਖਕ (2015 ਵਿੱਚ) ਬਣ ਗਿਆ ਹੈ ਮਾਰਟਿਨ ਫੋਲਰ:

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

ਮੈਂ ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਮਾਮਲੇ ਲਈ ਇਸ ਗ੍ਰਾਫ ਵਿੱਚ ਜੋੜਾਂਗਾ:

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

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

ਲਾਭਦਾਇਕ ਅਤੇ ਹਾਨੀਕਾਰਕ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ

ਅਤੇ ਇੱਥੇ ਮੁੱਖ ਵਿਚਾਰ ਹੈ:

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

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

"ਮੁੱਖ ਵਿਚਾਰ" ਵੱਲ ਵਾਪਸ ਜਾਣਾ: ਕੀ ਮੈਨੂੰ ਆਪਣੇ ਅਨੁਭਵ 'ਤੇ ਬਿਲਕੁਲ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਇਸ ਸਾਲ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਮੈਂ ਦੇਖਿਆ ਹੈ 85 ਪ੍ਰੋਜੈਕਟ. ਉਹ ਸਾਰੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨਹੀਂ ਸਨ (ਲਗਭਗ ਇੱਕ ਤਿਹਾਈ ਤੋਂ ਅੱਧੇ ਕੋਲ ਅਜਿਹੀ ਆਰਕੀਟੈਕਚਰ ਸੀ), ਪਰ ਇਹ ਅਜੇ ਵੀ ਵੱਡੀ ਗਿਣਤੀ ਹੈ। ਅਸੀਂ (Flant ਕੰਪਨੀ) ਆਊਟਸੋਰਸਰਾਂ ਵਜੋਂ ਛੋਟੀਆਂ ਕੰਪਨੀਆਂ (5 ਡਿਵੈਲਪਰਾਂ ਦੇ ਨਾਲ) ਅਤੇ ਵੱਡੀਆਂ (~ 500 ਡਿਵੈਲਪਰਾਂ ਦੇ ਨਾਲ) ਵਿੱਚ ਵਿਕਸਤ ਕੀਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਕਿਸਮ ਨੂੰ ਦੇਖਣ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਵਾਧੂ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਇਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਾਲਾਂ ਵਿੱਚ ਲਾਈਵ ਅਤੇ ਵਿਕਸਤ ਦੇਖਦੇ ਹਾਂ।

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਕਿਉਂ?

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਫਾਇਦਿਆਂ ਬਾਰੇ ਸਵਾਲ ਕਰਨ ਲਈ ਉੱਥੇ ਹੈ ਬਹੁਤ ਖਾਸ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤੇ ਮਾਰਟਿਨ ਫੋਲਰ ਤੋਂ:

1. ਮਾਡਿਊਲਰਿਟੀ ਦੀਆਂ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ;
2. ਸੁਤੰਤਰ ਤੈਨਾਤੀ;
3. ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ।

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

ਜੇ ਅਸੀਂ "ਸੰਵੇਦਨਾਵਾਂ ਵਿੱਚ" ਕੁਝ ਬਿੰਦੂਆਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਾਂ, ਤਾਂ:

• ਮੋਡੀਊਲਾਂ ਦੀਆਂ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ: ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਭਿਆਨਕ ਮੋਨੋਲਿਥ ਹੈ, ਅਤੇ ਹੁਣ ਸਭ ਕੁਝ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਸਾਫ਼-ਸੁਥਰਾ ਪ੍ਰਬੰਧ ਕੀਤਾ ਜਾਵੇਗਾ, ਜਿਸ ਵਿੱਚ ਹਰ ਚੀਜ਼ "ਸ਼ੈਲਫਾਂ ਉੱਤੇ" ਹੈ, ਗਰਮ ਅਤੇ ਨਰਮ ਮਿਸ਼ਰਤ ਨਹੀਂ ਹਨ;
• ਤੈਨਾਤੀ ਦੀ ਸੁਤੰਤਰਤਾ: ਅਸੀਂ ਸੇਵਾਵਾਂ ਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵਾਂਗੇ ਤਾਂ ਜੋ ਵਿਕਾਸ ਤੇਜ਼ੀ ਨਾਲ ਹੋ ਸਕੇ (ਸਮਾਂਤਰ ਵਿੱਚ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ);
• ਵਿਕਾਸ ਦੀ ਸੁਤੰਤਰਤਾ: ਅਸੀਂ ਇਹ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਇੱਕ ਟੀਮ/ਡਿਵੈਲਪਰ ਨੂੰ ਦੇ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਉਹ ਇੱਕ ਦੂਜੇ ਨੂੰ, ਜਿਸਦੇ ਸਦਕਾ ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਸਕਦੇ ਹਾਂ;
• боਵਧੇਰੇ ਭਰੋਸੇਯੋਗਤਾ: ਜੇਕਰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਡਿਗਰੇਡੇਸ਼ਨ ਹੁੰਦਾ ਹੈ (20 ਵਿੱਚੋਂ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਡਿੱਗਦਾ ਹੈ), ਤਾਂ ਸਿਰਫ਼ ਇੱਕ ਬਟਨ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ, ਅਤੇ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ।

ਆਮ (ਹਾਨੀਕਾਰਕ) ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ

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

ਇੱਕ ਉਦਾਹਰਨ ਇੱਕ ਸੰਖੇਪ ਔਨਲਾਈਨ ਸਟੋਰ ਹੋਵੇਗਾ ਜੋ ਐਮਾਜ਼ਾਨ ਜਾਂ ਘੱਟੋ ਘੱਟ ਓਜ਼ੋਨ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਜਾ ਰਿਹਾ ਹੈ. ਇਸਦਾ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

ਕਾਰਨਾਂ ਦੇ ਸੁਮੇਲ ਲਈ, ਇਹ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਲਿਖੇ ਗਏ ਹਨ:

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

ਇਸ ਦੇ ਨਤੀਜੇ ਕੀ ਹਨ?

ਫੋਲਰ ਕੋਲ ਵੀ ਇਹ ਹੈ ਇੱਕ ਲੇਖ ਹੈ - ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ "ਭੁਗਤਾਨ" ਬਾਰੇ:

ਅਤੇ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਕੀ ਸਾਡੀਆਂ ਉਮੀਦਾਂ ਪੂਰੀਆਂ ਹੋਈਆਂ ਹਨ।

ਮੋਡੀਊਲ ਦੀਆਂ ਸੀਮਾਵਾਂ ਸਾਫ਼ ਕਰੋ...

ਪਰ ਸਾਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿੰਨੀਆਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ?ਤਬਦੀਲੀ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਲਈ? ਕੀ ਅਸੀਂ ਇਹ ਵੀ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਾਂ ਕਿ ਵੰਡੇ ਟਰੇਸਰ ਤੋਂ ਬਿਨਾਂ ਸਭ ਕੁਝ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ (ਆਖ਼ਰਕਾਰ, ਕਿਸੇ ਵੀ ਬੇਨਤੀ ਨੂੰ ਅੱਧੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੁਆਰਾ ਸੰਸਾਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)?

ਇੱਕ ਪੈਟਰਨ ਹੈ"ਗੰਦਗੀ ਦਾ ਵੱਡਾ ਢੇਰ", ਅਤੇ ਇੱਥੇ ਇਹ ਗੰਦਗੀ ਦਾ ਇੱਕ ਵੰਡਿਆ ਹੋਇਆ ਗੰਢ ਨਿਕਲਿਆ. ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ, ਇੱਥੇ ਬੇਨਤੀਆਂ ਕਿਵੇਂ ਹੁੰਦੀਆਂ ਹਨ ਇਸਦਾ ਇੱਕ ਅੰਦਾਜ਼ਨ ਦ੍ਰਿਸ਼ਟਾਂਤ ਹੈ:

ਤੈਨਾਤੀ ਦੀ ਸੁਤੰਤਰਤਾ...

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

ਤਕਨਾਲੋਜੀ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ...

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

ਵਿਕਾਸ ਦੀ ਸੁਤੰਤਰਤਾ...

ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ (ਇੰਨੇ ਸਾਰੇ ਹਿੱਸਿਆਂ ਦੇ ਨਾਲ) ਲਈ ਇੱਕ ਟੈਸਟ ਲੂਪ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ? ਪਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਇਸਨੂੰ ਅੱਪ ਟੂ ਡੇਟ ਰੱਖਣ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਸਭ ਇਸ ਤੱਥ ਵੱਲ ਖੜਦਾ ਹੈ ਕਿ ਟੈਸਟ ਸਰਕਟਾਂ ਦੀ ਅਸਲ ਸੰਖਿਆ, ਜਿਸਨੂੰ ਅਸੀਂ ਸਿਧਾਂਤਕ ਰੂਪ ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹਾਂ, ਘੱਟੋ-ਘੱਟ ਹੋਣ ਲਈ ਬਾਹਰ ਕਾਮੁਕ.

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

ਵੱਖਰਾ ਸਕੇਲਿੰਗ...

ਹਾਂ, ਪਰ ਇਹ ਵਰਤੇ ਗਏ DBMS ਦੇ ਖੇਤਰ ਵਿੱਚ ਸੀਮਿਤ ਹੈ। ਦਿੱਤੇ ਗਏ ਆਰਕੀਟੈਕਚਰ ਉਦਾਹਰਨ ਵਿੱਚ, ਕੈਸੈਂਡਰਾ ਨੂੰ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੋਵੇਗੀ, ਪਰ MySQL ਅਤੇ PostgreSQL ਹੋਣਗੇ।

Боਵੱਧ ਭਰੋਸੇਯੋਗਤਾ...

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

ਲੋਡ ਮਾਪਣਯੋਗਤਾ...

ਇਹ ਸੱਚਮੁੱਚ ਵਧੀਆ ਹੈ।

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ "ਹਲਕੀਤਾ"...

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

ਅਤੇ ਇੱਥੇ ਸਾਡੀਆਂ ਉਮੀਦਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦਾ ਨਤੀਜਾ ਹੈ:

ਪਰ ਇਹ ਸਭ ਕੁਝ ਨਹੀਂ ਹੈ!

ਕਿਉਂਕਿ:

• ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸਾਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਬੱਸ ਦੀ ਲੋੜ ਪਵੇਗੀ।
• ਸਹੀ ਸਮੇਂ 'ਤੇ ਇਕਸਾਰ ਬੈਕਅੱਪ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ? ਇੱਕੋ ਇੱਕ реальный ਇਸ ਲਈ ਆਵਾਜਾਈ ਨੂੰ ਬੰਦ ਕਰਨ ਦਾ ਵਿਕਲਪ ਹੈ। ਪਰ ਉਤਪਾਦਨ ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ?
• ਜੇ ਅਸੀਂ ਕਈ ਖੇਤਰਾਂ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਸਥਿਰਤਾ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ ਇੱਕ ਬਹੁਤ ਹੀ ਮਿਹਨਤੀ ਕੰਮ ਹੈ।
• ਕੇਂਦਰੀਕ੍ਰਿਤ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਸਾਨੂੰ PHP ਸੰਸਕਰਣ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਹਰੇਕ ਰਿਪੋਜ਼ਟਰੀ ਲਈ ਵਚਨਬੱਧ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ (ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਦਰਜਨਾਂ ਹਨ).
• ਕਾਰਜਸ਼ੀਲ ਜਟਿਲਤਾ ਵਿੱਚ ਵਾਧਾ, ਔਫਹੈਂਡ, ਘਾਤਕ ਹੈ।

ਇਸ ਸਭ ਦਾ ਕੀ ਕਰੀਏ?

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

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

ਪਰ ਕੀ ਜੇ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਸਥਿਤੀ ਵਿਚ ਹਾਂ?

ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਸੁਲਝਾਉਣ ਦਾ ਪਹਿਲਾ ਕਦਮ ਹੈ ਉਸ ਨਾਲ ਸਹਿਮਤ ਹੋਣਾ ਅਤੇ ਸਮਝਣਾ ਕਿ ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਹੈ, ਜਿਸ ਦਾ ਅਸੀਂ ਹੋਰ ਦੁੱਖ ਨਹੀਂ ਝੱਲਣਾ ਚਾਹੁੰਦੇ।

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

ਉਦਾਹਰਨ ਲਈ, ਉੱਪਰ ਦੱਸੇ ਗਏ ਸਮੂਹਿਕ ਚਿੱਤਰ ਲਈ ...

ਸਭ ਤੋਂ ਵੱਧ ਸ਼ੱਕੀ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਓ:

ਫਰੰਟਐਂਡ ਪੀੜ੍ਹੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਸਾਰੀਆਂ ਮਾਈਕਰੋਸੇਵਾਵਾਂ ਨੂੰ ਜੋੜੋ:

... ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਿੱਚ, ਇੱਕ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ (ਆਧੁਨਿਕ ਅਤੇ ਆਮ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਖੁਦ ਸੋਚਦੇ ਹੋ) ਭਾਸ਼ਾ/ਫ੍ਰੇਮਵਰਕ:

ਇਸ ਵਿੱਚ ਇੱਕ ORM (ਇੱਕ DBMS) ਅਤੇ ਪਹਿਲਾਂ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨ ਹੋਣਗੇ:

... ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋਏ, ਉੱਥੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦੇ ਹੋ:

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

ਸੰਖੇਪ ਕਰਨ ਲਈ

ਵੱਡੀ ਤਸਵੀਰ 'ਤੇ ਦੇਖੋ. ਅਕਸਰ, ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨਾਲ ਇਹ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਆਪਣਾ ਕੰਮ ਲਿਆ, ਪਰ "ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨਾਲ ਖੇਡਣਾ" ਚਾਹੁੰਦਾ ਸੀ।

"ਮਾਈਕਰੋ ਸਰਵਿਸਿਜ਼" ਸ਼ਬਦ ਵਿੱਚ "ਮਾਈਕ੍ਰੋ" ਹਿੱਸਾ ਬੇਲੋੜਾ ਹੈ।. ਉਹ ਸਿਰਫ "ਮਾਈਕ੍ਰੋ" ਹਨ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਵਿਸ਼ਾਲ ਮੋਨੋਲਿਥ ਤੋਂ ਛੋਟੇ ਹਨ। ਪਰ ਉਹਨਾਂ ਨੂੰ ਛੋਟੀ ਨਾ ਸਮਝੋ।

ਅਤੇ ਅੰਤਮ ਵਿਚਾਰ ਲਈ, ਆਓ ਅਸਲ ਚਾਰਟ 'ਤੇ ਵਾਪਸ ਚਲੀਏ:

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

ਵੀਡੀਓਜ਼ ਅਤੇ ਸਲਾਈਡਾਂ

ਭਾਸ਼ਣ ਤੋਂ ਵੀਡੀਓ (~ 50 ਮਿੰਟ; ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਦਰਸ਼ਕਾਂ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਵਨਾਵਾਂ ਨੂੰ ਵਿਅਕਤ ਨਹੀਂ ਕਰਦਾ, ਜਿਸ ਨੇ ਰਿਪੋਰਟ ਦੇ ਮੂਡ ਨੂੰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ, ਪਰ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੈ):

ਰਿਪੋਰਟ ਦੀ ਪੇਸ਼ਕਾਰੀ:

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਹੋਰ ਰਿਪੋਰਟਾਂ:

• «ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 28 ਮਈ, 2018);
• «ਕੁਬਰਨੇਟਸ ਅਤੇ ਗਿਟਲੈਬ ਦੇ ਨਾਲ CI/CD ਵਧੀਆ ਅਭਿਆਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਹਾਈਲੋਡ++ 'ਤੇ 7 ਨਵੰਬਰ, 2017);
• «ਛੋਟੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਨਾਲ ਸਾਡਾ ਅਨੁਭਵ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 6 ਜੂਨ, 2017);
• «ਅਸੀਂ ਇੱਕ ਡੈਪ ਨਾਲ CI/CD ਲਈ ਡੌਕਰ ਚਿੱਤਰ ਜਲਦੀ ਅਤੇ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦੇ ਹਾਂ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਹਾਈਲੋਡ++ 'ਤੇ 8 ਨਵੰਬਰ, 2016);
• «ਡੌਕਰ ਨਾਲ ਨਿਰੰਤਰ ਸਪੁਰਦਗੀ ਅਭਿਆਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 31 ਮਈ, 2016).

ਤੁਹਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਪ੍ਰਕਾਸ਼ਨਾਂ ਵਿੱਚ ਵੀ ਦਿਲਚਸਪੀ ਹੋ ਸਕਦੀ ਹੈ:

• «2018 ਵਿੱਚ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਪਾਗਲਪਨ ਦੀ ਮੌਤ";
• «ਗੂਗਲ ਦੇ ਅਨੁਸਾਰ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ 7 ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ";
• «ਕੁਬਰਨੇਟਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਚੁਣੌਤੀਆਂ 'ਤੇ ਨਿਊ ਸਟੈਕ ਦੇ ਅੰਕੜੇ".

ਸਰੋਤ: www.habr.com