forum.opennet.ru - "Доступен атомарно обновляемый дистрибутив openSUSE Leap Micro 6.1 " (29)

"Доступен атомарно обновляемый дистрибутив openSUSE Leap Micro 6.1 "

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Доступен атомарно обновляемый дистрибутив openSUSE Leap Micro 6.1 "	+/–
Сообщение от opennews (??), 06-Дек-24, 21:18
Проект openSUSE опубликовал релиз атомарно обновляемого дистрибутива openSUSE Leap Micro 6.1, предназначенного для создания микросервисов и для использования в качестве базовой системы для платформ виртуализации и контейнерной изоляции. Для загрузки доступны установочные сборки для архитектур x86_64 и ARM64 (Aarch64), а также готовые системные образы для систем виртуализации... Подробнее: https://www.opennet.me/opennews/art.shtml?num=62359
Ответить \| Правка \| Cообщить модератору

Оглавление

Размеры совсем не микро Даже в 700 Мб не влазит , Анон1110м (?), 22:41 , 06-Дек-24, (7) +7

Да уж, настоящие алхимики ассемблерного кода умудряются впихнуть на дискету целу, Аноним (16), 02:38 , 07-Дек-24, (16) +2

И все конечно нею пользуются, verh010m (ok), 10:28 , 07-Дек-24, (26) –1
Они уже браузер кстати написали , Аноним (35), 17:37 , 07-Дек-24, (35) +1

в настройках добавили галку использовать джаваскрипт джаваскрипта нет, Аноним (40), 23:31 , 07-Дек-24, (40)

какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при помощ, crypt (ok), 18:31 , 07-Дек-24, (36)

Не знаю как у сусёвых, пробовал атомарщину от федорки и никсось, никсось субекти, Аноним (44), 11:30 , 12-Дек-24, (44)

а я пойду самым простым путем попробую вручную root на BTRFS сделать снапшоты, crypt (ok), 12:41 , 12-Дек-24, (46)

вот это даа, осилили man zramctl прочитать , Аноним (9), 22:48 , 06-Дек-24, (9) +2
есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное поделие, chdlb (?), 23:28 , 06-Дек-24, (10) +3

Если оно позволяет относительно экономно без пердолинга запускать инстансы с GUI, Аноним (44), 11:34 , 12-Дек-24, (45)

Объясните, плиз, в чем суть микросервисов Я помню в середине десятых годов был , Аноним (16), 02:43 , 07-Дек-24, (17)

Смотря что считать традиционным подходом Для нас традиционный подход -- это, Аноним (19), 04:13 , 07-Дек-24, (19)

Как бэ, есть разница Юниксвейная утилита написана раз и работает, обновляясь раз, YetAnotherOnanym (ok), 13:22 , 07-Дек-24, (31)
Умпутун из Radio-t вроде как не из этих, но микросервисы использует , Анон1110м (?), 20:16 , 07-Дек-24, (39)

Разрешаю вам пить фруктовый молочный коктейль когда вам захочется Нет же ниче, Аноним (19), 04:38 , 08-Дек-24, (41)

это когда вот ту самую серверную часть приложения разбирают на несколько приложе, chdlb (?), 04:39 , 07-Дек-24, (21) +3

Systemctl микросервис менеджер над сустемд д нужен , а мир отрицающих чужие нара, Mir_daynov (?), 07:11 , 07-Дек-24, (22) –2
Про то что микросервисы дают изоляцию, гибкость разработки, тестирования Да даж, Аноним (35), 09:19 , 07-Дек-24, (24)

изоляцию - дагибкость разработки - нетгибкость тестирования - нетпрямое следстви, chdlb (?), 10:27 , 07-Дек-24, (25)

О да в твоём мире все упирается в компетенцию каких то Васянов, которых ты не зн, Аноним (35), 10:52 , 07-Дек-24, (28) +1

ты ничего не понял из написанного, спрыгнул от архитектуры к процессу разработки, chdlb (?), 14:09 , 07-Дек-24, (32)

Не знаю Раньше было все то же самое большое приложение, его серверная часть, д, verh010m (ok), 10:37 , 07-Дек-24, (27)

Да, а документация как эти процессы у вас взаимодействуют была Я знаю что не бы, Аноним (35), 10:57 , 07-Дек-24, (29) +2

