Quarkus java что это

Quarkus — сверхзвуковая субатомная Java. Краткий обзор фреймворка

Введение

Седьмого марта компания RedHat (вскоре — IBM) представила новый фреймворк — Quarkus. По словам разработчиков, этот фреймворк базируется на GraalVM и OpenJDK HotSpot и предназначен для Kubernetes. Стек Quarkus включает в себя: JPA/Hibernate, JAX-RS/RESTEasy, Eclipse Vert.x, Netty, Apache Camel, Kafka, Prometheus и другие.

Цель создания — сделать Java лидирующей платформой для развертывания в Kubernetes и разработки serverless приложений, предоставляя разработчикам унифицированный подход к разработке как в реактивном, так и в императивном стиле.

Если смотреть на эту классификацию фреймворков, то Quarkus где-то между «Aggregators/Code Generators» и «High-level fullstack frameworks». Это уже больше, чем агрегатор, но и до full-stack не дотягивает, т.к. заточен на разработку backend.

Обещана очень высокая скорость запуска приложения и небольшой расход памяти. Вот данные с сайта разработчика:

Время от старта до первого ответа (с):

Потребление памяти (Mb):

Впечатляюще, не так ли?

*Информации об этом стеке технологий я не нашел, можно предположить, что это какой-нибудь Spring Boot с дополнительным обвесом.

Hello World!

Самое простое приложение, написанное на Quarkus, будет выглядеть так:

Это буквально один класс и его достаточно! Можно запустить приложение при помощи Maven в режиме разработки:

Отличие от привычного приложения — нет класса Application! Quarkus поддерживает hot reload, так что можно менять приложение, не перезапуская его, тем самым разработка становится ещё быстрее.

Что дальше? Можно добавить сервис в контроллер при помощи аннотации Inject. Код сервиса:

Заметьте, что в Quarkus используются стандартные аннотации из знакомых фреймворков — CDI и JAX-RS. Ничего нового учить не надо, если вы работали с CDI и JAX-RS до этого, конечно.

Работа с базой данных

Используется Hibernate и стандартные JPA аннотации для сущностей. Как и в случае с REST контроллерами, необходимо написать минимум кода. Достаточно указать зависимости в файле сборки, расставить аннотации @Entity и сконфигурировать datasource в application.properties.

Все. Никаких sessionFactory, persistence.xml и прочих сервисных файлов. Пишем только тот код, который нужен. Однако, при необходимости, можно создать файл persistence.xml и более тонко сконфигурировать ORM слой.

Quarkus поддерживает кэширование сущностей, коллекций для отношений один-ко-многим, а также запросов. На первый взгляд, выглядит здорово, но это локальное кэширование, для одного узла Kubernetes. Т.е. кэши разных узлов не синхронизированы между собой. Я надеюсь, это временно.

Асинхронное выполнение кода

Как было сказано выше, Quarkus поддерживает и реактивный стиль программирования. Код предыдущего приложения можно записать в другом виде.

Асинхронный код также можно перенести в сервис, результат будет таким же.

Тестирование

Тесты для Quarkus-приложений можно писать на JUnit4 или JUnit5. Ниже дан пример теста для endpoint, он написан при помощи RestAssured, но можно использовать и другой фреймворк:

Аннотация @QuarkusTest предписывает запустить приложение перед тем, как запускать тесты. В остальном — знакомый всем разработчикам код.

Платформо-зависимое приложение

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

Что интересно, сгенерированное приложение можно протестировать. И это важно, поскольку исполнение “родного” кода может отличаться от исполнения на JVM. Аннотация @SubstrateTest запускает платформо-зависимый код приложения. Переиспользование существующего кода тестов можно осуществить при помощи наследования, в итоге код для тестирования платформо-зависимого приложения будет выглядеть вот так:

Сгенерированный образ можно запаковать в Docker и запускать в Kubernetes или OpenShift, подробно описано в инструкции.

Инструментарий

