Java 애플리케이션에 적합한 Azure 서비스 선택
이 문서에서는 다양한 Java 기술 및 아키텍처에 대한 Azure의 지원을 강조하면서 Java 애플리케이션 배포에 Azure 서비스를 사용하는 방법을 안내합니다. 다양한 제어 및 단순성 수준에 맞게 조정된 "리프트 앤 시프트", 컨테이너화 및 PaaS(Platform-as-a-Service)와 같은 배포 방법을 간략하게 설명합니다.
이 문서에서는 A+B 사고방식을 옹호하며 고정 A 또는 B 선택에 대한 애플리케이션 요구 사항에 따라 서비스를 선택하도록 조언합니다. 유연한 접근 방식을 위해 사용 사례, 비즈니스 목표, 보안 및 예산을 고려하는 것이 좋습니다. 이 문서에서는 개발자 환경을 향상시키기 위해 Java 에코시스템 리더와 Microsoft의 파트너십을 강조하고 원본, 이진 파일 또는 컨테이너 등 Java 애플리케이션을 배포하기 위한 Azure 서비스를 권장합니다. 이 미묘한 접근 방식을 통해 Java 애플리케이션에 배포 전략에 가장 적합한 Azure 서비스를 제공하고 효율성, 확장성 및 비용 효율성을 극대화하려는 Microsoft의 노력에 따라 혁신에 집중할 수 있습니다.
안심하고 쉽게 Java 애플리케이션 배포
Java 에코시스템에는 Java SE, Jakarta EE(Java EE 및 J2EE 후속 기능), Spring, 수많은 애플리케이션 서버 및 기타 프레임워크와 같은 다양한 기술이 포함되어 있습니다. 앱을 빌드하고, 프레임워크를 사용하고, 애플리케이션 서버를 실행하는 등 Java로 수행하는 모든 작업은 다양한 선택 사항으로 워크로드를 Azure 지원. 마찬가지로 VM 또는 컨테이너에서 실행되는 모놀리식 애플리케이션부터 완전 관리형 서비스에서 실행되는 클라우드 네이티브 마이크로 서비스 기반 애플리케이션에 이르기까지 모든 애플리케이션 아키텍처를 Azure 지원.
Azure는 다양한 수준의 제어 및 단순도에 맞게 조정된 클라우드에서 Java 애플리케이션을 실행하기 위한 다음 세 가지 기본 방법을 제공합니다.
"리프트 앤 시프트" 접근 방식을 사용하면 기존 애플리케이션을 Azure Virtual Machines로 직접 최소 변경 마이그레이션할 수 있습니다.
컨테이너화는 AKS(Azure Kubernetes Service) 및 Azure Red Hat OpenShift가 컨테이너화된 앱을 오케스트레이션하기 위한 기본 플랫폼인 유연성을 제공합니다.
PaaS(Platform-as-a-Service)는 가장 경제적인 총 소유 비용과 함께 최적의 개발자 생산성 및 운영 관리 효율성을 제공하는 용이성과 효율성의 정점을 나타냅니다.
Java 애플리케이션 개발 단계에 관계없이 Azure는 요구 사항을 충족하는 호환되는 클라우드 솔루션을 제공합니다. Java 애플리케이션 배포에서 이러한 제품에 대한 자세한 내용은 안심하고 쉽게 확인할 수 있습니다.
Java 애플리케이션에 대한 완전한 이식성: 어디서나 원활하게 배포
Java 애플리케이션에 대해 어떤 Azure 서비스를 선택하든 애플리케이션의 유연성이 보장됩니다. Java 코드와 컴파일된 출력이 있으므로 로컬 개발 머신, 빌드 서버, 온-프레미스 환경 또는 선택한 클라우드 플랫폼 등 원하는 위치에 애플리케이션을 자유롭게 배포할 수 있습니다. 애플리케이션의 이식성은 사용자의 손에 있습니다.
물론, 선택의 여지가 너무 많을 때, 당신은 딜레마에 직면.
딜레마 – Java 애플리케이션에 서비스 A 또는 B 사용
Azure의 제품을 탐색하는 경우 Java 애플리케이션을 실행하는 데 가장 적합한 Azure 서비스를 선택하는 딜레마가 발생할 수 있습니다. 이 선택은 리소스 계획, 예산, 프로젝트 타임라인 및 궁극적으로 애플리케이션의 출시 시간에 영향을 주기 때문에 매우 중요합니다. 이 결정은 초기 배포 비용뿐만 아니라 지속적인 기본 부담 비용에도 영향을 줍니다.
과거에 조직은 소프트웨어 애플리케이션에 대한 두 플랫폼, 기술 또는 경쟁 솔루션 중에서 선택해야 하는 경우가 종종 있습니다. 예를 들어 조직에서는 Java Enterprise 애플리케이션용 WebLogic 또는 WebSphere, 컨테이너 관리를 위한 Docker Swarm 또는 Kubernetes 또는 배포를 위한 VM(가상 머신) 중에서 결정해야 했습니다. 이 의사 결정 프로세스는 "A 또는 B 사고 방식"이라고 하며, 두 버전의 웹 페이지 또는 앱을 서로 비교하여 더 나은 성능을 확인하는 방법인 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, ACA(Azure Container Apps), Azure Kubernetes Service 또는 Virtual Machines에 관계없이 A+B 사고방식은 애플리케이션 호스팅을 위한 Azure 서비스 배열을 평가하고 선택할 수 있는 위도를 부여합니다. 이 철학은 언어와 프레임워크 경계를 초월하여 보편적으로 적용할 수 있습니다. 여기서는 Java 애플리케이션이 중심이지만 A+B 사고방식은 모든 프로그래밍 언어로 개발된 애플리케이션에 똑같이 관련성이 있고 유용합니다.
A+B 사고방식을 수용하면 미리 결정된 단일 서비스에만 국한되지 않습니다. 대신 애플리케이션의 고유한 요구에 가장 적합한 방식으로 서비스를 결합할 수 있습니다. 이 접근 방식은 유연성과 확장성을 향상시킬 뿐만 아니라 비용 및 운영 효율성을 최적화합니다. 이 방법을 사용하면 작업 중인 클라우드 환경만큼 기술 전략이 동적이고 적응할 수 있습니다.
서비스 A 또는 B를 생각할 필요가 없는 이유
애플리케이션에 적합한 클라우드 서비스를 선택하는 것은 특히 Azure에서 클라우드에서 제공하는 옵션의 유연성과 폭 덕분에 서비스 A 또는 서비스 B 간에 이진 결정이 될 필요는 없습니다. 다음 섹션에서는 기존의 "하나 또는 다른" 선택을 고수할 필요가 없는 이유와 보다 유동적인 접근 방식을 채택하면 작업에 도움이 되는 방법을 설명합니다.
오래된 습관에서 새로운 유연성으로
일반적으로 IT 시스템을 배포하는 데는 긴 설치 시간과 함께 하드웨어 및 소프트웨어에 대한 상당한 선행 투자가 포함되었습니다. 이 환경에서는 하나의 플랫폼을 신중하게 선택하고 주변의 모든 플랫폼을 최적화하여 비용과 리소스를 절약하는 것이 논리적이었습니다. 그러나 Azure를 비롯한 클라우드 환경은 주문형 및 탄력적 특성으로 패러다임 전환을 도입합니다. 사용량에 대해서만 비용을 지불하고, 초기 자본 지출의 부담 없이 요구 사항에 맞게 리소스를 조정하는 것이 간단합니다.
클라우드로의 전환
특히 클라우드 및 Azure로 이동하면 인프라 및 플랫폼 책임이 관리되는 방식이 크게 변경됩니다. 다음 다이어그램에서 볼 수 있듯이 이전에 조직에서 맡은 무거운 리프팅의 대부분은 이제 Microsoft로 이동합니다. 이 변경은 작업을 간소화하고 애플리케이션을 관리하는 데 필요한 노력을 줄입니다. 여러 플랫폼을 관리하는 제약 조건에 구속되지 않으므로 추가 비용과 복잡성에 대해 걱정하지 않고 각 작업에 가장 적합한 도구를 선택할 수 있습니다.
다음 다이어그램은 고객 및 클라우드 공급자 간의 공유 책임 모델을 보여 주는 다이어그램입니다.
각 필요에 가장 적합한 선택
이 새로운 클라우드 중심 환경에서 의사 결정 프로세스는 모든 요구 사항을 미리 결정된 하나의 서비스에 맞추기보다는 올바른 작업에 적합한 도구를 선택하는 데 더 많은 역할을 합니다. Azure Kubernetes Service와 Spring Boot 애플리케이션용 Azure Spring Apps 또는 다른 서비스 집합 중에서 선택하든, 포커스는 각 특정 애플리케이션의 요구 사항을 가장 잘 충족하는 항목으로 이동합니다.
마이크로 서비스의 증가
마이크로 서비스의 채택은 이 유연한 접근 방식을 더욱 지원합니다. 기본적으로 마이크로 서비스는 각 서비스에 가장 적합한 기술을 사용하도록 장려하여 자연스럽게 A+B 사고방식에 부합하는 기술 다양성을 촉진합니다. 이 방법은 다양한 서비스의 장점을 사용하여 보다 강력하고 효율적이며 확장 가능한 애플리케이션 아키텍처를 빌드하는 방법을 설명합니다.
A+B 수용의 이점
A+B 사고방식을 채택하면 몇 가지 주요 이점이 있습니다. 이를 통해 민첩성과 유연성이 향상되어 작업의 각 측면에 가장 적합한 도구와 서비스를 선택할 수 있습니다. 이 접근 방식은 리소스 및 비용 효율성을 높일 뿐만 아니라 제품 출시 시간을 단축합니다. 궁극적으로 이 접근 방식은 비즈니스 요구 사항 및 목표에 보다 긴밀하게 기술 선택을 조정하여 운영 우수성을 촉진합니다.
요약하자면, 클라우드 및 Azure는 애플리케이션 배포 및 관리에 대한 새로운 사고 방식을 제공합니다. 제한적인 A 또는 B 선택에서 벗어나 A+B 사고방식을 수용함으로써 애플리케이션의 특정 요구 사항에 더 부합하는 결정을 내릴 수 있으므로 효율성, 민첩성 및 비용 절감이 향상됩니다.
A+B 사고방식으로 전환하기 위한 실용적인 지침
다음 목록에서는 A+B 사고방식으로 전환하고 계속하기 위한 지침으로 사용할 수 있는 몇 가지 주요 원칙을 열거합니다.
사용 사례에서 솔루션으로 이동합니다. 종종 많은 소프트웨어 팀이 기술을 먼저 결정한 다음 사용 사례 및 디자인에 강제로 맞도록 시도합니다. 대부분의 경우 이 방법은 비용, 개발 시간, 리소스 및 운영 비용 측면에서 상당한 오버헤드를 발생합니다. 솔루션에 뛰어들기 전에 기능적 및 비기능적 사용 사례 및 요구 사항을 명확하게 이해할 수 있습니다.
비즈니스 목표, 비즈니스 특성 및 경쟁의 특성 및 프로덕션에 새 기능을 배포해야 하는 빈도를 이해합니다. 항상 비즈니스 목표와 목표를 충족하도록 솔루션을 디자인해야 합니다.
보안 및 규정 준수 요구 사항을 이해합니다. 모든 것이 인터넷을 통해 액세스되는 클라우드 시대에 보안은 매우 중요하며 협상할 수 없습니다. 또한 서비스하는 업계에 따라 애플리케이션이 특정 규정 준수 요구 사항을 충족해야 할 수 있습니다. 고급 보안 공격을 방지하고 규정 준수 요구 사항을 충족하기 위해 솔루션을 디자인해야 합니다.
예산 및 타임라인 이해합니다. 초기 개발, 진행 중인 작업 및 향후 릴리스에 대한 예산을 명확하게 이해하세요. 또한 타임라인 이해합니다. 추가 비용과 부정적인 비즈니스 영향 측면에서 지연된 프로젝트의 비용은 종종 과소 평가됩니다. 예산과 타임라인 모두 충족하도록 솔루션을 디자인합니다.
해당하는 경우 클라우드 네이티브를 생각해 보세요. ‘클라우드 네이티브 아키텍처 및 기술은 클라우드에서 빌드된 워크로드를 디자인, 생성 및 운영하는 접근 방식으로, 클라우드 컴퓨팅 모델을 최대한 활용합니다.’ 클라우드 네이티브를 사용하면 더 빠른 속도로 애플리케이션을 빌드하고 프로덕션에 배포할 수 있습니다. 또한 클라우드는 탄력성, 글로벌 규모, 고급 분석, AI 및 ML(기계 학습) 기능 등 온-프레미스에서 불가능할 수 있는 기능을 제공합니다. 가능한 한 클라우드 네이티브 기술을 기반으로 솔루션을 디자인합니다.
DevOps 문화를 생각해 보세요. DevOps는 도구나 프로세스뿐만 아니라 개발과 운영 간의 협업을 촉진하여 더 빠르고 안정적인 소프트웨어 배달을 제공하는 소프트웨어 개발 사례입니다. 일반적으로 문화권이라고 하는 DevOps는 사람, 프로세스 및 기술을 연결하여 지속적인 가치를 제공합니다.
비즈니스 및 비기능적 요구 사항을 충족하는 솔루션을 선택합니다.
- 구현 속도가 가장 빠릅니다.
- 기술, 빌드, 배포 및 운영과 관련된 비용 측면에서 비용 효율적입니다.
- 조작이 쉽습니다.
- 자동화와 완벽하게 호환됩니다.
- 디자인에 의한 DevOps 지원.
이러한 원칙은 솔루션을 미리 결정된 플랫폼에 강제로 맞추는 대신 비즈니스 목표를 충족하는 솔루션을 구축하는 데 초점을 맞추는 데 도움이 됩니다.
예외
다른 항목과 마찬가지로 A+B에는 예외가 있습니다. 다음 목록은 완전하지는 않지만 발생할 수 있는 몇 가지 예외에 대한 방향 지침을 제공합니다.
엔터프라이즈 전략. 예를 들어 일부 엔터프라이즈에서는 여러 프로그래밍 언어가 실행 중일 수 있고 모든 애플리케이션을 통합된 방식으로 빌드하고 배포하려고 하기 때문에 컨테이너를 엔터프라이즈 전체에서 채택하여 애플리케이션을 빌드하고 배포합니다.
너무 멀리 실행 줄 아래로. A+B 분석을 진행하기 전에 솔루션을 선택했을 수 있습니다. 솔루션 실행에 이미 깊이 있는 경우 계속 진행하지만 다음 애플리케이션의 경우 A+B 사고방식의 원칙을 사용하여 사용 사례에 적합한 솔루션을 선택합니다.
대규모 데이터 센터 마이그레이션. 클라우드로의 여정을 가속화하기 위해 기업은 일반적으로 Azure Migrate와 같은 도구를 사용하여 서버(애플리케이션 호스팅)를 Azure로 대량으로 마이그레이션하는 "리프트 앤 시프트"라는 전략을 사용합니다. 일부는 이 방법을 사용하여 데이터 센터를 Azure로 마이그레이션하고 효율적이고 비용 효율적인 방식으로 종료합니다. 이 시나리오에서는 A+B 사고 방식을 사용하여 Azure로 마이그레이션한 후 애플리케이션을 현대화하는 것이 좋습니다.
주요 고려 사항
Azure에서 애플리케이션에 적합한 대상을 선택하는 데 사용할 수 있는 사고 프레임워크와 원칙을 제공했습니다. 그것은 모두에 맞는 하나의 크기가 아닙니다. A 또는 B가 아니라 A + B입니다.
다음 다이어그램에서는 모든 애플리케이션에 대한 Azure 서비스를 선택할 때의 주요 고려 사항을 요약합니다.
Java 애플리케이션에 적합한 Azure 서비스를 선택하는 방법
Azure의 Java 애플리케이션에 대한 다양한 기술 옵션 중에 선택 프로세스를 간소화하기 위해 개발자, 고객 및 시스템 통합자가 최적의 Azure 서비스에 연결할 수 있도록 간단한 의사 결정 트리를 만들었습니다.
비기능적 요구 사항을 고려하기 위한 실질적인 지침 외에도 기술적인 관점에서 고려해야 할 초기 질문은 인프라에 대한 제어가 필요한지 여부입니다. 그렇지 않은 경우 관리되는 서비스가 가장 권장되는 가장 좋은 경로입니다. 애플리케이션의 특성(Spring 또는 App Server 기반)은 Spring 애플리케이션이 Azure Spring Apps에 부합하는 반면 Azure 앱 Service는 Tomcat 또는 JBoss EAP 애플리케이션에 적합하다는 결정을 추가로 안내합니다.
인프라 제어가 필요한 경우 다중 클라우드 기술 기본 설정에 따라 선택할 수 있습니다. Azure Virtual Machines는 간단한 전환을 제공하며 Tanzu와 통합된 경우 IaaS의 Tanzu 마켓플레이스 제품이 이상적입니다. Kubernetes에 투자한 고객에게는 Azure Kubernetes Service 및 Azure Red Hat OpenShift 옵션이 있습니다. 이 의사 결정 프레임워크는 고객 요구 사항을 Azure의 가장 적합한 솔루션과 페어링하여 선택을 간소화하도록 설계되었습니다.
Microsoft는 다음 영역의 파트너를 포함하여 다양한 파트너와 공동 작업합니다.
- Oracle, Broadcom, Red Hat, IBM 및 OpenAI와 같은 주요 Java 에코시스템 파트너.
- MySQL, PostgreSQL, MongoDB Labs, DataStax, Redis Labs, Confluent 및 Elastic과 같은 주요 데이터베이스 및 도구 조직
- New Relic, Dynatrace, AppDynamics, Grafana Labs 및 Datadog와 같은 관찰 전문가
- 개발 도구(예: IntelliJ, Maven 및 Gradle).
당사의 결합된 투자는 보다 원활한 개발자 환경을 만들고, 데이터베이스, 캐시, 메시징 및 디렉터리와 같은 필수 서비스와 원활하게 통합하고, 관찰을 위한 포괄적인 도구를 제공하는 데 사용됩니다. 자동화, 부하 분산 및 자동 크기 조정을 통해 인프라 관리의 부담을 덜어주려고 합니다. 이 지원을 통해 기본 시스템이 강력하고 확장성이 있다는 사실을 확신하고 코드를 통해 비즈니스 가치를 창출하는 데 집중할 수 있습니다. 이러한 이유로 특정 Azure 서비스를 사용하여 Java 애플리케이션 유형을 호스트하고 실행하는 것이 좋습니다.
Java 애플리케이션을 원본 또는 이진 파일로 배포
소스 코드에서 직접 배포하든 컴파일된 이진 파일(JAR, WAR 또는 EAR 파일)로 배포하든 Azure의 Java 애플리케이션의 경우 이러한 용도로 특별히 설계된 Azure의 포괄적인 서비스 제공 덕분에 배포가 간소화됩니다. Java 애플리케이션의 고유 이식성은 Azure가 고유한 배포 전략 및 운영 요구 사항에 맞게 다양한 서비스를 제공할 수 있음을 의미합니다. 이러한 유연성을 통해 Java 애플리케이션의 세부 사항에 관계없이 요구 사항에 완벽하게 맞는 Azure 서비스가 보장됩니다.
Azure가 다양한 Java 애플리케이션 배포 시나리오를 충족하는 방법을 보여 주는 다음 세 가지 예제를 고려합니다.
Spring 애플리케이션. Spring 애플리케이션을 사용하는 개발자를 위해 Microsoft Azure는 Spring 오픈 소스 프로젝트의 선두 주인 Tanzu by Broadcom과 협력하여 Azure Spring Apps라는 최고의 클라우드 서비스를 제공했습니다. 이 협업은 Azure DevOps, GitHub Actions 및 Jenkins와 같은 자동화 도구와 함께 IntelliJ, VS Code, Maven 및 Gradle과 같은 인기 있는 개발 도구를 통합하여 개발자 환경을 향상시킵니다. Application Insights, New Relic, Dynatrace, App Dynamics, Grafana, Log Analytics, Elastic 및 Splunk와 같은 관찰 도구도 지원됩니다. 보안은 Key Vault가 비밀 및 TLS/SSL 인증서를 처리하는 통합, 관리 ID를 통한 지원 서비스를 통한 "암호 없는" 인증 및 Azure RBAC(역할 기반 액세스 제어)를 통합하여 클라우드의 Spring 앱에 대한 안전하고 간소화된 배포 프로세스를 보장하는 최우선 과제입니다.
JBoss EAP의 Java 애플리케이션 마찬가지로 JBoss EAP를 사용하는 Java 애플리케이션의 경우 Microsoft Azure 팀과 Red Hat JBoss EAP 팀 간의 협업 덕분에 맞춤형 환경이 제공됩니다. 이 파트너 관계를 통해 Azure 앱 Service에 대한 지원이 향상되어 JBoss EAP 애플리케이션용으로 설계된 풍부한 기능 집합을 제공합니다. 이 지원을 통해 Microsoft 및 Red Hat의 결합된 전문 지식을 사용하여 Java 애플리케이션이 Azure에서 원활하고 안전하며 효율적으로 실행되도록 할 수 있습니다.
WebLogic의 엔터프라이즈 Java 애플리케이션. Oracle WebLogic에서 실행되는 기존 엔터프라이즈 Java 애플리케이션에도 Azure 전용 경로가 있습니다. Microsoft Azure와 Oracle WebLogic 팀 간의 협업은 Azure Virtual Machines에서 최적화된 배포를 위한 길을 열었습니다. 이 파트너십은 가상 머신, 스토리지, 네트워킹 및 부하 분산 장치와 같은 기본 IaaS 기능과 통합하여 Azure에서 엔터프라이즈 Java 애플리케이션을 위한 견고한 기반을 제공합니다. 이러한 조정된 노력을 통해 애플리케이션은 WebLogic의 견고성과 Azure 인프라의 확장성 및 유연성을 모두 활용할 수 있습니다.
이러한 시나리오는 다양한 프레임워크 및 아키텍처에 맞게 Java 애플리케이션에 유연하고 안전하고 효율적인 배포 환경을 제공하기 위한 Azure의 헌신을 강조합니다. 또한 Azure는 Tomcat 또는 WebSphere에서 실행되는 것과 같은 다른 Java 애플리케이션에 대한 특수 서비스를 제공하여 모든 유형의 Java 애플리케이션에 적합한 Azure 서비스가 있는지 확인합니다.
개발자와 운영자는 이러한 맞춤형 Azure 서비스를 사용하여 Java 애플리케이션을 쉽게 자동화하고 보호함으로써 원활하고 생산적인 클라우드 배포 환경을 얻을 수 있습니다. 그러나 대체 배포 옵션을 선택하려면 이러한 필수 개발자 및 운영자 환경의 건물 및 기본 감쇠를 직접 처리해야 할 수 있습니다.
다음 다이어그램에서는 원본 또는 이진 파일로 배포된 모든 Java 애플리케이션 유형에 권장되는 Azure 서비스를 보여 줍니다.
이 다이어그램에서 참조되는 서비스에 대해 자세히 알아보려면 다음 표의 링크를 사용합니다.
Java 애플리케이션을 컨테이너로 배포
Java 애플리케이션 배포와 관련하여 컨테이너화는 기업 전체에서 컨테이너 생성, 관리 및 거버넌스의 자동화를 향상시키는 최첨단 접근 방식을 나타냅니다. 문제는 고품질의 컨테이너화된 소프트웨어 애플리케이션을 신속하게 제공하기 위한 중요한 단계인 컨테이너를 안전하고 안정적으로 구축하는 데 있습니다. 이 프로세스는 처음부터 시작하거나 기존 컨테이너 시스템을 사용하여 코드와 이진 파일을 컴파일하고 저장하는 도구를 통합하여 컨테이너 업데이트 및 관리를 간소화할 수 있습니다. 이러한 통합은 CI/CD(연속 통합/연속 배포) 파이프라인에 맞게 컨테이너 형식의 Java 애플리케이션에 대한 유연한 배포 방법을 제공하는 데 매우 중요합니다.
Azure 서비스는 컨테이너화된 애플리케이션의 배달을 완화할 뿐만 아니라 원본 또는 이진 파일에서 배포하기 위한 명확한 경로를 제공하여 눈에 띄습니다. 이 이중 접근 방식은 개발자에게 미치는 영향을 최소화하고 인프라 또는 플랫폼 운영자의 부하를 줄일 수 있습니다. Java의 고유한 이식성을 고려할 때 Azure의 광범위한 컨테이너 서비스를 통해 배포 전략 및 요구 사항에 완벽하게 부합하는 서비스를 찾을 수 있습니다.
Azure가 컨테이너화된 Java 애플리케이션 배포 시나리오를 충족하는 방법을 보여주는 다음 두 가지 예제를 고려합니다.
Spring 애플리케이션. Azure Spring Apps는 컨테이너화된 Spring 애플리케이션에 적합합니다. 원본, 이진 파일 또는 컨테이너 이미지를 비롯한 여러 배포 유형을 지원합니다. 이러한 유연성을 통해 배포 방법 간에 쉽게 이동할 수 있습니다. 컨테이너로 시작하지만 나중에 원본 또는 이진 파일로 배포하기로 결정할 수 있습니다. 이 옵션은 번거롭고 반복적이며 시간이 많이 소요될 수 있는 컨테이너의 지속적인 건물 및 기본 테넌트의 필요성을 우회하기 때문에 유리합니다.
Tomcat의 Java 애플리케이션. Azure 앱 Service는 Tomcat에서 실행되도록 설계된 Java 애플리케이션을 컨테이너화하는 데 적합합니다. 이진 파일 또는 컨테이너 이미지와 같은 다양한 배포 유형을 수용합니다. Azure Spring Apps와 마찬가지로 이 서비스는 배포 전략을 번갈아 사용할 수 있는 유연성을 제공합니다. 컨테이너 배포로 시작하고 나중에 이진 파일(WAR 및 JAR)으로 전환하는 옵션을 기본 수 있습니다. 이러한 다양성을 통해 특정 시나리오에 가장 효율적인 배포 방법을 선택하여 개발 및 배포 프로세스를 간소화할 수 있습니다.
이러한 예제는 기존 방법이나 최신 컨테이너화를 통해 Java 애플리케이션을 배포하기 위한 다재다능하고 효율적이며 개발자 친화적인 환경을 제공하기 위한 Azure의 노력을 강조합니다.
다음 다이어그램에서는 컨테이너로 배포된 모든 Java 애플리케이션 유형에 권장되는 Azure 서비스를 보여 줍니다.
이 다이어그램에서 참조되는 서비스에 대해 자세히 알아보려면 다음 표의 링크를 사용합니다.
요약
Java 애플리케이션 배포를 탐색할 때 Azure는 미묘한 A+B 접근 방식을 옹호하여 모든 애플리케이션의 요구 사항에 맞게 조정된 다양한 서비스를 제공합니다. Microsoft가 Java 에코시스템 리더와 협업한 결과, 각각 원본, 이진 파일 또는 컨테이너로 배포된 특정 Java 애플리케이션 유형에 권장되는 Azure 서비스 제품군이 배포 프로세스를 간소화하고 최적의 성능을 보장했습니다. 가장 적합한 Azure 서비스와 배포 전략을 일치시키는 데 중점을 두는 것은 작업에 적합한 도구를 유연하게 선택할 수 있도록 하기 위한 Microsoft의 노력을 강조합니다. Java 애플리케이션의 고유 이식성은 주요 이점이며, 온-프레미스 시스템과 다양한 클라우드 공급자 간에 원활한 전환을 통해 운영 효율성과 민첩성을 향상시킬 수 있습니다. 보다 광범위하고 포괄적인 선택 프로세스를 옹호함으로써 Microsoft는 Java 애플리케이션에 대한 클라우드 경험을 간소화할 뿐만 아니라 확장성, 보안, 관찰 가능성 및 비용 효율성을 극대화합니다. 궁극적으로 Microsoft의 지침은 개발자와 기업이 Azure의 에코시스템을 사용할 수 있도록 하여 각 Java 애플리케이션이 요구 사항에 가장 적합한 클라우드 환경에서 번창하도록 합니다.
다음 단계
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기