«В Идеале Нам Хотелось Бы Вообще Заменить Spring На Micronaut» — Интервью Грэма Роша О Перспективах Развития Micronaut

Микронавт ворвался в нашу жизнь внезапно, без стука и без объявления войны.

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

Micronaut — это современный фреймворк для JVM для написания модульных микросервисов и бессерверных приложений, использующий для этого возможности GraalVM. В свою очередь, Grails — это фреймворк, появившийся еще в 2005 году и с тех пор постоянно совершенствующийся.

Grails 3 перешёл на SpringBoot в 2015 году, а версия 4.0.0 появилась в июле прошлого года.

У Grails по-прежнему есть своя аудитория, для которой он очень хорошо подходит и решает весьма специфические задачи.

Грэм Рош создал обе эти структуры.

.

Мы пригласили Грэма в нашу виртуальную студию, чтобы обсудить, почему пришлось изобретать велосипеды и делать костыли, стоит ли хоронить Grails и Spring Boot, как поддерживать Jakarta EE, не ломаясь, что будет в Micronaut 2, стоит ли писать Micronaut поверх Micronaut и когда Java наконец умрет. Собеседование проводит:

• Юрий Артамонов из JetBrains — поддерживает Micronaut в IntelliJ IDEA;
• Владимир Ситников из NetCracker — работает над производительностью на Java;
• За разработку конференции JPoint отвечает Олег Чирухин из JUG Ru Group.

OpenSource и мотивация

Грэм: Это требует много времени, денег, и вам нужно быть максимально вовлеченным в бизнес.

Очень часто люди со временем теряют интерес к своему проекту — требуется настойчивость.

Моя карьера до Micronaut и Grails началась в отделе Fujitsu, который разрабатывал системы управления онлайн-обучением на Java. Мои начальники очень интересовались открытым исходным кодом; большая работа была проделана с проектом Apache Cocoon. Сейчас об этом мало кто знает; это была платформа XML/XSLT. Для меня мое знакомство с открытым исходным кодом началось с электронного обучения.

Я написал на Groovy инструмент для преобразования документов Word в учебный материал в нужном формате.

До этого у нас было 15 человек, которые вручную конвертировали материалы из документов Word в формат, который могла обрабатывать наша система онлайн-курсов.

С моей утилитой вся эта работа была автоматизирована, что позволило переключить усилия на более разумные вещи.

Благодаря этому проекту я познакомился с сообществом Groovy и открытым исходным кодом в целом.

Гийом Лафорж (руководитель отдела разработки Groovy и комитета JSR-241 — прим.

ред.) в какой-то момент спросил, не хочет ли кто-нибудь сделать аналог Ruby on Rails для экосистемы Java. Наша компания уже использовала Java, Spring и Hibernate в системах управления обучением наших клиентов.

Это был очень трудоемкий процесс, поэтому я решил использовать Groovy для той же цели в надежде, что это будет более эффективно.

Так появился Grails. С самого начала Grails был частью моей работы в Object Computing, а когда этот проект стал по-настоящему популярным, он стал моей постоянной работой.

Это произошло примерно через год после случившегося.

Мы основали организацию с открытым исходным кодом под названием GT1, которую позже приобрела Spring Source (теперь она называется Pivotal).

Я проработал в Pivotal семь лет. Все это дало мне большой опыт работы с различными фреймворками, и мне захотелось попробовать создать новый фреймворк с нуля, основываясь на накопленных знаниях об ошибках в Spring и Grails. В частности, ошибки, касающиеся потребления памяти, времени запуска и прочего.

Этой новой структурой стал Micronaut. Я думаю, что не смогу создать его внутри Pivotal, потому что он несовместим со Spring. Похоже, эту новую структуру многие встретили с большим пониманием, поскольку на тот момент существовала потребность в более эффективном решении.

Олег: Скажите, откуда вы берете силы изобретать новые инструменты снова и снова? Как вам удается работать над этим годами? Грэм: Вам нужно быть на несколько шагов впереди всех и идти в ногу с последними изменениями в отрасли.

