Микросервисы кажутся удобнее, ведь как бы есть четкий протокол и небольшие системы, каждая из которых выполняет не сложную задачу. Ну и как бы встроенное масштабирование малой кровью за счет некой шины обмены данными/событиями — подключай к шине сколько тебе нужно нод.
Но на практике, как обычно, оказалось не все так радужно
Здравствуйте, Shmj, Вы писали:
S>Микросервисы кажутся удобнее, ведь как бы есть четкий протокол и небольшие системы, каждая из которых выполняет не сложную задачу. Ну и как бы встроенное масштабирование малой кровью за счет некой шины обмены данными/событиями — подключай к шине сколько тебе нужно нод.
Это никому не нужно, более того — вредно. Такая архитектура безцельной повсеместной масшабируемости одна из причин почему Cassandra опасно применять в продукции.
S>Но на практике, как обычно, оказалось не все так радужно
На моей памяти этот подход с микросервисами изобретают 5-ый раз. И каждый раз все должно быть суперкруто на этот раз, но вот опять не получается.
Удивительно, правда?
Здравствуйте, Shmj, Вы писали:
S>Тут: https://habr.com/en/articles/733786/
S>Микросервисы кажутся удобнее, ведь как бы есть четкий протокол и небольшие системы, каждая из которых выполняет не сложную задачу. Ну и как бы встроенное масштабирование малой кровью за счет некой шины обмены данными/событиями — подключай к шине сколько тебе нужно нод.
Недавно набрел на видос на тему микросервисов, тру стори во второй половине https://youtu.be/s-vJcOfrvi0
S>Но на практике, как обычно, оказалось не все так радужно
На практике микросервисы ВСЕГДА работают хуже монолита. Преимущество микросервисов в масштабировании разработки, чтобы огромное количество разработчиков могли регулярно выдавать релизы не ломая систему полностью. И то если придерживаться строгих правил изоляции этих самых микросервисов.
Здравствуйте, Shmj, Вы писали:
S>Тут: https://habr.com/en/articles/733786/
S>Микросервисы кажутся удобнее, ведь как бы есть четкий протокол и небольшие системы, каждая из которых выполняет не сложную задачу. Ну и как бы встроенное масштабирование малой кровью за счет некой шины обмены данными/событиями — подключай к шине сколько тебе нужно нод.
S>Но на практике, как обычно, оказалось не все так радужно
Это доказательство только одного: "Если в башне по...нь, то что е...нь, что не е...нь". Ибо засовывать в S3 промежуточные кадры при генерации видео (если статья не врёт) было запредельной шизой с самого начала.
— Ребе, у меня дома тесно, друг у друга на головах сидим!
— Введи в дом корову.
— Ребе, теперь даже повернуться негде!
— Убери корову из дома.
— Ребе, спасибо, стало так свободно!
Ну и что толку с этого рассказа, кроме того, что автора решения надо было уволить с самого начала?
Здравствуйте, Shmj, Вы писали:
S>Но на практике, как обычно, оказалось не все так радужно
Микросервисы — это инструмент, и инструмент опасный, не для фанатиков и бездумного применения. Я бы сказал, что главное назначение микросервисов — управление сложностью системы. Можно написать код в 200 строчек, можно наворотить 20 взаимосвязанных классов. На уровне микросервисов это выглядит точно так же.
Про микросервисы судить не буду. Наверное на каком-то масштабе они неизбежны. Вроде у всех крупных компаний они. Я таких проектов не видел.
Монолит в экстремуме это однозначно дурость. Если у меня есть человек, который на питоне делает ИИ, правильней этот модуль обернуть в докер и вызывать. А не переписывать на го.
Также часто есть отдельные задачи, очевидно требующие масштабирования. Ну к примеру перекодировка видео. Запускать новый инстанс монолита (и вообще проектировать монолит под кластерность) только потому, что у тебя на сервере закончился CPU это тупо. Выделить перекодировку видео в отдельный сервис из ста строк, и масштабировать только его — правильно. Вы же не суёте постгрес в адресное пространство бэкэнда.
Также есть отдельные задачи, легко решающиеся на одном стеке технологий и сложно решающиеся на другом. К примеру в Казахстане используется своя криптография. Есть библиотека для Java. Код на Java это несколько сотен строк. Переписывать эти библиотеки на Go (к которым нет исходников), потом по-хорошему эту новую реализацию ещё и сертифицировать в КНБ надо будет. Удачи, ага. Не, я бы взялся, если кому-то охота потратить пару лет. Но всем охота потратить пару дней.
Резюмируя — начинать надо с монолита, но не стесняться выделять из него то, что "просится" выделиться в отдельные сервисы, а не впихивать невпихуемое.
А насчёт прям полноценных микросервисов сказать ничего не могу. Пока нужды такой не было.
Здравствуйте, scf, Вы писали:
S>>Но на практике, как обычно, оказалось не все так радужно
scf>Микросервисы — это инструмент, и инструмент опасный, не для фанатиков и бездумного применения. Я бы сказал, что главное назначение микросервисов — управление сложностью системы. Можно написать код в 200 строчек, можно наворотить 20 взаимосвязанных классов. На уровне микросервисов это выглядит точно так же.
С микросервисами проще — можно посадить девопс-обезъян, чтобы разруливали, и разрабов не трогали. В монолите весь головняк на разрабах
Здравствуйте, Marty, Вы писали:
S>>>Но на практике, как обычно, оказалось не все так радужно
scf>>Микросервисы — это инструмент, и инструмент опасный, не для фанатиков и бездумного применения. Я бы сказал, что главное назначение микросервисов — управление сложностью системы. Можно написать код в 200 строчек, можно наворотить 20 взаимосвязанных классов. На уровне микросервисов это выглядит точно так же.
M>С микросервисами проще — можно посадить девопс-обезъян, чтобы разруливали, и разрабов не трогали. В монолите весь головняк на разрабах
Только в этой трактовке обезьяны будут разработчики. Т.к. их огораживают в клетки.
Здравствуйте, Shmj, Вы писали:
S>Но на практике, как обычно, оказалось не все так радужно
Есть две типичные ошибки, которые мы все так любим допускать.
1. Если что-то работает хорошо для нас в конкретной ситуации, то мы пытаемся запихать это во все дырки и убедить всех окружающих, что им без этого никак не прожить, и если они это не используют, то они лохи и дураки.
2. Если что-то работает плохо для нас в конкретной ситуации, то мы недемленно предаём это анафеме, всячески пытаемся оградить от этого всех окружающих, и если они это всё же используют, то они лохи и дураки.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Marty, Вы писали:
M>С микросервисами проще — можно посадить девопс-обезъян, чтобы разруливали,
Максимум неэтичное отношение к девопсам. M>и разрабов не трогали. В монолите весь головняк на разрабах
Первое что сделают девопсы если есть проблемы с развёртыванием или интеграцией это пойдут к девелоперам которые будут вынуждены разбираться что же такое происходит в деплое.
G>На практике микросервисы ВСЕГДА работают хуже монолита. Преимущество микросервисов в масштабировании
заработков на G>разработке, чтобы огромное количество разработчиков могли регулярно
кормиться там, где достаточно небольшой команды
Старый доктор оставил вместо себя сына, недавно окончившего мединститут, и уехал в отпуск. Возвращается, а сын ему заявляет:
— Я тут Павла Моисеевича вылечил. Ты его тридцать лет лечил, а я его — за один месяц!
— Идиот! Я на его почках тебя выучил, машину купил, дачу построил... А ты его... вылечил!!!
vsb>Также есть отдельные задачи, легко решающиеся на одном стеке технологий и сложно решающиеся на другом. К примеру в Казахстане используется своя криптография. Есть библиотека для Java. Код на Java это несколько сотен строк. Переписывать эти библиотеки на Go (к которым нет исходников), потом по-хорошему эту новую реализацию ещё и сертифицировать в КНБ надо будет. Удачи, ага. Не, я бы взялся, если кому-то охота потратить пару лет. Но всем охота потратить пару дней.
Неужели это настолько экзотичная криптография, что её нет в OpenSSL/LibreSSL/WolfSSL?
Здравствуйте, Shmj, Вы писали:
S>Тут: https://habr.com/en/articles/733786/
S>Микросервисы кажутся удобнее, ведь как бы есть четкий протокол и небольшие системы, каждая из которых выполняет не сложную задачу. Ну и как бы встроенное масштабирование малой кровью за счет некой шины обмены данными/событиями — подключай к шине сколько тебе нужно нод.
S>Но на практике, как обычно, оказалось не все так радужно
Вот как должна быть организована работа программиста, там где в вакансиях указано ci/cd и прочие подобные дела?
Вот мне нужно внести изменения в какой-то кусок проекта, этот кусок представлен одним решением в VS, я могу его запустить у себя на компьютере что бы погонять в отладчике, мне для этого не нужна бд где-то в стороне, я бд с нужными ему данными подымаю у себя на компе(делаю экспорт) В проекте есть тесты, все зависимости заменены заглушками. Я вношу изменения, запускаю тесты, убеждаюсь что все хорошо, делаю коммит пушу в репо, а дальше работает автоматика на ci/cd сервере и этап ручного тестирования если он у нас есть. В общем если, мой код принят, то мои проблемы как программиста закончились.
Вот микросервисы под такую организацию работы идеально подходят.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Неужели это настолько экзотичная криптография, что её нет в OpenSSL/LibreSSL/WolfSSL?
Подвиды ГОСТа. Я детально в этом не разбираюсь. Может и есть, но там есть нюансы. Во-первых "одобренная" библиотека имеет какой-то сертификат от КНБ. Утверждается, что если пишешь реализацию сам или используешь неодобренную, то надо проходить сертификацию в КНБ, а это вероятно геморрой. Звучит страннно, но пробовать большого желания нет.
Помимо этого есть ещё Web Services Security, XML Security. Там тоже руками ничего не напишешь, там всякая муть, трансформы и прочее. В общем библиотека работает и даёт результат (подпись принимается, чужая подпись проверяется). А своя или ещё какая-то реализация вполне может не работать, а связи с "той стороной" особо нет, приходит тебе ошибка и всё тут.
Если интересны названия алгоритмов из местной документации, то вот:
Алгоритм хеширования ГОСТ 34.311
Алгоритм ГОСТ 34.310
Алгоритм подписи ГОСТ 34.310
Алгоритм шифрования ГОСТ 28147-89
ГОСТ 34.310-2004
Алгоритм подписи ГОСТ 34.310 (4)
Алгоритм подписи ГОСТ Р 34.10
Алгоритм подписи ГОСТ 34.310 (3)
Алгоритм подписи ГОСТ 34.310 (4)
СТ РК ГОСТ Р 34.10-2015
Подпись СТ РК ГОСТ Р 34.10-2015 с хэшированием СТ РК ГОСТ Р 34.11-2015 (256)
Подпись СТ РК ГОСТ Р 34.10-2015 с хэшированием СТ РК ГОСТ Р 34.11-2015 (512)
ГОСТ 34.11-95
Насколько я понимаю, тут несколько базовых алгоритмов из семейства ГОСТ и куча их вариаций и сочетаний.
Q> дальше работает автоматика на ci/cd сервере и этап ручного тестирования если он у нас есть. В общем если, мой код принят, то мои проблемы как программиста закончились.
В теории оно так, а на практике тебе придется таки разобраться, что где происходит, и почему твой код то старой версии, то новой, то "отсутствует allocation", то "мы тебе включили auto-scaling, иди перепиши весь свой сервис".
Здравствуйте, SkyDance, Вы писали:
Q>> дальше работает автоматика на ci/cd сервере и этап ручного тестирования если он у нас есть. В общем если, мой код принят, то мои проблемы как программиста закончились.
SD>В теории оно так, а на практике тебе придется таки разобраться, что где происходит, и почему твой код то старой версии, то новой, то "отсутствует allocation", то "мы тебе включили auto-scaling, иди перепиши весь свой сервис".
Я конечно не много с идеализировал, но то что микросервисы позволяют легко и просто настроить удобный рабочий процесс — это их преимущество. Можно конечно и без микросервисов это сделать, но тут уже нужно уметь.
Q>Я конечно не много с идеализировал, но то что микросервисы позволяют легко и просто настроить удобный рабочий процесс — это их преимущество. Можно конечно и без микросервисов это сделать, но тут уже нужно уметь.
С микросервисами уметь надо куда больше.
К тому же почти всегда микросервисы рано или поздно превращаются в распределенный монолит.
Если нам не помогут, то мы тоже никого не пощадим.
