В истории с нашим первым собственным ЦОДом, действительно, сначала был объект, а потом все остальное. Но это не профанство. Мы сравнивали расчеты по многим вариантам. И все-равно остановились на этом.
Важная оговорка: объект обладает подключением к электросетям ФСК. Это экономия на э/э примерно в два раза. Как долгосрочный экономический фактор этот — самый важный.
Построить 120км ВОЛС намного дешевле и проще, чем получить новое подключение к электросетям.
KubeVirt - интересный проект, и для приватных инсталляций вполне может стать выходом. Но мы говорим про публичное IaaS облако и масштаб гиперскейлера. Есть риск наткнуться на острые углы и ограничения, идущие от изначальной ориентированности оркестратора (k8s) на контейнеры. И вы сами правильно сказали - функционал, пока еще, ограничен.
Это два несравниваемых решения. Как теплое с мягким. ProxMox - это про виртуалки. CloudStack — про облака. Принципиально другой жизненный цикл вычислительных машин, и как следствие — другой подход к эксплуатации ПО в этих средах.
Спасибо, по 4 пункту сразу отдали в разработку. А если по-порядку, то вот:
Тут надо смотреть на каждую ситуацию в отдельности. Единого варианта нет. Кому-то подойдет ProxMox (это все-же про виртуализацию на уровне предприятия), для кого-то - CloudStack или OpenNebula (если замахнуться на приватное облако). Кому-то проще/лучше будет переехать на K8S, пусть и на BareMetall. Помимо масштабов инсталляции надо еще и на задачу смотреть.
Для платформы приложений L1veStack этого вполне хватает, для приватного теста своего клауда — тоже. Перед релизом, конечно, возьмем /18 подсеть. Про ЦОДы и инфраструктуру скоро выпустим статьи.
Уставный Капитал — не показатель. Мы запускаемся на частные инвестиции и следуем практикам бережливого стартапа. Что не мешает нам преследовать амбициозные цели.
Уже исправляем). Кстати, присоединяйтесь к нашей программе тестирования. Мы уже набрали участников, но для вас сделаем исключение. Познакомитесь поближе с продуктом. Так «абстрактный L1veStack» станет вполне конкретным Docker-хостингом или даже Serverless Kubernetes платформой для развертывания ваших приложений.
К этому вопросу мы подошли основательно. Собрали бэк-лог, детально проанализировали его, и поделили на три глобальные вехи: proof-of-concept (уже прошли), MVP и релиз. С MVP мы выйдем в закрытую бету в ближайшее время. А до релиза платформы как самостоятельного продукта придется какое-то время попахать.
Мы выбрали стек, который позволяет нам двигаться быстро (есть хорошие компетенции), и спланировали архитектуру, в которой нет адских усложнений. Во всем этом есть опыт. О том, что получается и что не получается мы честно поделимся в будущих постах.
Простите, да, не совсем точно выразился в последнем абзаце. Мы развернули Опенстек. Посмотрели в процессе и в тестовой эксплуатации два месяца. Оценили, как с ним жить, и стали пилить свою платформу.
Знаете, мы любим OSS и много его используем. И лично у меня десяток проектов, с совершенно разным стеком (включая кластерные системы разного рода). И ни с одним из сотни продуктов не было СТОЛЬКО стружек после их запиливания.
Но вы правы в том, что если рядом с OSS есть Enterprise-версия, то степень наглости разработчиков/глючности опенсорса может варьироваться от «легкие ограничения» до «хрен ты её запустишь без перепиливания кода». И вы считаете, что это честно?
Вы, похоже, невнимательно читали. Вывод как раз в том, что мы им не пользуемся и другим не советуем. А уж строить на нем коммерческую услугу — тем более!
Нет, совершенно неправильно. Мы с ним совладали и оценили расходы на допиливание как более высокие, чем создание своей платформы.
Почему вы считаете, что открытый проект без коммерческой доработки должен быть корявым? Кто сказал, что это нормально, когда OSS не работает «из коробки» как заявлено и требует напильника или коммерческой поддержки?
Мы не тарифицируем запрошенные ресурсы, только потребленные. Посекундно.
Если вы запускаете, к примеру, контейнер с Redis, он потребляет 10 (!) МБ памяти, и в среднем 0.85% процессорного времени. В реальности это прямо по секундам считается, но в нашем условном примере получится такая математика:
10 МБ * 0,0015 ₽ (за МБ в час) * 730 часов = 10,95 ₽ за RAM за месяц.
0,85% загрузка vCPU * 4,5 ₽ (за 100% vCPU в час) * 730 часов = 27,92 ₽ за vCPU
SSD нужен не каждому контейнеру, а выделенный IP - не каждому проекту. При этом отсутствие публичного IP ≠ отсутствие внешнего доступа.
Итого, контейнер с Redis обойдется за месяц 38,87 ₽, если проработает весь месяц. Но у контейнера может быть более короткий жизненный цикл. Например, если запускать контейнер для экспериментов, тестирования, или во время обучения.
730 часов в среднем в месяц получается при расчете 365 (дней) * 24 (часа) / 12 (месяцев).
Под информационными системами с российским владельцем мы имеем в виду VK ID, Я.ID или Сбер.ID. Доверять аутентификацию своих пользователей конкурентам — не самая удачная идея.
Кроме того, важно учитывать, что на нас, как на хостинг, распространяются требования по обязательной идентификации клиентов.
Минцифры утвердило такие способы:
через Единую систему идентификации и аутентификации (ЕСИА) и Единую биометрическую систему (ЕБС);
с использованием усиленной квалифицированной электронной подписи;
после предъявления при личном обращении к провайдеру хостинга определённого набора документов;
посредством перевода денежных средств на банковский счёт провайдера хостинга с банковского счёта лица, обратившегося к провайдеру хостинга, открытого в банке РФ в соответствии с требованиями законодательства:
через иную информационную систему, используемую провайдером хостинга и обеспечивающую идентификацию;
Интеграция любого из этих способов в UX-сценарий, чтобы система оставалась удобной и понятной для пользователей, — отдельная задача, требующая дополнительных ресурсов на разработку.
При этом вход по смс сегодня остается стандартным и привычным вариантом.
Ваш комментарий по способам входа мы отметили для себя, и, как любое пожелание пользователя, будем держать на виду при проектировании. Спасибо за ваше внимание!
Мы ваш проект всесторонне проанализировали после ваших ноябрьских публикаций. Как и при анализе других облачных провайдеров для нашего IaaS-проекта, мы уделяем внимание разным аспектам, включая наличие собственной инфраструктуры.
Очень странный аргумент. По вашей логике, если у платформы нет своего собственного ЦОД, то она не полноценна? Выглядит как попытка натянуть сову на глобус)
Речь как раз не столько про ЦОД, сколько про собственную инфраструктуру.
Если серьезно, то любая платформа это в первую очередь технологическое решение и функционал, который предоставляется пользователю.
Функционал платформы — это абстрагированное отражение ее инфраструктуры. Хочется понимать, насколько надежно базовое решение, на котором работает платформа.
Физические сервера при этом могут быть в любом достойном ЦОД (в аренде или коллокейшне)
Это уже вопрос вашей ответственности перед конечным пользователем. Насколько вы надежны как бизнес? Сложно однозначно ответить на этот вопрос утвердительно, если вы используете исключительно арендованную инфраструктуру.
Мы стараемся максимально абстрагировать конечного пользователя от содержимого под нашим капотом. Сейчас система переваривает синтаксис Docker Compose, в работе — поддержка YAML Config для Kubernetes и Helm Chart.
Какой прокси гейтвей, можно ли его как то настроить (CORS, хедеры и т.д.)?
Этот функционал планируется как часть платформы, но пока даже не начинали работу — это не типичный сценарий. Тем не менее, ничего не мешает использовать в качестве входной точки контейнер с NGinx или Kong и настроить их как душе угодно.
Можно ли со своим доменом?
Конечно. На данный момент потребуется IPv4 (в работе — функционал подключения любого домена без выделенного IP).
Что с сетевыми метриками и логами запросов?
Пока ситуация аналогична Gateway: этот функционал не встроен в платформу. Однако никто не мешает поднять ELK, Prometheus, Grafana и вообще все, что душе угодно.
Есть ли автоскейлинг и по каким метрикам его можно настроить?
Есть вертикальный, если не задать лимит ресурсов. Также можно задать несколько реплик и менять их количество на ходу. Для автоматизации горизонтального скейлинга готовим пользовательские сценарии.
Есть ли постоянные тома хранилища, снепшоты, резервное копирование?
Сетевые тома есть. Снепшоты находятся в разработке, резервного копирования нет, но с учетом резервирования и снепшотов оно не критично.
Есть ли версионирование деплоев? Можно ли откатиться по кнопке?
Нет. Спасибо за предметные вопросы. Сейчас перед нами десятки фич, поэтому важно правильно расставить приоритеты, какие из них нужнее.
Будет ли техническая документация?
Обязательно. Сейчас мы предлагаем максимально простой опыт: Docker Compose -> deply (понятно по видео).
Все, что вы описали, относится к продвинутым настройкам для развертывания. Многим пользователям потребуется время, чтобы освоить их. Мы хотим сохранить баланс между простотой интерфейса и гибкостью настроек, чтобы сделать платформу удобной как для новичков, так и для опытных разработчиков.
Каждый из описанных сценариев требует значительных усилий (кроме, возможно, версионирования) и нескольких спринтов на реализацию. Поэтому мы рассчитываем на помощь сообщества — ваша обратная связь поможет нам приоритизировать задачи и создать действительно полезный инструмент.
Незадолго до запуска мы провели анализ рынка облачных провайдеров и проверили тезис о том, что мы — первый контейнерный хостинг.
В статье упоминалось, что есть несколько хостингов, предлагающих запуск контейнеров, но как дополнение к VPS.
Amvera мы не учитывали, поскольку они больше ориентированы на запуск вашего кода (из гита) внутри контейнера с фиксированным тарифом. Они и сами позиционируют себя как DevOps-платформа.
dockerhosting.ru, который размещается на чужом хостинге, мы в расчет брать не стали. Мы не нашли информацию о юридическом лице, а их три тарифа с фиксированной оплатой больше напоминают классические VPS, только сбоку.
Ваш проект, dockerhost.ru, мы тоже изучали. Как и dockerhosting.ru, он немного не дотягивает до полноценного провайдера, так как опирается на инфраструктуру Selectel вместо собственной.
Да кто ж его знает. Это вытекает это не из регламентов, а из практики. А до практики не дойти, не выполнив требования регламентов.
г. Александров, Владимирская область.
В истории с нашим первым собственным ЦОДом, действительно, сначала был объект, а потом все остальное. Но это не профанство. Мы сравнивали расчеты по многим вариантам. И все-равно остановились на этом.
Важная оговорка: объект обладает подключением к электросетям ФСК. Это экономия на э/э примерно в два раза. Как долгосрочный экономический фактор этот — самый важный.
Построить 120км ВОЛС намного дешевле и проще, чем получить новое подключение к электросетям.
KubeVirt - интересный проект, и для приватных инсталляций вполне может стать выходом. Но мы говорим про публичное IaaS облако и масштаб гиперскейлера. Есть риск наткнуться на острые углы и ограничения, идущие от изначальной ориентированности оркестратора (k8s) на контейнеры. И вы сами правильно сказали - функционал, пока еще, ограничен.
То что вы описали — это про маленький VPS-хостинг. Мы все-же про облака и гиперскейл.
Это два несравниваемых решения. Как теплое с мягким. ProxMox - это про виртуалки. CloudStack — про облака. Принципиально другой жизненный цикл вычислительных машин, и как следствие — другой подход к эксплуатации ПО в этих средах.
Спасибо, по 4 пункту сразу отдали в разработку. А если по-порядку, то вот:
Тут надо смотреть на каждую ситуацию в отдельности. Единого варианта нет. Кому-то подойдет ProxMox (это все-же про виртуализацию на уровне предприятия), для кого-то - CloudStack или OpenNebula (если замахнуться на приватное облако). Кому-то проще/лучше будет переехать на K8S, пусть и на BareMetall. Помимо масштабов инсталляции надо еще и на задачу смотреть.
Для платформы приложений L1veStack этого вполне хватает, для приватного теста своего клауда — тоже. Перед релизом, конечно, возьмем /18 подсеть. Про ЦОДы и инфраструктуру скоро выпустим статьи.
Уставный Капитал — не показатель. Мы запускаемся на частные инвестиции и следуем практикам бережливого стартапа. Что не мешает нам преследовать амбициозные цели.
Уже исправляем). Кстати, присоединяйтесь к нашей программе тестирования. Мы уже набрали участников, но для вас сделаем исключение. Познакомитесь поближе с продуктом. Так «абстрактный L1veStack» станет вполне конкретным Docker-хостингом или даже Serverless Kubernetes платформой для развертывания ваших приложений.
К этому вопросу мы подошли основательно. Собрали бэк-лог, детально проанализировали его, и поделили на три глобальные вехи: proof-of-concept (уже прошли), MVP и релиз. С MVP мы выйдем в закрытую бету в ближайшее время. А до релиза платформы как самостоятельного продукта придется какое-то время попахать.
Мы выбрали стек, который позволяет нам двигаться быстро (есть хорошие компетенции), и спланировали архитектуру, в которой нет адских усложнений. Во всем этом есть опыт. О том, что получается и что не получается мы честно поделимся в будущих постах.
Простите, да, не совсем точно выразился в последнем абзаце. Мы развернули Опенстек. Посмотрели в процессе и в тестовой эксплуатации два месяца. Оценили, как с ним жить, и стали пилить свою платформу.
Знаете, мы любим OSS и много его используем. И лично у меня десяток проектов, с совершенно разным стеком (включая кластерные системы разного рода). И ни с одним из сотни продуктов не было СТОЛЬКО стружек после их запиливания.
Но вы правы в том, что если рядом с OSS есть Enterprise-версия, то степень наглости разработчиков/глючности опенсорса может варьироваться от «легкие ограничения» до «хрен ты её запустишь без перепиливания кода». И вы считаете, что это честно?
Вы, похоже, невнимательно читали. Вывод как раз в том, что мы им не пользуемся и другим не советуем. А уж строить на нем коммерческую услугу — тем более!
Нет, совершенно неправильно. Мы с ним совладали и оценили расходы на допиливание как более высокие, чем создание своей платформы.
Почему вы считаете, что открытый проект без коммерческой доработки должен быть корявым? Кто сказал, что это нормально, когда OSS не работает «из коробки» как заявлено и требует напильника или коммерческой поддержки?
Мы не тарифицируем запрошенные ресурсы, только потребленные. Посекундно.
Если вы запускаете, к примеру, контейнер с Redis, он потребляет 10 (!) МБ памяти, и в среднем 0.85% процессорного времени. В реальности это прямо по секундам считается, но в нашем условном примере получится такая математика:
10 МБ * 0,0015 ₽ (за МБ в час) * 730 часов = 10,95 ₽ за RAM за месяц.
0,85% загрузка vCPU * 4,5 ₽ (за 100% vCPU в час) * 730 часов = 27,92 ₽ за vCPU
SSD нужен не каждому контейнеру, а выделенный IP - не каждому проекту. При этом отсутствие публичного IP ≠ отсутствие внешнего доступа.
Итого, контейнер с Redis обойдется за месяц 38,87 ₽, если проработает весь месяц. Но у контейнера может быть более короткий жизненный цикл. Например, если запускать контейнер для экспериментов, тестирования, или во время обучения.
730 часов в среднем в месяц получается при расчете 365 (дней) * 24 (часа) / 12 (месяцев).
Под информационными системами с российским владельцем мы имеем в виду VK ID, Я.ID или Сбер.ID. Доверять аутентификацию своих пользователей конкурентам — не самая удачная идея.
Кроме того, важно учитывать, что на нас, как на хостинг, распространяются требования по обязательной идентификации клиентов.
Минцифры утвердило такие способы:
через Единую систему идентификации и аутентификации (ЕСИА) и Единую биометрическую систему (ЕБС);
с использованием усиленной квалифицированной электронной подписи;
после предъявления при личном обращении к провайдеру хостинга определённого набора документов;
посредством перевода денежных средств на банковский счёт провайдера хостинга с банковского счёта лица, обратившегося к провайдеру хостинга, открытого в банке РФ в соответствии с требованиями законодательства:
через иную информационную систему, используемую провайдером хостинга и обеспечивающую идентификацию;
с использованием платёжной карты;
с использованием абонентского номера;
с использованием сервиса быстрых платежей (СБП).
Подробнее можно почитать тут: https://habr.com/ru/news/766708/
Интеграция любого из этих способов в UX-сценарий, чтобы система оставалась удобной и понятной для пользователей, — отдельная задача, требующая дополнительных ресурсов на разработку.
При этом вход по смс сегодня остается стандартным и привычным вариантом.
Ваш комментарий по способам входа мы отметили для себя, и, как любое пожелание пользователя, будем держать на виду при проектировании. Спасибо за ваше внимание!
Мы ваш проект всесторонне проанализировали после ваших ноябрьских публикаций. Как и при анализе других облачных провайдеров для нашего IaaS-проекта, мы уделяем внимание разным аспектам, включая наличие собственной инфраструктуры.
Речь как раз не столько про ЦОД, сколько про собственную инфраструктуру.
Функционал платформы — это абстрагированное отражение ее инфраструктуры. Хочется понимать, насколько надежно базовое решение, на котором работает платформа.
Это уже вопрос вашей ответственности перед конечным пользователем. Насколько вы надежны как бизнес? Сложно однозначно ответить на этот вопрос утвердительно, если вы используете исключительно арендованную инфраструктуру.
Мы стараемся максимально абстрагировать конечного пользователя от содержимого под нашим капотом. Сейчас система переваривает синтаксис Docker Compose, в работе — поддержка YAML Config для Kubernetes и Helm Chart.
Этот функционал планируется как часть платформы, но пока даже не начинали работу — это не типичный сценарий. Тем не менее, ничего не мешает использовать в качестве входной точки контейнер с NGinx или Kong и настроить их как душе угодно.
Конечно. На данный момент потребуется IPv4 (в работе — функционал подключения любого домена без выделенного IP).
Пока ситуация аналогична Gateway: этот функционал не встроен в платформу. Однако никто не мешает поднять ELK, Prometheus, Grafana и вообще все, что душе угодно.
Есть вертикальный, если не задать лимит ресурсов. Также можно задать несколько реплик и менять их количество на ходу. Для автоматизации горизонтального скейлинга готовим пользовательские сценарии.
Сетевые тома есть. Снепшоты находятся в разработке, резервного копирования нет, но с учетом резервирования и снепшотов оно не критично.
Нет. Спасибо за предметные вопросы. Сейчас перед нами десятки фич, поэтому важно правильно расставить приоритеты, какие из них нужнее.
Обязательно. Сейчас мы предлагаем максимально простой опыт: Docker Compose -> deply (понятно по видео).
Все, что вы описали, относится к продвинутым настройкам для развертывания. Многим пользователям потребуется время, чтобы освоить их. Мы хотим сохранить баланс между простотой интерфейса и гибкостью настроек, чтобы сделать платформу удобной как для новичков, так и для опытных разработчиков.
Каждый из описанных сценариев требует значительных усилий (кроме, возможно, версионирования) и нескольких спринтов на реализацию. Поэтому мы рассчитываем на помощь сообщества — ваша обратная связь поможет нам приоритизировать задачи и создать действительно полезный инструмент.
Спасибо за идею! Это в наших планах — внедрить поддержку IPv6 и предоставлять их бесплатно.
Незадолго до запуска мы провели анализ рынка облачных провайдеров и проверили тезис о том, что мы — первый контейнерный хостинг.
В статье упоминалось, что есть несколько хостингов, предлагающих запуск контейнеров, но как дополнение к VPS.
Amvera мы не учитывали, поскольку они больше ориентированы на запуск вашего кода (из гита) внутри контейнера с фиксированным тарифом. Они и сами позиционируют себя как DevOps-платформа.
dockerhosting.ru, который размещается на чужом хостинге, мы в расчет брать не стали. Мы не нашли информацию о юридическом лице, а их три тарифа с фиксированной оплатой больше напоминают классические VPS, только сбоку.
Ваш проект, dockerhost.ru, мы тоже изучали. Как и dockerhosting.ru, он немного не дотягивает до полноценного провайдера, так как опирается на инфраструктуру Selectel вместо собственной.
Так что всё по факту: первые!
Да, каждому контейнеру можно задать предел выделяемых ресурсов и впоследствии менять его на ходу.
В биллинге отображается полная детализация потребления.
Идею с гарантиями общего лимита ресурсов для проекта взяли на вооружение, спасибо!
1. Отдали в разработку, уже фиксим.
2. Исправили, спасибо!