Merencanakan platform aplikasi modern

  • Artikel

Metodologi Rencana Cloud Adoption Framework membantu membuat rencana adopsi cloud secara keseluruhan untuk memandu program dan tim yang terlibat dalam transformasi digital berbasis cloud Anda. Panduan ini menyediakan templat untuk membuat backlog dan rencana untuk membangun keterampilan yang diperlukan di seluruh tim Anda, semua berdasarkan apa yang berusaha Anda lakukan di cloud.

Penerapan metodologi Rencana berfokus pada lima R rasionalisasi properti digital Anda. Jalur paling umum ke cloud berfokus pada kecepatan, efisiensi, dan pengulangan proses migrasi dan modernisasi. Dari lima R, perencanaan biasanya memprioritaskan opsi hosting ulang dengan dukungan paralel terbatas untuk opsi rancang ulang dan bangun ulang.

Properti digital

Saat merencanakan properti digital, Anda akan berkeinginan untuk mengumpulkan data inventaris dan rasionalisasi properti Anda. Dalam rencana adopsi kontainer, sangat penting bahwa semua aset, misalnya VM, data, dan aplikasi, dikelompokkan berdasarkan beban kerja yang mereka dukung. Setelah pengelompokan dan rasionalisasi dasar selesai, Anda dapat mengevaluasi beban kerja ini untuk menentukan paket dan opsi hosting ulang atau rancang ulang.

Templat rencana adopsi cloud standar bertanggung jawab atas jenis pekerjaan yang diperlukan dalam upaya adopsi cloud tertentu. Tetapi Anda perlu menambahkan tugas ke rencana Anda untuk mengemas beban kerja ke dalam kontainer dan orkestrasi provisi kontainer.

Perhatian

Artikel ini mengasumsikan pembaca sudah mengikuti praktik terbaik yang diuraikan dalam seri artikel mengenai membangun rencana adopsi cloud di Azure DevOps. Jika Anda melacak rencana adopsi cloud di spreadsheet atau alat pelacakan proyek lainnya, bagian berikut masih berlaku, tetapi langkah-langkah yang dapat dilakukan untuk menambahkan data ke rencana Anda perlu disesuaikan.

Peringatan

Menggabungkan strategi platform aplikasi modern ke dalam proses migrasi standar (atau pabrik migrasi) akan memerlukan implementasi tugas yang matang yang terkait dengan merancang arsitektur beban kerja sebelum migrasi. Melanjutkan strategi ini tanpa tugas-tugas tersebut akan menunda upaya migrasi dan dapat menyebabkan keputusan arsitektur yang buruk untuk host kontainer dan beban kerja pendukung yang disebarkan.

Mengidentifikasi beban kerja kandidat

Dalam skenario platform aplikasi modern, pengembalian dalam jangka waktu yang lebih panjang, yang membutuhkan investasi di muka yang lebih besar, lebih diprioritaskan dibandingkan proses migrasi yang lebih efisien. Investasi dengan jangka waktu yang lebih panjang diwakilkan di bagian-bagian tertentu dari rencana sebagai fokus yang ditingkatkan pada memungkinkan inovasi dan merampingkan operasi untuk kelompok beban kerja tertentu.

Untuk mulai menyelaraskan strategi dan rencana, identifikasi beban kerja apa pun yang kemungkinan akan terpengaruh oleh penambahan platform aplikasi modern dalam strategi adopsi cloud Anda. Asumsi tersebut akan divalidasi sebelum menerapkan perubahan teknis apa pun. Untuk membantu mengidentifikasi kandidat potensial, cari kriteria berikut di dalam portofolio beban kerja Anda:

  • Pengembangan aktif atau investasi DevOps: Persentase beban kerja produksi akan berada di bawah pengembangan aktif. Beberapa bahkan dikelola melalui praktik DevOps yang sedang berlangsung.
  • Portabilitas beban kerja: Beberapa beban kerja dipengaruhi oleh kepatuhan, perlindungan data, atau batasan operasional yang mungkin memerlukan portabilitas pada cloud privat, tepi, atau bahkan beberapa penyedia cloud publik.
  • Konsolidasi beban kerja: Banyak beban kerja (terutama beban kerja dengan pemanfaatan yang rendah) mungkin merupakan kandidat untuk konsolidasi pada host kontainer yang menyebabkan sedikitnya server/VM dan berkurangnya biaya operasi.
  • Beban kerja warisan: Beban kerja warisan dapat memblokir pembaruan untuk sistem operasi dan bahkan mencegah migrasi ke cloud. Beban kerja warisan yang tidak kompatibel dengan fitur Azure mungkin merupakan kandidat migrasi pada host kontainer.

