Ударим Java EE автопробегом по бездорожью и разгильдяйству! Интервью с Себастианом Дашнером, коммитером Jakarta EE

Сегодня в нашей виртуальной студии Себастиан Дашнер. Вкратце, кто это такой:

• Lead Java Developer Advocate в IBM;
• Множество интересных докладов и своих видео на YouTube;
• Автор книги «Architecting Modern Java EE Applications»,
• Участник Java Community Process: экспертные группы JAX-RS, JSON-P, Config;
• Коммитер в кучу опенсорсных проектов, включая всё, связанное с Java EE/ Jakarta EE/MicroProfile.

В этом интервью мы поговорим на следующие темы:

Ведут интервью, как всегда, Евгений Трифонов (phillennium ), и Олег Чирухин (olegchir) из JUG.ru Group.

Евгений: Начнём с нетехнического вопроса. В вашем Твиттере я видел фотографию вас в Новосибирске в толстовке «ДЖАВА». Какое у вас осталось впечатление от этой поездки?

Себастиан: Рад, что вы узнали фотографию, эта толстовка у меня с Joker 2017. Конференция JBreak мне определённо запомнилась. Я никогда бы не предположил, что отправлюсь в такой далёкий уголок Сибири — думаю, из моего круга общения я один из немногих, кто там побывал. Кроме того, за день до конференции я отмечал свой день рождения, и мы отправились кататься на снегоходах, после чего посидели в бане и поели шашлыки. В общем, осталось много приятных воспоминаний. Природа вокруг Новосибирска очень красивая. И производит большое впечатление тот факт, что, если посчитать ещё и Красноярск с Томском, на тысячу километров вокруг тебя нет других крупных городов.

Евгений: Вы — Java Developer Advocate в IBM. Это не совсем обычная позиция — другие знакомые мне Developer Advocates, как правило, занимаются продвижением продуктов своей компании. Какие именно у вас обязанности в IBM? Вы добиваетесь всеми возможными способами максимального распространения и эффективного использования Java?

Себастиан: Да, это довольно точное описание того, чем я занимаюсь. Надо добавить, что я в первую очередь выступаю в интересах не столько компании или продукта, сколько разработчиков. Стремлюсь облегчить их работу и учу вещам, так или иначе связанным с Java Enterprise. Делюсь своими знаниями в блогах, подкастах, на семинарах и конференциях. Я не продаю какие-то отдельные продукты, скорее я продаю технологию в целом.

Евгений: Вы — большой сторонник опенсорса, но работаете в IBM, который у большинства людей с опенсорсом не ассоциируется. При этом мне известно, что IBM иногда принимает довольно активное участие во многих опенсорсных проектах, например, в OpenJ9. Как IBM относится к опенсорсу?

Себастиан: Вы правильно заметили, что многие часто недооценивают участие IBM в опенсорсных проектах — я сам не имел об этом представления, пока не начал работать в этой компании. Например, IBM ведёт много работы в Cloud Native и в Java и является одним из главных участников в Kubernetes и Istio. Доступ к исходникам OpenJ9 был открыт Eclipse Foundation, которая, в свою очередь, была создана IBM. Эта компания также содействовала развитию serverless-технологий, например, Apache OpenWhisk. В целом, программисты в IBM очень дружелюбно настроены к опенсорсу — практически всё, что сейчас делается в этой компании, имеет опенсорсный аспект или открытую версию. Пока что люди действительно недостаточно знакомы с усилиями IBM в этом направлении, и моя работа как Developer Advocate заключается, помимо прочего, в том, чтобы информировать об этом сообщество.

Олег: Недавно прочитал в твиттере, что вы отправились в особое JUG-путешествие на мотоциклах по Японии вместе со Стивом Чином (Steve Chin). JUG на мотоциклах, whaaaat? Можно подробней об этом?

