Membangun arsitektur hybrid dan multicloud menggunakan Google Cloud

Last reviewed 2024-11-27 UTC

Panduan arsitektur ini memberikan panduan praktis tentang cara merencanakan dan merancang lingkungan hybrid dan multi-cloud menggunakan Google Cloud. Dokumen ini adalah dokumen pertama dari tiga dokumen dalam kumpulan. Panduan ini akan membahas peluang dan pertimbangan yang terkait dengan arsitektur ini dari sudut pandang bisnis dan teknologi. Artikel ini juga menganalisis dan membahas banyak pola arsitektur hybrid dan multicloud yang telah terbukti.

Kumpulan dokumen untuk pola arsitektur hybrid dan multicloud terdiri dari bagian berikut:

Anda dapat membaca setiap artikel arsitektur ini secara terpisah, tetapi untuk mendapatkan manfaat maksimal, sebaiknya baca artikel tersebut secara berurutan sebelum membuat keputusan arsitektur.

Kecepatan perubahan permintaan pasar yang cepat telah meningkatkan persyaratan dan ekspektasi yang dibebankan pada IT perusahaan, seperti skala dinamis, peningkatan performa untuk pengalaman pengguna yang dioptimalkan, dan keamanan. Banyak perusahaan tingkat perusahaan mengalami kesulitan untuk memenuhi permintaan dan ekspektasi ini hanya menggunakan infrastruktur dan proses tradisional. Departemen IT juga berada di bawah tekanan untuk meningkatkan efektivitas biaya, sehingga sulit untuk membenarkan investasi modal tambahan di pusat data dan peralatan.

Strategi hybrid cloud yang menggunakan kemampuan komputasi cloud publik memberikan solusi pragmatis. Dengan menggunakan cloud publik, Anda dapat memperluas kapasitas dan kemampuan platform komputasi tanpa biaya investasi modal di awal.

Dengan menambahkan satu atau beberapa solusi berbasis cloud publik, seperti Google Cloud, ke infrastruktur yang ada, Anda tidak hanya mempertahankan investasi yang ada, tetapi juga tidak perlu berkomitmen pada satu vendor cloud. Selain itu, dengan menggunakan strategi hybrid, Anda dapat memodernisasi aplikasi dan proses secara bertahap sesuai resource.

Untuk membantu Anda merencanakan keputusan arsitektur dan perencanaan strategi hybrid atau multicloud, ada beberapa potensi tantangan dan pertimbangan desain yang harus Anda pertimbangkan. Panduan arsitektur multi-bagian ini menyoroti potensi manfaat dari berbagai arsitektur dan potensi tantangan.

Ringkasan hybrid cloud dan multicloud

Karena workload, infrastruktur, dan proses bersifat unik untuk setiap perusahaan, setiap strategi hybrid cloud harus disesuaikan dengan kebutuhan spesifik Anda. Akibatnya, istilah hybrid cloud dan multicloud terkadang digunakan secara tidak konsisten.

Dalam konteks Google Cloud panduan arsitektur ini, istilah hybrid cloud menjelaskan arsitektur tempat workload di-deploy di beberapa lingkungan komputasi, salah satunya berbasis di cloud publik, dan setidaknya salah satunya pribadi—misalnya, pusat data lokal atau fasilitas colocation.

Istilah multicloud menjelaskan arsitektur yang menggabungkan setidaknya dua CSP publik. Seperti yang diilustrasikan dalam diagram berikut, terkadang arsitektur ini mencakup lingkungan komputasi pribadi (yang mungkin menyertakan penggunaan komponen cloud pribadi). Pengaturan tersebut disebut arsitektur hybrid dan multicloud.

Diagram tiga arsitektur yang dibahas dalam seri ini: hybrid, multicloud, dan campuran arsitektur hybrid dan multicloud.

Kontributor

Penulis: Marwan Al Shawi | Partner Customer Engineer

Kontributor lainnya:

Pemicu, pertimbangan, strategi, dan pendekatan

Dokumen ini menentukan dan membahas tujuan, pendorong, dan persyaratan bisnis, serta bagaimana faktor-faktor ini dapat memengaruhi keputusan desain Anda saat membuat arsitektur hybrid dan multicloud.

Tujuan

Organisasi dapat mengadopsi arsitektur hybrid atau multicloud sebagai solusi permanen untuk memenuhi tujuan bisnis tertentu, atau sebagai status sementara untuk memfasilitasi persyaratan tertentu, seperti migrasi ke cloud.

Menjawab pertanyaan berikut tentang bisnis Anda adalah cara yang baik untuk menentukan persyaratan bisnis, dan menetapkan ekspektasi spesifik tentang cara mencapai sebagian atau semua tujuan bisnis Anda. Pertanyaan ini berfokus pada hal-hal yang diperlukan untuk bisnis Anda, bukan cara mencapainya secara teknis.

  • Sasaran bisnis mana yang mendorong keputusan untuk mengadopsi arsitektur hybrid atau multicloud?
  • Apa tujuan bisnis dan teknis yang akan dicapai dengan arsitektur hybrid atau multicloud?
  • Apa pendorong bisnis yang memengaruhi tujuan ini?
  • Apa persyaratan bisnis spesifiknya?

Dalam konteks arsitektur hybrid dan multi-cloud, salah satu sasaran bisnis untuk pelanggan perusahaan mungkin adalah memperluas operasi penjualan online atau pasar dari satu wilayah untuk menjadi salah satu pemimpin global di segmen pasar mereka. Salah satu tujuan bisnisnya mungkin adalah mulai menerima pesanan pembelian dari pengguna di seluruh dunia (atau dari wilayah tertentu) dalam waktu enam bulan.

Untuk mendukung persyaratan dan tujuan bisnis yang disebutkan sebelumnya, salah satu potensial tujuan teknis utama adalah memperluas infrastruktur IT dan arsitektur aplikasi perusahaan dari model khusus lokal ke arsitektur campuran, menggunakan kemampuan dan layanan global cloud publik. Tujuan ini harus spesifik dan terukur, yang menentukan dengan jelas cakupan ekspansi dalam hal target wilayah dan linimasa.

Secara umum, arsitektur hybrid atau multicloud jarang menjadi tujuan tersendiri, tetapi sebagai sarana untuk memenuhi tujuan teknis yang didorong oleh persyaratan bisnis tertentu. Oleh karena itu, memilih arsitektur hybrid atau multicloud yang tepat memerlukan klarifikasi persyaratan ini terlebih dahulu.

Penting untuk membedakan antara tujuan bisnis dan tujuan teknis project IT Anda. Tujuan bisnis Anda harus berfokus pada sasaran dan misi organisasi Anda. Sasaran teknis Anda harus berfokus pada pembuatan fondasi teknologi yang memungkinkan organisasi Anda memenuhi persyaratan dan sasaran bisnisnya.

Pendorong bisnis memengaruhi pencapaian tujuan dan sasaran bisnis. Oleh karena itu, mengidentifikasi pendorong bisnis dengan jelas dapat membantu membentuk tujuan atau sasaran bisnis agar lebih relevan dengan kebutuhan dan tren pasar.

Diagram alir berikut menggambarkan pendorong, sasaran, tujuan, dan persyaratan bisnis, serta tujuan dan persyaratan teknis, serta hubungan semua faktor ini satu sama lain:

Diagram alur yang menunjukkan hal-hal yang perlu dipertimbangkan saat mengembangkan persyaratan teknis, termasuk pendorong bisnis, sasaran, tujuan, dan persyaratan, serta tujuan teknis.

Pendorong bisnis dan teknis

Pertimbangkan pengaruh pendorong bisnis terhadap tujuan teknis Anda. Beberapa pendorong bisnis umum yang memengaruhi saat memilih arsitektur hybrid meliputi hal-hal berikut:

  • Memperhatikan hukum dan peraturan tentang kedaulatan data.
  • Mengurangi belanja modal (CAPEX) atau pengeluaran IT umum dengan dukungan manajemen keuangan cloud dan disiplin pengoptimalan biaya seperti FinOps.
    • Adopsi cloud dapat didorong oleh skenario yang membantu mengurangi CAPEX, seperti membuat solusi Disaster Recovery dalam arsitektur hybrid atau multi-cloud.
  • Meningkatkan pengalaman pengguna.
  • Meningkatkan fleksibilitas dan ketangkasan untuk merespons perubahan permintaan pasar.
  • Meningkatkan transparansi terkait biaya dan pemakaian resource.

Pertimbangkan daftar pendorong bisnis Anda untuk mengadopsi arsitektur hybrid atau multicloud secara bersamaan. Jangan mempertimbangkannya secara terpisah. Keputusan akhir Anda harus bergantung pada keseimbangan prioritas bisnis Anda.

