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

ਮੋਨੋਲਿਥ (Monoliths) ਦਾ ਕੋਆਰਡੀਨੇਸ਼ਨ ਟੈਕਸ

ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ, ਬਿੱਲ ਮਨੁੱਖੀ ਘੰਟਿਆਂ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਆਪਣਾ ਦਿਨ ਸਾਂਝੇ ਕੋਡ, ਸਟਾਈਲ ਅਤੇ ਰਿਲੀਜ਼ ਸ਼ਡਿਊਲ ਨੂੰ ਅਲਾਈਨ ਕਰਨ ਵਿੱਚ ਬਿਤਾਉਂਦੀਆਂ ਹਨ। ਇੱਕ ਡਿਵੈਲਪਰ ਜੋ ਇੱਕ ਮਾਮੂਲੀ ਚੈੱਕਆਊਟ ਫਿਕਸ ਸ਼ਿਪ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਸ਼ਾਇਦ ਦਰਜਨਾਂ ਹੋਰ ਟੀਮਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾ ਰਹੇ ਸਾਂਝੇ ਡਿਪੈਂਡੈਂਸੀ (dependency) ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਪੂਰੇ ਰਿਗਰੈਸ਼ਨ ਸੂਟ (regression suite) ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਇਹ ਲਾਗਤ ਚੁੱਪਚਾਪ ਵਧਦੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਕਲਾਉਡ ਬਿੱਲ 'ਤੇ ਕਦੇ ਵੀ ਇੱਕ ਲਾਈਨ ਆਈਟਮ ਵਜੋਂ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੀ। ਇਹ ਘਟਦੀ ਵੇਗ (velocity), ਕੋਡ ਸਟਾਈਲ ਬਾਰੇ Slack ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਕੰਟੈਕਸ-ਸਵਿਚਿੰਗ (context-switching), ਅਤੇ ਇੱਕ ਅਜਿਹੀ CSS ਆਰਕੀਟੈਕਚਰ ਦੀ ਹੌਲੀ ਰਗੜ ਵਿੱਚ ਲੁਕੀ ਹੁੰਦੀ ਹੈ ਜਿਸਦਾ ਮਾਲਕ ਕੋਈ ਨਹੀਂ ਹੈ ਪਰ ਹਰ ਕੋਈ ਇਸਨੂੰ ਛੂਹਦਾ ਹੈ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਹਾਡੀ ਟੀਮ ਵਧਦੀ ਹੈ, ਇਹ ਟੈਕਸ ਵੀ ਇਸਦੇ ਨਾਲ ਵਧਦਾ ਹੈ। ਕੋਡ ਰਿਵਿਊ ਬੋਟਲਨੇਕਸ ਤਕਨੀਕੀ ਚਿੰਤਾਵਾਂ ਤੋਂ ਸਮਾਜਿਕ ਚਿੰਤਾਵਾਂ ਵੱਲ shifting ਹੋ ਜਾਂਦੇ ਹਨ। ਦੋ ਸੌ ਕੰਟਰੀਬਿਊਟਰਾਂ ਵਾਲੀ ਇੱਕ ਸਿੰਗਲ ਰਿਪੋਜ਼ਟਰੀ ਲੀਨੀਅਰਲੀ (linearly) ਨਹੀਂ ਵਧਦੀ; ਇਹ ਕੰਬੀਨੇਟੋਰੀਅਲੀ (combinatorially) ਵਧਦੀ ਹੈ। ਮਰਜ ਕਿਊਜ਼ (Merge queues) ਪਿੱਛੇ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਰਿਲੀਜ਼ ਟ੍ਰੇਨਾਂ ਦਿਨਾਂ ਤੱਕ ਖਿੱਚ ਜਾਂਦੀਆਂ ਹਨ। ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਇੱਕ ਰਾਜਨੀਤਿਕ ਇਕਾਈ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਨਵੇਂ ਬਟਨ ਵੇਰੀਐਂਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਲਈ ਇੱਕ ਸ਼ਾਸਨ ਪ੍ਰੀਖਿਆ (governing council) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਮੋਨੋਲਿਥ ਬਦਲਾਅ ਦਾ ਵਿਰੋਧ ਬਦਲੇ ਦੀ ਭਾਵਨਾ ਨਾਲ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਬਦਲਾਅ ਦਾ ਵਿਰੋਧ ਇਸ ਲਈ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਸਤਹ ਸਾਂਝੀ ਹੈ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਸਹਿਮਤੀ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ।

