Dokumen ini dapat membantu Anda merencanakan, mendesain, dan menerapkan fase penilaian dari migrasi Anda ke Google Cloud. Dengan menemukan inventaris workload dan layanan Anda, serta memetakan dependensinya, Anda dapat mengidentifikasi apa yang perlu dimigrasikan dan urutannya. Saat merencanakan dan mendesain migrasi ke Google Cloud, Anda harus terlebih dahulu mengetahui pengetahuan mendalam tentang lingkungan saat ini dan workload yang akan dimigrasikan.
Dokumen ini adalah bagian dari rangkaian multi-bagian berikut tentang migrasi ke Google Cloud:
- Migrasikan ke Google Cloud: Mulai
- Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda (dokumen ini)
- Bermigrasi ke Google Cloud: Merencanakan dan membangun dasar Anda
- Bermigrasi ke Google Cloud: Transfer set data besar
- Bermigrasi ke Google Cloud: Men-deploy workload
- 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 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 lingkungan Anda saat ini. Anda harus 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 tentang 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 jadwal dan rencana migrasi.
- Validasi rencana migrasi Anda.
Membangun inventaris workload Anda
Untuk mencakup migrasi, Anda harus terlebih dahulu memahami jumlah item, seperti beban kerja 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 beban kerja, seperti database, perantara 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 memungkinkan Anda men-deploy workload di lingkungan cloud, lisensi lainnya secara eksplisit melarang deployment cloud. Beberapa lisensi ditetapkan berdasarkan jumlah CPU atau soket yang digunakan, dan konsep ini mungkin tidak berlaku ketika dijalankan di teknologi cloud. Beberapa data Anda mungkin memiliki batasan terkait wilayah geografis tempat data tersebut disimpan. Terakhir, beberapa workload sensitif dapat memerlukan tenancy tunggal.
Bersama dengan inventaris, ada baiknya Anda memberikan bantuan untuk penafsiran visual data yang telah dikumpulkan. Misalnya, Anda dapat memberikan grafik dan diagram dependensi untuk memperjelas aspek yang diminati, seperti distribusi beban kerja Anda dalam proses deployment otomatis atau manual.
Cara membuat inventaris
Ada berbagai cara untuk membangun inventaris beban kerja. Meskipun cara tercepat untuk memulai adalah melanjutkan secara manual, pendekatan ini mungkin sulit untuk lingkungan produksi yang besar. Informasi dalam inventaris yang dibuat secara manual dapat habis masa berlakunya dengan cepat, dan migrasi yang dihasilkan mungkin gagal karena Anda tidak mengonfirmasi konten inventaris Anda.
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 membangun inventaris workload, lihat Pusat Migrasi: Memulai penemuan aset.
Contoh inventaris workload
Contoh ini adalah inventaris lingkungan yang mendukung aplikasi e-commerce. Inventaris tersebut mencakup workload, dependensi, layanan yang mendukung beberapa beban kerja, dan peralatan 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 |
| Workload e-commerce | Beban kerja 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) | Beban kerja 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 workload 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
Di lingkungan Anda, Anda mungkin memiliki layanan yang mendukung beberapa workload. 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
Penting untuk memiliki pemahaman yang jelas tentang cara kerja deployment dan proses operasional Anda. Proses ini adalah bagian dasar dari praktik yang menyiapkan dan memelihara lingkungan produksi 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. Lakukan penilaian terkait proses yang dimiliki tim pengembangan untuk membangun workload Anda. Misalnya, bagaimana tim pengembangan Anda merancang, melakukan coding, dan menguji workload?
- Buat artefak yang Anda deploy di lingkungan sumber. Untuk men-deploy workload di lingkungan sumber, Anda mungkin akan membuat artefak yang dapat di-deploy, seperti image container atau image sistem operasi, atau menyesuaikan artefak yang ada, seperti image sistem operasi pihak ketiga dengan menginstal dan mengonfigurasi software. Mengumpulkan informasi tentang cara membuat artefak ini akan membantu Anda memastikan bahwa artefak yang dihasilkan cocok untuk deployment di Google Cloud.
Simpan artefak. Jika menghasilkan artefak yang disimpan di artefak registry di lingkungan sumber, Anda harus menyediakan artefak tersebut di lingkungan Google Cloud Anda. Anda dapat melakukannya dengan menggunakan strategi seperti berikut:
- Buat saluran komunikasi antarlingkungan: Buat artefak di lingkungan sumber Anda dapat dijangkau dari lingkungan Google Cloud target.
- Faktorkan ulang proses build artefak: Selesaikan pemfaktoran ulang minor pada lingkungan sumber sehingga Anda dapat menyimpan artefak di lingkungan sumber dan lingkungan target. Pendekatan ini mendukung migrasi dengan membangun infrastruktur seperti repositori artefak sebelum Anda harus mengimplementasikan proses build artefak di lingkungan Google Cloud target. Anda dapat menerapkan pendekatan ini secara langsung atau menggunakan pendekatan sebelumnya dalam membangun saluran komunikasi terlebih dahulu.
Memiliki artefak yang tersedia di lingkungan sumber dan target memungkinkan Anda berfokus pada migrasi tanpa harus mengimplementasikan 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 melindungi dari kerentanan umum dan eksposur jaringan yang tidak diinginkan, serta penandatanganan kode untuk membantu memastikan bahwa hanya kode tepercaya yang berjalan di lingkungan Anda.
Deploy artefak di lingkungan sumber Anda. 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 akan diperlukan untuk memfaktorkan ulang proses pada akhirnya. Misalnya, jika proses deployment hanya berfungsi dengan lingkungan sumber, Anda mungkin perlu memfaktorkan ulang proses tersebut untuk menargetkan lingkungan Google Cloud Anda.
Memasukkan konfigurasi runtime. Anda mungkin perlu memasukkan konfigurasi runtime untuk cluster, lingkungan runtime, atau deployment workload tertentu. Konfigurasi mungkin melakukan inisialisasi variabel lingkungan dan nilai konfigurasi lainnya, seperti secret, kredensial, dan kunci. Untuk membantu memastikan bahwa proses injeksi konfigurasi runtime Anda berfungsi di Google Cloud, sebaiknya evaluasi cara Anda mengonfigurasi workload yang berjalan di lingkungan sumber Anda.
Logging, pemantauan, dan pembuatan profil. Lakukan penilaian terhadap proses logging, pemantauan, dan pembuatan profil yang Anda miliki untuk memantau kondisi lingkungan sumber, metrik yang diinginkan, dan cara Anda memakai data yang disediakan oleh proses ini.
Autentikasi. Lakukan penilaian terkait cara Anda melakukan autentikasi terhadap lingkungan sumber.
Sediakan dan konfigurasi 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 manajemen 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 antar-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 kategori yang berbeda. Kategorisasi ini dapat membantu Anda memprioritaskan workload untuk dimigrasikan sesuai dengan kompleksitas dan risikonya saat berpindah ke cloud.
Matriks katalog harus memiliki satu dimensi untuk setiap kriteria penilaian yang Anda pertimbangkan di lingkungan Anda. Pilih sekumpulan kriteria yang mencakup semua persyaratan lingkungan Anda, termasuk resource sistem yang diperlukan setiap workload. Misalnya, Anda mungkin tertarik untuk mengetahui apakah suatu beban kerja memiliki dependensi, atau apakah workload tersebut stateless atau stateful. Saat Anda mendesain matriks katalog, pertimbangkan bahwa untuk setiap kriteria yang ditambahkan, Anda menambahkan dimensi lain untuk diwakili. Matriks yang dihasilkan mungkin sulit divisualisasikan. Solusi yang memungkinkan untuk masalah ini adalah dengan menggunakan beberapa matriks yang lebih kecil, bukan matriks tunggal yang kompleks.
Selain itu, di samping setiap beban kerja, Anda harus menambahkan indikator kompleksitas migrasi. Indikator ini memperkirakan rating kesulitan untuk memigrasikan setiap workload. Perincian indikator ini bergantung pada lingkungan Anda. Untuk contoh dasar, Anda dapat memiliki tiga kategori: mudah dimigrasikan, sulit dimigrasikan, atau tidak dapat dimigrasi. 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 membangun inventaris workload, lihat Pusat Migrasi: 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 workload lain.
- Periode nonaktif maksimum yang diizinkan untuk beban kerja.
- Seberapa sulit beban kerja untuk 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 | ||
| Workload 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 Cloudsepenuhnya, organisasi Anda harus mulai mempelajari layanan, produk, dan teknologi yang dapat digunakan bisnis Anda Google Cloud. Staf Anda dapat memulai dengan Google Cloud akun uji coba gratis 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:
- Referensi publik dan terbuka: Anda dapat memulai pembelajaran Google Cloud dengan lab praktik, serial video, webinar Cloud OnAir, dan acara pelatihan Cloud OnBoard gratis.
- Kursus mendalam: Jika ingin lebih memahami cara kerjanya Google Cloud , Anda dapat mengikuti kursus on-demand dari Google Cloud Skills Boost atau Google Cloud Spesialisasi Pelatihan dari Coursera yang dapat Anda ikuti secara online sesuai kemampuan Anda atau pelatihan 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 Google Cloud layanan.
Anda juga dapat mesertifikasi pengetahuan engineer Anda tentang Google Cloud dengan berbagai sertifikasi, di berbagai tingkat:
- Sertifikasi level associate: Titik awal bagi pengguna yang baru mengenal Google Cloud , yang dapat membuka peluang untuk memperoleh sertifikasi profesional, seperti sertifikasi partner cloud engineer.
- Sertifikasi profesional: Jika Anda ingin menilai keterampilan desain dan implementasi lanjutan selama Google Cloud dengan pengalaman bertahun-tahun, Anda bisa mendapatkan sertifikasi seperti arsitek cloud profesional atau data engineer profesional.
- 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 developer Google: Anda dapat menunjukkan keterampilan pengembangan dengan sertifikasi Associate Android developer (Sertifikasi ini sedang diperbarui) dan pakar web seluler.
Selain pelatihan dan sertifikasi, salah satu cara terbaik untuk mendapatkan pengalaman dengan Google Cloud adalah dengan mulai menggunakan produk untuk membangun bukti konsep bisnis.
Bukti konsep eksperimen dan desain
Untuk menunjukkan nilai dan efektivitas Google Cloud, pertimbangkan untuk mendesain dan mengembangkan satu atau beberapa bukti konsep (PoC) untuk setiap kategori workload di katalog workload Anda. Melalui eksperimen dan pengujian, Anda dapat memvalidasi asumsi dan menunjukkan nilai cloud kepada pemimpin bisnis.
Minimal, PoC Anda harus menyertakan hal berikut:
- Daftar lengkap kasus penggunaan yang didukung workload Anda, termasuk kasus yang tidak umum dan kasus ekstrem.
- 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 workload yang terikat 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 banyak waktu yang diperlukan untuk melakukannya. Jika Anda mengalami peningkatan nilai yang signifikan, seperti mengurangi waktu peningkatan skala workload baru sebesar 95% dibandingkan dengan lingkungan Anda saat ini, eksperimen ini dapat menunjukkan nilai bisnis instan.
Jika Anda tertarik untuk mengevaluasi performa database lokal 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 Benchmark PerfKit, dan membandingkan Google Cloud dengan penyedia cloud lainnya. 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 Anda mendapatkan gambaran jelas tentang resource yang diperlukan di lingkungan baru, Anda dapat membuat model total biaya kepemilikan yang memungkinkan Anda membandingkan biaya Google Cloud dengan biaya lingkungan Anda saat ini.
Ketika membuat model biaya ini, Anda tidak hanya harus mempertimbangkan biaya untuk hardware dan software, tetapi juga semua biaya operasional untuk menjalankan pusat data Anda sendiri,seperti daya, pendinginan, pemeliharaan, dan layanan dukungan lainnya. Pertimbangkan bahwa cara ini biasanya juga lebih mudah untuk mengurangi biaya, berkat skalabilitas Google Cloud resource yang elastis dibandingkan 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 workload yang memproses banyak data atau yang menghasilkan traffic jaringan dalam jumlah besar, Anda mungkin perlu mempertimbangkan arsitektur dan aliran 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 grup instance penskalaan otomatis. Opsi ini dapat berdampak besar pada biaya pengoperasian layanan dan harus dieksplorasi untuk menghitung total biaya kepemilikan (TCO).
Untuk menghitung total biaya Google Cloud resource, Anda dapat menggunakan kalkulator harga.
Memilih strategi migrasi untuk workload Anda
Untuk setiap workload yang akan dimigrasikan, evaluasi dan pilih strategi migrasi yang paling sesuai dengan kasus penggunaannya. Misalnya, workload Anda mungkin memiliki kondisi berikut:
- Model ini tidak menoleransi periode nonaktif atau kehilangan data, seperti beban kerja yang sangat penting. Untuk workload ini, Anda dapat memilih strategi migrasi periode nonaktif nol atau hampir nol.
- Chromebook menoleransi periode nonaktif, seperti beban kerja sekunder atau backend. Untuk beban kerja ini, Anda dapat memilih strategi migrasi yang memerlukan periode nonaktif.
Saat Anda memilih strategi migrasi, pertimbangkan bahwa strategi migrasi dengan periode nonaktif nol dan hampir nol biasanya lebih mahal dan rumit untuk desain dan penerapannya dibandingkan strategi migrasi yang memerlukan periode nonaktif.
Pilih alat migrasi Anda
Setelah memilih strategi migrasi untuk workload Anda, tinjau dan tentukan alat migrasi yang digunakan.
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 workload
- Ketersediaan untuk menggunakan layanan terkelola untuk migrasi
Untuk memastikan migrasi dan migrasi 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, pemuatan, atau bahkan seluruh infrastruktur dari satu lingkungan ke lingkungan lainnya. Dengan kemampuan ini, model ini merangkum logika migrasi yang kompleks dan menawarkan kemampuan pemantauan migrasi.
Menentukan rencana dan jadwal migrasi
Setelah memiliki gambaran menyeluruh tentang lingkungan Anda saat ini, Anda harus menyelesaikan rencana migrasi dengan:
- Mengelompokkan beban kerja dan data yang akan dimigrasikan dalam kumpulan (disebut juga sprint dalam beberapa konteks).
- Memilih urutan migrasi batch yang diinginkan.
- Memilih urutan migrasi workload yang diinginkan 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 Anda mendapatkan pengalaman dengan Google Cloud, momentum dengan migrasi, dan pemahaman tentang lingkungan, Anda dapat melakukan hal berikut:
- Menyempurnakan pengelompokan beban kerja dan data yang akan dimigrasikan.
- Meningkatkan ukuran batch migrasi.
- Perbarui urutan migrasi batch dan beban kerja di dalam batch.
- Perbarui komposisi batch.
Untuk mengelompokkan beban kerja dan data yang akan dimigrasikan dalam batch, serta untuk menentukan pengurutan migrasi, Anda menilai beban kerja berdasarkan beberapa kriteria, seperti berikut:
- Nilai bisnis dari workload.
- Apakah workload di-deploy atau dijalankan dengan cara yang unik dibandingkan dengan infrastruktur Anda yang lain.
- Tim yang bertanggung jawab atas pengembangan, deployment, dan pengoperasian beban kerja.
- Jumlah, jenis, dan cakupan dependensi workload.
- Memfaktorkan ulang upaya untuk membuat beban kerja berfungsi di lingkungan baru.
- Persyaratan kepatuhan dan lisensi beban kerja.
- Persyaratan ketersediaan dan keandalan workload.
Beban kerja yang Anda migrasikan terlebih dahulu adalah beban kerja yang memungkinkan tim Anda membangun pengetahuan dan pengalaman 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 bersifat kritis untuk bisnis akan melindungi lini utama bisnis Anda, dan mengurangi dampak terhadap bisnis dari risiko dan kesalahan yang belum ditemukan saat tim Anda mempelajari teknologi cloud. Misalnya, jika Anda memilih komponen tempat logika transaksi keuangan utama dari workload e-commerce Anda diterapkan sebagai penggerak pertama, kesalahan apa pun selama migrasi dapat berdampak pada lini bisnis utama Anda. Pilihan yang lebih baik adalah database SQL yang mendukung workload Anda, atau lebih baik lagi, database staging.
Sebaiknya Anda menghindari beban kerja yang jarang digunakan. Misalnya, jika Anda memilih workload yang hanya digunakan beberapa kali per tahun oleh sejumlah kecil pengguna, meskipun migrasinya berisiko rendah, beban kerja ini tidak meningkatkan momentum migrasi Anda, dan mungkin sulit untuk mendeteksi dan merespons masalah.
Kasus ekstrem
Anda juga harus menghindari kasus ekstrem agar dapat menemukan pola yang dapat diterapkan ke workload lain untuk dimigrasikan. Sasaran utama saat memilih penggerak pertama adalah mendapatkan pengalaman dengan pola umum di organisasi sehingga Anda dapat membangun pusat informasi. Anda dapat menerapkan hal yang telah dipelajari dengan pemindah pertama ini saat memigrasikan workload mendatang.
Misalnya, jika sebagian besar workload Anda didesain dengan metodologi pengembangan berbasis pengujian dan dikembangkan menggunakan bahasa pemrograman Python, yang memilih workload dengan cakupan pengujian yang kecil serta dikembangkan menggunakan bahasa pemrograman Java, Anda tidak dapat menemukan pola apa pun yang dapat diterapkan saat memigrasikan workload Python.
Tim
Saat memilih penggerak pertama, perhatikan tim yang bertanggung jawab atas setiap workload. Tim yang bertanggung jawab untuk first-mover harus sangat termotivasi, serta ingin mencoba Google Cloud dan layanannya. Selain itu, pemimpin bisnis harus memiliki tujuan yang jelas untuk tim first-mover dan bekerja secara aktif untuk mensponsori serta mendukung mereka melalui proses.
Misalnya, tim berperforma tinggi yang bekerja di kantor utama dengan histori yang telah terbukti dalam menerapkan praktik pengembangan modern seperti DevOps dan disiplin ilmu seperti site reliability engineering dapat menjadi kandidat yang tepat. Jika mereka juga memiliki sponsor kepemimpinan {i>top-down<i} dan tujuan yang jelas untuk setiap migrasi workload, mereka bisa menjadi kandidat yang luar biasa.
Dependensi
Selain itu, Anda harus berfokus pada workload yang memiliki jumlah dependensi paling sedikit, baik dari workload atau layanan lain. Migrasi workload tanpa dependensi akan lebih mudah jika Anda memiliki pengalaman terbatas dengan Google Cloud.
Jika Anda harus memilih workload yang memiliki dependensi pada komponen lain, pilih workload yang dikaitkan secara longgar ke dependensinya. Jika workload sudah didesain untuk dependensinya yang tidak tersedia, 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 ketidaktersediaan infrastruktur lainnya.
Meskipun ada strategi untuk memigrasikan data workload stateful, workload stateless jarang memerlukan migrasi data. Memigrasikan beban kerja stateless dapat lebih mudah karena Anda tidak perlu mengkhawatirkan fase sementara di mana data berada sebagian di lingkungan saat ini dan sebagian di lingkungan target. Misalnya, microservice stateless adalah kandidat aplikasi yang pertama dimigrasikan yang baik, karena tidak bergantung pada data stateful lokal.
Upaya pemfaktoran ulang
First-mover harus memerlukan jumlah pemfaktoran ulang yang minimal, sehingga Anda dapat berfokus pada migrasi itu sendiri dan pada Google Cloud, daripada menghabiskan banyak upaya untuk melakukan perubahan pada kode dan konfigurasi workload Anda. Pemfaktoran ulang harus berfokus pada perubahan yang diperlukan, yang memungkinkan workload Anda berjalan di lingkungan target, bukan berfokus pada modernisasi dan pengoptimalan workload, yang akan ditangani pada fase migrasi berikutnya.
Misalnya, beban kerja yang hanya memerlukan perubahan konfigurasi adalah penggerak pertama yang baik, karena Anda tidak perlu mengimplementasikan perubahan apa pun pada codebase, dan Anda dapat menggunakan artefak yang ada.
Pemberian lisensi dan kepatuhan
Lisensi juga berperan dalam memilih penggerak pertama, karena beberapa beban kerja Anda mungkin dilisensikan berdasarkan persyaratan yang memengaruhi migrasi Anda. Misalnya, beberapa lisensi secara eksplisit melarang pengoperasian workload di lingkungan cloud.
Saat memeriksa persyaratan pemberian lisensi, jangan lupa persyaratan kepatuhan karena Anda mungkin memiliki persyaratan tenant tunggal untuk beberapa workload Anda. Karena alasan ini, Anda harus memilih workload dengan jumlah batasan lisensi dan kepatuhan paling sedikit sebagai first-first.
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, hal ini akan mengalihkan perhatian tim Anda dari mendapatkan pengalaman yang diperlukan dengan Google Cloud, karena mereka harus meluangkan waktu untuk menerapkan strategi tersebut.
Misalnya, persyaratan ketersediaan mesin batch processing dapat menoleransi periode nonaktif yang lebih lama daripada workload yang berhubungan langsung dengan pelanggan di situs e-commerce Anda tempat pengguna menyelesaikan transaksi.
Memvalidasi rencana migrasi
Sebelum mengambil tindakan untuk memulai rencana migrasi, sebaiknya Anda memvalidasi kelayakannya. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk memvalidasi rencana migrasi.
Langkah berikutnya
- Pelajari cara merencanakan migrasi dan membangun dasar Anda 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