Setelah menyadari manfaat cloud, organisasi Anda mungkin memutuskan untuk melakukan migrasi sepenuhnya jika tidak ada batasan—seperti biaya atau persyaratan kepatuhan tertentu yang mewajibkan data yang sangat aman untuk dihosting di lokasi—yang mencegahnya melakukannya.

Meskipun menggunakan satu penyedia cloud dapat menawarkan beberapa manfaat, seperti pengurangan kompleksitas, integrasi bawaan di antara layanan, dan opsi pengoptimalan biaya seperti diskon penggunaan terikat, masih ada beberapa skenario saat arsitektur multicloud dapat bermanfaat bagi bisnis. Berikut adalah pendorong bisnis umum untuk mengadopsi arsitektur multi-cloud, beserta pertimbangan terkait untuk setiap pendorong:

  • Mematuhi hukum dan peraturan tentang kedaulatan data: Skenario paling umum adalah saat organisasi memperluas bisnisnya ke wilayah atau negara baru dan harus mematuhi peraturan hosting data baru.
    • Jika penyedia layanan cloud (CSP) yang ada dan digunakan tidak memiliki region cloud lokal di negara tersebut, maka untuk tujuan kepatuhan, solusi umum adalah menggunakan CSP lain yang memiliki region cloud lokal di negara tersebut.
  • Mengurangi biaya: Pengurangan biaya sering kali menjadi pendorong bisnis paling umum untuk mengadopsi teknologi atau arsitektur. Namun, penting untuk mempertimbangkan lebih dari sekadar biaya layanan dan potensi diskon harga saat memutuskan apakah akan mengadopsi arsitektur multicloud. Perhitungkan biaya pembuatan dan pengoperasian solusi di beberapa cloud, serta kendala arsitektur apa pun yang mungkin timbul dari sistem yang ada.

Terkadang, potensi tantangan yang terkait dengan strategi multicloud mungkin lebih besar daripada manfaatnya. Strategi multi-cloud mungkin akan menimbulkan biaya tambahan di lain waktu.

Tantangan umum yang terkait dengan pengembangan strategi multi-cloud meliputi hal-hal berikut:

  • Meningkatkan kompleksitas pengelolaan.
  • Mempertahankan keamanan yang konsisten.
  • Mengintegrasikan lingkungan software.
  • Mencapai performa dan keandalan lintas cloud yang konsisten.
  • Membuat tim teknis dengan keterampilan multi-cloud mungkin mahal dan mungkin memerlukan perluasan tim, kecuali jika dikelola oleh perusahaan pihak ketiga.
  • Mengelola harga produk dan alat pengelolaan dari setiap CSP.
  • Menggunakan kemampuan unik dari setiap CSP: Arsitektur multicloud memungkinkan organisasi menggunakan teknologi baru tambahan untuk meningkatkan penawaran kemampuan bisnis mereka sendiri tanpa dibatasi oleh pilihan yang ditawarkan oleh satu penyedia cloud.
    • Untuk menghindari risiko atau kompleksitas yang tidak terduga, nilai potensi tantangan Anda melalui penilaian kelayakan dan efektivitas, termasuk tantangan umum yang disebutkan sebelumnya.
  • Menghindari ketergantungan pada vendor: Terkadang, perusahaan ingin menghindari terikat dengan satu penyedia cloud. Dengan pendekatan multicloud, mereka dapat memilih solusi terbaik untuk kebutuhan bisnis mereka. Namun, kelayakan keputusan ini bergantung pada beberapa faktor, seperti berikut:
    • Dependensi teknis
    • Pertimbangan interoperabilitas antar-aplikasi
    • Biaya membangun ulang atau memfaktorkan ulang aplikasi
    • Kumpulan keterampilan teknis
    • Keamanan dan pengelolaan yang konsisten
  • Meningkatkan tingkat keandalan dan ketersediaan aplikasi penting bagi bisnis: Dalam beberapa skenario, arsitektur multicloud dapat memberikan ketahanan terhadap pemadaman layanan. Misalnya, jika satu region CSP mengalami gangguan, traffic dapat dirutekan ke CSP lain di region yang sama. Skenario ini menganggap bahwa kedua penyedia cloud mendukung kemampuan atau layanan yang diperlukan di wilayah tersebut.

Jika peraturan residensi data di negara atau wilayah tertentu mewajibkan penyimpanan data sensitif—seperti informasi identitas pribadi (PII)—dalam lokasi tersebut, pendekatan multi-cloud dapat memberikan solusi yang mematuhi peraturan. Dengan menggunakan dua CSP di satu region untuk memberikan ketahanan terhadap pemadaman, Anda dapat memfasilitasi kepatuhan terhadap pembatasan peraturan sekaligus menangani persyaratan ketersediaan.

Berikut adalah beberapa pertimbangan ketahanan yang perlu dinilai sebelum menggunakan arsitektur multi-cloud:

  • Pergerakan data: Seberapa sering data berpindah dalam lingkungan multicloud Anda?
    • Apakah pemindahan data akan menimbulkan biaya transfer data yang signifikan?
  • Keamanan dan pengelolaan: Apakah ada potensi kompleksitas keamanan atau pengelolaan?
  • Paritas kemampuan: Apakah kedua CSP di region yang dipilih menawarkan kemampuan dan layanan yang diperlukan?
  • Kumpulan keterampilan teknis: Apakah tim teknis memiliki keterampilan yang diperlukan untuk mengelola arsitektur multicloud?

Pertimbangkan semua faktor ini saat menilai kelayakan penggunaan arsitektur multi-cloud untuk meningkatkan ketahanan.

Saat menilai kelayakan arsitektur multicloud, penting untuk mempertimbangkan manfaat jangka panjangnya. Misalnya, men-deploy aplikasi di beberapa cloud untuk pemulihan dari bencana atau peningkatan keandalan dapat memperbesar biaya dalam jangka pendek, tetapi dapat mencegah pemadaman layanan atau kegagalan. Kegagalan tersebut dapat menyebabkan kerusakan keuangan dan reputasi jangka panjang. Oleh karena itu, penting untuk mempertimbangkan biaya jangka pendek terhadap nilai potensial jangka panjang pengadopsian multicloud. Selain itu, nilai potensial jangka panjang dapat bervariasi berdasarkan ukuran organisasi, skala teknologi, tingkat kepentingan solusi teknologi, dan industri.

Organisasi yang berencana untuk berhasil membuat lingkungan hybrid atau multi-cloud, harus mempertimbangkan untuk membuat Cloud Center of Excellence (COE). Tim COE dapat menjadi saluran untuk mengubah cara tim internal dalam organisasi Anda melayani bisnis selama transisi ke cloud. COE adalah salah satu cara organisasi Anda dapat menerapkan cloud dengan lebih cepat, mendorong standardisasi, dan mempertahankan penyelarasan yang lebih kuat antara strategi bisnis dan investasi cloud Anda.

Jika tujuan arsitektur hybrid atau multicloud adalah untuk membuat status sementara, pendorong bisnis umum meliputi:

  • Kebutuhan untuk mengurangi CAPEX atau pengeluaran IT umum untuk project jangka pendek.
  • Kemampuan untuk menyediakan infrastruktur tersebut dengan cepat untuk mendukung kasus penggunaan bisnis. Contoh:
    • Arsitektur ini dapat digunakan untuk project berbatas waktu. Layanan ini dapat digunakan untuk mendukung project yang memerlukan infrastruktur terdistribusi berskala tinggi dalam durasi terbatas, sambil tetap menggunakan data yang ada di lokasi.
  • Kebutuhan akan project transformasi digital multi-tahun yang mengharuskan perusahaan besar untuk membangun dan menggunakan arsitektur hybrid selama beberapa waktu untuk membantu mereka menyelaraskan modernisasi infrastruktur dan aplikasi dengan prioritas bisnis mereka.
  • Kebutuhan untuk membuat arsitektur hybrid, multicloud, atau campuran sementara setelah penggabungan perusahaan. Dengan demikian, organisasi baru dapat menentukan strategi untuk status akhir arsitektur cloud barunya. Biasanya, dua perusahaan yang bergabung menggunakan penyedia cloud yang berbeda, atau satu perusahaan menggunakan pusat data pribadi di lokasi sendiri dan perusahaan lainnya menggunakan cloud. Dalam kedua kasus tersebut, langkah pertama dalam penggabungan dan akuisisi hampir selalu adalah mengintegrasikan sistem IT.

Pendorong teknis

Bagian sebelumnya membahas faktor pendorong bisnis. Agar disetujui, keputusan arsitektur utama hampir selalu memerlukan dukungan dari driver tersebut. Namun, driver teknis, yang dapat didasarkan pada keuntungan teknis atau batasan, juga dapat memengaruhi driver bisnis. Dalam beberapa skenario, Anda harus menerjemahkan driver teknis menjadi driver bisnis dan menjelaskan bagaimana driver tersebut dapat memengaruhi bisnis secara positif atau negatif.

