TechForge ਦੀ ਨਵੀਂ ਗਾਈਡ ਚੇਤਾਵਨੀ ਦਿੰਦੀ ਹੈ ਕਿ ਕਈ ਨਵੇਂ ਮਾਈਕਰੋਸਰਵਿਸ (microservices) ਪ੍ਰੋਜੈਕਟ ਅੰਤ ਵਿੱਚ "ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਮੋਨੋਲਿਥ" (distributed monoliths) ਬਣ ਕੇ ਰਹਿ ਜਾਂਦੇ ਹਨ, ਜੋ ਕਿ ਸਕੇਲਿੰਗ ਦੇ ਕਿਸੇ ਵੀ ਫਾਇਦੇ ਤੋਂ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਕਾਲਜ਼ ਦੀ ਲੇਟੈਂਸੀ (latency) ਦਿੰਦੇ ਹਨ। ਇਹ ਲੇਖ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਮਜ਼ਬੂਤ ਮੋਨੋਲਿਥ (monolith) ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਉਦੋਂ ਹੀ ਵੱਖ ਕਰਨ ਦੀ ਅਪੀਲ ਕਰਦਾ ਹੈ ਜਦੋਂ ਸਪੱਸ਼ਟ ਸਕੇਲਿੰਗ ਜਾਂ ਮਾਲਕੀ (ownership) ਦੀਆਂ ਲੋੜਾਂ ਪੈਦਾ ਹੋਣ।
ਟੀਮਾਂ ਮਾਈਕਰੋਸਰਵਿਸਜ਼ ਵੱਲ ਇੰਨੀ ਜਲਦੀ ਕਿਉਂ ਭੱਜਦੀਆਂ ਹਨ
ਮਾਈਕਰੋਸਰਵਿਸਜ਼ ਦਾ ਆਕਰਸ਼ਣ ਸਪੱਸ਼ਟ ਹੈ: ਸੁਤੰਤਰ ਸੇਵਾਵਾਂ (independent services), ਵੱਖਰੇ ਡਿਪਲਾਈਮੈਂਟਸ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਹਰੇਕ ਹਿੱਸੇ ਨੂੰ ਉਸਦੀਆਂ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ 'ਤੇ ਸਕੇਲ ਕਰਨ ਦਾ ਵਾਅਦਾ। ਸਟਾਰਟ-ਅੱਪ ਸੱਭਿਆਚਾਰ ਅਤੇ ਹਾਲੀਆ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ ਨੇ ਇਸ ਪੈਟਰਨ ਨੂੰ ਆਧੁਨਿਕ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਪ੍ਰਤੀਕ ਵਜੋਂ ਬਦਲ ਦਿੱਤਾ ਹੈ। ਫਿਰ ਵੀ, ਇੱਕ ਮੋਨੋਲਿਥ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਵੱਖ ਕਰਨ ਨਾਲ ਅਕਸਰ ਇੱਕ ਨਵਾਂ ਕਿਸਮ ਦਾ ਮੋਨੋਲਿਥ ਬਣ ਜਾਂਦਾ ਹੈ—ਡਜ਼ਨਾਂ ਨੈੱਟਵਰਕਡ ਕੰਪੋਨੈਂਟਸ। ਇਸਦੀ ਕੀਮਤ? ਉੱਚੀ ਲੇਟੈਂਸੀ, ਮੁਸ਼ਕਲ ਡੀਬੱਗਿੰਗ, ਅਤੇ ਵਧੇਰੇ ਆਪਰੇਸ਼ਨਲ ਓਵਰਹੈੱਡ, ਜਦੋਂ ਕਿ ਅਸਲ ਫਾਇਦੇ ਦੂਰ ਹੀ ਰਹਿੰਦੇ ਹਨ।
ਪਹਿਲੀ ਗਲਤੀ: ਸਿਰਫ਼ ਨਾਮ ਦੇ ਲਈ ਮੋਨੋਲਿਥ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨਾ
ਟੀਮਾਂ ਅਕਸਰ ਇੱਕ ਸਿੰਗਲ ਕੋਡਬੇਸ (codebase) ਅਤੇ ਸਾਂਝੇ ਡਾਟਾਬੇਸ ਨੂੰ ਰੱਖਦੇ ਹੋਏ ਸਿਸਟਮ ਨੂੰ "ਮਾਈਕਰੋ-ਸਰਵਿਸ-ਅਧਾਰਤ" (micro-service-based) ਕਹਿੰਦੀਆਂ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ ਤੰਗ ਤਰ੍ਹਾਂ ਜੁੜੇ ਹੋਏ (tightly coupled) ਮੋਡਿਊਲਜ਼ ਦੀ ਇੱਕ ਲੜੀ ਬਣਦੀ ਹੈ ਜੋ ਅਜੇ ਵੀ HTTP ਜਾਂ RPC ਰਾਹੀਂ ਇੱਕ ਦੂਜੇ ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ। ਗਾਈਡ ਇਸਨੂੰ "ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਮੋਨੋਲਿਥ" ਕਹਿੰਦੀ ਹੈ। ਇਸ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਇੱਕ ਰਵਾਇਤੀ ਮੋਨੋਲਿਥ ਵਰਗੀਆਂ ਹੀ ਹਨ—ਤੰਗ ਕਪਲਿੰਗ ਅਤੇ ਬਾਕੀ ਹਿੱਸਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਹਿੱਸੇ ਨੂੰ ਬਦਲਣ ਵਿੱਚ ਮੁਸ਼ਕਲ—ਪਲੱਸ ਨੈੱਟਵਰਕ ਹੌਪਸ (network hops) ਤੋਂ ਵਧ ਗਈ ਲੇਟੈਂਸੀ।
ਇਸ ਦੀ ਬਜਾਏ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਪਹਿਲਾਂ ਇੱਕ ਸਾਫ਼ ਮੋਨੋਲਿਥ ਬਣਾਓ। ਸਪੱਸ਼ਟ ਮੋਡਿਊਲ ਸੀਮਾਵਾਂ (boundaries) ਨਿਰਧਾਰਤ ਕਰੋ, ਡਾਟਾ ਲੇਅਰ ਨੂੰ ਇਕਜੁੱਟ ਰੱਖੋ, ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਯੂਨਿਟ ਵਜੋਂ ਟੈਸਟ ਅਤੇ ਡਿਪਲੋਏ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਮੋਡਿਊਲ ਨੂੰ ਉਸਦੀ ਆਪਣੀ ਸੇਵਾ ਵਿੱਚ ਉਦੋਂ ਹੀ ਕੱਢੋ ਜਦੋਂ ਉਸਨੂੰ ਸੁਤੰਤਰ ਸਕੇਲਿੰਗ ਜਾਂ ਵੱਖਰੀ ਟੀਮ ਦੀ ਮਾਲਕੀ ਦੀ ਲੋੜ ਹੋਵੇ।
ਤਕਨੀਕੀ ਲੇਅਰ ਬਨਾਮ ਬਿਜ਼ਨਸ ਕੈਪੇਬਿਲਟੀ (business capability) ਅਨੁਸਾਰ ਵੱਖ ਕਰਨਾ
ਇੱਕ ਹੋਰ ਆਮ ਗਲਤੀ ਤਕਨੀਕੀ ਚਿੰਤਾਵਾਂ—UI, ਬਿਜ਼ਨਸ ਲੌਜਿਕ, ਜਾਂ ਡਾਟਾ ਐਕਸੈਸ—ਦੇ ਅਨੁਸਾਰ ਸੇਵਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਹੈ। ਇਹ ਇੱਕ ਸਿੰਗਲ ਆਪਰੇਸ਼ਨ ਲਈ ਇੱਕ ਰਿਕੁਐਸਟ ਨੂੰ ਸੇਵਾਵਾਂ ਦੀ ਇੱਕ ਲੜੀ ਰਾਹੀਂ ਲੰਘਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਰਿਸਪਾਂਸ ਸਮਾਂ ਵਧ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕਮਜ਼ੋਰ ਡਿਪੈਂਡੈਂਸੀ ਗ੍ਰਾਫ ਬਣਦਾ ਹੈ।
ਬਿਹਤਰ ਪਹੁੰਚ: ਸੇਵਾਵਾਂ ਨੂੰ ਬਿਜ਼ਨਸ ਕੈਪੇਬਿਲਟੀਜ਼ ਜਿਵੇਂ ਕਿ “orders,” “payments,” ਜਾਂ “inventory” ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੰਗਠਿਤ ਕਰੋ। ਹਰੇਕ ਕੈਪੇਬਿਲਟੀ ਨੂੰ ਆਪਣੇ ਡਾਟਾ ਅਤੇ ਆਪਣੇ API ਦਾ ਮਾਲਕ ਬਣਨ ਦਿਓ, ਜਿਸ ਨਾਲ ਰਿਕੁਐਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਲੇਅਰਾਂ ਵਿੱਚ ਹੋਪ (hop) ਕਰਨ ਦੀ ਲੋੜ ਖਤਮ ਹੋ ਜਾਵੇਗੀ।
ਡਾਟਾ ਮਾਲਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਜਦੋਂ ਦੋ ਸੇਵਾਵਾਂ ਇੱਕੋ ਡਾਟ
Kubernetes, ਹਾਲਾਂਕਿ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਸਿੱਖਣ ਲਈ ਬਹੁਤ ਮਿਹਨਤ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਸ ਦਾ ਸੰਚਾਲਨ (operational overhead) ਵੀ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੈ। ਕੁਝ ਸੀਮਤ ਸੇਵਾਵਾਂ (services) ਲਈ, Docker Compose ਪੂਰੇ ਸਟੈਕ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦੀ ऑर्ਕੇਸਟਰੇਸ਼ਨ (orchestration) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਕਿਸੇ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਪਲੇਟਫਾਰਮ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ, ਡਿਪਲਾਈਮੈਂਟ ਦੀ ਬਾਰੰਬਾਰਤਾ, ਜਾਂ ਟੀਮ ਦਾ ਆਕਾਰ ਇਸ ਦੀ ਮੰਗ ਕਰੇ।
ਸੇਵਾਵਾਂ ਨੂੰ ਟੀਮ ਦੀ ਮਾਲਕੀ ਨਾਲ ਜੋੜੋ
ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ (Microservices) ਦਾ ਕੁਝ ਹਿੱਸਾ ਇਸ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ ਤਾਂ ਜੋ ਛੋਟੀਆਂ, ਖੁਦਮੁਖਤਿਆਰ ਟੀਮਾਂ ਕਿਸੇ ਸੇਵਾ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ (lifecycle) ਦੀ ਮਾਲਕੀ ਕਰ ਸਕਣ। ਜੇਕਰ ਇੱਕੋ ਟੀਮ ਦਸ ਸੇਵਾਵਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਤਾਂ ਤਾਲਮੇਲ ਦੀ ਲਾਗਤ (coordination costs) ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਧ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਮੌਜੂਦਾ ਲਾਭ ਘਟ ਜਾਂਦੇ ਹਨ। ਇਹ ਗਾਈਡ ਸੁਝਾਅ ਦਿੰਦੀ ਹੈ ਕਿ ਦਸ ਤੋਂ ਘੱਟ ਲੋਕਾਂ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ ਮੋਨੋਲਿਥ (monolith) ਵਧੇਰੇ ਫਾਇਦੇਮੰਦ ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਕਿ ਮੋਡਿਊਲਰ ਵਿਕਾਸ (modular development) ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਦੇ ਨਾਲ-ਨਾਲ ਸਰਲਤਾ ਨੂੰ ਵੀ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ।
ਵਿਰੋਧੀ ਦਲੀਲ: ਜਦੋਂ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ
ਇਹ ਗਾਈਡ ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦੀ ਕਿ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਆਪਣੇ ਆਪ ਵਿੱਚ ਮਾੜੀਆਂ ਹਨ। ਅਜਿਹੇ ਮਾਹੌਲ ਵਿੱਚ ਜਿੱਥੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦੀਆਂ ਸਕੈਲਿੰਗ ਲੋੜਾਂ (scaling requirements) ਬਹੁਤ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਾਂ ਜਿੱਥੇ ਨਿਯਮਤ ਪਾਬੰਦੀਆਂ (regulatory constraints) ਸਖ਼ਤ ਡਾਟਾ ਆਇਸੋਲੇਸ਼ਨ ਦੀ ਮੰਗ ਕਰਦੀਆਂ ਹਨ, ਉੱਥੇ ਇਹ ਪੈਟਰਨ ਅਸਲ ਮੁੱਲ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਕਈ ਪ੍ਰੋਡਕਟ ਲਾਈਨਾਂ ਵਾਲੀਆਂ ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਅਕਸਰ ਪਾਉਂਦੀਆਂ ਹਨ ਕਿ ਸੁਤੰਤਰ ਸੇਵਾਵਾਂ ਟੀਮਾਂ ਵਿਚਕਾਰ ਰਗੜ (friction) ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਤੇਜ਼ ਰਿਲੀਜ਼ ਚੱਕਰਾਂ (release cycles) ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਮੁੱਖ ਗੱਲ ਇਰਾਦਾ (intentionality) ਹੈ। ਜੇਕਰ ਕੋਈ ਟੀਮ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਨੂੰ ਇਸ ਲਈ ਅਪਣਾਉਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਖਾਸ ਫੀਚਰ ਲਈ ਪ੍ਰਤੀ ਸੈਕਿੰਡ ਲੱਖਾਂ ਰਿਕਵੈਸਟਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦੀ ਲੋੜ ਹੈ, ਜਾਂ ਇਸ ਲਈ ਕਿਉਂਕਿ ਇੱਕ ਨਵੀਂ ਪ੍ਰੋਡਕਟ ਲਾਈਨ ਦੀ ਮਾਲਕੀ ਇੱਕ ਵੱਖਰੇ ਬਿਜ਼ਨਸ ਯੂਨਿਟ ਕੋਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਵਧ ਗਈ ਗੁੰਝਲਤਾ ਜਾਇਜ਼ ਹੈ। ਗਾਈਡ ਦੀਆਂ ਚੇਤਾਵਨੀਆਂ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜਿੱਥੇ ਫੈਸਲਾ ਅਸਲ ਲੋੜਾਂ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਹਾਈਪ (hype) ਕਾਰਨ ਲਿਆ ਗਿਆ ਹੋਵੇ।
ਅੱਗੇ ਕਿਸ ਚੀਜ਼ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਹੈ
ਜਿਵੇਂ-ਜਿਵੇਂ ਵਧੇਰੇ ਕੰਪਨੀਆਂ ਕਲਾਉਡ-ਨੇਟਿਵ ਸਟੈਕ (cloud-native stacks) ਅਪਣਾ ਰਹੀਆਂ ਹਨ, ਸਰਵਿਸ ਮੈਸ਼ (service mesh), ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਟ੍ਰੇਸਿੰਗ (distributed tracing), ਅਤੇ ਆਟੋਮੇਟਿਡ ਕੈਨਰੀ ਡਿਪਲਾਈਮੈਂਟਸ (automated canary deployments) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਟੂਲ ਹੋਰ ਬਿਹਤਰ ਹੁੰਦੇ ਜਾ ਰਹੇ ਹਨ। ਇਹ ਤਰੱਕੀਆਂ ਸੰਚਾਲਨ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ ਪਰ ਗਾਈਡ ਵਿੱਚ ਦੱਸੇ ਗਏ ਮੂਲ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰਦੀਆਂ। ਟੀਮਾਂ ਨੂੰ ਅਬਜ਼ਰਵੇਬਿਲਟੀ ਪਲੇਟਫਾਰਮਾਂ (observability platforms) ਅਤੇ ਐਸਿੰਕ ਮੈਸੇਜਿੰਗ ਫਰੇਮਵਰਕਾਂ (async messaging frameworks) ਦੇ ਵਿਕਾਸ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ ਤਰਕ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਉਹ ਚਲਾਉਂਦੇ ਹਨ।
ਸਿੱਖਿਆ
ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਕਿਸੇ ਮੰਜ਼ਿਲ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਇੱਕ ਸਾਧਨ ਹਨ, ਉਹ ਖੁਦ ਮੰਜ਼ਿਲ ਨਹੀਂ ਹਨ। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਮੋਨੋਲਿਥ (monolith) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਹਰੇਕ ਸੇਵਾ ਨੂੰ ਉਸਦੇ ਡਾਟਾ ਦੀ ਅਸਲ ਮਾਲਕੀ ਦਿਓ, ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਉੱਥੇ ਅਸਿੰਕਰੋਨਸ ਸੰਚਾਰ (asynchronous communication) ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਕੋਡ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਤੋਂ ਹੀ ਲਚਕਤਾ (resilience) ਅਤੇ ਅਬਜ਼ਰਵੇਬਿਲਟੀ (observability) ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਜਦੋਂ ਬਿਜ਼ਨਸ ਕੇਸ ਸਪੱਸ਼ਟ ਹੋਵੇ, ਤਾਂ ਜਾਣਬੁੱਝ ਕੇ ਸੇਵਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰੋ; ਨਹੀਂ ਤਾਂ, ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਉਨਾ ਹੀ ਸਰਲ ਰੱਖੋ ਜਿੰਨੀ ਸਮੱਸਿਆ ਦੀ ਮੰਗ ਹੈ।