ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਸਟਾਰਟਅਪਾਂ ਨੂੰ ਫਿਕਸਡ capacity ਵਾਲੇ ਖਰਚਾਂ ਤੋਂ ਇਸਤੇਮਾਲ-ਅਧਾਰਿਤ ਬਿੱਲਿੰਗ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ। ਪ੍ਰਾਇਸਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਲੁਕਿਆ ਹੋਇਆ ਖਰਚ ਕਿੱਥੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਖਰਚ ਦਾ ਅੰਦਾਜ਼ਾ ਕਿਵੇਂ ਲਗਾਇਆ ਜਾਵੇ — ਇਹ ਸਭ ਸਿੱਖੋ।
ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਪਹਿਲੇ ਸਵਾਲ ਨੂੰ ਹੀ ਬਦਲ ਦੇਂਦੇ ਹਨ: ਪੂਰਵ-ਨਿਰਧਾਰਿਤ “ਸਾਨੂੰ ਕਿੰਨੀ ਡੇਟਾਬੇਸ capacity ਖ਼ਰੀਦਣੀ ਚਾਹੀਦੀ ਹੈ?” ਦੇ ਬਜਾਏ ਤੁਸੀਂ ਪੁੱਛਦੇ ਹੋ “ਅਸੀਂ ਕਿੰਨੀ ਡੇਟਾਬੇਸ ਵਰਤੋਂਗੇ?” ਇਹ ਸੁਧਾਰਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਬਜਟਿੰਗ, ਫੋਰਕਾਸਟਿੰਗ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਪ੍ਰੋਡਕਟ ਫੈਸਲਿਆਂ ਨੂੰ ਵੀ ਮੁੜ-ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਪਰੰਪਰਿਕ ਡੇਟਾਬੇਸ ਨਾਲ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਈਜ਼ (CPU/RAM/storage) ਚੁਣਦੇ ਹੋ, ਉਸ ਨੂੰ ਰਿਜ਼ਰਵ ਕਰਦੇ ਹੋ ਅਤੇ ਉਸਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਚਾਹੇ ਟਰੈਫਿਕ ਜ਼ਿਆਦਾ ਹੋਵੇ ਜਾਂ ਘੱਟ। ਭਾਵੇਂ ਤੁਸੀਂ autoscale ਵਰਤੋ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਇੰਸਟੈਂਸ ਅਤੇ peak capacity ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸੋਚਦੇ ਹੋ।
ਸਰਵਰਲੈਸ ਵਿੱਚ, ਬਿੱਲ ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗ ਦੀਆਂ ਯੂਨਿਟਾਂ ਨਾਲ ਟ੍ਰੈਕ ਹੁੰਦਾ ਹੈ—ਉਦਾਹਰਨ ਲਈ requests, compute time, read/write operations, storage ਜਾਂ data transfer. ਡੇਟਾਬੇਸ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ scale ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਦਾ ਨੁਕਸ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਐਪ ਦੇ ਅੰਦਰ ਹੋਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਲਈ ਸਿੱਧਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ: ਹਰ spike, background job ਅਤੇ ਅਣਉਪਯੋਗੀ ਕੁਐਰੀ ਖਰਚ 'ਤੇ ਦਰਜ ਹੋ ਸਕਦੀ ਹੈ।
ਆਰੰਭਕ ਦੌਰ ਵਿੱਚ, performance ਆਮ ਤੌਰ 'ਤੇ “ਪਰਯਾਪਤ” ਹੁੰਦੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਪਸ਼ਟ ਯੂਜ਼ਰ ਪੇਨ ਨੂੰ ਨਹੀਂ ਛੁਹ ਦੇਂਦੇ। ਲਾਗਤ, ਦੂਜੇ ਪਾਸੇ, ਤੁਹਾਡੇ runway ਨੂੰ ਤੁਰੰਤ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ।
ਸਰਵਰਲੈਸ ਇਕ ਵੱਡੀ ਫਾਇਦਾ ਦੇ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ idle capacity ਲਈ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰਦੇ, ਖਾਸ ਕਰਕੇ pre-product-market fit ਦੌਰਾਨ ਜਦੋਂ ਟਰੈਫਿਕ ਅਣਪਛਾਤਾ ਹੁੰਦਾ ਹੈ। ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ:
ਇਸ ਲਈ ਫਾਉਂਡਰਾਂ ਨੂੰ ਇਹ ਬਦਲਾਅ ਪਹਿਲਾਂ ਵਿੱਤੀ ਸਮੱਸਿਆ ਵਜੋਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਸਕੇਲਿੰਗ ਦੀ ਸਮੱਸਿਆ ਵਜੋਂ।
ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਓਪਰੇਸ਼ਨ ਨੂੰ ਸਧਾਰਨ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਅੱਗੇ ਦੇ ਬੰਧਨ ਹਟਾ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਨਵੇਂ ਟਰੇਡ-ਆਫ ਲਿਆਉਂਦੇ ਹਨ: ਕੀਮਤ ਦੀ ਜਟਿਲਤਾ, spikes ਦੌਰਾਨ ਆਕਸਮਿਕ ਖਰਚੇ, ਅਤੇ ਨਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਵੇਹਵਾਰ (ਜਿਵੇਂ cold starts ਜਾਂ throttling, ਪ੍ਰੋਵਾਈਡਰ ਦੇ ਅਨੁਸਾਰ)।
ਅਗਲੇ ਸੇਕਸ਼ਨਾਂ ਵਿੱਚ ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਸਰਵਰਲੈਸ ਪ੍ਰਾਇਸਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਲੁਕਿਆ ਹੋਇਆ ਖਰਚ ਕਿਥੇ ਮਿਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ-ਕਿਵੇਂ ਖਰਚ ਦਾ ਫੋਰਕਾਸਟ ਅਤੇ ਨਿਯੰਤਰਣ ਕਰਨਾ ਹੈ—ਚਾਹੇ ਤੁਹਾਡੇ ਕੋਲ ਪੂਰਾ ਡੇਟਾ ਹੋਵੇ ਜਾਂ ਨਾ।
ਸਰਵਰਲੈਸ ਤੋਂ ਪਹਿਲਾਂ, ਜ਼ਿਆਦਾਤਰ ਸਟਾਰਟਅਪ ਡੇਟਾਬੇਸ ਇਸੇ ਤਰੀਕੇ ਨਾਲ ਖਰੀਦਦੇ ਸਨ ਜਿਵੇਂ ਦਫ਼ਤਰ ਦੀ ਜਗ੍ਹਾ: ਤੁਸੀਂ ਇਕ ਸਾਈਜ਼ ਚੁਣਦੇ ਹੋ, ਪਲਾਨ 'ਤੇ ਸਾਇਨ-ਅਪ ਕਰਦੇ ਹੋ, ਅਤੇ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ ਚਾਹੇ ਤੁਸੀਂ ਉੱਸਦੀ ਪੂਰੀ ਵਰਤੋਂ ਕਰੋ ਜਾਂ ਨਾ ਕਰੋ।
ਕਲਾਸਿਕ ਕਲਾਉਡ ਡੇਟਾਬੇਸ ਬਿੱਲ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਵੀਜ਼ਨਡ ਇੰਸਟੈਂਸ ਨਾਲ ਡੋਮਿਨੇਟ ਹੁੰਦੀ ਹੈ—ਇਕ ਨਿਸ਼ਚਿਤ ਮਸ਼ੀਨ ਸਾਈਜ਼ (ਜਾਂ ਕਲਸਟਰ ਸਾਈਜ਼) ਜੋ ਤੁਸੀਂ 24/7 ਚਲਾਉਂਦੇ ਹੋ। ਚਾਹੇ ਰਾਤ ਨੂੰ ਟਰੈਫਿਕ ਘੱਟ ਹੋਵੇ, ਮੀਟਰ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਅਜੇ ਵੀ “ਚਾਲੂ” ਹੈ।
ਜ਼ਰੂਰਤ ਘਟਾਉਣ ਲਈ, ਟੀਮਾਂ ਅਕਸਰ reserved capacity ਜੋੜਦੀਆਂ ਹਨ (ਇਕ ਜਾਂ ਤਿੰਨ ਸਾਲ ਦੀ ਕਮੇਟਮੈਂਟ ਲਈ ਛੂਟ)। ਇਹ ਪ੍ਰਤੀ-ਘੰਟੇ ਦਰ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਬੇਸਲਾਈਨ ਖਰਚ 'ਤੇ ਲਾਕ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਪ੍ਰੋਡਕਟ pivot, ਵਿਕਾਸ ਰੋਕਣਾ, ਜਾਂ ਆਰਕੀਟੈਕਚਰ ਬਦਲਣ 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਬੈਠ ਸਕਦਾ।
ਫਿਰ ਆਉਂਦਾ ਹੈ overprovisioning: ਅਜਿਹਾ ਇੰਸਟੈਂਸ ਚੁਣਨਾ ਜੋ ਤੁਸੀਂ ਹੁਣੀਂ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ “ਕਿਸੇ ਇਮਰਜੰਸੀ ਲਈ।” ਇਹ ਇਕ ਬੁੱਧੀਮਾਨ ਚੋਣ ਹੈ ਜਦੋਂ ਤੁਸੀਂ outages ਤੋਂ ਡਰਦੇ ਹੋ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਆਰੰਭ 'ਚ ਹੀ ਉੱਚ ਫਿਕਸਡ ਲਾਗਤ ਵੱਲ ਧੱਕ ਦਿੰਦਾ ਹੈ।
ਸਟਾਰਟਅਪਾਂ ਕੋਲ ਮੁਲਾਇਮ, ਪੇਸ਼ਗੀ ਟਰੈਫਿਕ ਕਮ ਹੀ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਪੱਤਰਿਕਾ spike, ਪਲੇਟਫਾਰਮ ਲਾਂਚ, ਜਾਂ ਮਹੀਨੇ ਦੇ ਅਖੀਰ ਦੇ ਰਿਪੋਰਟਿੰਗ ਟਰੈਫਿਕ ਦਾ ਸਾਹਮਣਾ ਕਰ ਸਕਦੇ ਹੋ। ਪਰੰਪਰਿਕ ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਖ਼ਰਾਬ ਹਫ਼ਤੇ ਲਈ ਸਾਈਜ਼ ਕਰਦੇ ਹੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ resize ਕਰਨਾ ਜੋਖ਼ਿਮ ਭਰਿਆ ਹੋ ਸਕਦਾ ਹੈ।
ਨਤੀਜਾ ਇੱਕ ਮਿਸ਼ਮੈਚ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਪੀਕ capacity ਲਈ ਸਾਰਾ ਮਹੀਨਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ, ਜਦਕਿ ਤੁਸੀਂ ਵਾਸਤੇ ਬਹੁਤ ਘੱਟ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ। ਉਹ “idle spend” ਇਨਵੌਇਸ 'ਤੇ ਆਮ ਦਿੱਸਦਾ ਹੈ, ਪਰ ਇਹ ਚੁੱਪਚਾਪ ਇੱਕ ਵੱਡਾ ਰਿਕਰਿੰਗ ਇਨਫਰਾਸਟਰੱਕਚਰ ਖਰਚ ਬਣ ਸਕਦਾ ਹੈ।
ਪਰੰਪਰਿਕ ਡੇਟਾਬੇਸਾਂ ਨਾਲ ਸਮਾਂ-ਲਾਗਤ ਵੀ ਹੁੰਦੀ ਹੈ ਜੋ ਛੋਟੀ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ:
ਭਾਵੇਂ ਤੁਸੀਂ managed services ਵਰਤ ਰਹੇ ਹੋ, ਫਿਰ ਵੀ ਕਿਸੇ ਨੂੰ ਇਹ ਕਾਰਜ ਸੰਭਾਲਣੇ ਪੈਦੇ ਹਨ। ਇੱਕ ਸਟਾਰਟਅਪ ਲਈ ਇਹ ਲਗਭਗ ਮਹਿੰਗਾ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮਾਂ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਪ੍ਰੋਡਕਟ ਕੰਮ 'ਚ ਲੱਗ ਸਕਦਾ ਸੀ—ਇੱਕ ਗੁਪਤ ਲਾਗਤ ਜੋ ਇਕ ਇਕੱਲੇ ਲਾਈਨ ਆਈਟਮ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੀ, ਪਰ runway 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਂਦੀ ਹੈ।
“ਸਰਵਰਲੈਸ” ਡੇਟਾਬੇਸ ਅਕਸਰ managed ਡੇਟਾਬੇਸ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ elastic capacity ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਸਰਵਰ ਚਲਾਉਂਦੇ, patch ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ instance size ਨਹੀਂ ਚੁਣਦੇ। ਇਸ ਦੀ ਬਜਾਇ, ਪ੍ਰੋਵਾਈਡਰ capacity ਨੂੰ ਉੱਪਰ-ਥੱਲੇ ਕਰਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂ ਦੇ ਸੰਕੇਤਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਤੁਹਾਨੂੰ ਬਿੱਲ ਕਰਦਾ ਹੈ।
ਜਿਆਦਾਤਰ ਪ੍ਰੋਵਾਈਡਰ ਕੁਝ ਬਿੱਲਿੰਗ ਮੀਟਰ ਮਿਲਾ ਦੇਂਦੇ ਹਨ (ਨਾਵਾਂ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਵਿਚਾਰ ਇਕੋ ਹਨ):
ਕੁਝ ਵੇਂਡਰ backups, replication, data transfer, ਜਾਂ ਖਾਸ ਫੀਚਰਾਂ (encryption keys, point-in-time restore, analytics replicas) ਲਈ ਵੱਖਰਾ ਚਾਰਜ ਕਰਦੇ ਹਨ।
Autoscaling ਮੁੱਖ ਵਿਵਹਾਰਕ ਬਦਲਾਵ ਹੈ: ਜਦੋਂ ਟਰੈਫਿਕ spike ਕਰਦੀ ਹੈ, ਡੇਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ਬਣਾਈ ਰੱਖਣ ਲਈ capacity ਵਧਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਉਸ ਸਮੇਂ ਜ਼ਿਆਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਮੰਗ ਘੱਟ ਹੁੰਦੀ ਹੈ, capacity ਘਟਦੀ ਹੈ ਅਤੇ ਲਾਗਤ ਘਟ ਸਕਦੀ ਹੈ—ਕਈ ਵਾਰ spiky ਵਰਕਲੋਡ ਲਈ ਨਾਭੇਤਕੀ ਤੌਰ 'ਤੇ ਨਾਫ਼ਾ ਹੋ ਸਕਦਾ ਹੈ।
ਉਹ ਲਚਕੀਲਾਪਨ ਖਿੱਚਾਉਣ ਵਾਲਾ ਹੈ, ਪਰ ਇਸਦਾ ਨਤੀਜਾ ਇਹ ਵੀ ਹੈ ਕਿ ਤੁਹਾਡਾ ਖਰਚ ਫਿਕਸਡ “instance size” ਨਾਲ ਨਹੀਂ ਜੁੜਦਾ। ਤੁਹਾਡੀ ਲਾਗਤ ਪ੍ਰੋਡਕਟ ਦੀ ਵਰਤੋਂ ਦੇ ਨਮੂਨੇ ਦੀ ਪਿੱਛੇ-ਪਿੱਛੇ ਚੱਲਦੀ ਹੈ: ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਮੁਹਿੰਮ, ਇੱਕ ਬੈਚ ਜੌਬ, ਜਾਂ ਇੱਕ ਅਣਉਪਯੋਗੀ ਕੁਐਰੀ ਤੁਹਾਡੇ ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ।
ਸਰਵਰਲੈਸ ਨੂੰ ਸਰਲਤਾ ਅਤੇ ਉਪਯੋਗਤਾ-ਅਧਾਰਿਤ ਭੁਗਤਾਨ ਦੇ ਤੌਰ 'ਤੇ ਪੜ੍ਹੋ, ਨਾ ਕਿ ਸਦਾ ਲਈ ਛੂਟ। ਮਾਡਲ ਉਤਾਰ-ਚੜ੍ਹਾਅ ਵਾਲੇ ਵਰਕਲੋਡ ਅਤੇ ਤੇਜ਼ iteration ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ, ਪਰ ਜੇ ਵਰਕਲੋਡ ਲਗਾਤਾਰ ਉੱਚ ਹੈ ਜਾਂ ਕੁਐਰੀਆਂ ਅਣਉਪਯੋਗ ਹਨ, ਤਾਂ ਇਹ ਸਜ਼ਾ ਵੀ ਦੇ ਸਕਦਾ ਹੈ।
ਪਰੰਪਰਿਕ ਡੇਟਾਬੇਸਾਂ ਨਾਲ, ਸ਼ੁਰੂਆਤੀ ਖਰਚ ਆਕਸਰ “ਕਿਰਾਇਆ” ਵਾਂਗ ਲੱਗਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਸਰਵਰ ਸਾਈਜ਼ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ (ਨੂੰ replicas, backups ਅਤੇ ops ਸਮੇਂ ਦੇ ਨਾਲ), ਚਾਹੇ ਗਾਹਕ ਆਉਂਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਤੁਹਾਨੂੰ “cost of goods sold” ਸੋਚ ਵੱਲ ਧੱਕਦੇ ਹਨ—ਲਾਗਤ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦੀਆਂ ਸੱਚੀਆਂ ਕਾਰਵਾਈਆਂ ਨਾਲ ਟ੍ਰੈਕ ਹੁੰਦੀ ਹੈ।
ਇਸ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ, ਪ੍ਰੋਡਕਟ ਵਿਹਾਰ ਨੂੰ ਡੇਟਾਬੇਸ ਦੇ ਬਿੱਲਯੋਗ ਯੂਨਿਟਾਂ ਨਾਲ ਤਬਦੀਲ ਕਰੋ। ਕਈ ਟੀਮਾਂ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਯੋਗਸ਼ੀਲ ਮੈਪਿੰਗ ਇਹ ਵਰਗੀ ਦਿਖਦੀ ਹੈ:
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਇਕ ਮਾਪਯੋਗ ਯੂਨਿਟ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹੋ: “ਜੇ ਗਤੀਵਿਧੀ ਦੋਗੁਣੀ ਹੋ ਜਾਵੇ, ਤਾਂ ਬਿੱਲ 'ਚ ਕੀ ਦੋਗੁਣੀ ਹੋਵੇਗਾ?”
ਸਿਰਫ਼ ਕੁੱਲ ਕਲਾਉਡ ਖ਼ਰਚ ਟਰੈਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਕੁਝ “ਲਾਗਤ ਪ੍ਰਤੀ” ਮੈਟ੍ਰਿਕਸ ਲਿਆਓ ਜੋ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰੀ ਮਾਡਲ ਨਾਲ ਮਿਲਦੇ ਹਨ:
ਇਹ ਨੰਬਰ ਤੁਹਾਨੂੰ ਮਦਦ ਕਰਦੇ ਹਨ ਦੇਖਣ ਵਿੱਚ ਕਿ ਵਾਧਾ ਸਿਹਤਮੰਦ ਹੈ ਜਾਂ ਨਹੀਂ। ਇੱਕ ਪ੍ਰੋਡਕਟ “ਸਕੇਲ” ਹੋ ਰਿਹਾ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਮਾਰਜਿਨ ਖਾਮੋਸ਼ੀ ਨਾਲ ਬਿਗੜ ਰਹੇ ਹਨ ਜੇ ਡੇਟਾਬੇਸ ਵਰਤੋਂ ਰੇਵੇਨਿਊ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੀ ਹੈ।
ਇਸਤਮਾਲ-ਅਧਾਰਿਤ ਕੀਮਤ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਇਸ ਗੱਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ free tiers ਅਤੇ trials ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ। ਜੇ ਹਰ ਮੁਫ਼ਤ ਯੂਜ਼ਰ ਮਹੱਤਵਪੂਰਨ ਕੁਐਰੀ ਵਾਲੀ ਉਪਜ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ “ਮੁਫ਼ਤ” ਅਧਿਕਾਰਤ ਚੈਨਲ ਲਈ ਵੈਰੀਏਬਲ ਲਾਗਤ ਹੋ ਸਕਦੀ ਹੈ।
ਪ੍ਰਾਇਕਟਿਕ ਸਧਾਰਨ ਬਦਲਾਅ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਮਹਿੰਗੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ (ਜਿਵੇਂ ਭਾਰੀ search, exports, ਲੰਬੀ history), free plans ਵਿੱਚ retention ਘਟਾਉਣਾ, ਜਾਂ ਉਹ ਫੀਚਰ ਗੇਟ ਕਰਨਾ ਜੋ ਬਰਸਟੀ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ। ਉਦੇਸ਼ ਪ੍ਰੋਡਕਟ ਨੂੰ ਖ਼ਤਮ ਕਰਨਾ ਨਹੀਂ—ਉਦੇਸ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ ਮੁਫ਼ਤ ਅਨੁਭਵ ਇੱਕ ਟਿਕਾਊ cost per activated customer ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਸਟਾਰਟਅਪ ਆਮ ਤੌਰ 'ਤੇ “ਅੱਜ ਤੁਹਾਨੂੰ ਜੋ ਚਾਹੀਦਾ ਹੈ” ਅਤੇ “ਅਗਲੇ ਮਹੀਨੇ ਤੁਹਾਨੂੰ ਜੋ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ” ਦੇ ਦਰਮਿਆਨ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਅੰਤਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਲਾਗਤ ਦੀ ਗੱਲ-ਬਾਤ ਬਦਲ ਦਿੰਦੇ ਹਨ: ਉਹ capacity planning (ਅਦਬੁੱਧ ਅੰਦਾਜ਼ਾ) ਨੂੰ ਇੱਕ ਐਸੇ ਬਿੱਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਜੋ ਅਸਲ ਉਪਯੋਗ ਦੇ ਨਾਲ ਘੁੰਮਦਾ ਹੈ।
ਪਰਪੱਕਚ ਹੋਈ ਕੰਪਨੀਆਂ ਜਿਨ੍ਹਾਂ ਕੋਲ steady baselines ਅਤੇ ਵੱਖ-ਵੱਖ ops ਟੀਮ ਹਨ, ਉਨ੍ਹਾਂ ਨਾਲੋਂ ਜਲਦੀ ਟੀਮਾਂ runway, ਤੇਜ਼ ਪ੍ਰੋਡਕਟ iteration, ਅਤੇ ਅਣਪਛਾਤੀ ਮੰਗ ਨੂੰ ਸੰਭਾਲ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਛੋਟਾ ਬਦਲਾਅ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਖ਼ਰਚ ਨੂੰ “ਗੋਲ-ਗੋਲੰਦਾ” ਤੋਂ ਇਕ ਮੁੱਖ ਲਾਈਨ ਆਈਟਮ ਤੱਕ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ feedback loop ਤੁਰੰਤ ਹੁੰਦੀ ਹੈ।
ਸ਼ੁਰੂਆਤੀ ਵਾਧਾ ਸਮਤਲ ਅੰਦਾਜ਼ 'ਚ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਬਰਸਟਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ:
ਪਰੰਪਰਿਕ ਡੇਟਾਬੇਸ ਸੈਟਅਪ ਨਾਲ, ਤੁਸੀਂ ਅਕਸਰ ਮਹੀਨੇ ਭਰ ਲਈ ਪੀਕ capacity ਦਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ ਕੁਝ ਘੰਟਿਆਂ ਦੇ ਪੀਕ ਨੂੰ ਸੰਭਾਲ ਸਕੋ। ਸਰਵਰਲੈਸ ਨਾਲ, elasticity ਕੁਝ ਹੱਦ ਤੱਕ ਵਰਸਟੇਜ ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਮਹਿੰਗੀ idle headroom ਰੱਖਣ ਦੀ ਲੋੜ ਘੱਟ ਰੱਖਦੇ ਹੋ।
ਸਟਾਰਟਅਪ ਅਕਸਰ ਆਸਾਨੀ ਨਾਲ ਦਿਸ਼ਾ ਬਦਲਦੇ ਹਨ: ਨਵੇਂ ਫੀਚਰ, ਨਵੀਆਂ onboarding flows, ਨਵੇਂ pricing tiers, ਨਵੇਂ ਬਾਜ਼ਾਰ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ growth curve ਅਣਜਾਣ ਹੈ—ਅਤੇ ਤੁਹਾਡੀ ਡੇਟਾਬੇਸ ਵਰਕਲੋਡ ਅਚਾਨਕ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਦੇ ਬਦਲ ਸਕਦੀ ਹੈ (ਵਧੇਰੇ reads, ਭਾਰੀ analytics, ਵੱਡੇ documents, ਲੰਬੇ sessions)।
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਪ੍ਰੋਵੀਜ਼ਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਮਹਿੰਗੀਆਂ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਕਰ ਸਕਦੇ ਹੋ:
ਸਰਵਰਲੈਸ ਅੰਡਰ-sizing ਦੇ ਕਾਰਨ outages ਦਾ ਜੋਖ਼ਮ ਘਟਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮੰਗ ਨਾਲ scale ਕਰ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਕਿਸੇ ਮੈਨੂਅਲ resize ਦਾ ਇੰਤਜ਼ਾਰ ਕਰੇ।
ਫਾਉਂਡਰਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡੀ ਜਿੱਤ ਸਿਰਫ ਘੱਟ ਔਸਤ ਖ਼ਰਚ ਨਹੀਂ—ਇਹ ਪ੍ਰਤੀਬੱਧਤਾ ਘਟਾਉਣਾ ਵੀ ਹੈ। ਇਸਤੇਮਾਲ-ਅਧਾਰਿਤ ਕੀਮਤ ਤੁਹਾਨੂੰ traction ਨਾਲ ਲਾਗਤ ਨੂੰ ਮੇਲ ਕਰਨ ਦਿੰਦੀ ہے ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ ਨੂੰ ਸਹਾਇਕ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ experiments ਚਲਾ ਸਕਦੇ ਹੋ, ਇੱਕ ਅਚਾਨਕ spike ਨੂੰ ਸਹਿਣ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਫੈਸਲਾ ਕਰ ਸਕਦੇ ਹੋ ਕਿ optimize ਕਰਨਾ ਹੈ, capacity reserve ਕਰਨੀ ਹੈ, ਜਾਂ ਵਿਕਲਪ ਵੇਖਣੇ ਹਨ।
ਟਰੇਡ-ਆਫ ਇਹ ਹੈ ਕਿ ਲਾਗਤ ਵੱਧ ਚਲਣਯੋਗ ਹੋ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਸਟਾਰਟਅਪਾਂ ਨੂੰ ਜਲਦੀ ਕੁਝ ਹਲਕੇ guardrails (ਬਜਟ, ਅਲਰਟ, ਮੁਢਲੀ usage attribution) ਲਾਉਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ ਚੰਨਾ ਸਿਹਂਕਿਆਰ ਹੋਏ ਬਿਨਾਂ elasticity ਦਾ ਫਾਇਦਾ ਲੈ ਸਕਣ।
ਸਰਵਰਲੈਸ ਬਿਲਿੰਗ activity ਨਾਲ ਖਰਚ ਨੂੰ ਮੈਚ ਕਰਨ ਵਿੱਚ ਮਹਾਨ ਹੈ—ਜਦ ਤਕ “activity” ਵਿੱਚ ਉਹ ਸਾਰਾ ਕੰਮ ਸ਼ਾਮਲ ਨਾ ਹੋ ਜੇ ਜੋ ਤੁਹਾਨੂੰ ਪਤਾ ਹੀ ਨਹੀਂ ਸੀ ਕਿ ਤੁਸੀਂ ਕਰਵਾ ਰਹੇ ਹੋ। ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਹੈਰਾਨੀਆਂ ਛੋਟੀ, ਮੁੜ-ਮੁੜ ਹੋਣ ਵਾਲੀਆਂ ਬਿਹੇਵਿਯਰਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਸਮੇਂ ਨਾਲ ਗੁਣਾ ਖਾਂਦੀਆਂ ਹਨ।
Storage ਅਕਸਰ ਸਥਿਰ ਨਹੀਂ ਰਹਿੰਦੀ। event tables, audit logs, ਅਤੇ product analytics ਤੁਹਾਡੇ ਕੋਰ ਯੂਜ਼ਰ ਡੇਟਾ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਧ ਸਕਦੇ ਹਨ।
Backups ਅਤੇ point-in-time recovery ਵੀ ਅਲੱਗ ਚਾਰਜ ਹੋ ਸਕਦੇ ਹਨ (ਜਾਂ ਪ੍ਰਭਾਵਤ ਤੌਰ 'ਤੇ storage ਨੂੰ ਦੁਹਰਾਉਂਦੇ ਹਨ)। ਇੱਕ ਸਧਾਰਨ guardrail retention ਨੀਤੀਆਂ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ ਲਈ:
ਕਈ ਟੀਮ ਸੋਚਦੀਆਂ ਹਨ ਕਿ “ਡੇਟਾਬੇਸ ਲਾਗਤ” ਸਿਰਫ reads/writes ਅਤੇ storage ਹੈ। ਪਰ ਨੈੱਟਵਰਕ ਚੁਪਚਾਪ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ:
ਭਾਵੇਂ ਪ੍ਰੋਵਾਈਡਰ ਘੱਟ ਪ੍ਰਤੀ-ਰਿਕਵੈਸਟ ਕੀਮਤ ਦਿਖਾਵੇ, inter-region ਟਰੈਫਿਕ ਅਤੇ egress ਇੱਕ ਠੋਸ ਲਾਈਨ ਆਈਟਮ ਬਣ ਸਕਦੇ ਹਨ।
ਇਸਤਮਾਲ-ਅਧਾਰਿਤ ਕੀਮਤ ਖ਼ਰਾਬ ਕੁਐਰੀ ਪੈਟਰਨਾਂ ਨੂੰ ਵਧਾ ਦੇਂਦੀ ਹੈ। N+1 ਕੁਐਰੀਆਂ, missing indexes, ਅਤੇ ਅਣਬਾਊਂਡ ਸਕੈਨ ਇੱਕ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਨੂੰ ਦਰਜਨ (ਜਾਂ ਸੈਂਕੜੇ) ਬਿੱਲ ਕੀਤੇ ਜਾਂਦੇ ਓਪਰੈਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।
ਜਿੱਥੇ latency dataset ਸਾਈਜ਼ ਨਾਲ ਵੱਧਦੀ ਹੋਵੇ, ਉੱਥੇ ਆਮ ਤੌਰ 'ਤੇ ਲਾਗਤ ਗੈਰ-ਰੇਖੀ ਹੁੰਦੀ ਹੈ।
ਸਰਵਰਲੈਸ ਐਪ ਤੇਜ਼ੀ ਨਾਲ scale ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਗਿਣਤੀ ਵੀ ਤੁਰੰਤ spike ਕਰ ਸਕਦੀ ਹੈ। cold starts, autoscaling events, ਅਤੇ “thundering herd” retries ਐਸੇ ਬਰਸਟ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ:
ਜੇ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਜਾਂ ਪ੍ਰਤੀ-concurrency billing ਕਰਦਾ ਹੈ, ਤਾਂ deploys ਜਾਂ incidents ਦੌਰਾਨ ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ।
Backfills, re-indexing, recommendation jobs, ਅਤੇ dashboard refreshes “ਪ੍ਰੋਡਕਟ ਵਰਤੋਂ” ਜਿਹਾ محسوس ਨਹੀਂ ਹੁੰਦੇ, ਪਰ ਅਕਸਰ ਇਹ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਕੁਐਰੀਆਂ ਅਤੇ ਲੰਬੇ-ਲੰਬੇ reads ਚਲਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਨਿਯਮ: analytics ਅਤੇ batch processing ਨੂੰ ਵੱਖਰੇ ਵਰਕਲੋਡ ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਉਹਨਾਂ ਲਈ ਵੱਖਰਾ ਬਜਟ ਅਤੇ ਸ਼ਡਿਊਲ ਬਣਾਓ, ਤਾਂ ਜੋ ਉਹ ਚੁਪਚਾਪ ਉਪਭੋਗਤਾ ਸਰਵਿਸ ਲਈ ਰੱਖੇ ਬਜਟ ਨੂੰ ਖ਼ਤਮ ਨਾ ਕਰ ਦਿਓ।
ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਸਿਰਫ ਇਹ ਨਹੀਂ ਬਦਲਦੇ ਕਿ ਤੁਸੀਂ ਕਿੰਨਾ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ—ਉਹ ਇਹ ਵੀ ਬਦਲਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ। ਮੁੱਖ ਟਰੇਡਆਫ ਸਧਾਰਨ ਹੈ: ਤੁਸੀਂ scale-to-zero ਨਾਲ idle ਖ਼ਰਚ ਘਟਾ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ latency ਅਤੇ ਵਿਵਿਧਤਾ ਲਿਆ ਸਕਦੇ ਹੋ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਪਤਾ ਲੱਗ ਸਕਦੀ ਹੈ।
Scale-to-zero spiky ਵਰਕਲੋਡ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ: admin dashboards, internal tools, early MVP ਟਰੈਫਿਕ, ਜਾਂ ਹਫ਼ਤਾਵਾਰੀ batch jobs. ਤੁਸੀਂ ਉਹ capacity ਲਈ ਭੁਗਤਾਨ ਰੋਕ ਦਿੰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਵਰਤ ਨਹੀਂ ਰਹੇ।
ਨੁਕਸਾਨ cold starts ਹੈ। ਜੇ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ (ਜਾਂ ਉਸ ਦੀ compute layer) idle ਹੋ ਜਾਵੇ, ਤਾਂ ਅਗਲੀ ਰਿਕਵੈਸਟ 'ਤੇ ਇੱਕ “wake-up” penalty ਲੱਗ ਸਕਦੀ ਹੈ—ਕਈ ਵਾਰੀ ਕੁਝ ਸੌ ਮਿਲੀਸੈਕੰਡ, ਕਈ ਵਾਰੀ ਸੈਕੰਡ—ਸੇਵਾ ਅਤੇ ਕੁਐਰੀ ਪੈਟਰਨ ਦੇ ਅਨੁਸਾਰ। ਇਹ ਪਿਛੇ ਰਹਿਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਦਰਜਨਾਂ ਲਈ ਦਿਲਚਸਪ ਹੋ ਸਕਦਾ ਹੈ:
ਅਕਸਰ ਸਟਾਰਟਅਪ ਦਾ ਗਲਤ ਪਸੇ: ਮਹੀਨਾਵਾਰ ਬਿੱਲ ਘੱਟ ਕਰਨ ਲਈ optimize ਕਰਨਾ, ਪਰ ਨਾ ਜਾਣਦੇ ਹੋਏ performance “ਬਜਟ” ਖਰਚ ਕਰਨਾ ਜੋ conversion ਜਾਂ retention ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ cold-start ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਗਤ-ਬਚਤ ਤਿਆਗੇ:
ਧਿਆਨ: ਹਰ ਮਿਟੀਗੇਸ਼ਨ ਖਰਚ ਨੂੰ ਇਕ ਹੋਰ ਲਾਈਨ ਆਈਟਮ (cache, functions, scheduled jobs) 'ਤੇ ਸਥਾਨਕ ਕਰਦਾ ਹੈ। ਇਹ ਅਕਸਰ ਹਮੇਸ਼ਾ-ਚਾਲੂ capacity ਨਾਲੋਂ ਸਸਤਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਟਰੈਫਿਕ ਸਥਿਰ ਹੋਵੇ ਤਾਂ ਮੈਪ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਵਰਕਲੋਡ ਦੀ ਸਰੂਪਤਾ ਸਭ ਤੋਂ ਵਧੀਆ ਲਾਗਤ/ਪ੍ਰਦਰਸ਼ਨ ਸੰਤੁਲਨ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ:
ਫਾਉਂਡਰਾਂ ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਸਵਾਲ: ਕਿਹੜੀਆਂ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਨੂੰ ਲਗਾਤਾਰ ਤੇਜ਼ੀ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਨੂੰ ਦੇਰੀ ਸਹਿ ਸਕਦੀ ਹੈ? ਡੇਟਾਬੇਸ ਮੋਡ ਨੂੰ ਉਸ ਜਵਾਬ ਨਾਲ ਮੇਲ ਖਾਣ ਦੇ ਲਈ ਅਲਾਇਨ ਕਰੋ, ਸਿਰਫ਼ ਬਿੱਲ ਦੇ ਨਾਲ ਨਹੀਂ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਤੁਸੀਂ ਅਕਸਰ ਆਪਣੇ ਕੁਐਰੀ ਮਿਕਸ, ਪੀਕ ਟਰੈਫਿਕ, ਜਾਂ ਫੀਚਰਾਂ ਦੀ ਦਹਨ-ਗ੍ਰਹਣਸ਼ੀਲਤਾ ਨਹੀਂ ਜਾਣਦੇ। ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸਾਂ ਦੇ ਨਾਲ, ਉਹ ਅਣਿਸ਼ਚਿਤਤਾ ਅਹਿਮ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਬਿੱਲ ਵਰਤੋਂ ਨੂੰ ਨਜ਼ਦੀਕੀ ਤੋਂ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮੰਤਵ ਸੁੱਧ ਨਹੀਂ—ਇੱਕ “ਠੀਕ ਕਾਫੀ” ਰੇਂਜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ ਜੋ ਝਟਕੇ ਵਾਲੇ ਬਿੱਲ ਤੋਂ ਬਚਾਏ ਅਤੇ ਕੀਮਤ ਫੈਸਲਿਆਂ ਦਾ ਸਮਰਥਨ ਕਰੇ।
ਇੱਕ ਪ੍ਰਤੀਨਿਧੀ ਹਫਤੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ “ਨਿਆਦਾ” ਵਰਤੋਂ ਦਰਸਾਉਂਦਾ ਹੋਵੇ (ਅਜੇ ਚਾਹੇ staging ਜਾਂ ਛੋਟੇ beta ਤੋਂ)। ਪ੍ਰੋਵਾਈਡਰ ਜੋ ਮੀਟਰ ਕਰਦਾ ਹੈ ਉਹਨਾਂ ਦੀਆਂ ਕੁਝ usage ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮਾਪੋ (ਆਮ: reads/writes, compute time, storage, egress)।
ਫਿਰ ਤਿੰਨ ਕਦਮਾਂ ਵਿੱਚ ਫੋਰਕਾਸਟ ਕਰੋ:
ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਬੈਂਡ ਦਿੰਦਾ ਹੈ: ਉਮੀਦ ਕੀਤੀ ਲਾਗਤ (baseline + growth) ਅਤੇ “stress spend” (peak multiplier)। cash flow ਦਾ ਯੋਜਨਾ stress ਨੰਬਰ ਦੇ अनुसार ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਔਸਤ।
1k, 10k, ਅਤੇ 100k users ਵਰਗੀਆਂ milestones ਲਈ representative endpoints 'ਤੇ ਹਲਕੇ load tests ਚਲਾਓ ਤਾਂ ਕਿ ਖਰਚ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗ ਸਕੇ। ਉਦਦੇਸ਼ ਬਿਲਕੁਲ ਸਹੀ ਨਹੀਂ—ਉਦੇਸ਼ ਇਹ ਪਤਾ ਲਾਉਣਾ ਹੈ ਕਿ ਕਦੋਂ ਖਰਚੀ ਕ੍ਰਿਵ ਬੈਂਡ ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ: ਜਦ ਇੱਕ chat ਫੀਚਰ writes ਦੁੱਗਣੇ ਕਰ ਦੇਂਦਾ, ਜਾਂ analytics ਕੁਐਰੀ ਭਾਰੀ scans ਟ੍ਰਿਗਰ ਕਰਦੀ)।
ਨਤੀਜੇ ਨਾਲ assumptions ਲਿਖੋ: average requests per user, read/write ਅਨੁਪਾਤ, ਅਤੇ peak concurrency।
ਮਹੀਨਾਵਾਰ ਬਜਟ ਰੱਖੋ, ਫਿਰ alerts thresholds (ਉਦਾਹਰਨ 50%, 80%, 100%) ਅਤੇ ਦੈਨੀਕ ਖਰਚ 'ਤੇ “abnormal spike” alert। alerts ਨੂੰ ਇੱਕ playbook ਨਾਲ ਜੋੜੋ: ਗੈਰ-ਜ਼ਰੂਰੀ jobs ਨੂੰ ਬੰਦ ਕਰੋ, logging/analytics ਕੁਐਰੀਆਂ ਘਟਾਓ, ਜਾਂ ਮਹਿੰਗੇ endpoints 'ਤੇ rate-limit ਲਗਾਓ।
ਅੰਤੀਮ ਤੌਰ 'ਤੇ, ਪ੍ਰੋਵਾਈਡਰਾਂ ਜਾਂ ਟੀਅਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਿਆਂ, ਉਹੀ usage assumptions ਵਰਤੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ /pricing 'ਤੇ sanity-check ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਅੰਕ-ਬਜੁਦਾ ਮਿਲਾ-ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ।
ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਇਨਾਮ ਦਿੰਦੇ ਹਨ, ਪਰ ਉਹ ਚੱਕਰਬੱਧਾ ਨੂੰ ਸਜ਼ਾ ਵੀ ਦੇ ਸਕਦੇ ਹਨ। ਉਦੇਸ਼ ਇਹ ਨਹੀਂ ਕਿ “ਸਬਰਦਾਰੀ ਹਰ ਚੀਜ਼ ਦਾ ਅਪਟਿਮਾਈਜ਼ ਕਰੋ”—ਉਦੇਸ਼ runaway spend ਨੂੰ ਰੋਕਣਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਆਪਣੇ ਟਰੈਫਿਕ ਪੈਟਰਨ ਸਿੱਖ ਰਹੇ ਹੋ।
dev, staging, ਅਤੇ prod ਨੂੰ ਵੱਖ-ਵੱਖ ਉਤਪਾਦ ਵਜੋਂ ਲਓ ਅਤੇ ਵੱਖ-ਵੱਖ ਸੀਮਾਵਾਂ ਰੱਖੋ। ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ experimental workloads ਨੂੰ customer traffic ਦੇ billing pool ਨਾਲ ਸਾਂਝਾ ਹੋਣ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਹਰ environment ਲਈ ਮਹੀਨਾਵਾਰ ਬਜਟ ਰੱਖੋ ਅਤੇ alerts thresholds ਲਾਉ। Dev ਨੂੰ ਜਾਣਬੂਝ ਕੇ ਤੰਗ ਰੱਖੋ: ਜੇ migration test ਅਸਲ ਪੈਸਾ ਬਰਬਾਦ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ ਜ਼ੋਰ ਨਾਲ fail ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੈਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ tooling ਵਰਤੋਂ ਜੋ “safe change + fast rollback” ਰੁਟੀਨ ਬਣਾ ਦੇਵੇ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ rollback ਨੂੰ ਜ਼ੋਰ ਦੇਂਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ experiments ship ਕਰ ਸਕੋ ਅਤੇ ਲਾਗਤ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ regressions 'ਤੇ ਕਾਬੂ ਰੱਖ ਸਕੋ।
ਜੇ ਤੁਸੀਂ ਲਾਗਤ ਨੂੰ atributable ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਉਸਨੂੰ manage ਨਹੀਂ ਕਰ ਸਕਦੇ। ਪਹਿਲੇ ਦਿਨ ਤੋਂ tags/labels standardize ਕਰੋ ਤਾਂ ਕਿ ਹਰ ਡੇਟਾਬੇਸ, ਪ੍ਰੋਜੈਕਟ, ਜਾਂ usage meter ਇੱਕ ਸਰਵਿਸ, ਟੀਮ, ਅਤੇ (ਸਭ ਤੋਂ ਵਧੀਆ) ਇੱਕ ਫੀਚਰ ਨਾਲ ਜੋੜੀ ਜਾ ਸਕੇ।
ਇੱਕ ਸਧਾਰਾ ਯੋਜਨਾ ਲਗਾਓ ਅਤੇ reviews ਵਿੱਚ enforcement ਕਰੋ:
ਇਸ ਨਾਲ “ਡੇਟਾਬੇਸ ਬਿੱਲ ਵਧ ਗਿਆ” ਸਥਾਨਕ ਤੌਰ 'ਤੇ “release X ਤੋਂ ਬਾਅਦ search reads ਦੁੱਗਣੇ ਹੋ ਗਏ” ਵਿੱਚ ਤਬਦੀਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ spike ਖਰਚ ਇਕ ਛੋਟੇ ਨੰਬਰ ਖਰਾਬ ਪੈਟਰਨਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ: tight polling loops, missing pagination, unbounded queries, ਅਤੇ accidental fan-out.
ਹਲਕੀ guardrails ਸ਼ਾਮਲ ਕਰੋ:
ਜਦ downside of downtime open-ended bill ਤੋਂ ਘੱਟ ਹੋ, ਤਾਂ hard limits ਵਰਤੋਂ:
ਜੇ ਤੁਸੀਂ ਹੁਣ ਇਹ ਨਿਯੰਤਰਣ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਬਾਅਦ ਵਿੱਚ FinOps ਅਤੇ ਗੰਭੀਰ ਕਲਾਉਡ ਖ਼ਰਚ ਪ੍ਰਬੰਧਨ 'ਤੇ ਜਦੋਂ ਤੁਸੀਂ ਅਸੀਂ ਸ਼ੁਰੂ ਕਰੋਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਯਾਦ ਆਵੇਗਾ।
ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਉਹਨਾਂ ਵੇਲੇ ਚਮਕਦੇ ਹਨ ਜਦੋਂ ਵਰਕਲੋਡ spiky ਅਤੇ ਅਣਿਸ਼ਚਿਤ ਹੋ। ਪਰ ਜਦੋਂ ਤੁਹਾਡਾ ਵਰਕਲੋਡ ਸਥਿਰ ਅਤੇ ਭਾਰੀ ਹੋ ਜਾਵੇ, ਤਾਂ "pay-for-what-you-use" ਦੀ ਗਣਿਤ ਉਲਟ ਸਕਦੀ ਹੈ—ਕਈ ਵਾਰ ਕਾਫੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ।
ਜੇ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਜ਼ਿਆਦਾਤਰ ਘੰਟਿਆਂ ਦੌਰਾਨ ਨਿਰੰਤਰ ਵਿਅਸਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ usage-based ਕੀਮਤ ਇੱਕ provisioned instance (ਜਾਂ reserved capacity) ਨਾਲੋਂ ਵੱਧ ਪੈ ਸਕਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੇ ਵਰਤੋਂ ਜਾਂ ਨਾ ਕਰੋ ਉਸਦਾ ਭੁਗਤਾਨ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਆਮ ਪੈਟਰਨ ਹੈ ਇੱਕ ਪੱਕਾ B2B ਪ੍ਰੋਡਕਟ ਜਿਸਦੀ traffic ਬਿਜ਼ਨਸ ਘੰਟਿਆਂ ਦੌਰਾਨ ਲਗਾਤਾਰ ਹੁੰਦੀ ਹੈ, ਨਾਲੇ ਰਾਤ ਵਿੱਚ background jobs ਚਲਦੇ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, fixed-size cluster ਅਤੇ reserved pricing ਇੱਕ ਘਟੀਆ ਪ੍ਰਭਾਵੀ ਲਾਗਤ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਦੇ ਸਕਦੇ ਹਨ—ਖਾਸ ਤੌਰ 'ਤੇ ਜੇ ਤੁਸੀਂ utilization ਉੱਚ ਰੱਖ ਸਕਦੇ ਹੋ।
ਸਰਵਰਲੈਸ ਹਮੇਸ਼ਾ-friendly ਨਹੀਂ ਹੁੰਦਾ:
ਇਨ੍ਹਾਂ ਵਰਕਲੋਡਾਂ ਨਾਲ ਤੁਹਾਨੂੰ ਦੋਹਾਂ ਮਾਰੇ ਜਾ ਸਕਦੇ ਹਨ: ਵੱਧ ਮੀਟਰਡ ਵਰਤੋਂ ਅਤੇ ਕਦੇ-ਕਦੇ slowdown ਜਦ scaling limits ਜਾਂ concurrency caps ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ।
Pricing pages ਮਿਲਦੇ-ਜੁਲਦੇ ਲੱਗ ਸਕਦੇ ਹਨ ਪਰ meters ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ। ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦਿਆਂ ਪੁਸ਼ਟੀ ਕਰੋ:
ਜਦੋਂ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਰੁਝਾਨ ਨੋਟ ਕਰੋ ਤਾਂ ਦੁਬਾਰਾ ਮਲਾਹਿਜ਼ਾ ਕਰੋ:
ਉਸ ਵੇਲੇ, ਇੱਕ side-by-side ਲਾਗਤ ਮਾਡਲ ਚਲਾਓ: ਮੌਜੂਦਾ ਸਰਵਰਲੈਸ ਬਿੱਲ vs ਇੱਕ right-sized provisioned ਸੈਟਅਪ (ਸੰਭਵਤ: reserved pricing) ਅਤੇ ਉਨ੍ਹਾਂ operational overhead ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਵੈ-ਚਲਾਉਂਦੇ ਹੋਏ ਲੈ ਰਹੇ ਹੋਵੋਗੇ। ਜੇ ਮਾਡਲ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ /blog/cost-forecasting-basics ਨੂੰ ਦੇਖੋ।
ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਉਨ੍ਹਾਂ ਲਈ ਵਧੀਆ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਤੁਹਾਡੀ ਟਰੈਫਿਕ ਅਸਮਾਨ ਅਤੇ ਤੁਸੀਂ ਤੇਜ਼ iteration ਕੀਮਤ ਕਰਦੇ ਹੋ। ਪਰ ਜਦੋਂ “meters” ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦੇ ਵਿਹਾਰ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਤਾਂ ਉਹ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਸਲਾ ਕਰਨ ਲਈ ਵਰਤੋਂ, ਅਤੇ ਇਸ ਗੱਲ ਤੋਂ ਬਚਣ ਲਈ ਕਿ ਤੁਸੀਂ ਅਜਿਹੇ ਦਸਤਖਤ ਕਰ ਲਵੋ ਜਿੱਥੇ ਤੁਸੀਂ ਆਪਣੀ ਟੀਮ (ਜਾਂ ਨਿਵੇਸ਼ਕਾਂ) ਨੂੰ ਸਮਝਾ ਨਾ ਸਕੋ।
ਕੀਮਤ ਮਾਡਲ ਨੂੰ ਆਪਣੀ growth uncertainty ਨਾਲ ਮਿਲਾਓ: ਜੇ ਤੁਹਾਡੀ ਟਰੈਫਿਕ, ਕੁਐਰੀਜ਼, ਜਾਂ ਡੇਟਾ ਅਕਾਰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ, ਤਾਂ ਉਹ ਮਾਡਲ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਡਰਾਇਵਰਾਂ ਨਾਲ ਫੋਰਕਾਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਇੱਕ ਅਸਲ ਫੀਚਰ ਲਈ ਚਲਾਓ, ਇੱਕ ਮਹੀਨੇ ਲਈ ਹਫਤਾਵਾਰ ਲਾਗਤ ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਨੋਟ ਲਵੋ ਕਿ ਕਿਸ ਮੀਟਰ ਨੇ ਹਰ ਛਾਲ ਨੂੰ ਚਲਾਇਆ। ਜੇ ਤੁਸੀਂ ਇਕ ਪੈਰਾਗ੍ਰਾਫ ਵਿੱਚ ਬਿੱਲ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਸ ਨੂੰ ਅਜੇ scale ਨਾ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਉਹ ਪਾਇਲਟ ਸ਼ੁਰੂ ਤੋਂ ਬਣਾਉਣ ਜਾ ਰਹੇ ਹੋ, ਤਾਂ ਸੋਚੋ ਕਿ ਤੁਸੀਂ instrumentation ਅਤੇ guardrails ਤੇ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਟੀਮਾਂ ਨੂੰ React + Go + PostgreSQL ਐਪ ਦਤਰਸ੍ਹੀ ਤੌਰ 'ਤੇ spin up ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰਨ ਦੀ ਸਹੂਲਤ ਦਿੰਦੀ ਹੈ, ਅਤੇ planning mode ਅਤੇ snapshots ਨਾਲ تجرباتی ਕੰਮ ਸੁਰੱਖਿਅਤ ਰੱਖਣ 'ਚ ਮਦਦ ਕਰਦੀ ਹੈ—ਇਹ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਜੇ ਸਿੱਖ ਰਹੇ ਹੋ ਕਿ ਕਿਹੜੀਆਂ ਕੁਐਰੀਆਂ ਅਤੇ ਵਰਕਫਲੋ ਤੁਹਾਡੀ ਯੂਨਿਟ ਇਕਾਨੋਮਿਕਸ ਨੂੰ ਚਲਾਉਣਗੀਆਂ।
ਇੱਕ ਪਾਰੰਪਰਿਕ ਡੇਟਾਬੇਸ ਤੁਹਾਨੂੰ capacity (ਇੰਸਟੈਂਸ ਸਾਈਜ਼, ਰਿਪਲਿਕਾ, reserved commitments) ਅੱਗੇ ਤਕਾਰਣਦੀ ਹੈ—ਚਾਹੇ ਤੁਸੀਂ ਉਸਦਾ ਇਸਤੇਮਾਲ ਕਰੋ ਜਾਂ ਨਾ ਕਰੋ। ਇਕ ਸਰਵਰਲੈਸ ਡੇਟਾਬੇਸ ਆਮ ਤੌਰ 'ਤੇ ਖਪਤ ਦੇ ਆਧਾਰ 'ਤੇ ਬਿੱਲ ਕਰਦਾ ਹੈ (compute time, requests, reads/writes, storage, ਅਤੇ ਕਈ ਵਾਰੀ data transfer), ਇਸਲਈ ਤੁਹਾਡੇ ਖਰਚੇ ਹਰ ਰੋਜ਼ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦੀ ਕਿਰਿਆ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੇ ਹਨ।
ਕਿਉਂਕਿ ਖਰਚ ਵੈਰੀਏਬਲ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ headcount ਜਾਂ ਹੋਰ ਖਰਚਾਂ ਨਾਲੋਂ ਤੇਜ਼ ਬਦਲ ਸਕਦਾ ਹੈ। ਛੋਟੀ ਟ੍ਰੈਫਿਕ ਵਾਧਾ, ਨਵਾਂ background job, ਜਾਂ ਇਕ ਅਣਛੁਟੀ ਕੁਐਰੀ ਤੁਹਾਡੇ ਇਨਵੌਇਸ ਨੂੰ ਗੰਭੀਰ ਤੌਰ 'ਤੇ ਬਦਲ ਸਕਦੀ ਹੈ—ਇਸ ਲਈ ਲਾਗਤ ਪ੍ਰਬੰਧਨ runway ਦਾ ਮਸਲਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਆਮ meters ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਹਮੇਸ਼ਾ ਪ੍ਰੋਵਾਈਡਰ ਦੀ /pricing ਜਾਣਕਾਰੀ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਸ਼ਾਮਲ ਹੈ ਅਤੇ ਕੀ ਅਲੱਗਮੀਟਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਉਸਤੇ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਉਪਭੋਗਤਾ ਕਿਰਿਆਵਾਂ ਨੂੰ ਬਿੱਲਯੋਗ ਯੂਨਿਟਾਂ ਨਾਲ ਮੈਪ ਕਰੋ। ਉਦਾਹਰਨ ਵਜੋਂ:
ਫਿਰ ਕੁਝ ਆਸਾਨ ਅਨੁਪਾਤ ਟਰੈਕ ਕਰੋ ਜਿਵੇਂ cost per MAU, cost per 1,000 requests, ਜਾਂ cost per order ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਵਾਧਾ ਸਿਹਤਮੰਦ ਹੈ ਜਾਂ ਨਹੀਂ।
ਅਕਸਰ ਚੇਤੇ ਰਹਿਣ ਵਾਲੇ ਮੁੱਖ ਕਾਰਨ ਹਨ:
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਛੋਟੇ ਤੋਂ ਲੱਗਦੇ ਹਨ ਪਰ ਮਹੀਨਾਵਾਰ ਖਰਚ ਵੱਡਾ ਕਰ ਸਕਦੇ ਹਨ।
Scale-to-zero idle ਖਰਚ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ cold starts ਲਿਆ ਸਕਦਾ ਹੈ: idle ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਰਿਕਵੈਸਟ ਨੂੰ ਵਾਧੂ latency ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ (ਕਈ ਵਾਰੀ ਸੈਂਕੜੇ ਮਿਲੀਸੈਕੰਡ ਜਾਂ ਕੋੱਝ ਸੈਕੰਡ)। ਇਹ ਅਕਸਰ internal tools ਜਾਂ batch jobs ਲਈ ਠੀਕ ਹੁੰਦਾ ਹੈ, ਪਰ login, checkout, search ਜਿਹੜੀਆਂ flows ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਕਠੋਰ p95/p99 latency ਟੀਚੇ ਹੁੰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।
ਟਾਰਗੇਟਡ ਰਾਹਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ:
ਨਤੀਜਾ ਮਾਪੋ—ਕਿਉਂਕਿ ਇਨ ਉਪਾਇਆں ਨਾਲ ਖਰਚ ਹੋਰ ਸਰਵਿਸਾਂ (cache, functions, schedulers) 'ਤੇ ਵੱਧ ਸਕਦਾ ਹੈ।
ਇਕ ਸਰਲ ਪਦਤੀ ਹੈ: baseline + growth + peak multiplier:
ਛੋਟੇ ਹਲਕੀਆਂ guardrails ਲਗਾਓ:
ਮਕਸਦ runaway ਬਿੱਲ ਤੋਂ ਬਚਣਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀ ਵਰਕਲੋਡ ਪੈਟਰਨ ਸਿੱਖ ਰਹੇ ਹੋ।
ਸਰਵਰਲੈਸ ਘੱਟ/ਅਣਜਾਣ ਟਰੈਫਿਕ ਲਈ ਬਹੁਤ ਚੰਗਾ ਹੈ। ਪਰ ਜਦੋਂ ਵਰਕਲੋਡ ਸਥਿਰ ਅਤੇ ਭਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ “pay-for-what-you-use” ਦਾ ਹਿਸਾਬ ਉਲਟ ਸਕਦਾ ਹੈ।
ਅਕਸਰ ਸਥਿਰ ਉੱਚ ਲੋਡ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ provisioned ਰਹਿਣਾ ਸਸਤਾ ਪੈਂਦਾ ਹੈ—ਇਹ ਉਹ ਸਥਿਤੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਨਿਰੀਖਿਤ cluster + reserved pricing ਨਾਲ ਉੱਚ utilization ਰੱਖ ਸਕਦੇ ਹੋ।
ਕੁਝ ਵਰਕਲੋਡ ਜੋ ਸਰਵਰਲੈਸ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾ ਸਕਦੇ ਹਨ:
ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਆਪਣੀ ਮੌਜੂਦਾ ਬਿੱਲ ਨੂੰ ਇੱਕ right-sized provisioned ਵਿਵਸਥਾ ਨਾਲ side-by-side ਮਾਡਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ operational overhead ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਵੇ।
ਕੈਸ਼-ਫਲੋਅ ਦਾ ਯੋਜਨਾ ਬਣਾਉਣ ਵੇਲੇ “stress spend” (ਪਿਕ ਗੁਣਾ) ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ, ਨਾ ਕਿ ਸਿਰਫ ਔਸਤ।