Daftar tidak lengkap berikut berisi beberapa pendorong teknis umum untuk menggunakan arsitektur hybrid atau multicloud:

  • Membangun kemampuan teknologi, seperti layanan analisis lanjutan dan AI, yang mungkin sulit diterapkan di lingkungan yang sudah ada.
  • Meningkatkan kualitas dan performa layanan.
  • Mengotomatiskan dan mempercepat peluncuran aplikasi untuk mencapai waktu penyiapan produk yang lebih cepat dan waktu siklus yang lebih singkat.
  • Menggunakan API dan layanan tingkat tinggi untuk mempercepat pengembangan.
  • Mempercepat penyediaan resource komputasi dan penyimpanan.
  • Menggunakan layanan serverless untuk membuat layanan dan kemampuan elastis lebih cepat dan dalam skala besar.
  • Menggunakan kemampuan infrastruktur global untuk membuat arsitektur global atau multi-regional guna memenuhi persyaratan teknis tertentu.

Pendorong teknis yang paling umum untuk arsitektur hybrid sementara dan arsitektur multicloud sementara adalah untuk memfasilitasi migrasi dari infrastruktur lokal ke cloud atau ke cloud tambahan. Secara umum, migrasi cloud hampir selalu mengarah ke penyiapan hybrid cloud secara alami. Perusahaan sering kali harus mentransisikan aplikasi dan data secara sistematis berdasarkan prioritas mereka. Demikian pula, penyiapan jangka pendek mungkin dimaksudkan untuk memfasilitasi bukti konsep menggunakan teknologi canggih yang tersedia di cloud selama jangka waktu tertentu.

Keputusan desain teknis

Tujuan teknis yang diidentifikasi dan penggeraknya adalah kunci untuk membuat keputusan arsitektur yang berorientasi pada bisnis dan memilih salah satu pola arsitektur yang dibahas dalam panduan ini. Misalnya, untuk mendukung tujuan bisnis tertentu, perusahaan dapat menetapkan tujuan bisnis untuk membangun praktik riset dan pengembangan selama tiga hingga enam bulan. Persyaratan bisnis utama untuk mendukung tujuan ini mungkin adalah membangun lingkungan teknologi yang diperlukan untuk riset dan desain dengan CAPEX serendah mungkin.

Tujuan teknis dalam hal ini adalah memiliki penyiapan hybrid cloud sementara. Pendorong untuk tujuan teknis ini adalah memanfaatkan model penetapan harga cloud on-demand untuk memenuhi persyaratan bisnis yang disebutkan sebelumnya. Pemicu lainnya dipengaruhi oleh persyaratan teknologi tertentu yang memerlukan solusi berbasis cloud dengan kapasitas komputasi tinggi dan penyiapan cepat.

Menggunakan Google Cloud untuk arsitektur hybrid dan multicloud

Penggunaan solusi open source dapat mempermudah penerapan pendekatan hybrid dan multicloud, serta meminimalkan keterikatan dengan vendor. Namun, Anda harus mempertimbangkan kompleksitas potensial berikut saat merencanakan arsitektur:

  • Interoperabilitas
  • Kemudahan dikelola
  • Biaya
  • Keamanan

Membangun di platform cloud yang berkontribusi dan mendukung open source dapat membantu menyederhanakan jalur Anda untuk mengadopsi arsitektur hybrid dan multicloud. Open cloud memberdayakan Anda dengan pendekatan yang memberikan pilihan maksimum dan mengabstraksi kompleksitas. Selain itu, Google Cloud menawarkan fleksibilitas untuk memigrasikan, mem-build, dan mengoptimalkan aplikasi di seluruh lingkungan hybrid dan multicloud sekaligus meminimalkan keterikatan pada vendor, menggunakan solusi terbaik, dan memenuhi persyaratan peraturan.

Google juga merupakan salah satu kontributor terbesar pada ekosistem open source dan bekerja sama dengan komunitas open source untuk mengembangkan teknologi open source terkenal seperti Kubernetes. Saat diluncurkan sebagai layanan terkelola, Kubernetes dapat membantu mengurangi kompleksitas seputar keamanan dan pengelolaan hybrid dan multicloud.

Merencanakan strategi hybrid dan multicloud

Dokumen ini berfokus pada cara menerapkan pertimbangan bisnis yang telah ditentukan saat merencanakan strategi hybrid dan multicloud. Panduan ini memperluas panduan dalam Pemicu, pertimbangan, strategi, dan pendekatan. Artikel tersebut mendefinisikan dan menganalisis pertimbangan bisnis yang harus diperhitungkan perusahaan saat merencanakan strategi tersebut.

Memperjelas dan menyepakati visi dan tujuan

Pada akhirnya, tujuan utama strategi hybrid atau multicloud adalah untuk mencapai persyaratan bisnis yang diidentifikasi dan tujuan teknis terkait untuk setiap kasus penggunaan bisnis yang selaras dengan tujuan bisnis tertentu. Untuk mencapai tujuan ini, buat rencana yang terstruktur dengan baik yang mencakup pertimbangan berikut:

Pahami bahwa menentukan rencana yang mempertimbangkan semua workload dan persyaratan pasti sulit dilakukan, terutama dalam lingkungan IT yang kompleks. Selain itu, perencanaan memerlukan waktu dan dapat menimbulkan persaingan visi pemangku kepentingan.

Untuk menghindari situasi tersebut, awalnya buat pernyataan visi yang menjawab pertanyaan-pertanyaan berikut (minimal):

  • Apa kasus penggunaan bisnis yang ditargetkan untuk memenuhi tujuan bisnis tertentu?
  • Mengapa pendekatan dan lingkungan komputasi saat ini tidak memadai untuk memenuhi tujuan bisnis?
  • Apa aspek teknologi utama yang perlu dioptimalkan dengan menggunakan cloud publik?
  • Mengapa dan bagaimana pendekatan baru ini akan mengoptimalkan dan memenuhi tujuan bisnis Anda?
  • Berapa lama Anda berencana menggunakan penyiapan hybrid atau multicloud?

Menyetujui tujuan dan pendorong bisnis dan teknis utama, lalu mendapatkan persetujuan dari pemangku kepentingan yang relevan dapat memberikan dasar untuk langkah-langkah berikutnya dalam proses perencanaan. Untuk menyelaraskan solusi yang Anda usulkan dengan visi arsitektur menyeluruh organisasi Anda secara efektif, selaraskan dengan tim dan pemangku kepentingan yang bertanggung jawab untuk memimpin dan mensponsori inisiatif ini.

Mengidentifikasi dan mengklarifikasi pertimbangan lainnya

Saat merencanakan arsitektur hybrid atau multicloud, penting untuk mengidentifikasi dan menyepakati batasan arsitektur dan operasional project Anda.

Di sisi operasi, daftar tidak lengkap berikut memberikan beberapa persyaratan yang mungkin menimbulkan beberapa batasan yang perlu dipertimbangkan saat merencanakan arsitektur Anda:

  • Mengelola dan mengonfigurasi beberapa cloud secara terpisah versus membuat model menyeluruh untuk mengelola dan mengamankan berbagai lingkungan cloud.
  • Memastikan autentikasi, otorisasi, audit, dan kebijakan yang konsisten di seluruh lingkungan.
  • Menggunakan alat dan proses yang konsisten di seluruh lingkungan untuk memberikan tampilan menyeluruh tentang keamanan, biaya, dan peluang untuk pengoptimalan.
  • Menggunakan standar kepatuhan dan keamanan yang konsisten untuk menerapkan tata kelola terpadu.

Di sisi perencanaan arsitektur, batasan terbesar sering kali berasal dari sistem yang ada dan dapat mencakup hal berikut:

  • Dependensi antar-aplikasi
  • Persyaratan performa dan latensi untuk komunikasi antar-sistem
  • Mengandalkan hardware atau sistem operasi yang mungkin tidak tersedia di cloud publik
  • Pembatasan pemberian lisensi
  • Ketergantungan pada ketersediaan kemampuan yang diperlukan di region yang dipilih dari arsitektur multicloud

Untuk informasi selengkapnya tentang pertimbangan lain yang terkait dengan aspek keamanan, pemosisi ulang data, dan portabilitas workload, lihat Pertimbangan lainnya.

Mendesain strategi arsitektur hybrid dan multicloud

Setelah Anda mengklarifikasi detail tujuan bisnis dan teknis dengan persyaratan bisnis terkait (dan idealnya mengklarifikasi dan menyepakati pernyataan visi), Anda dapat membuat strategi untuk membuat arsitektur hybrid atau multicloud.

Diagram alir berikut merangkum langkah-langkah logis untuk membuat strategi tersebut.

Saat menyusun strategi, pertimbangkan tujuan bisnis Anda, dapatkan dukungan, buat rencana tingkat tinggi, lalu gunakan rencana tersebut untuk menentukan strategi Anda.

