Dokumen ini dapat membantu Anda merencanakan, mendesain, dan menerapkan fase penilaian migrasi ke Google Cloud. Menemukan inventaris aplikasi dan layanan serta memetakan dependensinya, dapat membantu Anda mengidentifikasi item yang perlu dimigrasikan dan urutannya. Saat merencanakan dan merancang migrasi ke Google Cloud, pertama-tama Anda perlu memiliki pengetahuan mendalam tentang lingkungan Anda saat ini serta aplikasi dan workload yang akan dimigrasikan.
Dokumen ini adalah bagian dari rangkaian multi-bagian berikut tentang migrasi ke Google Cloud:
- Bermigrasi ke Google Cloud: Memulai
- Migrasi ke Google Cloud: Menilai dan menemukan workload Anda (dokumen ini)
- Bermigrasi ke Google Cloud: Membangun fondasi Anda
- Bermigrasi ke Google Cloud: Mentransfer set data besar Anda
- Bermigrasi ke Google Cloud: Men-deploy workload Anda
- Bermigrasi ke Google Cloud: Bermigrasi dari deployment manual ke deployment otomatis dalam container
- Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda
- Bermigrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi
- Bermigrasi ke Google Cloud: Meminimalkan biaya
Diagram berikut menggambarkan jalur perjalanan migrasi Anda.
Fase penilaian adalah fase pertama dalam migrasi Anda ke Google Cloud. Dalam fase ini, Anda akan menentukan persyaratan dan dependensi untuk memigrasikan aplikasi Anda ke Google Cloud.
Dokumen ini berguna jika Anda merencanakan migrasi dari lingkungan lokal, lingkungan hosting pribadi, penyedia cloud lain, atau jika Anda mengevaluasi peluang untuk bermigrasi dan mempelajari seperti apa fase penilaian ini.
Fase penilaian sangat penting untuk keberhasilan migrasi Anda. Anda perlu mendapatkan pengetahuan mendalam tentang aplikasi yang ingin dimigrasikan, persyaratannya, dependensinya, dan tentang lingkungan Anda saat ini. Anda perlu memahami titik awal agar berhasil merencanakan dan menjalankan migrasi Google Cloud.
Dalam fase ini, Anda melakukan langkah-langkah berikut:
- Buat inventaris aplikasi yang komprehensif.
- Buat katalog aplikasi Anda sesuai dengan properti dan dependensinya.
- Latih dan ajari tim Anda di Google Cloud.
- Buat eksperimen dan bukti konsep di Google Cloud.
- Hitung total biaya kepemilikan (TCO) lingkungan target.
- Pilih beban kerja yang ingin Anda migrasikan terlebih dahulu.
Membuat inventaris aplikasi
Untuk menentukan cakupan migrasi, Anda harus terlebih dahulu memahami jumlah item, seperti aplikasi dan peralatan hardware, yang ada di lingkungan Anda saat ini, beserta dependensinya. Membuat inventaris adalah tugas penting yang memerlukan upaya signifikan, terutama jika Anda tidak menerapkan sistem katalog otomatis. Untuk memiliki inventaris yang komprehensif, Anda harus menggunakan keahlian tim yang bertanggung jawab atas desain, deployment, dan operasi setiap beban kerja di lingkungan Anda saat ini, serta lingkungan itu sendiri.
Inventaris tidak boleh dibatasi hanya untuk aplikasi, tetapi setidaknya harus berisi hal berikut:
- Dependensi setiap aplikasi, seperti database, broker pesan, sistem penyimpanan konfigurasi, dan komponen lainnya.
- Layanan yang mendukung infrastruktur aplikasi Anda, seperti repositori sumber, alat continuous integration (CI), dan repositori artefak.
- Server, baik lingkungan virtual atau fisik, dan runtime.
- Peralatan fisik, seperti perangkat jaringan, firewall, dan hardware khusus lainnya.
Saat menyusun daftar ini, Anda juga harus mengumpulkan informasi tentang setiap item, termasuk:
- Lokasi kode sumber dan apakah Anda dapat memodifikasi kode sumber ini.
- Metode deployment untuk beban kerja di lingkungan runtime, misalnya, jika Anda menggunakan pipeline deployment otomatis atau manual.
- Batasan jaringan atau persyaratan keamanan.
- Persyaratan alamat IP.
- Cara Anda mengekspos beban kerja kepada klien.
- Persyaratan pemberian lisensi untuk software atau hardware apa pun.
- Cara beban kerja melakukan autentikasi terhadap sistem pengelolaan akses dan identitas Anda.
Misalnya, untuk setiap alat hardware, Anda harus mengetahui spesifikasi mendetailnya, seperti nama, vendor, teknologi, dan dependensinya pada item lain dalam inventaris Anda. Contoh:
- Nama: Peralatan NAS
- Vendor dan model: Vendor Y, Model Z
- Teknologi: NFS, iSCSI
- Dependensi: Konektivitas jaringan dengan frame Jumbo ke hardware komputasi VM.
Daftar ini juga harus menyertakan informasi non-teknis, misalnya, berdasarkan persyaratan pemberian lisensi yang mengizinkan Anda untuk menggunakan setiap item dan persyaratan kepatuhan lainnya. Meskipun beberapa lisensi mengizinkan Anda men-deploy aplikasi di lingkungan cloud, lisensi lain secara eksplisit melarang deployment cloud. Beberapa lisensi ditetapkan berdasarkan jumlah CPU atau soket yang digunakan, dan konsep ini mungkin tidak berlaku saat dijalankan di teknologi cloud. Beberapa data Anda mungkin memiliki batasan terkait region geografis tempatnya disimpan. Akhirnya, beberapa beban kerja yang sensitif mungkin memerlukan tenancy tunggal.
Bersama dengan inventaris, ada baiknya Anda memberikan bantuan untuk penafsiran visual data yang telah dikumpulkan. Misalnya, Anda dapat menyediakan diagram dan grafik dependensi untuk menyoroti aspek yang diminati, seperti bagaimana aplikasi Anda didistribusikan dalam proses deployment otomatis atau manual.
Cara membuat inventaris
Ada berbagai cara untuk membuat inventaris aplikasi. Meskipun cara tercepat untuk memulainya adalah dengan melanjutkan secara manual, pendekatan ini bisa menjadi sulit untuk lingkungan produksi yang besar. Informasi dalam inventaris yang dibuat secara manual dapat menjadi usang dengan cepat, dan migrasi yang dihasilkan mungkin gagal karena didasarkan pada asumsi yang salah.
Membuat inventaris bukanlah pekerjaan satu kali. Jika lingkungan Anda saat ini sangat dinamis, Anda juga harus berupaya mengotomatiskan pembuatan dan pemeliharaan inventaris, sehingga pada akhirnya Anda memiliki tampilan yang konsisten tentang semua item di lingkungan Anda pada waktu tertentu. Untuk mengetahui informasi tentang cara mem-build inventaris aplikasi, lihat Pusat Migrasi: Memulai penemuan aset.
Google juga bermitra dengan beberapa perusahaan untuk membantu dalam perjalanan migrasi Anda. Untuk mengetahui informasi selengkapnya, lihat Menemukan bantuan.
Contoh inventaris aplikasi
Contoh ini adalah inventaris lingkungan yang mendukung aplikasi e-commerce. Inventaris ini mencakup aplikasi, dependensi, layanan yang mendukung beberapa aplikasi, dan peralatan hardware.
Aplikasi
Untuk setiap aplikasi di lingkungan, tabel berikut menyoroti teknologi yang paling penting, prosedur deployment-nya, dan persyaratan lainnya.
| Nama | Lokasi kode sumber | Teknologi | Prosedur deployment | Persyaratan lainnya | Dependensi | Persyaratan resource sistem |
|---|---|---|---|---|---|---|
| Situs pemasaran | Repositori perusahaan | Frontend Angular | Otomatis | Departemen hukum harus memvalidasi konten | Layanan caching | 5 core CPU RAM 8 GB |
| Back office | Repositori perusahaan | Backend Java, frontend Angular | Otomatis | T/A | Database SQL | 4 core CPU RAM 4 GB |
| Aplikasi E-commerce | Aplikasi eksklusif | Vendor X Model Y Versi 1.2.0 |
Manual | Data pelanggan harus berada di dalam Uni Eropa | Database SQL | 10 core CPU RAM 32 GB |
| Enterprise resource planning (ERP) | Aplikasi eksklusif | Vendor Z, Model C, Versi 7.0 | Manual | T/A | Database SQL | 10 core CPU RAM 32 GB |
| Microservice stateless | Repositori perusahaan | Java | Otomatis | T/A | Layanan caching | 4 core CPU RAM 8 GB |
Dependensi
Tabel berikut adalah contoh dependensi aplikasi yang tercantum dalam inventaris. Dependensi ini diperlukan agar aplikasi berfungsi dengan benar.
| Nama | Teknologi | Persyaratan lainnya | Dependensi | Persyaratan resource sistem |
|---|---|---|---|---|
| Database SQL | PostgreSQL | Data pelanggan harus berada di dalam Uni Eropa | Sistem pencadangan dan arsip | 30 core CPU RAM 512 GB |
Layanan pendukung
Anda mungkin memiliki layanan yang mendukung beberapa aplikasi di lingkungan Anda. Dalam contoh e-commerce ini, ada layanan berikut:
| Nama | Teknologi | Persyaratan lainnya | Dependensi | Persyaratan resource sistem |
|---|---|---|---|---|
| Repositori kode sumber | Git | T/A | Sistem pencadangan dan arsip | 2 core CPU RAM 4 GB |
| Sistem pencadangan dan arsip | Vendor G, Model H, versi 2.3.0 | Secara hukum, penyimpanan jangka panjang diperlukan untuk beberapa item | T/A | 10 core CPU RAM 8 GB |
| Alat CI | Jenkins | T/A | Repositori kode sumber repositori artefak sistem pengarsipan dan pencadangan |
32 core CPU RAM 128 GB |
| Repositori artefak | Vendor A Model N Versi 5.0.0 |
T/A | Sistem pencadangan dan arsip | 4 core CPU RAM 8 GB |
| Layanan batch processing | Cron job berjalan di dalam alat CI | T/A | Alat CI | 4 core CPU RAM 8 GB |
| Layanan caching | Memcached Redis |
T/A | T/A | 12 core CPU RAM 50 GB |
Hardware
Lingkungan contoh memiliki peralatan hardware berikut:
| Nama | Teknologi | Persyaratan lainnya | Dependensi | Persyaratan resource sistem |
|---|---|---|---|---|
| Firewall | Vendor H Model V |
T/A | T/A | T/A |
| Instance Server j | Vendor K Model B |
Harus dinonaktifkan karena tidak didukung lagi | T/A | T/A |
| Peralatan NAS | Vendor Y Model Z NFS iSCSI |
T/A | T/A | T/A |
Menilai proses deployment dan operasional Anda
Setelah membuat inventaris beban kerja Anda, sebaiknya nilai proses deployment dan operasional Anda. Proses deployment dan operasional Anda adalah bagian mendasar dari praktik yang menyiapkan dan memelihara lingkungan produksi serta beban kerja yang berjalan di sana.
Proses ini dapat menyediakan infrastruktur yang diperlukan, dan membuat artefak yang diperlukan beban kerja Anda, seperti paket sistem operasi, paket deployment beban kerja, image sistem operasi, dan image container. For each workload, gather information about: how many artifacts it needs, the type of each artifact, how you're building these artifacts, how and where you're storing them, and how you're injecting runtime configuration so that these artifacts are reusable across environments.z
Setelah menilai proses deployment dan operasional, sebaiknya Anda juga menilai bagaimana proses ini dapat memfasilitasi migrasi Anda ke Google Cloud, dan bagaimana proses tersebut membantu Anda mengurangi cakupan dan risiko migrasi. Misalnya, Anda dapat memfaktorkan ulang proses build artefak untuk menyimpan artefak di lingkungan sumber dan di Google Cloud saat migrasi sedang berlangsung. Memiliki artefak di kedua lingkungan memungkinkan Anda untuk berfokus pada migrasi workload dan data dari lingkungan sumber ke Google Cloud tanpa harus mengimplementasikan proses build artefak di lingkungan Google Cloud target sejak awal proses migrasi.
Menilai infrastruktur Anda
Setelah menilai proses deployment dan operasional, sebaiknya Anda menilai infrastruktur yang saat ini mendukung workload Anda di lingkungan sumber.
Untuk menilai infrastruktur tersebut, pertimbangkan hal berikut:
- Proses yang Anda gunakan untuk menyediakan resource yang diperlukan beban kerja, seperti infrastruktur sebagai kode.
- Cara Anda mengatur resource di lingkungan sumber. Misalnya, beberapa lingkungan mendukung pemisahan logis antara resource menggunakan konstruksi yang mengisolasi grup resource satu sama lain, seperti organisasi dan project.
- Cara Anda menghubungkan lingkungan ke lingkungan lain, seperti lingkungan lokal, dan penyedia cloud lainnya.
Mengategorikan aplikasi
Setelah menyelesaikan inventaris, Anda perlu mengatur aplikasi ke dalam berbagai kategori. Kategorisasi ini dapat membantu Anda memprioritaskan aplikasi untuk bermigrasi sesuai dengan kompleksitas dan risikonya ketika dipindahkan ke cloud.
Matriks katalog harus memiliki satu dimensi untuk setiap kriteria penilaian yang Anda pertimbangkan di lingkungan Anda. Pilih serangkaian kriteria yang mencakup semua persyaratan lingkungan Anda, termasuk resource sistem yang diperlukan setiap aplikasi. Misalnya, Anda mungkin tertarik untuk mengetahui apakah aplikasi memiliki dependensi, atau apakah bersifat stateless atau stateful. Saat mendesain matriks katalog, pertimbangkan bahwa untuk setiap kriteria yang ditambahkan, Anda menambahkan dimensi lain untuk ditampilkan. Matriks yang dihasilkan mungkin sulit divisualisasikan. Solusi yang memungkinkan untuk masalah ini adalah menggunakan beberapa matriks yang lebih kecil, bukan satu matriks yang kompleks.
Selain itu, di samping setiap aplikasi, Anda harus menambahkan indikator kompleksitas migrasi. Indikator ini memperkirakan rating kesulitan untuk memigrasikan setiap aplikasi. Tingkat perincian indikator ini bergantung pada lingkungan Anda. Sebagai contoh dasarnya, Anda mungkin memiliki tiga kategori: mudah dimigrasikan, sulit dimigrasikan, atau tidak dapat dimigrasikan. Untuk menyelesaikan aktivitas ini, Anda memerlukan pakar untuk setiap item dalam inventaris untuk memperkirakan kompleksitas migrasinya. Pemicu kompleksitas migrasi ini unik untuk setiap bisnis.
Setelah katalog lengkap, Anda juga dapat membuat visual dan grafik untuk membantu Anda dan tim mengevaluasi metrik yang diminati dengan cepat. Misalnya, gambar grafik yang menyoroti jumlah komponen yang memiliki dependensi atau soroti kesulitan migrasi setiap komponen.
Untuk mengetahui informasi tentang cara mem-build inventaris aplikasi Anda, lihat Pusat Migrasi: Memulai penemuan aset.
Contoh katalog aplikasi
Kriteria penilaian berikut digunakan dalam contoh ini, satu untuk setiap sumbu matriks:
- Seberapa penting aplikasi bagi bisnis.
- Apakah aplikasi memiliki dependensi, atau merupakan dependensi untuk aplikasi lain.
- Periode nonaktif maksimum yang diizinkan untuk aplikasi.
- Seberapa sulit aplikasi dimigrasikan.
| Pentingnya bisnis | Tidak memiliki dependensi atau dependen | Memiliki dependensi atau dependen | Periode nonaktif maksimum yang diizinkan | Kesulitan |
|---|---|---|---|---|
| Misi penting | Microservice stateless | 2 menit | Mudah | |
| ERP | 24 jam | Sulit | ||
| Aplikasi E-commerce | Tanpa periode nonaktif | Sulit | ||
| Firewall hardware | Tanpa periode nonaktif | Tidak dapat dipindahkan | ||
| Database SQL | 10 menit | Mudah | ||
| Repositori kode sumber | 12 jam | Mudah | ||
| Non-misi penting | Situs pemasaran | 2 jam | Mudah | |
| Pencadangan dan pengarsipan | 24 jam | Mudah | ||
| Layanan batch processing | 48 jam | Mudah | ||
| Layanan caching | 30 menit | Mudah | ||
| Back office | 48 jam | Sulit | ||
| Alat CI | 24 jam | Mudah | ||
| Repositori artefak | 30 menit | Mudah |
Untuk membantu memvisualisasikan hasil di katalog, Anda dapat membuat visual dan diagram. Diagram berikut menyoroti tingkat kesulitan migrasi:
Dalam diagram sebelumnya, sebagian besar aplikasi mudah dipindahkan, sementara hanya tiga aplikasi yang sulit dipindahkan, dan salah satunya tidak dapat Anda pindahkan.
Mengedukasi organisasi Anda tentang Google Cloud
Untuk memanfaatkan Google Cloud sepenuhnya, organisasi Anda harus mulai mempelajari layanan, produk, dan teknologi yang dapat digunakan bisnis Anda di Google Cloud. Staf Anda dapat memulai dengan akun uji coba gratis Google Cloud yang berisi kredit untuk membantu mereka bereksperimen dan belajar secara langsung. Menciptakan lingkungan bebas untuk pengujian dan pembelajaran sangat penting untuk pengalaman belajar staf Anda.
Anda memiliki beberapa opsi pelatihan:
- Resource publik dan terbuka: Anda dapat mulai mempelajari Google Cloud dengan lab interaktif, serial video, Webinar Cloud OnAir, dan acara pelatihan Cloud OnBoard gratis.
- Kursus mendalam: Jika Anda ingin memahami lebih dalam tentang cara kerja Google Cloud, Anda dapat mengikuti kursus on-demand dari Google Cloud Skills Boost atau Spesialisasi Pelatihan Google Cloud dari Coursera yang dapat Anda hadiri secara online sesuai kemampuan Anda atau pelatihan di kelas oleh partner pelatihan resmi kami di seluruh dunia. Kursus ini biasanya berlangsung selama satu hari hingga beberapa hari.
- Jalur pembelajaran berbasis peran: Anda dapat melatih engineer sesuai dengan peran mereka dalam organisasi. Misalnya, Anda dapat melatih developer aplikasi atau operator infrastruktur cara terbaik menggunakan layanan Google Cloud.
Anda juga dapat mensertifikasi pengetahuan engineer Anda tentang Google Cloud dengan berbagai sertifikasi, di berbagai tingkat:
- Sertifikasi Associate: Titik awal bagi mereka yang baru menggunakan Google Cloud yang dapat membuka pintu untuk sertifikasi profesional, seperti sertifikasi partner cloud engineer.
- Sertifikasi profesional: Jika ingin menilai keterampilan desain dan implementasi tingkat lanjut untuk Google Cloud berdasarkan pengalaman bertahun-tahun, Anda bisa mendapatkan sertifikasi, seperti professional cloud architect atau professional data engineer.
- Sertifikasi Google Workspace: Anda dapat menunjukkan keterampilan kolaborasi menggunakan alat Google Workspace dengan sertifikasi Google Workspace.
- Sertifikasi Apigee: Dengan sertifikasi engineer API tersertifikasi Apigee, Anda dapat menunjukkan kemampuan untuk mendesain dan mengembangkan API yang tangguh, aman, dan skalabel.
- Sertifikasi Google Developers: Anda dapat menunjukkan keterampilan pengembangan dengan sertifikasi Associate Android developer (Sertifikasi ini sedang diperbarui) dan mobile web specialist.
Selain pelatihan dan sertifikasi, salah satu cara terbaik untuk mendapatkan pengalaman dengan Google Cloud adalah dengan mulai menggunakan produk tersebut untuk membuat bukti konsep bisnis.
Bereksperimen dan mendesain bukti konsep
Untuk menunjukkan nilai dan efikasi Google Cloud, pertimbangkan untuk merancang dan mengembangkan satu atau beberapa bukti konsep (PoC) untuk setiap kategori aplikasi di katalog aplikasi Anda. Eksperimen dan pengujian memungkinkan Anda memvalidasi asumsi dan menunjukkan nilai cloud kepada para pemimpin bisnis.
Minimal, PoC Anda harus menyertakan hal berikut:
- Daftar lengkap kasus penggunaan yang didukung aplikasi Anda, termasuk kasus yang tidak umum dan tidak terduga.
- Semua persyaratan untuk setiap kasus penggunaan, seperti persyaratan performa dan skalabilitas, jaminan konsistensi yang diharapkan, mekanisme failover, dan persyaratan jaringan.
- Daftar potensial teknologi dan produk yang ingin Anda selidiki dan diuji.
Anda harus mendesain PoC dan eksperimen untuk memvalidasi semua kasus penggunaan yang ada dalam daftar. Setiap eksperimen harus memiliki konteks, cakupan, output yang diharapkan, dan dampak bisnis yang dapat diukur.
Misalnya, jika salah satu aplikasi yang terikat dengan CPU perlu diskalakan dengan cepat untuk memenuhi puncak permintaan, Anda dapat menjalankan eksperimen untuk memverifikasi bahwa suatu zona dapat membuat banyak core CPU virtual, dan berapa lama waktu yang diperlukan untuk melakukannya. Jika Anda mengalami nilai tambah yang signifikan, seperti mengurangi waktu peningkatan skala aplikasi baru sebesar 95% dibandingkan dengan lingkungan Anda saat ini, hal ini dapat menunjukkan nilai bisnis instan.
Jika ingin mengevaluasi performa database lokal Anda dibandingkan dengan Cloud SQL, Spanner, Firestore, atau Bigtable, Anda dapat menerapkan PoC jika logika bisnis yang sama menggunakan database yang berbeda. PoC ini memberi Anda peluang berisiko rendah untuk mengidentifikasi solusi database terkelola yang tepat untuk beban kerja Anda di beberapa tolok ukur dan biaya operasi.
Jika ingin mengevaluasi performa proses penyediaan VM di Google Cloud, Anda dapat menggunakan alat pihak ketiga seperti PerfKit Benchmarker, dan membandingkan Google Cloud dengan penyedia cloud lain. Anda dapat mengukur waktu keseluruhan untuk menyediakan resource di cloud, selain melaporkan metrik standar performa puncak, termasuk latensi, throughput, dan waktu penyelesaian. Misalnya, Anda mungkin ingin mengetahui berapa banyak waktu dan upaya yang diperlukan untuk menyediakan banyak cluster Kubernetes. PerfKit Benchmarker adalah upaya komunitas open source yang melibatkan lebih dari 500 peserta, seperti peneliti, institusi akademik, dan perusahaan, termasuk Google.
Menghitung total biaya kepemilikan
Setelah memiliki gambaran yang jelas tentang resource yang diperlukan di lingkungan baru, Anda dapat membuat model total biaya kepemilikan yang memungkinkan Anda membandingkan biaya di Google Cloud dengan biaya lingkungan Anda saat ini.
Saat membuat model biaya ini, Anda harus mempertimbangkan tidak hanya biaya untuk hardware dan software, tetapi juga semua biaya operasional untuk menjalankan pusat data Anda sendiri, seperti daya listrik, pendinginan, pemeliharaan, dan layanan dukungan lainnya. Pertimbangkan bahwa tindakan ini juga biasanya lebih mudah untuk mengurangi biaya, berkat skalabilitas resource Google Cloud yang elastis, dibandingkan dengan pusat data lokal yang lebih kaku.
Biaya yang sering diabaikan saat mempertimbangkan migrasi cloud adalah penggunaan jaringan cloud. Di pusat data, membeli infrastruktur jaringan, seperti router dan tombol, lalu menjalankan pemasangan kabel jaringan yang sesuai adalah biaya satu kali yang memungkinkan Anda menggunakan seluruh kapasitas jaringan. Di lingkungan cloud, ada banyak cara yang dapat ditagih untuk penggunaan jaringan. Untuk aplikasi yang menggunakan banyak data, atau aplikasi yang menghasilkan traffic jaringan dalam jumlah besar, Anda mungkin perlu mempertimbangkan arsitektur dan alur jaringan baru untuk menurunkan biaya jaringan di cloud.
Google Cloud juga menyediakan berbagai opsi untuk penskalaan resource dan biaya yang cerdas. Misalnya, di Compute Engine, Anda dapat menyesuaikan ukuran selama migrasi dengan Migrate for Compute Engine, atau setelah VM berjalan, atau membuat penskalaan grup instance secara otomatis. Opsi ini dapat berdampak besar pada biaya pengoperasian layanan dan harus dieksplorasi untuk menghitung total biaya kepemilikan (TCO).
Untuk menghitung total biaya resource Google Cloud, Anda dapat menggunakan kalkulator harga.
Memilih aplikasi yang akan dimigrasikan terlebih dahulu
Setelah mendapatkan gambaran menyeluruh tentang lingkungan Anda saat ini, Anda harus menyelesaikan rencana migrasi dengan memilih urutan awal yang Anda inginkan untuk memigrasikan aplikasi. Anda dapat menyaring pesanan ini selama migrasi jika sudah mendapatkan pengalaman dengan Google Cloud serta memahami lingkungan dan aplikasi Anda.
Aplikasi yang Anda migrasikan terlebih dahulu adalah aplikasi yang memungkinkan tim Anda membangun pengetahuan dan pengalaman mereka di Google Cloud. Eksposur cloud dan pengalaman yang lebih besar dari tim Anda dapat menurunkan risiko komplikasi selama fase migrasi Anda, serta mempermudah dan mempercepat migrasi berikutnya. Oleh karena itu, memilih aplikasi yang pertama dimigrasikan dengan tepat sangat penting untuk keberhasilan migrasi. Anda dapat memilih satu aplikasi, atau menempatkan banyak aplikasi dari seluruh matriks aplikasi dalam daftar aplikasi yang pertama Anda migrasikan.
Mengidentifikasi aplikasi yang pertama dimigrasikan memang rumit, tetapi berikut ini beberapa kriteria untuk memandu Anda:
- Nilai bisnis aplikasi.
- Apakah aplikasi di-deploy atau dijalankan dengan cara yang unik dibandingkan dengan infrastruktur Anda lainnya.
- Tim yang bertanggung jawab atas pengembangan, deployment, dan operasi aplikasi.
- Jumlah, jenis, dan cakupan dependensi aplikasi.
- Pemfaktoran ulang upaya untuk membuat aplikasi berfungsi di lingkungan baru.
- Persyaratan kepatuhan dan pemberian lisensi aplikasi.
- Persyaratan ketersediaan dan keandalan aplikasi.
Nilai bisnis
Memilih aplikasi yang tidak penting bagi bisnis akan melindungi lini bisnis utama Anda, dan mengurangi dampak bisnis dari risiko serta kesalahan yang belum diketahui saat tim Anda mempelajari teknologi cloud. Misalnya, jika Anda memilih komponen tempat logika transaksi keuangan utama dari aplikasi e-commerce Anda diterapkan sebagai aplikasi yang pertama dimigrasi, kesalahan apa pun selama migrasi dapat berdampak pada lini bisnis utama Anda. Pilihan yang lebih baik adalah database SQL yang mendukung aplikasi Anda, atau lebih baik lagi, database staging.
Sebaiknya Anda menghindari aplikasi yang jarang digunakan. Misalnya, jika Anda memilih aplikasi yang hanya digunakan beberapa kali per tahun oleh sejumlah kecil pengguna, meskipun merupakan migrasi dengan risiko rendah, hal ini tidak meningkatkan momentum migrasi, dan dapat sulit untuk dideteksi dan merespons masalah.
Kasus ekstrem
Anda juga harus menghindari kasus ekstrem agar dapat menemukan pola yang dapat diterapkan ke aplikasi lain untuk dimigrasikan. Tujuan utama saat memilih aplikasi yang pertama Anda migrasikan adalah mendapatkan pengalaman dengan pola umum dalam organisasi Anda sehingga Anda dapat membangun dasar pengetahuan. Anda dapat menerapkan kembali hal yang telah dipelajari dengan aplikasi yang pertama dimigrasikan ini saat memigrasikan aplikasi mendatang.
Misalnya, jika sebagian besar aplikasi Anda didesain mengikuti metodologi pengembangan berbasis pengujian dan dikembangkan menggunakan Bahasa pemrograman Python, memilih aplikasi dengan sedikit cakupan pengujian dan dikembangkan menggunakan Bahasa pemrograman Java, tidak memungkinkan Anda menemukan pola apa pun yang dapat diterapkan saat memigrasikan aplikasi Python.
Tim
Saat memilih aplikasi yang pertama Anda migrasikan, perhatikan tim yang bertanggung jawab untuk setiap aplikasi. Tim yang bertanggung jawab atas aplikasi yang pertama dimigrasikan harus sangat termotivasi, dan selalu ingin mencoba Google Cloud dan layanannya. Selain itu, pemimpin bisnis harus memiliki tujuan yang jelas untuk tim aplikasi yang pertama dimigrasikan dan bekerja secara aktif untuk mensponsori dan mendukung mereka melalui prosesnya.
Misalnya, tim berperforma tinggi yang bekerja di kantor utama dengan sejarah yang terbukti dalam menerapkan praktik pengembangan modern seperti DevOps dan disiplin ilmu seperti site reliability engineering bisa menjadi kandidat yang baik. Jika mereka juga memiliki sponsor kepemimpinan yang top-down dan tujuan yang jelas seputar setiap migrasi aplikasi, mereka bisa menjadi kandidat yang luar biasa.
Dependensi
Selain itu, Anda harus fokus pada aplikasi yang memiliki jumlah dependensi paling sedikit, baik dari aplikasi atau layanan lain. Migrasi aplikasi tanpa dependensi akan lebih mudah jika pengalaman Anda dengan Google Cloud terbatas.
Jika Anda harus memilih aplikasi yang memiliki dependensi pada komponen lain, pilih aplikasi yang dikaitkan secara longgar ke dependensinya. Jika aplikasi sudah didesain untuk ketidaktersediaan dependensinya yang tidak pasti, aplikasi tersebut dapat mengurangi hambatan saat memigrasikan aplikasi ke lingkungan target. Misalnya, kandidat yang dikaitkan secara longgar adalah aplikasi yang berkomunikasi menggunakan perantara pesan, atau yang berfungsi secara offline, atau dirancang untuk menoleransi ketidaktersediaan infrastruktur lainnya.
Meskipun ada strategi untuk memigrasikan data aplikasi stateful, aplikasi stateless jarang memerlukan migrasi data. Migrasi aplikasi stateless dapat menjadi lebih mudah karena Anda tidak perlu khawatir tentang fase sementara ketika sebagian data berada di lingkungan Anda saat ini dan sebagian di lingkungan target Anda. Misalnya, microservice stateless adalah kandidat aplikasi yang pertama dimigrasikan yang baik, karena tidak bergantung pada data stateful lokal.
Upaya pemfaktoran ulang
Aplikasi yang pertama dimigrasikan harus memerlukan pemfaktoran ulang dalam jumlah minimal, sehingga Anda dapat berfokus pada migrasi itu sendiri dan di Google Cloud, daripada menghabiskan banyak upaya untuk mengubah kode dan konfigurasi aplikasi Anda. Pemfaktoran ulang harus berfokus pada perubahan yang diperlukan agar aplikasi Anda dapat berjalan di lingkungan target, bukan berfokus pada modernisasi dan pengoptimalan aplikasi, yang akan ditangani dalam fase migrasi berikutnya.
Misalnya, aplikasi yang hanya memerlukan perubahan konfigurasi merupakan aplikasi yang pertama dimigrasikan yang baik, karena Anda tidak perlu menerapkan perubahan apa pun pada codebase, dan Anda dapat menggunakan artefak yang ada.
Pemberian lisensi dan kepatuhan
Lisensi juga berperan dalam memilih aplikasi yang pertama dimigrasikan, karena beberapa aplikasi Anda mungkin dilisensikan berdasarkan persyaratan yang memengaruhi migrasi Anda. Misalnya, beberapa lisensi secara eksplisit melarang aplikasi yang berjalan di lingkungan cloud.
Saat memeriksa persyaratan pemberian lisensi, jangan lupakan persyaratan kepatuhan karena Anda mungkin memiliki persyaratan tenancy tunggal untuk beberapa aplikasi Anda. Karena alasan ini, Anda harus memilih aplikasi yang memiliki jumlah lisensi dan pembatasan kepatuhan paling sedikit sebagai aplikasi yang pertama dimigrasikan.
Misalnya, pelanggan Anda mungkin memiliki hak hukum untuk memilih di region mana Anda menyimpan data mereka, atau data pelanggan Anda mungkin terbatas pada region tertentu.
Ketersediaan dan keandalan
Aplikasi yang pertama dimigrasikan yang baik adalah yang dapat membayar periode nonaktif yang disebabkan oleh periode pergeseran. Jika memilih aplikasi yang memiliki persyaratan ketersediaan yang ketat, Anda harus menerapkan strategi migrasi data tanpa periode nonaktif seperti Y (menulis dan membaca) atau dengan mengembangkan microservice akses data. Meskipun pendekatan ini dapat dilakukan, pendekatan ini mengalihkan perhatian tim Anda dari mendapatkan pengalaman yang diperlukan dengan Google Cloud, karena mereka harus menghabiskan waktu untuk menerapkan strategi tersebut.
Misalnya, persyaratan ketersediaan mesin batch processing dapat menoleransi periode nonaktif yang lebih lama dibandingkan aplikasi yang ditampilkan kepada pelanggan di situs e-commerce tempat pengguna menyelesaikan transaksi mereka.
Langkah selanjutnya
- Pelajari cara merencanakan migrasi dan membangun fondasi Anda di Google Cloud.
- Pelajari cara menemukan bantuan untuk migrasi.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.