Пришло несколько мыслей по мотивам поста «Куда развивать виртуальные услуги ?» и не только.
default.abcd.bz/blog/hosting/17247.html

Внимание, дальше будет словоблудие и пиздобольство, вместо готовой панели.



Писать панель для управления вдс или хостингом на дедике — дело достаточно запарное. И там может вылезти значительное количество граблей. Более того есть бесплатные панели которые всем не нравятся и есть типа ентерпрайз решения, которые умеют все, но стоят конских денег и не пиратятся.
Прочитав множество топиков на эту тему и попытавшись собрать все «пожелания» в одну кучу я вижу требования к панели такие:
— простое добавление дедика в панель
— создание виртуалки на дедике с возможностью её переноса на другой дедик (с даунтаймом с согласия клиента)
— нарезка дедика под хостинг — дисковые квоты, переключение версий PHP, мускул, apache\nginx и прочие «радости»
— для хостинга — подключение бесплатного SSL сходу и по умолчанию
— биллинг за хостинг (для клиента)
— биллинг «складчины» за хостинг — платежи за хостинг сливаются в один дедик/вдс (для продавца дедика)
— биллинг «складчины» за вдс — платежи за вдс на одном дедике сливаются в оплату дедика автоматом (для продавца дедика)
— биллинг за ВДС (для клиента)
— биллинг за дедик (для клиента)
— днс — регистрация/продление, авто-почта и т.д. (тут тема достойна отдельной панели)

На сколько я понял не одна из существующих панелей на данный момент не упрощает продажу дедика или впс, а наоборот — усложняет. Если у тебя есть дедик, и ты хочешь его перепродать под шаред-хостинг или впс — все нужно делать самому.

Это основное. Тут ещё много чего обсуждать.
Я пару дней прям глубоко задумался над этим. И пришел к таким выводам
делать такую панель как отдельно расспространяемую софтину — бессмысленно.
Причины такие: такая софтина достаточно сложна, и будет на разные оси/конфигурации серверов вставать очень плохо, никакой факт не поможет. Нужна будет высокая админская конфигурация чтобы вкрячить её на дедик. Или она будет заточена под фиксированную версию ОС и шаблонный конфиг дедика — что сразу делает её не нужной.
делать такую панель чтобы продавц сами её ставили и отдавали клиентам — ничего не меняет в текущем раскладе вещей.
Алиска и большинство игроков хотят просто как можно быстрее продать ресурсы, а клиент хочет «одну кнопку» и чтобы было.
Через панель должно быть возможно «уплотнить» дедики, если клиенты свалил/забили болт и т.д.

Самое главное — такую панель надо все время поддерживать, выпускать новые версии, следить за совместимостью и т.д. Нельзя просто написать и забыть — через год она перестанет работать.

Решение.
Возможно поддерживать такую панель если полностью контролировать сервера, с которыми она работает. При этом панель и продаваемый сервер — не должны быть вместе, на одном хосте. Т.е. панель должна стоять отдельно и настраивать подключаемые к ней сервера. Это рентабельно делать только если есть жёстко заданная экосистема, в которой все технические аспекты находятся под контролем. Чтобы достичь этого панель должна работать как сервис.

Панель как сервис. (теперь буду называть сервисом)
Из всех описанных проблем нынешнего хостинга и слов о том что «нужно создавать новый рынок» вытекает что сервис должен соединить покупателя с продавцом. И избавить обоих от головной боли.
Продавец дедиков приходит на сервис и регистрирует там свои дедики (оставляя рутовый пароль), конфиг дедика считывается автоматически. Также указывает сумму, которую хочет получать с дедика в месяц.
Клиент шареда/вдс приходит на сервис и оставляет заявку (из шаблонных, шаблонов может быть много, нужный выбирается через конфигуратор) на шаред или вдс.
Клиенты набираются согласно вместимости дедика и система заливает на дедик преднастроенные виртуалки для шареда или нарезает дедик на вдс-ки и отдает доступы клиентам.
Пока дедик не заполнен — он работает без прибыли (плата за доли меньше той суммы, которую просил продавец). Когда спрос превышает предложение — все просто. Когда спрос меньше предложений — сервис или гоняет свои «резервные» сервера (в идеале не более одного с недобором по «долям»)
Когда продавец продает дедик в системе — дедик должен быть уже готов и включен.

Немного про техническую часть.
Сервис существует полностью на подконтрольной создателю инфраструктуре и взаимодействует с серверами через агентов, которые ставяться на сервера.
Агент должен быть написан так, чтобы не требовать никаких особых настроек и зависимостей, кроме разве что нескольких установленных пакетов через менеджер пакетов. Раскатать агента на сервер можно через ansible, покрыв самые популярные дистрибы линуксов.
Агент занимает тем, что мониторит дедик, закачивает на него и запускает образы преднастроенных или чистых виртуалок.
Чистые — для потребителей ВДС
Преднастроенные — хостинги, игровые сервера, шаред-хостинги.
Т.е. клиент может себе заказать не только хостиг, но и готовый шаред-хостинг. Виртуалка может быть одна на сервере и занимать весь сервер. Это не оптимально по ресурсам, но это «управляемо» и такого клиента можно легко перенести к другому «продавцу» в случае проблем.
Если клиент хочет чистый дедик — сервис дедик не настраивает, а просто отдает логин/пароль сразу клиенту.
Техническая поддержка, ответы на вопросы в таком случае идут через сервис, но отвечает на них продавец — в чате, тикитах или где-то ещё.

Это получается не «облако», а сервис автоматизированного ресейла ресурсов, заточенный под продажу отдельных, не связанных между собой дедиков. Будь то они в ДЦ или у кого-то в подвале. SLA у сервиса будет низкий, но это компенсируется хорошей ценой.

В полном масштабе система очень объемная.
Минимальная рабочая и осиляемая по набору функционала выглядит так:
— регистрация продавца
— админка с регистрацией его дедикиков
— регистрация клиента
— «маркет» имеющихся в продаже дедиков
— конфигуратор ВДС, покупка ВДС (если есть соответствующие доли)
(соответственно сервис находит на каком дедике есть нужная доля и ставит туда чистую или преднастроенную на хостинг виртуалку)

шаред-хостинг — это сильно сложнее и сильно потом, если вообще будет нужно

По моим оценка (по многолетнему опыту разработки) готовая к работе альфа может быть собрана за 3-4 месяца фулл-тайм работы 2-х матерых программистов. Далее даже если не развивать функционал, то надо будет постоянно чинить и обновлять под новые версии всего, начиная с версий линукса.
Чтобы при этом сохранить уровень дохода «типичного программиста» для тех у кого нету спонсоров, сданных в аренду квартир, процентов в банке и прочих благ — проект должен очень быстро выйти на минимальную окупаемость. 1,2,3 месяца можно прожить на накопления и кредиты, а дальше если не будет дохода — придется искать другие способы заработка. Если писать это проект по вечерам и воскресеньям — шансы на его становление близки к нулю. Итого, чтобы выйти на окупаемость самый простой вариант — брать 10% от стоимости перепродаваемого дедика, тогда нужно около 1500 дедиков иметь на перепродаже.
Для получаения такого количества клиентов — они или уже где-то должны ждать или должен быть массивный маркетинг. ибо 1500 дедиков нарезанных на ВДС — это средне-потолочно 8000 клиентов.

Итого. Объем рынка совковых-вдс и прочих-говношаредов имеет такой спрос, чтобы на гора выдать 8000 клиентов?