Фреймворк Quarkus можно использовать с Maven и Gradle. Maven поддерживается в полной мере, в отличие от Gradle. К сожалению, на текущий момент Gradle не поддерживает генерацию пустого проекта, на сайте есть подробный учебник.

Расширения

Quarkus — расширяемый фреймворк. На текущий момент существует порядка 40 расширейний, которые добавляют различную функциональность — от поддержки Spring DI контейнера и Apache Camel до логгирования и публикации метрик для работающих сервисов. И уже существует расширение для поддержки написания приложений на языке Kotlin, в дополнение к Java.

Заключение

По моему мнению, Quarkus вполне себе в трендах времени. Разработка backend кода становится все проще и проще, и этот фреймворк ещё больше упрощает и ускоряет разработку сервисов, добавляя “родную” поддержку Docker и Kubernetes. Огромный плюс — встроенная поддержка GraalVM и генерации платформо-зависимых образов, что позволяет делать сервисы по-настоящему быстро стартующими и занимающими мало места в памяти. А это очень важно в наше время массового увлечения микросервисами и serverless архитектурой.

Источник

Quarkus: Сверхзвуковая субатомная ветклиника

Это вольный пересказ моего Lightning Talk с конференции Joker 2019. С тех пор вышло несколько новых версий Quarkus, доклад приведен в соответствие с текущим положением вещей.

В рамках разработки нашего фреймворка CUBA Platform, мы уделяем много внимания тому, что происходит в индустрии. Хотя фреймворк CUBA выстроен вокруг Spring, нельзя игнорировать то, что происходит вокруг. И, наверняка, все заметили, что в последнее время очень много шума вокруг cloud-native фреймворков. Два новичка — Micronaut и Quarkus достаточно уверенно начинают вступать на территорию Spring Boot. В один прекрасный день было решено сделать небольшое RnD, по результатам которого я расскажу об опыте работы с фреймворком Quarkus на примере хорошо известного приложения – Petclinic.

Quarkus?

Короткий обзор фреймворка Quarkus был в этой статье. Вкратце: вместо того, чтобы писать свой фреймворк с нуля, разработчики RedHat взяли готовые библиотеки (Hibernate ORM, Eclipse Vert.x, Netty, RESTEasy) и собрали их в единый пакет, а поверх этой сборки сделали совместимый с Java стандартами API. Quarkus соответствует спецификации Eclipse Microprofile 3.2. Кроме того, фреймворк построен так, чтобы минимизировать использование рефлексии при старте приложения, что дает выигрыш по времени старта, использованию памяти и дает возможность использовать AOT компиляцию с GraalVM.
Также в последних версиях Quarkus добавили движок-шаблонизатор для создания UI — Qute. На момент RnD он не был доступен (и, если честно, я плохо понимаю, зачем он нужен), а в нашем проекте использовался React.

Так что там с ветклиникой?

Petclinic – приложение-пример, написанное на Spring Framework. Все началось с версии на Spring, а сейчас ветклинику делают все, кому не лень и в разных вариантах: на классическом Spring, на Spring Boot, пишут код на Kotlin, добавляют GraphQL API, в общем, развлекаются как могут. Ветклиника — это такой полигон, на котором можно обкатывать новые фреймворки. Было решено сделать ветклинику в «классическом» варианте, без использования микросервисов: написать серверную часть с REST API на Quarkus, а клиентскую часть использовать готовую, на ReactJS.

Front-end берем готовый, структуру классов также было решено частично взять из приложения, написанного на чистом Spring. Что ещё нам нужно от фреймворка для создания приложения? Удобный API для написания REST сервисов и работы с БД. Хорошо, если будет dependency injection. В Spring приложениях вы можете использовать весь арсенал библиотек, доступных для JVM. А что с этим у Quarkus?

