Migrasikan aplikasi Java ke Azure

Artikel ini memberikan gambaran umum tentang strategi yang direkomendasikan untuk memigrasikan aplikasi Java ke Azure.

Panduan migrasi ini dirancang untuk mencakup Java mainstream pada skenario Azure, dan untuk memberikan saran serta pertimbangan pada perencanaan tingkat tinggi. Jika Anda ingin membahas skenario migrasi aplikasi Java tertentu dengan tim Microsoft Java di Azure, isi kuesioner berikut, dan perwakilan akan menghubungi Anda.

Mengidentifikasi jenis aplikasi

Sebelum memilih tujuan cloud untuk aplikasi Java, Anda harus mengidentifikasi jenis aplikasinya. Sebagian besar aplikasi Java adalah salah satu dari jenis berikut:

• Aplikasi spring:
  • Aplikasi Spring Boot/JAR
  • Aplikasi spring yang menggunakan modul middleware Spring Cloud
• Aplikasi Java EE
• Aplikasi web
• Pekerjaan Batch/terjadwal

Jenis-jenis tersebut dijelaskan di bagian berikut.

Aplikasi Spring Boot/JAR

Banyak aplikasi yang lebih baru dipanggil langsung dari baris perintah. Aplikasi ini masih menangani permintaan web, tetapi alih-alih mengandalkan server aplikasi untuk menyediakan penanganan permintaan HTTP, mereka menggabungkan komunikasi HTTP dan semua dependensi lainnya secara langsung ke dalam paket aplikasi. Aplikasi tersebut berkali-kali dibangun dengan kerangka kerja seperti Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x, dan lainnya.

Aplikasi ini dikemas ke dalam arsip dengan ekstensi .jar (file JAR).

Aplikasi spring yang menggunakan modul middleware Spring Cloud

Gaya arsitektur layanan mikro adalah pendekatan untuk mengembangkan satu aplikasi sebagai serangkaian layanan kecil. Setiap layanan berjalan dalam prosesnya sendiri dan berkomunikasi dengan menggunakan mekanisme ringan, seringkali API sumber daya HTTP. Layanan ini dibangun di sekitar kemampuan bisnis dan dapat disebarkan secara independen oleh mesin penyebaran otomatis sepenuhnya. Ada minimum manajemen terpusat dari layanan ini, yang mungkin ditulis dalam bahasa pemrograman yang berbeda dan menggunakan teknologi penyimpanan data yang berbeda. Layanan tersebut umumnya dibangun dengan kerangka kerja seperti Spring Cloud.

Layanan ini dikemas ke dalam beberapa aplikasi dengan ekstensi .jar (file JAR).

Aplikasi Java EE

Aplikasi Java EE (juga disebut sebagai aplikasi J2EE atau, baru-baru ini, aplikasi EE Jakarta) dapat berisi beberapa, semua, atau tidak ada elemen aplikasi web. Aplikasi ini juga dapat berisi dan mengonsumsi lebih banyak komponen seperti yang didefinisikan oleh spesifikasi EE Jakarta.

Aplikasi Java EE dapat dikemas sebagai arsip dengan ekstensi .ear (file EAR) atau sebagai arsip dengan ekstensi .war (file WAR).

Aplikasi Java EE harus disebarkan ke server aplikasi yang mematuhi Java EE (seperti Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara, dan lainnya).

Aplikasi yang hanya mengandalkan fitur yang disediakan oleh spesifikasi Java EE (yaitu, aplikasi app-server-independent) dapat dimigrasikan dari satu server aplikasi yang sesuai ke server aplikasi lainnya. Jika aplikasi Anda bergantung pada server aplikasi tertentu (app-server-dependent), Anda mungkin perlu memilih tujuan layanan Azure yang memungkinkan Anda menghosting server aplikasi tersebut.

Aplikasi web

Aplikasi web berjalan di dalam kontainer Servlet. Beberapa aplikasi ini menggunakan API servlet secara langsung, sementara banyak yang menggunakan kerangka kerja lain yang merangkum API servlet, seperti Apache Struts, Spring MVC, JavaServer Faces (JSF), dan lainnya.

Aplikasi web dikemas ke dalam arsip dengan ekstensi .war (file WAR).

Pekerjaan Batch/terjadwal

Beberapa aplikasi dimaksudkan untuk berjalan sebentar, mengeksekusi beban kerja tertentu, kemudian keluar daripada menunggu permintaan atau input pengguna. Ada kalanya, pekerjaan tersebut perlu dijalankan sekali atau pada interval yang dijadwalkan secara teratur. Di tempat, pekerjaan seperti itu sering dipanggil dari crontab server.

Aplikasi ini dikemas ke dalam arsip dengan ekstensi .jar (file JAR).

Memilih tujuan layanan Azure target

Bagian berikut menunjukkan kepada Anda tujuan layanan mana yang memenuhi persyaratan aplikasi Anda, dan tanggung jawab apa yang mereka libatkan.

