Комментарии 13
Ключевые технологии нужно создавать самостоятельно. С такой позиции в России у нас есть только один конкурент, и сделать облако не хуже, а то и лучше, — неплохая мотивация для того, чтобы вписаться в эту историю именно сейчас.
Точно один конкурент? Яндекс, Сбер, mail.ru cloud и Selectel пишут свои облачные платформы, а не используют готовые вендорские платформы. Так что конкурентов должно быть точно больше одного.
А датацентры у вас свои, или арендуете пространство у третьих лиц?
Проект выглядит мертворожденным.
Во первых очевидное лукавство - конкурировать все таки придется со всеми российскими провайдерами - абсолютному большинству клиентов не важно, какой технологический стек внутри облака - если сервисы стабильно работают в пределах SLA. Большинство провайдеров - аффилированны с клиентами и готовы демпенговать по ценам => переманить клиентскую базу на новую платформу будет крайне сложно
Во вторых завяление о проблемах с масштабированием и ненадежностью сети в OpenStack - для того чтобы столкнуться с проблемами масштабирования даже в стандартной инсталляции с Neutron - нужно иметь десятки тысяч клиентских виртуальных машин в облаке. У вас уже есть такая клиентская база в паблике?
Третье - отсутствие логической связи между заявлением о том, что в стандартных сетевых плагинах OpenStack есть проблемы с масштабированием - и необходимостью писать вообще весь control plane с нуля.
Ну и даже если согласиться со всей этой логикой отказа от открытого ПО в инфраструктуре облака - тогда вопрос - а на чем реализовано SDS и Object Storage? Пишете сами? Или все же там какой нибудь Ceph?
Но! Как pet-project на деньги бигтеха - опыт наверняка интересный )
Не лукавство, это стратегические соображения. В long-term с развитием рынка (в частности зрелости пользователей) в этом бизнесе «победит» тот у кого есть свой продукт, свои технологии, сильная инженерная команда. В частности, чтоб выжать максимум из железа и чтоб юнит экономика сошлась at scale, чтоб можно было дать best in class продукт за конкурентную цену. “Неважно на каком стеке внутри Облака если сервисы стабильно работают в пределах SLA” - увы, чтоб сервисы работали стабильно в пределах SLA at scale оказывается важно какой стек внутри Облака, и возможность команды его контролировать. Помимо не функциональных характеристик, стек внутри Облака определяет и то какой продукт по функциональности на нем можно построить. «Спорить» в эпистолярном жанре по сабжу на эту тему дальше не буду, как говорится, время покажет
У нас уже есть 10-ки тысяч виртуальных машин экосистемы нашего бигтеха. И как я писал выше мы строим единое решение для внутреннего клиента и внешнего. Платформа вирутализации - фундаментальный слой платформы, ошибочно рассуждать как в прикладном сервисе «когда дорастем до таких нагрузок, тогда и переделаем», увы переделки потом - это годы боли и нестабильного продукта.
Сеть это лишь самый яркий пример, влияющий на стабильность, с ней «мучаются» все игроки на рынке. Контроль над архитектурой control plane тоже существенным образом влияет на то как можно реализовать те или иные сценарии, какой уровень интеграции сервисов можно дать и тп.
В качестве самого нижнего слоя хранения в данный момент ceph и для сетевых дисков и для kv хранения в object storage. Весь metadata слой object storage уже свой. Мы начали разработку специализированных решений под разные классы хранения. Детали что и зачем мы тут делаем буду раскрыты в отдельных постах
Вы говорите о стратегической важности полного контроля над стеком. Но почему тогда в качестве основы для хранения выбрали Ceph, а не стали разрабатывать систему хранения с нуля сразу? Если определённые компоненты можно брать готовыми, почему не использовать такую же логику для Control Plane с модификациями поверх OpenStack или других платформ?
Это компромисс между скоростью создания продукта и технологий. Построение своих вариаций distributed storage - это инженерно самая тяжелая часть, времени на реализацию и доведение до продакшен потребуется довольно много. И мы начали разрабатывать подсистемы для разных классов хранения, я это написал выше. При этом мы понимаем, что с точки зрения внедрения своих наработок мы сможем позже делать это инкрементально, не беспокоя пользователя. В частности потому что системы хранения на нижнем уровне скейлятся шардами и интерфейс взаимодействия (api) очень узкий: «положи/прочитай набор байт по ключу». Когда же мы говорим про cpl компоненты там интерфейс взаимодействие (модель данных, api) большой, сложность реализации своими силами ниже, и мы оценили что для нас doable реализовать сразу «правильно» за адекватные сроки.
В вашей версии получается, что «правильно» реализовать Control Plane изначально проще, чем заново проектировать и заменять фундаментальную систему хранения в будущем. Но «правильность» решений на ранних этапах может оказаться иллюзорной — по мере роста облака, появления новых сценариев и изменений в индустрии может выясниться, что изначальный дизайн Control Plane требует серьёзных переделок. Как вы оцениваете риск того, что принятое сейчас архитектурное решение для Control Plane также придётся переосмыслять и переделывать с существенными затратами? Предусмотрена ли какая-то модульность или абстракция, позволяющая адаптироваться к новым требованиям без корневой реконструкции?
В вашей версии получается, что «правильно» реализовать Control Plane изначально проще, чем заново проектировать и заменять фундаментальную систему хранения в будущем
Имхо некорректно логический формулировать вывод «одно проще, чем другое». Это все же две совершенно ортогональные темы, логику нашего решения по каждой из них выше описал.
Но «правильность» решений на ранних этапах может оказаться иллюзорной — по мере роста облака, появления новых сценариев и изменений в индустрии может выясниться, что изначальный дизайн Control Plane требует серьёзных переделок. Как вы оцениваете риск того, что принятое сейчас архитектурное решение для Control Plane также придётся переосмыслять и переделывать с существенными затратами?
Так ровно по этому мы и начали писать cpl свой сразу, вы сами и ответили на свой вопрос про open source :). Мы уже сейчас знаем что такое современная облачная платформа и какие в ней есть сценарии, которые как раз проблематично реализовать, взяв этот самый open source. И если его все же взять на старте, то дальше, да, «переделывать с существенными затратами».
Если же говорить о том, что «свое потом тоже переделывать возможно придется». У меня и команды большой опыт построения Облачных платформ, я сам строю Облако можно сказать 3-ий раз, у многих моих коллег это тоже не первый раз. Мы довольно хорошо знаем домен и закладываемся сразу на перспективу, но даже если где-то ошибемся, то это наш код, как раз его то адаптировать в будущем будет проще.
Позвольте уточнить несколько моментов, поскольку, судя по всему, возникло лёгкое недопонимание того, что я имел в виду:
«Ортогональность» тем Control Plane и системы хранения
Вы пишете, что «логически некорректно формулировать вывод, что одно проще, чем другое», и считаете их «ортогональными». Однако в предыдущих сообщениях (и статье) фактически прозвучало противопоставление: мол, строить собственный Control Plane сразу «адекватно», а систему хранения можно пока взять готовую (Ceph), а потом заменить.
Я не утверждал, что это «одна и та же» задача. Скорее, хотел показать: с точки зрения рисков и долгосрочных затрат обе области (Control Plane и Storage) критичны для облака. При этом в статье вы выбрали разные стратегии: Control Plane — полностью свой, систему хранения — временно стороннюю. Поэтому возникает логичный вопрос: почему одну «боль» вы решаете сразу с нуля, а вторую предпочитаете отложить, хотя в обоих случаях потенциально масштабные переделки чреваты большими усилиями?
Проблема «иллюзорной правильности» на старте
Мы говорили не о том, что «open source» изначально хуже, а о том, что любая архитектура, принятная на ранних этапах, может столкнуться с новыми сценариями, которые поначалу не были учтены. На практике есть масса примеров, когда даже собственный код, написанный опытными инженерами, нуждается в глубокой переделке при изменении рыночных условий или добавлении новых сервисов.
Ваш ответ сводится к тезису «мы имеем достаточный опыт и лучше понимаем домен, поэтому код будет проще адаптировать». Но опыт, безусловно, снижает риски, хотя и не обнуляет их. Остаётся открытым вопрос: какие именно механизмы модульности или абстракции вы закладываете, чтобы эти будущие изменения не привели к «годам боли»? Ведь даже с крутой командой нельзя предусмотреть абсолютно всё.
Свобода в будущем vs. Сложность текущей разработки
Вы уверены, что собственный Control Plane будет проще адаптировать, поскольку «это ваш код». Понятно, что отсутствие жёсткой привязки к чужой roadmap даёт свободу — но часто «самописные» решения по мере роста обрастают своими уникальными ограничениями и техническим долгом.
В open source-комьюнити много контрибуций и патчей, появляются новые фичи или паттерны, которые можно относительно легко «подтянуть». В случае полностью самописного Control Plane всё придётся делать силами своей команды. Это не всегда быстрее или дешевле, даже если команда «строит облако в третий раз».
Хотелось бы узнать, как вы будете оценивать целесообразность «подтягивать» некие сторонние компоненты, если технологический ландшафт изменится (например, появятся новые подходы к сетевой виртуализации или диспетчеризации ресурсов)?
Двойная логика выбора
Вы пишите, что OpenStack «проблемно адаптировать» под современные сценарии, поэтому сразу от него отказались; одновременно вы взяли Ceph с прицелом «потом спокойно перепишем, когда созреем». Но ведь Ceph — это тоже open source, со своими нетривиальными ограничениями.
Получается, что в одном случае (Control Plane) вас не устраивает необходимость глубоких доработок, поэтому делаете всё «под себя» здесь и сейчас.
В другом случае (Storage) та же самая проблема не воспринимается как блокирующая. При этом Ceph — довольно «тяжёлое» решение, которое тоже потребует немало усилий при интеграции и дальнейшей замене.
Именно поэтому у стороннего читателя может сложиться впечатление, что вы противопоставляете «сделать сразу правильно» и «взять что-то готовое с доработкой потом», хотя для обеих задач (Control Plane и Storage) риски похожи. Отсюда и наш первоначальный вопрос — как именно вы оцениваете риски долгосрочных переделок в собственном коде, и почему считаете, что этот риск меньше, чем при использовании open source-платформы (для Control Plane), но при этом нормальный для Ceph (Storage)?
Ваш опыт и экспертиза, несомненно, повышают шансы, что архитектура Control Plane будет продумана и более гибкая изначально.
Однако хочется понять, какие конкретные архитектурные паттерны или процессы (модульность, ревизия API, планирование backward-совместимых изменений и т. д.) вы используете, чтобы «фундамент» Control Plane не пришлось перелопачивать через пару лет с не меньшими издержками, чем при отказе от open source.
Надеюсь, удалось прояснить, что я не пытаюсь смешать в одну кучу две разных задачи, а скорее уточнить вашу логику по обеим направлениям. Ведь цель дискуссии — разобрать возможные технические и стратегические риски, чтобы чётче понимать, как вы пришли к нынешней архитектуре.
Принято решение что в облаке важнее control plane.
Есть компании, которые решили что строить свой storage - лучше. YADRO и другие. Можно так же придти к ним и спросить "зачем вы пишете свой storage, а не систему управления облаком" :)
Просто кто-то строил облако пару раз, кто-то эксперт в данных. Имея большой объем железа и желание построить из него облако - было бы странно сначала приниматься за storage.
Однако хочется понять, какие конкретные архитектурные паттерны или процессы
Следите за блогом компании и MTS True Tech - там про многое рассказано и будет дополняться.
Как мы строим публичное облако с нуля: опыт MWS