Здесь есть некоторые тонкости. Quarkus приложения могут работать как «обычные» JVM приложения, в таком случае вы можете использовать практически любые библиотеки, как и в случае использования Spring. Но если вы хотите поддерживать Graal VM Native Image, который работает, исходя из предположения, что программа должна сразу знать о себе все (Closed World Assumption), то список возможных библиотек сильно ограничивается, поскольку многие из них интенсивно используют динамические классы и прочие рефлексивные штуки. И не со всем из этого GraalVM хорошо дружит.

Сделанные специально для Quarkus библиотеки называются расширениями и при сборке приложения они обрабатываются дополнительно для совместимости с AOT. Для этого введена специальная фаза сборки – build augmentation. На текущий момент список расширений для Quarkus довольно обширен, но многим он все ещё может показаться недостаточным. Что хорошо — для разработки Petclinic всё нужное есть: Hibernate, RESTEasy, а также ArC для dependency injection.

Несмотря на то, что в Quarkus есть два вида библиотек, на управление зависимостями это никак не влияет – вы просто прописываете координаты расширения в дескриптор проекта.

Давайте посмотрим на код уже!

Модель данных

Здесь нет никаких новостей, используем Hibernate. Мы взяли готовую структуру классов из проекта petclinic для Spring, там используется Hibernate в качестве ORM. Нелишним будет напомнить, что RedHat является одним из основных спонсоров Hibernate, так что было бы странно не видеть этот ORM в составе Quarkus.

С данными в Quarkus можно работать несколькими способами.

Можно заинжектить EntityManager и использовать его для работы с сущностями:

А можно использовать расширение Panache. Если унаследовать свои сущности от PanacheEntity (мы это сделали для BaseEntity ), то в каждом классе сущности появятся методы для работы с базой данных (find, list, delete, persist и т.д.). Предыдущий код работы с данными, но с использованием Panache:

Кроме того, Panache поддерживает репозитории, можно использовать их, такой подход может быть более привычным.

Я не могу выделить явные преимущества или недостатки того или иного подхода, но лично мне кажется, что работа с Panache чуть проще.

Сервисы

Контроллеры

Для создания REST API контроллеров пришлось немного почитать документацию по JAX-RS, чтобы провести аналогию с классами и аннотациями Spring. Взять готовые Spring контроллеры не получилось, пришлось переписать код на JAX-RS, но, в целом – совсем ничего сложного, если вы умеете делать REST контроллеры.
Получилось как-то так. Код простой и ничего Quarkus-специфичного в нем нет.

А как тестировать код?

Для тестирования используются RESTAssured и JUnit, есть опция тестирования кода, скомпилированного в нативный исполняемый файл. Здесь тоже никаких новостей.

Запускаем!

У нас есть контроллеры, сервисы и сущности – все нужное для запуска приложения. Что характерно – специальный файл-запускатель Aplication.java в Quarkus не нужен, при сборке фреймворк его сам сделает.

При разработке приложение обычно запускается в development mode, когда можно редактировать код и видеть изменения без перезапуска приложения:

Естественно, можно упаковать приложение в Docker контейнер, есть подробная и не очень длинная инструкция, как это делать.

И что там со быстродействием?

Petclinic на Quarkus стартует быстро, примерно в 2 раза быстрее, чем UberJar «эталонного» приложения Petclinic, написанного на Spring Boot. Для тестов использовалась база H2, in-memory. Hibernate не проверял и не обновлял схему БД при старте приложения. Итоги ниже.

Spring Boot Uber Jar:

Двукратное увеличение скорости запуска приложения — это неплохо, но давайте рассмотрим ещё одну вещь: AOT компиляцию при помощи GraalVM Native Image. Это то, что делает Micronaut и то, что сейчас делают в Spring. В Quarkus компиляция в нативный код – это не набор заклинаний, а просто название профиля при запуске в maven.

Нативный код стартует ультрабыстро — это занимает десятые доли секунды!

Расход памяти я мерил в Linux утилитой pmap, методика есть на сайте Quarkus. Обратите внимание на цифру RSS – resident set size, это актуальная цифра расхода памяти.
Spring Boot Uber Jar:

А это – расход памяти, если мы скомпилируем приложение в исполняемый файл при помощи GraalVM. Потребление памяти меньше примерно в 20 раз в сравнении со Spring Boot приложением.

Промежуточные итоги

Стандартная ветклиника получилась без проблем. Писать на Quarkus можно без головной боли, ничего раздражающего для себя я не увидел, обычный фреймворк с приятными плюшками вроде dev mode. Все как-то сразу получилось, даже неинтересно. Никаких плагинов для IDEA ставить не пришлось, тесты запускаются, приложение запускается. Отладка работает через remote port.

Developer Mode – хорошо сделан. Просто запускаете приложение и начинаете править код. Quarkus сам перекомпилирует и перезапустит приложение, если были сделаны изменения. Получается цикл «код — обновление страницы — анализ вывода — код». На больших и сложных приложениях это, очевидно, будет работать медленно, но Quarkus изначально сделан для разработки микросервисов, поэтому разработчики выбрали полный перезапуск приложения вместо перегрузки отдельных классов. Небольшой минус — необходимо переподключаться к debug порту, если приложение стартует заново.

Добавляем безопасности

Делаем строковые константы, чтобы проще рефакторить код.

Добавляем аннотацию к методу, прописываем роли. Собственно, все.

Для React клиента был сделан отдельный API вызов, который проверяет правильность имени и пароля. При ответе ACCEPTED base64 строка аутентификации кэшируется на клиенте в браузере и передается при каждом вызове API.

Тут я нашел свой первый баг в Quarkus. CORS в сочетании с Security давал интересный эффект. Неправильная пара пользователь-пароль отбрасывалась сразу и до CORS фильтра дело не доходило. В результате, нужные заголовки в ответ не добавлялись. А, если нет CORS заголовков, то браузер даже не допускал ответ сервера до React клиента. После долгой переписки баг все-таки исправили и React клиент ожил.

Имитация Spring

Для Quarkus существуют расширения, которые добавляют поддержку Spring аннотаций и некоторых API. В принципе, это логично. Компилятору должно быть все равно, написан ли там Inject или Autowired. С API посложнее, конечно, но, в принципе, тоже реализуемо. Конечно, не все поддерживается, но можно сделать код немного привычнее, если вы переходите на Spring. Вот что получилось.

JPA репозитории ровно такие же, как в Spring.

Пока добавлял репозитории, пришлось временно убрать наследование сущностей, потому что проявился ещё один баг. Но его починили без долгой переписки, как часть большого исправления.

Сервис в Quarkus может быть вообще неотличим от спрингового.

Да и контроллер тоже.

Заметьте, что можно смешивать аннотации Quarkus и Spring. В итоге, все заработало нормально, как и должно было. Разработчики из RedHat делают все, чтобы стать заметным игроком на рынке Java фреймворков.

Заключение

С Quarkus приятно работать, RedHat в него сейчас активно вкладывается, появилось огромное количество материалов и докладов на конференциях. Можно смело начинать эксперименты с фреймворком, стабильные версии уже вышли. Один из последних примеров использования Quarkus на боевом проекте — Lufthansa.

Важное замечание: даже сами разработчики из RedHat не рекомендуют переводить на Quarkus то, что у вас сейчас отлично работает на Spring или другом фреймворке. Начинайте на Quarkus новую разработку, не трогайте существующие сервисы.

Так что, если вы планируете приложение с сервисной архитектурой и вам реально важно быстро поднимать новые экземпляры backend сервисов – потестируйте Quarkus. Он и так быстр, а в сочетании с AOT компиляцией – вообще круто получается.

Ещё, есть смысл рассмотреть Quarkus, если расходы на Spring приложение в облаке становятся ощутимыми из-за потребления памяти (и вы уверены, что это из-за Spring). Тогда, возможно, затраты на переписывание приложения со Spring на Quarkus будут скомпенсированы меньшими расходами на облачную инфраструктуру в дальнейшем.