Untuk membantu Anda menentukan tujuan dan kebutuhan teknis arsitektur hybrid atau multicloud, langkah-langkah dalam diagram alir sebelumnya dimulai dengan persyaratan dan tujuan bisnis. Cara Anda menerapkan strategi dapat bervariasi bergantung pada tujuan, pendorong, dan jalur migrasi teknologi setiap kasus penggunaan bisnis.

Penting untuk diingat bahwa migrasi adalah sebuah perjalanan. Diagram berikut menggambarkan fase perjalanan ini seperti yang dijelaskan dalam Bermigrasi ke Google Cloud.

Jalur migrasi dengan empat fase.

Bagian ini memberikan panduan tentang fase "Assess", "Plan", "Deploy", dan "Optimize" dalam diagram sebelumnya. Laporan ini menyajikan informasi ini dalam konteks migrasi hybrid atau multicloud. Anda harus menyelaraskan migrasi apa pun dengan panduan dan praktik terbaik yang dibahas di bagian jalur migrasi panduan Bermigrasi ke Google Cloud . Fase ini mungkin berlaku untuk setiap workload satu per satu, bukan untuk semua workload sekaligus. Pada waktu tertentu, beberapa workload mungkin berada dalam fase yang berbeda:

Fase penilaian

Pada fase Penilaian, Anda melakukan penilaian workload awal. Selama fase ini, pertimbangkan sasaran yang diuraikan dalam dokumen perencanaan strategi dan visi Anda. Tentukan rencana migrasi dengan terlebih dahulu mengidentifikasi daftar kandidat workload yang dapat menerima manfaat dari deployment atau migrasi ke cloud publik.

Untuk memulai, pilih beban kerja yang tidak terlalu penting bagi bisnis atau terlalu sulit untuk dimigrasikan (dengan dependensi minimal atau tidak ada pada beban kerja apa pun di lingkungan lain), tetapi cukup umum untuk dijadikan sebagai cetak biru bagi deployment atau migrasi mendatang.

Idealnya, beban kerja atau aplikasi yang Anda pilih harus menjadi bagian dari kasus penggunaan atau fungsi bisnis yang ditargetkan yang memiliki efek yang dapat diukur pada bisnis setelah selesai.

Untuk mengevaluasi dan memitigasi potensi risiko migrasi, lakukan penilaian risiko migrasi. Anda harus menilai workload kandidat untuk menentukan kesesuaiannya untuk dimigrasikan ke lingkungan multi-cloud. Penilaian ini melibatkan evaluasi berbagai aspek aplikasi dan infrastruktur, termasuk hal berikut:

  • Persyaratan kompatibilitas aplikasi dengan penyedia cloud yang Anda pilih
  • Model penetapan harga
  • Fitur keamanan yang ditawarkan oleh penyedia cloud yang Anda pilih
  • Persyaratan interoperabilitas aplikasi

Menjalankan penilaian juga membantu Anda mengidentifikasi persyaratan privasi data, persyaratan kepatuhan, persyaratan konsistensi, dan solusi di beberapa lingkungan cloud. Risiko yang Anda identifikasi dapat memengaruhi workload yang Anda pilih untuk dimigrasikan atau dioperasikan.

Ada beberapa jenis alat, seperti Pusat Migrasi Google Cloud, untuk membantu Anda menilai workload yang ada. Untuk informasi selengkapnya, lihat Migrasi ke Google Cloud: Memilih alat penilaian.

Dari perspektif modernisasi beban kerja, alat penilaian kesesuaian membantu menilai beban kerja VM untuk menentukan apakah beban kerja tersebut sesuai untuk modernisasi ke penampung atau untuk migrasi ke Compute Engine.

Fase perencanaan

Pada fase Rencanakan, mulailah dengan aplikasi yang diidentifikasi dan workload cloud yang diperlukan, lalu lakukan tugas berikut:

  1. Kembangkan strategi migrasi yang diprioritaskan yang menentukan gelombang migrasi aplikasi dan jalur.
  2. Identifikasi pola arsitektur aplikasi hybrid atau multicloud tingkat tinggi yang berlaku.
  3. Pilih pola arsitektur jaringan yang mendukung pola arsitektur aplikasi yang dipilih.

Idealnya, Anda harus menggabungkan pola jaringan cloud dengan desain zona landing. Desain zona landing berfungsi sebagai elemen dasar utama dari keseluruhan arsitektur hybrid dan multicloud. Desain memerlukan integrasi yang lancar dengan pola ini. Jangan mendesain zona landing secara terpisah. Pertimbangkan pola jaringan ini sebagai subset dari desain zona landing.

Zona landing mungkin terdiri dari aplikasi yang berbeda, masing-masing dengan pola arsitektur jaringan yang berbeda. Selain itu, dalam fase ini, penting untuk menentukan desain Google Cloud organisasi, project, dan hierarki resource untuk menyiapkan zona landing lingkungan cloud Anda bagi integrasi dan deployment hybrid atau multicloud.

Sebagai bagian dari fase ini, Anda harus mempertimbangkan hal-hal berikut:

  • Tentukan pendekatan migrasi dan modernisasi. Ada informasi selengkapnya tentang pendekatan migrasi nanti dalam panduan ini. Hal ini juga dibahas secara lebih mendetail di bagian jenis migrasi di Migrasi ke Google Cloud.
  • Gunakan temuan fase penilaian dan penemuan Anda. Sesuaikan dengan beban kerja kandidat yang ingin Anda migrasikan. Kemudian, kembangkan rencana gelombang migrasi aplikasi. Rencana harus menyertakan perkiraan persyaratan ukuran resource yang Anda tentukan selama fase penilaian.
  • Tentukan model komunikasi yang diperlukan antara aplikasi terdistribusi dan di antara komponen aplikasi untuk arsitektur hybrid atau multicloud yang diinginkan.
  • Tentukan arketipe deployment yang sesuai untuk men-deploy workload Anda, seperti zonal, regional, multi-regional, atau global, untuk pola arsitektur yang dipilih. Archetype yang Anda pilih membentuk dasar untuk membuat arsitektur deployment khusus aplikasi yang disesuaikan dengan kebutuhan bisnis dan teknis Anda.
  • Tentukan kriteria keberhasilan yang dapat diukur untuk migrasi, dengan tonggak pencapaian yang jelas untuk setiap fase atau gelombang migrasi. Memilih kriteria sangat penting, meskipun tujuan teknisnya adalah memiliki arsitektur campuran sebagai penyiapan jangka pendek.
  • Tentukan SLA dan KPI aplikasi saat aplikasi Anda beroperasi dalam penyiapan hybrid, terutama untuk aplikasi yang mungkin memiliki komponen terdistribusi di beberapa lingkungan.

Untuk informasi selengkapnya, lihat Tentang perencanaan migrasi untuk membantu merencanakan migrasi yang sukses dan meminimalkan risiko terkait.

Tahap deployment

Pada fase Deploy, Anda siap untuk mulai menjalankan strategi migrasi. Mengingat potensi jumlah persyaratan, sebaiknya gunakan pendekatan berulang.

Prioritaskan workload Anda berdasarkan gelombang migrasi dan aplikasi yang Anda kembangkan selama fase perencanaan. Dengan arsitektur hybrid dan multicloud, mulai deployment Anda dengan membangun konektivitas yang diperlukan antara Google Cloud dan lingkungan komputasi lainnya. Untuk memfasilitasi model komunikasi yang diperlukan untuk arsitektur hybrid atau multicloud, dasarkan deployment pada desain dan jenis konektivitas jaringan yang Anda pilih, beserta pola jaringan yang berlaku. Sebaiknya Anda menggunakan pendekatan ini untuk keputusan desain zona landing secara keseluruhan.

Selain itu, Anda harus menguji dan memvalidasi aplikasi atau layanan berdasarkan kriteria keberhasilan aplikasi yang ditentukan. Idealnya, kriteria ini harus mencakup persyaratan pengujian fungsional dan pengujian beban (non-fungsional) sebelum beralih ke produksi.

Fase pengoptimalan

Pada fase Optimalkan, uji deployment Anda: Setelah menyelesaikan pengujian, dan aplikasi atau layanan memenuhi ekspektasi kapasitas fungsional dan performa, Anda dapat memindahkannya ke produksi. Alat visibilitas dan pemantauan cloud, seperti Cloud Monitoring, dapat memberikan insight tentang performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda, serta membantu Anda mengoptimalkannya jika diperlukan.

Untuk informasi selengkapnya, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda. Untuk mempelajari lebih lanjut cara mendesain alat tersebut untuk arsitektur hybrid atau multicloud, lihat Pola pemantauan dan logging hybrid dan multicloud.

Menilai workload kandidat

