Раньше (то есть в девяностые и начало нулевых) хостинг был всего двух видов: Dedicated и Shared. В первом случае ты получаешь сервер определенной конфигурации — и делай с ним, что хочешь.
Shared Hosting — альтернатива для простых людей и малых организаций. Платишь немного денег и получаешь доступ к админской панели, папке на FTP и реляционной БД (или нескольким). Все, что нужно, чтобы развернуть сайт! Если понадобятся какие‑то настройки веб‑сервера, то для этого в Apache есть конфиги .
, которые кладутся прямо в папку с сайтом.
Недостатков у этого метода масса. Масштабируемость — никакая, доступа по SSH обычно нет, установить что‑то на уровне системы невозможно, поставить задачу в cron — никак. Да и с безопасностью у обычного FTP не все в порядке из‑за отсутствия шифрования.
На замену Shared Hosting пришло сразу много разных вещей, каждая из них — для своей категории пользователей.
VPS и VDS — замена для тех, кто мечтал о выделенном сервере (Dedicated), но не хотел платить много. Тут тебе и SSH, и cron, и установка любых приложений. Многие провайдеры сейчас даже разрешают загрузить ISO с операционкой. Очевидный недостаток — систему придется админить: настраивать и потом обновлять веб‑сервер, обратный прокси, базу данных, фреймворки и все остальное хозяйство. Ускорить деплой можно при помощи Docker, но порог вхождения это только повышает.
Если нужна масштабируемость, то ставки растут еще сильнее: для серьезных дел теперь нужен облачный хостинг, Kubernetes, виртуальная сетка и прочие радости. Не то чтобы в этом было что‑то плохое, просто это индустриальный уровень, где поддержкой может заниматься целая команда.
Для тех, кто не хочет админить, есть другое решение — PaaS-платформы вроде Heroku и Google App Engine, а также лямбда‑функции, они же «бессерверный хостинг». В первом случае мы завязываемся на какое‑то конкретное заранее обустроенное окружение со своими особенностями, во втором вообще загружаем только программный код и даже данные храним где‑то отдельно. Немного в стороне стоит Vercel — удивительное творение фронтендеров, которые решили заново изобрести бэкенд.
Все эти штуки тоже хороши, но ориентированы в первую очередь на веб‑приложения. То есть нацелены на программистов, имеют определенный порог вхождения и не дают просто взять и выложить что‑то в интернет.
Чуть более дружественны к новичкам облачные среды разработки вроде Glitch и Replit. Некоторые из них готовы хостить статику в разумных пределах и позволяют держать сервис перманентно запущенным, причем даже на бесплатных тарифах.
Ну и наконец, для простых людей, не обученных искусствам кодинга и администрирования, есть сервисы вроде Wix.com, «Тильды» и прочих конструкторов. Но рассматривать их как хостинг было бы странно: тут нужно платить несколько тысяч рублей в месяц за смехотворное количество данных и трафика. Скорее это плата за пользовательский софт, готовые шаблоны и дополнительные сервисы вроде приема платежей.
В общем, все перечисленное совершенно не подходит, если ты планируешь либо захостить статический сайт, либо просто кинуть какой‑то файл и сделать его доступным через HTTP. Ну или запустить простенькое веб‑приложение, не настраивая весь стек и не адаптируя свой код к причудам окружения.
Для статических сайтов, впрочем, есть еще два неплохих варианта: бакеты S3 и GitHub Pages. С тех пор как бесплатные аккаунты GitHub стало возможно делать приватными, он стал почти идеальной площадкой для небольшого личного сайта.
Нужно только понимать, что сервис предоставляется «по доброте душевной», то есть только до тех пор, пока в Microsoft его считают выгодным и полезным. Если не веришь, что его когда‑нибудь могут прекратить, вспомни судьбу GeoCities.
Объектное хранилище S3 такого недостатка лишено и точно не должно никуда пропасть, пока ты платишь копеечку. Вот только перевести ее из России теперь непросто; аналоги S3 есть у «Яндекса» и Mail.ru, но статические сайты, насколько я знаю, там хостить не выйдет.
К тому же бакет S3 требует единоразовой, но заковыристой настройки, прежде чем станет сайтом. Чтобы файлы из него было видно из интернета, понадобится подключить роутинг Amazon Route 53 и определенным образом настроить политики доступа.
info
Как‑то раз я написал статью о статгенераторе Lektor. Он разработан на Python, а создал его автор минималистичного веб‑фреймворка Flask и шаблонизатора Jinja2.
Кстати, если хочешь сэкономить, можешь попробовать замутить какое‑то сочетание из статического сайта на GitHub и бесплатных возможностей облачной IDE вроде Glitch или Replit. Можно еще попробовать добавить Firebase для хранения данных, там вполне вольготные лимиты на бесплатное использование. Но это все же немного из серии «как сделать троллейбус из буханки хлеба» — занятно, но не очень надежно и основано на конкретных продуктах.
Ну и наконец, сайт можно захостить прямо у себя дома — на свисающей с пачкорда Raspberry Pi. Достаточно купить статический IP и прописать NAT на роутере. Выйдет даже не Dedicated, а владение своим дата‑центром! Но, думаю, недостатки такого решения вполне очевидны.
Получается, что уникальность Shared-хостинга была в простоте и стандартизации. Ты всегда мог рассчитывать на один и тот же стек LAMP и любимые всеми хостерами cPanel и phpMyAdmin. Да, конечно, сейчас все это уже полное старье. Но тот же уровень переносимости теперь достижим только с виртуальным сервером и Docker. Тот же уровень легкости — просто никак.
Хоронить старорежимный хостинг пока рановато: его еще предоставляют компании вроде BlueHost, HostGator, SiteGround и прочие. Но из мейнстрима он превратился в редкость и доступен все больше как легаси.
Мне кажется, при изобилии самых разных вариантов прямой замены ему так и не придумали. Перетаскивать статику и скриптики в окно FTP-клиента и получать работающий сайт по‑прежнему чертовски удобно.