Kisi opsi hosting

Gunakan kisi berikut untuk mengidentifikasi tujuan potensial untuk jenis aplikasi Anda. Seperti yang Anda lihat, Azure Kubernetes Service (AKS) dan Azure Virtual Machines mendukung semua jenis aplikasi, tetapi mereka mengharuskan tim Anda untuk mengambil lebih banyak tanggung jawab, seperti yang ditunjukkan di bagian berikutnya.

Kisi tanggung jawab berkelanjutan

Gunakan kisi berikut untuk memahami tanggung jawab setiap tempat tujuan di tim Anda setelah migrasi.

Tugas yang ditunjukkan dengan Azure dikelola sepenuhnya atau sebagian besar oleh Azure. Tim Anda bertanggung jawab secara berkelanjutan untuk tugas yang ditunjukkan dengan 👉. Sebaiknya terapkan proses yang mumpuni dan sangat otomatis untuk memenuhi semua tanggung jawab tersebut.

Tujuan → Tugas ↓	App Layanan	Azure Kontainer Aplikasi	AKS	Virtual Mesin
Memperbarui pustaka (termasuk remediasi kerentanan)	👉	👉	👉	👉
Memperbarui server aplikasi (termasuk remediasi kerentanan)	Azure	👉	👉	👉
Memperbarui Java Runtime (termasuk remediasi kerentanan)	Azure	👉	👉	👉
Memicu pembaruan Kubernetes (dilakukan oleh Azure dengan pemicu manual)	T/A	Azure	👉	T/A
Pemulihan Bencana	Azure	👉	👉	Azure
Merekonsiliasi perubahan API Kubernetes yang tidak kompatibel dengan versi lama	T/A	👉	👉	T/A
Memperbarui gambar dasar kontainer (termasuk remediasi kerentanan)	T/A	👉	👉	T/A
Memperbarui sistem operasi (termasuk remediasi kerentanan)	Azure	Azure	Azure1	👉
Mendeteksi dan menghidupkan ulang instans yang gagal	Azure	Azure	Azure	👉
Menerapkan pengurasan dan rolling restart untuk pembaruan	Azure	Azure	Azure	👉
Pengelolaan infrastruktur	Azure	👉	👉	👉
Manajemen pemantauan dan peringatan	👉	👉	👉	👉

¹ Beberapa pembaruan keamanan mungkin memerlukan boot ulang simpul, yang tidak dilakukan secara otomatis. Untuk informasi selengkapnya, lihat Menerapkan pembaruan keamanan dan kernel pada simpul Linux di Azure Kubernetes Service (AKS).

Jika Anda menyebarkan kontainer servlet (seperti Spring Boot) sebagai bagian dari aplikasi Anda, Anda harus menganggapnya sebagai pustaka dan, dengan demikian, itu selalu menjadi tanggung jawab Anda.

Memastikan konektivitas lokal

Jika aplikasi Anda perlu mengakses salah satu layanan lokal Anda, Anda harus menyediakan salah satu layanan konektivitas Azure. Untuk informasi selengkapnya, lihat Menyambungkan jaringan lokal ke Azure. Atau, Anda harus memfaktor ulang aplikasi untuk menggunakan API yang tersedia untuk umum yang diekspos sumber daya lokal Anda.

Anda harus menyelesaikan upaya ini sebelum memulai migrasi apa pun.

Buatlah inventaris tentang kapasitas dan penggunaan sumber daya saat ini

Dokumentasikan perangkat keras dari server produksi saat ini beserta jumlah permintaan rata-rata dan permintaan tertinggi serta penggunaan sumber daya. Anda memerlukan informasi ini untuk menyediakan sumber daya di tujuan layanan.

Panduan migrasi

Gunakan kisi berikut untuk menemukan panduan migrasi berdasarkan jenis aplikasi dan tujuan layanan Azure yang ditargetkan.

Aplikasi Java

Gunakan baris di bawah ini untuk menemukan jenis aplikasi Java Anda dan kolom untuk menemukan tujuan layanan Azure yang akan menghosting aplikasi Anda.

Jika Anda ingin memigrasikan aplikasi JBoss EAP ke Tomcat di App Service, pertama konversi aplikasi Java EE ke Java Web Apps (servlet) yang berjalan di Tomcat, kemudian ikuti panduan yang ditunjukkan di bawah ini.

Aplikasi Java EE

Gunakan baris di bawah ini untuk menemukan jenis aplikasi Java EE Anda yang berjalan di server aplikasi tertentu. Gunakan kolom untuk menemukan tujuan layanan Azure yang akan menghosting aplikasi Anda.

Lihat juga

• Alasan untuk pindah ke Java 11 dan seterusnya
• Transisi dari Java 8 ke Java 11
• Transisi dari Java 7 ke Java 8