Комментарии 4
забавно, что только на этой стадии
На этой стадии можно начинать мыслить конструктивно
Увеличилось быстродействие — переход с Akka на Spring в среднем увеличил производительность REST в 1,5—2 раза.
Вспоминается известный сценарий: в плохо организованном проекте на PHP возникает евангелист Go, переписывает всё с нуля, а затем приписывает весь прирост скорости самому языку, забывая, что главная проблема может быть в неудачной реализации.
И в этой статье примерно так же, многие аргументы звучат не как объективный анализ технологий, а больше как "не умею или не хочу разбираться с тем, что есть, поэтому затащу любимый Spring".
Рубрика: каждые пять лет в сбере обязательно кто-то приходит, и требует срочно переделать все. Зачем, почему, какие у этого будут трудозатраты - не важно. Просто надо.
Казалось бы сами пишите: "В проекте, который изначально запускали на вполне нормальном техстеке — Scala, Akka, Akka HTTP". А в чем проблема заняться рефакторингом? Стек нормальный. а основная боль судя по всему в том, что "через четыре года разработки периодически меняющейся командой подрядчиков появился зоопарк из Akka, Akka HTTP, Akka Streams, Cats, Zio, Monix, Scalike jDBC, Quill, Monocle, Tapir, Play, Circe и ещ` десятка малоизученных эзотерических библиотек суммарно с сотней звёзд на Github".
Ради этого надо было все тащить в кубер, переделывать монолит на микросервисы, полностью менять техстек?
Итог неутешительный: "Почти полностью сменился состав команды backend-разработки". И все ради того, чтобы в среднем увеличилось производительность REST в 1,5—2 раза, чего бы вы добились с куда меньшими трудозатрами, просто по-нормальному текущий проект переписав.
Со Scala-монолита на Java-микросервисы, или Как перебрать движок, не останавливая машину