Особенно в стоимости оперативного решения проблем.
Почему? Почему с платформой (я больше про всякие OpenShift, а не облачные KaaS'ы) и поддержкой от вендора проблемы решать дольше/дороже, чем в самодельных инсталляциях Kubernetes?
Стоимость миграции — более очевидный, но всё-таки тоже спорный вопрос. Мигрировать с кастомных инсталляций, когда они разрослись (обросли кучей своих автоматизаций и удобств), на что угодно другое — это вовсе не простая (не дешёвая) операция :-)
чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках
По нашему опыту, обслуживание KaaS'ов вовсе не является таким простым и дешёвым, как в случае зрелой платформы. А чем дольше проект их использует, тем больше завязывается на специфику того, с чего потом больно уходить…
А разве готовые платформы это не делают? Упрощение и улучшение пользовательского опыта и фич (для конечных пользователей). А то, что там внутри этой платформы, остаётся на откуп вендорам. Это стоит денег, но не согласен, что дешевле получать "граблями в лоб". Точнее, свои грабли могут быть дешевле до определенной точки размеров/зрелости бизнеса, при достижении которой каждый простой обходится сильно дороже готового продукта/его поддержки.
в английском языке нет наших падежей и нелепо выглядит попытка прикрутить изменённые окончания
Не согласен с вами. В английском не склоняются существительные, но в русском языке этому правилу лучше следовать. Пусть многие в техническое среде так не делают, это явление — оно вовсе не о правилах и красоте речи...
«Я купил Tesla»/«Я еду на Tesla» или «Я купил Теслу»/«Я еду на Тесле»? Конечно, второе! Первое звучит не по-русски, а возможны случаи, когда попросту не будет передавать верный смысл/вводить в заблуждение (не зря же слова в русском языке склоняются).
Но от русскоязычного написания англоязычных названий я бы тоже воздержался. Может быть, конкретно с Теслой это ещё и прокатит, потому что уже привыкли, но вот со многими другими названиями будет больше проблем, чем пользы.
Идеальный вариант — добавлять русское существительное перед брендом, которое склонять: «Я купил машину Tesla». Но при частом употреблении может получиться довольно громоздко.
В общем, добавление русских окончаний англоязычным терминам не более нелепо, чем их употребление вовсе без окончаний.
UPD. По беглому анализу свежих данных последнего опроса от CNCF (https://github.com/cncf/surveys/tree/main/cloudnative) у меня получилось, что containerd используют в production 42% опрошенных (+25,5% пробуют), а CRI-O — менее 15% (+17,5% пробуют).
Пришел в комментарии с тем же вопросом. Кажется, что преимущество в сообществе всё-таки у containerd, а это зачастую означает, что остальные плюсы тоже скорее у него (больше юзеров - больше кейсов и исправлений, реализации запросов юзеров и т.п.). Если это не какое-то узкое/нишевое решение, конечно, но в данном случае речи об этом нет.
CRI-O - это видение Red Hat, которое пытаются сделать массовым. А containerd - реальный (действующий) выбор сообщества и индустрии. Ведущие мировые облачные провайдеры используют именно containerd. В этой таблице от Oracle можно наглядно увидеть. А здесь обсуждается вопрос потенциальной поддержки CRI-O в EKS.
$ autossh
Команда «autossh» не найдена, но может быть установлена с помощью:
sudo snap install autossh # version 1.4, or
sudo apt install autossh # version 1.4g-1
See 'snap info autossh' for additional versions.
А в чем вопрос? На комментарии к статьям, которые являются переводами от других авторов... да ещё и к старым таким статьям - отвечают с куда меньшей вероятностью...
Только вот во всем этом многообразии по-настоящему устоявшихся терминов (единых, общепринятых, универсальных) до сих пор скорее нет, чем есть. А в русскоязычном сообществе эта проблема, по моим ощущениям, не особо о(б)суждается.
Почему? Почему с платформой (я больше про всякие OpenShift, а не облачные KaaS'ы) и поддержкой от вендора проблемы решать дольше/дороже, чем в самодельных инсталляциях Kubernetes?
Стоимость миграции — более очевидный, но всё-таки тоже спорный вопрос. Мигрировать с кастомных инсталляций, когда они разрослись (обросли кучей своих автоматизаций и удобств), на что угодно другое — это вовсе не простая (не дешёвая) операция :-)
По нашему опыту, обслуживание KaaS'ов вовсе не является таким простым и дешёвым, как в случае зрелой платформы. А чем дольше проект их использует, тем больше завязывается на специфику того, с чего потом больно уходить…
А разве готовые платформы это не делают? Упрощение и улучшение пользовательского опыта и фич (для конечных пользователей). А то, что там внутри этой платформы, остаётся на откуп вендорам. Это стоит денег, но не согласен, что дешевле получать "граблями в лоб". Точнее, свои грабли могут быть дешевле до определенной точки размеров/зрелости бизнеса, при достижении которой каждый простой обходится сильно дороже готового продукта/его поддержки.
Во втором абзаце написано: "Kubernetes Enhancement Proposals (KEPs)".
Ваш комментарий — это скопированный фрагмент этой статьи 4-летней давности. Зачем?
https://en.wikipedia.org/wiki/Vanilla_software
Здесь было их сравнение.
Не согласен с вами. В английском не склоняются существительные, но в русском языке этому правилу лучше следовать. Пусть многие в техническое среде так не делают, это явление — оно вовсе не о правилах и красоте речи...
«Я купил Tesla»/«Я еду на Tesla» или «Я купил Теслу»/«Я еду на Тесле»? Конечно, второе! Первое звучит не по-русски, а возможны случаи, когда попросту не будет передавать верный смысл/вводить в заблуждение (не зря же слова в русском языке склоняются).
Но от русскоязычного написания англоязычных названий я бы тоже воздержался. Может быть, конкретно с Теслой это ещё и прокатит, потому что уже привыкли, но вот со многими другими названиями будет больше проблем, чем пользы.
Идеальный вариант — добавлять русское существительное перед брендом, которое склонять: «Я купил машину Tesla». Но при частом употреблении может получиться довольно громоздко.
В общем, добавление русских окончаний англоязычным терминам не более нелепо, чем их употребление вовсе без окончаний.
UPD. По беглому анализу свежих данных последнего опроса от CNCF (https://github.com/cncf/surveys/tree/main/cloudnative) у меня получилось, что containerd используют в production 42% опрошенных (+25,5% пробуют), а CRI-O — менее 15% (+17,5% пробуют).
На всякий случай примечание для тех, кому это может быть важно: Dragonfly — это не Open Source, а BSL (Business Source License).
Пришел в комментарии с тем же вопросом. Кажется, что преимущество в сообществе всё-таки у containerd, а это зачастую означает, что остальные плюсы тоже скорее у него (больше юзеров - больше кейсов и исправлений, реализации запросов юзеров и т.п.). Если это не какое-то узкое/нишевое решение, конечно, но в данном случае речи об этом нет.
CRI-O - это видение Red Hat, которое пытаются сделать массовым. А containerd - реальный (действующий) выбор сообщества и индустрии. Ведущие мировые облачные провайдеры используют именно containerd. В этой таблице от Oracle можно наглядно увидеть. А здесь обсуждается вопрос потенциальной поддержки CRI-O в EKS.
Наконец, containerd - это уже давно (с 2019 года) graduated project в CNCF (https://www.cncf.io/announcements/2019/02/28/cncf-announces-containerd-graduation/), а CRI-O - до сих пор incubating (https://www.cncf.io/projects/cri-o/), что подчеркивает разницу в их зрелости/принятии индустрией.
На фоне этого обоснование вашего выбора выглядит иначе. Каковы были действительные причины? :-)
Да, сильно вырос. Например, есть такая публичная информация.
2006 год указан в описании самого проекта ВсеИнструменты, это момент основания компании. А далее (в следующем абзаце) написано:
Релиз Kubernetes 1.26 отложили до 8 декабря (т.е. будет этой ночью) из-за security updates к Go (вышли версии 1.19.4 и 1.18.9).
(Это про первую часть вопроса.)
Делать SEO-тексты на Хабре прямо с ссылками на ключевых словах, ведущими на сайт компании, — это катастрофа.
А в чем вопрос? На комментарии к статьям, которые являются переводами от других авторов... да ещё и к старым таким статьям - отвечают с куда меньшей вероятностью...
Появился официальный анонс релиза в блоге проекта: Kubernetes v1.25: Combiner.
Отвечали в статье с анонсом поддержки.
Год назад на Хабре уже был обзор Lens.
По терминологии есть куда более широкий диапазон вариантов.
Только вот во всем этом многообразии по-настоящему устоявшихся терминов (единых, общепринятых, универсальных) до сих пор скорее нет, чем есть. А в русскоязычном сообществе эта проблема, по моим ощущениям, не особо о(б)суждается.