Ох, этот рассказ тянет на отдельный доклад. Если вкратце, то мы решаем эту проблему немного иначе. Инфраструктура одна, но мы стараемся избегать единых точек отказа, без которых всё ляжет.
Делаем инфраструктуру достаточно устойчивой к отказам. Начинаем с датацентров и учений. Каждый элемент должен быть по возможности максимально автономным и устойчивым к отказам других компонентов и систем. Стажёрам я обычно это описываю как то, что вы должны писать микросервис так, чтобы он работал как та собачка.
Та собачка
Проектируем компоненты работать в рамках заданных датацентров / зон доступности (пересекается с учениями).
Там, где не можем или не хотим делать систему полокационной, она не должна быть единой точкой отказа и система должна позволять т.н. факапный режим работы. Например, если вдруг откажет git-репозиторий или CI/CD (условный Argo CD), пользователь должен иметь возможность пойти и поправить спеку напрямую в кубере. Если откажет описываемый в статье кубер (его кросслокационная инсталляция, которая в том числе позволяет описать, как размазывать сервис по нескольким локациям), то пользователь имеет возможность опять-таки пойти напрямую в конечную систему и что-то починить/поменять там напрямую. При этом мы должны думать и о восстановлении после сбоя: если пользователь что-то починил руками, то проснувшийся CI/CD не должен молча перетереть спеки каким-то новым коммитом, а должен максимально орать «эй, я вижу ручные изменения, которых нет в коде!»
Ну и остальное в таком же духе. Таким образом, мы не переходим к ситуации «если сломается наша единая инфра, то положим весь Яндекс» — у нас достаточно изоляции и резервирования, несмотря на уменьшение гранулярности.
Я уже не в первый раз вижу когда большая компания делает что то, на что я смотрю и недоумеваю «зачем».
Разумеется, большие компании это делают не от большой скуки. Основные причины бывают две: «стандартное» решение либо где-то жмёт, либо дороже. В нашем случае и то, и другое.
Одни например изобрели кубернетис для crd, контроллеры к которому депоятся «снаружи»
Вообще в контексте описываемой в посте архитектуры абсолютно неважно, где поднимать контроллеры. <дальше лирическое отступление не в тему поста, но раз уж коллега спрашивает, разверну подробнее> Если бы у нас для поднятия контейнеров использовался честный кубер с его kubelet'ами и всем прочим, то мы могли бы запустить контроллеры и там, никаких архитектурных ограничений нет. Но мы используем своё облако со своими примитивами контейнеров. Почему? По многим причинам. Одна из самых простых и очевидных — это то что максимальное количество нод, которое удалось людям в мире держать в одном kubernetes-кластере, составляет емнип примерно 30к. Потом кубер складывается. У нас это немного другие порядки. Это в том числе пример того, где большим компаниям «жмёт». Чтобы не сталкиваться с этой проблемой, в менее крупных компаниях в том числе принято каждой команде поднимать свой отдельный кубер, самостоятельно его администрировать и резвиться в нём как захочется. Это приводит к намного более сильной фрагментации и недоутилизации железа, увеличению накладных расходов на сам кубер, увеличению расходов на SRE (каждой команде надо иметь своих), т.е. это просто дорого. На наших объёмах — очень значительно.
вместо того чтобы адаптировать существующие решения например crossplane? Как будто такой подход мог быть дешевле и быстрее.
Чтобы меня потом не обвиняли, я сразу оговорюсь, что crossplane — отличная концепция, и как я и говорил в посте, во многих случаях она прекрасно подойдёт :) Сам crossplane состоит по сути из двух частей:
Providers. Они скрываются под общим зонтиком crossplane, но на самом деле по сути это фреймворк для кодогенерации и написания самодостаточных контроллеров, такой же, например, как kubebuilder. Мы использовали контроллер upjet для управления теми нашими элементами инфраструктуры, которые используют терраформ, и он нормально вписывается в нашу общую структуру. Вместе с тем основная сила crossplane тут заключается в реестре уже существующих провайдеров, а в нашем случае это не даёт профита. Для написания собственных контроллеров мы смотрели и на crossplane, и на kubebuilder, и пришли к выводу, что их добавочная польза поверх стандартного controller-runtime не очень высока и проще написать небольшую аналогичную кодогенерацию, которая будет хорошо вписываться в нашу систему сборки вместо Makefile. Там действительно на стороне провайдеров не очень много всего, это не так, что мы тут писали монструозный велосипед :)
Compositions и Claims. Это как раз кмк основная суть crossplane, обработку которой вы устанавливаете, когда устанавливаете себе crossplane в кластер. Идея хорошая, но тут они в позиции догоняющих: раньше это были сугубо статические шаблоны с простыми подстановками, которые позволяют из набора параметров срендерить несколько простых hard mode (в наших терминах) спек, где остальные параметры уже проставлены. А что, если надо что-то сложнее? Если количество создаваемых hard mode спек зависит от количества переданных параметров (например, передали список зон доступности, в которых надо развернуть копии приложение) или в срендеренной спеке надо вычислять значение параметра как сумму трёх других параметров? Поддержку composition functions в crossplane зарелизили только в конце августа. Поэтому честный ответ тут такой: если бы мы дизайнили и писали свои easy mode контроллеры сейчас, мы бы намного более пристально смотрели на crossplane, но так получилось, что мы тут уже всё написали раньше и (имхо) во многом пока ещё лучше.
И ещё дополнительно тут на всякий случай скажу, что в целом crossplane не противопоставляется всем тезисам, о которых я пишу в этой статье (скорее пересекается: они точно так же требуют блюсти обратную совместимость, например). Можно с тем же успехом реализовывать всё перечисленное и поверх crossplane.
считать всё корректно для уникода (и особенно для UTF-8) чуть менее просто.
Тут зависит от реализации. Для раста можно заменить итератор по bytes на итератор по chars и получить всё то же самое и без особой просадки производительности.
А на php с кем-то предложенным тут mb_substr это будет уже O(n⁴), потому что для взятия каждого следующего символа надо будет пробежать по всей строке.
У достаточно большого, не статический, но внешний.
Не могу сейчас найти, но был даже публичный сервис, который предлагал всем желающим ssh-нуться к ним и показывал проблемы и уязвимости вашего клиентсвкого конфига. Они как раз статистику собирали.
В очень большом проценте случаев этого достаточно, чтобы, воспользовавшись агентом, добраться до машины пользователя (где этот же ключ лежит в authorized_keys) и дальше с правами пользователя выполнить что угодно:
— стянуть приватный ключ, если он не запаролен
— прописать свой ключ в authorized_keys и ходить на пользовательскую машину пользоваться уже локальным агентом
— запустить любые туннели или сервисы
В РФ таможенная пошлина для товаров бытового назначения, полученных из заграничных интернет-магазинов, платится просто на почте при получении посылки. Никуда идти не нужно.
Так только если продавец отправляет товар обычной почтой. Если какой-нибудь более быстрой службой — всё будет уже интереснее.
(Что инетерсно тот товарищ, который source-map делает он даже написал собственный аллокатор памяти для WASM — потому что встроенный в Rust был слишком большой… ну у меня даже слов нет.)
Не знаю про ту ситуацию и не очень в курсе, как это всё работает в WASM, но возможно он просто не захотел разбираться: в расте по умолчанию используется достаточно жирный jemalloc, но вообще при компиляции можно попросить использовать обычный системный аллокатор.
Я скорее про затраты на поддержание. Легко говорить о сложностях сборки, когда сам всеми силами их избегаешь и правишь итоговый результат :)
А если честно собирать и то, и другое, то вроде так на так и выходит, наверное.
Тут надо быть немного осторожнее с утверждениями, потому что ещё в XVIII-XIX вв. свежевошедшие в язык слова «офици[н]альный», «офис» и другие писались и так, и сяк, в том числе и с двумя «ф» :) Поэтому если говорить о традиции, то там всё немного сложно.
Ну не странно ли, учитывая явно слышимое Э и иностранное происхождение слова?
Иностранные слова со звуком [э] очень часто заимствуются в русский с буквой «е» в написании: «претензия», «секс», «бутерброд». «э» пишется чаще либо в начале слова («эхо»), либо в сочетаниях с гласными («маэстро»), либо для устранения неоднозначности («мэтр»/«метр»). Впрочем, исключений в обе стороны тонны и правописание конкретно «флешки» обсуждаемо. Поиск говорит о трёхкратном превосходстве варианта «флешка» (81 млн результатов против 27 млн у «флэшка»).
Да, и он работает так же, как работают абсолютно все: генерируем си-враппер, подключаем его через FFI.
Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.
Вообще довольно странно выглядит требование работать с библиотеками на C++, учитывая то, что никто не может работать с библиотеками на C++ (даже C++):
В стандарте так и не зафиксировано, как должны выглядеть символы для классов, методов, инстанцированных шаблонов, мэнглинг может различаться в зависимости от компилятора, языка, архитектуры, чего угодно. В windows нельзя из собранного студией кода использовать dll, собранный mingw, и наоборот. Как этим должен пользоваться внешний инструмент?
Шаблоны в С++, которые хочет автор, существуют только в заголовочных файлах. Долгая затея с экспортируемыми шаблонами, введённая в 98-м стандарте, провалилась, поддержать их за десять лет смог ровно один компилятор Comeau, и в C++11 их из стандарта выкинули. Сейчас затею пытаются повторить с модулями, но чем это всё кончится, пока непонятно. Поэтому единственный способ их поддержать — самому стать компилятором C++-кода, чтобы обрабатывать заголовочные файлы с шаблонами. Затея, изначально обречённая на провал.
Ох, этот рассказ тянет на отдельный доклад. Если вкратце, то мы решаем эту проблему немного иначе. Инфраструктура одна, но мы стараемся избегать единых точек отказа, без которых всё ляжет.
Делаем инфраструктуру достаточно устойчивой к отказам. Начинаем с датацентров и учений. Каждый элемент должен быть по возможности максимально автономным и устойчивым к отказам других компонентов и систем. Стажёрам я обычно это описываю как то, что вы должны писать микросервис так, чтобы он работал как та собачка.
Та собачка
Проектируем компоненты работать в рамках заданных датацентров / зон доступности (пересекается с учениями).
Там, где не можем или не хотим делать систему полокационной, она не должна быть единой точкой отказа и система должна позволять т.н. факапный режим работы. Например, если вдруг откажет git-репозиторий или CI/CD (условный Argo CD), пользователь должен иметь возможность пойти и поправить спеку напрямую в кубере. Если откажет описываемый в статье кубер (его кросслокационная инсталляция, которая в том числе позволяет описать, как размазывать сервис по нескольким локациям), то пользователь имеет возможность опять-таки пойти напрямую в конечную систему и что-то починить/поменять там напрямую. При этом мы должны думать и о восстановлении после сбоя: если пользователь что-то починил руками, то проснувшийся CI/CD не должен молча перетереть спеки каким-то новым коммитом, а должен максимально орать «эй, я вижу ручные изменения, которых нет в коде!»
Ну и остальное в таком же духе. Таким образом, мы не переходим к ситуации «если сломается наша единая инфра, то положим весь Яндекс» — у нас достаточно изоляции и резервирования, несмотря на уменьшение гранулярности.
Google внутри себя тоже использует не кубер, а своё проприетарное облако Google Borg: https://research.google/pubs/pub43438/
Попробую ответить не буллетами, но по пунктам :)
Разумеется, большие компании это делают не от большой скуки. Основные причины бывают две: «стандартное» решение либо где-то жмёт, либо дороже. В нашем случае и то, и другое.
Вообще в контексте описываемой в посте архитектуры абсолютно неважно, где поднимать контроллеры. <дальше лирическое отступление не в тему поста, но раз уж коллега спрашивает, разверну подробнее> Если бы у нас для поднятия контейнеров использовался честный кубер с его kubelet'ами и всем прочим, то мы могли бы запустить контроллеры и там, никаких архитектурных ограничений нет. Но мы используем своё облако со своими примитивами контейнеров. Почему? По многим причинам. Одна из самых простых и очевидных — это то что максимальное количество нод, которое удалось людям в мире держать в одном kubernetes-кластере, составляет емнип примерно 30к. Потом кубер складывается. У нас это немного другие порядки. Это в том числе пример того, где большим компаниям «жмёт». Чтобы не сталкиваться с этой проблемой, в менее крупных компаниях в том числе принято каждой команде поднимать свой отдельный кубер, самостоятельно его администрировать и резвиться в нём как захочется. Это приводит к намного более сильной фрагментации и недоутилизации железа, увеличению накладных расходов на сам кубер, увеличению расходов на SRE (каждой команде надо иметь своих), т.е. это просто дорого. На наших объёмах — очень значительно.
Чтобы меня потом не обвиняли, я сразу оговорюсь, что crossplane — отличная концепция, и как я и говорил в посте, во многих случаях она прекрасно подойдёт :) Сам crossplane состоит по сути из двух частей:
Providers. Они скрываются под общим зонтиком crossplane, но на самом деле по сути это фреймворк для кодогенерации и написания самодостаточных контроллеров, такой же, например, как kubebuilder. Мы использовали контроллер upjet для управления теми нашими элементами инфраструктуры, которые используют терраформ, и он нормально вписывается в нашу общую структуру. Вместе с тем основная сила crossplane тут заключается в реестре уже существующих провайдеров, а в нашем случае это не даёт профита. Для написания собственных контроллеров мы смотрели и на crossplane, и на kubebuilder, и пришли к выводу, что их добавочная польза поверх стандартного controller-runtime не очень высока и проще написать небольшую аналогичную кодогенерацию, которая будет хорошо вписываться в нашу систему сборки вместо Makefile. Там действительно на стороне провайдеров не очень много всего, это не так, что мы тут писали монструозный велосипед :)
Compositions и Claims. Это как раз кмк основная суть crossplane, обработку которой вы устанавливаете, когда устанавливаете себе crossplane в кластер. Идея хорошая, но тут они в позиции догоняющих: раньше это были сугубо статические шаблоны с простыми подстановками, которые позволяют из набора параметров срендерить несколько простых hard mode (в наших терминах) спек, где остальные параметры уже проставлены. А что, если надо что-то сложнее? Если количество создаваемых hard mode спек зависит от количества переданных параметров (например, передали список зон доступности, в которых надо развернуть копии приложение) или в срендеренной спеке надо вычислять значение параметра как сумму трёх других параметров? Поддержку composition functions в crossplane зарелизили только в конце августа. Поэтому честный ответ тут такой: если бы мы дизайнили и писали свои easy mode контроллеры сейчас, мы бы намного более пристально смотрели на crossplane, но так получилось, что мы тут уже всё написали раньше и (имхо) во многом пока ещё лучше.
И ещё дополнительно тут на всякий случай скажу, что в целом crossplane не противопоставляется всем тезисам, о которых я пишу в этой статье (скорее пересекается: они точно так же требуют блюсти обратную совместимость, например). Можно с тем же успехом реализовывать всё перечисленное и поверх crossplane.
Тут зависит от реализации. Для раста можно заменить итератор по bytes на итератор по chars и получить всё то же самое и без особой просадки производительности.
А на php с кем-то предложенным тут mb_substr это будет уже O(n⁴), потому что для взятия каждого следующего символа надо будет пробежать по всей строке.
Вот так, читая про духовку, я узнал, как чинить свой холодильник)
Не могу сейчас найти, но был даже публичный сервис, который предлагал всем желающим ssh-нуться к ним и показывал проблемы и уязвимости вашего клиентсвкого конфига. Они как раз статистику собирали.
— стянуть приватный ключ, если он не запаролен
— прописать свой ключ в authorized_keys и ходить на пользовательскую машину пользоваться уже локальным агентом
— запустить любые туннели или сервисы
Так только если продавец отправляет товар обычной почтой. Если какой-нибудь более быстрой службой — всё будет уже интереснее.
И этот большой аллокатор написан авторами wasm32-unknown-emscripten-тулчейна, понятно.
Не знаю про ту ситуацию и не очень в курсе, как это всё работает в WASM, но возможно он просто не захотел разбираться: в расте по умолчанию используется достаточно жирный jemalloc, но вообще при компиляции можно попросить использовать обычный системный аллокатор.
А если честно собирать и то, и другое, то вроде так на так и выходит, наверное.
Но ведь если я правильно понял статью, Вы тоже напрямую редактировали сгенерированный код, чтобы не возиться с пересборкой?
Иностранные слова со звуком [э] очень часто заимствуются в русский с буквой «е» в написании: «претензия», «секс», «бутерброд». «э» пишется чаще либо в начале слова («эхо»), либо в сочетаниях с гласными («маэстро»), либо для устранения неоднозначности («мэтр»/«метр»). Впрочем, исключений в обе стороны тонны и правописание конкретно «флешки» обсуждаемо. Поиск говорит о трёхкратном превосходстве варианта «флешка» (81 млн результатов против 27 млн у «флэшка»).
Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.
Вообще довольно странно выглядит требование работать с библиотеками на C++, учитывая то, что никто не может работать с библиотеками на C++ (даже C++):