×Закрыть

Serverless, Micronaut Framework та розподілені системи: тренди у Java, на які варто звернути увагу

У цій статті я хочу поділитися своїми думками щодо Java-трендів, які обов’язково будуть обговорювати на найближчих конференціях у доповідях, які я особисто піду слухати.

Декілька років тому на одній з українських конференцій я вперше почув про Atomix. Я дізнався, що з його допомогою можна легко і швидко побудувати стійку та гнучку розподілену систему. У вільний від роботи час я додатково вивчав усі кроки побудови таких систем та готувався використати Atomix при першій же можливості. Що згодом і зробив.

Мабуть, якщо б я не потрапив на цю конференцію, я б не дізнався про Atomix і не досягнув би успіху у вирішенні розподілених задач. Тепер я не лише маю досвід у його комерційному застосуванні, а й залюбки ділюся ним з колегами під час особистої комунікації й на публічних заходах. Зараз готую про це доповідь на Devoxx Ukraine, з прикладами та цікавим демо. Звісно, на таких заходах не вчать користуватися технологією, проте почути щось нове та цікаве можна. Так і в цій статті без детальних інструкцій ознайомимося з перевагами і недоліками нових технологій у Java.

Micronaut Framework

Micronaut — це фреймворк для побудови мікросервісних рішень, покликаний стати поруч або й замінити усім відомий Spring Boot. Останній давно освоївся на цьому ринку і вважається, по суті, стандартним підходом. На моєму досвіді це, здається, перший раз, коли зі Spring Boot щось починає конкурувати. І це незважаючи на те, що Micronaut вийде в реліз тільки 23 жовтня. Наскільки цей фреймворк стабільний, скоріш за все, стане зрозуміло, коли його почнуть використовувати в продакшені або ж коли можна буде послухати доповіді від людей, що працювали зі Snapshot-версіями в експериментаційних цілях.

Серед очевидних переваг Micronaut Framework перед Spring Boot — швидкість його старту. Це принципово важливо для тих, чия мета — динамічно збільшувати або зменшувати кількість сервісів, тим самим регулюючи швидкодію системи в цілому.

Також Micronaut відрізняється тим, що у ньому застосований зовсім інший підхід до менеджменту класів. Spring це робить під час старту програми — створює так звані «біни», огортаючи їх додатковою логікою за рахунок проксювання, — та вирішує залежності між класами. Це уповільнює процес та вносить певні ризики. Micronaut усе робить на етапі компіляції: огортає, вирішує залежності, і як результат — породжує більшу кількість класів після компіляції. Таким чином, старт аплікації стає в рази швидшим і більш передбачуваним.

Наразі це два серйозні аргументи проти мейнстрімної технології. Тим не менш, Spring має дуже велику екосистему, що зростала роками, тому категорично стверджувати, що Micronaut здатен витіснити Spring не можна. Завдяки Spring Framework та іншим продуктам компанії Pivotal ми маємо величезний набір інструментів: Spring Data, Cloud, Web Services, State Machine і т. д. Завдяки їм можемо легко вирішувати загальні проблеми з мінімальним втручанням у логіку. З іншого боку, в обличчі Micronaut отримуємо новий, сучасний інструмент, що ціленаправлено створений і спроектований для того, аби будувати мікросервісні рішення. Це робить його цікавим, корисним і обов’язковим кандидатом для розгляду на роль основної технології в розробці мікросервісних рішень.

Vert.x

Наступний тренд — це саме підхід до архітектури додатків.

Vert.x покликаний стати новим кроком у розвитку архітектури багатокомпонентних систем після мікросервісів. Цікаво, що Vert.x базується на реалізації сучасних підходів до побудови розподілених та реактивних систем. Це автоматично робить його швидким, стабільним та трендовим. Проте наразі важко сказати, чи стане Vert.x одним зі стандартних підходів до реалізації архітектурних рішень як наступник мікросервісів. Перед тим, як зав’язувати рішення на його екосистемі, необхідно об’єктивно оцінити ситуацію, спробувати його на pet-проекті і прислуховуватись до тих, хто має з ним справу на комерційних проектах. Тоді зважити всі «за» та «проти» і приймати рішення залежно від конкретної бізнес-задачі.

GraalVM

