Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже. Мозилла не только перевела команду Rust в режим выживания поувольняв часть сотрудников, но еще и избавилась от главного паровоза этого прекрасного языка — Servio, сдав его на кладбище.
Как считаете, D теперь не будет так грустно и одиноко?
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже. Мозилла не только перевела команду Rust в режим выживания поувольняв часть сотрудников, но еще и избавилась от главного паровоза этого прекрасного языка — Servio, сдав его на кладбище.
KP>Как считаете, D теперь не будет так грустно и одиноко?
Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко.
Не хочется, чтобы веб стал chrome-only.
Здравствуйте, ltc, Вы писали:
ltc>Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко.
Я их ещё после их фокуса с Quantum списал в утиль. Они тогда убили всё то, что делало FF — FF.
ltc>Не хочется, чтобы веб стал chrome-only.
Увы...
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже. Мозилла не только перевела команду Rust в режим выживания поувольняв часть сотрудников, но еще и избавилась от главного паровоза этого прекрасного языка — Servio, сдав его на кладбище.
С чего ты взял, что Servo был паровозом? Он мне всегда казался странным проектом, никому особо не нужным. Делать движок, на который никто переходить не собирается и в лучшем случае какие-то его куски будут дёргать в фаерфокс.
В целом не думаю, что именно Rust-у что-то угрожает. Он давным давно перерос мозиллу. Ты лучше расскажи, как в амазоне применяют Rust. Широко ли. Будет ли амазон донатить на разработку Rust?
Здравствуйте, ltc, Вы писали:
ltc>Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко. ltc>Не хочется, чтобы веб стал chrome-only.
На третий день Орлиный Глаз заметил, что у сарая нет одной стены.
Веб уже давно стал Chrome-only. Ну ладно, Chrome + Safari -only, если их разделять. Фаерфокс уже давно стал нерелевантен, к сожалению.
Здравствуйте, vsb, Вы писали:
vsb>С чего ты взял, что Servo был паровозом? Он мне всегда казался странным проектом, никому особо не нужным. Делать движок, на который никто переходить не собирается и в лучшем случае какие-то его куски будут дёргать в фаерфокс.
А разве не Мозилла была основным спонсором для Rust? Ну а затеяли они Rust вроде потому, что не осилили C++ и движек вечно тёк. Не?
vsb>В целом не думаю, что именно Rust-у что-то угрожает. Он давным давно перерос мозиллу. Ты лучше расскажи, как в амазоне применяют Rust. Широко ли. Будет ли амазон донатить на разработку Rust?
А причем тут я и Амазон? Я только про Motional могу рассказать. Никак не применяется и не будет применяться
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже.
Было очевидно что так оно и будет, хотя из статьи не видно что растукапец уже настал.
KP>Как считаете, D теперь не будет так грустно и одиноко?
А что такое D?
Здравствуйте, CreatorCray, Вы писали:
CC> ltc>Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко. CC> Я их ещё после их фокуса с Quantum списал в утиль. Они тогда убили всё то, что делало FF — FF.
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже. Мозилла не только перевела команду Rust в режим выживания поувольняв часть сотрудников, но еще и избавилась от главного паровоза этого прекрасного языка — Servio, сдав его на кладбище.
KP>Как считаете, D теперь не будет так грустно и одиноко?
Здравствуйте, kaa.python, Вы писали:
vsb>>С чего ты взял, что Servo был паровозом? Он мне всегда казался странным проектом, никому особо не нужным. Делать движок, на который никто переходить не собирается и в лучшем случае какие-то его куски будут дёргать в фаерфокс.
KP>А разве не Мозилла была основным спонсором для Rust? Ну а затеяли они Rust вроде потому, что не осилили C++ и движек вечно тёк. Не?
Ну это как джаву задумали для того, чтобы программировать кофеварки. Элементы истории. Сейчас Rust, насколько я знаю, выделился в отдельную Rust foundation.
vsb>>В целом не думаю, что именно Rust-у что-то угрожает. Он давным давно перерос мозиллу. Ты лучше расскажи, как в амазоне применяют Rust. Широко ли. Будет ли амазон донатить на разработку Rust?
KP>А причем тут я и Амазон? Я только про Motional могу рассказать. Никак не применяется и не будет применяться
Почему-то думал, ты в Амазоне работаешь, видимо с кем-то спутал.
Здравствуйте, vsb, Вы писали:
vsb>Веб уже давно стал Chrome-only. Ну ладно, Chrome + Safari -only, если их разделять. Фаерфокс уже давно стал нерелевантен, к сожалению.
А я использую Firefox Quantum. Google ограничивают плагины своей политикой, потому пришлось отказаться от Chromium.
Здравствуйте, vsb, Вы писали:
vsb>Ну это как джаву задумали для того, чтобы программировать кофеварки. Элементы истории. Сейчас Rust, насколько я знаю, выделился в отдельную Rust foundation.
Да много что выделялось, чаще всего это было синонимо "на кладбище".
vsb>Почему-то думал, ты в Амазоне работаешь, видимо с кем-то спутал.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AleksandrN, Вы писали:
AN>>Ещё один язык программирования, созданный как замена C++. K>Ты понимаешь что это был сарказм? Я осведомлён о существовании D, но на нём никто не пишет как и такой штуке как OCaml, например.
Еще как пишут, у нас тут вроде D. Mon таким занимается. И на OCaml пишут, в Синге (не самое IT-есто на земле) внезапно есть стратап у которого стек это Rust+OCaml. В более продвинутых местах думаю должно быть больше
И, если уж говорить про Rust, то POC версия компилятора был на OCaml, что разумно, при том на сколько там развиты инстументы для написания парсеров всего и вся.
Здравствуйте, CreatorCray, Вы писали:
ltc>>Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко. CC>Я их ещё после их фокуса с Quantum списал в утиль. Они тогда убили всё то, что делало FF — FF.
Здравствуйте, vsb, Вы писали:
vsb>Веб уже давно стал Chrome-only. Ну ладно, Chrome + Safari -only, если их разделять. Фаерфокс уже давно стал нерелевантен, к сожалению.
В смысле? Я вот ничем другим кроме как Firefox не пользуюсь уже лет -нцать.
KP>Еще как пишут, у нас тут вроде D. Mon таким занимается. И на OCaml пишут, в Синге (не самое IT-есто на земле) внезапно есть стратап у которого стек это Rust+OCaml. В более продвинутых местах думаю должно быть больше KP>И, если уж говорить про Rust, то POC версия компилятора был на OCaml, что разумно, при том на сколько там развиты инстументы для написания парсеров всего и вся.
Как-то не впечатляет история успеха — https://ocaml.org/learn/success.html
А если Jane Street обанкротится, то OCaml окончательно встретится с D
Здравствуйте, Максим, Вы писали:
М>Как-то не впечатляет история успеха — https://ocaml.org/learn/success.html М>А если Jane Street обанкротится, то OCaml окончательно встретится с D
В целом я согласен ситуация там так себе, и брать OCaml для чего-то большего чем POC так себе идея. Если хочется компилируемой функциональщины в проде, то только хардкор — только Haskell. Он то никогда не помрет, как и какой-нибудь C++
Здравствуйте, vsb, Вы писали:
ltc>>Не хочется, чтобы веб стал chrome-only.
vsb>На третий день Орлиный Глаз заметил, что у сарая нет одной стены.
vsb>Веб уже давно стал Chrome-only. Ну ладно, Chrome + Safari -only, если их разделять. Фаерфокс уже давно стал нерелевантен, к сожалению.
Может ты и прав, я далек от веб-дева. Понятно, что фаерфокс давно уже не составляет реальной конкуренции хрому в плане рыночной доли, но хочется надеяться, что разработчики стандартов, фреймворков, да и просто сайтов все-таки учитывают существование мозиллы.
Здравствуйте, ltc, Вы писали:
ltc>Может ты и прав, я далек от веб-дева. Понятно, что фаерфокс давно уже не составляет реальной конкуренции хрому в плане рыночной доли, но хочется надеяться, что разработчики стандартов, фреймворков, да и просто сайтов все-таки учитывают существование мозиллы.
Обычные разработчики в массе своей не учитывают. Ситуацию спасает лишь то, что современные стандарты довольно хороши и написать код, который не будет работать в фаерфоксе, но будет работать в хроме, не так уж и просто.
Здравствуйте, Dair, Вы писали:
vsb>>Веб уже давно стал Chrome-only. Ну ладно, Chrome + Safari -only, если их разделять. Фаерфокс уже давно стал нерелевантен, к сожалению.
D>В смысле? Я вот ничем другим кроме как Firefox не пользуюсь уже лет -нцать.
Здравствуйте, Dair, Вы писали:
D>В смысле? Я вот ничем другим кроме как Firefox не пользуюсь уже лет -нцать.
Либо у тебя безразмерное терпение, либо у твоего железа безразмерные ресурсы. Огнелис после 26-й версии скатился в... в... В общем, пришлось его заменить.
Здравствуйте, dsorokin, Вы писали:
D>Не заметил, чтобы что-то изменилось для Rust. Поживает, как и поживал до этого. Короче, "не дождетесь"!
Мы уже даже на могилке самого лучшего языка на свете на букву N, и заканчивающегося на мерле, поплясать успели. Так что, всё может быть, я бы не был таким пессимистичным
Здравствуйте, Privalov, Вы писали:
P>Либо у тебя безразмерное терпение, либо у твоего железа безразмерные ресурсы. Огнелис после 26-й версии скатился в... в... В общем, пришлось его заменить.
Да примерно та же фигня, что и Хром.
Здравствуйте, kaa.python, Вы писали:
KP>Мы уже даже на могилке самого лучшего языка на свете на букву N, и заканчивающегося на мерле, поплясать успели. Так что, всё может быть, я бы не был таким пессимистичным
Здравствуйте, vsb, Вы писали:
vsb>Обычные разработчики в массе своей не учитывают. Ситуацию спасает лишь то, что современные стандарты довольно хороши и написать код, который не будет работать в фаерфоксе, но будет работать в хроме, не так уж и просто.
Да ладно? Современные фронтэндеры кроме хрома вообще другие браузеры не рассматривают и кроме хрома хрен где работает. Как минимум UI для кубернейтс какой то из прошлых версий работает только на хроме. Обновимся на более новую, там обещают что и в файрфоксе заработает.
Развитие языка зависит не только от того, кто его использует, но и от того, сколько денег готовы давать разработчикам языка. А вот со спонсорами у Rust Foundation, после того как начались финансовые проблемы у Mozilla, как-то не очень — https://www.rust-lang.org/sponsors
1Password is providing a free 1Password Teams subscription to the Rust Team, used to store and share secrets between team members.
Google Cloud is providing support for the Rust Project by helping prevent compiler regressions with Crater.
ARM is providing builders for Rust’s CI infrastructure to test the compiler on AArch64.
Здравствуйте, Максим, Вы писали:
М>Развитие языка зависит не только от того, кто его использует, но и от того, сколько денег готовы давать разработчикам языка.
Часто эти сами разработчики трудоустроены там, где Rust используют. Например, один из самых продуктивных разработчиков (на мой взгляд -- прим.) библиотек для Rust (практически все библиотеки "enterprise" уровня от него) работает в Facebook. У нас работает разработчик компилятора, который активно работает над эргономикой ошибок (окей, со следующей недели уже не работает ).
Async, по-моему, активно спонсировался кем-то вне Mozilla. Возможно, Google.
Здравствуйте, rudzuk, Вы писали:
R>Quantum — лучшее, что случилось с FF.
Я перестал пользоваться FF после этого.
Когда они просто похерили половину плагинов, ради которых я и держал FF и стали выглядеть как хром я просто поставил хром.
Здравствуйте, Privalov, Вы писали:
P>Плюс Хром обновлялся, когда хотел. И разрешения не спрашивал. Просто пихал задачу в планировщик.
Это легко отламывается.
ltc>>Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко. CC>Я их ещё после их фокуса с Quantum списал в утиль. Они тогда убили всё то, что делало FF — FF.
Жуткие тормоза?
E>Да ладно? Современные фронтэндеры кроме хрома вообще другие браузеры не рассматривают и кроме хрома хрен где работает. Как минимум UI для кубернейтс какой то из прошлых версий работает только на хроме. Обновимся на более новую, там обещают что и в файрфоксе заработает.
вот сейчас обидно было
p.s. поговаривают, что страшный суд отменили и вместо этого человечеству прислали кубер. в рамках этой версии хром-онли смотрится органично
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже.
Чему радоваться-то? Очень интересный проект.
Как язык — на мой взгляд, чрезмерно сложный. Думается, что можно было б сделать те же вещи проще для использования. Но более интересен сам эксперимент по предотвращению целых классов болезненных ошибок ещё на этапе компиляции.
Такие эксперименты занимают долгое время и хочется думать, что ещё лет через 15 появится какой-нибудь "Rust с человеческим лицом", которым можно будет пользоваться без нервных тиков и слёз на глазах.
KP>Мозилла [..] избавилась от главного паровоза этого прекрасного языка.
Servo? Разве ж это паровоз? Браузерный движок. Кто-нибудь кроме Mozilla и Samsung его использовал?
Я всё чаще вижу Rust в нише системного программирования. Даже к ядру Linux уже подбирается.
А место Mozilla, скорее всего, займут несколько других компаний — Rust как эксперимент удался. Концепция языка показала свою жизнеспособность и преимущества. Языком уже заинтересовались и Facebook и Apple и куча менее известных компаний. Тут скорее стоит переживать за судьбу самого браузера, т.к. у Mozilla дела идут не так уж гладко. Один раз её уже закапывали в конце 90-х под именем Netscape Navigator. В тот раз их убила попытка переписать всё с нуля, заново. Как бы проект опять не заглох.
Здравствуйте, Максим, Вы писали:
М>Как-то не впечатляет история успеха — https://ocaml.org/learn/success.html М>А если Jane Street обанкротится, то OCaml окончательно встретится с D
OCaml — ГЦ. как замена плюсам не подходит. JS может с таким же успехом использовать скалу или джулию.
Здравствуйте, CreatorCray, Вы писали:
CC>Я перестал пользоваться FF после этого. CC>Когда они просто похерили половину плагинов, ради которых я и держал FF и стали выглядеть как хром я просто поставил хром.
Плагины частично возродились, а мой основной, TST, вполне себе работает. В хроме же ничего подобного нет и не предвидится.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Когда я работал в Автодеске (10К+ человек), у нас одна команда написала на Rust небольшой проектик и потом трубила об этом очень громко. Это я к чему собственно, Rust прекрасный язык, а вот растоманы обычно фанатичные и шумные.
Здравствуйте, Artem Korneev, Вы писали:
AK>Чему радоваться-то? Очень интересный проект.
Проект мне нравится, меня растоманы разражают. Они как немерлисты на пике — агрессивные и ограниченные. Особенно доставляют JS-разработчики рассказывающие о том, что в C++ было все плохо (там и есть не то что бы хорошо, но вам то с хрена ли знать что именно там плохо?!), а с Rust стало всё забибизь
AK>Как язык — на мой взгляд, чрезмерно сложный. Думается, что можно было б сделать те же вещи проще для использования. Но более интересен сам эксперимент по предотвращению целых классов болезненных ошибок ещё на этапе компиляции.
Через привнесение боли в процесс написания? Хотелось бы напомнить что Haskell делает то же самое, но еще лучше (и защита и привнесение боли)
AK>Servo? Разве ж это паровоз? Браузерный движок. Кто-нибудь кроме Mozilla и Samsung его использовал? AK>Я всё чаще вижу Rust в нише системного программирования. Даже к ядру Linux уже подбирается.
Да пофигу кто использовал, важно кто платил. Вот сюда к примеру глянь, тренд этого года с начала массовой ковидлы — резкое падение.
Здравствуйте, ltc, Вы писали:
ltc>Меня больше беспокоит судьба фаерфокса, как-то мозиллу лихорадит последнее время жестко. ltc>Не хочется, чтобы веб стал chrome-only.
Тоже напрягает, что всякие плюшки типа диктора/скайпа для веб только в хроме и едже. в фф юзабилити получше и внешне он более что ли строго выглядит.
Здравствуйте, varenikAA, Вы писали:
AA>На выхах зашел на https://code.dlang.org/ посмотрел на гуи, как-то вяло. единственный серьезный проект vibe-d. AA>остальное больше на курсовую похоже.
Это довольно интересное заявление от человека, который всё норовит раскопать стюардессу активно педалит за LISP-ы
Здравствуйте, kaa.python, Вы писали:
KP>Это довольно интересное заявление от человека, который всё норовит раскопать стюардессу активно педалит за LISP-ы
ну да, если сравнивать лисп с другими маргинальными ЯП, он выигрывает, что у раста, что у ди, если слегка углубляешься в лисп,
то находишь множество готовых и рабочих библиотек и решений, а выразительность лисп в его синтаксической простоте, гениально!
Аналогичная ситуация с go. в этом случае правда еще реклама гугла помогла.
но посмотрите и ГОСТ шифрования реализован и вообще библиотек просто море.
Это при том что яп гораздо "хуже" раста.
(loop for i from 1 to 10 do (format t "~A~%" i))
for i = 1 to 10 do printfn "%A" i
Я уж не говорю про clojure который имеет только один недостаток — jvm.
на последней я даже написал за пару дней веб-апп с базкой и веб-мордой и рест клиент к джире для отслеживания последних изменений по всем проектам.
Здравствуйте, kaa.python, Вы писали:
KP>Может, главное достоинство? У тебя же все библиотеки из мира JVM доступны и именно поэтому ты смог:
и да и нет. если на тачке SSD и 64Gb ОЗУ и 16 физических ядер, тогда возможно да, но если у тебя Celeron M, 2Gb ОЗУ, и жесткий с истекшим сроком надежности, то 100% — нет.
этим ним и ди и привлекают.
лиспы кстати, по крайней мере sbcl стартуют пошустрее кложи на порядок. и память по человечески кушает.
я уже пробовал для жвм задавать минимум памяти при старте. она тогда еще сильнее тормозит.
надежда только на грааль вм. но это сложно.
Здравствуйте, varenikAA, Вы писали:
AA>Вот, конкретно. причем что в режиме разработке, что из уберджара. 7+11 секунд и это на i5 с ssd и 8Gb ОЗУ. AA>Вишенка на торте эксепшен на иконку )))
AA>Ну, что это?
JVM такая JVM
Поэтому надо не мудрить и брать Go для бэкенда
AK>Как язык — на мой взгляд, чрезмерно сложный. Думается, что можно было б сделать те же вещи проще для использования. Но более интересен сам эксперимент по предотвращению целых классов болезненных ошибок ещё на этапе компиляции.
У меня такое же сложилось впечатление о Rust. Наш текущий проект состоит из набора относительно независимых сервисов, которые общаются между собой по REST. Ну и в принципе каждая команда могла реализовывать свой сервис на языке, который посчитает нужным. Так вот, один из сервисов написали на Rust, ну просто потому, что человек захотел его изучить. Ну вроде написали, как-то это заработало, но автор через некоторе время ушел заниматься другими вещами, а сервис должны были поддерживать люди, скажем так, менее восторженно настроенные к Rust. В итоге, внесение даже малейших изменеий превратилось в боль, поскольку нельзя просто взять и начать писать на Rust. После полугода мучений, волевым решением, за неделю все было переписано на Golang. Теперь можно даже тестеров просить поправить код по-быстрому
Все это я рассказал не к тому, что Rust плохой. Просто язык этот, на мой взгляд, очень нишевый и требует четкого понимания — перевешивает ли тот выхлоп который он даст все сложности (начиная от изучения и заканчивая поиском программистов).
Здравствуйте, Privalov, Вы писали:
D>>В смысле? Я вот ничем другим кроме как Firefox не пользуюсь уже лет -нцать. P>Либо у тебя безразмерное терпение, либо у твоего железа безразмерные ресурсы. Огнелис после 26-й версии скатился в... в... В общем, пришлось его заменить.
Я пытался несколько раз пользоваться Хромом, так тот на тех же ресурсах что и ФФ у меня всегда существенно больше тормозил
Здравствуйте, varenikAA, Вы писали:
AA>и да и нет. если на тачке SSD и 64Gb ОЗУ и 16 физических ядер, тогда возможно да, но если у тебя Celeron M, 2Gb ОЗУ, и жесткий с истекшим сроком надежности, то 100% — нет.
Скажите, а зачем обладателю такого компьютера вообще что бы то ни было? Может ему лучше картошку выращивать? Или что там ему на роду написано делать.
Здравствуйте, Privalov, Вы писали:
D>>В смысле? Я вот ничем другим кроме как Firefox не пользуюсь уже лет -нцать. P>Либо у тебя безразмерное терпение, либо у твоего железа безразмерные ресурсы. Огнелис после 26-й версии скатился в... в... В общем, пришлось его заменить.
А я вот когда-то давно ушел с ФФ на Хром из-за производительности как раз... А пару лет назад вдруг заметил, что Хром (без плагинов) стал слишком часто отъедать кучу проца даже без нагрузки. Пытался разобраться но не нашел причину. Попробовал ФФ, и опять втянулся и снова стал пользоваться им в основном.
AK>Такие эксперименты занимают долгое время и хочется думать, что ещё лет через 15 появится какой-нибудь "Rust с человеческим лицом", которым можно будет пользоваться без нервных тиков и слёз на глазах.
вроде я и согласен про сложность, но в длинном ряду хардкорных системных языков(от циклона до прости господи атс) раст воспринимаю именно как язык с человеческим лицом — куда уж человечнее
примерно такое же впечатление в ряду хардкорных языков с пруверами вызывает Дафни(судьба которого еще более печальна)
Здравствуйте, kaa.python, Вы писали:
KP>Когда я работал в Автодеске (10К+ человек), у нас одна команда написала на Rust небольшой проектик и потом трубила об этом очень громко. Это я к чему собственно, Rust прекрасный язык, а вот растоманы обычно фанатичные и шумные.
Разные люди увлекаются языком Rust. Зачем всех ровнять под одну гребенку? Будто среди поклонников других языков мало крикунов?
Конечно, Rust не заменит в обозримом будущем C++. Об этом речь не идет. Однако, люди с опытом в функциональном программировании, особенно с опытом в языке Haskell, чаще всего выбирают язык Rust, а не C++. Наверное, не стоит пытаться понравиться всем абсолютно, ибо это невозможно и даже бессмысленно, но завоевать сердца поклонников функциональных языков программирования авторы языка Rust все же смогли!
Здравствуйте, dsorokin, Вы писали:
D>Конечно, Rust не заменит в обозримом будущем C++. Об этом речь не идет. Однако, люди с опытом в функциональном программировании, особенно с опытом в языке Haskell, чаще всего выбирают язык Rust, а не C++.
Знаю нескольких с опытом в Haskell. Почти все они параллельно круто пишут на плюсах, один на Эликсире и Elm. Больше замечаю диванных аналитиков от мира JS радующихся Rust
Но это, идея языка очень хорошая, я вцелом за Rust, если что, особенно если за счет работодателя его где-то выучить удасться
Здравствуйте, kaa.python, Вы писали:
KP>Знаю нескольких с опытом в Haskell. Почти все они параллельно круто пишут на плюсах, один на Эликсире и Elm. Больше замечаю диванных аналитиков от мира JS радующихся Rust
KP>Но это, идея языка очень хорошая, я вцелом за Rust, если что, особенно если за счет работодателя его где-то выучить удасться
И все тобой перечисленное в конце-концов вчистую сольет GO, как ни прискорбно. Вся история развития программирования показывают, что побеждают языки с минимальными требованиями к программистам, чем меньше требования, тем лучше. За примерами далеко ходить не надо: JavaScript, Python, PHP, GO.
Здравствуйте, mrTwister, Вы писали:
T>И все тобой перечисленное в конце-концов вчистую сольет GO, как ни прискорбно. Вся история развития программирования показывают, что побеждают языки с минимальными требованиями к программистам, чем меньше требования, тем лучше. За примерами далеко ходить не надо: JavaScript, Python, PHP, GO.
Не могу сказать что меня это расстраивает. Для меня C++, Go и Python — основная кормовая база
Здравствуйте, kaa.python, Вы писали:
KP>Особенно доставляют JS-разработчики рассказывающие о том, что в C++ было все плохо (там и есть не то что бы хорошо, но вам то с хрена ли знать что именно там плохо?!), а с Rust стало всё забибизь
Не встречал таких пока.
Насколько я понимаю, есть овер-дохрена народу, которые ограничились чтением вводных мануалов типа "hello world на Rust" и на этом их познания о Rust заканчиваются. Вот как раз простые сценарии в Rust реализуются и правда элементарно. Если использовать IDE, то даже многопоточный hello world получается не сложнее питона. Отсюда у многих леммингов на реддитах наступает эйфория, им кажется что Rust это такая простая и лёгкая замена плюсам.
Да даже задачки с литкода в большинстве своём на Rust'е можно писать вполне себе нормально. Там обычно все эти синхронизации, сериализации и изменяемые состояния либо отсутствуют, либо сведены к минимуму. Садо-мазо, боль и унижения с Rust'ом начинаются на более поздних этапах, до которых лемминги с реддитов часто и не доходят.
KP>Через привнесение боли в процесс написания?
Именно! Только так!
KP>Хотелось бы напомнить что Haskell делает то же самое, но еще лучше (и защита и привнесение боли)
Вот с Haskell'ем я бы тоже познакомился. Но пока не встречал его в продакшне, а времени изучать его из академического интереса нет.
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже. Мозилла не только перевела команду Rust в режим выживания поувольняв часть сотрудников,
Мы наняли одного человека, который ушёл из Мозиллы. Rust ещё в начале года создал foundation, с неплохой поддержкой нескольких корпораций. Над кодом компилятора работают из Амазона, Гугла и MS.
KP>но еще и избавилась от главного паровоза этого прекрасного языка — Servio, сдав его на кладбище.
Servo был исследовательским проектом, по большей части. Никто всерьёз не планировал, что весь код Мозиллы можно будет взять и переписать за раз. Кусочки этого проекта (Stylo CSS) были интегрированы в основой код Мозиллы. Постепенно там пилят и другие её компоненты.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, vsb, Вы писали:
vsb>>Обычные разработчики в массе своей не учитывают. Ситуацию спасает лишь то, что современные стандарты довольно хороши и написать код, который не будет работать в фаерфоксе, но будет работать в хроме, не так уж и просто. E>Да ладно? Современные фронтэндеры кроме хрома вообще другие браузеры не рассматривают и кроме хрома хрен где работает. Как минимум UI для кубернейтс какой то из прошлых версий работает только на хроме. Обновимся на более новую, там обещают что и в файрфоксе заработает.
Здравствуйте, Je suis Mamut, Вы писали:
JSM>p.s. поговаривают, что страшный суд отменили и вместо этого человечеству прислали кубер. в рамках этой версии хром-онли смотрится органично
Я туда вообще перестал заглядывать, оно просто работает. Даже глючнопадучий Seafile с полпинка подымает, так что уже 200 дней руки не доходят починить/обновить.
Страшный суд был до кубернетес.
Платят за него супер. Разработчики в восторге. Руководство в восторге. Работы много. Вы точно с этой вселенной?
Здравствуйте, Cyberax, Вы писали:
C>Мы наняли одного человека, который ушёл из Мозиллы. Rust ещё в начале года создал foundation, с неплохой поддержкой нескольких корпораций. Над кодом компилятора работают из Амазона, Гугла и MS.
Ну я не то что бы очень серьезен был, когда пост писал. Как ни как КСВ, тут сам раздел обязывает немного накидывать
T>И все тобой перечисленное в конце-концов вчистую сольет GO, как ни прискорбно. Вся история развития программирования показывают, что побеждают языки с минимальными требованиями к программистам,
"Миллионы мух не могут ошибаться" (С)
Что считать победой, вступить в партию миллионов мух?
Здравствуйте, Слава, Вы писали:
С>Скажите, а зачем обладателю такого компьютера вообще что бы то ни было? Может ему лучше картошку выращивать? Или что там ему на роду написано делать.
иногда думаю, что если бы кодить заставляли на рухляди, то по было бы более шустрое.
Здравствуйте, Artem Korneev, Вы писали:
AK>В нише системного программирования Rust не сольёт. Он может слить плюсам или Си, но не Go.
Что есть ниша системного программирования?
Понятно, что ядерные драйвера вряд ли кто-то будет писать на Go (да и на Rust'е тоже). Но почему бы на Go не быть написанным какому-нибудь почтовому демону, мне непонятно.
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, mrTwister, Вы писали:
T>>И все тобой перечисленное в конце-концов вчистую сольет GO, как ни прискорбно.
AK>В нише системного программирования Rust не сольёт. Он может слить плюсам или Си, но не Go.
Вот как раз Си может быть и останется для совсем хардкора. Для чего-то более высокоуровнего будет Go
Здравствуйте, SkyDance, Вы писали:
T>>И все тобой перечисленное в конце-концов вчистую сольет GO, как ни прискорбно. Вся история развития программирования показывают, что побеждают языки с минимальными требованиями к программистам,
SD>"Миллионы мух не могут ошибаться" (С) SD>Что считать победой, вступить в партию миллионов мух?
Речь не про то, ошибаются ли миллионы мух или нет, а про то, что задают тренды и определяют историю именно миллионы (мух или не мух, не важно).
Здравствуйте, Je suis Mamut, Вы писали:
JSM>в моей вселенной коллеги, на которых он свалился играют со мной в теннис меньше, а ругаются больше JSM>платить им больше тоже не стали
У меня тоже только сугубо положительные впечатления. У меня есть теория, кто плачут от кубернетеса обычно либо те, кому он не нужен, а они все равно используют из-за хайпа, либо те, кто не пробовал на голых виртуалках делать пачку разных связанных друг с другом сервисов с автоскейлингом и автоматическим восстановлением. Вот если им дать сначала поиграться в это без кубера, а потом с кубером, вот тут то любовь к кубернетесу и просыпается.
Здравствуйте, mrTwister, Вы писали:
T>У меня тоже только сугубо положительные впечатления. У меня есть теория, кто плачут от кубернетеса обычно либо те, кому он не нужен, а они все равно используют из-за хайпа, либо те, кто не пробовал на голых виртуалках делать пачку разных связанных друг с другом сервисов с автоскейлингом и автоматическим восстановлением. Вот если им дать сначала поиграться в это без кубера, а потом с кубером, вот тут то любовь к кубернетесу и просыпается.
Но тут есть интересный момент, то же самое часто можно дешевле и проще решить через Swarm нежели чем k9s
JSM>>в моей вселенной коллеги, на которых он свалился играют со мной в теннис меньше, а ругаются больше JSM>>платить им больше тоже не стали
T>У меня тоже только сугубо положительные впечатления. У меня есть теория, кто плачут от кубернетеса обычно либо те, кому он не нужен, а они все равно используют из-за хайпа, либо те, кто не пробовал на голых виртуалках делать пачку разных связанных друг с другом сервисов с автоскейлингом и автоматическим восстановлением. Вот если им дать сначала поиграться в это без кубера, а потом с кубером, вот тут то любовь к кубернетесу и просыпается.
я так понимаю, они им занялись как раз из-за автоскейлинга (т.е. до того его не было)
Здравствуйте, Artem Korneev, Вы писали:
AK>Да даже задачки с литкода в большинстве своём на Rust'е можно писать вполне себе нормально. Там обычно все эти синхронизации, сериализации и изменяемые состояния либо отсутствуют, либо сведены к минимуму. Садо-мазо, боль и унижения с Rust'ом начинаются на более поздних этапах, до которых лемминги с реддитов часто и не доходят.
Сказки венского леса.
AK>Вот с Haskell'ем я бы тоже познакомился. Но пока не встречал его в продакшне, а времени изучать его из академического интереса нет.
Вот, а если бы был знаком, то сразу многое бы прояснилось, почему в Rust многие вещи сделаны именно так, а не иначе.
Здравствуйте, Je suis Mamut, Вы писали:
V_>>Платят за него супер. Разработчики в восторге. Руководство в восторге. Работы много. Вы точно с этой вселенной?
JSM>в моей вселенной коллеги, на которых он свалился играют со мной в теннис меньше, а ругаются больше JSM>платить им больше тоже не стали
Очевидно, что проблема с кваливихацией.
Причем, по моему опыту подготовки, имеющийся опыт имеет заметно меньшее значение, чем желание человека к самообучению.
Видел и тех и других, в динамике.
Потому, по тому же самому опыту, платить им больше не станут, так и будут ругаться до старости.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, Vetal_ca, Вы писали:
V_>>Но вот домашний сервак S>А можно поподробнее про сервисы: что и зачем?
Freeswitch — телефония с самописным приложением для настроек этих линий (~12 номеров), 2 VoIP провайдера, Канада и Россия
VPN-Quagga-DNS — домашний routing mesh, прозрачно связывающий облака и дома (мои и заинтересованных родственников)
Пара сайтов, включая WP. Сам WP руками трогать не хочется, но, тем не менее, прекрасно все крутится
Личный Docker registry
VPN, чтобы извне
Ну и, менеджер SSL с прокси. И Vault не дотянул курсором
Здравствуйте, dsorokin, Вы писали:
D>Здравствуйте, Artem Korneev, Вы писали:
AK>>Вот с Haskell'ем я бы тоже познакомился. Но пока не встречал его в продакшне, а времени изучать его из академического интереса нет.
D>Вот, а если бы был знаком, то сразу многое бы прояснилось, почему в Rust многие вещи сделаны именно так, а не иначе.
Поясню свою мысль. Те, кто писал более-менее сложный код на хаскеле, то те широко использовали IORef и аналоги. Это просто неизбезжно в хаскеле. А основная ошибка начинающих писать код на расте заключается в том, что они недооценивают использование RefCell, аналога IORef из мира хаскеля. Вместо этого всеми силами порою стараются обойтись без RefCell, а это не всегда разумно. Рискну предположить, что это основная проблема, с которой сталкиваются новички на языке раст. Впрочем, начинающие хаскелисты грешат тем же, избегая использовать IORef там, где это действительно нужно. Идеи идеями, но иногда нужно использовать мутабельные ссылки по их прямому назначению.
Здравствуйте, Dair, Вы писали:
D>Я пытался несколько раз пользоваться Хромом, так тот на тех же ресурсах что и ФФ у меня всегда существенно больше тормозил
Не, что Хром не нужен, я и так знаю. Может, и попробую установить Огнелиса. Но пока пользуюсь Хромой Оперой и, реже, Вивальди. Последний, должен сказать, весьма неплох.
Здравствуйте, Je suis Mamut, Вы писали:
JSM>фрилансерам тоже перепадает, или это более-менее он-сайт всё?
Je suis freelancers — мы все сейчас удаленщики
Вообще, конкретно потому что я видел, проблема не в удаленке как способ работы. А в законах, как оформлять работника, платить ЗП и т.п. Если удаленка, то это еще типа бухгалтер/юрист для всего оформления.
Т.е., местному, поступил на довольствие и работай где хочешь.
Потом еще к Devops/SRE всякие SOC 2 compliance идут. И это не только по системам но и к сотрудникам относится. Например, у меня местных reference просили, после трудоустройства уже, как часть соответствия этим SOC 2.
Так что, не все так просто и не из-за вредности или упрямства начальства.
Здравствуйте, Vetal_ca, Вы писали:
V_>Je suis freelancers — мы все сейчас удаленщики V_>Вообще, конкретно потому что я видел, проблема не в удаленке как способ работы. А в законах, как оформлять работника, платить ЗП и т.п. Если удаленка, то это еще типа бухгалтер/юрист для всего оформления.
PEO (Professional Employment Organization) на помощь! Т.е. фактически аутсорс всего HR и бухгалтерии.
D> Идеи идеями, но иногда нужно использовать мутабельные ссылки по их прямому назначению.
Вот это как раз и есть ошибка, которую допускают неопытные программисты.
Не новички (которые читают умные книги и статьи, и пытаются без этой мутабельности). А те, кто уже о себе думают как о серьезных разработчиках, но еще не понимают реальной ошибочности такой оценки.
Прямое сравнение могу привести с Erlang ETS. Новички начинают без использования ETS, ибо читают книжки, статьи и прочее.
Но потом "становятся крутыми", и обнаруживают, что, оказывается, можно очень ловко abuse'ить ETS и как бы получать как бы производительность там, где сначала не получалось (и не получится без понимания, как надо делать на самом деле).
И только следующим уже этапом может придти осознание, что этот удобный вариант out-of-band обмена информацией в обход message queue ведет к большим потерям производительности (причем там, где не ждешь — на постоянном копировании в/из ETS).
Здравствуйте, Pzz, Вы писали:
Pzz>Понятно, что ядерные драйвера вряд ли кто-то будет писать на Go (да и на Rust'е тоже). Но почему бы на Go не быть написанным какому-нибудь почтовому демону, мне непонятно.
А на каком языке нельзя писать почтовый демон? Что такое почтовый демон? Работа с сокетами, файлами, разбор текстовых протоколов. Ну OpenSSL прикрутить. Тут по-моему вообще без разницы, на чём писать. Ну на ассемблере будет много писанины, да, хотя, наверное, если привыкнуть, то не особо медленней, чем на C.
Здравствуйте, SkyDance, Вы писали:
D>> Идеи идеями, но иногда нужно использовать мутабельные ссылки по их прямому назначению.
SD>Вот это как раз и есть ошибка, которую допускают неопытные программисты. SD>Не новички (которые читают умные книги и статьи, и пытаются без этой мутабельности). А те, кто уже о себе думают как о серьезных разработчиках, но еще не понимают реальной ошибочности такой оценки.
SD>Прямое сравнение могу привести с Erlang ETS. Новички начинают без использования ETS, ибо читают книжки, статьи и прочее. SD>Но потом "становятся крутыми", и обнаруживают, что, оказывается, можно очень ловко abuse'ить ETS и как бы получать как бы производительность там, где сначала не получалось (и не получится без понимания, как надо делать на самом деле).
SD>И только следующим уже этапом может придти осознание, что этот удобный вариант out-of-band обмена информацией в обход message queue ведет к большим потерям производительности (причем там, где не ждешь — на постоянном копировании в/из ETS).
Так можно до чего угодно договориться в отрыве от реального предмета обсуждения
Здравствуйте, kaa.python, Вы писали:
KP>Похоже что дела у самого безопасного и быстрого и прекрасного языка на свете идут всё хуже. Мозилла не только перевела команду Rust в режим выживания поувольняв часть сотрудников, но еще и избавилась от главного паровоза этого прекрасного языка — Servio, сдав его на кладбище.
KP>Как считаете, D теперь не будет так грустно и одиноко?
Здравствуйте, mrTwister, Вы писали:
T>У меня есть теория, кто плачут от кубернетеса обычно либо те, кому он не нужен, а они все равно используют из-за хайпа, либо те, кто не пробовал на голых виртуалках делать пачку разных связанных друг с другом сервисов с автоскейлингом и автоматическим восстановлением. Вот если им дать сначала поиграться в это без кубера, а потом с кубером, вот тут то любовь к кубернетесу и просыпается.
Предыдущий продукт, которым моя команда занималась, был на голых VMSS. Текущий на кубере. Вместо любви к куберу в основном кое что другое просыпается регулярно, особенно у тех кто код пишет и отлаживает.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, vsb, Вы писали:
vsb>>С чего ты взял, что Servo был паровозом? Он мне всегда казался странным проектом, никому особо не нужным. Делать движок, на который никто переходить не собирается и в лучшем случае какие-то его куски будут дёргать в фаерфокс.
KP>А разве не Мозилла была основным спонсором для Rust? Ну а затеяли они Rust вроде потому, что не осилили C++ и движек вечно тёк. Не?
По твоей же ссылке в стартовом сообщении:
В Firefox уже интегрированы такие наработки Servo, как многопоточный CSS-движок и система отрисовки WebRender.
Всё что надо было — успешно обкатали в том движке и забрали/заинтегрили к себе, далее отпустили в свободное плаванье, чтобы продолжать получать свои доходы от ESR + ни в коем виде более не мараться с Сосунгами, помня офигительные истории с Tizen.
НС>Предыдущий продукт, которым моя команда занималась, был на голых VMSS. Текущий на кубере. Вместо любви к куберу в основном кое что другое просыпается регулярно, особенно у тех кто код пишет и отлаживает.
У нас кстати тоже предыдущий был на голых VMSS. Геморроя с ними было на порядок больше, чем с кубером. Точнее не с самими VMSS (хотя и с ними тоже, LB там жесть), сколько с деплоем. Время апгрейда сократилось с нескольких часов до нескольких минут. Для добавления нового сервиса раньше надо было идти на поклон к админам DevOpsам, ждать фиг знает сколько пока они допилят деплоймент, чертыхаться пока они исправят там баги. Сейчас же разработчик сам коммитит новый простенький yaml файлик формат которого описан в любом букваре по кубернетесу и всё, мы имеем новый сервис. Я к тому, что команды разработки стали гораздо более автономные и могут решать практически все свои проблемы и развивать приложения самостоятельно без привлечения админов. При этом всё просто работает. Не понимаю, что там дебажть. Тестирование также значительно упростилось, так как появилась возможность тестировать не только в service provider'е (azure), а где угодно. Например, нам по определённым причинам удобнее проводить тестирование на своём кубернетисе, не в облаке. При этом самому приложению пофиг где его запускают, в ажуре, или у себя: и там и там кубернетис, который с точки зрения приложения работает одинаково.
Здравствуйте, mrTwister, Вы писали:
T>У нас кстати тоже предыдущий был на голых VMSS. Геморроя с ними было на порядок больше, чем с кубером. Точнее не с самими VMSS (хотя и с ними тоже, LB там жесть), сколько с деплоем. Время апгрейда сократилось с нескольких часов до нескольких минут.
У меня прямо обратный экспириенс. На VMSS, после некоторого количества потраченных усилий, релизы проходили как по маслу, а на кубере каждый релиз как в первый раз. Обязательно что то ломается.
T> Для добавления нового сервиса раньше надо было идти на поклон к админам DevOpsам, ждать фиг знает сколько пока они допилят деплоймент
Ну так ошибка в том, что у вас к девопсам надо было идти, хотя девопс должен быть частью команды продукта.
НС>Ну так ошибка в том, что у вас к девопсам надо было идти, хотя девопс должен быть частью команды продукта.
Ну вот как раз с кубером этого достичь гораздо проще, так как он стандартизует высокоуровневое описание инфраструктуры: сервисов, правил масштабирования и пр. Админы про это теперь вообще ничего не знают.
Здравствуйте, mrTwister, Вы писали:
НС>>Ну так ошибка в том, что у вас к девопсам надо было идти, хотя девопс должен быть частью команды продукта. T>Ну вот как раз с кубером этого достичь гораздо проще,
Моя практика показала, что не проще. Экономим на функционале кубера, теряем на борьбе с самим кубером.
T> так как он стандартизует высокоуровневое описание инфраструктуры: сервисов, правил масштабирования и пр.
Не не не. Вот то что он стандартизует — это одно. Именно ради этого и приходится его тащить. Но стандартизация не всегда нужна, а гемороя сам по себе он привносит изрядно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не не не. Вот то что он стандартизует — это одно. Именно ради этого и приходится его тащить. Но стандартизация не всегда нужна, а гемороя сам по себе он привносит изрядно.
А какой именно геморрой ты имеешь ввиду? У вас, я надеюсь, managed kubernetes?
=> k8s & Dev, второе для работы с конкретным модулем в комфорте собственной рабочей станции.
дальше забота DevOps и внешней конфигурации, где уже, централизованно появляются эти самые N environments
— Нету больше вопросов, где мне взять username/pass для БД/Message Broker/..... В кластере он генерируется через Vault. На рабочей станции, точно так же генерируется в кластере и доставляется девелоперу через S3 bucket
— нету больше списка ресурсов, серверов с портами и прочего. Это все доставляется и автоподставляется с консул темплейт. Разраб получает точно так же как credentials
— не будет у них никаких там SSL. А как разрабочики мучаются с SSL я уже насмотрелся. Учитывая, что cross-node траффик должен шифроваться (SOC 2 или местечковые требования). То дальше или мучения разработчиков или mTLS через service mesh. Последнее, шифрование есть, а разработчики занимаются своими делами.
— Разработчики больше не работают с AWS Secrets Manager. Ни с Cloudwatch, ни с кучей другого. Все эти привязки к провайдеру ушли в некий тонкий слой. Что-то тянет секреты, что-то подтягивает данные с (S3/Azure Container/...)? что-то забирает логи из текстовых текстовых файлов/stdout/socket и пишет их туда, куда скажут, централизовано. Неразрешимая задача продаванов "Клиент XYZ подпишет с нами, если мы не будем на AWS" решается элементарно, сменой этого слоя. На Azure, GCP или тот же Digital Ocean с минус ~ 40% инвойсу. Раньше, до меня с кубернетесами, они в самых смелых снах не представляли, как смогут оторваться от AWS
Теперь ты: расскажи, тогда, конкретно, отчего у вас не в восторге? Что, конкретно, ломается, что не работает. Какие мучения разрабов, diff(мучения-до-кубернетес, мучения-после)
Здравствуйте, kaa.python, Вы писали:
AA>>Я уж не говорю про clojure который имеет только один недостаток — jvm. KP>Может, главное достоинство?
Та не. ))
Еще на первом дотнете нарисовал как-то упрощённый интерпретатор Схемы...
В общем, оно вело себя отвратительно, дотнетный сборщик мусора для сценария {CAR, CDR} оказался тормозным.
И явовский тогда был не лучше.
Т.е. лисповские графы требуют в разы более шустрого GC.
Там пустые ячейки просто складываются в список и переиспользуются.
Попробовал так же в дотнете — опять не подходит — язык Схема является чистым, иммутабельным, это надо прописывать полям readonly, но тогда невозможно уже выделенные объекты складывать в пул...
В итоге, на технике начала 2000-х это было чушью, годилось только для относительно небольших "скриптов".
Не зря Кложура появилась на слуху только где-то к 2010-м годам, когда техника чуть подросла...
Здравствуйте, mrTwister, Вы писали:
НС>>Не не не. Вот то что он стандартизует — это одно. Именно ради этого и приходится его тащить. Но стандартизация не всегда нужна, а гемороя сам по себе он привносит изрядно. T>А какой именно геморрой ты имеешь ввиду?
Куча инструментария, которым его приходится обвешивать, потому что сам он чего то не совсем. Хелмы, приблуды для хелмов, консул, Ленз и т.п.
И я еще могу понять Виталика из Канады, который в основном использует готовые решения. Но когда ты сам эти решения делаешь, то количество танцев с бубном чтобы поднять новый кластер совсем не радует, я не говорю уж о том чтобы поднять часть сервисов вне кластера под отладкой.
Здравствуйте, Vetal_ca, Вы писали:
V_>Со своей стороны: V_>- нет больше инстансов и прочего VM-centric
Зато есть ноды и поды.
V_>- нет больше скольки-то там environments, оно, фактически, одно два:
Это уж как повезет.
V_>- Нету больше вопросов, где мне взять username/pass для БД/Message Broker/..... В кластере он генерируется через Vault.
И при чем тут кубер? Тем более что родных Secrets тебе не хватило, раз Vault понадобился.
V_>- нету больше списка ресурсов, серверов с портами и прочего. Это все доставляется и автоподставляется с консул темплейт.
Опять же, кубер тут никаким боком. Консул и без кубера работает, а родные куберовские Config Maps — опять какая то марсианская недоделка.
V_> Разраб получает точно так же как credentials
Ну и? В VMSS ставишь галку, потом просто лезешь в KeyVault напрямую или через App Configuration. И никакого кубера не нужно.
V_>- не будет у них никаких там SSL. А как разрабочики мучаются с SSL я уже насмотрелся.
Правда думаешь что SSL offload в кубере изобрели?
V_>- Разработчики больше не работают с AWS Secrets Manager. Ни с Cloudwatch, ни с кучей другого. Все эти привязки к провайдеру ушли в некий тонкий слой.
Ну вот единственное ради чего кубер имеет смысл. Только восторга от того никакого, увы. Это как с JS — какашка полная, но альтернатив все равно нет.
V_>что-то забирает логи из текстовых текстовых файлов/stdout/socket и пишет их туда, куда скажут, централизовано.
И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает.
V_>Теперь ты: расскажи, тогда, конкретно, отчего у вас не в восторге?
От того что разработка и настройка деплоймента превратилась в задачу для целой команды хронически перегруженных девопсов (при том что написание и подержку хелмов для собственных сервисов они взвалили на разрабов), в то время как раскатка на голых VMSS, пусть и без возможности съехать в другой клауд, занимала, после некоторой первоначальной инвестиции, 20% времени одного разраба.
Ну и как вишенка на торте — продукт на VMSS после первоначального тюнинга уже больше года работает как швейцарские часы вообще без присмотра, а новый продукт на кубере постоянно чудит, все никак потребный зоопарк из десятков сторонних продуктов не срастется.
V_> Что, конкретно, ломается, что не работает. Какие мучения разрабов, diff(мучения-до-кубернетес, мучения-после)
Мне одного того, что разрабы вместо написания хелмов поднимаю кластер в композе, ибо в 100 раз быстрее чем пачку хелмов расписывать и потом ждать когда оно задеплоится, вполне достаточно чтобы считать кубер далеко не идеальным решением.
НС>Куча инструментария, которым его приходится обвешивать, потому что сам он чего то не совсем. Хелмы, приблуды для хелмов, консул, Ленз и т.п.
Не знаю, мы как-то без всего этого обходимся, нет ни хелма, ни консула, ничего. Да, используем стандартные секреты, ConfigMap, при этом нет никаких проблем, работает все как часы.
Здравствуйте, mrTwister, Вы писали:
T>Не знаю, мы как-то без всего этого обходимся, нет ни хелма, ни консула, ничего. Да, используем стандартные секреты, ConfigMap, при этом нет никаких проблем, работает все как часы.
Ну если даже хелмов не используете, то у вас, судя по всему, совсем простой по структуре и настройкам кластер.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зато есть ноды и поды.
И, в чем проблема? Нод, их, вообще не видно. Поды ... Это как процессы -> контейнеры -> поды. Плюс огромное удобство, подготовка тех же credentials в init контейнерах. Или незаметная для основного приложения отправка тех же логов через sidecar контейнер. Тот же, FluentBit
НС>И при чем тут кубер? Тем более что родных Secrets тебе не хватило, раз Vault понадобился.
Секреты Kubernetes это статические вещи, как пароли в KeePass у простых смертных. Эти сredentials имеют совершенно другой принцип. Эти creds создаются по запросу на те же 30 секунд, они одноразовы и "проворачиваемы" (или как оно там, secrets rotation по русски). И ведут они к тем же Mongo, Postgres, AWS AMI и т.п., нигде вне контекста Pod не хранясь, с минимальным периодом жизни. С Kubernetes secrets это не сравнимо. Но, надо заметить, Kubrentes (и Hashicorp Vault) дает такую возможность совершенно "бесшовно", что есть признак гибкой и удобной системы.
V_>>- нету больше списка ресурсов, серверов с портами и прочего. Это все доставляется и автоподставляется с консул темплейт.
НС>Опять же, кубер тут никаким боком. Консул и без кубера работает, а родные куберовские Config Maps — опять какая то марсианская недоделка.
Работает. И без косула работает. Разница только во времени внедрения. так сказать, день-неделя-месяц-год, никакой разницы, ага.
НС>Ну и? В VMSS ставишь галку, потом просто лезешь в KeyVault напрямую или через App Configuration. И никакого кубера не нужно.
VMSS это типа instance profile на EC2 ? Переносим на GCP и это уже не работает. Ох уж этот отдел маркетинга провайдеров с попыткой привязать к своим технологиям.
В общем, в топку, что VMSS что EC2 Instance profile, все эти скрытые неявные привязки должны быть явны и видимы.
НС>Правда думаешь что SSL offload в кубере изобрели?
Что ты здесь имеешь в виду под SSL Offloading? Наиболее употребимый вариант, что приходит на ум, это SSL Offloading на reverse proxy, что к моему примеру никак не относится и задач для внутри-кластерной SSL не подходит.
НС>Ну вот единственное ради чего кубер имеет смысл. Только восторга от того никакого, увы. Это как с JS — какашка полная, но альтернатив все равно нет.
Не скажу за JS — но про какашку требует четкого обоснования. Пока какашки не видел, только восторг и рабочий environment. Как на работе, так и в личных проектах, где меня уж точно никто не заставляет пользоваться неудобными инструментами.
НС>И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает.
И что у тебя в приложении "зашито"? Прямо так, к ELK завязано на уровне приложения?
V_>>Теперь ты: расскажи, тогда, конкретно, отчего у вас не в восторге?
НС>От того что разработка и настройка деплоймента превратилась в задачу для целой команды хронически перегруженных девопсов (при том что написание и подержку хелмов для собственных сервисов они взвалили на разрабов), в то время как раскатка на голых VMSS, пусть и без возможности съехать в другой клауд, занимала, после некоторой первоначальной инвестиции, 20% времени одного разраба. НС>Ну и как вишенка на торте — продукт на VMSS после первоначального тюнинга уже больше года работает как швейцарские часы вообще без присмотра, а новый продукт на кубере постоянно чудит, все никак потребный зоопарк из десятков сторонних продуктов не срастется.
ХЗ, тут надо по месту смотреть. У нас срастается, как сторонние так и внутренние приложения.
НС>Мне одного того, что разрабы вместо написания хелмов поднимаю кластер в композе, ибо в 100 раз быстрее чем пачку хелмов расписывать и потом ждать когда оно задеплоится, вполне достаточно чтобы считать кубер далеко не идеальным решением.
КМК, кто-то Helm charts у вас увлекся. Впрочем, выбор правильного баланса для конкретного случая тут достаточно сложная задача. Kustomize vs Helm vs Terraform vs Spinnaker vs .... На предыдущем месте один пришлый DevOps за Helm Charts "топил". В смысле, написания этих Helm charts для собственных приложений. Даже juniorа ему выдали под эксперименты, замучил он этого junior-а. Меня не переубедил, мне кажется, что Helm больше для создателей компонентов. Типа VLC компонентов для Delphi. Хотя, как пользователь, с точки зрения потребления этих сторонних компонентов, все замечательно. Тот же Bitnami, просто супер
Тут, главное, не прикипать, мыслить широко и, если видно что закопался (типа как вы с Helm) "переобуваться" под более подходящую технологию. Ничего страшного в переобувании и адаптации нет.
В настоящий момент больше склоняюсь к Terraform/Terragrunt + Kubernetes, и их Kubernetes-Alpha. Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
Здравствуйте, Vetal_ca, Вы писали:
НС>>Зато есть ноды и поды. V_>И, в чем проблема?
А в чем проблема с VM?
НС>>И при чем тут кубер? Тем более что родных Secrets тебе не хватило, раз Vault понадобился. V_>Секреты Kubernetes это статические вещи, как пароли в KeePass у простых смертных.
О чем и речь. Вроде функционал есть, но применим только в простых случаях. И так везде. Вроде есть service discovery с DNS, но обычно ставят consult. Вроде есть автоскейлинг, но на практике еще и KEDA нужна. И т.п.
V_>Работает. И без косула работает. Разница только во времени внедрения. так сказать, день-неделя-месяц-год, никакой разницы, ага.
Внезапно перепрыгнули от разработчиков к внедрению?
НС>>Ну и? В VMSS ставишь галку, потом просто лезешь в KeyVault напрямую или через App Configuration. И никакого кубера не нужно. V_>VMSS это типа instance profile на EC2 ?
Нет, это что то типа AWS Auto Scaling
V_>Переносим на GCP и это уже не работает.
А если не переносим?
НС>>Ну вот единственное ради чего кубер имеет смысл. Только восторга от того никакого, увы. Это как с JS — какашка полная, но альтернатив все равно нет. V_>Не скажу за JS — но про какашку требует четкого обоснования.
Того что я уже привел вполне достаточно.
V_> Пока какашки не видел, только восторг и рабочий environment.
Восторг внедренцев? Охотно верю. Но ты с разработчиков начал.
НС>>И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает. V_>И что у тебя в приложении "зашито"? Прямо так, к ELK завязано на уровне приложения?
Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком.
V_>КМК, кто-то Helm charts у вас увлекся.
Остальные варианты еще хуже.
V_>Меня не переубедил, мне кажется, что Helm больше для создателей компонентов.
Бинго!
V_> Типа VLC компонентов для Delphi. Хотя, как пользователь, с точки зрения потребления этих сторонних компонентов, все замечательно.
Даже не сомневаюсь. Только мне как раз эти хелмы писать и править приходится постоянно.
V_>В настоящий момент больше склоняюсь к Terraform/Terragrunt + Kubernetes, и их Kubernetes-Alpha.
Terraform немного из другой оперы. А Kustomize соседняя команда решила использовать, и теперь долго и больно стараются на хелмы переползти.
V_> Но, готов переметнутся на более подходящую технологию, если что. Не взирая на текущие предпочтения.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну если даже хелмов не используете, то у вас, судя по всему, совсем простой по структуре и настройкам кластер.
Система и правда не сложная, но я, тем не менее не очень понимаю, для чего сложным системам нужен хелм. Насколько я понимаю, хелм нужен разработчикам компонент под кубернетес, когда заранее неизвестно в каком окружении и в каких условиях будет использоваться компонент. Но ведь при разработке некоробочных приложений это не так, мы заранее точно знаем в каких окружениях будет запускаться приложение и можем еще на этапе сборки сервиса сгенерировать отдельный yaml под каждое окружение, который не потребует никакой дальнейшей кастомизации. Причем в этом же yaml'е будут и все необходимые для работы ConfigMap'ы. В результате весь деплоймент сводится к выполнению одной команды "kubectl apply"
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А в чем проблема с VM?
Микроменеджмент. Кубернетес сам разбрасывает. Добавить ресурсов, убрать ресурсы, гранулярность использования (заполнение проплаченного). Вплоть до гибких способов исчпользования spot instances
НС>О чем и речь. Вроде функционал есть, но применим только в простых случаях. И так везде. Вроде есть service discovery с DNS, но обычно ставят consult. Вроде есть автоскейлинг, но на практике еще и KEDA нужна. И т.п.
C++ тоже не имеет операторов для отрисовки окна. И, тем не менее, используется
Короче, не аргумент.
НС>Внезапно перепрыгнули от разработчиков к внедрению?
Если "без кубернетес можно" выливается в месяц работы и вагон гемора, то это, внезапно, не вариант. Отклонено. Теоретически — можно, практически — нет.
V_>>Переносим на GCP и это уже не работает.
НС>А если не переносим?
Вот так прямо к сейлзам идешь и говоришь, "У нас тут VMSS, мы "поженены" на Azure, потому обойдемся без этих клиентов — отдавайте их конкурентам"
НС>Того что я уже привел вполне достаточно.
Ничего ты не сказал. Все что ты сказал, что у тебя что-то там не получается. Пока, все что понятно, это Helm Charts и его identations. И, наверняка, закономерное неприятие написания Charts разработчиками.
НС>>>И тут кубер сам по себе ничем тебе не поможет, а ELK и без кубера работает. V_>>И что у тебя в приложении "зашито"? Прямо так, к ELK завязано на уровне приложения?
НС>Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком.
Все эти варианты "вне кубернетес", как правило, вторичны. Выбор узок. Интеграция растянута во времени. Что, в реальном мире называется "не выдерживает конкуренции". Вариант есть, но его нет
Да,что там у нас с mTLS вне кубернетес? Не вижу твоих предложений. Напоминаю:
Клиент: "Подпишем, если будет SOC 2" -> "Data-in-transit-encryption".
Разработчики меняют свои endpoints и мучаются с SSL ?
НС>Остальные варианты еще хуже.
Отклонено как недоказательное.
V_>>Меня не переубедил, мне кажется, что Helm больше для создателей компонентов.
НС>Даже не сомневаюсь. Только мне как раз эти хелмы писать и править приходится постоянно.
Ну так не правь. Ты же не юниор, чтобы следовать приказаниям, не взирая ни на что. Меняй, внедряй предлагай более правильное и соответствующее задаче.
НС>Terraform немного из другой оперы. А Kustomize соседняя команда решила использовать, и теперь долго и больно стараются на хелмы переползти.
Здравствуйте, Vetal_ca, Вы писали:
НС>>А в чем проблема с VM? V_>Микроменеджмент. Кубернетес сам разбрасывает.
Поды — да. А ноды ты сам резервируешь. И далеко не всегда нужно на одной ноде несколько подов.
НС>>Внезапно перепрыгнули от разработчиков к внедрению? V_>Если "без кубернетес можно" выливается в месяц работы и вагон гемора, то это, внезапно, не вариант. Отклонено. Теоретически — можно, практически — нет.
Практически настройка кубера занимает порой времени больше, чем без него.
V_>>>Переносим на GCP и это уже не работает. НС>>А если не переносим? V_>Вот так прямо к сейлзам идешь и говоришь, "У нас тут VMSS, мы "поженены" на Azure, потому обойдемся без этих клиентов — отдавайте их конкурентам"
Ну а сейлзы тебе говорят, что им пофиг, и все равно кроме азура нам ничего не нужно.
НС>>Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком. V_>Все эти варианты "вне кубернетес", как правило, вторичны.
Нет. ELK появился задолго до кубера.
V_>Да,что там у нас с mTLS вне кубернетес?
Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2.
НС>>Даже не сомневаюсь. Только мне как раз эти хелмы писать и править приходится постоянно. V_>Ну так не правь.
V_> Ты же не юниор, чтобы следовать приказаниям, не взирая ни на что. Меняй, внедряй предлагай более правильное и соответствующее задаче.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Поды — да. А ноды ты сам резервируешь. И далеко не всегда нужно на одной ноде несколько подов.
Да, и тут все гибко в отличие от ручного прибивания гвоздями сервиса к ноду.
НС>Практически настройка кубера занимает порой времени больше, чем без него.
cd tf/deplyment/aws/prod/us-east1/core-cluster/01-insall && terragrunt apply
Минут 20 занимает времени, полностью автоматически
Точно так же с AKS, GCP или DO
V_>>Вот так прямо к сейлзам идешь и говоришь, "У нас тут VMSS, мы "поженены" на Azure, потому обойдемся без этих клиентов — отдавайте их конкурентам"
НС>Ну а сейлзы тебе говорят, что им пофиг, и все равно кроме азура нам ничего не нужно.
Ну вот, == никак. "Не шмогла", слив зафиксирован.
НС>>>Нет. Но при чем тут кубер? logstash или fluentd кубера не требуют никаким боком. V_>>Все эти варианты "вне кубернетес", как правило, вторичны.
НС>Нет. ELK появился задолго до кубера.
Опять съехал Если аргумент неудобен, то можно съехать? В реальном мире 2-3 съезда и перестанут воспринимать как серъезного человека.
Вопрос был о централизованной logging системой и возможностью переключать logging backends: ELK/PaperTrail/CloudWatch и т.д. и т.п.
В кубернетес логгирование легко абстрагируется. Так что приложения пишут в файлы/stdout а на уровне кластера уже перенаправляется в тот или иной logging backend. Где запущен тот-же ELK — дело десятое
НС>Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2.
И как вы, конкретно, data-in-transit encryption решали? Сколько людей было задействовано, сколько усилий. Кто это шифрование внедрял и как, конкретно подключал?
И, главное, почему это быстрее/лучше/надежнее чем тот же "LinkerD 2/Consul Service Mesh" и прочих, "mTLS автоматом" ?
НС>И какое решение более правильное?
Все что выше обсуждалось — пока мусор. Теперь мы переходим к сути вопроса.
Вот это и есть главный вопрос. Не переубедить. А узнать, где именно у вас проблемы и соотносятся ли они с моей ситуацией. Чтобы эти конкретные проблемы у себя обойти.
Пока тобой описанное никак не соотносится, кроме как эпизодических обсуждений на тему "А давайте сами писать Helm Charts"
По моему опыту, использовать Terraform с его HCL описаниями и связующими переменными показало себя намного лучше в моей практике, чем написание Helm Charts.
Даже решение mrTwister + Kustomize, добавляющий image tag от CI/CD выглядит проще этих Helm Charts
С другой стороны, Terraform c его state не совсем подходит для случая Кластер-на-девелоперской-машине. Или для деплойментов-на-раз, типа прогона тестов из Jenkins и создания/уничтожения mockup DB.
Здравствуйте, Vetal_ca, Вы писали:
НС>>Поды — да. А ноды ты сам резервируешь. И далеко не всегда нужно на одной ноде несколько подов. V_>Да, и тут все гибко в отличие от ручного прибивания гвоздями сервиса к ноду.
Serverless, опять же, ортогонален куберу.
V_>Минут 20 занимает времени, полностью автоматически
Да, если есть готовые отлаженные скрипты деплоя. Речь же про разработку.
НС>>Нет. ELK появился задолго до кубера. V_>Опять съехал
Куда я съехал? Централизованный сбор и индексация логов абсолютно ортогональны куберу, сам кубер ничего в этом плане не предоставляет.
V_>В кубернетес логгирование легко абстрагируется. Так что приложения пишут в файлы/stdout а на уровне кластера уже перенаправляется в тот или иной logging backend.
При чем тут кубер? Без кубера нет stdout и файлов? Или fluentd, внезапно, без кубера перестал работать? Ты бы разобрался как оно устроено, а не просто тыкал в готовые решения.
НС>>Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2. V_>И как вы, конкретно, data-in-transit encryption решали?
Там есть оговорки, позволяющие для внутрикластера это требование обойти. В подробности не вникал.
V_> Сколько людей было задействовано, сколько усилий. Кто это шифрование внедрял и как, конкретно подключал?
Тебе список фамилий что ли нужен? Вся команда почти была задействована в той или иной мере. Это требование SOC.
V_>И, главное, почему это быстрее/лучше/надежнее чем тот же "LinkerD 2/Consul Service Mesh" и прочих, "mTLS автоматом" ?
Почему отсутствие SSL там где он не нужен быстрее и проще чем его наличие? Странный вопрос.
НС>>И какое решение более правильное? V_>Все что выше обсуждалось — пока мусор. Теперь мы переходим к сути вопроса.
V_>Вот это и есть главный вопрос.
Это совсем не главный вопрос, потому что главный вопрос это сам кубер, а не какой то очередной отдельный тул.
SD>Задают тренды и историю единицы. SD>Ленин, Джобс, Маск.
SD>А миллионы просто ей следуют.
А ты к какой из этих двух категорий относишься?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Vetal_ca, Вы писали:
НС>Serverless, опять же, ортогонален куберу.
Привязан к провайдеру. Как и Fargate для AWS
НС>Да, если есть готовые отлаженные скрипты деплоя. Речь же про разработку.
Отмазка девопса?
НС>Куда я съехал? Централизованный сбор и индексация логов абсолютно ортогональны куберу, сам кубер ничего в этом плане не предоставляет.
V_>>В кубернетес логгирование легко абстрагируется. Так что приложения пишут в файлы/stdout а на уровне кластера уже перенаправляется в тот или иной logging backend.
НС>При чем тут кубер? Без кубера нет stdout и файлов? Или fluentd, внезапно, без кубера перестал работать? Ты бы разобрался как оно устроено, а не просто тыкал в готовые решения.
Там еще есть более удобные варианты, можешь почитать на досуге.
НС>>>Без понятия, не сталкивался. Нам почему то полное отсутствие SSL внутри кластера не помешало пройти SOC 2.
НС>Тебе список фамилий что ли нужен? Вся команда почти была задействована в той или иной мере. Это требование SOC.
То есть, не делали. А если бы делали, то увидели бы, что SSL/TLS "вручную", L7 требует вникания каждого члена команды. Адаптации и обучения. Включая сопутствующие минусы этого ручного и непрозрачного случая. Пример минуса "а какая версия OpenSSL в контейнере питона какого-то далекого компонента?"
В кубернетес можно единовременно добавить service mesh со сквозным шифорованием так, что приложение ни в коей степени не задействовано. Плюс сохранено много-много часов разработчиков. Не говоря уже о плюсах централизованного менеджмента всего это in-cluster шифрования, см пример выше.
Конечно, ты напишешь, чтобы выкрутиться "Можно и без" или чпрез старый "LinkerD 1.0" — ответ уже дан и закрыт — оптимально нельзя. Неоптимально — пускай наши конкуренты делают.
НС>Это совсем не главный вопрос, потому что главный вопрос это сам кубер, а не какой то очередной отдельный тул.
У меня лично, кубер не вопрос. Ни разворачивание, ни поды ни ноды — под моим руководством оно не вызывает вопросов. Преподавать с важным видом или пропагандировать кубернетес — не есть моя цель.
Вопрос только в частных случаях, где можно улучшить мои знания за счет опыта других. Что есть непосредственная цель моего тут участия. И, как ты уже, наверное, заметил, выхлоп данной ветки приближается к нулю, посему откланяюсь.
Здравствуйте, Pzz, Вы писали:
Pzz>Что есть ниша системного программирования?
Возможность работать без GC, большого рантайма и боксинга. Ниша C/C++ — вычислительный и железячный софт, где Go вообще никаким боком.
Pzz>Понятно, что ядерные драйвера вряд ли кто-то будет писать на Go (да и на Rust'е тоже).
На Rust'e можно. Поблемы не технические, а легаси и политика.
Pzz>Но почему бы на Go не быть написанным какому-нибудь почтовому демону, мне непонятно.
Почтовый доме можно написать на чем угодно, включая Питон.
Здравствуйте, Vetal_ca, Вы писали:
НС>>Serverless, опять же, ортогонален куберу. V_>Привязан к провайдеру. Как и Fargate для AWS
Т.е. вернулись к тому же самому — единственное неоспоримое преимущество кубера — некоторая стандартизация инфраструктуры — облака, PowerShift etc.
V_>Ты описываешь частный случай, Exposing logs directly from the application
Нет.
V_>Там еще есть более удобные варианты, можешь почитать на досуге.
Ты сам почитай на досуге
Kubernetes doesn't specify a logging agent, but two optional logging agents are packaged with the Kubernetes release: Stackdriver Logging for use with Google Cloud Platform, and Elasticsearch. You can find more information and instructions in the dedicated documents. Both use fluentd with custom configuration as an agent on the node.
НС>>Тебе список фамилий что ли нужен? Вся команда почти была задействована в той или иной мере. Это требование SOC. V_>То есть, не делали.
Если факты не подходят под теорию ...
НС>>Это совсем не главный вопрос, потому что главный вопрос это сам кубер, а не какой то очередной отдельный тул. V_>У меня лично, кубер не вопрос.
Ну так ты и не разработчик. И выводы, судя по всему, делаешь на основании своих личных задач, в кои поставки того или иного вида коробки не входят.
К примеру, если взять коробочные сервисы, то практически в 100% случаев там есть хелм, чуть реже есть еще docker-compose.yml. А вот терраформ ты будещь поддерживать сам.
Болтология проскипана. Полезной информации у тебя нет, а бесполезную преподносишь так, что красивее будет продолжать вариться тебе в собственном соку.
НС>Ну так ты и не разработчик. И выводы, судя по всему, делаешь на основании своих личных задач, в кои поставки того или иного вида коробки не входят. НС>К примеру, если взять коробочные сервисы, то практически в 100% случаев там есть хелм, чуть реже есть еще docker-compose.yml. А вот терраформ ты будещь поддерживать сам.
Чисто по "реальной" части:
1. Helm Charts я не пишу
2. 3D party компоненты прекрасно интегрируются и параметризуются с Terraform:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Внезапно перепрыгнули от разработчиков к внедрению? V_>>Если "без кубернетес можно" выливается в месяц работы и вагон гемора, то это, внезапно, не вариант. Отклонено. Теоретически — можно, практически — нет. НС>Практически настройка кубера занимает порой времени больше, чем без него.
В AWS сейчас это выглядит так: запускаем EKS, настраиваем роли и всё. EKS запускает контейнеры на Fargate-узлах по требованию: https://medium.com/better-programming/serverless-kubernetes-cluster-on-aws-with-eks-on-fargate-a7545cf179be
Я не про то как это в облака вывесить, а про то как собрать из кучи сервисов единый продукт. А то что EKS или AKS под готовое решение поднять не сложно я как бы в курсе.