ਸੀਮਾਵਾਂ ਤੈਅ ਕਰਨਾ (Drawing Boundaries)

ਮਾਈਕ੍ਰੋਫਰੰਟਐਂਡਸ ਕੋਆਰਡੀਨੇਸ਼ਨ ਲਾਗਤਾਂ ਨੂੰ ਖਾਸ ਸੀਮਾਵਾਂ ਵਿੱਚ ਲੈ ਜਾਂਦੇ ਹਨ। ਸਾਂਝੇ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਬਾਰੇ ਹਫਤਾਵਾਰੀ ਮੀਟਿੰਗ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ ਲਾਈਨ ਖਿੱਚ ਲੈਂਦੇ ਹੋ। ਟੀਮ A ਪ੍ਰੋਡਕਟ ਕੈਟਾਲਾਗ ਦੀ ਮਾਲਕ ਹੈ। ਟੀਮ B ਕਾਰਟ (cart) ਦੀ ਮਾਲਕ ਹੈ। ਉਹ ਇੱਕ ਇਕਰਾਰਨਾਮੇ (contract) 'ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਰੂਟਿੰਗ ਬਾਊਂਡਰੀ ਜਾਂ ਇੱਕ ਸੀਮਤ ਈਵੈਂਟ ਸਕੀਮਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਹ ਗੱਲ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਇਹ ਮੁੱਖ ਵਟਾਂਦਰਾ ਹੈ: ਇੱਕ ਵੱਖਰੇ ਕਿਸਮ ਦੇ ਅਨੁਸ਼ਾਸਨ ਦੇ ਬਦਲੇ ਆਟੋਨੋਮੀ (autonomy)।

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

ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਬਿੱਲ

ਮਾਈਕ੍ਰੋਫਰੰਟਐਂਡਸ ਪਲੇਟਫਾਰਮ ਲਾਗਤਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਇੱਕ ਸ਼ੈੱਲ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਰਨਟਾਈਮ 'ਤੇ ਫਰੈਗਮੈਂਟਸ ਨੂੰ ਜੋੜਨ ਦੇ ਯੋਗ ਹੋਵੇ। ਤੁਹਾਨੂੰ ਇੱਕ ਡਿਪਲੋਇਮੈਂਟ ਪਾਈਪਲਾਈਨ ਦੀ ਲੋੜ

ਕੋਈ ਵੀ ਮਾਡਲ ਮੁਫ਼ਤ ਨਹੀਂ ਹੈ। ਪੰਦਰਾਂ ਲੋਕਾਂ ਵਾਲੀ ਇੱਕ ਸਟਾਰਟਅੱਪ ਨੂੰ ਪਲੇਟਫਾਰਮ ਟੀਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਮੋਡਿਊਲ ਫੈਡਰੇਸ਼ਨ (module federation), ਸੁਤੰਤਰ ਡਿਪਲਾਇਮੈਂਟ ਪਾਈਪਲਾਈਨਾਂ (independent deployment pipelines), ਅਤੇ ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਕੰਟਰੈਕਟ ਟੈਸਟਿੰਗ (distributed contract testing) ਦਾ ਵਾਧੂ ਬੋਝ ਉਨ੍ਹਾਂ ਦੀ ਪੂਰੀ ਰਫ਼ਤਾਰ ਨੂੰ ਖ਼ਤਮ ਕਰ ਦੇਵੇਗਾ। ਉਨ੍ਹਾਂ ਨੂੰ ਤਾਲਮੇਲ (coordination) ਰਾਹੀਂ ਭੁਗਤਾਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਤਾਲਮੇਲ ਸਸਤਾ ਹੈ। ਉਹ ਦਸ ਮਿੰਟ ਦੀ ਗੱਲਬਾਤ ਵਿੱਚ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਪੈਟਰਨ (state management pattern) 'ਤੇ ਸਹਿਮਤ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਉਸੇ ਦੁਪਹਿਰ ਨੂੰ ਇਸਨੂੰ ਸ਼ਿਪ (ship) ਕਰ ਸਕਦੇ ਹਨ।