Beban kerja kandidat dokumen

Catatan

Daftar pertimbangan berikut hanya boleh didokumentasikan untuk kandidat migrasi yang diidentifikasi oleh kriteria di atas.

Saat membangun rencana adopsi cloud, setiap beban kerja didokumentasikan mengikuti panduan dalam Menentukan dan memprioritaskan beban kerja. Beban kerja apa pun yang merupakan kandidat untuk skenario platform aplikasi modern akan memerlukan informasi tambahan untuk memandu pelaksanaan rencana. Artikel tersebut menyoroti pentingnya mendokumentasikan input bisnis dan teknis untuk menentukan beban kerja. Untuk kandidat platform aplikasi modern, poin data berikut harus ditambahkan ke definisi beban kerja.

Input bisnis

Berikut ini adalah poin data terkait bisnis yang mungkin memengaruhi keputusan untuk menyertakan beban kerja dalam strategi platform aplikasi modern.

  • Driver kepatuhan: Kriteria kepatuhan spesifik apa yang mendorong pertimbangan untuk menghosting beban kerja ini di cloud privat?
  • Driver perlindungan data: Langkah-langkah perlindungan data apa yang mendorong pertimbangan untuk menghosting beban kerja ini di cloud privat?
  • Batasan operasional: Batasan operasional apa yang mendorong pertimbangan untuk menghosting beban kerja ini di cloud privat?
  • Hasil platform aplikasi modern: Manakah dari berikut ini yang merupakan driver di belakang mengevaluasi beban kerja ini sebagai kandidat kontainer? DevOps, portabilitas, konsolidasi, warisan, atau kelipatan driver ini.
  • Model operasi: Apakah beban kerja ini akan dikelola secara terpusat (oleh IT/CCoE pusat), tidak terpusat (oleh tim beban kerja), atau dengan operasi perusahaan (dukungan pusat dan operasi khusus beban kerja)?

Input teknis

Berikut ini adalah poin data dari tim teknologi yang dapat memengaruhi keputusan untuk menyertakan beban kerja dalam strategi platform aplikasi modern.

Pertimbangan lokasi:

Pertimbangan terkait tempat beban kerja akan dihosting.

  • Persyaratan hosting cloud publik: Apakah ada batasan teknis khusus yang terkait dengan persyaratan cloud publik?
  • Persyaratan hosting cloud privat: Apakah ada batasan teknis khusus yang terkait dengan persyaratan cloud privat?
  • Persyaratan hosting tepi: Apakah ada batasan teknis khusus yang terkait dengan persyaratan tepi?
  • Persyaratan portabilitas: Apakah ada batasan teknis khusus yang terkait dengan persyaratan portabilitas cloud?

Pertimbangan operasi:

Pertimbangan terkait pengoperasian platform, host, dan beban kerja.

  • Platform cloud utama: Organisasi harus menentukan platform cloud utama untuk menyediakan alat manajemen operasi. Beberapa organisasi mungkin memiliki lebih dari satu platform cloud utama untuk mengelola berbagai jenis operasi. Apakah platform cloud utama untuk mengoperasikan beban kerja ini?
  • Platform operasi tambahan: Apakah beban kerja ini juga akan dikelola oleh platform operasi tambahan?
  • Persyaratan hosting cloud: Apakah beban kerja ini memerlukan strategi hosting cloud tertentu? Cloud publik, cloud privat, atau portabilitas cloud
  • Platform orkestrasi yang distandarkan: Jika perusahaan memiliki solusi standar untuk orkestrasi kontainer, sertakan nama platform yang distandarkan untuk dipertimbangkan. Contoh: Azure Kubernetes Service (AKS), mesin AKS, atau Kubernetes.
  • Pertimbangan orkestrasi kustom: Apakah ada persyaratan untuk platform orkestrasi kontainer non-standar? Jika demikian, jelaskan persyaratan tersebut.
  • Operasi host yang distandarkan: Diasumsikan bahwa beban kerja tidak berbahaya dan dapat dihosting di kontainer bersama yang didukung oleh operasi host yang distandarkan. Apakah beban kerja ini kompatibel dengan pendekatan ini?
  • Pertimbangan operasi host yang disesuaikan: Jika beban kerja tidak kompatibel dengan operasi yang distandarkan, persyaratan spesifik apa yang harus dipertimbangkan saat menyusun praktik operasi host untuk beban kerja ini?

