Комментарии 21
Есть вопросы с обоснованием зачем это все нужно.
Времена меняются, и теперь у нас повсеместно облака и Kubernetes.
И микросервисы. Основная идея которых, быть небольшими и довольно легкими. Да, стартуют они не моментально, но гораздо шустрее монолита. И эта скорость вполне может устраивать. Грубо говоря, пустое приложение на Spring Boot стартует за пару секунд. Потом на него навешают всякие валидации схем БД, накатывание миграций и прочее и стартовать он станет минуту (тут, кстати, вопрос что делать со всем этим в нативном приложении). Но все равно, даже такая цифра для многих сценариев энтерпрайза вполне себе норм.
Кубер перезапускает приложения
Да, но если он это делает часто, то зачастую это сигнал о том, что с приложением что-то не то.
Поэтому нам важна скорость перезапуска и количество используемой оперативной памяти.
У вас есть информация по использованию памяти? Интересно насколько эффективно это получается у нативного приложения? По идее, размер heap же никак не уменьшается.
Частично согласен, частично нет. Попробую развернуть
Если говорить об энтерпрайзах, вопрос не в том, что "достаточно-недостаточно", а что можно сэкономить ещё. Если компания в месяц тратит на облако десять миллионов рублей, то 10% это уже приличная сумма, на которую можно купить нескольких синьоров. В реальности, большие компании тратят сильно больше.
Представь, вот у тебя какая-то система, состоящая из нескольких сотен микросервисов. (Насколько помню, в Альфе кор занимает что-то в районе трех сотен, слышал на каком-то митапе. А у Нетфликса там под тысячу). И каждый из них обернут в условный Spring Boot, который отжирает память у каждого из микросервисов снова и снова, на одно и то же. Это очень много бесцельно потраченных ресурсов!
Наверное, можно представить менеджера энтерпрайза, которого не волнуют деньги, в том числе что на его личную премию капнет 10% от сэкономленных 10% (лишняя сотня тысяч в примере выше), но это точно массовый чел?)
Да, но если он это делает часто, то зачастую это сигнал о том, что с приложением что-то не то.
А в большой системе у тебя всегда есть что-то, что не работает, и это тратит деньги :)
А еще у тебя может постоянно меняться скейлинг в зависимости от того, сколько людей набежало (условный Нетфликс, в котором утром нет никого, а под вечер есть кто-то), или когда загрузка меняется между регионами (когда Восток спит, Запад еще смотрит), или еще что-то.
А еще у тебя аджайл, и разработчики каждые 10 минут выкатывают новую версию какого-нибудь микросервиса, одного из сотен, и их нужо там двигать, иногда каскадно перезапускать...
По идее, размер heap же никак не уменьшается.
Рабочие данные магически, конечно, никуда не ужмутся. Да и производительность сборщика мусора на достаточно больших данных (сотни гигабайт) заставит заплакать. А вот размер приложения может сократиться очень сильно.
Там в статье очень непросто есть этот раздел про JIT vs AOT.
Мы эксплицитно говорим, что нам нужна максимальная скорость деплоймента, минимальный размер и атомарность поставки. И взамен мы готовы пожертвовать пиковой производительностью и эффективностью работы с памятью (микросервисы на то и микросервисы, что они не должны тратить много памяти).
Если тебе не подходит такая сделка, и тебе нужна монолитная пиковая производительность в произвольном месте приложения, работа с терабайтами данных - эта технология не для тебя.
Точно так же тебе тогда не нужен Go и Python на продакшене, у них со всем этим тоже так себе дела обстоят.
И каждый из них обернут в условный Spring Boot, который отжирает память у каждого из микросервисов снова и снова, на одно и то же. Это очень много бесцельно потраченных ресурсов!
Поэтому и хотелось узнать информацию, сколько именно выиграем по памяти от использования native. Т.е. какие-то цифры (проценты или мб). Почему условный Spring Boot вдруг перестанет жрать память? Короче, есть подозрение, что это экономия на спичках.
Рабочие данные магически, конечно, никуда не ужмутся. А вот размер приложения может сократиться очень сильно
Сильно это насколько?
Там в статье очень непросто есть этот раздел про JIT vs AOT.
В статье нашел только околомаркетинговую картинку.
Наверное, можно представить менеджера энтерпрайза, которого не волнуют деньги, в том числе его личная премия, но это точно массовый чел?)
Наверное, можно представить менеджера энтерпрайза, которого не волнует, что фичи не вывели вовремя в прод потому, что разрабы пытаются отладить и собрать нативное чудо, но это точно массовый чел? )
Если тебе не подходит такая сделка, и тебе нужна монолитная пиковая производительность в произвольном месте приложения, работа с терабайтами данных - эта технология не для тебя.
Вот и хочется понять, кому может подойти такая сделка. Пока получается, что пригодится тем, кому постоянно требуется перезапускать приложение.
Точно так же тебе тогда не нужен Go и Python на продакшене, у них со всем этим тоже так себе дела обстоят.
вот мне тоже показалось что AOT режим метит в нишу Go - быстро стартует, нативный, относительно мало весит, меньше футпринт. но читая текущие недостатки кажется проще взять уж тогда го, чем сношаться с джавой. мб в будущем при адопшене, развитии и полировке AOT решения будет меньше цена использования и ряд ниш в рамках джава-команд это займет. пока выглядит что "экономически оправданная" применимость подхода покрывает весьма узкий спектр кейсов
Воот. Тоже на будущее думали про использование GraalVM. Зависимостей штучки три-четыре. Надемся будет безпроблемная компиляция в native image real-time-intelligence/fbase: Hybrid time-series column storage database engine written in Java (github.com)
Ну если хотите повышенное использование памяти и увеличенное время старта, то upx самое то
Есть какие-то исследования по этому?
сценарий похож на fat jar: необходима предварительная распаковка
Ну вот паковал я gitea для интереса, RSS сразу после старта (это еще не установленная версия)grep gitea | xargs ps -o pid,rss,command -p | awk '{$2=int($2/1024)"M";}{ print;}'806 196M ./gitea-with-upx
835 167M ./gitea-1.18.-rc1-linux-amd64
Время запуска под WSL2
time ./gitea-with-upx --help
real 0m1.998s
user 0m1.992s
sys 0m0.041s
time ./gitea-1.18.-rc1-linux-amd64 --help
real 0m0.074s
user 0m0.060s
sys 0m0.045s
Axiom Runtme Container платный, но сильно меньше (около 50-100 мегабайт), и подходит серьезным энтерпрайзам (сейчас на нем работает весь российский банкинг).
Если честно, вообще упустил момент, когда и как этот Axiom появился. Вроде бы был Беллсофт, который делал понятное: коммитил в OpenJDK, собирал свои JDK и docker-образы, двигал Alpine и проник по умолчанию в билдпаки paketo. Что произошло потом? Это какое-то разделение на с этой/с той стороны? С этой стало "только платно"? Если я по собственной невнимательности упустил какие-то статьи / новости, прошу бросить в меня ссылками :)
Как оно может уже быть во всём российском банкинге, когда банкинг это крайне медленная инерциальная штука? Вот я смотрю на CI раннерах в одном из доступных мне банков, там россыпь образов разного, от maven:3 и openjdk:11, до той же либерики, которую затащил я, но Axiom-а нету. Слишком громогласное заявление, и оттого отталкивающее. Извините :)
Кубернейтис и экономия времени старта. На секундочку - пока твой приклад не начнет отдавать хелсчеки - куб в него не будет роутить трафик. То есть выкатываем новую версию, а она (обоже, если там какой-нибудь томкат) стартует целых 80-90 секунд, и, обоже, эти 90 секунд у нас продолжает работать старая версия. Странная метрик, если честно, время старта приложения, наверно для локальной отладки - ок, но в проде, где у тебя почти всё эвенчуально, странная.
платный, но сильно меньше (около 50-100 мегабайт)
бесплатный образ eclipse-temurin:11.0.17_8-jre-alpine по подсчётам докерхаба 55.76 MB
для мелкостартапа уход с джавы означает страшные потери времени на разработку - с другими технологиями куда больше нужно мучиться в отладке, настройке, поддержке прода, итп.
Пишите на Elixir и не будете мучиться в отладке и настройке, как с Java)
Тут можно почитать как в Spotify задолбались отлаживать JVM и сняли все свои проблемы переходом на Elixir
Двадцать бабушек – уже рубль. Как GraalVM Native Image позволяет экономить джавистам и девопсам деньги на облако