ਪੰਜ ਸੌ ਲੋਕਾਂ ਵਾਲਾ ਇੱਕ ਉੱਦਮ (enterprise), ਜਿਸ ਵਿੱਚ ਦਰਜਨਾਂ ਬਿਜ਼ਨਸ ਯੂਨਿਟ ਵੱਖ-ਵੱਖ ਤਿਮਾਹੀ ਚੱਕਰਾਂ (quarterly cycles) 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਨੂੰ ਉਲਟ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਤਾਲਮੇਲ ਦਾ ਟੈਕਸ (coordination tax) ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਗਿਆ ਹੈ। ਰਿਲੀਜ਼ ਟ੍ਰੇਨਾਂ (Release trains) ਵਿੱਚ ਹਫ਼ਤੇ ਲੱਗ ਜਾਂਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰਿੰਗ ਹੈੱਡਕਾਊਂਟ (Platform engineering headcount) ਪਹਿਲਾਂ ਹੀ ਬਜਟ ਦੀ ਹਕੀਕਤ ਹੈ, ਇਸ ਲਈ ਮਾਈਕ੍ਰੋਫਰੰਟਐਂਡ ਇਨਫਰਾਸਟ੍ਰਕਚਰ (microfrontend infrastructure) ਜੋੜਨਾ ਇੱਕ ਮਾਮੂਲੀ ਲਾਗਤ ਹੈ, ਨਾ ਕਿ ਕੋਈ ਨਵੀਂ ਲਾਈਨ ਆਈਟਮ। ਉਨ੍ਹਾਂ ਲਈ, ਅਲਾਈਨਮੈਂਟ ਮੀਟਿੰਗਾਂ (alignment meetings) ਦੀ ਬਜਾਏ ਡਿਪਲਾਇਮੈਂਟ ਗ੍ਰਾਫ (deployment graphs) ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਇੱਕ ਤਰਕਪੂਰਨ ਗਣਿਤ ਹੈ।

ਅਸਲੀ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਲਈ ਕਿਹੜਾ ਬਿੱਲ ਵਧੇਰੇ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਸਕੇਲ (scale) ਹੁੰਦਾ ਹੈ। ਮੋਨੋਲਿਥ (Monoliths) ਤੁਹਾਨੂੰ ਮਨੁੱਖੀ ਤਾਲਮੇਲ ਦੀ ਸੀਮਾ 'ਤੇ ਟੈਕਸ ਲਗਾਉਂਦੇ ਹਨ। ਮਾਈਕ੍ਰੋਫਰੰਟਐਂਡ (Microfrontends) ਤੁਹਾਨੂੰ ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਨੀਂਹ 'ਤੇ ਟੈਕਸ ਲਗਾਉਂਦੇ ਹਨ।

ਆਪਣੀ ਕਰੰਸੀ (Currency) ਚੁਣਨਾ