Pertimbangan aplikasi:

Pertimbangan khusus mengenai bagaimana aplikasi dikembangkan dan akan dikembangkan ke depannya.

  • Runtime platform sebagai layanan (PaaS): Penyedia cloud publik menghasilkan runtime aplikasi yang konsisten, sering disebut sebagai penawaran platform sebagai layanan (PaaS). Di Azure, runtime PaaS disediakan oleh Azure App Service. Bisakah aplikasi ini beroperasi pada runtime PaaS? Runtime manakah yang paling kompatibel?
  • Runtime yang distandarkan: Apabila aplikasi tidak kompatibel dengan runtime PaaS, apakah ada runtime yang distandarkan yang disediakan oleh organisasi? Di runtime manakah beban kerja ini akan dibangun?
  • Pertimbangan runtime kustom: Pertimbangan spesifik apa yang memerlukan runtime yang disesuaikan untuk beban kerja ini?
  • Batasan runtime: Apakah ada batasan yang dikenakan pada aplikasi oleh runtime yang dipilih?
  • Dependensi aplikasi: Apakah beban kerja ini bergantung pada sistem yang ada yang berada di lokasi tertentu (seperti publik atau privat)? Contoh akan mencakup sistem ERP seperti SAP yang berjalan dalam solusi tertentu.
  • Gravitasi data: Apakah beban kerja ini bergantung pada sumber data yang berada di lokasi tertentu (seperti publik atau privat)? Contoh dapat mencakup dependensi pada data di SAP atau sumber data terpusat lainnya.
  • Pertimbangan daftar yang disetujui: Apakah pertimbangan operasi kustom disetujui untuk digunakan dalam platform cloud Anda? Layanan yang disetujui manakah yang harus disertakan dalam penyebaran?

Pertimbangan untuk kontainer awal

Mengemas beban kerja Anda dalam kontainer merupakan badan kerja pertama yang perlu dijadwalkan dan dikerjakan. Yang kedua adalah merencanakan hosting kontainer tersebut.

Solusi PaaS untuk runtime yang distandarkan, orkestrasi, dan operasi

Beberapa beban kerja dengan kemandirian tinggi, dan tidak perlu mendapat keuntungan dari kontrol lanjutan dan persyaratan infrastruktur yang hadir dengan platform besar seperti Kubernetes. Hanya karena beban kerja Anda berada dalam kontainer, bukan berarti beban kerja tersebut harus disebarkan ke Kubernetes. Azure menyediakan berbagai solusi untuk menjalankan beban kerja di dalam portofolio Anda yang tidak memerlukan tingkat manajemen dan infrastruktur yang dibutuhkan AKS. Solusi berikut masing-masing akan mengikuti pendekatan ini terhadap perencanaan:

Pertimbangkan untuk menggunakan solusi yang lebih ringan untuk kontainer Anda dengan beban kerja yang tidak Anda harapkan untuk tumbuh dalam kompleksitas dan yang selaras dengan tujuan dan batasan solusi ini.

Orkestrasi yang distandarkan dengan runtime dan operasi kustom pada cloud publik

Untuk beban kerja yang tidak dapat berjalan dalam platform PaaS yang sepenuhnya terkelola dan harus menyampaikan kontrol tingkat infrastruktur, keinginan untuk menggunakan fitur penyebaran canggih seperti yang ditawarkan oleh orkestrator kontainer, atau berharap untuk tumbuh dalam kompleksitas modular, beralih ke Azure Kubernetes Service (AKS). AKS memecahkan masalah kedua hosting kontainer, tetapi juga menyediakan opsi arsitektur, SRE, keamanan, penyebaran, pemantauan, dan infrastruktur yang luas.

