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 в найближчому майбутньому. Буде приємно подискутувати.
