Dokumen ini dapat membantu Anda merencanakan, mendesain, dan menerapkan fase penilaian migrasi ke Google Cloud. Menemukan inventaris workload 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 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: Merencanakan dan 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.
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.
Pada fase penilaian, Anda akan menentukan persyaratan dan dependensi untuk memigrasikan lingkungan sumber ke Google Cloud.
Fase penilaian sangat penting untuk keberhasilan migrasi Anda. Anda perlu mendapatkan pengetahuan mendalam tentang workload yang ingin dimigrasikan, persyaratannya, dependensinya, dan tentang lingkungan Anda saat ini. Anda perlu memahami titik awal agar berhasil merencanakan dan menjalankan migrasi Google Cloud.
Fase penilaian terdiri dari tugas-tugas berikut:
- Mem-build inventaris workload yang komprehensif.
- Membuat katalog workload 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 strategi migrasi untuk workload Anda.
- Pilih alat migrasi Anda.
- Tentukan rencana dan linimasa migrasi.
- Validasi rencana migrasi Anda.
Membuat inventaris workload
Untuk menentukan cakupan migrasi, Anda harus terlebih dahulu memahami jumlah item, seperti workload 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 workload, tetapi setidaknya harus berisi hal berikut:
- Dependensi setiap workload, seperti database, broker pesan, sistem penyimpanan konfigurasi, dan komponen lainnya.
- Layanan yang mendukung infrastruktur workload Anda, seperti repositori sumber, alat continuous integration dan continuous deployment (CI/CD), 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 workload 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 wilayah geografis tempatnya disimpan. Terakhir, beberapa beban kerja 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 cara beban kerja Anda didistribusikan dalam proses deployment otomatis atau manual.
Cara membuat inventaris
Ada berbagai cara untuk membuat inventaris beban kerja. 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 Anda tidak mengonfirmasi konten inventaris.
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 informasi tentang cara membuat inventaris workload, lihat Migration Center: Memulai penemuan aset.
Contoh inventaris workload
Contoh ini adalah inventaris lingkungan yang mendukung aplikasi e-commerce. Inventaris ini mencakup beban kerja, dependensi, layanan yang mendukung beberapa beban kerja, dan perangkat hardware.
Beban kerja
Untuk setiap workload 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 |
| Beban kerja e-commerce | Workload 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) | Workload 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 beban kerja yang tercantum dalam inventaris. Dependensi ini diperlukan agar workload 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 workload 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
Sangat penting untuk memiliki pemahaman yang jelas tentang cara kerja proses deployment dan operasional Anda. Proses ini adalah bagian mendasar dari praktik yang menyiapkan dan memelihara lingkungan produksi Anda serta beban kerja yang berjalan di sana.
Proses deployment dan operasional Anda dapat mem-build artefak yang diperlukan oleh beban kerja Anda agar berfungsi. Oleh karena itu, Anda harus mengumpulkan informasi tentang setiap jenis artefak. Misalnya, artefak dapat berupa paket sistem operasi, paket deployment aplikasi, image sistem operasi container, atau lainnya.
Selain jenis artefak, pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:
- Kembangkan workload Anda. Nilai proses yang dimiliki tim pengembangan untuk mem-build workload Anda. Misalnya, bagaimana tim pengembangan Anda mendesain, melakukan coding, dan menguji workload?
- Buat artefak yang Anda deploy di lingkungan sumber. Untuk men-deploy beban kerja di lingkungan sumber, Anda mungkin membuat artefak yang dapat di-deploy, seperti image container atau image sistem operasi, atau Anda mungkin menyesuaikan artefak yang ada, seperti image sistem operasi pihak ketiga dengan menginstal dan mengonfigurasi software. Mengumpulkan informasi tentang cara Anda membuat artefak ini membantu Anda memastikan bahwa artefak yang dihasilkan sesuai untuk deployment di Google Cloud.
Simpan artefak. Jika Anda membuat artefak yang disimpan di registry artefak di lingkungan sumber, Anda harus menyediakan artefak tersebut di lingkungan Google Cloud. Anda dapat melakukannya dengan menggunakan strategi seperti berikut:
- Membuat saluran komunikasi antarlingkungan: Buat artefak di lingkungan sumber Anda dapat dijangkau dari lingkungan Google Cloud target.
- Faktorkan ulang proses build artefak: Selesaikan pemfaktoran ulang kecil pada lingkungan sumber agar Anda dapat menyimpan artefak di lingkungan sumber dan lingkungan target. Pendekatan ini mendukung migrasi Anda dengan mem-build infrastruktur seperti repositori artefak sebelum Anda harus menerapkan proses build artefak di lingkungan Google Cloud target. Anda dapat menerapkan pendekatan ini secara langsung, atau Anda dapat mengembangkan pendekatan sebelumnya dengan membuat saluran komunikasi terlebih dahulu.
Dengan memiliki artefak yang tersedia di lingkungan sumber dan target, Anda dapat berfokus pada migrasi tanpa harus menerapkan proses build artefak di lingkungan Google Cloud target sebagai bagian dari migrasi.
Pindai dan tanda tangani kode. Sebagai bagian dari proses build artefak, Anda mungkin menggunakan pemindaian kode untuk membantu Anda melindungi dari kerentanan umum dan ekspos jaringan yang tidak diinginkan, serta penandatanganan kode untuk membantu Anda memastikan bahwa hanya kode tepercaya yang berjalan di lingkungan Anda.
Deploy artefak di lingkungan sumber. Setelah membuat artefak yang dapat di-deploy, Anda mungkin akan men-deploy-nya di lingkungan sumber. Sebaiknya Anda menilai setiap proses deployment. Penilaian ini membantu memastikan bahwa proses deployment Anda kompatibel dengan Google Cloud. Hal ini juga membantu Anda memahami upaya yang pada akhirnya akan diperlukan untuk memfaktorkan ulang proses. Misalnya, jika proses deployment Anda hanya berfungsi dengan lingkungan sumber, Anda mungkin perlu memfaktorkan ulang proses tersebut untuk menargetkan lingkungan Google Cloud Anda.
Memasukkan konfigurasi runtime. Anda mungkin memasukkan konfigurasi runtime untuk cluster, lingkungan runtime, atau deployment beban kerja tertentu. Konfigurasi dapat menginisialisasi variabel lingkungan dan nilai konfigurasi lainnya seperti secret, kredensial, dan kunci. Untuk membantu memastikan proses injeksi konfigurasi runtime Anda berfungsi di Google Cloud, sebaiknya Anda menilai cara Anda mengonfigurasi workload yang berjalan di lingkungan sumber Anda.
Logging, pemantauan, dan pembuatan profil. Nilai proses logging, pemantauan, dan pembuatan profil yang Anda terapkan untuk memantau kondisi lingkungan sumber, metrik yang diinginkan, dan cara Anda menggunakan data yang disediakan oleh proses ini.
Autentikasi. Nilai cara Anda mengautentikasi terhadap lingkungan sumber.
Menyediakan dan mengonfigurasi resource Anda. Untuk menyiapkan lingkungan sumber, Anda mungkin telah mendesain dan menerapkan proses yang menyediakan dan mengonfigurasi resource. Misalnya, Anda mungkin menggunakan Terraform bersama dengan alat pengelolaan konfigurasi untuk menyediakan dan mengonfigurasi resource di lingkungan sumber Anda.
Menilai infrastruktur Anda
Setelah menilai proses deployment dan operasional, sebaiknya Anda menilai infrastruktur yang mendukung workload Anda di lingkungan sumber.
Untuk menilai infrastruktur tersebut, pertimbangkan hal berikut:
- 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, project, dan namespace.
- Cara Anda menghubungkan lingkungan ke lingkungan lain, seperti lingkungan lokal, dan penyedia cloud lainnya.
Mengategorikan workload Anda
Setelah menyelesaikan inventaris, Anda perlu mengatur workload ke dalam berbagai kategori. Kategorisasi ini dapat membantu Anda memprioritaskan workload yang akan dimigrasikan 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 workload. Misalnya, Anda mungkin tertarik untuk mengetahui apakah beban kerja 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 workload, Anda harus menambahkan indikator kompleksitas migrasi. Indikator ini memperkirakan rating kesulitan untuk memigrasikan setiap workload. 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 informasi tentang cara membuat inventaris workload, lihat Migration Center: Memulai penemuan aset.
Contoh katalog workload
Kriteria penilaian berikut digunakan dalam contoh ini, satu untuk setiap sumbu matriks:
- Seberapa penting beban kerja bagi bisnis.
- Apakah beban kerja memiliki dependensi, atau merupakan dependensi untuk beban kerja lain.
- Periode nonaktif maksimum yang diizinkan untuk beban kerja.
- Seberapa sulit workload 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 | ||
| Beban kerja 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 beban kerja mudah dipindahkan, tiga di antaranya sulit dipindahkan, dan salah satunya tidak dapat dipindahkan.
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. 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 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 ikuti secara online sesuai kecepatan Anda sendiri 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 workload atau operator infrastruktur cara terbaik menggunakan layanan Google Cloud.
Anda juga dapat certify 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 beban kerja di katalog beban kerja 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 beban kerja Anda, termasuk kasus yang tidak umum dan tidak terduga.
- Semua persyaratan untuk setiap kasus penggunaan, seperti persyaratan performa, skalabilitas, dan konsistensi, 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 beban kerja yang terikat CPU perlu diskalakan dengan cepat untuk memenuhi puncak permintaan, Anda dapat menjalankan eksperimen untuk memverifikasi bahwa zona dapat membuat banyak inti CPU virtual, dan berapa lama waktu yang diperlukan untuk melakukannya. Jika Anda mengalami nilai tambah yang signifikan, seperti mengurangi waktu penskalaan beban kerja baru sebesar 95% dibandingkan dengan lingkungan Anda saat ini, eksperimen ini dapat menunjukkan nilai bisnis instan.
Jika Anda ingin mengevaluasi performa database lokal jika dibandingkan dengan Cloud SQL, Spanner, Firestore, atau Bigtable, Anda dapat mengimplementasikan PoC di mana 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 beban kerja yang menggunakan banyak data, atau beban kerja 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 strategi migrasi untuk workload Anda
Untuk setiap beban kerja yang akan dimigrasikan, evaluasi dan pilih strategi migrasi yang paling sesuai dengan kasus penggunaannya. Misalnya, workload Anda mungkin memiliki kondisi berikut:
- Aplikasi tersebut tidak dapat menerima downtime atau kehilangan data, seperti beban kerja yang sangat penting. Untuk workload ini, Anda dapat memilih strategi migrasi tanpa periode nonaktif atau hampir tanpa periode nonaktif.
- Layanan ini dapat mentoleransi periode nonaktif, seperti beban kerja sekunder atau backend. Untuk beban kerja ini, Anda dapat memilih strategi migrasi yang memerlukan periode nonaktif.
Saat memilih strategi migrasi, pertimbangkan bahwa strategi migrasi periode nonaktif nol dan hampir nol biasanya lebih mahal dan rumit untuk dirancang dan diterapkan daripada strategi migrasi yang memerlukan periode nonaktif.
Pilih alat migrasi Anda
Setelah memilih strategi migrasi untuk beban kerja, tinjau dan tentukan alat migrasi.
Ada banyak alat migrasi yang tersedia, masing-masing dioptimalkan untuk kasus penggunaan migrasi tertentu. Kasus penggunaan dapat mencakup hal berikut:
- Strategi migrasi
- Lingkungan sumber dan target
- Ukuran data dan workload
- Frekuensi perubahan pada data dan beban kerja
- Ketersediaan untuk menggunakan layanan terkelola untuk migrasi
Untuk memastikan migrasi dan peralihan yang lancar, Anda dapat menggunakan pola deployment aplikasi, orkestrasi infrastruktur, dan aplikasi migrasi kustom. Namun, alat khusus yang disebut layanan migrasi terkelola dapat memfasilitasi proses pemindahan data, beban kerja, atau bahkan seluruh infrastruktur dari satu lingkungan ke lingkungan lainnya. Dengan kemampuan ini, keduanya mengenkapsulasi logika migrasi yang kompleks dan menawarkan kemampuan pemantauan migrasi.
Menentukan rencana dan linimasa migrasi
Setelah mendapatkan gambaran menyeluruh tentang lingkungan Anda saat ini, Anda harus menyelesaikan rencana migrasi dengan:
- Mengelompokkan workload dan data untuk dimigrasikan dalam batch (juga disebut sprint dalam beberapa konteks).
- Memilih urutan migrasi batch.
- Memilih urutan migrasi beban kerja di dalam setiap batch.
Sebagai bagian dari rencana migrasi, sebaiknya Anda juga membuat dokumen berikut:
- Dokumen desain teknis
- Matriks RACI
- Linimasa (seperti rencana T-Minus)
Saat mendapatkan pengalaman dengan Google Cloud, momentum dengan migrasi, dan pemahaman tentang lingkungan Anda, Anda dapat melakukan hal berikut:
- Pertajam pengelompokan beban kerja dan data yang akan dimigrasikan.
- Meningkatkan ukuran batch migrasi.
- Perbarui urutan migrasi batch dan workload di dalam batch.
- Perbarui komposisi batch.
Untuk mengelompokkan workload dan data yang akan dimigrasikan dalam batch, dan menentukan urutan migrasi, Anda menilai workload berdasarkan beberapa kriteria, seperti berikut:
- Nilai bisnis beban kerja.
- Apakah beban kerja di-deploy atau dijalankan dengan cara yang unik dibandingkan dengan infrastruktur Anda lainnya.
- Tim yang bertanggung jawab atas pengembangan, deployment, dan operasi workload.
- Jumlah, jenis, dan cakupan dependensi workload.
- Pemfaktoran ulang upaya untuk membuat workload berfungsi di lingkungan baru.
- Persyaratan kepatuhan dan pemberian lisensi workload.
- Persyaratan ketersediaan dan keandalan beban kerja.
Workload yang Anda migrasikan terlebih dahulu adalah workload 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.
Nilai bisnis
Memilih workload 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 beban kerja 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 beban kerja Anda, atau lebih baik lagi, database staging.
Sebaiknya Anda menghindari workload yang jarang digunakan. Misalnya, jika Anda memilih beban kerja 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 workload lain untuk dimigrasikan. Tujuan utama saat memilih aplikasi yang pertama Anda migrasikan adalah mendapatkan pengalaman dengan pola umum dalam organisasi Anda sehingga Anda dapat membuat basis pengetahuan. Anda dapat menerapkan hal yang telah dipelajari dengan aplikasi yang pertama dimigrasikan ini saat memigrasikan beban kerja mendatang.
Misalnya, jika sebagian besar beban kerja Anda dirancang dengan mengikuti metodologi pengembangan berbasis pengujian dan dikembangkan menggunakan bahasa pemrograman Python, memilih beban kerja dengan cakupan pengujian yang sedikit dan dikembangkan menggunakan bahasa pemrograman Java, tidak memungkinkan Anda menemukan pola apa pun yang dapat diterapkan saat memigrasikan beban kerja Python.
Tim
Saat memilih aplikasi yang pertama Anda migrasikan, perhatikan tim yang bertanggung jawab untuk setiap workload. Tim yang bertanggung jawab atas aplikasi yang pertama dimigrasikan harus sangat bermotivasi, 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 workload, mereka bisa menjadi kandidat yang luar biasa.
Dependensi
Selain itu, Anda harus fokus pada workload yang memiliki jumlah dependensi paling sedikit, baik dari workload atau layanan lain. Migrasi beban kerja tanpa dependensi akan lebih mudah jika pengalaman Anda dengan Google Cloud terbatas.
Jika Anda harus memilih beban kerja yang memiliki dependensi pada komponen lain, pilih beban kerja yang dikaitkan secara longgar ke dependensinya. Jika workload sudah didesain untuk ketidaktersediaan dependensinya yang tidak pasti, workload tersebut dapat mengurangi hambatan saat memigrasikan workload ke lingkungan target. Misalnya, kandidat yang dikaitkan secara longgar adalah workload yang berkomunikasi menggunakan perantara pesan, atau yang berfungsi secara offline, atau dirancang untuk menoleransi ketiadaan infrastruktur lainnya.
Meskipun ada strategi untuk memigrasikan data workload stateful, workload stateless jarang memerlukan migrasi data. Migrasi workload stateless dapat menjadi lebih mudah karena Anda tidak perlu khawatir tentang fase sementara saat data sebagian 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 workload Anda. Pemfaktoran ulang harus berfokus pada perubahan yang diperlukan agar workload Anda dapat berjalan di lingkungan target, bukan berfokus pada modernisasi dan pengoptimalan workload, yang akan ditangani dalam fase migrasi berikutnya.
Misalnya, workload yang hanya memerlukan perubahan konfigurasi merupakan workload 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 beban kerja Anda mungkin dilisensikan berdasarkan persyaratan yang memengaruhi migrasi Anda. Misalnya, beberapa lisensi secara eksplisit melarang workload yang berjalan di lingkungan cloud.
Saat memeriksa persyaratan pemberian lisensi, jangan lupakan persyaratan kepatuhan karena Anda mungkin memiliki persyaratan tenancy tunggal untuk beberapa beban kerja Anda. Karena alasan ini, Anda harus memilih beban kerja yang memiliki jumlah pembatasan lisensi dan kepatuhan paling sedikit sebagai beban kerja 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 workload 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 beban kerja yang ditampilkan kepada pelanggan di situs e-commerce tempat pengguna menyelesaikan transaksi mereka.
Memvalidasi rencana migrasi
Sebelum mengambil tindakan untuk memulai rencana migrasi, sebaiknya Anda memvalidasi kelayakan rencana tersebut. Untuk informasi selengkapnya, lihat Praktik terbaik untuk memvalidasi rencana migrasi.
Langkah selanjutnya
- Pelajari cara merencanakan migrasi dan membangun fondasi di Google Cloud.
- Pelajari kapan harus menemukan bantuan untuk migrasi.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Marco Ferrari | Cloud Solutions Architect