Pilihan lingkungan komputasi untuk berbagai workload secara signifikan memengaruhi kesuksesan strategi hybrid dan multicloud. Keputusan penempatan workload harus selaras dengan tujuan bisnis tertentu. Oleh karena itu, keputusan ini harus dipandu oleh kasus penggunaan bisnis yang ditargetkan yang memungkinkan efek bisnis yang terukur. Namun, memulai dengan beban kerja/aplikasi yang paling penting bagi bisnis tidak selalu diperlukan atau direkomendasikan. Untuk informasi selengkapnya, lihat Memilih aplikasi yang akan dimigrasikan terlebih dahulu dalam panduan Memigrasikan ke Google Cloud .

Seperti yang telah dibahas di bagian Pemacu bisnis dan teknis, ada berbagai jenis pemicu dan pertimbangan untuk arsitektur hybrid dan multicloud.

Daftar ringkasan faktor berikut dapat membantu Anda mengevaluasi kasus penggunaan migrasi dalam konteks arsitektur hybrid atau multicloud dengan peluang untuk memiliki dampak bisnis yang terukur:

  • Potensi diferensiasi atau inovasi pasar yang diwujudkan dengan menggunakan layanan cloud untuk mengaktifkan fungsi atau kemampuan bisnis tertentu, seperti kemampuan kecerdasan buatan yang menggunakan data lokal yang ada untuk melatih model machine learning.
  • Potensi penghematan total biaya kepemilikan untuk aplikasi.
  • Potensi peningkatan dalam ketersediaan, ketahanan, keamanan, atau performa—misalnya, menambahkan situs pemulihan dari bencana (DR) di cloud.
  • Potensi percepatan proses pengembangan dan rilis—misalnya, mem-build lingkungan pengembangan dan pengujian di cloud.

Faktor-faktor berikut dapat membantu Anda mengevaluasi risiko migrasi:

  • Potensi dampak pemadaman layanan yang disebabkan oleh migrasi.
  • Pengalaman tim Anda dengan deployment cloud publik, atau dengan deployment untuk penyedia cloud baru atau kedua.
  • Kebutuhan untuk mematuhi pembatasan hukum atau peraturan yang sudah ada.

Faktor-faktor berikut dapat membantu Anda mengevaluasi kesulitan teknis migrasi:

  • Ukuran, kompleksitas, dan usia aplikasi.
  • Jumlah dependensi dengan aplikasi dan layanan lain di berbagai lingkungan komputasi.
  • Batasan apa pun yang diberlakukan oleh lisensi pihak ketiga.
  • Dependensi pada versi tertentu dari sistem operasi, database, atau konfigurasi lingkungan lainnya.

Setelah menilai workload awal, Anda dapat mulai memprioritaskannya dan menentukan gelombang migrasi dan pendekatan. Kemudian, Anda dapat mengidentifikasi pola arsitektur yang berlaku dan pola jaringan pendukung. Langkah ini mungkin memerlukan beberapa iterasi, karena penilaian Anda dapat berubah dari waktu ke waktu. Oleh karena itu, ada baiknya mengevaluasi kembali workload setelah Anda melakukan deployment cloud pertama kali.

Pendekatan arsitektur untuk mengadopsi arsitektur hybrid atau multicloud

Dokumen ini memberikan panduan tentang pendekatan dan pertimbangan umum serta yang telah terbukti untuk memigrasikan workload Anda ke cloud. Artikel ini memperluas panduan dalam Mendesain strategi arsitektur hybrid dan multicloud, yang membahas beberapa kemungkinan, dan langkah yang direkomendasikan, untuk mendesain strategi guna mengadopsi arsitektur hybrid atau multicloud.

Cloud-first

Cara umum untuk mulai menggunakan cloud publik adalah pendekatan cloud-first. Dalam pendekatan ini, Anda men-deploy workload baru ke cloud publik, sementara workload yang ada tetap berada di tempatnya. Dalam hal ini, pertimbangkan deployment klasik ke lingkungan komputasi pribadi hanya jika deployment cloud publik tidak dapat dilakukan karena alasan teknis atau organisasi.

Strategi cloud-first memiliki kelebihan dan kekurangan. Sisi positifnya, adalah fokus pada masa depan. Anda dapat men-deploy workload baru dengan cara yang dimodernisasi sekaligus menghindari (atau setidaknya meminimalkan) kerepotan memigrasikan workload yang sudah ada.

Meskipun pendekatan cloud-first dapat memberikan keuntungan tertentu, pendekatan ini dapat berpotensi menyebabkan peluang untuk meningkatkan atau menggunakan workload yang ada terlewatkan. Workload baru mungkin mewakili sebagian dari keseluruhan lanskap IT, dan pengaruhnya terhadap pengeluaran dan performa IT dapat terbatas. Mengalokasikan waktu dan resource untuk memigrasikan workload yang ada berpotensi menghasilkan manfaat atau penghematan biaya yang lebih substansial dibandingkan dengan mencoba mengakomodasi workload baru di lingkungan cloud.

Menerapkan pendekatan cloud-first yang ketat juga berisiko meningkatkan kompleksitas lingkungan IT Anda secara keseluruhan. Pendekatan ini dapat menimbulkan redundansi, performa yang lebih rendah karena potensi komunikasi lintas-lingkungan yang berlebihan, atau menghasilkan lingkungan komputasi yang tidak cocok untuk workload individual. Selain itu, kepatuhan terhadap peraturan industri dan hukum privasi data dapat membatasi perusahaan untuk memigrasikan aplikasi tertentu yang menyimpan data sensitif.

Dengan mempertimbangkan risiko ini, sebaiknya Anda menggunakan pendekatan cloud-first hanya untuk workload tertentu. Dengan menggunakan pendekatan cloud-first, Anda dapat berkonsentrasi pada workload yang dapat mendapatkan manfaat terbesar dari migrasi atau deployment cloud. Pendekatan ini juga mempertimbangkan modernisasi workload yang sudah ada.

Contoh umum arsitektur hybrid cloud-first adalah saat aplikasi dan layanan lama yang menyimpan data penting harus diintegrasikan dengan data atau aplikasi baru. Untuk menyelesaikan integrasi, Anda dapat menggunakan arsitektur hibrida yang memodernisasi layanan lama dengan menggunakan antarmuka API, yang memungkinkan layanan tersebut digunakan oleh layanan dan aplikasi cloud baru. Dengan platform pengelolaan API cloud, seperti Apigee, Anda dapat menerapkan kasus penggunaan tersebut dengan perubahan aplikasi minimal dan menambahkan keamanan, analisis, dan skalabilitas ke layanan lama.

Migrasi dan modernisasi

Modernisasi IT dan multicloud hybrid adalah konsep berbeda yang saling terkait dalam lingkaran kebaikan. Penggunaan cloud publik dapat memfasilitasi dan menyederhanakan modernisasi workload IT. Modernisasi workload IT dapat membantu Anda mendapatkan lebih banyak manfaat dari cloud.

Tujuan utama modernisasi workload adalah sebagai berikut:

  • Mencapai fleksibilitas yang lebih baik sehingga Anda dapat beradaptasi dengan persyaratan yang berubah.
  • Mengurangi biaya infrastruktur dan operasi.
  • Meningkatkan keandalan dan ketahanan untuk meminimalkan risiko.

Namun, mungkin tidak memungkinkan untuk memodernisasi setiap aplikasi dalam proses migrasi secara bersamaan. Seperti yang dijelaskan dalam Migrasi ke Google Cloud, Anda dapat menerapkan salah satu jenis migrasi berikut, atau bahkan menggabungkan beberapa jenis sesuai kebutuhan:

  • Menghosting ulang (lift-and-shift)
  • Mengalihkan ke platform baru (meningkatkan dan mengoptimalkan)
  • Memfaktorkan ulang (move-and-improve)
  • Merancang ulang (melanjutkan modernisasi)
  • Build ulang (remove and replace, terkadang disebut rip and replace)
  • Pembelian ulang

Saat membuat keputusan strategis tentang arsitektur hybrid dan multicloud, penting untuk mempertimbangkan kelayakan strategi Anda dari perspektif biaya dan waktu. Sebaiknya pertimbangkan pendekatan migrasi bertahap, dimulai dengan lift-and-shift atau replatforming, lalu memfaktorkan ulang atau merancang ulang sebagai langkah berikutnya. Biasanya, lift-and-shift membantu mengoptimalkan aplikasi dari perspektif infrastruktur. Setelah aplikasi berjalan di cloud, akan lebih mudah untuk menggunakan dan mengintegrasikan layanan cloud guna mengoptimalkannya lebih lanjut menggunakan arsitektur dan kemampuan cloud-first. Selain itu, aplikasi ini masih dapat berkomunikasi dengan lingkungan lain melalui koneksi jaringan hybrid.