Микросервисы это и есть традиционный подход уже давно , Аноним (35), 09:07 , 07-Дек-24, (23)
зарабатывать деньги на лошках нормальные люди как писали unix-way-ные демоны, т, Аноним (33), 14:15 , 07-Дек-24, (33) +2
Если совсем коротко, то когда пишется сложная система, в которой есть больше пя, beck (??), 18:58 , 07-Дек-24, (37)

while true do a 124 b 124 c log doneдарю бесплатно перезапу, Аноним (33), 19:04 , 07-Дек-24, (38)

Но только на одной машине Можно, конечно, while true do a 124 ssh us, Аноним (19), 05:03 , 08-Дек-24, (42) –1

Сообщения [Сортировка по ответам | RSS]

7. Сообщение от Анон1110м (?), 06-Дек-24, 22:41 +7 +/–

Размеры совсем не микро. Даже в 700 Мб не влазит.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #36

9. Сообщение от Аноним (9), 06-Дек-24, 22:48 +2 +/–

>Добавлена возможность включения сжатия раздела подкачки при помощи модуля zRAM, размещающего сжатое блочное устройство в ОЗУ.
вот это даа, осилили man zramctl прочитать?

Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от chdlb (?), 06-Дек-24, 23:28 +3 +/–

есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное поделие

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45

16. Сообщение от Аноним (16), 07-Дек-24, 02:38 +2 +/–

Да уж, настоящие алхимики ассемблерного кода умудряются впихнуть на дискету целую полнофункциональную ос с кучей приложений

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #26, #35

17. Сообщение от Аноним (16), 07-Дек-24, 02:43 +/–

Объясните, плиз, в чем суть микросервисов? Я помню в середине десятых годов был прям жуткий хайп по ним, на том же хабре статьи сотнями на эту тему писали
Клиент сервер это мне понятно, а микросервисы что такое? Это чем то отличается от традиционного подхода? Откуда такая популярность, интересно просто

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19, #21, #23, #33, #37

19. Сообщение от Аноним (19), 07-Дек-24, 04:13 +/–

Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много маленьких программ, каждая из которых делает одну задачу, но делает её хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая идея, существующая с 1970 года, была открытием.
По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели юниксвей, только вместо IPC через пайпы или sunrpc у них теперь IPC через HTTP.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #31, #39

21. Сообщение от chdlb (?), 07-Дек-24, 04:39 +3 +/–

это когда вот ту самую серверную часть приложения разбирают на несколько приложений и все это крутится в бекенде взаимодействуя между собой по необходимости (HTTP, gRPC и тд)
смысла в этом особо нет, но "одаренным" это позволяет хоть что-то разнести по серверам, сделав систему распределенной (потому что по-другому не умеют или никогда не делали), хапнув проблем, о которых они изначально и не подозревали, но это будет сильно позже, когда проект пропишется в проде значительно
у такой архитекутуры есть реально пару стоящих кейсов, когда это может быть понадобиться, но большинство разрабатываемых приложений сделаны как раз по принципу micro-services for the sake of micro-services
по-хорошему тебе нужны микросервисы только тогда, когда тебе нужно изолировать часть твоего приложения и масштабировать ее отдельно, вот прям вынужден это делать по тем или иным причинам, во всех остальных случаях это в лучшем случае самообман, и микросервисы нахрен не нужны

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #22, #24

22. Сообщение от Mir_daynov (?), 07-Дек-24, 07:11 –2 +/–

Systemctl микросервис менеджер над сустемд д нужен , а мир отрицающих чужие наработки обезличенные и не инвестируемые из за мира обезьян и даунов захвативших власть над чужими транзакциями не нужен пока не станут человеками , накоа им вообще дали нфс оборудование пусть бы типографировали себе бумагу , аналоговым механическим методом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

23. Сообщение от Аноним (35), 07-Дек-24, 09:07 +/–

Микросервисы это и есть традиционный подход уже давно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

24. Сообщение от Аноним (35), 07-Дек-24, 09:19 +/–

Про то что микросервисы дают изоляцию, гибкость разработки, тестирования. Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь. Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь. В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #25, #27

25. Сообщение от chdlb (?), 07-Дек-24, 10:27 +/–