GraalVM — цікава реалізація віртуальної машини, написана на Java. Одна з її крутих особливостей — це можливість виконувати код, написаний на різних мовах програмування, в одному і тому ж середовищі. Проте з цим треба бути обережним. Необдумані рішення можуть призвести до «солянки» на проекті. І в такому разі користі від цього гнучкого підходу буде мало. Тому всім, кому цікава Graal VM або хто бачить практичне застосування кількох мов програмування в одному і тому ж функціоналі, необхідно виробити чіткі підходи та вимоги до використання Graal VM і контролювати хід їх виконання. Також не зайвим буде порадитися з людьми, які мають безпосередній досвід роботи з GraalVM і наслідувати тільки найкращі практики.

На мою думку, завдяки GraalVM можна багато чого спростити та отримати кращу швидкодію завдяки потужному механізму реорганізації інструкцій під час компіляції. Особливо, якщо в команді не всі люди — джавісти. Або ж коли є специфічна задача, яку значно легше виконати, якщо залучити спеціалістів і технології не з Java-стеку.

Serverless архітектура

Технологія Serverless — це можливість виконувати логіку (код) без прив’язки до конкретного середовища (сервера чи операційної системи). Розробнику не потрібно думати про те, як і де його код буде запущено. Достатньо просто відправити його у «хмару» і відслідковувати результати виконання. Звісно, це багато чого спрощує, адже можна економити на інфраструктурі, віддавши все у «хмару».

Мені важко судити про перспективність цього напрямку і готовність ринку до нього. Думаю, про це рано говорити. Не всім підходить варіант віддати свою логіку та дані у хмару. Так неможливо контролювати, на яких машинах вони обробляються, куди врешті-решт потрапляють та де компілюються. Існує безліч великих компаній, які не готові навіть розгортати свої рішення у «хмарах», використовувати їхні сервіси та віртуальні машини. Багато країн взагалі не дозволяють відправляти свої дані за межі своєї території. Проте це вирішується розширенням «хмарних» локацій у нових країнах.

Я вже згадував, що serverless, по своїй суті, говорить нам: «Віддайте нам свої дані та логіку». Проте це ще й означає суттєву зав’язку на конкретних «хмарних» технологіях та сервісах.

Особисто я б рекомендував використовувати serverless технології тоді, коли ви вже і так зав’язані на ті чи ніші «хмарні» рішення. І лише тоді, коли логіка, надіслана на виконання в «хмару», не є бізнес-процесом, що вимагає паралельного виконання або обробки даних. Адже тестувати таке рішення та збирати з нього статистику — непроста задача.

У будь-якому випадку, цей тренд вартий уваги. Ним бажано володіти, адже є і такі клієнти, що готові економити на інфраструктурі і будувати своє рішення на «хмарних» технологіях.

Розподілені системи

Розподілені системи не є чимось новим. Проте й досі буває, що технологію для рішення конкретної бізнес-задачі обирають неправильно. Зазвичай, звертають увагу на популярні та розкрученні технології, або щось, з чим уже працювали. Проте вибір повинен базуватися на аналізі рішень, які імплементовані в тій чи іншій технології. При тому, що він не завжди на всі 100% покриває поставлені вимоги. У такому випадку можна спробувати імплементувати свою систему, використовуючи наявні рішення та протоколи.

Готових рішень на ринку багато, тому відразу починати писати свій «велосипед» не потрібно. Проте неправильний вибір технології може спричинити серйозні проблеми в майбутньому. Це трапляється, коли той чи інший підхід стає проблемою, а не рішенням у певних випадках. Щоб уникнути таких ситуацій, потрібно розуміти, як розподілені системи побудовані, як вони працюють і що гарантують. Більшість уже чули про САР теорему, знають і розуміють, що вона гарантує, що ні та які типи розподілених систем породжує. Проте це не єдина річ, яка має впливати на вибір. Знання про алгоритми консенсусу, протоколи комунікації, засоби збереження та передачі даних — усе це та інше значно зменшує ризик вибору неправильної технології. Звісно, у будь-якому випадку головним критерієм завжди є бізнес. Тільки після того, як зрозумієш конкретну бізнес-задачу, реально обрати відповідну технологію.

Висновки