А вот для внутренних корпоративных приложений, где не всегда важен быстрый старт сервисов, можно обойтись и более традиционными фреймворками типа Spring Boot или CUBA Platform.

Если интересно посмотреть на субатомную ветклинику – она на GitHub. Замечания и дополнения приветствуются.

Источник

Как Quarkus объединяет императивное и реактивное программирование

В этом году мы планируем всерьез развивать темы контейнеров, Cloud-Native Java и Kubernetes. Логичным продолжением этих тем будет рассказ о фреймворке Quarkus, уже рассмотренном на Хабре. Сегодняшняя статья посвящена не столько устройству «субатомной сверхбыстрой Java», сколько тем перспективам, которые Quarkus привносит в Enterprise. (Кстати, смотрите наш вебинар «Это Quarkus – Kubernetes native Java фреймворк». Покажем, как начать «с нуля» или перенести готовые решения)

Java и JVM по-прежнему исключительно популярны, но при работе с бессерверными технологиями и облачно-ориентированными микросервисами Java и другие языки для JVM применяются все реже, так как занимают слишком много места в памяти и слишком медленно загружаются, из-за чего плохо подходят для использования с короткоживущими контейнерами. К счастью, в настоящее время эта ситуация начинает меняться благодаря Quarkus.

Сверхбыстрая субатомная Java вышла на новый уровень!

42 релиза, 8 месяцев работы сообщества и 177 потрясающих разработчиков – итогом всего это стал выпуск в ноябре 2019 года Quarkus 1.0, релиза, который знаменует собой важную веху в развитии проекта и предлагает массу классных функций и возможностей (подробнее о них можно прочитать в анонсе).

Сегодня мы расскажем, как Quarkus объединяет модели императивного и реактивного программирования на базе единого реактивного ядра. Мы начнем с краткого экскурса в историю, а затем детально разберем, в чем заключается дуализм реактивного ядра Quarkus и как Java-разработчики могут воспользоваться этими преимуществами.

Микросервисы, управляемые событиями архитектуры и serverless-функции – все это сегодня, что называется, на подъеме. С недавних пор создание облачно-ориентированных архитектур стало гораздо проще и доступнее, однако проблемы остались – особенно у Java-разработчиков. Например, в случае serverless-функций и микросервисов есть острая необходимость в том, чтобы сократить время запуска, снизить расход памяти и таки сделать их разработку делом более удобным и приятным. Java в последние годы внесла несколько улучшений, вроде доработанного для контейнеров функционала ergonomics и проч. Однако добиться нормальной работы Java в контейнере по-прежнему непросто. Поэтому мы начнем с того, что рассмотрим некоторые из внутренних сложностей Java, которые особенно остро проявляются при разработке контейнерно-ориентированных Java-приложений.

Для начала обратимся к истории.

Потоки и контейнеры

Начиная с версии 8u131, Java стала более-менее поддерживать контейнеры за счет улучшений в функционале ergonomics. В частности, теперь JVM знает, на скольких процессорных ядрах она выполняется, и может соответствующим образом настраивать пулы потоков – как правило, пулы fork/join. Безусловно, это замечательно, но, допустим, у нас есть традиционное веб-приложение, использующее HTTP-сервлеты и запускаемые в Tomcat, Jetty и проч. В результате это приложение выдаст каждому запросу отдельный поток и позволит ему блокировать этот поток при ожидании операций ввода-вывода, например, при обращении к БД, файлам или другим сервисам. То есть, размер такого приложения зависит не от количества доступных ядер, а от количества одновременных запросов. Кроме того, это означает, что квоты или лимиты в Kubernetes по количеству ядер тут не особо помогут, и дело в итоге закончится тротлингом.

Исчерпание памяти

Квоты и лимиты