> Про то что микросервисы дают изоляцию, гибкость разработки, тестирования.
изоляцию - да
гибкость разработки - нет
гибкость тестирования - нет
> Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь.
прямое следствие изоляции, но нужная ли эта фрагментация? должна быть веская причина так делать (о чем я и говорил), а не просто микросервисы ради микросервисов (о чем я тоже говорил)
> Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь.
о сразу видно все знающего индюка с зашкаливающим ЧСВ, без коментариев ))
> В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.
абсолютно нет, это всего лишь означает, что несколько калек не смогли организовать процесс разработки
с каких это пор архитектура определяется структурой команд, а не наоборот? при таком подходе у тебя будет нагажено, что в монолитной системе, что в микросервисах, где бы там ни было...
более того качество интеграции отдельных модулей у тебя определяется степенью слаженности команды, а мы уже поняли, что в этом вопросе уровень - дно
и никто не мешает делать приложение модульным, но без микросервисов

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #28

26. Сообщение от verh010m (ok), 07-Дек-24, 10:28 –1 +/–

И все конечно нею пользуются

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

27. Сообщение от verh010m (ok), 07-Дек-24, 10:37 +/–

Не знаю. Раньше было все то же самое: большое приложение, его серверная часть, делилась на несколько отдельных процессов, которые держали связь между собой либо по сокету, либо по какому-нибудь именованносу пайпу, если так сильно хочется... И по сети всё это разносилось без проблем. Сейчас зачем-то решили все это обвязать кучей надстроек и изобрести новую профессию девопса. Или как оно там называется. Ну и, конечно, платить за это всяким амазонам. Так вижу

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #29

28. Сообщение от Аноним (35), 07-Дек-24, 10:52 +1 +/–

О да в твоём мире все упирается в компетенцию каких то Васянов, которых ты не знаешь. Они уйдут и всё развалится. Или даже просто постареет или заболеет. Слаженность команды ещё больший бред и что кто-то сверху её должен контролировать. Человек в среднем работает у тебя 2 года. Какая слаженность, какие калеки. Новый человек придет и сразу должен приступить к работе, а не разбираться в баш лапшах и прочей архитектуре. И выслушивать всяких токсиков типа тебя про такая у них компетенция.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #32

29. Сообщение от Аноним (35), 07-Дек-24, 10:57 +2 +/–

Да, а документация как эти процессы у вас взаимодействуют была? Я знаю что не было, а то что вы называли документацией это смех. Процесс взаимодействия должен быть стандартизован и воспроизводим, а не тут gprc, тут у нас баш скрипты, тут Вася помнит как работает и взаимодействует, только он в отпуске и выгорел. Выделить человека, который будет разбираться в этом цирке это вполне взвешенное решение. Ну или даже так если этот человек не в состоянии разобраться что весь этот цирк наворотил переписывайте чтобы было понятно. Так ясно?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

31. Сообщение от YetAnotherOnanym (ok), 07-Дек-24, 13:22 +/–

Как бэ, есть разница.
Юниксвейная утилита написана раз и работает, обновляясь раз несколько месяцев, а то и лет.
Микросервис пишется второпях, выкатывается в продакшон срочно-обморочно, с перспективой переписывания и редеплоя через неделю. Соответственно, фишка микросервисов с точки зрения бизнеса - возможность поправить что-то, не рискуя обрушить всю систему.
Иными словами, юниксвейные утилиты и микросервисы - это как байкеры в кожаных косухах на харлеях и байкеры в красных черепашках на ямахах.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

32. Сообщение от chdlb (?), 07-Дек-24, 14:09 +/–

ты ничего не понял из написанного, спрыгнул от архитектуры к процессу разработки, описывая своей унылый кейс и текучку ресурсов на вашем проекте
а ты кстати не думал, что отчасти эта текучка из-за состояния проекта, потому что он представляет из себя кусок субстанции? у вас смердит дилентанством во всем, вот и не задерживаются, и ни с чем не разбираются
ты пишешь про каких-то васянов, компетенции, я не понимаю этот бред, какое отношение это имеет ко мне?
а то что для работы микросервисов необходимо согласовывать версии API, данные, инфракструктуру тебя не смущает? притом у тебя нет ничего из раннего связывания, ни типов, ни проверок во время компиляции, ни сквозного тестирования, все что у тебя есть, твое согласование полностью зависит от эффективности взаимодействия команд, где текучка 50% в год, и само это взаимодействие ущербное с твоих же слов
т.е. то от чего зависят микросервисы в твоем случае самое проблемное место, фактически у тебя не микросервисы, а просто наколенные поделия, код которых тебе кажется проще сопровождать потому что они в разных кодовых базах, когда очередную наколенку можно изолировать в виде микросервиса...
по сути своей это проект костылей, а не микросервисов

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от Аноним (33), 07-Дек-24, 14:15 +2 +/–