Себастиан: Это была отличная поездка. Мы со Стивом Чином уже несколько раз путешествовали на мотоциклах, и каждый раз мы стараемся совместить это с выступлениями на конференциях и в юзер-группах. Несколько таких путешествий было в Германии, и три — в Японии. На первый взгляд может показаться, что мы это делаем только для развлечения — и, конечно, нельзя отрицать, что мы отлично проводим время в этих поездках. Но и с чисто практической точки зрения мотоцикл — очень удобный вид транспорта для Японии или Центральной Европы, потому что там города с юзер-группами и айтишным сообществом находятся всего в сотне-другой километров друг от друга, и на мотоцикле можно избежать пробок. В каждой из этих поездок мы старались встретиться с максимальным количеством людей и поделиться с ними своими знаниями.

Олег: Вы много путешествуете и даже ездили в Россию, хоть нашу визу получить не так-то просто. Существует мнение, что Developer Advocate — несерьёзное занятие. Будто бы вы разъезжаете по всему свету, развлекаетесь на конференциях — что угодно, лишь бы не писать код. Считаете ли вы, что у вас настоящая тяжелая работа? Кажется, каждый день летать на самолёте должно быть изнурительно.

Себастиан: Думаю, тут обе точки зрения немного правы. Мне нравится моя работа, но при этом она далеко не всегда простая. Одно никак не мешает другому. Действительно, поездки могут выматывать, в особенности если непосредственно после переезда вы не отдыхаете, а выступаете на конференции или организуете семинар. А сразу после конференции нужно снова садиться в самолёт, так что день оказывается занят целиком. С другой стороны, если бы эта деятельность не увлекала, то от такого ритма очень быстро поехала бы крыша, и человек бы просто выгорел. В общем, если мне за день удаётся научить людей чему-то и провести удачный семинар, то даже усталость становится приятной.

Евгений: Насколько мне известно, эта работа требует большого количества усилий для того, чтобы оставаться в курсе новейших технологий в области. Из-за дополнительных нагрузок для Developer Advocates это тяжелее, чем для тех, кто постоянно программирует. Я знаю, что вы регулярно пишете код для Jakarta EE, так что вы, очевидно, не оторвались от технологии. Трудно ли одновременно быть Developer Advocate и разработчиком?

Себастиан: Да, безусловно, для моей работы очень важно оставаться программистом, иначе потеряешь связь с реальностью. Чтобы говорить о технологии со знанием дела, нужен постоянный опыт работы с ней. И времени на программирование действительно остаётся значительно меньше из-за конференций. Кроме того, нужно, чтобы вас по-настоящему увлекала техническая сторона дела и вы готовы были бы тратить на неё вечера и выходные. В общем, нужен определённый баланс между обеими сторонами деятельности.

Олег: Давайте перейдём к техническим вопросам. На первой странице вашего блога есть эпиграф:

IT should be simple and productive.
IT should solve problems, not create ones.
I believe that IT is a chance, not a cost factor.

Какие, на ваш взгляд, самые важные факторы, определяющие продуктивность Java-разработчика? Есть ли какие-нибудь советы относительно того, как быть более продуктивным, лайфхаки, конкретные технически ништяки и утилиты вроде jcmd или sdkman, что угодно?

Себастиан: Да, таких программ много. Что касается простоты, то речь идёт о том, что нужно стремиться избавляться от излишней сложности как в инструментах, которые мы разрабатываем, так и в реализациях, где мы эти инструменты используем. Зачастую разработчиков привлекает сложность сама по себе, в продукт добавляются всё новые фичи исключительно из спортивного интереса. Всегда нужно спрашивать себя: станет ли мир лучше от этой фичи? Поможет ли она решить какую-либо проблему? Приблизит ли она нас к завершению работы над продуктом?

Если говорить о продуктивности самого разработчика, я действительно могу порекомендовать ресурсы для этого. Загуглите моё имя и фразу «developer productivity». Я записал видеокурс, который выложен на Youtube, и там я даю советы как раз по этой теме. Там рассказывается про использование командной строки, горячих клавиш, про то, как пользоваться клавиатурой. Общий смысл — как сделать больше работы в меньший промежуток времени. И если вы станете вникать в эту тему, то сам процесс автоматизации и оптимизации работы станет затягивать. Вы станете больше времени продумывать решение проблемы и меньше — тупо стучать по клавишам. В общем, производительность программирования — очень близкая мне тема.