В Java 11 появилась поддержка CPU-квот (вроде PreferContainerQuotaForCPUCount). Kubernetes тоже предлагает поддержку лимитов и квот. Да, всё это имеет смысл, но, если приложение опять выходит за рамки выделенной квоты, мы снова приходим к тому, что размер – как в случае с традиционными Java-приложениями – определяется по числу ядер и с выделением отдельного потока на каждый запрос, то есть толку от всего этого немного.
Кроме того, если использовать квоты и лимиты или функции горизонтального (scale-out) масштабирования платформы, лежащей в основе Kubernetes, проблема тоже не решается сама собой. Мы просто тратим больше ресурсов на решение исходной проблемы или в итоге приходим к перерасходу ресурсов. А если это высоконагруженная система в публичном общедоступном облаке, мы почти наверняка начинаем использовать больше ресурсов, чем это действительно нужно.

И что со всем этим делать?

Если по-простому, то использовать асинхронных и неблокирующие библиотеки ввода-вывода и фреймворки вроде Netty, Vert.x или Akka. Они гораздо лучше подходят для работы в контейнерах из-за своей реактивной природы. Благодаря неблокирующему вводу-выводу, один и тот же поток может обрабатывать сразу несколько одновременных запросов. Пока один запрос ждет результатов ввода-вывода, обрабатывающий его поток высвобождается и берется за другой запрос. А когда результаты ввода-вывода наконец-то поступают, обработка первого запроса продолжается. Чередуя обработку запросов в рамках одного и того же потока, можно сократить общее число потоков и снизить расход ресурсов на обработку запросов.

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

Как, и это всё?

Нет, есть еще кое-что. Реактивное программирование помогает лучше использовать ресурсы, но тоже имеет свою цену. В частности, код придется переписывать согласно принципам неблокируемости и избегать блокировки потоков ввода-вывода. А это совсем другая модель разработки и выполнения. И хотя здесь есть масса полезных библиотек, это все равно кардинальная смена привычного способа мышления.

Во-первых, вам надо научиться писать код, который выполняется асинхронно. Как только вы начинаете использовать неблокирующий ввод-вывод, вам требуется явно прописывать, что должно произойти при получении ответа на запрос. Просто блокировать и ждать больше не получится. Взамен вы можете передавать обратные вызовы, использовать реактивное программирование или continuation. Но и это еще не все: чтобы использовать неблокирующий ввод-вывод, вам нужны и неблокирующие сервера и клиенты, и желательно везде. В случае с HTTP всё просто, но есть еще и БД, и файловые системы, и многое другое.

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

Представляем Quarkus

Собственно, в этом и есть суть Quarkus – объединить реактивную и императивную модели в рамках одной среды выполнения.

В основе Quarkus лежат Vert.x и Netty, поверх которых используется целый ряд реактивных фреймворков и расширений, призванных помочь разработчику. Quarkus предназначен для построения не только HTTP-микросервисов, но и управляемых событиями архитектур. Благодаря своей реактивной природе, он очень эффективно работает с системами обмена сообщениями (Apache Kafka, AMQP и т.д).

Вся хитрость в том, как использовать один и тот же реактивный движок как для императивного, так и для реактивного кода.

Quarkus с этим блестяще справляется. Выбор между императивным и реактивным очевиден – использовать и для того, и для другого реактивное ядро. И с чем оно очень помогает, так это с быстрым неблокирующим кодом, который обрабатывает почти все, что проходит через поток цикла событий (event-loop thread, он же – IO thread). Но если у вас есть классические приложения REST или приложения на стороне клиента, у Quarkus наготове императивная модель программирования. Например, поддержка HTTP в Quarkus строится на использовании неблокирующего и реактивного движка (Eclipse Vert.x и Netty). Все HTTP-запросы, получаемые вашим приложением, вначале проходят через цикл событий (IO Thread), а затем отправляются той части кода, которая управляет запросами. В зависимости от точки назначения код управления запросами может вызываться в рамках отдельного потока (так называемый worker thread, применяется в случае сервлетов и Jax-RS) или же использовать исходный поток ввода-вывода (реактивный маршрут reactive route).

Для коннекторов систем передачи сообщений используются неблокирующие клиенты, работающие поверх движка Vert.x. Поэтому вы можете эффективно отправлять, получать и обрабатывать сообщения от систем класса messaging middleware.