> Объясните, плиз, в чем суть микросервисов?
зарабатывать деньги на лошках. нормальные люди как писали unix-way-ные демоны, так и пишут

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

35. Сообщение от Аноним (35), 07-Дек-24, 17:37 +1 +/–

Они уже браузер кстати написали?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #40

36. Сообщение от crypt (ok), 07-Дек-24, 18:31 +/–

какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в себе, за гранью юзабилити.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #44

37. Сообщение от beck (??), 07-Дек-24, 18:58 +/–

> Объясните, плиз, в чем суть микросервисов?
Если совсем коротко,  то когда пишется сложная система, в которой есть больше пяти взаимодействующих друг с другом блоков, то к этому всему нужна некая управлялка этими блоками, запуск, логи, распределение памяти и прочих ресурсов.
Микросервисы несут идею, что эту управлялку некты напейсали до тебя,  и можно ея взять и пользоваться, ну там в конфигах девопсы поиграют и всё отлично будет.
Проблема в том, что блоки в системе практически всегда друг с другом бизнес-логически связаны и, условно, если один блок упал, то и вся система тоже упала, а не просто какой-то кубер в докере передёрнул какой-то сервис и пляши дальше.
Несомненно,  есть какая-то часть задач, которые можно решить микросервисным подходом. Но их немного.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #38

38. Сообщение от Аноним (33), 07-Дек-24, 19:04 +/–

while [ true ]; do ./a | ./b | ./c > log ; done
дарю бесплатно перезапуск, модульность и логи

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #42

39. Сообщение от Анон1110м (?), 07-Дек-24, 20:16 +/–

> Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много
> маленьких программ, каждая из которых делает одну задачу, но делает её
> хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая
> идея, существующая с 1970 года, была открытием.
> По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели
> юниксвей, только вместо IPC через пайпы или sunrpc у них теперь
> IPC через HTTP.
Умпутун из Radio-t вроде как не из этих, но микросервисы использует.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #41

40. Сообщение от Аноним (40), 07-Дек-24, 23:31 +/–

в настройках добавили галку "использовать джаваскрипт"
джаваскрипта нет

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

41. Сообщение от Аноним (19), 08-Дек-24, 04:38 +/–

Разрешаю вам пить фруктовый молочный коктейль когда вам захочется :).
Нет же ничего плохого в микросервисах. Главное, чтобы дизайн был ортогональным и взаимодействие между компонентами как-нибудь разумно сделано.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

42. Сообщение от Аноним (19), 08-Дек-24, 05:03 –1 +/–

Но только на одной машине.
Можно, конечно,
while [[ true ]]; do ./a | ssh user@server:~/b | ./c > log ; done
но тоже, ну так... стартовать процесс на каждого клиента плохо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

44. Сообщение от Аноним (44), 12-Дек-24, 11:30 +/–

> какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при
> помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в
> себе, за гранью юзабилити.
Не знаю как у сусёвых, пробовал атомарщину от федорки и никсось, никсось субективно быстрее и меньше занимает после чистки мусора.
Но это так, наблюдение, боже упаси не топлю за никсось с её необходимостью чистать талмуды текста и искать порой альтернативные решения на фоне с беглым ознакомлением с федоркиной атомарщиной! Сам хочу попробовать что-то сусёвое, но руки не доходят, ленивый стал.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46

45. Сообщение от Аноним (44), 12-Дек-24, 11:34 +/–

> есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное
> поделие
Если оно позволяет относительно экономно без пердолинга запускать инстансы с GUI-софтом, то почему нет-то?
А если не позволяет, то тогда я не понимаю зачем оно нужно, ещё один велосипедный огород из-за NIH-синдрома?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

46. Сообщение от crypt (ok), 12-Дек-24, 12:41 +/–

> но руки не доходят, ленивый стал.
а я пойду самым простым путем. попробую вручную root на BTRFS сделать. "снапшоты для бедных, как в ZFS". если ФС похожие, то должно получиться.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