Олег: Насколько понимаю, вы коммитер в MicroProfile, и поэтому можете знать всё, связанное с ним. Расскажите, пожалуйста, что сейчас происходит вокруг Java EE и Jakarta? Я немного читал об этом, но для меня, как человека из мира Spring, всё это слишком запутанно.

Себастиан: Как вы, наверное, знаете, Jakarta EE — наследница Java EE, которую сейчас переводят в Eclipse Foundation. Это довольно сложный процесс, и он ещё не завершён, так что разработчики пока не могут пользоваться Jakarta EE. Однако в основе всё равно лежат стандарты Java EE, исходной точкой будет Java EE 8. Конечно, в будущем Jakarta EE будет продолжать развиваться подобно тому, как Java EE развивалась в рамках JCP (Java Community Process). Это значит, что сообщество из нескольких компаний, корпораций и отдельных разработчиков будет совместно вырабатывать стандарты для новой enterprise-версии Java.

Из-за этих изменений в Java EE и возник MicroProfile. Его создали несколько вендоров, у которых работают сервера Java EE. Цель здесь — обеспечить более быстрое развитие технологии, меньше завязанное на жёсткие стандарты. Мне кажется очень интересным тот факт, что MicroProfile старается восполнить недостатки Java ЕЕ в том, что касается современных cloud-native микросервисов. Например, в Java EE пока что нет систем для injectable configuration, fault-tolerance, мониторинга, всяких OpenTracing и тому подобного. MicroProfile даёт доступ ко всем этим вещам, так что вам нет необходимости реализовывать их все самостоятельно. При этом почти во всех случаях соблюдается совместимость с Java EE. В качестве основы берутся стандарты Java EE (например, JAX-RS и CDI), с которыми большинство JavaEE-разработчиков уже знакомы. Поэтому когда мне в моём приложении Java EE оказывается необходима fault tolerance, например, я не пишу всё это вручную, а интегрирую MicroProfile с моим приложением. Эти две экосистемы очень хорошо сочетаются друг с другом. У многих приложений, таких как Open Liberty или Payara, рантаймы поддерживают и MicroProfile, и Java EE. Всё, что остаётся сделать в этом случае — включить определённые фичи в рантайм, а затем добавить необходимые проекты MicroProfile в приложение Java EE. Пока мы ждём окончательного перехода Java EE в Eclipse Foundation, можно пользоваться этим решением.

Олег: Считаете ли вы, что MicroProfile нужно сделать частью Jakarta?

Себастиан: Это отличный вопрос, и окончательного решения по нему пока что нет. Лично я считаю, что MicroProfile лучше всего работает как своего рода инкубатор для Jakarta EE. Новый стандарт вначале добавляется в MicroProfile (как это было сделано с OpenTracing или injectable configuration), а затем мы смотрим, как система себя ведёт в продакшне. Когда она достигает зрелости, те её элементы, которые хорошо себя зарекомендовали, становятся полноценными стандартами. Таким образом, мы избавляемся от некоторой неопределённости, поскольку уже знаем, хорошо система работает в продакшне или нет.

Олег: Раз уж речь зашла о стандартах, я видел Eclipse Specification Processes, это был огромный гуглодок, в котором было очень сложно разобраться. Похожим адским клубком выглядели документы с черновиками спецификаций Jakarta EE. Не могли бы вы помочь этот клубок размотать? Например, чем это отличается от Java Community Process?

Себастиан: Eclipse Foundation — опенсорсная организация. В данный момент мы пытаемся определить форму тех процессов, в соответствии с которыми Jakarta EE будет развиваться в будущем. Вы упомянули JCP — так вот, я полностью согласен с мнением, что стандарты для Jakarta EE должны быть сделаны по образцу JCP. Я считаю, что эта модель очень хорошо себя показала. При этом нужно иметь в виду, что ни у одной компании нет монополии на разработку стандартов для Jakarta EE. В этом процессе участвует несколько компаний с более или менее одинаковыми правами, так что он не застрянет в развитии, если одна из них окажется не в состоянии больше в нём участвовать. Я считаю это важным преимуществом, поскольку эта технология очень важная, и её безопаснее разрабатывать в открытом сообществе.