Когда я работал над Grails, индустрия была совсем другой.

Это было больше 10 лет назад, архитектуры тогда были совсем другие, микросервисов не было и в помине.

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

Java тоже не стояла на месте; его разработчики многое сделали для запуска Java в контейнерах.

Отсюда и живой интерес к таким проектам, как Micronaut, GraalVM и им подобным.

Они пытаются оптимизировать Java для работы в новых условиях с новыми нагрузками.

Всегда нужно оставаться актуальным и внедрять инновации.

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

Остерегайтесь комфорта.

Олег: Есть ли секретный трюк, который позволял вам сохранять мотивацию все эти годы? Грэм: Мотивация зависит от того, насколько вы вовлечены в свой проект, насколько он вас затрагивает. Это зависит от того, любите ли вы свою работу.

О себе могу сказать точно, что люблю тебя.

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

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

Для меня всегда было очень важно услышать слова благодарности.

Например, когда ко мне после выступления на JPoint или какой-то другой конференции подходят разработчики и говорят, насколько Grails или Micronaut изменили их жизнь и работу их компаний, это важно.

Что такое Микронаут

Micronaut подключается к компилятору Java, Kotlin или Groovy и генерирует все, что обычный фреймворк, такой как Spring, генерирует во время выполнения, используя отражение (например, определение bean-компонентов).

Благодаря такому подходу полностью исчезает необходимость в размышлениях.

Когда мы только начали работать с Micronaut, мы провели множество тестов производительности приложений Java, Spring и Rails и пришли к выводу, что отражение само по себе приводит к огромному увеличению потребления памяти.

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

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

Именно поэтому мы поставили перед собой задачу полностью отказаться от отражения, и именно поэтому был создан Микронавт. Примерно через несколько месяцев после появления Micronaut компания Oracle объявила, что работает над GraalVM. Это очень интересный проект, в котором есть функция Native Image. Он позволяет создать собственный исполняемый файл для приложения, тем самым экономя потребление памяти, время загрузки и многое другое.

Оказалось, что эта особенность Native Image и Micronaut прекрасно дополняют друг друга.

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

Из всех фреймворков Micronaut является одним из наиболее подходящих для использования с Native Image. В Micronaut главное — предварительные вычисления.

Для меня самое интересное во фреймворках — это компиляция и создание инфраструктуры фреймворка.

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

Все остальное нам было интересно: как эта система ведет себя во время выполнения, сколько памяти она потребляет, какова ее производительность, размер трассировки стека и т. д. Традиционные фреймворки с рефлексией и генерацией байт-кода (будь то cglib, Byte Buddy или что-то в этом роде) подобное) огромные трассировки стека.

Мы хотели, чтобы наш был значительно компактнее.

Micronaut — это Java-фреймворк, подобный Spring, но без отражения, и благодаря этому его потребление памяти значительно ниже.

Судьба Spring Boot, Grails и Groovy

Если вы используете отражение во время выполнения, Spring отлично себя показывает. Но теперь, благодаря Micronaut, у пользователей есть выбор.

Проект Micronaut требует очень мало памяти.

Наши клиенты утверждают, что низкое потребление памяти Micronaut вдвое сократило затраты на Google Cloud по сравнению с другими платформами.

Если новая технология более эффективна, почему бы не использовать ее? Micronaut предоставляет возможность создавать целый ряд новых приложений, причем самых разных, будь то приложения для HTTP-серверов, MessageListeners в Kafka, консольные приложения, лямбды в AWS, бессерверные приложения и т. д. Быстрый запуск очень важен для лямбд и бессерверных приложений.

приложений и низкое потребление памяти.

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

И некоторые другие получат большую пользу.

Важно иметь выбор.

Владимир: Сравнивая Micronaut и Grails, можно ли сказать, что Micronaut можно встроить в современный Grails? Грэм: Да.

В Grails 4 мы добавили Micronaut в качестве контекста родительского приложения для Spring. Мы изменили много кода внутри Grails, чтобы можно было использовать Micronaut. Это позволило существенно сократить время запуска.