7. Сообщение от Анон1110м (?), 06-Дек-24, 22:41	+7 +/–
Размеры совсем не микро. Даже в 700 Мб не влазит.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #16, #36

9. Сообщение от Аноним (9), 06-Дек-24, 22:48	+2 +/–
>Добавлена возможность включения сжатия раздела подкачки при помощи модуля zRAM, размещающего сжатое блочное устройство в ОЗУ. вот это даа, осилили man zramctl прочитать?
Ответить \| Правка \| Наверх \| Cообщить модератору

10. Сообщение от chdlb (?), 06-Дек-24, 23:28	+3 +/–
есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное поделие
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #45

16. Сообщение от Аноним (16), 07-Дек-24, 02:38	+2 +/–
Да уж, настоящие алхимики ассемблерного кода умудряются впихнуть на дискету целую полнофункциональную ос с кучей приложений
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #26, #35

17. Сообщение от Аноним (16), 07-Дек-24, 02:43	+/–
Объясните, плиз, в чем суть микросервисов? Я помню в середине десятых годов был прям жуткий хайп по ним, на том же хабре статьи сотнями на эту тему писали Клиент сервер это мне понятно, а микросервисы что такое? Это чем то отличается от традиционного подхода? Откуда такая популярность, интересно просто
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #19, #21, #23, #33, #37

19. Сообщение от Аноним (19), 07-Дек-24, 04:13	+/–
Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много маленьких программ, каждая из которых делает одну задачу, но делает её хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая идея, существующая с 1970 года, была открытием. По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели юниксвей, только вместо IPC через пайпы или sunrpc у них теперь IPC через HTTP.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #31, #39

21. Сообщение от chdlb (?), 07-Дек-24, 04:39	+3 +/–
это когда вот ту самую серверную часть приложения разбирают на несколько приложений и все это крутится в бекенде взаимодействуя между собой по необходимости (HTTP, gRPC и тд) смысла в этом особо нет, но "одаренным" это позволяет хоть что-то разнести по серверам, сделав систему распределенной (потому что по-другому не умеют или никогда не делали), хапнув проблем, о которых они изначально и не подозревали, но это будет сильно позже, когда проект пропишется в проде значительно у такой архитекутуры есть реально пару стоящих кейсов, когда это может быть понадобиться, но большинство разрабатываемых приложений сделаны как раз по принципу micro-services for the sake of micro-services по-хорошему тебе нужны микросервисы только тогда, когда тебе нужно изолировать часть твоего приложения и масштабировать ее отдельно, вот прям вынужден это делать по тем или иным причинам, во всех остальных случаях это в лучшем случае самообман, и микросервисы нахрен не нужны
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #22, #24

22. Сообщение от Mir_daynov (?), 07-Дек-24, 07:11	–2 +/–
Systemctl микросервис менеджер над сустемд д нужен , а мир отрицающих чужие наработки обезличенные и не инвестируемые из за мира обезьян и даунов захвативших власть над чужими транзакциями не нужен пока не станут человеками , накоа им вообще дали нфс оборудование пусть бы типографировали себе бумагу , аналоговым механическим методом.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21

23. Сообщение от Аноним (35), 07-Дек-24, 09:07	+/–
Микросервисы это и есть традиционный подход уже давно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

24. Сообщение от Аноним (35), 07-Дек-24, 09:19	+/–
Про то что микросервисы дают изоляцию, гибкость разработки, тестирования. Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь. Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь. В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #25, #27

25. Сообщение от chdlb (?), 07-Дек-24, 10:27	+/–
> Про то что микросервисы дают изоляцию, гибкость разработки, тестирования. изоляцию - да гибкость разработки - нет гибкость тестирования - нет > Да даже просто возможность разработки на разных языках ты упоминать конечно же не хочешь. прямое следствие изоляции, но нужная ли эта фрагментация? должна быть веская причина так делать (о чем я и говорил), а не просто микросервисы ради микросервисов (о чем я тоже говорил) > Потому что все свои сервисы ты пилишь в одного, а тесты вообще не пишешь. о сразу видно все знающего индюка с зашкаливающим ЧСВ, без коментариев )) > В любые проектах где больше одного разработчика одновременно микросервисы это мастхевейший мастхев. абсолютно нет, это всего лишь означает, что несколько калек не смогли организовать процесс разработки с каких это пор архитектура определяется структурой команд, а не наоборот? при таком подходе у тебя будет нагажено, что в монолитной системе, что в микросервисах, где бы там ни было... более того качество интеграции отдельных модулей у тебя определяется степенью слаженности команды, а мы уже поняли, что в этом вопросе уровень - дно и никто не мешает делать приложение модульным, но без микросервисов
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #28

