Сервер із фіксованою ціною чи оплата за використання?

Якщо ваш застосунок працює постійно, а трафік досить передбачуваний, сервер із фіксованою ціною дивуватиме менше. Якщо трафік дуже малий або раптово й сильно стрибає, платформи з оплатою за використання можуть мати більше сенсу. Це не стільки технічний вибір, скільки питання, який рядок у вашому рахунку постійно зростає.

У порівнянні нижче немає цін, бо ставки за одиницю різняться між платформами й часто змінюються. Натомість воно дає спосіб порахувати за власними цифрами.

За що бере гроші кожна модель?

Кожен рядок — компроміс, і жодна модель не виграє в усіх.

Коли оплата за використання доречніша?

• Проєкт новий і майже не має трафіку. Якщо його покриває безплатний тариф, платити за сервер немає сенсу.
• Ви публікуєте короткочасну демонстрацію чи сторінку кампанії. Налаштовувати сервер заради того, що закриється за кілька тижнів, не варто.
• Ваш трафік раптово й різко стрибає. Одному серверу в цей момент може не вистачити потужності, а платформа це поглине за вас.
• Ваші відвідувачі розкидані по всьому світу, і ви хочете відповідати кожному з близького місця.
• Ви не хочете мати справу з оновленнями, резервними копіями чи моніторингом і готові платити за це.

Коли сервер із фіксованою ціною доречніший?

• Ваш застосунок постійно виконує фонову роботу: обробники черг, заплановані завдання, з’єднання WebSocket.
• Ви хочете мати базу даних, кеш і застосунок поруч. Коли вони на одній машині, кожен із них не виставляє окремий рахунок.
• Ваші функції ШІ дають довгі відповіді. Там, де оплата йде за тривалість функції, кожна повільна відповідь додає до вартості.
• Ваш бюджет має бути відомий наперед. Щомісячна плата визначена заздалегідь, тож кінець місяця не принесе сюрпризів.
• Ви віддаєте багато зображень чи файлів, і трафік став вашою найбільшою статтею витрат.

Як порахувати за власними цифрами?

Замість здогадок візьміть цифри за останні три місяці. Якщо ви ще не запустилися, візьміть очікуваний трафік і зазначте, що це оцінка.

1. Запишіть щомісячний трафік у ГБ, кількість запитів і сумарну тривалість функцій.
2. Запишіть свої хвилини збірки. Кожен push — це збірка, тому в команди, яка публікує часто, цей рядок швидко зростає.
3. Додайте додаткове, як-от місця в команді, базу даних і кеш.
4. Помножте кожну позицію на ставку за одиницю з актуальної сторінки цін платформи. Це дасть рахунок за звичайний місяць.
5. Повторіть розрахунок так, ніби трафік удесятеро більший. Це ваш рахунок за поганий місяць.
6. Порівняйте обидва результати з місячною платою за сервер, який комфортно потягне ваш застосунок.

Якщо цифра за поганий місяць вас не турбує і вам нецікаво обслуговувати сервер, лишайтеся там, де є. Якщо звичайний місяць уже коштує більше, ніж сервер, або поганий місяць зашкодив би бізнесу, сервер варто серйозно розглянути.

Чого коштує фіксована ціна?

Коли сервер ваш, частина роботи теж стає вашою. Обирайте це, знаючи, що саме:

• Оновлення операційної системи та застосунків лягає на вас. Панелі розгортання беруть на себе частину цієї роботи, але не всю.
• Нічого не зростає автоматично, коли потужності не вистачає. Сервер сповільнюється, а збільшуєте його ви.
• Один сервер — одна точка відмови. Поки він перезапускається, ваш застосунок ненадовго перестає відповідати.
• Ви відповідаєте з одного місця. Далекі відвідувачі бачать більшу затримку, і мережа доставки вмісту перед сервером може допомогти, якщо це для вас важливо.

Чи можна поєднати обидва?

Так, вибір не мусить бути «все або нічого». Поширена схема тримає інтерфейс на платформі з оплатою за використання, а бекенд, базу даних і обробники черг запускає на сервері з фіксованою ціною. Більшість трафіку йде на інтерфейс, а постійна робота, що роздуває рахунок, лишається на сервері за сталою ціною. Ціна такого рішення — стежити за двома місцями й захищати з’єднання між ними. Якщо у вас один застосунок, така схема зазвичай складніша, ніж того варта, тож починайте з одного місця.

Золота середина: git push на власному сервері

Часто найбільша різниця між двома моделями — зручність, і ця різниця зменшується. Панелі розгортання з відкритим кодом, як-от Coolify, дають той самий робочий процес на власному сервері: ви підключаєте репозиторій GitHub, кожен push збирається й публікується, змінними середовища та доменами ви керуєте у вебінтерфейсі, а сертифікат панель запитує сама. Root-доступ у вас лишається, і якщо хочете, усім можна керувати з панелі.

У Seturack варіанти Coolify і Next.js приходять із уже встановленою цією панеллю. Розмір ви обираєте повзунком, а збільшуєте пізніше з панелі. Під час збільшення IP-адреса й дані залишаються тими самими, а платите ви лише різницю за дні, що залишилися. Щоденна резервна копія входить у ціну, а трафік необмежений. Сервери розташовані в Стамбулі. Порівняти розміри можна на сторінці цін.

Готове до роботи в Seturack: Next.js, Coolify.