В вашей версии получается, что «правильно» реализовать Control Plane изначально проще, чем заново проектировать и заменять фундаментальную систему хранения в будущем
Имхо некорректно логический формулировать вывод «одно проще, чем другое». Это все же две совершенно ортогональные темы, логику нашего решения по каждой из них выше описал.
Но «правильность» решений на ранних этапах может оказаться иллюзорной — по мере роста облака, появления новых сценариев и изменений в индустрии может выясниться, что изначальный дизайн Control Plane требует серьёзных переделок. Как вы оцениваете риск того, что принятое сейчас архитектурное решение для Control Plane также придётся переосмыслять и переделывать с существенными затратами?
Так ровно по этому мы и начали писать cpl свой сразу, вы сами и ответили на свой вопрос про open source :). Мы уже сейчас знаем что такое современная облачная платформа и какие в ней есть сценарии, которые как раз проблематично реализовать, взяв этот самый open source. И если его все же взять на старте, то дальше, да, «переделывать с существенными затратами».
Если же говорить о том, что «свое потом тоже переделывать возможно придется». У меня и команды большой опыт построения Облачных платформ, я сам строю Облако можно сказать 3-ий раз, у многих моих коллег это тоже не первый раз. Мы довольно хорошо знаем домен и закладываемся сразу на перспективу, но даже если где-то ошибемся, то это наш код, как раз его то адаптировать в будущем будет проще.
Это компромисс между скоростью создания продукта и технологий. Построение своих вариаций distributed storage - это инженерно самая тяжелая часть, времени на реализацию и доведение до продакшен потребуется довольно много. И мы начали разрабатывать подсистемы для разных классов хранения, я это написал выше. При этом мы понимаем, что с точки зрения внедрения своих наработок мы сможем позже делать это инкрементально, не беспокоя пользователя. В частности потому что системы хранения на нижнем уровне скейлятся шардами и интерфейс взаимодействия (api) очень узкий: «положи/прочитай набор байт по ключу». Когда же мы говорим про cpl компоненты там интерфейс взаимодействие (модель данных, api) большой, сложность реализации своими силами ниже, и мы оценили что для нас doable реализовать сразу «правильно» за адекватные сроки.
Не лукавство, это стратегические соображения. В long-term с развитием рынка (в частности зрелости пользователей) в этом бизнесе «победит» тот у кого есть свой продукт, свои технологии, сильная инженерная команда. В частности, чтоб выжать максимум из железа и чтоб юнит экономика сошлась at scale, чтоб можно было дать best in class продукт за конкурентную цену. “Неважно на каком стеке внутри Облака если сервисы стабильно работают в пределах SLA” - увы, чтоб сервисы работали стабильно в пределах SLA at scale оказывается важно какой стек внутри Облака, и возможность команды его контролировать. Помимо не функциональных характеристик, стек внутри Облака определяет и то какой продукт по функциональности на нем можно построить. «Спорить» в эпистолярном жанре по сабжу на эту тему дальше не буду, как говорится, время покажет
У нас уже есть 10-ки тысяч виртуальных машин экосистемы нашего бигтеха. И как я писал выше мы строим единое решение для внутреннего клиента и внешнего. Платформа вирутализации - фундаментальный слой платформы, ошибочно рассуждать как в прикладном сервисе «когда дорастем до таких нагрузок, тогда и переделаем», увы переделки потом - это годы боли и нестабильного продукта.
Сеть это лишь самый яркий пример, влияющий на стабильность, с ней «мучаются» все игроки на рынке. Контроль над архитектурой control plane тоже существенным образом влияет на то как можно реализовать те или иные сценарии, какой уровень интеграции сервисов можно дать и тп.
В качестве самого нижнего слоя хранения в данный момент ceph и для сетевых дисков и для kv хранения в object storage. Весь metadata слой object storage уже свой. Мы начали разработку специализированных решений под разные классы хранения. Детали что и зачем мы тут делаем буду раскрыты в отдельных постах
Имхо некорректно логический формулировать вывод «одно проще, чем другое». Это все же две совершенно ортогональные темы, логику нашего решения по каждой из них выше описал.
Так ровно по этому мы и начали писать cpl свой сразу, вы сами и ответили на свой вопрос про open source :). Мы уже сейчас знаем что такое современная облачная платформа и какие в ней есть сценарии, которые как раз проблематично реализовать, взяв этот самый open source. И если его все же взять на старте, то дальше, да, «переделывать с существенными затратами».
Если же говорить о том, что «свое потом тоже переделывать возможно придется». У меня и команды большой опыт построения Облачных платформ, я сам строю Облако можно сказать 3-ий раз, у многих моих коллег это тоже не первый раз. Мы довольно хорошо знаем домен и закладываемся сразу на перспективу, но даже если где-то ошибемся, то это наш код, как раз его то адаптировать в будущем будет проще.
Это компромисс между скоростью создания продукта и технологий. Построение своих вариаций distributed storage - это инженерно самая тяжелая часть, времени на реализацию и доведение до продакшен потребуется довольно много. И мы начали разрабатывать подсистемы для разных классов хранения, я это написал выше. При этом мы понимаем, что с точки зрения внедрения своих наработок мы сможем позже делать это инкрементально, не беспокоя пользователя. В частности потому что системы хранения на нижнем уровне скейлятся шардами и интерфейс взаимодействия (api) очень узкий: «положи/прочитай набор байт по ключу». Когда же мы говорим про cpl компоненты там интерфейс взаимодействие (модель данных, api) большой, сложность реализации своими силами ниже, и мы оценили что для нас doable реализовать сразу «правильно» за адекватные сроки.
Не лукавство, это стратегические соображения. В long-term с развитием рынка (в частности зрелости пользователей) в этом бизнесе «победит» тот у кого есть свой продукт, свои технологии, сильная инженерная команда. В частности, чтоб выжать максимум из железа и чтоб юнит экономика сошлась at scale, чтоб можно было дать best in class продукт за конкурентную цену. “Неважно на каком стеке внутри Облака если сервисы стабильно работают в пределах SLA” - увы, чтоб сервисы работали стабильно в пределах SLA at scale оказывается важно какой стек внутри Облака, и возможность команды его контролировать. Помимо не функциональных характеристик, стек внутри Облака определяет и то какой продукт по функциональности на нем можно построить. «Спорить» в эпистолярном жанре по сабжу на эту тему дальше не буду, как говорится, время покажет
У нас уже есть 10-ки тысяч виртуальных машин экосистемы нашего бигтеха. И как я писал выше мы строим единое решение для внутреннего клиента и внешнего. Платформа вирутализации - фундаментальный слой платформы, ошибочно рассуждать как в прикладном сервисе «когда дорастем до таких нагрузок, тогда и переделаем», увы переделки потом - это годы боли и нестабильного продукта.
Сеть это лишь самый яркий пример, влияющий на стабильность, с ней «мучаются» все игроки на рынке. Контроль над архитектурой control plane тоже существенным образом влияет на то как можно реализовать те или иные сценарии, какой уровень интеграции сервисов можно дать и тп.
В качестве самого нижнего слоя хранения в данный момент ceph и для сетевых дисков и для kv хранения в object storage. Весь metadata слой object storage уже свой. Мы начали разработку специализированных решений под разные классы хранения. Детали что и зачем мы тут делаем буду раскрыты в отдельных постах
Да свои, опорные под Москвой, есть планы на расширение текущих и постройку новых.
Яндекс - да, о нем речь. Сбер, vk, selectel - под капотом openstack в той или иной вариации