Это дало пользователям доступ к некоторым функциям Micronaut, таким как HTTP-клиент. В будущем мы планируем ещё больше внедрить Micronaut в Grails. В идеале мы хотели бы вообще заменить Spring на Micronaut, но это сломало бы приложения многих наших пользователей — та же ситуация, в которой находится Spring. Несмотря на это, Micronaut продолжит играть большую роль в развитии экосистемы Grails. .

Юрий: Считаете ли вы разумным использовать Groovy для написания микросервисов? Ведь это довольно динамичный язык.

Грэм: Groovy — замечательный язык, я давно с ним работаю.

За время своего существования он довольно сильно изменился.

Недавно вышел Groovy 3, и в нем много интересных изменений.

Я убежден, что существуют типы приложений, которые прекрасно работают с Groovy. Но если для вас приоритетом является экономия памяти, то Groovy — не лучший выбор.

Это динамический язык, активно использующий отражение.

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

Несмотря на это, Groovy отлично зарекомендовал себя и прекрасно работает в правильном контексте.

Жертвы ради продуктивности

Чтобы Micronaut работал, ему необходимо подключиться к компилятору.

Если у вас огромный монолитный код с миллионами строк, то с Micronaut ему придётся несладко, да и с любым фреймворком, который вместо того, чтобы выполнять его во время выполнения, пытается всё скомпилировать заранее.

Micronaut намного лучше при использовании с модульными приложениями.

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

Для Gradle у нас есть поддержка инкрементной обработки аннотаций, что устраняет необходимость перекомпиляции всего проекта.

Разница в скорости компиляции не такая уж и большая, но об этом стоит помнить.

Именно этим мы пожертвовали ради снижения потребления памяти.

И мы не единственные: любое использование AOT сопряжено с жертвами.

GraalVM уже заработал плохую репутацию из-за времени компиляции.

Предположение о закрытом мире

Micronaut можно использовать на обычной JVM. Более того, если вам это действительно нужно, вы даже можете использовать отражение.

Многие люди делают это.

Мы поддерживаем Hibernate, и он обязательно использует рефлексию; мы никак не можем на это повлиять, просто так работает Hibernate. С другой стороны, Micronaut Data имеет поддержку JDBC, и рефлексия там никак не используется; чтение и запись в базу данных происходит без него.

Мы предоставляем альтернативу тем, кто хочет добиться максимальной оптимизации своих приложений без использования Hibernate или JPA. Действительно, Micronaut Data JDBC пользуется спросом! Владимир: Если я разделю приложение на несколько модулей компиляции, например JAR-файлов со свободным доступом к классам друг друга, сможет ли Micronaut правильно их связать? Грэм: Сможет. Однако если мы обратимся к какому-то внешнему проекту с аннотацией javax.inject, который не собран через Micronaut, мы не сможем его интерпретировать и выполнить внедрение — для работы нужны метаданные Micronaut, а в данном случае они отсутствуют. Они появляются только при компиляции приложения Micronaut. Проблема возникает из-за природы этой технологии.

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

Ошибки в Микронавте

Например, проблемы с потреблением памяти Spring, скорее всего, будут сохраняться до тех пор, пока существует сам Spring. Об этих багах все знают, и они не критичны, но они существуют. Грэм: Конечно, Spring основан на очень специфической архитектуре.

Владимир: Приложения, работающие с данными, часто имеют проблемы с несогласованностью — для этого всегда есть открытые тикеты, которые невозможно закрыть.

Есть ли в Micronaut подобные баги или постоянно открытые проблемы? Грэм: Теперь я не могу придумать ничего, что нельзя было бы исправить.

Есть проблемы, которые мы очень хотим исправить, но пока у нас просто нет на это ресурсов.

Например, мы не можем полагаться на kapt для обработки аннотаций в Котлине.

Было бы здорово написать нативный плагин и выкинуть kapt для Kotlin и заодно реализовать поддержку Scala с помощью их плагинов компилятора AST. Вряд ли мы до этого доберемся в ближайшее время, поскольку у нас уже есть работающее решение, хотя оно и не идеальное.

