Migrasi cloud: Apa yang perlu Anda ketahui (dan di mana menemukannya)

Migrasi ke cloud untuk enterprise yang telah menjalankan beban kerja secara lokal selama bertahun-tahun bukanlah hal yang mudah. Agar berhasil, rencana migrasi perlu mempertimbangkan berbagai aspek yang berkaitan dengan manusia, proses, dan teknologi. Jika mendesain migrasi, Anda membutuhkan panduan dan praktik terbaik untuk membantu memandu Anda melalui proses ini.

Berdasarkan pengalaman sebagai arsitek solusi, kami telah mengumpulkan dokumen lengkap untuk praktisi TI yang merencanakan, mendesain, dan mengimplementasikan migrasi ke Google Cloud. Di halaman Migrasi ke Google Cloud kami, Anda bisa menemukan informasi teknis lengkap dan saran yang Anda butuhkan untuk membantu merencanakan dan menjalankan migrasi yang berhasil. Untuk membantu Anda memulai lebih cepat, entri blog ini memberikan garis besar tingkat tinggi dan link ke bagian dokumentasi yang relevan sehingga Anda bisa memperoleh lebih banyak informasi.

Memulai migrasi

Sebelum memulai migrasi, Anda harus memiliki beberapa pemahaman mendasar tentang Google Cloud, lingkungan Anda, dan pendekatan migrasi yang berbeda:

1. Pahami perbedaan antara Google Cloud dan lingkungan saat ini. Lingkungan sumber bisa berupa lingkungan lokal atau lingkungan hosting pribadi. Lingkungan ini memiliki model operasional yang berbeda dibandingkan dengan cloud publik, dari sudut pandang keamanan fisik, jaringan, daya, hardware, dan virtualisasi.

2. Identifikasi tipe beban kerja yang perlu dimigrasikan. Kami menyarankan Anda memulai migrasi dengan mengklasifikasikan beban kerja sebagai beban kerja lama, atau cloud-native. Beban kerja lama dikembangkan tanpa mempertimbangkan lingkungan cloud, dengan dukungan terbatas untuk sumber daya penskalaan seperti disk dan komputasi. Akibatnya, beban kerja ini sulit dimodifikasi dan berat untuk dijalankan serta dirawat. Bila didesain mengikuti praktik terbaik, beban kerja cloud-native secara native skalabel, portabel, tersedia, dan aman. Akibatnya, beban kerja cloud-native cenderung meningkatkan produktivitas dan keluwesan developer, karena developer bisa berfokus pada beban kerja aktual, daripada menghabiskan upaya untuk mengelola lingkungan pengembangan dan runtime.

3. Tentukan tingkat kematangan organisasi Anda untuk teknologi cloud. Ketika diidentifikasi sejak awal, kesenjangan keterampilan bisa diatasi sebagai bagian dari proses migrasi melalui tindakan seperti belajar mandiri, pelatihan, atau bimbingan sejawat. Anda bisa menggunakan Cloud Adoption Framework dari Google Cloud untuk mengukur kematangan adopsi cloud organisasi Anda.

4. Pahami berbagai tipe pendekatan migrasi dan konsekuensinya, karena beban kerja yang berbeda mungkin memerlukan pendekatan migrasi yang berbeda. Kami mendefinisikan tiga tipe migrasi:

  1. Lift and shift. Anda memigrasikan beban kerja, dengan menerapkan perubahan paling sedikit.

  2. Improve and move. Anda memodifikasi bagian beban kerja untuk mengadopsi pendekatan cloud-native sebagai bagian dari migrasi.

  3. Rip and replace. Anda mencabut beban kerja, lalu menulis beban kerja baru, dengan mengadopsi pendekatan cloud-native.

Untuk informasi selengkapnya tentang tipe migrasi, lihat bagian panduan migrasi di Tipe migrasi.

Empat fase migrasi