Олег: Такую сложную технологию необходимо на чём-то тестировать. Пользуетесь ли вы Technology Compatibility Kits для Java и Jakarta? Или у вас свой набор тестов?

Себастиан: Это тоже очень важная тема. В JCP все эти TCK обычно имели закрытые исходники. Это было довольно сомнительным преимуществом. С одной стороны, спецификация могла предоставить тесты, которые показывали, являлась ли некоторая реализация допустимой или нет. Но обычный разработчик не знал, что именно было протестировано там внутри, какое было покрытие у этих тестов и т.п. Сейчас TCK стали опенсорсными. В их разработке и улучшении могут теперь участвовать все компании и разработчики. Если оказывается, что продукт какой-либо компании не работает так, как заявлено в спецификации, то можно не только указать на это компании, но и оставить заявку в самом TCK. Или ещё лучше, можно отправить несколько pull-requests и улучшить сам TCK. Так вы улучшите не только софт одного поставщика, но и всю экосистему.

Олег: Есть ещё один продукт, у которого в имени присутствует слово «Profile»: IBM WebSphere Liberty Profile. Коль скоро вы работаете IBM, можете рассказать нам, что это такое и в чём отличие от Open Liberty?

Себастиан: WebSphere Liberty Profile — коммерческая версия Open Liberty. Это сервер приложений Java EE, для которого IBM предоставляет коммерческую поддержку. Я могу ошибаться, но, по-моему, Open Liberty стала опенсорсной полтора года назад. Благодаря этому у enterprise-разработчиков есть теперь бесплатный и опробованный в продакшне сервер приложений. Если же компании нужна коммерческая поддержка или некоторые коммерческие фичи, она может воспользоваться WebSphere Liberty Profile. На дворе 2019 год, и я считаю, что сейчас каждая компания должна предоставлять опенсорсную версию своего продукта, чтобы у разработчиков была возможность бесплатно опробовать продукт. Опенсорс очень важен, и я рад, что у IBM теперь есть несколько вариантов бывшего WebSphere Liberty Server.

Олег: Я слышал, что он написан поверх OSGi. Вы не могли бы рассказать подробнее о том, как он устроен внутри?

Себастиан: Я лично не занимался разработкой Open Liberty, но, насколько мне известно, под ним действительно лежит OSGi. Интересно, что там достаточно просто можно настроить, какие именно фичи будут включены. Если вы хотите использовать только MicroProfile, который охватывает лишь небольшое количество стандартов Java EE, то вы можете настроить систему соответствующим образом. Или можно сделать так, чтобы у вас было полноценное приложение Java EE. Благодаря тому, что в запущенном инстансе включено только то, что действительно необходимо, достигается оптимальное время запуска и минимальное потребление ресурсов.

Олег: Отличается ли конфигурация и использование Liberty Profile от Full Profile? Используются ли одни и те же инструменты в обоих случаях?

Себастиан: Существенных отличий в использовании нет. В отношении выбора фич оба сервера можно настроить одинаково. Если у вас есть приложение Java EE или MicroProfile, настройка будет одинаковой для обоих типов.

Олег: Компании уже давно используют Full Profile. А насколько оправдано использование Liberty Profile в крупных организациях?

Себастиан: Абсолютно оправдано. Даже если предприятие купило коммерческую поддержку, это не значит, что оно обязательно должно использовать Full Profile, вполне разумно использовать более легковесную версию. Если в основе продукта корпорации лежат современные микросервисы и лёгкие рантаймы, то им может быть лучше выбрать именно WebSphere Liberty и настроить её так, чтобы она работала, скажем, только с MicroProfile. К счастью, коммерческая поддержка и коммерческие фичи никак не связаны со старым миром WebSphere, так что сам по себе рантайм на удивление лёгкий и компактный, он запускается очень быстро, его можно развернуть за считанные секунды. Так что если у вас есть современное приложение на основе Java EE, вы можете настроить свои фичи соответствующим образом и включить только те стандарты, которые действительно необходимы. Независимо от того, пользуетесь ли вы коммерческими фичами, вы все равно имеете доступ к этому быстрому и современному рантайму.