У kapt есть недостатки — Java AST, к которому kapt предоставляет доступ, не предоставляет информацию об аргументах метода по умолчанию, в отличие от нативного Kotlin AST. У нас есть проблемы, которые мы могли бы решить, но у нас просто нет на это времени.

Если говорить о вещах, которые в принципе невозможны, то у нас никогда не будет скорости компиляции, сравнимой с проектом, не обрабатывающим аннотации.

Зачем изобретать колеса?

Проблема в том, что вся модель программирования Spring Boot в значительной степени зависит от отражения и генерации байт-кода во время работы приложения.

На этом основаны все подпроекты в экосистеме Spring — Spring Data, Spring Batch и все остальные.

У нас есть Micronaut для Spring, и он использует предварительные вычисления для аннотаций Spring. Но такой проект несовместим с модулями Spring. Таким образом, у команды Spring Boot нет простого способа решить эту проблему, не разрушая существующую экосистему.

Владимир: Вы говорили о проблеме обратной совместимости — это проекты с большой историей, и на них опирается множество уже написанных приложений.

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

Новое – хорошо забытое старое

Я думаю, Micronaut можно было создать лет 10 назад, просто на менее зрелой платформе.

Процессоры аннотаций широко используются в экосистеме Android, и это не новая система.

Если задуматься, Android выбрал процессоры аннотаций по той же причине, по которой они были выбраны в Micronaut: они изо всех сил старались избежать отражения и генерации байт-кода во время выполнения, поскольку на мобильных устройствах это очень медленно и требует много памяти.

В общем, серверной Java есть чему поучиться у Android. Мы только сейчас начинаем использовать шаблоны, которые использовались при создании Android. Многое из того, над чем мы работали, уже реализовано в Android. Google написал фреймворк Dagger, который очень похож на Micronaut. Вчера кто-то сказал, что Микронаут — это Даггер на стероидах.

Я думаю, это справедливое сравнение: Dagger выполняет только внедрение зависимостей, а Micronaut делает множество других вещей.

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

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

И не только Micronaut работает над этой проблемой; другие платформы также пытаются оптимизировать память.

Поддержка спецификаций

Этот принцип подтверждается тем фактом, что javax будет переименован в jakartax. Мы предпочитаем предоставлять поддержку спецификаций поверх Micronaut. У нас есть поддержка проверки bean-компонентов (javax.validation) и javax.inject. Недавно мы выпустили Micronaut Serverless, поэтому теперь у нас есть поддержка бессерверных приложений.

Мы выпустили Micronaut JAX-RS, который позволяет использовать аннотации JAX-RS. Преимущество подхода в том, что при переходе с javax на jkartax нам не нужно будет нарушать совместимость с существующими приложениями.

Все необходимое будет изменено в следующем выпуске поддержки JAX-RS или другого модуля.

Micronaut имеет множество удобных функций, которые зависят от обработки аннотаций во время компиляции.

Micronaut может преобразовать значение одной аннотации в значение любой другой аннотации во время компиляции.

Если вы определяете аннотацию javax.validation, вы можете привязать ее к внутреннему представлению и не привязывать себя к этому API. Поэтому при переименовании пакетов нам просто нужно связать их с другим набором аннотаций.

По нашему опыту, многие спецификации, которые начинаются с большой шумихи, затем просто исчезают. Примеров этому множество, некоторые из них — Open Tracing, Open Telemetry. Впервые мы увидели MicroProfile, когда Micronaut находился в разработке уже шесть месяцев.

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

Владимир: Рекомендуете ли вы своим пользователям создать дополнительный слой поверх Micronaut? Грэм: Им решать.

Мы стараемся принимать правильные решения с точки зрения пользователей фреймворка.

Я понял эту идею, и в этом аргументе есть определённые основания.

Но у нас есть четкая политика релизов, есть семантическое версионирование.

Мы гарантируем, что не нарушим совместимость любых приложений, использующих Micronaut 1.x. В Micronaut 2.x могут быть изменения, нарушающие совместимость, но все они будут задокументированы.

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