26. Сообщение от verh010m (ok), 07-Дек-24, 10:28	–1 +/–
И все конечно нею пользуются
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16

27. Сообщение от verh010m (ok), 07-Дек-24, 10:37	+/–
Не знаю. Раньше было все то же самое: большое приложение, его серверная часть, делилась на несколько отдельных процессов, которые держали связь между собой либо по сокету, либо по какому-нибудь именованносу пайпу, если так сильно хочется... И по сети всё это разносилось без проблем. Сейчас зачем-то решили все это обвязать кучей надстроек и изобрести новую профессию девопса. Или как оно там называется. Ну и, конечно, платить за это всяким амазонам. Так вижу
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #29

28. Сообщение от Аноним (35), 07-Дек-24, 10:52	+1 +/–
О да в твоём мире все упирается в компетенцию каких то Васянов, которых ты не знаешь. Они уйдут и всё развалится. Или даже просто постареет или заболеет. Слаженность команды ещё больший бред и что кто-то сверху её должен контролировать. Человек в среднем работает у тебя 2 года. Какая слаженность, какие калеки. Новый человек придет и сразу должен приступить к работе, а не разбираться в баш лапшах и прочей архитектуре. И выслушивать всяких токсиков типа тебя про такая у них компетенция.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25 Ответы: #32

29. Сообщение от Аноним (35), 07-Дек-24, 10:57	+2 +/–
Да, а документация как эти процессы у вас взаимодействуют была? Я знаю что не было, а то что вы называли документацией это смех. Процесс взаимодействия должен быть стандартизован и воспроизводим, а не тут gprc, тут у нас баш скрипты, тут Вася помнит как работает и взаимодействует, только он в отпуске и выгорел. Выделить человека, который будет разбираться в этом цирке это вполне взвешенное решение. Ну или даже так если этот человек не в состоянии разобраться что весь этот цирк наворотил переписывайте чтобы было понятно. Так ясно?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #27

31. Сообщение от YetAnotherOnanym (ok), 07-Дек-24, 13:22	+/–
Как бэ, есть разница. Юниксвейная утилита написана раз и работает, обновляясь раз несколько месяцев, а то и лет. Микросервис пишется второпях, выкатывается в продакшон срочно-обморочно, с перспективой переписывания и редеплоя через неделю. Соответственно, фишка микросервисов с точки зрения бизнеса - возможность поправить что-то, не рискуя обрушить всю систему. Иными словами, юниксвейные утилиты и микросервисы - это как байкеры в кожаных косухах на харлеях и байкеры в красных черепашках на ямахах.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19

32. Сообщение от chdlb (?), 07-Дек-24, 14:09	+/–
ты ничего не понял из написанного, спрыгнул от архитектуры к процессу разработки, описывая своей унылый кейс и текучку ресурсов на вашем проекте а ты кстати не думал, что отчасти эта текучка из-за состояния проекта, потому что он представляет из себя кусок субстанции? у вас смердит дилентанством во всем, вот и не задерживаются, и ни с чем не разбираются ты пишешь про каких-то васянов, компетенции, я не понимаю этот бред, какое отношение это имеет ко мне? а то что для работы микросервисов необходимо согласовывать версии API, данные, инфракструктуру тебя не смущает? притом у тебя нет ничего из раннего связывания, ни типов, ни проверок во время компиляции, ни сквозного тестирования, все что у тебя есть, твое согласование полностью зависит от эффективности взаимодействия команд, где текучка 50% в год, и само это взаимодействие ущербное с твоих же слов т.е. то от чего зависят микросервисы в твоем случае самое проблемное место, фактически у тебя не микросервисы, а просто наколенные поделия, код которых тебе кажется проще сопровождать потому что они в разных кодовых базах, когда очередную наколенку можно изолировать в виде микросервиса... по сути своей это проект костылей, а не микросервисов
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #28

33. Сообщение от Аноним (33), 07-Дек-24, 14:15	+2 +/–
> Объясните, плиз, в чем суть микросервисов? зарабатывать деньги на лошках. нормальные люди как писали unix-way-ные демоны, так и пишут
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

