Когда разработка мобильного приложения подходит к концу, у владельца проекта нередко появляется вполне логичный вопрос: какой хостинг теперь нужно купить? С сайтом все понятно — его файлы загружаются на сервер, домен направляется на хостинг, после чего пользователи открывают страницы через браузер. С Android- и iOS-приложениями схема устроена иначе.
Само мобильное приложение обычно не «лежит на хостинге» в том смысле, в котором там находится сайт. Пользователь устанавливает программу на смартфон, и значительная часть ее кода выполняется непосредственно на устройстве. Сервер нужен только тогда, когда приложению необходимо взаимодействовать с данными или функциями за пределами конкретного телефона.
Например, пользователь создает аккаунт, авторизуется, синхронизирует данные между несколькими устройствами, загружает фотографию, отправляет сообщение или оформляет заказ. В таком случае приложению уже требуется backend — серверная часть, которая принимает запросы, работает с базой данных и возвращает результат.
Именно для нее и выбирают хостинг, VPS, облачный сервер или готовую backend-платформу.
При этом далеко не каждому приложению вообще нужен собственный сервер. Калькулятор, офлайн-справочник, таймер, простая утилита или программа, которая хранит всю информацию исключительно на смартфоне, могут прекрасно работать без отдельного хостинга.
Поэтому правильный выбор начинается не с сравнения тарифов и количества гигабайт, а с более простого вопроса: что именно мобильное приложение должно делать в интернете?
Когда мобильному приложению вообще нужен сервер
Представим простой калькулятор. Пользователь вводит значения, приложение выполняет вычисления и показывает результат. Все происходит непосредственно на смартфоне.
Если разработчику не требуется учетная запись, синхронизация, получение данных с собственного сервера или другие сетевые функции, отдельный backend такому приложению может быть не нужен.
Похожая ситуация возможна с офлайн-справочником, конвертером величин, некоторыми трекерами, заметками и другими локальными инструментами.
Даже обновление самого приложения не требует собственного веб-хостинга, если оно распространяется через магазин приложений. Новая версия публикуется в соответствующем магазине, после чего пользователь получает обновление оттуда.
Сервер появляется тогда, когда данные должны существовать независимо от конкретного устройства.
Допустим, человек создал аккаунт на смартфоне, а затем установил приложение на планшет и хочет увидеть там ту же информацию. Хранить единственную копию данных только на первом устройстве уже нельзя. Нужна серверная часть.
То же относится к приложениям, в которых пользователи взаимодействуют друг с другом.
Мессенджер должен где-то хранить и передавать сообщения. Интернет-магазину нужны каталог, остатки и заказы. Сервису бронирования — расписание и единая база заявок. Социальному приложению — профили, публикации и реакции.
В таких проектах мобильная программа является клиентом, а основная общая информация находится на серверной стороне.
Типичная упрощенная схема выглядит так:
мобильное приложение → API → backend → база данных.
Если пользователи загружают фотографии, видео или документы, появляется еще и файловое либо объектное хранилище.
Если нужны уведомления, подключаются сервисы push-сообщений.
Если приложение принимает платежи, добавляется взаимодействие с платежной системой.
По мере развития проекта инфраструктура может становиться значительно сложнее, но небольшому приложению совершенно необязательно начинать с десятка отдельных серверов.
Что именно размещается на хостинге мобильного приложения
Одна из главных путаниц возникает из-за самого выражения «хостинг для приложения».
APK или другой установочный пакет Android-приложения может распространяться через магазин приложений или иным предусмотренным разработчиком способом. Для iOS используется собственная экосистема распространения.
Но серверное приложение работает отдельно.
На сервере может находиться backend, написанный на PHP, Python, Node.js, Java, Go или другой технологии.
Он получает запросы от смартфона.
Например, приложение отправляет логин и пароль. Backend проверяет учетные данные и возвращает результат авторизации.
Пользователь открывает список заказов. Backend получает соответствующие записи из базы данных и передает их приложению.
Пользователь меняет фотографию профиля. Сервер принимает файл или организует его загрузку в отдельное хранилище, а затем сохраняет информацию о новом изображении.
Таким образом, выбирать нужно не «хостинг для Android» или «хостинг для iPhone» как таковой. Нужно выбирать инфраструктуру для конкретной серверной части.
Один и тот же backend вполне может одновременно обслуживать Android-приложение, iOS-приложение и веб-сайт.
Например, интернет-магазин может иметь сайт и два мобильных клиента, которые работают с общей базой товаров и заказов через единый API.
В таком случае отдельный сервер для каждой мобильной платформы обычно не требуется.
Android и iOS не определяют мощность сервера
Иногда возникает вопрос, требуется ли Android-приложению один тип сервера, а iOS — другой.
В большинстве обычных проектов нет.
Сервер получает сетевые запросы и возвращает данные. Ему не принципиально, отправил запрос смартфон Android, iPhone или браузер, если API спроектирован для работы с соответствующими клиентами.
Поэтому выбирать VPS по операционной системе смартфонов пользователей бессмысленно.
Гораздо важнее технология backend, база данных, количество пользователей, характер запросов, объем хранимой информации и требования к доступности.
Можно ли использовать обычный виртуальный хостинг
Иногда можно.
Если backend написан, например, на PHP и представляет собой относительно простое API, обычный виртуальный хостинг способен прекрасно справиться с задачей.
Провайдер уже предоставляет веб-сервер, PHP, базу данных, SSL, панель управления и резервное копирование. Для небольшого проекта это может быть значительно проще самостоятельного VPS.
Не нужно устанавливать операционную систему, настраивать веб-сервер, следить за системными обновлениями и самостоятельно обслуживать СУБД.
Но виртуальный хостинг имеет ограничения.
Пользователь не получает полный контроль над сервером. Нельзя произвольно устанавливать любые системные компоненты. Действуют ограничения процессора, памяти, процессов и других ресурсов.
Для простого PHP-backend это может вообще не создавать проблем.
Для постоянно работающего Node.js или Python-приложения уже нужно проверять возможности конкретного провайдера. Некоторые виртуальные хостинги поддерживают такие технологии, другие — нет.
Если нужны отдельные worker-процессы, Redis, очереди задач, собственная конфигурация веб-сервера или нестандартное программное обеспечение, shared-хостинг может стать слишком ограниченным.
Поэтому виртуальный тариф стоит выбирать не по принципу «он дешевле VPS», а после проверки требований backend.
Когда мобильному приложению нужен VPS
VPS дает значительно больше свободы.
Разработчик получает виртуальную машину и может самостоятельно устанавливать необходимое программное обеспечение.
На одном сервере можно разместить API, базу данных, reverse proxy и другие компоненты небольшого проекта.
Для старта это вполне нормальная архитектура.
Не нужно сразу выносить каждый сервис на отдельную машину только потому, что так устроена инфраструктура крупной компании.
VPS становится особенно полезен, если backend использует постоянно работающие процессы, требует собственной серверной конфигурации или зависит от программного обеспечения, недоступного на обычном хостинге.
Например, приложение написано на Node.js. Дополнительно работает worker для обработки фоновых задач и Redis для временных данных.
Или backend создан на Python и требует определенного окружения и серверных компонентов.
На VPS разработчик может самостоятельно построить такую систему.
Но вместе с возможностями появляется ответственность.
Сервер необходимо обновлять, защищать, контролировать и резервировать. Нужно следить за свободным диском, состоянием служб и журналами.
Если разработчик приложения не занимается системным администрированием, можно рассмотреть управляемый VPS или готовую облачную платформу.
Не нужно покупать мощный VPS на вырост
С мобильными приложениями особенно легко попасть в ловушку будущей популярности.
Проект еще не опубликован, а инфраструктура уже проектируется так, будто завтра появится миллион активных пользователей.
В результате владелец оплачивает ресурсы, которые практически не используются, а разработка усложняется.
Гораздо разумнее начать с конфигурации, достаточной для текущей нагрузки, но предусмотреть возможность увеличения ресурсов.
Если приложение станет популярным, сервер можно масштабировать.
Именно возможность роста важнее огромного запаса мощности в первый день.
Готовый backend или собственный сервер
У мобильного разработчика есть не только выбор между виртуальным хостингом и VPS.
Существуют платформы, которые предоставляют готовые backend-функции.
Такой подход часто называют Backend as a Service, или BaaS.
Разработчику могут быть доступны готовая авторизация пользователей, база данных, файловое хранилище, серверные функции, уведомления и другие сервисы.
Это позволяет значительно быстрее запустить приложение.
Не нужно самостоятельно разворачивать сервер только ради регистрации пользователей или хранения нескольких таблиц.
Для прототипа, небольшого приложения или стартапа такой подход может быть очень удобным.
Но у него есть и обратная сторона.
Проект становится зависимым от возможностей, тарифов и ограничений конкретной платформы.
По мере роста расходы могут меняться. Некоторые нестандартные функции сложнее реализовать в рамках готовой экосистемы.
Миграция на собственный backend тоже может потребовать работы, если приложение сильно связано с сервисами выбранной платформы.
Собственный сервер дает больше контроля, но требует разработки и обслуживания серверной части.
Поэтому универсального победителя нет.
Если нужно быстро запустить относительно стандартную функциональность, BaaS способен сэкономить много времени. Если проект имеет сложную бизнес-логику и требует полного контроля над данными и инфраструктурой, собственный backend может оказаться разумнее.
Где хранить данные пользователей
Если приложению нужен сервер, почти всегда возникает вопрос хранения данных.
Для структурированной информации обычно используется база данных.
Это могут быть аккаунты пользователей, настройки, записи, товары, заказы, подписки и другие сущности.
Конкретная СУБД зависит от архитектуры проекта.
Часто используются PostgreSQL, MySQL, MariaDB и другие решения. Для отдельных задач могут применяться NoSQL-системы.
Небольшому приложению необязательно выделять базе отдельный сервер.
Backend и СУБД могут работать на одном VPS, если ресурсов хватает.
Это упрощает инфраструктуру и снижает расходы.
По мере роста базу можно вынести на отдельную машину или перейти на управляемую СУБД.
Но есть важное отличие между базой данных и пользовательскими файлами.
Фотографии, видео и документы не всегда разумно хранить непосредственно внутри базы.
Для большого количества файлов удобнее использовать файловое или объектное хранилище, а в базе сохранять информацию о них.
Это особенно актуально для приложений, где пользователи активно загружают фотографии и видео.
Если хранить все на системном диске одного небольшого VPS, пространство может закончиться намного раньше, чем вычислительные ресурсы.
Фотографии и видео способны изменить требования к инфраструктуре
Текстовые данные обычно занимают относительно немного места. Медиа — совсем другая история.
Представим приложение, в котором каждый пользователь может загрузить десять фотографий.
При небольшой аудитории проблема практически незаметна. Когда пользователей становится много, объем хранения начинает быстро расти.
Кроме самого места появляется трафик.
Сервер должен отдавать изображения тысячам устройств.
Поэтому медиафайлы часто выносят в объектное хранилище, а для их доставки используют CDN.
Это позволяет отделить хранение пользовательского контента от backend-сервера.
API занимается бизнес-логикой, а тяжелые статические файлы раздаются специализированной инфраструктурой.
Но маленькому приложению такая схема необязательно нужна с первого дня.
Если пользователи загружают несколько небольших изображений, обычного диска VPS может быть достаточно.
Главное — заранее понимать, как объем данных будет расти и куда их можно перенести позже.
Push-уведомления не отправляются просто с VPS на смартфон
Push-уведомления — еще одна область, вокруг которой возникает путаница.
Наличие собственного сервера не означает, что приложение напрямую устанавливает постоянное соединение с VPS исключительно ради получения обычных системных push-сообщений.
Для доставки уведомлений используются платформенные push-сервисы.
Backend определяет, кому и какое уведомление нужно отправить, после чего взаимодействует с соответствующей инфраструктурой доставки.
Поэтому при проектировании сервера нужно хранить необходимые идентификаторы устройств и безопасно работать с учетными данными сервисов уведомлений.
При этом секретные серверные ключи нельзя помещать внутрь мобильного приложения, если они позволяют выполнять привилегированные операции.
Все, что встроено в клиентскую программу и отправлено пользователю, потенциально может быть исследовано.
Секреты, которые должны оставаться действительно секретными, принадлежат серверной стороне.
Безопасность backend мобильного приложения особенно важна
Мобильное приложение нельзя считать доверенным клиентом только потому, что оно опубликовано официально.
Злоумышленник может исследовать сетевые запросы, модифицировать программу или вообще обращаться к API без оригинального приложения.
Поэтому сервер обязан самостоятельно проверять права доступа.
Если пользователь отправил запрос «покажи заказ №123», backend не должен просто верить, что этот заказ действительно принадлежит ему.
Нужно проверить авторизацию и разрешение на конкретное действие.
То же относится к изменению данных.
Нельзя полагаться исключительно на ограничения интерфейса. То, что в мобильном приложении отсутствует кнопка для определенной операции, еще не означает, что никто не попробует вызвать соответствующий endpoint напрямую.
Соединение с сервером должно быть защищено HTTPS.
Пароли нельзя хранить в базе открытым текстом.
Секретные ключи сторонних сервисов следует хранить на сервере, если клиенту они не нужны непосредственно.
Публичные API необходимо защищать от неконтролируемого количества запросов.
И конечно, backend и его зависимости нужно своевременно обновлять.
Почему нельзя просто спрятать секретный ключ в APK
Это заслуживает отдельного внимания, потому что ошибка встречается регулярно.
Разработчик использует внешний API, для которого нужен секретный ключ. Кажется удобным записать ключ непосредственно в мобильное приложение и отправлять запросы к сервису со смартфона.
Но приложение устанавливается на устройство пользователя.
Нельзя рассчитывать, что секрет, находящийся внутри распространяемого клиентского кода, навсегда останется неизвестным.
Если ключ дает доступ к платным или привилегированным операциям, безопаснее выполнять такие обращения через собственный backend.
Мобильное приложение обращается к вашему серверу, сервер проверяет пользователя и только затем взаимодействует с внешним сервисом, используя секретные учетные данные.
Конечно, это не означает, что абсолютно любой внешний API нужно проксировать через собственный сервер. Некоторые сервисы специально предусматривают публичные клиентские ключи и собственные механизмы ограничения.
Нужно понимать назначение конкретного ключа и модель безопасности используемого сервиса.
Старые версии приложения продолжают обращаться к серверу
Это одно из главных отличий мобильного backend от обычного сайта.
Когда владелец обновляет веб-сайт, посетитель при следующем открытии страницы получает новую версию.
С мобильным приложением все иначе.
Пользователь может месяцами не устанавливать обновление.
В результате к одному API одновременно обращаются разные версии клиента.
Представим, что разработчик изменил формат ответа сервера. Новая версия приложения его понимает, а старая — нет.
Если просто заменить API без учета совместимости, часть пользователей получит ошибки.
Поэтому серверную часть нужно развивать осторожно.
Для серьезных изменений API может использовать версионирование.
Например, старая версия приложения некоторое время работает с прежним интерфейсом, а новая — с обновленным.
Это не обязательно означает, что любую небольшую правку нужно превращать в новую версию API. Но обратную совместимость необходимо учитывать еще при проектировании.
Особенно важно это для приложений, где невозможно заставить всех пользователей обновиться в одну минуту.
Как выбрать расположение сервера
География сервера влияет прежде всего на сетевую задержку и правовые требования к обработке данных.
Если основная аудитория приложения находится в одном регионе, разумно размещать backend относительно близко к пользователям, если этому не мешают другие требования проекта.
Для приложения, ориентированного преимущественно на российскую аудиторию, нет большого смысла без причины отправлять каждый запрос через половину земного шара.
Но физическое расстояние — не единственный фактор.
Качество сети конкретного дата-центра, маршрутизация и производительность самого приложения тоже влияют на скорость.
Кроме того, если приложение обрабатывает персональные или другие регулируемые данные, нужно учитывать действующие требования законодательства и условия используемых внешних сервисов.
Для международного проекта инфраструктура со временем может распределяться по нескольким регионам.
Но маленькому приложению не нужно сразу создавать глобальную сеть серверов.
На старте достаточно выбрать разумную локацию для основной аудитории и сохранить возможность масштабирования.
Как понять сколько ресурсов потребуется
Количество установок приложения не равно количеству одновременных пользователей.
Это очень важное различие.
Программу могут установить сто тысяч человек, но большинство открывает ее раз в неделю. Другой сервис имеет гораздо меньше установок, зато пользователи активно взаимодействуют с ним весь день.
Поэтому выбирать сервер по числу скачиваний бессмысленно.
Не менее бесполезно считать только количество API-запросов за сутки.
Один запрос может вернуть небольшую запись из кеша. Другой запускает сложную выборку из базы, обработку изображения или обращение к нескольким внешним сервисам.
Нагрузка отличается в десятки и сотни раз.
Для нового приложения точные показатели заранее неизвестны.
Поэтому разумнее начинать с умеренной конфигурации и настроить мониторинг.
После запуска нужно смотреть загрузку процессора, использование памяти, время ответа API, состояние базы, дисковое пространство и ошибки.
Особенно важны пики.
Средняя нагрузка может быть небольшой, но после push-уведомления тысячи пользователей одновременно открывают приложение.
Именно в этот момент инфраструктура проходит настоящий тест.
Резервные копии важнее самого кода приложения
Исходный код backend обычно хранится в Git или другой системе контроля версий.
Если сервер потерян, программу можно развернуть заново.
Уникальные пользовательские данные восстановить значительно сложнее.
Поэтому резервное копирование должно прежде всего учитывать базу данных и загруженные пользователями файлы.
Частота backup зависит от того, насколько быстро меняется информация.
Для приложения, где пользовательские данные появляются постоянно, резервная копия раз в неделю может означать потерю огромного количества информации.
Для почти статичного проекта требования будут другими.
Полезно хранить хотя бы одну независимую копию вне основного сервера.
Если единственный backup находится на том же диске, что и рабочая база, при серьезной аварии можно потерять сразу оба.
И периодически нужно проверять восстановление.
Backup, который существует, но никогда не тестировался, дает ложное чувство безопасности.
Что происходит когда приложение начинает расти
Самый простой путь масштабирования — увеличить ресурсы существующего сервера.
Если проекту стало тесно на текущем VPS, можно перейти на конфигурацию с большим количеством процессорных ресурсов и памяти.
Для многих приложений этого хватает очень надолго.
Дальше можно постепенно разделять инфраструктуру.
База данных переезжает на отдельный сервер или управляемую платформу.
Пользовательские изображения — в объектное хранилище.
Статический контент — за CDN.
Фоновые задачи выполняются отдельными worker-процессами.
Если одного экземпляра backend становится недостаточно, запускаются несколько и перед ними устанавливается балансировщик нагрузки.
Но каждая такая ступень добавляет сложность.
Поэтому масштабировать нужно реальную проблему, а не предполагаемую.
Если CPU загружен на небольшую долю, база работает быстро, а API отвечает без задержек, добавление еще трех серверов ничего полезного пользователю не даст.
Что проверить перед покупкой хостинга для мобильного приложения
Перед сравнением тарифов нужно описать серверную часть проекта.
Ответьте хотя бы на несколько вопросов.
Нужен ли приложению сервер вообще? На каком языке написан backend? Как он запускается? Какая база данных используется? Загружают ли пользователи файлы? Нужны ли фоновые процессы? Есть ли WebSocket? Как реализована авторизация? Нужны ли push-уведомления?
После этого можно составлять требования к инфраструктуре.
При выборе площадки я бы проверила:
- поддержку технологии, на которой написан backend;
- доступные версии языка и серверного окружения;
- возможность установки необходимых зависимостей;
- наличие SSH, если он нужен разработчику;
- поддержку постоянно работающих процессов;
- возможность запускать фоновые задачи;
- доступные базы данных;
- возможность подключить внешнюю СУБД;
- наличие SSL и автоматическое продление сертификата;
- возможность использовать собственный API-поддомен;
- ресурсные ограничения;
- производительность и доступный объем диска;
- условия хранения пользовательских файлов;
- автоматические резервные копии;
- возможность скачать backup;
- доступ к журналам;
- наличие мониторинга;
- возможность быстро увеличить ресурсы;
- географию дата-центров;
- качество и режим работы технической поддержки.
Не каждый пункт нужен любому приложению.
Например, локальному калькулятору весь этот список вообще может не понадобиться, потому что серверной части у него нет.
А социальному сервису с фотографиями, сообщениями и тысячами активных пользователей придется значительно внимательнее относиться к базе, хранилищу, мониторингу и масштабированию.
Какой хостинг для мобильного приложения выбрать в итоге
Начать стоит с главного: Android- или iOS-приложению не обязательно нужен хостинг.
Если программа полностью работает на смартфоне и не хранит общие пользовательские данные на сервере, отдельная инфраструктура может вообще отсутствовать.
Когда приложению требуются аккаунты, синхронизация, общая база, загрузка файлов, сообщения или другая сетевая логика, появляется backend.
И уже для него выбирается площадка.
Небольшой PHP-backend может прекрасно работать на виртуальном хостинге. Более сложному Node.js, Python или другому серверному приложению может быть удобнее на VPS или специализированной платформе.
Если проект использует стандартные функции вроде авторизации, базы и файлового хранилища, стоит рассмотреть и готовые backend-сервисы. Они способны заметно ускорить разработку, хотя увеличивают зависимость от выбранной платформы.
Не покупайте огромный сервер только по количеству планируемых установок приложения.
Смотрите на реальную активность пользователей и характер серверных операций.
После запуска настройте мониторинг. Именно он покажет, чего не хватает: CPU, памяти, базы, диска или вообще не сервера, а оптимизации кода.
Если приложение хранит пользовательские данные, резервное копирование должно быть частью архитектуры с самого начала, а не функцией, о которой вспоминают после первой аварии.
Не забывайте и о безопасности. Мобильный клиент нельзя считать доверенной средой. Сервер должен самостоятельно проверять пользователя и его права, а действительно секретные ключи не следует прятать внутри распространяемого приложения.
И обязательно учитывайте старые версии клиента. После обновления backend часть пользователей продолжит работать со старой сборкой мобильного приложения, поэтому изменения API нужно проводить с учетом обратной совместимости.
Для небольшого проекта хорошим началом может стать один сервер или вообще готовая backend-платформа. Если аудитория вырастет, базу, файлы, кеш и фоновые задачи можно постепенно разделять.
Хорошая инфраструктура мобильного приложения — не самая дорогая и не самая сложная. Она должна надежно решать сегодняшнюю задачу и позволять проекту расти без необходимости полностью перестраивать backend после первых же успехов.