Мы обеспечиваем поддержку спецификаций, но не привязываем себя к пространству имен конкретного API, поэтому не попадаем в ситуацию, когда тот API, от которого мы зависим, внезапно исчезает.

DevOps

Обычно мы выпускаем релизы каждые несколько недель.

Наши релизы небольшие и обычно исправляют три или четыре проблемы.

Одним из преимуществ Micronaut является то, что он имеет хорошо развитую инфраструктуру сборки.

Наш процесс выпуска заключается в том, что мы просто помечаем репозитории.

Все остальное автоматизировано: загрузка в Bintray, синхронизация с Maven Central, публикация документации, обновление сайта, создание примечаний к выпуску и тому подобное.

Тестирование, реакция на проблемы

Вы собираете такие случаи? Где вы берете данные испытаний? Грэм: Мы получаем много отчетов о проблемах, это важный источник для тест-кейсов.

Но помимо них существует большая экосистема субмодулей Micronaut, они также постоянно выявляют проблемы в ядре Micronaut. Кроме того, для каждого коммита мы запускаем большой набор тестов, проверяющих работу Micronaut с GraalVM Native Image и обеспечивающих совместимость.

В этом нам помогает Oracle, а команда GraalVM получает оповещение при нарушении совместимости — такие случаи случались не раз.

Мы проводим много автоматизированного тестирования в различных случаях.

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

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

Их нужно решать по мере поступления.

В целом, поскольку люди чаще используют фреймворк, наше тестовое покрытие увеличивается.

Скорость запуска и производительность Micronaut обеспечивают важное преимущество с точки зрения тестирования.

Наш набор тестов огромен, в нем тысячи тестов, но когда компьютер полностью загружен, я могу запустить весь набор локально за 5 минут. Разница с Grails здесь колоссальная.

В нем также есть юнит-тесты ядра, есть несколько тысяч тестов, а также сотни функциональных тестов.

Поскольку Grails зависит от Spring, он запускается значительно медленнее, а запуск его набора функциональных тестов занимает полчаса.

В ядре Micronaut есть тысячи функциональных тестов, и все они должны запускать сервер и отправлять клиентские запросы.

Несмотря на это, время выполнения этих тестов на Github Actions составляет где-то 10-12 минут. Это значительно облегчило нам разработку.

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

Владимир: Тестируете ли вы производительность разных компиляторов? У вас довольно тесная интеграция с компилятором Java. Грэм: Да, помимо функциональных тестов, у нас есть тысячи тестов, которые используют API компилятора Java для компиляции байт-кода, динамической компиляции исходного кода и его тестирования.

Совместимость компилятора

При разработке фреймворка вы наверняка хотите знать, совместим ли он с последней версией Java? Грэм: Около года назад с нами связалась команда OpenJDK и пригласила нас принять участие в их программе раннего тестирования OpenJDK. Мы запускали тесты параллельно для OpenJDK 8, 11 и 13, а также для каждой предварительной версии OpenJDK 14. Где-то в Интернете есть страница, на которой перечислены все проекты, которые систематически тестируют OpenJDK, и Micronaut находится на ней.

список.

Команда и интересы

Сколько у вас участников проекта? Получаете ли вы большую помощь от людей в сообществе? Грэм: Обычно у нас на постоянной основе работают около трех человек.

Кроме того, в зависимости от количества клиентов количество разработчиков увеличивается и уменьшается.

Есть разработчики, которые хотят временно работать над программным обеспечением с открытым исходным кодом.

В сообществе Micronaut значительно больше участников, чем в Grails. Думаю, одна из причин этого в том, что Micronaut написан в основном на Java, а Grails — на Groovy, и многим, возможно, было сложно преодолеть языковой барьер при работе с ним.

Нам очень помог один проект — Micronaut OpenAPI, который обеспечивает поддержку Swagger. Это очень интересный проект, поскольку он работает иначе, чем другие, поддерживающие Swagger. Обычно для интеграции создается компонент, который анализирует работу приложения во время выполнения, а затем с помощью отражения создает определение Swagger во время выполнения.