Secara garis besar, perjalanan migrasi bisa ditangkap sebagai proses empat fase: Assess, Plan, Deploy, dan Optimize. Memang lebih mudah menunjukkannya secara linier, tetapi hal ini tidaklah sesederhana itu, karena fase ini sering kali terjadi secara paralel untuk beban kerja yang berbeda.

migration-to-gcp-getting-started-migration-path-01.jpg

Fase 1: Evaluasi beban kerja yang akan dimigrasikan

Fase ini dibangun berdasarkan semua pekerjaan awal yang telah dilakukan, dengan fokus pada inventarisasi beban kerja yang direncanakan untuk dimigrasikan dan masing-masing dependensinya. Hal-hal yang perlu dipikirkan meliputi (tetapi tidak terbatas pada) persyaratan hardware dan kinerja, pengguna, perizinan, kepatuhan, dan dependensi beban kerja. Kemudian, petakan informasi ini ke dalam katalog aplikasi yang merangkum informasi beberapa pertanyaan utama, misalnya:

  1. Apakah beban kerja memiliki dependensi, atau merupakan dependensi untuk beban kerja lain

  2. Seberapa penting beban kerja ini bagi bisnis

  3. Bagaimana tingkat kesulitan saat melakukan migrasi beban kerja

Katalog aplikasi akan memberi Anda tampilan tingkat tinggi besarnya upaya yang diperlukan untuk memigrasikan semua beban kerja yang berbeda. Anda juga bisa menggunakan fitur otomatis seperti StratoZone yang dapat memindai beban kerja yang ada dan memberi Anda informasi berdasarkan data yang dikumpulkan. StratoZone tidak hanya membantu penemuan tetapi juga bisa membantu Anda memetakan instance untuk mencocokkan instance Google Compute Engine. Lihat entri blog ini untuk pengantar StratoZone. Informasi tambahan tentang cara melakukan penemuan juga tersedia di bagian Mengategorikan aplikasi Anda.

Untuk lebih memahami besarnya risiko atau upaya, Anda harus melakukan bukti konsep (POC) yang menguji berbagai kasus penggunaan dan persyaratan beban kerja, dengan fokus pada beban kerja yang lebih rumit. Ini membantu mendapatkan lebih banyak informasi lebih awal serta mengurangi hal-hal yang tidak diketahui.

Anda juga harus melakukan penghitungan total biaya kepemilikan (TCO) pada fase ini, sehingga memberikan visibilitas bisnis mengenai seperti apa pengeluaran cloud mereka setelah migrasi, dibandingkan dengan lingkungan saat ini. Saat berpindah dari lingkungan lokal ke cloud, sering kali ada biaya tersembunyi yang terlewat saat menghitung biaya di pusat data lama. Kami mencantumkan beberapa hal yang harus diperhatikan saat membangun TCO ini di bagian Menghitung total biaya kepemilikan di panduan kami. Membuat bisnis memahami pergeseran model biaya dan semua keuntungan tambahan yang diperoleh akan sangat penting untuk keberhasilan migrasi.

Terakhir, Anda perlu memutuskan beban kerja yang akan dimigrasikan terlebih dahulu. Jawabannya tentu bervariasi dari masing-masing bisnis yang bergantung pada banyak faktor berbeda, seperti nilai bisnis beban kerja, kompleksitas migrasi, dan ketersediaan serta persyaratan beban kerja. Untuk membantu memutuskan hal ini, ada baiknya mengadakan pertemuan dengan para pakar di bidangnya tentang beban kerja yang berbeda dan membahas daftar faktor yang disepakati bersama. Keberhasilan dengan beban kerja pertama adalah kunci keberhasilan keseluruhan perjalanan migrasi Anda, karena kesuksesan awal akan memberikan kepercayaan dan keyakinan, sedangkan kesulitan di awal terkadang bisa menggagalkan keseluruhan project migrasi.

Fase 2: Rencanakan fondasinya

Fase berikutnya adalah merencanakan bagian mendasar dari lingkungan cloud baru, yang terdiri dari tetapi tidak terbatas pada:

1. Menetapkan identitas pengguna dan layanan. Bagaimana akun layanan dan pengguna dibuat dan dikelola? Anda bisa memilih antara domain G Suite atau Cloud Identity, dan secara opsional mengintegrasikannya dengan Penyedia Identitas (IdP) yang ada. Baca tentang hal ini di bagian Manajemen Identitas dan Akses.

2. Mendesain hierarki organisasi sumber daya. Bagaimana struktur berbagai sumber daya Google Cloud dibuat secara hierarkis? Node organisasi, folder, dan project menyediakan blok bangunan untuk menyiapkan hierarki organisasi sumber daya. Organisasi sumber daya yang didesain dengan baik menyederhanakan kontrol akses dan manajemen tagihan. Contoh berbagai tipe desain adalah:

    1. Hierarki berorientasi lingkungan - Desain ini memisahkan lingkungan produksi, penjaminan kualitas, dan pengembangan.

    2. Hierarki berorientasi fungsi - Desain ini memecah berbagai fungsi bisnis ke dalam folder mereka sendiri di tingkat atas, dan menerapkan hierarki berorientasi lingkungan di bawahnya.

    3. Hierarki berorientasi granular - Desain ini dibangun di atas hierarki berorientasi fungsi dengan menambahkan organisasi unit bisnis di tingkat atas.

Anda bisa mendalami topik ini di bagian hierarki sumber daya.

3. Menetapkan grup dan peran untuk akses sumber daya. Apa saja peran pengguna yang akan mengakses lingkungan cloud Anda? Izin apa yang harus dimiliki oleh peran yang berbeda ini? Anda perlu membuat peran manajer seperti admin organisasi, admin jaringan, dan admin keamanan untuk mengelola sumber daya cloud. Ini juga merupakan praktik terbaik membuat peran khusus untuk berbagai kelas pengguna yang akan menggunakan lingkungan cloud, misalnya developer, penguji, dan engineer keandalan situs (SRE). Semua memiliki sekumpulan izin minimum yang terkait dengan peran untuk menjalankan tugasnya. Dokumen Praktik terbaik untuk organisasi enterprise memberikan detail selengkapnya tentang topik ini.

4. Mendesain topologi dan konektivitas jaringan Anda. Di region mana Anda akan menerapkan aplikasi? Apakah akan ada konektivitas kembali ke lingkungan sumber? Berapa banyak jaringan terpisah yang perlu Anda siapkan? Jawaban atas pertanyaan ini akan dimasukkan ke dalam cara Anda mendesain Virtual Private Cloud (VPC), yang merupakan jaringan pribadi Anda dalam Google Cloud. Satu VPC memetakan satu jaringan mandiri dalam lingkungan cloud Anda. VPC memiliki subnet, aturan firewall, dan rute yang memungkinkan Anda meniru karakteristik jaringan fisik. Anda juga harus menerapkan praktik terbaik keamanan; Anda bisa membaca tentang semua ini di bagian Keamanan, serta di bagian Mengamankan aplikasi dan data Anda dari panduan Praktik terbaik untuk organisasi enterprise. Konektivitas kembali ke lingkungan sumber juga bisa dilakukan menggunakan opsi seperti interkoneksi langsung, peering, atau VPN. Untuk informasi selengkapnya, baca bagian Konektivitas dan jaringan.

Fase 3: Terapkan beban kerja

Setelah fondasi migrasi siap, langkah berikutnya adalah menentukan pendekatan terbaik untuk menerapkan beban kerja ke lingkungan cloud Anda. Anda tidak perlu melakukan pendekatan yang sama untuk semua beban kerja, tetapi, semakin terstandardisasi prosesnya, semakin besar peluang untuk pembelajaran lintas tim dan penyempurnaan proses penerapan. Contoh dari pendekatan penerapan yang berbeda adalah:

1. Penerapan manual penuh. Pendekatan ini adalah cara termudah dan tercepat untuk mengaktifkan dan menjalankan beban kerja Anda, dan bisa dilakukan langsung dari Cloud Console atau Cloud SDK. Meskipun penerapan manual mungkin boleh saja untuk eksperimen, kami tidak merekomendasikan pendekatan ini untuk penerapan beban kerja produksi karena rentan error, tidak dapat diulang, dan cenderung didokumentasikan dengan buruk. Jika Anda saat ini menggunakan penerapan manual, bagian Migrasi dari penerapan manual ke penerapan otomatis dalam container akan dapat membantu Anda memperbaiki proses.

Untuk lingkungan produksi, pilihan yang lebih baik adalah menggunakan layanan yang bisa secara otomatis mereplikasikan beban kerja yang ada di lingkungan Anda saat ini dan menerapkannya ke GCP. Google Cloud menawarkan beberapa layanan seperti itu:

  1. Migrate for Compute Engine - Layanan ini memungkinkan Anda melakukan migrasi aplikasi berbasis VM dari lingkungan yang ada (mis. VMware, Azure, AWS) ke GCP dengan periode nonaktif dan risiko minimal.

  2. Migrate for Anthos - Daripada melakukan migrasi VM sebagaimana adanya, Anda bisa dengan cerdas mengonversi dan menjalankan beban kerja di VM dan memigrasikan beban kerja tersebut ke dalam container di GKE. Hal ini sering kali mengurangi biaya dan manajemen.

  3. Database Migration Solutions - Baik melalui pihak ketiga seperti Striim, atau menggunakan dukungan replikasi native di Google Cloud SQL, ada banyak teknik berbeda untuk memasukkan data Anda ke Google Cloud.

  4. VMware Engine - Migrasikan semua beban kerja berbasis VMware yang ada dari infrastruktur lokal Anda tanpa perubahan apa pun langsung ke Google Cloud VMware Engine. Ini memungkinkan Anda menggunakan kembali semua fitur penerapan VMware yang sudah ada dan segera memulai migrasi, dan dengan mudah menambahkan beban kerja baru dengan framework VMware dalam Google Cloud.

2. Penerapan menggunakan fitur manajemen konfigurasi. Penggunaan fitur manajemen konfigurasi (CM) seperti Ansible, Chef, atau Puppet menyediakan cara yang dapat diulang, otomatis dan terkontrol untuk menjalankan penerapan Anda. Namun, fitur ini paling cocok untuk penyediaan dan konfigurasi, dan kurang cocok untuk penerapan beban kerja. Hal ini karena fitur tersebut memerlukan logika penerapan khusus untuk menangani prosedur seperti penerapan bebas periode nonaktif, penerapan blue-green, atau peluncuran update, dan akhirnya menjadi semakin sulit dikelola dan dipertahankan dalam jangka panjang.

3. Penerapan dengan menggunakan fitur orkestrasi container. Jika beban kerja Anda dalam container, Anda bisa menggunakan Google Kubernetes Engine (GKE) untuk menangani proses penerapan. Orkestrator Kubernetes langsung mendukung banyak tipe logika penerapan seperti penerapan bebas periode nonaktif dan peluncuran update yang kreatif. Selain itu, jika beban kerja Anda masih pada VM yang menjalankan GCE, Azure, atau AWS Migrate for Anthos memungkinkan Anda mengonversi VM menjadi container secara otomatis. Anda bisa mendapatkan keuntungan menjalankan di container dengan lebih cepat.

4. Penerapan secara otomatis. Proses penerapan otomatis dipicu berdasarkan beberapa tindakan yang menghasilkan perubahan dalam beban kerja dan bisa dibuat di atas fitur orkestrasi apa pun yang mendukung skrip. Penerapan otomatis memungkinkan Anda mengefisienkan dan menstandardisasi proses penerapan Anda yang akan mengurangi error manusia.