Олег: В октябре Oracle выпустили Helidon — это легковесный фреймворк для микросервисов в Java. Насколько я знаю, он не использует ни один из существующих серверов приложений, он построен поверх своего собственного набора библиотек. Вместе они предоставляют основу для построения микросервисов — фичи для конфигурации, настроек безопасности, поднятия веб-сервера и так далее. Поверх этой системы был даже реализован MicroProfile. У меня сложилось впечатление, что разработчики Helidon считают, что в Java EE слишком много легаси, и её нужно выбросить и переписать заново. Что вы об этом думаете?

Себастиан: Helidon — очень интересный проект. Но, если честно, мне кажется наивным считать, что Java EE нужно целиком переписать. Действительно, большинству приложений не нужна Java EE целиком. Как правило, требуется выделенный набор фич / стандартов, чаще всего используемый в enterprise-приложениях. Например, обычный MicroProfile пока что не предоставляет JPA или сложных сценариев для многопоточности. Для этого нужны как минимум некоторые компоненты Java EE. В целом, процесс создания приложения мне сейчас видится таким образом. Опираясь на наиболее важные и современные компоненты Java EE, например, CDI, JPA, JAX-RS, JTA и так далее, мы выбираем нужный нам набор стандартов, при этом игнорируем множество унаследованных вещей, присутствующих в Java EE. Исходя из этого выбора мы берём тот рантайм, который поддерживает все эти фичи. Если мы занимаемся чем-либо, связанным с cloud-native микросервисами, то добавляем к этому стандарты MicroProfile, например, fault tolerance. Но рантайм вроде Helidon не поддерживает фичи, принадлежащие сугубо к Java EE, а между тем, многопоточность или JPA — фичи, которые, по моему опыту, весьма необходимы. Я предпочёл бы рантайм, который поддерживал бы и Java EE/Jakarta EE, и Microprofile, и при этом давал бы возможность выбирать те фичи, которые нужны для конкретного приложения. Например, если вам нужен persistence и у вас есть база данных, вы можете включить JPA. В общем, у вас будет набор фич, очень похожий на MicroProfile, но при этом кое-что от Java EE тоже будет необходимо. Такого рода рантаймы — Open Liberty, Payara, WildFly и так далее.

Олег: Насколько я знаю, одна из наиболее интересных фич, которые будут в ближайшем будущем реализованы в Jakarta — поддержка современных облачных технологий. А как сейчас обстоит дело с Java в контейнерах? Насколько я помню, несколько лет назад на багтрекере OpenJDK было несколько багов, связанных с совместимостью, размером хипа, сигналами и так далее. Можно ли сейчас, в 2019 году, использовать Java в контейнерах?

Себастиан: Да, определённо можно. Причиной большей части проблем, связанных с этим, была не собственно Java, а то, как работал Linux с контейнерами. Зачастую контейнер просто не знал о различных ограничениях на ресурсы, которые можно было выставить. В последних версиях эти проблемы были решены. Теперь Java можно просто запустить в контейнере, и эти параметры будут включены по умолчанию. И если вы запросите размер памяти в системе или размер кучи по умолчанию, эти значения будут указаны верно. Java EE отлично работает в контейнерах Docker и, в целом, хорошо интегрируется с cloud-native технологиями.

Олег: А как насчёт инфраструктуры? Пользуетесь ли вы чем-то вроде Kubernetes или Istio?

Себастиан: Да, достаточно активно. Все мои приложения сейчас написаны на контейнерах Docker, для оркестрации контейнеров обычно используется Kubernetes, а для управления сервисами — Istio. Всё это прекрасно сочетается с подходом современной Java EE. Cloud-native технологии позволяют добавить множество необходимых фич поверх приложения, причём это делается прозрачно для приложения, ему не нужно заниматься вещами, связанными со средой — например, обнаружением сервисов, обеспечением видимости, мониторингом и т.п.

Олег: Что вы можете сказать о нативной интеграции Java EE с Kubernetes и прочей инфраструктурой? Будут ли у нас нативные API для этого?

