Маєте програмний продукт? Додайте його безкоштовно. Людина прочитає й опублікує протягом доби.Маєте продукт? Додайте його безкоштовно.

Додайте свій продукт
Додати продукт

Хостинг і хмара

Місце, де застосунок працює насправді.

Хостинг і хмара

У цій категорії поки немає продуктів

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

Додайте свій продукт

Що охоплює ця полиця

Місця, де працює застосунок: керовані платформи, що розгортають код із репозиторію, контейнерні сервіси, віртуальні машини та повноцінні хмарні провайдери з кількома сотнями сервісів.

Правильна відповідь залежить не стільки від масштабу, скільки від того, скільки операційної роботи ви готові взяти на себе. Кожен рівень контролю, який ви беретеся утримувати, додає обов’язок, що настає у невдалу годину.

Бази даних мають власну полицю в категорії бази даних. Нагляд за тим, що відбувається, коли все вже працює, належить до моніторингу.

Чотири рівні контролю

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

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

Віртуальні машини дають вам операційну систему з усім, що до неї додається, зокрема оновленнями, безпекою та резервними копіями.

Повноцінні хмарні провайдери пропонують усі три варіанти разом із каталогом керованих сервісів ціною складності та рахунку, що потребує уваги.

Питання, що вирішують продуктивність

  • Вибір регіону: поблизу користувачів і бази даних.
  • Холодні старти для всього, що масштабується до нуля між запитами.
  • Постійні з’єднання, з якими деякі безсерверні моделі справляються погано.
  • Час збирання та розгортання, адже десятихвилинне розгортання змінює частоту релізів.
  • Роздача статики, закешованої поблизу відвідувачів, а не щоразу з origin.

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

Надійність і те, що буде в поганий день

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

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

Потім запитайте про відновлення, яке контролюєте ви. Збій провайдера можна пережити, якщо копія ваших даних лежить деінде, а розгортання відтворюване. Жодна з цих умов не виконується сама собою.

Вартість і статті, що ростуть непомітно

Обчислювальні ресурси: ось цифра зі сторінки цін. Рахунок зазвичай складається з п’яти складників.

Вихідний трафік оплачується за гігабайт даних, що залишають провайдера, і найшвидше накопичується на відео, завантаженнях і трафіку між регіонами. Сховище росте й рідко зменшується. Керовані сервіси мають власні лічильники. Хвилини збирання рахуються на платформах, що перезбирають при кожному пуші. Плани підтримки майже всюди платні вище за базовий рівень.

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

Переносність і як її зберегти

Прив’язка до провайдера в цій категорії рідко буває драматичною. Вона накопичується по одному зручному сервісу.

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

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

Підбираємо платформу до застосунку

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

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

Усе з незвичайними вимогами, чи то особливе обладнання, стабільно високий трафік або сувора локалізація даних, схиляє до «голої» хмари чи виділених машин.

Статичні сайти належать до дешевого краю й часто взагалі нічого не коштують у правильному розміщенні.

Вирішуйте за формою навантаження, а не за розміром компанії. Малі команди запускають вимогливі застосунки, а великі нерідко запускають прості.

Запитання, які ставлять люди

Чим відрізняється платформа від «голої» хмари?

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

Де розміщувати, щоб було найшвидше?

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

Як працює тарифікація вихідного трафіку?

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

Чи потрібна мережа доставки контенту?

Для будь-якого сайту з глобальною аудиторією так, і більшість платформ її вже включають. Вона кешує статичні файли поблизу відвідувачів і нічим не допомагає з динамічними відповідями, які все одно надходять з origin.

Як уникнути прив'язки до провайдера?

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