При таком подходе потребление памяти очень велико.

Представьте, что вам нужно динамически генерировать огромную документацию в Yaml для большого приложения во время его работы, а для этого нужно анализировать веб-контроллеры, методы и т.д. В нашем проекте используется API TypeElementVisitor от Micronaut, который позволяет работать с AST. независимо от языка, то есть одинаково работает с Kotlin, Ruby и Java. Это позволяет генерировать спецификации OpenAPI во время компиляции.

Они создаются в статическом файле swagger.yaml, который можно хранить в статических ресурсах.

Благодаря этому определение Swagger не требует какой-либо обработки во время выполнения.

Микронавт в реальном мире

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

Вот тут-то и пригодятся преимущества Micronaut. Есть и другие примеры, гораздо большего масштаба.

Я думаю, все слышали о Майнкрафте — это, наверное, самая большая компьютерная игра в мире.

У них много микросервисов, и значительную их часть они сейчас мигрируют на Micronaut. Это позволит им более эффективно использовать ресурсы.

Им приходится иметь дело со всеми сложностями большой архитектуры на основе микросервисов.

Основываясь на их ответах, мы постоянно оптимизируем наш HTTP-клиент, чтобы лучше удерживать соединения и тому подобное.

Их отчеты о проблемах позволили нам исправить множество ошибок и улучшить приложение, поэтому мы рады сотрудничеству.

Существует множество примеров использования Micronaut. Еще один такой пример — сеть супермаркетов Target в США.

Micronaut позволил им существенно сократить расходы на Google Cloud.

Интернет вещей

Полезен ли Micronaut в этом контексте? Разумно ли использовать его в контроллерах умных выключателей света в вашем доме? Грэм: Да, конечно.

В Object Computing мы сейчас работаем над проектом IoT. Мы создаем инфраструктуру поверх облака Amazon AWS IoT. Мы используем Eclipse Paho для интеграции MQTT. Micronaut идеально подходит для этой задачи.

Наш фреймворк создан не только для веба, он может работать как на Android (можно запустить на телефоне), так и на IoT-устройствах, на Raspberry Pi. Grails и Micronaut сильно отличаются друг от друга.

Основное отличие состоит в том, что Grails — это веб-фреймворк, ориентированный на CRUD, а Micronaut гораздо более универсален.

Облачная Java

Какие новые приложения в настоящее время доступны в этой области? Или все же невозможно использовать Java в облаке? Грэм: Ну а ведь это вполне реально.

Все всегда хотят похоронить облачную Java, но почему-то не получается.

Java, Spring Boot — это огромные проекты, сейчас существует большой интерес к Micronaut, и есть много крупных организаций, которые используют Java в облачной среде.

Я думаю, что в ближайшем будущем мы увидим много интересных инноваций в этой области.

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

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

Это избавит от проблемы «холодного старта», поскольку вместо запуска всей JVM вы можете уже «прогреть» JVM с работающими функциями.

Ну и вообще облачная Java — активно развивающееся направление.

Ведь значительная часть облачной инфраструктуры реализована на Java:K Теги: #программирование #разработка сайтов #java #micronaut

• Доступ К Вашему Компьютеру Из Любого Места

  19 Oct, 24

• Как Получить Помощь В Linux

  19 Oct, 24

• Книга «Путь Программиста».

  19 Oct, 24

• Проблемы С Управлением Данными? Как Ии И Машинное Обучение Могут Решить Одну Из Наших Самых Больших Проблем

  19 Oct, 24

• Стоит Ли Apple Продавать Windows?

  19 Oct, 24

• Acer Iconia Tab A701 — Возвращение Джедая

  19 Oct, 24

• Внимание! Linux-Версия Эксплойта Eternalblue

  19 Oct, 24

• Выступление На Ted

  19 Oct, 24

• Счетчик Просмотров На Ютубе

  19 Oct, 24

• Как Интегрировать Ckeditor В Angularjs

  19 Oct, 24