Java-світ є технологічним та різноманітним, та попри все це продовжує стрімко розвиватися. Немає гарантій, що усі згадані вище тренди стануть мейнстрімом через певний час. Однак слідкувати за новинками, цікавитися, тестувати й ділитися досвідом мають усі. Таким чином, наша спільнота буде достатньо міцною й готовою до будь-яких змін, як в екосистемі Java, так і сфері ІТ в цілому.

Діліться у коментарях своїм аналізом і думками про те, що чекає Java в найближчому майбутньому. Буде приємно подискутувати.

LinkedIn

40 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Micronaut Framework стане далеко не першим конкурентом спрінг бута. Цю роль вже досить давно і успішно виконує Dropwizard.

Dropwizard — солянка з бібліотек. І не сказав би що він щось робить успішно =) проте, це моя думка.

Так, дійсно, це солянка, точно така сама як і Spring Boot. Стосовно успіштості: маєте якісь конкретні приклади недоліків Dropwizard?

Spring Boot не солянка =) Він взагалі був розроблений для швидкого старту розробки аплікацій на основі Spring Framework еко-системи. При розробці на Spring Boot ви використовуєте розробки або адаптації (як наприкад Cloud Stack від netflix) і суть тільки у тому щоб все взлетіло без ніякого (або з мінімальним) втручанням. От і вся роль Spring Boot.

Він взагалі був розроблений для швидкого старту розробки аплікацій на основі Spring Framework еко-системи.

Ок, якщо перефразувати, то вийде «розроблений для швидкого приготування солянки зі спрінгових фреймворків».
Все що ви сказали в даному повідомлені про Spring Boot є вірним і для Dropwizard.

Ні, не теж саме, Pivotal давно задав стандарт і всі свої продукти пилить під нього. Щоб Ви не взяли — все інтегрується, конфігурується і тд по загальних підходах. Проте, я працював з Dropwizard давненько, тому якщо вони в останніх релізах таки підвели все під спільний знаменник — тоді супер, і тоді так, вони теж саме але в «профіль»

Щодо Dropwizard і його успішності — треба судити трендами, а не моїм чи вашим переконанням. Для цього терба просто глянути на тенденцію використання тої чи іншої технлогії. І якщо так зробити то доля Dropwizard нещадно мала, в порівнянні з Spring еко-сиистемою.

Ви зараз переводите тему. Спершу ви пишете

І не сказав би що він щось робить успішно

а потім говорите про тренди. Я тому і питаю: чи знаєте ви щось про Dropwizard таке, що робить його не успішним у вирішенні тієї чи іншої проблеми?

Якраз тему я не переводжу, а продовжую свої слова :
"

проте, це моя думка

"

І в продовдення скажу, що з Dropwizard працював на кількох проектах в минулому, і бажання з ним працювати надалі — нема. І це знову моя особиста думка. А причини — та хоча б те, що він не адаптує рішення до загального підходу, не будує спільний інтерфейс чи тощо, а просто збирає їх докупи, з таким підзодом нічого не заваджає взяти Jersey, Guava додати до того Google Guice і ще що вам там завгодно — для чого тоді взагалі Dropwizard? Тільки для, свого роду, полегшення менеджменту усіх цих компонент.

Цю роль вже досить давно і успішно виконує Dropwizard.

лол просто лол. К сожалению, дропвизард мертв, по факту. Дропвизард, ВайлдфлайСварм, Нинздя, Плей (кстати) — это про построение алл-ин-ван фремворков, а не про вреймворки для микросревисов.

Micronaut Framework стане далеко не першим конкурентом спрінг бута.

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

К сожалению, дропвизард мертв

Це в чому заключається? Продукт активно доповнюється і релізиться github.com/...​izard/dropwizard/releases Хто його похоронив?

это про построение алл-ин-ван фремворков

Що мається на увазі під олл-ін-ван фреймворками? Дропвізард взагалі не є інструментом для написання фреймворків (як, власне, і спрінг бут), це інструмент для написання аплікух для рестових сервісів.

Це в чому заключається? Продукт активно доповнюється і релізиться github.com/...​izard/dropwizard/releases Хто його похоронив?

Та хоть так stackshare.io/...​pwizard-vs-play-vs-spring
Или поищите другое сравнение __использования__ фреймворков.

Що мається на увазі під олл-ін-ван фреймворками? Дропвізард взагалі не є інструментом для написання фреймворків (як, власне, і спрінг бут), це інструмент для написання аплікух для рестових сервісів.