На сайте Quarkus.io собрано несколько хороших руководств, которые помогут начать работу с Quarkus:

Полезные ресурсы

10 видеоуроков по Quarkus, чтобы освоиться в теме

Как пишут на сайте Quarkus.io, Quarkus – это Kubernetes-ориентированный Java-стек, заточенный под GraalVM и OpenJDK HotSpot и собранный из лучших Java-библиотек и стандартов.

Чтобы помочь вам разобраться в теме, мы отобрали 10 видеоуроков, где освещаются различные аспекты Quarkus и примеры его использования:

1. Представляем Quarkus: Java-фреймворк нового поколения для Kubernetes

Авторы: Томас Кворнстром (Thomas Qvarnstrom) и Джейсон Грин (Jason Greene)
Цель проекта Quarkus заключается в том, чтобы создать Java-платформу для Kubernetes и serverless-сред, а также объединить реактивную и императивную модели программирования в рамках единой среды выполнения, чтобы разработчики могли гибко варьировать подход при работе с широким спектром распределенных архитектур приложений. Узнайте больше из вводной лекции ниже.

2. Quarkus: сверхбыстрая субатомная Java

Автор: Блюр Саттер (Burr Sutter)
Видеоурок из интернет-лектория DevNation Live демонстрирует, как использовать Quarkus для оптимизации корпоративных Java-приложений, API, микросервисов и serverless-функций в среде Kubernetes/OpenShift, сделав их гораздо меньше, быстрее и масштабируемее.

3. Quarkus и GraalVM: разгоняем Hibernate до сверхскоростей и ужимаем до субатомных размеров

Автор: Сейн Гриноверо (Sanne Grinovero)
Из презентации вы узнаете, как появился Quarkus, как он работает и как позволяет сделать комплексные библиотеки, вроде Hibernate ORM, совместимыми с native-образами GraalVM.

4. Учимся разрабатывать serverless-приложения

Автор: Мартин Лютер (Marthen Luther)
В видео ниже показано, как создать простое Java-приложение с помощью Quarkus и развернуть его в качестве serverless-приложения на Knative.

5. Quarkus: кодируйте с удовольствием

Автор: Эдсон Янага (Edson Yanaga)
Видегайд по созданию вашего первого проекта Quarkus, позволяющий понять почему Quarkus завоевывает сердца разработчиков.

6. Java и контейнеры – каким будет их совместное будущее

Автор: Марк Литтл (Mark Little)
Эта презентация знакомит с историей Java и объясняет, почему Quarkus – это будущее Java.

7. Quarkus: сверхбыстрая субатомная Java

Автор: Дмитрис Адреандис (Dimitris Andreadis)
Обзор преимуществ Quarkus, получивших признание разработчиков: простота, сверхвысокие скорости, лучшие библиотеки и стандарты.

8. Quarkus и субатомные реактивные системы

Автор: Клемент Эскофьер (Clement Escoffier)
Благодаря интеграции с GraalVM Quarkus обеспечивает сверхбыстрый опыт разработки и субатомную среду исполнения. Автор говорит о реактивной стороне Quarkus и о том, как ей пользоваться при создании реактивных приложений и приложений с потоковой передачей данных.

9. Quarkus и быстрая разработка приложений в Eclipse MicroProfile

Автор: Джон Клинган (John Clingan)
Сочетая Eclipse MicroProfile и Quarkus, разработчики могут создавать полнофункциональные контейнерные приложения MicroProfile, которые запускаются за какие-то десятки миллисекунд. В видео подробно разбирается, как кодировать контейнерное приложение MicroProfile для развертывания на платформе Kubernetes.

10. Java, версия «Турбо»

Автор: Маркус Биль (Marcus Biel)
Автор показывает, как использовать Quarkus для создания супермаленьких и супербыстрых Java-контейнеров, позволяющих совершить настоящий прорыв, особенно в serverless-средах.

Источник