Misalnya, Anda dapat memfaktorkan ulang atau merancang ulang aplikasi berbasis VM monolitik yang besar dan mengubahnya menjadi beberapa microservice independen, berdasarkan arsitektur microservice berbasis cloud. Dalam contoh ini, arsitektur microservice menggunakan Google Cloud layanan penampung terkelola seperti Google Kubernetes Engine (GKE) atau Cloud Run. Namun, jika arsitektur atau infrastruktur aplikasi tidak didukung di lingkungan cloud target sebagaimana adanya, Anda dapat mempertimbangkan untuk memulai dengan membuat ulang platform, memfaktorkan ulang, atau mendesain ulang strategi migrasi untuk mengatasi batasan tersebut jika memungkinkan.

Saat menggunakan salah satu pendekatan migrasi ini, pertimbangkan untuk memodernisasi aplikasi Anda (jika berlaku dan memungkinkan). Modernisasi dapat memerlukan penerapan dan penerapan Site Reliability Engineering (SRE) atau prinsip DevOps, sehingga Anda mungkin juga perlu memperluas modernisasi aplikasi ke lingkungan pribadi dalam penyiapan campuran. Meskipun menerapkan prinsip SRE melibatkan inti engineering, hal ini lebih merupakan proses transformasi daripada tantangan teknis. Oleh karena itu, hal ini kemungkinan akan memerlukan perubahan prosedural dan budaya. Untuk mempelajari lebih lanjut bagaimana langkah pertama untuk menerapkan SRE di organisasi adalah mendapatkan dukungan dari para pemimpin, lihat Dengan SRE, gagal merencanakan berarti merencanakan kegagalan.

Memadukan pendekatan migrasi

Setiap pendekatan migrasi yang dibahas di sini memiliki kekuatan dan kelemahan tertentu. Keuntungan utama mengikuti strategi hybrid dan multicloud adalah Anda tidak perlu mengandalkan satu pendekatan saja. Sebagai gantinya, Anda dapat memutuskan pendekatan mana yang paling cocok untuk setiap workload atau stack aplikasi, seperti yang ditunjukkan dalam diagram berikut.

Diagram alir yang menunjukkan berbagai pendekatan untuk memigrasikan beban kerja dari lingkungan cloud Anda.

Diagram konseptual ini mengilustrasikan berbagai jalur atau pendekatan migrasi dan modernisasi yang dapat diterapkan secara bersamaan ke berbagai beban kerja, yang didorong oleh bisnis yang unik, persyaratan teknis, dan tujuan dari setiap beban kerja atau aplikasi.

Selain itu, komponen stack aplikasi yang sama tidak perlu mengikuti pendekatan atau strategi migrasi yang sama. Contoh:

  • Database backend on-premise aplikasi dapat di-replatform dari MySQL yang dihosting sendiri ke database terkelola menggunakan Cloud SQL di Google Cloud.
  • Virtual machine frontend aplikasi dapat difaktorkan ulang untuk berjalan di penampung menggunakan GKE Autopilot, tempat Google mengelola konfigurasi cluster, termasuk node, penskalaan, keamanan, dan setelan lainnya yang telah dikonfigurasi sebelumnya.
  • Solusi load balancing hardware on-premise dan kemampuan WAF firewall aplikasi web dapat diganti dengan Cloud Load Balancing dan Google Cloud Armor.

Pilih hosting ulang (lift-and-shift), jika salah satu kondisi berikut berlaku untuk workload:

  • Workload memiliki jumlah dependensi yang relatif kecil di lingkungannya.
  • Workload tidak dianggap pantas untuk difaktorkan ulang, atau pemfaktoran ulang sebelum migrasi tidak memungkinkan.
  • Workload didasarkan pada software pihak ketiga.

Pertimbangkan untuk memfaktorkan ulang (pindahkan dan tingkatkan) untuk jenis workload berikut:

  • Workload memiliki dependensi yang harus diuraikan.
  • Workload mengandalkan sistem operasi, hardware, atau sistem database yang tidak dapat diakomodasi di cloud.
  • Workload tidak memanfaatkan resource komputasi atau penyimpanan secara efisien.
  • Workload tidak dapat di-deploy secara otomatis tanpa upaya tertentu.

Pertimbangkan apakah build ulang (hapus dan ganti) memenuhi kebutuhan Anda untuk jenis workload berikut:

  • Workload tidak lagi memenuhi persyaratan saat ini.
  • Aplikasi ini dapat digabungkan dengan aplikasi lain yang menyediakan kemampuan serupa tanpa mengorbankan persyaratan bisnis.
  • Workload didasarkan pada teknologi pihak ketiga yang telah mencapai akhir siklus prosesnya.
  • Workload memerlukan biaya lisensi pihak ketiga yang tidak lagi ekonomis.

Rapid Migration Program menunjukkan cara Google Cloud membantu pelanggan menggunakan praktik terbaik, menurunkan risiko, mengontrol biaya, dan menyederhanakan langkah-langkah mereka untuk meraih kesuksesan di bidang cloud.

Pertimbangan lainnya

Dokumen ini menyoroti pertimbangan desain inti yang memainkan peran penting dalam membentuk keseluruhan arsitektur hybrid dan multicloud Anda. Analisis dan nilai secara menyeluruh pertimbangan ini di seluruh arsitektur solusi Anda, yang mencakup semua beban kerja, bukan hanya beban kerja tertentu.

Pemfaktoran ulang

Dalam migrasi pemfaktoran ulang, Anda memodifikasi workload untuk memanfaatkan kemampuan cloud, bukan hanya untuk membuatnya berfungsi di lingkungan baru. Anda dapat meningkatkan setiap workload untuk meningkatkan performa, fitur, biaya, dan pengalaman pengguna. Seperti yang disoroti dalam Memfaktorkan ulang: move-and-improve, beberapa skenario pemfaktoran ulang memungkinkan Anda mengubah workload sebelum memigrasikannya ke cloud. Pendekatan pemfaktoran ulang ini menawarkan manfaat berikut, terutama jika sasaran Anda adalah membuat arsitektur hibrida sebagai arsitektur yang ditargetkan dalam jangka panjang:

  • Anda dapat meningkatkan proses deployment.
  • Anda dapat membantu mempercepat ritme rilis dan mempersingkat siklus masukan dengan berinvestasi pada alat dan infrastruktur continuous integration/continuous deployment (CI/CD).
  • Anda dapat menggunakan pemfaktoran ulang sebagai dasar untuk mem-build dan mengelola arsitektur campuran dengan portabilitas aplikasi.

Agar berfungsi dengan baik, pendekatan ini biasanya memerlukan investasi tertentu dalam infrastruktur dan alat lokal. Misalnya, menyiapkan Container Registry lokal dan menyediakan cluster Kubernetes untuk memasukkan aplikasi ke dalam container. Edisi Google Kubernetes Engine (GKE) Enterprise dapat berguna dalam pendekatan ini untuk lingkungan campuran. Informasi selengkapnya tentang GKE Enterprise dibahas di bagian berikut. Anda juga dapat melihat arsitektur referensi lingkungan hibrida GKE Enterprise untuk mengetahui detail selengkapnya.

Portabilitas workload

Dengan arsitektur hybrid dan multicloud, Anda mungkin ingin dapat mengalihkan workload antar-lingkungan komputasi yang menghosting data Anda. Untuk membantu memungkinkan pergerakan workload yang lancar antar-lingkungan, pertimbangkan faktor-faktor berikut:

  • Anda dapat memindahkan aplikasi dari satu lingkungan komputasi ke lingkungan komputasi lainnya tanpa mengubah aplikasi dan model operasionalnya secara signifikan:
    • Deployment dan pengelolaan aplikasi konsisten di seluruh lingkungan komputasi.
    • Visibilitas, konfigurasi, dan keamanan konsisten di seluruh lingkungan komputasi.
  • Kemampuan untuk membuat workload portabel tidak boleh bertentangan dengan workload yang mengutamakan cloud.

Otomatisasi infrastruktur

Otomatisasi infrastruktur sangat penting untuk portabilitas dalam arsitektur hybrid dan multicloud. Salah satu pendekatan umum untuk mengotomatiskan pembuatan infrastruktur adalah melalui infrastruktur sebagai kode (IaC). IaC melibatkan pengelolaan infrastruktur dalam file, bukan mengonfigurasi resource secara manual—seperti VM, grup keamanan, atau load balancer—di antarmuka pengguna. Terraform adalah alat IaC populer untuk menentukan resource infrastruktur dalam file. Terraform juga memungkinkan Anda mengotomatiskan pembuatan resource tersebut di lingkungan heterogen.

Untuk informasi selengkapnya tentang fungsi inti Terraform yang dapat membantu Anda mengotomatiskan penyediaan dan pengelolaan resource Google Cloud , lihat Blueprint dan modul Terraform untuk Google Cloud.