алл-ин-ван фремворки — это фремворки позовляющие реализовать все уровни вашего приложения без установки дополнительных фремворков. В самом простом случае — презентейшн/Рест АПИ + депенденси инжекшн + ДАО + рест клиент для других сервисов + возможность конфигурации.

Дякую за пояснення. Стосовно приведеної статистики, то це статистика усіх спрінгових фреймворків з усіма дропвізардними фреймворками. Особисто я, з розробки дропвізарда, окрім, звісно, самого дропвізарда (як рішення для побудови рестових веб сервісів), знаю лише Dropwizard metrics (і ті, очевидно, перейшли їм колись від codahale). Spring Frameworks же собою являє величезну охапку рішень (як автор сказав екосистему). Вцілому, використання Dropwizard не забороняє використання будь-якиї спрінгових фреймворків.

Я б ще додав новий HTTP Client який йде з коробки в нових джава версіях. Майже всі проекти юзають шттп клієнти. Тому можна вже зараз сказати — прощавай Apache Http Client, Async Http Client і інші.

Тому можна вже зараз сказати — прощавай Apache Http Client, Async Http Client і інші.

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

Ну ясно, що це не станеться за 1 день. Але думаю напротязі року клієнт обросте фічами, які потрібні 90% юзерів і тоді юзати апч протсо не буде сенсу.

Але думаю напротязі року клієнт обросте фічами, які потрібні 90% юзерів і тоді юзати апч протсо не буде сенсу.

А теперь давайте поговорим про адопшн джава 11 :)

Але думаю напротязі року клієнт обросте фічами

Обрастёт? Это как? будут выкатываться 11.1, 11.2, 11.3 c дополненным API?

Пам’ятаю ваша компанія була однією з піонерів в використанні 9 версії, плануєте так само зробити з 11 чи може вже? :)

Так. Так як в нас близько 40 серверів чекаю поки з’явиться інсталер one-liner — stackoverflow.com/...​stall-jdk-11-under-ubuntu

Круто, тримайте в курсі! Було б гарно почути що міграція на 11 не вимагала ніяких додаткових зусиль :D
А ви чекаєте збірку від оракла, на openjdk зразу не переходите?

Було б гарно почути що міграція на 11 не вимагала ніяких додаткових зусиль :D

Вже перевіряв, компілюється без проблем і тести проходять. Так що, думаю, тим хто на 10-ці (як ми) цей перехід буде самий легкий з усіх.

А ви чекаєте збірку від оракла, на openjdk зразу не переходите?

Ми чикаєм OpenJdk від оракла, не HotSpot.

Ми чикаєм OpenJdk від оракла, не HotSpot.

Вот здесь не понял вас.
Oracle JDK и OracleOpenJDK JDK 11 builds сами по себе билды OpenJDK c виртуальной машиной под названием HotSpot. Внутренности практично идентичны для версий 9 и выше. До этого все таки было много отличий: -XX:+UnlockCommercialFeatures, диагностические тулзы (Java Flight Recorder), но внутри все равно HotSpot

Oracle JDK и OracleOpenJDK JDK 11 builds сами по себе билды OpenJDK c виртуальной машиной под названием HotSpot.

Ну тут я не дуже впевнений. Як тоді відрізнити Oracle JDK від OracleOpenJDK?
Зараз, до речі, sudo apt install openjdk-11-jdk інсталює HotSpot.

«Я не настоящий сварщик», но читал, что вывод команды java —version будет разный в случае Oracle JDK и OpenJDK

HotSpot будет и там, и там, так как оба билда собираются по сути из одних и тех же исходников, разница только в брендировании и лицензировании

Упс. Запустив один сервер — відвалився log4j2 :). Прийдеться почекати від них фіксу.

Також Micronaut відрізняється тим, що у ньому застосований зовсім інший підхід до менеджменту класів. Spring це робить під час старту програми — створює так звані «біни», огортаючи їх додатковою логікою за рахунок проксювання, — та вирішує залежності між класами. Це уповільнює процес та вносить певні ризики. Micronaut усе робить на етапі компіляції: огортає, вирішує залежності, і як результат — породжує більшу кількість класів після компіляції. Таким чином, старт аплікації стає в рази швидшим і більш передбачуваним.