ਜੇਕਰ ਤੁਸੀਂ ਮਾਈਕ੍ਰੋਫਰੰਟਐਂਡ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਇਸ ਬਾਰੇ ਸਪੱਸ਼ਟ ਰਹੋ ਕਿ ਤੁਸੀਂ ਕੀ ਖਰੀਦ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਟੀਮ ਦੀ ਖੁਦਮੁਖਤਿਆਰੀ (autonomy) ਅਤੇ ਸੁਤੰਤਰ ਡਿਪਲਾਏਬਿਲਟੀ (deployability) ਖਰੀਦ ਰਹੇ ਹੋ। ਹੇਠ ਲਿਖੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਫੰਡ ਪ੍ਰਬੰਧ ਕਰਨ ਲਈ ਤਿਆਰ ਰਹੋ:

  • ਇੱਕ ਰਨਟਾਈਮ ਸ਼ੈੱਲ (runtime shell) ਜੋ ਫਰੈਗਮੈਂਟਸ (fragments) ਵਿਚਕਾਰ ਕੰਪੋਜ਼ੀਸ਼ਨ, ਰੂਟਿੰਗ ਅਤੇ ਐਰਰ ਬਾਊਂਡਰੀਜ਼ (error boundaries) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
  • ਇੱਕ ਸਾਂਝੀ ਡਿਪੈਂਡੈਂਸੀ ਪਾਲਿਸੀ (shared dependency policy) ਜੋ ਡਿਡੂਪਲੀਕੇਸ਼ਨ ਰਣਨੀਤੀ (deduplication strategy) 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ, ਨਾ ਕਿ ਸਾਂਝੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਲੌਜਿਕ 'ਤੇ।
  • ਹਰ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਸਰਫੇਸ ਲਈ ਕਰਾਸ-ਟੀਮ ਕੰਟਰੈਕਟ ਟੈਸਟਿੰਗ (cross-team contract testing)।
  • ਇੱਕਸਾਰ ਅੌਬਜ਼ਰਵੇਬਿਲਟੀ (Unified observability) ਜੋ ਵੱਖ-ਵੱਖ ਬੰਡਲਜ਼ (distributed bundles) ਵਿੱਚ ਯੂਜ਼ਰ ਕਲਿੱਕ ਨੂੰ ਜੋੜ ਸਕਦੀ ਹੈ।
  • ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਗਵਰਨੈਂਸ ਮਾਡਲ (performance governance model), ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਇੱਕ ਟੀਮ ਉਸ ਫਾਈਨਲ ਪੇਲੋਡ (final payload) ਦੀ ਮਾਲਕ ਨਹੀਂ ਹੁੰਦੀ ਜਿਸਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਮੋਨੋਲਿਥ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਇਨਵੌਇਸ (invoice) ਬਾਰੇ ਇਮਾਨਦਾਰ ਰਹੋ। ਤੁਸੀਂ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ (synchronization) ਦੇ ਬਦਲੇ ਸਰਲਤਾ ਖਰੀਦ ਰਹੇ ਹੋ। ਇਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਉਮੀਦ ਰੱਖੋ:

  • ਸਾਂਝੀ ਕੋਡ ਮਾਲਕੀ (shared code ownership) ਅਤੇ ਇਸਨੂੰ ਇਕਸਾਰ ਰੱਖਣ ਲਈ ਲੋੜੀਂਦੇ ਗਵਰਨੈਂਸ ਰੀਤੀ-ਰਿਵਾਜ।
  • ਇੱਕ ਰਿਲੀਜ਼ ਕੈਡੈਂਸ (release cadence) ਜੋ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸਭ ਤੋਂ ਹੌਲੀ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਹੁੰਦਾ ਹੈ।
  • ਲਾਇਬ੍ਰੇਰੀ ਅੱਪਗ੍ਰੇਡਾਂ 'ਤੇ ਵਿਸ਼ਾਲ ਬਲਾਸਟ ਰੇਡੀਅਸ (wide blast radius)।
  • ਇਹ ਕੜਵੀ ਸੱਚਾਈ ਕਿ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਰਫ਼ਤਾਰ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਸਾਵਧਾਨ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਰਫ਼ਤਾਰ ਦੇ ਬਰਾਬਰ ਹੋ ਜਾਵੇਗੀ।

ਅਸਲੀ ਸਿੱਖਿਆ (The Real Takeaway)

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