Anda dapat menggunakan alat pengelolaan konfigurasi seperti Ansible, Puppet, atau Chef untuk membuat proses deployment dan konfigurasi yang umum. Atau, Anda dapat menggunakan alat pembuatan image seperti Packer untuk membuat image VM untuk berbagai platform. Dengan menggunakan satu file konfigurasi bersama, Anda dapat menggunakan Packer dan Cloud Build untuk membuat image VM yang akan digunakan di Compute Engine. Terakhir, Anda dapat menggunakan solusi seperti Prometheus dan Grafana untuk membantu memastikan pemantauan yang konsisten di seluruh lingkungan.

Berdasarkan alat ini, Anda dapat merakit rantai alat umum seperti yang diilustrasikan dalam diagram logis berikut. Rantai alat umum ini menghilangkan perbedaan antara lingkungan komputasi. Rantai alat ini juga memungkinkan Anda menyatukan penyediaan, deployment, pengelolaan, dan pemantauan.

Rantai alat memungkinkan portabilitas aplikasi.

Meskipun rantai alat umum dapat membantu Anda mencapai portabilitas, rantai alat ini memiliki beberapa kekurangan berikut:

  • Menggunakan VM sebagai fondasi umum dapat mempersulit penerapan aplikasi cloud-first yang sebenarnya. Selain itu, penggunaan VM saja dapat mencegah Anda menggunakan layanan yang dikelola cloud. Anda mungkin melewatkan peluang untuk mengurangi overhead administratif.
  • Membangun dan memelihara rantai alat umum akan menimbulkan biaya overhead dan biaya operasional.
  • Seiring dengan perluasan rantai alat, rantai alat dapat mengembangkan kompleksitas unik yang disesuaikan dengan kebutuhan spesifik perusahaan Anda. Peningkatan kompleksitas ini dapat berkontribusi pada meningkatnya biaya pelatihan.

Sebelum memutuskan untuk mengembangkan alat dan otomatisasi, jelajahi layanan terkelola yang ditawarkan penyedia cloud Anda. Jika penyedia menawarkan layanan terkelola yang mendukung kasus penggunaan yang sama, Anda dapat mengabstraksi beberapa kompleksitasnya. Dengan begitu, Anda dapat berfokus pada beban kerja dan arsitektur aplikasi, bukan infrastruktur yang mendasarinya.

Misalnya, Anda dapat menggunakan Model Resource Kubernetes untuk mengotomatiskan pembuatan cluster Kubernetes menggunakan pendekatan konfigurasi deklaratif. Anda dapat menggunakan Deployment Manager convert untuk mengonversi konfigurasi dan template Deployment Manager ke format konfigurasi deklaratif lainnya yang didukung Google Cloud (seperti Terraform dan Kubernetes Resource Model) sehingga dapat ditransfer saat Anda memublikasikannya.

Anda juga dapat mempertimbangkan untuk mengotomatiskan pembuatan project dan pembuatan resource dalam project tersebut. Otomatisasi ini dapat membantu Anda mengadopsi pendekatan infrastruktur sebagai kode untuk penyediaan project.

Container dan Kubernetes

Menggunakan kemampuan yang dikelola cloud membantu mengurangi kompleksitas pembuatan dan pengelolaan rantai alat kustom untuk mencapai otomatisasi dan portabilitas workload. Namun, hanya menggunakan VM sebagai fondasi umum akan mempersulit penerapan aplikasi yang benar-benar cloud-first. Salah satu solusinya adalah menggunakan container dan Kubernetes sebagai gantinya.

Container membantu software Anda berjalan dengan andal saat Anda memindahkannya dari satu lingkungan ke lingkungan lainnya. Karena container memisahkan aplikasi dari infrastruktur host yang mendasarinya, container memfasilitasi deployment di seluruh lingkungan komputasi, seperti hybrid dan multicloud.

Kubernetes menangani orkestrasi, deployment, penskalaan, dan pengelolaan aplikasi dalam container Anda. Kubernetes bersifat open source dan diatur oleh Cloud Native Computing Foundation. Menggunakan Kubernetes akan menyediakan layanan yang membentuk fondasi aplikasi cloud-first. Karena dapat menginstal dan menjalankan Kubernetes di banyak lingkungan komputasi, Anda juga dapat menggunakannya untuk membuat lapisan runtime umum di seluruh lingkungan komputasi:

  • Kubernetes menyediakan layanan dan API yang sama di lingkungan komputasi pribadi atau cloud. Selain itu, tingkat abstraksi jauh lebih tinggi daripada saat menggunakan VM, yang umumnya menghasilkan lebih sedikit pekerjaan dasar yang diperlukan dan peningkatan produktivitas developer.
  • Tidak seperti rantai alat kustom, Kubernetes diadopsi secara luas untuk pengembangan dan pengelolaan aplikasi, sehingga Anda dapat memanfaatkan keahlian, dokumentasi, dan dukungan pihak ketiga yang sudah ada.
  • Kubernetes mendukung semua implementasi penampung yang:

Saat beban kerja berjalan di Google Cloud, Anda dapat menghindari upaya penginstalan dan pengoperasian Kubernetes menggunakan platform Kubernetes terkelola seperti Google Kubernetes Engine (GKE). Tindakan ini dapat membantu staf operasi mengalihkan fokus mereka dari membangun dan mengelola infrastruktur menjadi membangun dan mengelola aplikasi.

Anda juga dapat menggunakan Autopilot, mode operasi GKE yang mengelola konfigurasi cluster, termasuk node, penskalaan, keamanan, dan setelan lainnya yang telah dikonfigurasi sebelumnya. Saat menggunakan GKE Autopilot, pertimbangkan persyaratan penskalaan dan batas penskalaannya.

Secara teknis, Anda dapat menginstal dan menjalankan Kubernetes di banyak lingkungan komputasi untuk membuat lapisan runtime umum. Namun, secara praktis, membangun dan mengoperasikan arsitektur semacam itu dapat menimbulkan kompleksitas. Arsitektur menjadi lebih kompleks saat Anda memerlukan kontrol keamanan tingkat penampung (mesh layanan).

Untuk menyederhanakan pengelolaan deployment multi-cluster, Anda dapat menggunakan GKE Enterprise untuk menjalankan aplikasi modern di mana saja dalam skala besar. GKE menyertakan komponen open source terkelola yang andal untuk mengamankan workload, menerapkan kebijakan kepatuhan, dan memberikan kemampuan observasi dan pemecahan masalah jaringan yang mendalam.

Seperti yang diilustrasikan dalam diagram berikut, menggunakan GKE Enterprise berarti Anda dapat mengoperasikan aplikasi multi-cluster sebagai fleet.

Diagram stack yang menunjukkan peluang pengelolaan fleet yang ditawarkan oleh GKE Enterprise.

GKE Enterprise membantu dengan opsi desain berikut untuk mendukung arsitektur hybrid dan multicloud:

  • Desain dan buat pengalaman seperti cloud di infrastruktur lokal atau solusi terpadu untuk mentransisikan aplikasi ke lingkungan hybrid GKE Enterprise. Untuk informasi selengkapnya, lihat arsitektur referensi lingkungan hybrid GKE Enterprise.

  • Buat desain dan bangun solusi untuk mengatasi kompleksitas multicloud dengan postur keamanan, operasi, dan tata kelola yang konsisten dengan GKE Multi-Cloud. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Multi-Cloud GKE.

GKE Enterprise juga menyediakan pengelompokan logis lingkungan serupa dengan keamanan, konfigurasi, dan pengelolaan layanan yang konsisten. Misalnya, GKE Enterprise mendukung arsitektur terdistribusi zero trust. Dalam arsitektur terdistribusi zero trust, layanan yang di-deploy di lokal atau di lingkungan cloud lain dapat berkomunikasi di seluruh lingkungan melalui komunikasi layanan ke layanan yang aman dan mTLS menyeluruh.

Pertimbangan portabilitas workload

Kubernetes dan GKE Enterprise menyediakan lapisan abstraksi untuk workload yang dapat menyembunyikan banyak seluk-beluk dan perbedaan antar-lingkungan komputasi. Daftar berikut menjelaskan beberapa abstraksi tersebut:

  • Aplikasi mungkin portabel untuk lingkungan yang berbeda dengan perubahan minimal, tetapi itu tidak berarti bahwa aplikasi berperforma baik di kedua lingkungan.
    • Perbedaan komputasi, kemampuan keamanan infrastruktur, atau infrastruktur jaringan yang mendasarinya, serta kedekatan dengan layanan dependen, dapat menyebabkan performa yang jauh berbeda.
  • Memindahkan workload antar-lingkungan komputasi mungkin juga mengharuskan Anda untuk memindahkan data.
    • Lingkungan yang berbeda dapat memiliki layanan dan fasilitas penyimpanan serta pengelolaan data yang berbeda.
  • Perilaku dan performa load balancer yang disediakan dengan Kubernetes atau GKE Enterprise mungkin berbeda di antara lingkungan.

Perpindahan data