35. Сообщение от Аноним (35), 07-Дек-24, 17:37	+1 +/–
Они уже браузер кстати написали?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #40

36. Сообщение от crypt (ok), 07-Дек-24, 18:31	+/–
какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в себе, за гранью юзабилити.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #44

37. Сообщение от beck (??), 07-Дек-24, 18:58	+/–
> Объясните, плиз, в чем суть микросервисов? Если совсем коротко, то когда пишется сложная система, в которой есть больше пяти взаимодействующих друг с другом блоков, то к этому всему нужна некая управлялка этими блоками, запуск, логи, распределение памяти и прочих ресурсов. Микросервисы несут идею, что эту управлялку некты напейсали до тебя, и можно ея взять и пользоваться, ну там в конфигах девопсы поиграют и всё отлично будет. Проблема в том, что блоки в системе практически всегда друг с другом бизнес-логически связаны и, условно, если один блок упал, то и вся система тоже упала, а не просто какой-то кубер в докере передёрнул какой-то сервис и пляши дальше. Несомненно, есть какая-то часть задач, которые можно решить микросервисным подходом. Но их немного.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #38

38. Сообщение от Аноним (33), 07-Дек-24, 19:04	+/–
while [ true ]; do ./a \| ./b \| ./c > log ; done дарю бесплатно перезапуск, модульность и логи
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #37 Ответы: #42

39. Сообщение от Анон1110м (?), 07-Дек-24, 20:16	+/–
> Смотря что считать "традиционным подходом". Для нас "традиционный подход" -- это много > маленьких программ, каждая из которых делает одну задачу, но делает её > хорошо. Но для любителей фруктовых молочных коктейлей из 2015 года такая > идея, существующая с 1970 года, была открытием. > По сути "микросервисы" -- это просто любители фруктовых молочных коктейлей переизобрели > юниксвей, только вместо IPC через пайпы или sunrpc у них теперь > IPC через HTTP. Умпутун из Radio-t вроде как не из этих, но микросервисы использует.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19 Ответы: #41

40. Сообщение от Аноним (40), 07-Дек-24, 23:31	+/–
в настройках добавили галку "использовать джаваскрипт" джаваскрипта нет
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #35

41. Сообщение от Аноним (19), 08-Дек-24, 04:38	+/–
Разрешаю вам пить фруктовый молочный коктейль когда вам захочется :). Нет же ничего плохого в микросервисах. Главное, чтобы дизайн был ортогональным и взаимодействие между компонентами как-нибудь разумно сделано.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #39

42. Сообщение от Аноним (19), 08-Дек-24, 05:03	–1 +/–
Но только на одной машине. Можно, конечно, while [[ true ]]; do ./a \| ssh user@server:~/b \| ./c > log ; done но тоже, ну так... стартовать процесс на каждого клиента плохо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #38

44. Сообщение от Аноним (44), 12-Дек-24, 11:30	+/–
> какие еще редакции сузе или не сузе позволяют делать атомарные апдейты при > помощи BTRFS? ostree (silverlight) федоровский пробовал - тормозит, как не в > себе, за гранью юзабилити. Не знаю как у сусёвых, пробовал атомарщину от федорки и никсось, никсось субективно быстрее и меньше занимает после чистки мусора. Но это так, наблюдение, боже упаси не топлю за никсось с её необходимостью чистать талмуды текста и искать порой альтернативные решения на фоне с беглым ознакомлением с федоркиной атомарщиной! Сам хочу попробовать что-то сусёвое, но руки не доходят, ленивый стал.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #36 Ответы: #46

45. Сообщение от Аноним (44), 12-Дек-24, 11:34	+/–
> есть у меня openSUSE Leap но вот конкретно Micro - совсем бессмысленное > поделие Если оно позволяет относительно экономно без пердолинга запускать инстансы с GUI-софтом, то почему нет-то? А если не позволяет, то тогда я не понимаю зачем оно нужно, ещё один велосипедный огород из-за NIH-синдрома?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

46. Сообщение от crypt (ok), 12-Дек-24, 12:41	+/–
> но руки не доходят, ленивый стал. а я пойду самым простым путем. попробую вручную root на BTRFS сделать. "снапшоты для бедных, как в ZFS". если ФС похожие, то должно получиться.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #44