вычислительных мощностей для физического размещения информации на
сервере, постоянно находящемся в сети (Wiki). И эта услуга, вобщем-то, является зеркалом веб-разработок — той самой информации, которая в сети. За последнии годы изменилась аудитория Интернет: увеличилась в количестве пользователей и увеличелаясь длительность нахождения в Сети. Изменилось и отношение к информации: новости хочется читать по-быстрее, а фотографии хранить — по-надёжней. Собственно, технологии веб-разработок тоже не стоят на месте. И рынок хостинга вынужден на это реагировать.
Технологии веб-приложений
Если было время, когда веб-приложения строились на Perl/PHP. То сейчас активно используются PHP/Python/Ruby. Язык программирования (фреймворк или набор модулей) определят скорость разработки сайта как приложения. Поскольку сайт-приложение может создаваться не одним человеком и не «в потоке сознания», а обычно командой и итеративно — системы контроля версий (VCS) упрощают работу.
Системы хранения данных тоже не стоят на месте. MySQL, пожалуй, самая популярная из бесплатных реляционных БД. Но на данный момент у неё есть форки в лице Percona Server и MariaDB, которые обещают совместимость с клиентом к MySQL, при этом награждая рядом плюшек. Так же есть конкурент — PostgreSQL. Тоже развивается, занимая свою нишу на рынке.
Сами веб-приложения теперь оперируют не просто файлами, а типами данных. Я имею ввиду, что сервер, отдавая style.css или script.js, может сжать налету, минифицировать, ориентируясь на особенности такого текстового файлика. Сервер, отдавая файлы video.mpeg, audiocast.mp3, сможет отдать их в поток. Сервер разделяет файлы статики, которые можно отдать быстро и в большом количестве, и файлы приложения.
Есть ряд других особенностей, которыми обросли веб-приложения. Например имейл-рассылка, которую свойственно делать почтовым серверам, но инициироваться она может из веб-приложения. Например push-технология, когда веб-приложение может инициировать канал общения с клиентом, оперативно информируя об изменениях — он-лайн чат самый яркий пример. Инициировать-то канал веб-приложение могло и раньше, а вот поддерживать большое количество слушателей — это уже становится задачей сервера.
Удобно, надёжно, быстро
Теперь возьмем за цель: удобно в мастабировании, надёжно в использовании, быстро в работе.
Дальше — пожелания для «идеального» хостинга:
- Наличие nginx или другого решения для раздачи статики
- Наличие PHP 5.3
- Наличие модулей iconv, GD, PDO, mbstring, mcrypt, xcache
- Доступ к user.php.ini
- По-возможности PHP 4.0/5.0/5.2/5.4 с возможностью выбора версии.
- Поддержка Perl/Python/Ruby
- Наличие MySQL в виде Percona Server или MariaDB
- Наличие PostgreSQL, sqLite
- По-возможности NoSQL решение в виде memcached и/или MongoDB
- Наличие Git, как системы контроля версий
- Удобное добавление пользователей через админчасть хостинга
- По-возможности Mercurial/Bazaar
- Масштабирование ресурсов без переноса приложения
- Автоматическое резервное копирование
- За последнии 5..14 дней или X GB
- В 2 датацентра, удалённых географически от текущего
- Выделенный IPv4 по запросу
- Поддержка IPv6
- Удобная установка SSL-сертификата через админчасть хостинга
- Возможность покупки этого SSL-сертификата
- Возможность установить ptr-запись
- По-возможности покупка домена
- Максимальное количество доменных зон на выбор. Например как 101domain.ru
- Удобное управение DNS-зоной
- Наличие ресейлинга
- Удобное управление проектами/пользователями через админчасть
- Реферальная программа
- Удобное управление проектами/пользователями через админчасть
Истоки проблемы
В итоге логичней всего — арендовать VDS или DS. И тут уже разворачиваться как душе угодно: ставить любые версии ПО, настраивать по вкусу. В общем подобным образом эта проблема решалась досегодня. Для крупных проектов студия ресейлила VDS, который настраивался силами самой студии. Для мелких проектов — хостинг студии или хостинг одного из крупных хостеров Украины.
Только в первом случае нужно «быть системным администратором». Даже, когда проект уже здан. С каждым новым проектом нужно вспоминать особенности настройки того или иного ПО. И даже знаю как конфигурировать apach или nginx, я предпочту не заниматься системным администрированием без резкой надобности.
Во втором случае получаешь ряд неудобств на этапе разработки. У хостера может может быть отключен mod_rewrite — красивых адресов не получишь. У хостера может быть отключен ряд модулей PHP — нормальной работы с XML или UTF8 не будет.
Вот и получается, что поддержка системы контроля версий и прозрачное масштабирование за гранью фантастики.
Решения
И хотя требование «выделенный IPv4» от хостинга как-бы неуместно, современные средства виртуализации должны позволить плавный переход от тарифа «Маленький хостинг» к тарифу «Виртуальный сервер». Плавный — значит без моего участия в копирывании файликов и БД, и даже без остановки работы приложения. Масштабирование, которое позволяет так наращивать производительность, должно позволить и уменьшить ресурсы по требованию и временно отключить приложение.
А подобное резервное копирование в два удалённых дата-центра — это уже реально для любого хостера. Такая услуга может тарифицироваться отдельно. Главное что б была и работала. Как показывает практика таким резервированием стоит пользоваться.
Из очень критичного остается nginx+Php+MySQL+git .
Пока найдены два кандидата: американский phpfog.com и русский locum.ru. И пока у них единственный недостаток — они не украинские, а значит нет украинских реквизитов, нет быстрого доступа в точку UA-IX.
В этом и заключается идея для региональных компаний: git-хостинг на Украине. Для начала.