Set fitur platform dilengkapi dengan persyaratan untuk mempelajari platform, baik di tingkat operator kluster maupun pada tingkat beban kerja. Faktorkan pendidikan tim operasi, tim arsitektur, dan tim rekayasa beban kerja Anda ke dalam garis waktu migrasi. Selain itu, karena AKS adalah platform, pastikan tim beban kerja memahami pemisahan tanggung jawab di dalam platform ini terhadap pengaturan hosting mereka saat ini. Ini mungkin serupa dalam beberapa hal, tetapi kemungkinan akan menjadi unik dalam beberapa hal lainnya.

Orkestrasi, runtime, dan operasi yang disesuaikan di cloud publik

Untuk beban kerja yang sangat khusus atau persyaratan organisasi tertentu, Azure menawarkan dua platform utama lainnya di ruang orkestrasi kontainer.

  • Azure Red Hat OpenShift
  • Struktur Layanan Azure

Jika ada alasan untuk mengeksplorasi alternatif, pastikan bahwa waktu dialokasikan untuk memahami keuntungan dan pertukaran dari semua opsi platform. Solusi default Azure adalah AKS, dan dokumentasi ini mengasumsikan AKS adalah teknologi yang dipilih.

Standarisasi operasi di seluruh platform cloud

Sering kali pelanggan akan menyebarkan orkestrator kontainer yang berbeda di lingkungan cloud privat, tepi, dan cloud publik. Untuk menstandarkan operasi di seluruh platform cloud yang berbeda tersebut, pelanggan dapat menggabungkan pendekatan operasi terpadu dengan memperluas alat operasi cloud mereka ke beberapa platform cloud.

Di Azure, organisasi dapat menstandarkan operasi di berbagai orkestrator dengan melakukan onboarding host kontainer yang berbeda ke Azure Arc untuk Kubernetes. Alat ini memastikan pemantauan, operasi, dan pemerintahan yang konsisten di setiap host kontainer.

Runtime aplikasi di lingkungan cloud privat dan tepi

Ketika beban kerja harus dijalankan di lingkungan cloud privat atau tepi, tetapi beban kerja paling baik didukung oleh runtime PaaS, ada beberapa alat yang dapat memungkinkan pengembang untuk membangun di atas runtime PaaS yang konsisten menggunakan Azure App Service:

  • Azure Stack HCI: Memungkinkan hosting Azure App Service secara asli di Azure Stack, dikelola oleh operator Azure Stack.
  • Azure Stack HCI for AKS: Memungkinkan hosting runtime kustom yang berjalan di AKS di dalam Azure Stack, dikelola oleh Azure Stack dan operator AKS untuk memungkinkan portabilitas ke solusi Kubernetes lainnya.
  • Azure App Service on Kubernetes with Azure Arc: Memungkinkan host Kubernetes mana pun untuk menyediakan layanan aplikasi di Azure. Semua host menjadi instans kecil dari Azure App Service. Karena setiap host juga di-onboard ke Azure Arc, host tersebut juga dapat dikelola melalui operasi host berbasis cloud yang konsisten.

Rencana kesiapan platform aplikasi modern

Selain rencana pengembangan keterampilan adopsi cloud, tim adopsi cloud mungkin perlu mengembangkan keterampilan yang terkait dengan kontainer dan Kubernetes sebelum menjalankan rencana Anda:

Pastikan waktu dialokasikan pada tim beban kerja untuk mendokumentasikan dan uji kering rencana migrasi. Aplikasi atau sistem eksternal yang ada (baik dependensi maupun sistem yang bergantung pada beban kerja ini) mungkin perlu dimodifikasi dengan fleksibilitas tambahan untuk mendukung upaya migrasi. Hal ini berlaku baik untuk lingkungan praproduksi maupun lingkungan produksi.

Langkah selanjutnya: Tinjau lingkungan atau zona pendaratan Azure Anda

Daftar artikel berikut akan membawa Anda ke panduan pada titik-titik tertentu dalam perjalanan adopsi cloud untuk membantu Anda berhasil dalam skenario adopsi cloud.