Ого, нічого собі, пацани придумали PHP-FPM!

Думаю, що не суть в тому що придумали, а в тому, що реалізували принципіально інши підхід від тог, що використовує Spring. Але чи буде він кращим — з часом глянемо ;)

serverless і не треба думати це гучно сказано, а фо факту треба буде враховувати архітектуру клауда і що він може надавати і що ні.

GraalVM

Все таки нужно понимать что GraalVM объединяет под единым названием:
1. Graal (JIT компилятор для JVM). Можно использовать с JDK 9 и выше, благодаря JEP 317
2. Truffle (в грубой форме — фрейморк для построение AST)
3. SubstrateVM ( Ahead-of-time Compilation и запуск как единного бинарника/native image)
4. и т.д. Полный список github.com/oracle/graal
Если 2 пункт является довольно узкоспециализированным, то остальные 1 и 3 очень даже применимы для рядового разработчика или обычных программ.
Особенно 1, Twitter получил хороший буст при замены C2 на Graal:

В продакшне мы экономим 8% утилизации CPU просто с помощью замены C2 на Graal. А в масштабах Twitter это много денег.
https://habr.com/company/jugru/blog/349638/
Serverless архітектура

Вот здесь как раз и приходит на помощь связка Graal + SubstrateVM:
1. Быстрый старт приложение
2. Единый бинарник/native image, что ведет за собой удобный деплой.
3. AOT компиляция

Micronaut Framework

И вот здесь стоит вспомнить что не все так сладко в связке Graal + SubstrateVM и есть разные ограничения и одно из них это dynamic class loading, что вызывает проблемы для «стандартного» приложение/стека (Spring/Hibernate). И вот здесь появляется Micronaut с его EFFICIENT COMPILE-TIME DEPENDENCY INJECTION AND AOP. Ждем ответа от Pivotal в виде Spring Fu

Vert.x

Я бы еще добавил сюда рост популярности к асинхронным и не блокирующим вычислениям:
1. Reactive Relational Database Connectivity https://github.com/r2dbc
2. Project Loom: lightweight threads/coroutines/continuations и т.д. Нативная поддержка в самой JVM
3. Kotlin Coroutines https://github.com/Kotlin/kotlin-coroutines/tree/master/examples

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

Але Мікронавт розроблявся спеціально для написання мікросервісів, що не скажеш про Бут. Хоча буде видно, чи приживеться тежнологія.

Java-трендів, які обов’язково будуть обговорювати на найближчих конференціях у доповідях

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

Micronaut Framework

Штука интересная, но как вы сказали ему прийдется противопоставлять себя уже полностью готовой зрелой инфраструктуре в виде сприг(бута).

Vert.x

Уже не новое, хайп был лет 5 назад. Не выстрелил потому что, снова же, не было инфраструктуры которая была у спринга и джаваЕЕ.

GraalVM

Очнеь интересная штука, от только у прикладных программистов для нее очень мало применений.

Serverless архітектура
Розробнику не потрібно думати про те, як і де його код буде запущено.

Ровно до того момента как прийдет менеджер и спросит «А почему мы платим Амазону 100500 денег?» :)
Тема интересная, но пока не очень для джавы. Джава хороша для постороение комплексных систем. Для простых скриптов поверх сервисов клауд-провайдера, которые выступают в таких системах в роли «серверов», вполне достаточно языокв попроще (например Го, прэвэд Валялькину)

Розподілені системи

Лет 20 как трэнд. От только на практике далеко не всем оно надо, а тем кому надо часто хватает простых архитектурных решений (вроде поставили балансер и за ним 100500 копий одного и того же)

Погоджуюсь, проте розподілені системи хоч і не нове слово проте за останній час розвивається стрімко. Адже, ресурси зараз не ті що 20 років назад і системи теж ;)

Хотелось большего... или это просто мои неоправданные ожидания от названия топика.

или это просто мои неоправданные ожидания от названия топика

А чего вы ожидали? (Не исключено что я буду делать что-то похожее на эту статью в конце года)

Більше буде на Девоксі, рекомендую сходити, особливо на доповідь по Micronaut.

Ещё одна реклама девокса...)

Скоріше рекомендація доповіді про Micronaut від Андрія Петрика, яку я вже чув і вона реально варта уваги.

Подписаться на комментарии