У Java было два хороших десятилетия. Тем из нас, кто помнит выпуск языка программирования, трудно поверить, что прошло почти двадцать пять лет с тех пор, как он был выпущен и сделал нашу жизнь намного проще. За прошедшие десятилетия Java расширилась и адаптировалась для решения всех задач, которые перед ней стояли.
Или почти каждый вызов, то есть. Те самые особенности, которые сделали Java настолько эффективной при адаптации к новым средам и задачам — тот факт, что новые библиотеки и сервисы можно добавлять модульным образом — означают, что многие задаются вопросом, останется ли он лучшим языком для использования.
Это потому, что, как мы также указывали в нашем отчете о будущем Java, контейнеризация сейчас набирает обороты. И, к сожалению, у использования Java в контейнерах есть реальные недостатки.
Quarkus — один из набора инструментов, которые пытаются обойти эту проблему. Но сможет ли он вернуть Java на подобающее ему место даже в эпоху контейнеризации? В этой статье мы узнаем.
Переход к контейнеризации
Во-первых, стоит напомнить себе, что на самом деле означает контейнеризация сегодня. В настоящее время обсуждение Docker, Kubernetes, микросервисов или CI/CD настолько распространено, что мало кто из нас задумывается о том, как эти подходы работают на более фундаментальном уровне.
По сути, контейнеризация — это подход к программированию, при котором приложение внутри программного контейнера написано на неродном языке (в данном случае — на Java). Это означает, что эти контейнеры не зависят от платформы (или, выражаясь жаргоном, «независимы от платформы») и могут работать на огромном количестве различных аппаратных и программных платформ.
Как подробно объясняет ИТ-эксперт Барбара Эриксон из Cloud Defense, контейнеры упрощают распределенную разработку и делают ее интуитивно понятной для больших команд, а также могут автоматизировать работу после развертывания, как вы никогда не поверите. Это достигается за счет изоляции различных приложений в разных цифровых «контейнерах для повышения безопасности и переносимости».
Звучит знакомо?
Так и должно быть, потому что вот что странно в контейнеризации и Java — обе пытаются достичь одного и того же результата. Java всегда разрабатывался как язык написал один раз, работает где угодно в терминологии исходных выпусков. Эта независимость от платформы является одной из основных причин, почему она стала такой популярной, и, как ни странно, также одной из причин, по которой Java не так хорошо работает в контейнерах.
Проблема с Явой
Java традиционно используется для защиты и обработки данных на удаленных серверах. Например, Java предоставляет расширения уровня защищенных сокетов (SSL), которые помогают дополнительно обеспечить безопасные соединения и передачу данных между серверами и клиентами, работающими через сетевое соединение. Сегодня примерно 25% всех доменов имеют шифрование SSL, многие из которых используют расширения безопасных сокетов Java.
Но не поймите меня неправильно: нет ничего плохого в том, чтобы время от времени использовать контейнеризованную Java в бессерверной среде. В частности, в процессе разработки упаковка Java в контейнеры может обеспечить гранулярную масштабируемость, которая имеет неоценимое значение при опробовании новых идей. Такой подход, наряду с заимствованием некоторых эффективных примеров кода для программирования на Java, может дать разработчикам свободу пробовать разные языки.
Однако у этого подхода есть и несколько существенных недостатков.
Наиболее фундаментальный из них вызван тем фактом, что Java и контейнеры — как я только что указал — пытаются достичь одной и той же цели.
Контейнеры при правильной реализации содержат все, что необходимо для запуска определенного приложения (почти) на любом оборудовании, которое вы хотите. В результате они обычно содержат несколько избыточных библиотек и экзотический код, который выполняется только в том случае, если вы (пытаетесь) запустить свой контейнерный код на каком-то столь же экзотическом оборудовании.
Java, поскольку она также независима от платформы, также содержит эти элементы. Это означает, что во многих случаях контейнеризация Java является излишним. Вы делаете что-то дважды (делая свой код широко совместимым), что вам нужно сделать только один раз.
Это создает две проблемы.
Один из них очевиден — контейнеризованная Java может иметь значительный дефицит производительности по сравнению с обычной Java или другими языками, используемыми в том же контейнере. Ваше оборудование потратит много времени на выяснение того, какие библиотеки ему нужно использовать — один раз для контейнера, а затем еще раз для самой Java — и это может сильно его замедлить.
Вторая проблема должна быть столь же очевидной, но часто это не так. Каждый раз, когда вы усложняете свой код — например, добавляя дополнительные избыточные библиотеки для малоизвестных аппаратных архитектур — вы усложняете его защиту. Одно из основных направлений исследований последних лет было как бороться с уязвимостями безопасности Java путем блокировки малоиспользуемых библиотек и функций, которые могут содержать вредоносное ПО или уязвимости безопасности десятилетней давности.
Как человек, который много лет пытался сделать Java более безопасным, позвольте мне вас умолять: пожалуйста, не добавляйте еще один уровень сложности к тому, что уже является сложным языком.
Оптимизация Quarkus
Вернее, не делайте этого без использования такого инструмента, как Quarkus. Quarkus — один из группы инструментов, которые стремятся преодолеть некоторые из проблем, о которых я упоминал выше. Инструмент оптимизирует Java для работы в бессерверных, облачных средах и средах Kubernetes, удаляя огромное количество кода, который не нужен для запуска Java таким образом.
Конечно, можно настроить собственную Java так, чтобы избежать некоторых из этих проблем. Вы можете вручную обрезать свой код, чтобы он соответствовал используемому типу контейнеризации, или даже использовать предварительно упакованные версии Java, специально разработанные для конкретных сред контейнеризации. Подобные сервисы стали важной частью преобразования Java в облачную эпоху, потому что они предлагают преимущества в производительности и безопасности по сравнению с использованием необработанной Java или упаковкой других языков в контейнеры.
Проблема с этим подходом, однако, заключается в том, что, хотя он может сэкономить время вычислений, он определенно не экономит ваше время. Quarkus берет на себя большую часть тяжелой работы по оптимизации Java, применяя стандартизированный набор оценок к вашей уже существующей контейнерной Java и убирая большую часть ее сложности.
Будущее
В самом широком смысле такие инструменты, как Quarkus, являются просто продолжением процесса, который шел с момента появления Java более двух десятилетий назад. Сейчас этот язык настолько хорошо известен и его преподают такому большому количеству студентов в рамках их первых курсов в колледже, что вопросы о том, является ли Java по-прежнему лучшим выбором для разработчиков, остаются в основном академическими.
Другими словами, хотя некоторые из нас могут время от времени задавать вопросы о том, является ли Java по-прежнему лучшим инструментом для использования наряду с новыми технологиями, такими как контейнеры, такие разработчики, как сотрудники Red Hat, уже на шаг впереди нас. Радость, эффективность и результативность использования Java означают, что некоторые из нас всегда найдут новые и лучшие способы сделать это, что бы ни принесло будущее.