Karena memindahkan, membagikan, dan mengakses data dalam skala besar antar-lingkungan komputasi bisa jadi rumit, perusahaan tingkat perusahaan mungkin ragu untuk membuat arsitektur hybrid atau multicloud. Keragu-raguan ini mungkin meningkat jika mereka sudah menyimpan sebagian besar data mereka di lokal atau di satu cloud.

Namun, berbagai opsi pemindahan data yang ditawarkan oleh Google Cloud, memberi perusahaan serangkaian solusi komprehensif untuk membantu memindahkan, mengintegrasikan, dan mengubah data mereka. Opsi ini membantu perusahaan menyimpan, membagikan, dan mengakses data di berbagai lingkungan dengan cara yang memenuhi kasus penggunaan spesifik mereka. Kemampuan tersebut pada akhirnya memudahkan pembuat keputusan bisnis dan teknologi untuk mengadopsi arsitektur hybrid dan multicloud.

Pemindahan data adalah pertimbangan penting untuk strategi dan perencanaan arsitektur hybrid dan multicloud. Tim Anda perlu mengidentifikasi berbagai kasus penggunaan bisnis dan data yang mendukungnya. Anda juga harus mempertimbangkan jenis, kapasitas, aksesibilitas, dan opsi gerakan penyimpanan.

Jika perusahaan memiliki klasifikasi data untuk industri yang diatur, klasifikasi tersebut dapat membantu mengidentifikasi lokasi penyimpanan dan pembatasan pergerakan data lintas region untuk class data tertentu. Untuk mengetahui informasi selengkapnya, lihat Perlindungan Data Sensitif. Perlindungan Data Sensitif adalah layanan terkelola sepenuhnya yang didesain untuk membantu Anda menemukan, mengklasifikasikan, dan melindungi aset data Anda.

Untuk mempelajari prosesnya, mulai dari merencanakan transfer data hingga menggunakan praktik terbaik dalam mengimplementasikan rencana, lihat Migrasi ke Google Cloud: Mentransfer set data besar.

Keamanan

Saat organisasi mengadopsi arsitektur hybrid dan multicloud, platform serangannya dapat meningkat bergantung pada cara sistem dan data didistribusikan di berbagai lingkungan. Ditambah dengan lanskap ancaman yang terus berkembang, peningkatan platform serangan dapat menyebabkan peningkatan risiko akses tidak sah, kehilangan data, dan insiden keamanan lainnya. Pertimbangkan keamanan dengan cermat saat merencanakan dan menerapkan strategi hybrid atau multicloud.

Untuk mengetahui informasi selengkapnya, lihat Attack Surface Management untuk Google Cloud.

Saat merancang arsitektur campuran, secara teknis tidak selalu memungkinkan atau viable untuk memperluas pendekatan keamanan lokal ke cloud. Namun, banyak kemampuan keamanan jaringan dari perangkat hardware adalah fitur cloud-first dan beroperasi dengan cara terdistribusi. Untuk informasi selengkapnya tentang kemampuan keamanan jaringan cloud-first Google Cloud, lihat Keamanan jaringan cloud.

Arsitektur hybrid dan multicloud dapat menimbulkan tantangan keamanan tambahan, seperti konsistensi dan visibilitas. Setiap penyedia cloud publik memiliki pendekatan keamanannya sendiri, termasuk berbagai model, praktik terbaik, kemampuan keamanan infrastruktur dan aplikasi, kewajiban kepatuhan, dan bahkan nama layanan keamanan. Inkonsistensi ini dapat meningkatkan risiko keamanan. Selain itu, model tanggung jawab bersama setiap penyedia cloud dapat berbeda. Penting untuk mengidentifikasi dan memahami demarkasi tanggung jawab yang tepat dalam arsitektur multicloud.

Observabilitas adalah kunci untuk mendapatkan insight dan metrik dari berbagai lingkungan. Dalam arsitektur multicloud, setiap cloud biasanya menyediakan alat untuk memantau postur keamanan dan kesalahan konfigurasi. Namun, penggunaan alat ini menghasilkan visibilitas silo, yang mencegah pembuatan intelijen ancaman lanjutan di seluruh lingkungan. Akibatnya, tim keamanan harus beralih antar-alat dan dasbor untuk menjaga keamanan cloud. Tanpa visibilitas keamanan menyeluruh ujung ke ujung untuk lingkungan hybrid dan multicloud, sulit untuk memprioritaskan dan mengurangi kerentanan.

Untuk mendapatkan visibilitas dan postur penuh dari semua lingkungan Anda, prioritaskan kerentanan Anda, dan mitigasi kerentanan yang Anda identifikasi. Sebaiknya gunakan model visibilitas terpusat. Model visibilitas terpusat menghindari perlunya korelasi manual antara berbagai alat dan dasbor dari berbagai platform. Untuk mengetahui informasi selengkapnya, lihat Pola pemantauan dan logging hybrid dan multicloud.

Sebagai bagian dari perencanaan Anda untuk memitigasi risiko keamanan dan men-deploy workload diGoogle Cloud, serta untuk membantu Anda merencanakan dan mendesain solusi cloud guna memenuhi tujuan keamanan dan kepatuhan, jelajahi pusat praktik terbaik keamanan Google Clouddan blueprint dasar-dasar perusahaan.

Tujuan kepatuhan dapat bervariasi, karena dipengaruhi oleh peraturan khusus industri dan persyaratan peraturan yang bervariasi di berbagai wilayah dan negara. Untuk mengetahui informasi selengkapnya, lihat Google Cloud pusat referensi kepatuhan. Berikut adalah beberapa pendekatan utama yang direkomendasikan untuk merancang arsitektur hybrid dan multicloud yang aman:

  • Mengembangkan strategi dan arsitektur keamanan cloud terpadu yang disesuaikan. Strategi keamanan hybrid dan multicloud harus disesuaikan dengan kebutuhan dan tujuan spesifik organisasi Anda.

    Anda harus memahami arsitektur dan lingkungan yang ditargetkan sebelum menerapkan kontrol keamanan, karena setiap lingkungan dapat menggunakan fitur, konfigurasi, dan layanan yang berbeda.

  • Pertimbangkan arsitektur keamanan terpadu di seluruh lingkungan hybrid dan multicloud.

  • Standarkan desain dan deployment cloud, terutama desain dan kemampuan keamanan. Tindakan ini dapat meningkatkan efisiensi dan memungkinkan tata kelola serta alat yang terpadu.

  • Gunakan beberapa kontrol keamanan.

    Biasanya, tidak ada satu kontrol keamanan yang dapat menangani semua persyaratan perlindungan keamanan secara memadai. Oleh karena itu, organisasi harus menggunakan kombinasi kontrol keamanan dalam pendekatan pertahanan berlapis, yang juga dikenal sebagai defense-in-depth.

  • Memantau dan terus meningkatkan postur keamanan: Organisasi Anda harus memantau berbagai lingkungannya untuk mendeteksi ancaman dan kerentanan keamanan. Perusahaan juga harus terus berupaya meningkatkan postur keamanannya.

  • Pertimbangkan untuk menggunakan pengelolaan postur keamanan cloud (CSPM) untuk mengidentifikasi dan memperbaiki kesalahan konfigurasi keamanan serta ancaman keamanan cyber. CSPM juga memberikan penilaian kerentanan di seluruh lingkungan hybrid dan multicloud.

Security Command Center adalah solusi keamanan dan manajemen risiko bawaan untuk Google Cloud yang membantu mengidentifikasi kesalahan konfigurasi dan kerentanan serta lainnya. Security Health Analytics adalah alat pemindaian penilaian kerentanan terkelola. Ini adalah fitur Security Command Center yang mengidentifikasi risiko dan kerentanan keamanan di lingkunganGoogle Cloud Anda dan memberikan rekomendasi untuk memperbaikinya.

Mandiant Attack Surface Management untuk Google Cloud memungkinkan organisasi Anda melihat aset lingkungan multicloud atau hybrid cloud mereka dengan lebih baik. Alat ini secara otomatis menemukan aset dari beberapa penyedia cloud, DNS, dan platform serangan eksternal yang diperluas untuk memberikan pemahaman yang lebih mendalam tentang ekosistemnya kepada perusahaan Anda. Gunakan informasi ini untuk memprioritaskan perbaikan pada kerentanan dan eksposur yang paling berisiko.

  • Solusi informasi keamanan dan manajemen peristiwa (SIEM) cloud: Membantu mengumpulkan dan menganalisis log keamanan dari lingkungan hybrid dan multicloud untuk mendeteksi dan merespons ancaman. SIEM Google Security Operations dari Google Cloud membantu memberikan Informasi keamanan dan manajemen peristiwa dengan mengumpulkan, menganalisis, mendeteksi, dan menyelidiki semua data keamanan Anda di satu tempat.

Membangun arsitektur hybrid dan multicloud menggunakan Google Cloud: Langkah berikutnya