Себастиан: Настраивать Kubernetes или Istio изнутри приложения пока что нельзя. И такой подход противоречил бы основному принципу cloud-native технологий. Вся среда должна быть прозрачной для вашего приложения. Приложение не должно знать, что оно запущено внутри контейнера Docker, который оркестрируется Kubernetes. Если речь идёт об обнаружении сервисов, приложение может найти и использовать логическое имя сервиса какого-то внешнего бэкенда просто как URL, как имя хоста. А обнаружение сервисов и маршрутизация выполняется Kubernetes при помощи поиска DNS или при помощи Istio. Этот процесс полностью прозрачен для вашего приложения. Я считаю такой подход правильным, потому что задача приложения — реализовывать бизнес-логику, а не заниматься вопросами среды.

Олег: Какое событие прошлого года из мира Java вам запомнилось больше всего?

Себастиан: Я даже затрудняюсь ответить — в Java сейчас происходит очень много изменений, резко выросла частота выхода новых версий. Помимо этого, быстро развиваются современные enterprise-технологии — MicroProfile, cloud-native технологии (Istio, Kubernetes). В прошлом году MicroProfile совершил огромный рывок вперёд, было выпущено множество новых версий. В общем, мы живём в очень интересное время.

Олег: Вы собираетесь выступить на JPoint с докладом «Безотказные приложения на Java Enterprise». Чему он будет посвящён?

Себастиан: Я расскажу о том, что именно нужно иметь в виду enterprise-разработчикам, когда они запускают приложение в продакшне. Одно дело — просто реализовать бизнес-логику приложения; другое — запустить её в суровой и не прощающей ошибок среде продакшна. Я буду говорить об устойчивости современного Java EE-приложения, о том, как в нём работают треды, как сделать приложение отзывчивым, как реализовывать и выполнять соглашения уровня сервисов.

Я жду с нетерпением конференции JPoint. В России я уже был, но в Москве — ещё ни разу. Я всегда рад пообщаться с активными Java-разработчиками, так что если у вас будет возможность к нам присоединиться — будет здорово.

Евгений: Последний вопрос. В России на Хабре недавно было очередное активное обсуждение перспектив Линукса на десктопе (например, могло бы помочь появление одного «официального» дистрибутива). Вы энтузиаст Linux, поэтому хочется спросить: что вы думаете об этом?

Себастиан: Отличный вопрос. Я уже много лет пользуюсь Linux на десктопе, и я согласен с тем, что с ним может быть тяжелее справиться, чем с другими операционными системами, в особенности если у пользователя нет технических навыков. Вопрос в том, поможет ли делу создание единого официального дистрибутива, который было бы проще установить и которым было бы проще пользоваться. На мой взгляд, правильным решением было бы предоставить выбор из различных фич и инструментов, которые поставлялись бы одной некоммерческой организацией. То есть это делалось бы не отдельной компанией, а сообществом, которое могло бы прийти к консенсусу относительно некоего базового варианта для разработчиков. Я сейчас пользуюсь Arch Linux — там всё очень низкоуровневое, после установки система показывает тебе только командную строку. Для большинства начинающих пользователей Linux жизнь с таким вариантом была бы слишком тяжёлой. Я не в восторге от Ubuntu и от их тяжеловесного UI, но такой дистрибутив значительно более доступен для новичков. Простого решения для этой проблемы я предложить не могу — по своей природе Linux устроен так, что в нём всё максимально настраиваемо, вы можете создать такую конфигурацию, которая подходит именно вам. Тем не менее, иметь некоторый разумный базовый вариант, наверное, было бы неплохо.

Олег: Спасибо большое за ответы!

Совсем скоро, 5-6 апреля, Себастиан выступит в Москве на JPoint с докладом «Bulletproof Java Enterprise applications for the hard production life». Помимо него приедут также Simon Ritter, Kohsuke Kawaguchi, Андрей Паньгин и многие другие. Здесь можно ознакомиться с программой.
С первого марта стоимость билетов увеличится.

Автор: Олег Чирухин

Источник