Выберите нужные службы Azure для приложений Java
В этой статье описано использование служб Azure для развертывания приложений Java, подчеркивая поддержку Azure для различных технологий и архитектур Java. В нем описываются такие методы развертывания, как "Lift and Shift", контейнеризация и платформа как услуга (PaaS), адаптированные к различным уровням управления и простоты.
Статья выступает за мышление A+B, советуя вам выбирать службы на основе потребностей приложения по фиксированному выбору A или B. Он предлагает рассмотреть вариант использования, бизнес-цели, безопасность и бюджет для гибкого подхода. В этой статье описывается партнерство Корпорации Майкрософт с лидерами экосистемы Java для улучшения взаимодействия с разработчиками и рекомендуется использовать службы Azure для развертывания приложений Java в качестве источника, двоичных файлов или контейнеров. Этот нюансный подход помогает сосредоточиться на инновациях, поддерживаемых обязательством Майкрософт предоставлять приложениям Java наиболее подходящие службы Azure для стратегии развертывания, максимизировать эффективность, масштабируемость и экономичность.
Развертывание любого приложения Java с уверенностью и легкостью
Экосистема Java включает различные технологии, такие как Java SE, Jakarta EE (преемник Java EE и J2EE), Spring, многочисленные серверы приложений и другие платформы. Независимо от того, что вы делаете с Java , например создание приложения, использование платформы и запуск сервера приложений , поддержка Azure рабочей нагрузки с большим выбором. Аналогичным образом поддержка Azure любую архитектуру приложений — от монолитных приложений, работающих на виртуальных машинах или в контейнерах до облачных приложений на основе микрослужб, работающих в полностью управляемых службах.
Azure предлагает следующие три основных метода для запуска приложений Java в облаке, адаптированных к различным уровням управления и простоты:
Подход "Lift and Shift" обеспечивает минимальное изменение существующих приложений непосредственно в Azure Виртуальные машины.
Контейнеризация обеспечивает гибкость, при этом Служба Azure Kubernetes (AKS) и Azure Red Hat OpenShift являются основными платформами для оркестрации контейнерных приложений.
Платформа как услуга (PaaS) представляет собой вершину простоты и эффективности, обеспечивая оптимальную производительность разработчика и операционную управляемость, часто связанную с наиболее экономичной общей стоимостью владения.
Независимо от этапа разработки приложений Java Azure предоставляет совместимое облачное решение для удовлетворения ваших требований. Дополнительные сведения об этих предложениях см. в статье "Развертывание приложений Java с уверенностью и легкостью".
Полная переносимость для приложений Java: простое развертывание в любом месте
Независимо от того, какую службу Azure вы выбираете для приложения Java, гарантируется гибкость приложения. Так как у вас есть код Java и его скомпилированные выходные данные, у вас есть свобода развертывать приложение в любом месте, будь то на локальном компьютере разработки, на серверах сборки, локальных средах или любой облачной платформе выбранной вами платформы. Переносимость приложения находится в руках.
Конечно, когда есть так много вариантов, вы сталкиваетесь с дилеммой.
Дилемма — использование службы A или B для приложений Java
Если вы перейдете по предложениям Azure, вы можете столкнуться с дилеммой выбора наиболее подходящей службы Azure для запуска приложений Java. Этот выбор имеет решающее значение, так как он влияет на планирование ресурсов, бюджет, временная шкала проектов и в конечном итоге время вашего приложения на рынок. Решение влияет не только на начальные затраты на развертывание, но и на текущие расходы на обслуживание.
В прошлом организации часто чувствовали себя вынужденными выбирать между двумя платформами, технологиями или конкурирующими решениями для своих программных приложений. Например, организациям пришлось решить между webLogic или WebSphere для приложений Java Enterprise, Docker Swarm или Kubernetes для управления контейнерами или контейнерами и виртуальными машинами (виртуальными машинами) для развертывания. Этот процесс принятия решений называется "A или B mindset", и он значительно отличается от A/B тестирования, который является методом сравнения двух версий веб-страницы или приложения друг с другом, чтобы определить, какой из них работает лучше. Вместо этого мышление A или B в этом контексте заключается в выборе одной платформы или технологии для развертывания приложений. Это происходит из традиционных локальных методик, где решения часто ограничиваются такими факторами, как упакованные модели доставки программного обеспечения, существенные предварительные инвестиции в инфраструктуру и лицензирование программного обеспечения, а также длительные сроки выполнения, необходимые для создания и развертывания любой платформы приложений.
Это мышление в Azure может привести к чрезмерному времени, потраченного на создание одной платформы, которая пытается разместить все приложения, потенциально введя задержки и неэффективность. Однако Azure предлагает более выгодный подход, поощряя переход от этого ограничивающего мышления к одному, который принимает лучшие из обоих миров, в конечном счете дает лучшую отдачу от инвестиций (ROI).
При переходе в Azure облачная среда предлагает гибкую парадигму, в которой можно подготавливать и отключать ресурсы в соответствии с вашими потребностями, устраняя необходимость выбирать между одной службой друг друга. Эта гибкость в подходе A+B, стратегия, которая отличается от традиционного мышления A или B, поощряя более широкий, более инклюзивной способ мышления. Azure упрощает эту смену, делая ее удобной и экономичной для смешивания преимуществ нескольких служб и внедрения мышления A+B. Этот подход подчеркивает принцип выбора служб, которые лучше всего соответствуют конкретным потребностям вашего приложения, в основном выступая за выбор подходящего инструмента для работы в руках.
Переход на мышление A+B позволяет организациям расширить свои процессы принятия решений и технические стратегии, охватывая новые возможности и возможности, которые предоставляет этот менталитет. В этой статье описаны принципы мышления A+B, позволяющие разумно выбрать службы Azure, которые наиболее эффективно соответствуют требованиям вашего приложения. Независимо от того, является ли azure Spring Apps, приложение Azure Service, Azure Container Apps (ACA), Служба Azure Kubernetes или Виртуальные машины, мышление A+B предоставляет вам широту для оценки и выбора из массива служб Azure для размещения приложений. Эта философия применима универсально, трансцендируя границы языка и платформы. Несмотря на то, что приложения Java здесь сосредоточены, мышление A+B одинаково актуально и полезно для приложений, разработанных на любом языке программирования.
Охватывая мышление A+B, вы не ограничиваетесь одной предварительно определенной службой. Вместо этого вы можете объединить службы таким образом, чтобы лучше всего соответствовать уникальным требованиям вашего приложения. Этот подход не только повышает гибкость и масштабируемость, но и оптимизирует затраты и эффективность работы. Этот подход гарантирует, что техническая стратегия является такой же динамической и адаптируемой, как и в облачной среде, в которой вы работаете.
Почему не нужно думать о службе A или B
Выбор подходящей облачной службы для приложений не должен быть двоичным решением между службой A или службой B, благодаря гибкости и широте возможностей облачных предложений, особенно с Azure. В следующих разделах описано, почему придерживаться традиционного выбора "один или другой" не требуется, и как внедрение более гибкого подхода может воспользоваться вашими операциями.
От старых привычек к новой гибкости
Традиционно развертывание ИТ-систем включало значительные предварительные инвестиции в оборудование и программное обеспечение, а также длительное время установки. Эта среда логическая, чтобы тщательно выбрать одну платформу и оптимизировать все вокруг, чтобы сэкономить на затратах и ресурсах. Однако облачная среда, в том числе Azure, вводит смену парадигмы с учетом спроса и эластичной природы. Вы платите только за то, что вы используете, и корректировка ресурсов в соответствии с вашими потребностями становится простой без бремени первоначальных капитальных расходов.
Переход в облако
Переход в облако и в Azure, в частности, приводит к значительному изменению способа управления инфраструктурой и платформой. Большая часть тяжелого подъема, ранее плечом вашей организации, теперь переходит в Корпорацию Майкрософт, как показано на следующей схеме. Это изменение упрощает операции и сокращает усилия, необходимые для управления приложениями. Ограничения управления несколькими платформами не связаны, освобождая вас от выбора лучшего инструмента для каждой работы, не беспокоясь о дополнительных затратах и сложностях.
На следующей схеме показана модель общей ответственности между клиентом и поставщиком облачных служб:
Выбор оптимального соответствия для каждой потребности
В этом новом облачном мире процесс принятия решений становится больше о выборе подходящего инструмента для правильной работы, а не попытке соответствовать всем вашим потребностям в одной предопределенной службе. Выбор между Служба Azure Kubernetes и Azure Spring Apps для приложений Spring Boot или любым другим набором служб, фокус перемещается на то, что лучше всего соответствует требованиям каждого конкретного приложения.
Рост микрослужб
Внедрение микрослужб также поддерживает этот гибкий подход. По проектированию микрослужбы поощряют использование наиболее подходящих технологий для каждой службы, повышая технологическое разнообразие, которое естественно соответствует мышлению A+B. Этот подход заключается в использовании сильных сторон различных служб для создания более надежной, эффективной и масштабируемой архитектуры приложений.
Преимущества охвата A+B
Внедрение мышления A+B предлагает несколько ключевых преимуществ. Это обеспечивает большую гибкость и гибкость, позволяя выбирать наиболее подходящие инструменты и службы для каждого аспекта операций. Такой подход не только приводит к повышению эффективности ресурсов и затрат, но и сокращению времени на рынок ваших продуктов. В конечном счете, этот подход повышает эффективность работы, выравнивая ваши технологии более тесно с потребностями и целями бизнеса.
В целом, облако и Azure, в частности, предлагает новый способ развертывания приложений и управления ими. Отключаясь от ограниченного выбора A или B и охватывая мышление A+B, вы можете принимать решения, которые более согласованы с конкретными потребностями ваших приложений, что приводит к повышению эффективности, гибкости и экономии затрат.
Практические рекомендации по переходу на умостроение A+B
В следующем списке перечислены некоторые ключевые принципы, которые можно использовать в качестве руководства для перехода к мышлению A+B и продолжению с ним:
Переход от варианта использования к решению, а не наоборот. Часто многие команды программного обеспечения сначала решают технологию, а затем пытаются принудительно вписать варианты использования и дизайн. Во многих случаях этот подход несет значительные издержки с точки зрения затрат, времени разработки, ресурсов и операционных расходов. Получите ясность в вариантах использования и требованиях, как функциональных, так и нефункциональным, прежде чем переходить к решению.
Понять ваши бизнес-цели, характер бизнеса и вашей конкуренции, а также как часто вам нужно развертывать новые возможности в рабочей среде. Вы всегда должны разработать свое решение для удовлетворения бизнес-целей и целей.
Общие сведения о требованиях к безопасности и соответствию требованиям. В эпоху облака, где все доступно через Интернет, безопасность имеет решающее значение и не является переговорным. Кроме того, в зависимости от используемой отрасли приложение может соответствовать определенным требованиям соответствия. Необходимо разработать решение для атак с повышенной безопасностью и соответствия требованиям.
Общие сведения о бюджете и временная шкала. Четкое представление о бюджете для первоначальной разработки, текущих операций и будущих выпусков. Кроме того, ознакомьтесь с временная шкала. Стоимость отложенных проектов, как с точки зрения дополнительных расходов, так и негативного влияния на бизнес, часто недооценивается. Разработка решения для удовлетворения бюджета и временная шкала.
Подумайте, где применимо облако. Облачная архитектура и технологии — это подход к проектированию, созданию и эксплуатации рабочих нагрузок, встроенных в облако, а также к использованию модели облачных вычислений. С помощью облака вы можете создавать и развертывать приложения в рабочей среде быстрее. Облако также предоставляет возможности, которые могут быть недоступны в локальной среде, например эластичность, глобальный масштаб, расширенная аналитика, ИИ и машинное обучение (ML). Разработайте решение на основе облачных технологий как можно больше.
Подумайте, что язык и региональные параметры DevOps. DevOps — это не просто инструменты или процессы, это практика разработки программного обеспечения, которая способствует совместной работе между разработкой и операциями, что приводит к более быстрой и надежной доставке программного обеспечения. Обычно называется языком и региональными параметрами, DevOps подключает людей, процессы и технологии для обеспечения непрерывной ценности.
Выберите решение, соответствующее бизнесу и нефункциональным требованиям, то есть:
- Самый быстрый способ реализации.
- Экономия с точки зрения затрат, связанных с навыками, созданием, развертыванием и операциями.
- Легко работать.
- Полностью совместим с автоматизацией.
- Поддержка DevOps по дизайну.
Эти принципы помогут вам сосредоточиться на том, где оно должно быть - на создании решения, которое соответствует вашим бизнес-целям, а не принудительной адаптации решения к предопределенной платформе.
Исключения
Как и все остальное, существуют исключения для A+B. Следующий список не является исчерпывающим, но предоставляет рекомендации по некоторым исключениям, которые могут возникнуть:
Стратегия предприятия. Например, некоторые предприятия используют корпоративное внедрение контейнеров для создания и развертывания приложений, так как они могут иметь несколько языков программирования в игре, и они хотят создавать и развертывать все приложения в едином режиме.
Слишком далеко вниз по строке с выполнением. Возможно, вы выбрали решение перед анализом A+B. Если вы уже глубоко в выполнении решения, продолжайте с ним, но для следующего приложения используйте принципы мышления A+B, чтобы выбрать подходящее решение для вашего варианта использования.
Миграция крупных центров обработки данных. Чтобы ускорить переход в облако, предприятия обычно используют стратегию под названием "лифт и смена", которая включает миграцию серверов (размещение приложений) в Azure с помощью таких инструментов, как миграция Azure. Некоторые используют этот подход для переноса центров обработки данных в Azure и их завершение в эффективном и экономичном режиме. В этом сценарии рекомендуется использовать мышление A+B для модернизации приложений после миграции в Azure.
Основные рекомендации
Мы предоставили вам платформу для мышления и принципов, которые можно использовать для выбора подходящих направлений в Azure для ваших приложений. Это не один размер, который соответствует всем. Это не A или B, но A + B.
На следующей схеме приведены основные рекомендации по выбору службы Azure для любого приложения:
Выбор подходящих служб Azure для приложений Java
Чтобы упростить процесс выбора среди множества вариантов технологий для приложений Java в Azure, мы создали простое дерево принятия решений, чтобы помочь разработчикам, клиентам и системам интеграторам в их оптимальной службе Azure.
Помимо практического руководства по рассмотрению нефункциональных требований, с технической точки зрения, первоначальный вопрос, который следует рассмотреть, является ли вам нужен контроль над инфраструктурой. Если вы этого не сделали, управляемые службы являются лучшими, наиболее рекомендуемый маршрут. Характер приложений , независимо от того, они основаны на Spring или App Server, см. в следующих руководствах: приложения Spring соответствуют Azure Spring Apps, а служба приложение Azure подходит для приложений Tomcat или JBoss EAP.
Для тех, кто требует управления инфраструктурой, выбор зависит от параметров многооблачной технологии: Azure Виртуальные машины предлагает простой переход, и для тех, кто интегрирован с Tanzu, предложения Tanzu на платформе IaaS идеально подходят. Клиенты, инвестирующие в Kubernetes, имеют варианты Служба Azure Kubernetes и Azure Red Hat OpenShift. Эта платформа принятия решений предназначена для упрощения выбора путем связывания требований клиентов с лучшими решениями Azure.
Корпорация Майкрософт сотрудничает с многочисленными партнерами, включая партнеров в следующих областях:
- Ведущие партнеры экосистемы Java, такие как Oracle, Broadcom, Red Hat, IBM и OpenAI.
- Ключевые базы данных и организации инструментов, такие как MySQL, PostgreSQL, MongoDB Labs, DataStax, Redis Labs, Confluent и Elastic.
- Эксперты по наблюдаемости, такие как New Relic, Dynatrace, AppDynamics, Grafana Labs и Datadog.
- Средства разработки, такие как IntelliJ, Maven и Gradle.
Наши объединенные инвестиции в создание более гладкого интерфейса разработчика, обеспечение простой интеграции с основными службами, такими как базы данных, кэши, обмен сообщениями и каталоги, а также предоставление комплексных инструментов для наблюдения. С помощью автоматизации, балансировки нагрузки и автомасштабирования мы стремимся взять на себя бремя управления инфраструктурой от плеч. Эта поддержка позволяет сосредоточиться на создании бизнес-ценности с помощью кода, уверенных в том, что базовые системы являются надежными и масштабируемыми. По этим причинам рекомендуется использовать определенные службы Azure для размещения и запуска типов приложений Java.
Развертывание приложений Java в качестве источника или двоичных файлов
Для приложений Java в Azure, развертываемых непосредственно из исходного кода или в виде скомпилированных двоичных файлов (JAR, WAR или EAR-файлов), развертывание упрощается благодаря комплексным предложениям служб Azure, разработанным специально для этих целей. Присущая переносимость приложений Java означает, что Azure может предоставить широкий спектр служб для сопоставления уникальных стратегий развертывания и операционных потребностей. Эта гибкость гарантирует, что независимо от того, какие особенности вашего приложения Java, есть служба Azure, которая идеально подходит для ваших требований.
Рассмотрим следующие три примера, в которых показано, как Azure обслуживает различные сценарии развертывания приложений Java:
Spring Applications. Для разработчиков, работающих с приложениями Spring, Microsoft Azure сотрудничал с Tanzu by Broadcom, лидером проектов с открытым исходным кодом Spring, чтобы предложить премьер-облачную службу, известную как Azure Spring Apps. Эта совместная работа улучшает возможности разработчиков путем интеграции популярных средств разработки, таких как IntelliJ, VS Code, Maven и Gradle, а также средства автоматизации, такие как Azure DevOps, GitHub Actions и Jenkins. Также поддерживаются такие средства наблюдения, как приложения Аналитика, New Relic, Dynatrace, App Dynamics, Grafana, Log Analytics, Elastic и Splunk. Безопасность является главным приоритетом, при интеграции с Key Vault, обрабатывающей секреты и SSL-сертификаты, проверку подлинности без пароля с помощью управляемых удостоверений и управления доступом на основе ролей Azure (RBAC), обеспечивая безопасный, упрощенный процесс развертывания для приложений Spring в облаке.
Приложения Java в JBoss EAP. Аналогичным образом, для приложений Java с помощью JBoss EAP есть специализированный интерфейс благодаря совместной работе между командой Microsoft Azure и командами Red Hat JBoss EAP. Это партнерство привело к расширенной поддержке службы приложение Azure, предлагая широкий набор функций, предназначенных для приложений JBoss EAP. Эта поддержка позволяет использовать объединенный опыт Microsoft и Red Hat, обеспечивая плавное, безопасное и эффективное выполнение приложений Java в Azure.
Корпоративные приложения Java в WebLogic. Традиционные корпоративные приложения Java, которые работают в Oracle WebLogic, также имеют выделенный путь к Azure. Совместная работа между Microsoft Azure и командами Oracle WebLogic проложила путь к оптимизированному развертыванию в Azure Виртуальные машины. Это партнерство распространяется на интеграцию с основными функциями IaaS, такими как виртуальные машины, хранилище, сеть и подсистемы балансировки нагрузки, обеспечивая надежную основу для корпоративных приложений Java в Azure. Эти согласованные усилия обеспечивают преимущества приложений как от надежности WebLogic, так и от масштабируемости и гибкости инфраструктуры Azure.
В этих сценариях подчеркивается преданность Azure для предоставления гибкой, безопасной и эффективной среды развертывания для приложений Java, обслуживающих различные платформы и архитектуры. Azure также предоставляет специализированные службы для других приложений Java, таких как те, которые работают в Tomcat или WebSphere, обеспечивая наличие службы Azure, подходящей для каждого типа приложения Java.
Разработчики и операторы получают плавное и продуктивное облачное развертывание с помощью этих специализированных служб Azure, автоматизации и защиты приложений Java с легкостью. Однако при выборе альтернативных вариантов развертывания может потребоваться выполнить сборку и обслуживание этих основных возможностей разработчика и оператора самостоятельно.
На следующей схеме показаны рекомендуемые службы Azure для каждого типа приложения Java, развернутого в качестве источника или двоичных файлов:
Чтобы узнать больше о службах, на которые ссылается эта схема, используйте ссылки в следующей таблице:
| Service | Краткое руководство по приложениям Java— развернуто как источник или двоичные файлы |
|---|---|
| Azure Spring Apps | Развертывание приложения Spring |
| Служба приложений | Развертывание приложения Java в Tomcat Развертывание приложения Java в JBoss EAP |
| Функции Azure | Развертывание приложения-функции Java |
| Виртуальные машины Azure | Oracle WebLogic Server в Azure Виртуальные машины Семейство IBM WebSphere в Azure Виртуальные машины |
Развертывание приложений Java в качестве контейнеров
Когда речь идет о развертывании приложений Java, контейнеризация представляет собой передовый подход, который повышает автоматизацию при создании контейнеров, управлении и управлении ими на разных предприятиях. Задача заключается в безопасном и надежном создании контейнеров, что является важным шагом для быстрого предоставления высококачественных контейнерных программных приложений. Этот процесс может начинаться с нуля или использовать существующие системы контейнеров, интегрируя средства, которые компилируют и хранят код и двоичные файлы для упрощения обновлений и управления контейнерами. Такая интеграция важна для адаптации к конвейерам непрерывной интеграции и непрерывного развертывания (CI/CD), предлагая гибкий метод развертывания для приложений Java в форме контейнера.
Службы Azure выделяются не только упрощением доставки контейнерных приложений, но и предоставление четких путей для развертывания из источников или двоичных файлов. Этот двойной подход сводит к минимуму влияние на разработчиков и снижает нагрузку для операторов инфраструктуры или платформы. Учитывая переносимость Java, широкий выбор служб контейнеров Azure гарантирует, что вы найдете идеальное соответствие стратегии развертывания и потребностей.
Рассмотрим следующие два примера, в которых показано, как Azure обслуживает контейнерные сценарии развертывания приложений Java:
Spring Applications. Azure Spring Apps — отличный выбор для контейнерных приложений Spring. Он поддерживает несколько типов развертывания, включая исходные, двоичные файлы или образы контейнеров. Эта гибкость позволяет легко переключаться между методами развертывания. Вы можете начать с контейнеров, но позже решите развернуть в качестве источников или двоичных файлов. Этот вариант выгоден, так как он обходит необходимость в постоянном строительстве и обслуживании контейнеров, которые могут быть громоздкими, повторяющимися и временными.
Приложения Java в Tomcat. служба приложение Azure подходит для контейнеризации приложений Java, предназначенных для запуска в Tomcat. Он содержит различные типы развертывания, такие как двоичные файлы или образы контейнеров. Как и Azure Spring Apps, эта служба обеспечивает гибкость в переключение между стратегиями развертывания. Вы можете начать развертывание контейнера и поддерживать возможность последующего перехода на развертывание двоичных файлов (WAR и JAR). Эта гибкость гарантирует, что вы можете выбрать наиболее эффективный метод развертывания для конкретного сценария, упрощая процесс разработки и развертывания.
В этих примерах подчеркивается приверженность Azure обеспечению универсальных, эффективных и понятных для разработчиков сред для развертывания приложений Java, будь то с помощью традиционных методов или современной контейнеризации.
На следующей схеме показаны рекомендуемые службы Azure для каждого типа приложения Java, развернутого как контейнеры:
Чтобы узнать больше о службах, на которые ссылается эта схема, используйте ссылки в следующей таблице:
Итоги
При навигации по развертыванию приложений Java в Azure чемпионы подход A+B предлагают спектр служб, адаптированных для удовлетворения потребностей каждого приложения. Совместная работа Корпорации Майкрософт с лидерами экосистем Java привела к набору служб Azure, каждый из которых рекомендуется для определенных типов приложений Java, развернутых как источник, двоичные файлы или контейнеры, упрощая процесс развертывания и обеспечивая оптимальную производительность. Этот акцент на сопоставлении стратегий развертывания с наиболее подходящими службами Azure подчеркивает приверженность Корпорации Майкрософт к обеспечению гибкости выбора подходящих инструментов для задания. Присущая переносимость приложений Java является ключевым преимуществом, что позволяет легко переходить между локальными системами и различными поставщиками облачных служб для повышения эффективности работы и гибкости. Выступая за этот более широкий, более инклюзивный процесс выбора, корпорация Майкрософт не только упрощает облачное путешествие для приложений Java, но и повышает масштабируемость, безопасность, наблюдаемость и экономичность. В конечном счете, руководство Майкрософт позволяет разработчикам и предприятиям использовать экосистему Azure, обеспечивая, чтобы каждое приложение Java процветало в облачной среде, лучше всего подходит для своих потребностей.
Следующий шаг
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по