Anda bisa menggunakan fitur seperti Jenkins, SonarQube, Cloud Build, atau Spinnaker untuk membangun pipeline penerapan otomatis end-to-end di samping fitur orkestrasi yang ada. Langkah-langkah kunci proses penerapan otomatis adalah:

    1. Peninjauan kode. Setiap perubahan pada basis kode Anda harus ditinjau oleh sejawat untuk memastikan kualitas perubahan sebelum menggabungkannya dalam basis kode.

    2. Continuous integration (CI). Setelah digabungkan, fitur CI menjalankan semua pengujian terhadap versi baru basis kode dan memastikan bahwa tidak ada pengujian yang gagal. Setelah berhasil, CI akan menandai build tersebut.

    3. Produksi artefak. Setiap build yang berhasil akan menghasilkan artefak. Container adalah salah satu contoh artefak. Pengujian juga bisa dijalankan dengan menggunakan fitur seperti Serverspec untuk memastikan artefak berfungsi dengan baik.

    4. Continuous deployment (CD).Artefak yang berhasil kemudian diterapkan ke dalam lingkungan cloud pengembangan atau penjaminan kualitas, setelah itu dilakukan serangkaian uji fungsional lain terhadap penerapan tersebut untuk memastikannya berjalan dengan baik. Setelah pengujian berhasil, penerapan kemudian bisa diterapkan ke lingkungan produksi Anda, baik secara otomatis, atau setelah dipicu secara manual oleh operator.

5. Penerapan dengan menerapkan pola infrastruktur sebagai kode. Ide di balik infrastruktur sebagai kode adalah untuk menangani konfigurasi dan penyediaan sumber daya cloud dengan cara yang sama seperti memperlakukan kode sumber untuk beban kerja Anda. Mirip dengan cara menerapkan versi baru beban kerja melalui serangkaian langkah dan pengujian otomatis, setiap perubahan pada konfigurasi infrastruktur juga melalui serangkaian langkah yang melibatkan pengujian sebelum diterapkan ke lingkungan cloud target. Ini adalah praktik terbaik yang kami rekomendasikan karena memberikan pengulangan dan keterlacakan, yang meningkatkan kecepatan penerapan secara keseluruhan. Proses ini bisa diimplementasikan dengan menggunakan fitur seperti Terraform dan layanan terkelola seperti Deployment Manager.

Fase 4: Optimalkan lingkungan Anda

Setelah penerapan dasar beban kerja Anda berjalan dan diuji di lingkungan Google Cloud yang baru, Anda bisa mulai meningkatkan fondasi ini. Ini termasuk bagian penting yang harus diselesaikan sebelum memotong traffic saat ini, misalnya melatih tim Anda tentang pedoman operasional cloud baru serta memastikan bahwa logging, pemantauan, dan pemberitahuan untuk beban kerja ini sudah siap.

Aspek lain yang bisa Anda optimalkan setelah beban kerja melayani traffic produksi meliputi:

  • Pengoptimalan biaya dengan autoscaling

  • Berpindah ke beban kerja terkelola untuk mengurangi biaya operasional

  • Mengotomatiskan proses penerapan

Baca tentang cara terbaik melakukan pendekatan ini di bagian Mengoptimalkan lingkungan Anda.

Baca terus untuk memastikan migrasi cloud berhasil

Migrasi besar bisa menjadi hal yang menakutkan bagi tim yang sangat ambisius. Namun dengan metodologi, perencanaan, dan pengujian yang tepat sebelum penerapan, Anda bisa memecah masalah menjadi langkah-langkah yang lebih kecil dan lebih mudah dikelola. Panduan solusi Migrasi ke Google Cloud membahas hal-hal di atas secara lebih detail, juga menyediakan sumber daya tambahan, seperti bagian ‘Mencari Bantuan’, yang bisa Anda gunakan untuk memulai migrasi beban kerja ke cloud.

Jika Anda memerlukan bantuan lebih lanjut dari para profesional yang memiliki rekam jejak migrasi yang berhasil, Organisasi Layanan Profesional Google Cloud menawarkan layanan konsultasi secara langsung atau melalui sejumlah mitra dengan berbagai spesialisasi. Cukup hubungi dan kami bisa membantu Anda!