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 multicloud Anda menggunakan Google Cloud. Dokumen ini adalah dokumen pertama dari tiga dokumen dalam set. Dokumen ini membahas peluang dan pertimbangan yang terkait dengan arsitektur ini dari sudut pandang bisnis dan teknologi. Dokumen 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-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.

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 dengan 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 cloud computing 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 sudah ada, Anda tidak hanya mempertahankan investasi yang sudah 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 tantangannya.

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 panduan arsitektur Google Cloud ini, istilah hybrid cloud menjelaskan arsitektur tempat workload di-deploy di beberapa lingkungan komputasi, salah satunya berbasis di cloud publik, dan setidaknya salah satunya adalah pribadi—misalnya, pusat data lokal atau fasilitas kolokasi.

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 mencakup penggunaan komponen cloud pribadi). Pengaturan tersebut disebut arsitektur hybrid dan multicloud.

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

Kontributor

Penulis: Marwan Al Shawi | Partner Customer Engineer

Kontributor lainnya:

Pemicu, pertimbangan, strategi, dan pendekatan

Dokumen ini mendefinisikan dan membahas tujuan, pendorong, dan persyaratan bisnis, serta bagaimana faktor-faktor ini dapat memengaruhi keputusan desain Anda saat membangun 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 beberapa atau semua tujuan bisnis Anda. Pertanyaan-pertanyaan ini berfokus pada hal yang diperlukan untuk bisnis Anda, bukan cara mencapainya secara teknis.

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

Dalam konteks arsitektur hybrid dan multicloud, salah satu sasaran bisnis untuk pelanggan perusahaan mungkin adalah memperluas operasi atau pasar penjualan online dari satu region untuk menjadi salah satu pemimpin global di segmen pasar mereka. Salah satu tujuan bisnis 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 potensi tujuan teknis utama adalah memperluas infrastruktur IT dan arsitektur aplikasi perusahaan dari model khusus lokal ke arsitektur hybrid, menggunakan kemampuan dan layanan global cloud publik. Tujuan ini harus spesifik dan terukur, serta mendefinisikan dengan jelas cakupan ekspansi dalam hal wilayah target dan linimasa.

Secara umum, arsitektur hybrid atau multicloud jarang menjadi tujuan tersendiri, melainkan 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. Tujuan teknis Anda harus berfokus pada membangun fondasi teknologi yang memungkinkan organisasi Anda memenuhi persyaratan dan tujuan bisnis mereka.

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

Diagram alir berikut mengilustrasikan pendorong, sasaran, tujuan, dan persyaratan bisnis, serta tujuan dan persyaratan teknis, dan bagaimana semua faktor ini saling terkait:

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

Pendorong bisnis dan teknis

Pertimbangkan pengaruh pendorong bisnis terhadap tujuan teknis Anda. Beberapa pendorong bisnis yang umum dan berpengaruh saat memilih arsitektur hybrid meliputi:

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

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

Setelah organisasi Anda menyadari manfaat cloud, organisasi tersebut mungkin memutuskan untuk bermigrasi sepenuhnya jika tidak ada batasan—seperti biaya atau persyaratan kepatuhan tertentu yang mengharuskan data yang sangat aman dihosting secara lokal—yang mencegahnya melakukannya.

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

  • Memperhatikan hukum dan peraturan tentang kedaulatan data: Skenario yang paling umum adalah saat organisasi memperluas bisnisnya ke wilayah atau negara baru dan harus mematuhi peraturan hosting data yang baru.
    • Jika penyedia layanan cloud (CSP) yang digunakan saat ini tidak memiliki region cloud lokal di negara tersebut, solusi umum untuk tujuan kepatuhan adalah menggunakan CSP lain yang memiliki region cloud lokal di negara tersebut.
  • Mengurangi biaya: Pengurangan biaya sering kali menjadi pendorong bisnis yang 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 untuk membangun dan mengoperasikan solusi di beberapa cloud, serta batasan arsitektur apa pun yang mungkin timbul dari sistem yang ada.

Terkadang, potensi tantangan yang terkait dengan strategi multicloud mungkin lebih besar daripada manfaatnya. Strategi multicloud mungkin akan menimbulkan biaya tambahan di kemudian hari.

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

  • Meningkatkan kompleksitas pengelolaan.
  • Mempertahankan keamanan yang konsisten.
  • Mengintegrasikan lingkungan software.
  • Mencapai performa dan keandalan lintas cloud yang konsisten.
  • Membangun tim teknis dengan keterampilan multicloud mungkin mahal dan mungkin memerlukan perluasan tim, kecuali jika dikelola oleh perusahaan pihak ketiga.
  • Mengelola alat pengelolaan dan harga produk 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 terbatas pada 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 ketergantungan pada satu penyedia cloud. Pendekatan multicloud memungkinkan mereka memilih solusi terbaik untuk kebutuhan bisnis mereka. Namun, kelayakan keputusan ini bergantung pada beberapa faktor, seperti berikut:
    • Dependensi teknis
    • Pertimbangan interoperabilitas antar-aplikasi
    • Biaya pembangunan ulang atau refaktorisasi aplikasi
    • Keterampilan teknis
    • Keamanan dan pengelolaan yang konsisten
  • Meningkatkan tingkat keandalan dan ketersediaan aplikasi penting bisnis: Dalam beberapa skenario, arsitektur multicloud dapat memberikan ketahanan terhadap pemadaman layanan. Misalnya, jika satu region CSP tidak aktif, traffic dapat dirutekan ke CSP lain di region yang sama. Skenario ini mengasumsikan bahwa kedua penyedia cloud mendukung kemampuan atau layanan yang diperlukan di region tersebut.

Jika peraturan residensi data di negara atau wilayah tertentu mewajibkan penyimpanan data sensitif—seperti informasi identitas pribadi (PII)—di lokasi tersebut, pendekatan multicloud dapat memberikan solusi yang sesuai. Dengan menggunakan dua CSP di satu region untuk memberikan ketahanan terhadap pemadaman layanan, Anda dapat memfasilitasi kepatuhan terhadap batasan peraturan sekaligus memenuhi persyaratan ketersediaan.

Berikut adalah beberapa pertimbangan ketahanan yang perlu dinilai sebelum mengadopsi arsitektur multicloud:

  • Pergerakan data: Seberapa sering data dapat berpindah dalam lingkungan multicloud Anda?
    • Apakah perpindahan data dapat 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?
  • Keterampilan teknis: Apakah tim teknis memiliki keterampilan yang diperlukan untuk mengelola arsitektur multicloud?

Pertimbangkan semua faktor ini saat menilai kelayakan penggunaan arsitektur multicloud untuk meningkatkan ketahanan.

Saat menilai kelayakan arsitektur multicloud, penting untuk mempertimbangkan manfaat jangka panjang. Misalnya, men-deploy aplikasi di beberapa cloud untuk disaster recovery atau peningkatan keandalan mungkin akan meningkatkan biaya dalam jangka pendek, tetapi dapat mencegah pemadaman layanan atau kegagalan. Kegagalan tersebut dapat menyebabkan kerugian finansial dan reputasi jangka panjang. Oleh karena itu, penting untuk mempertimbangkan biaya jangka pendek terhadap potensi nilai jangka panjang dari pengadopsian multicloud. Selain itu, nilai potensial jangka panjang dapat bervariasi berdasarkan ukuran organisasi, skala teknologi, tingkat kekritisan solusi teknologi, dan industri.

Organisasi yang berencana untuk berhasil membuat lingkungan hybrid atau multicloud, harus mempertimbangkan membangun 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 bagi organisasi Anda untuk mengadopsi cloud lebih cepat, mendorong standardisasi, dan mempertahankan keselarasan yang lebih kuat antara strategi bisnis dan investasi cloud Anda.

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

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

Penggerak teknis

Bagian sebelumnya membahas faktor pendorong bisnis. Untuk mendapatkan persetujuan, keputusan arsitektur utama hampir selalu memerlukan dukungan dari pendorong tersebut. Namun, pendorong teknis, yang dapat didasarkan pada keuntungan atau batasan teknis, juga dapat memengaruhi pendorong bisnis. Dalam beberapa skenario, perlu untuk menerjemahkan pendorong teknis menjadi pendorong bisnis dan menjelaskan bagaimana hal tersebut dapat memengaruhi bisnis secara positif atau negatif.

Daftar tidak lengkap berikut berisi beberapa pendorong teknis umum untuk mengadopsi 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 membangun layanan dan kemampuan yang elastis dengan lebih cepat dan dalam skala besar.
  • Menggunakan kemampuan infrastruktur global untuk membangun arsitektur global atau multi-regional guna memenuhi persyaratan teknis tertentu.

Penggerak teknis yang paling umum untuk arsitektur hybrid sementara dan 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 untuk jangka waktu tertentu.

Keputusan desain teknis

Tujuan teknis yang diidentifikasi dan pendorongnya adalah kunci untuk membuat keputusan arsitektur berbasis bisnis dan untuk memilih salah satu pola arsitektur yang dibahas dalam panduan ini. Misalnya, untuk mendukung sasaran bisnis tertentu, perusahaan mungkin 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 kasus ini adalah memiliki penyiapan hybrid cloud sementara. Pendorong untuk tujuan teknis ini adalah memanfaatkan model harga on-demand cloud untuk memenuhi persyaratan bisnis yang disebutkan sebelumnya. Faktor pendorong 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 pada vendor. Namun, Anda harus mempertimbangkan potensi kompleksitas 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. Cloud terbuka memberdayakan Anda dengan pendekatan yang memberikan pilihan maksimum dan mengabstraksi kompleksitas. Selain itu, Google Cloud menawarkan fleksibilitas untuk memigrasikan, membangun, dan mengoptimalkan aplikasi di seluruh lingkungan hybrid dan multicloud sambil meminimalkan keterikatan pada vendor, menggunakan solusi terbaik, serta memenuhi persyaratan peraturan.

Google juga merupakan salah satu kontributor terbesar untuk 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 pengelolaan dan keamanan 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 sasaran ini, buat rencana yang terstruktur dengan baik yang mencakup pertimbangan berikut:

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

Untuk menghindari situasi tersebut, pertama-tama rumuskan 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 cukup untuk memenuhi tujuan bisnis?
  • Apa aspek teknologi utama yang harus 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 selanjutnya dalam proses perencanaan. Untuk menyelaraskan solusi yang Anda usulkan secara efektif dengan visi arsitektur menyeluruh organisasi Anda, selaraskan dengan tim Anda dan pemangku kepentingan yang bertanggung jawab untuk memimpin dan mensponsori inisiatif ini.

Mengidentifikasi dan mengklarifikasi pertimbangan lainnya

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

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

  • Mengelola dan mengonfigurasi beberapa cloud secara terpisah versus membangun model holistik 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 pandangan holistik tentang keamanan, biaya, dan peluang 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 sudah 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 mengetahui informasi selengkapnya tentang pertimbangan lain yang terkait dengan portabilitas workload, pemindahan data, dan aspek keamanan, lihat Pertimbangan lainnya.

Merancang strategi arsitektur hybrid dan multicloud

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

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

Saat menyusun strategi, pertimbangkan tujuan bisnis Anda, dapatkan persetujuan, buat rencana tingkat tinggi, lalu gunakan rencana tersebut untuk menyusun 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 dari setiap kasus penggunaan bisnis.

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

Jalur migrasi dengan empat fase.

Bagian ini memberikan panduan tentang fase "Menilai", "Merencanakan", "Men-deploy", dan "Mengoptimalkan" dalam diagram sebelumnya. Panduan ini menyajikan informasi tersebut dalam konteks migrasi hybrid atau multicloud. Anda harus menyelaraskan migrasi apa pun dengan panduan dan praktik terbaik yang dibahas di bagian jalur migrasi dalam panduan Migrate to Google Cloud . Fase ini mungkin berlaku untuk setiap workload secara individual, bukan untuk semua workload sekaligus. Kapan saja, 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 visi dan strategi 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 workload yang tidak terlalu penting bagi bisnis atau terlalu sulit untuk dimigrasikan (dengan dependensi minimal atau tanpa dependensi pada workload apa pun di lingkungan lain), tetapi cukup umum untuk dijadikan sebagai cetak biru bagi deployment atau migrasi mendatang.

Idealnya, workload atau aplikasi yang Anda pilih harus menjadi bagian dari kasus penggunaan atau fungsi bisnis yang ditargetkan dan memiliki efek yang terukur pada bisnis setelah selesai.

Untuk mengevaluasi dan memitigasi potensi risiko migrasi, lakukan penilaian risiko migrasi. Penting untuk menilai workload kandidat Anda guna menentukan kesesuaiannya untuk migrasi ke lingkungan multicloud. 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 Google Cloud Migration Center, untuk membantu Anda menilai workload yang ada. Untuk mengetahui informasi selengkapnya, lihat Migrasi ke Google Cloud: Memilih alat penilaian.

Dari perspektif modernisasi workload, alat penilaian kesesuaian membantu menilai workload VM untuk menentukan apakah workload tersebut cocok untuk dimodernisasi ke container atau dimigrasikan ke Compute Engine.

Fase perencanaan

Pada fase Plan, 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 berbagai aplikasi, masing-masing dengan pola arsitektur jaringan yang berbeda. Selain itu, dalam fase ini, penting untuk memutuskan desain Google Cloud organisasi, project, dan hierarki resource guna menyiapkan zona landing lingkungan cloud Anda untuk integrasi dan deployment hybrid atau multicloud.

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

  • Menentukan 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. Selaraskan dengan workload kandidat yang ingin Anda migrasikan. Kemudian, kembangkan rencana gelombang migrasi aplikasi. Rencana tersebut 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 zona, regional, multi-regional, atau global, untuk pola arsitektur yang dipilih. Arketipe yang Anda pilih menjadi dasar untuk membangun arsitektur deployment khusus aplikasi yang disesuaikan dengan kebutuhan bisnis dan teknis Anda.
  • Tentukan kriteria keberhasilan yang terukur untuk migrasi, dengan pencapaian yang jelas untuk setiap fase atau gelombang migrasi. Memilih kriteria sangat penting, meskipun tujuan teknisnya adalah memiliki arsitektur hybrid 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 mengetahui informasi selengkapnya, lihat Tentang perencanaan migrasi untuk membantu merencanakan migrasi yang berhasil dan meminimalkan risiko terkait.

Fase deployment

Pada fase Deploy, Anda siap untuk mulai menjalankan strategi migrasi. Mengingat banyaknya persyaratan, langkah terbaik adalah mengambil 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 lakukan pendekatan ini untuk keseluruhan keputusan desain zona landing Anda.

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

Fase mengoptimalkan

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

Untuk mengetahui 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 sangat memengaruhi keberhasilan 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 workload/aplikasi yang paling penting bagi bisnis tidak selalu diperlukan atau direkomendasikan. Untuk mengetahui informasi selengkapnya, lihat Memilih aplikasi yang akan dimigrasikan terlebih dahulu dalam panduan Migrasi ke Google Cloud .

Seperti yang dibahas di bagian Penggerak bisnis dan teknis, ada berbagai jenis penggerak 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 memberikan efek 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 disaster recovery (DR) di cloud.
  • Potensi percepatan proses pengembangan dan rilis—misalnya, membangun lingkungan pengembangan dan pengujian di cloud.

Faktor-faktor berikut dapat membantu Anda mengevaluasi risiko migrasi:

  • Potensi dampak pemadaman layanan yang disebabkan oleh migrasi.
  • Pengalaman yang dimiliki 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 apa pun pada versi tertentu dari sistem operasi, database, atau konfigurasi lingkungan lainnya.

Setelah menilai workload awal, Anda dapat mulai memprioritaskannya dan menentukan gelombang dan pendekatan migrasi. Kemudian, Anda dapat mengidentifikasi pola arsitektur yang berlaku dan pola jaringan pendukung. Langkah ini mungkin memerlukan beberapa iterasi, karena penilaian Anda dapat berubah seiring 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 yang telah terbukti untuk memigrasikan workload Anda ke cloud. Panduan ini memperluas panduan dalam Merancang strategi arsitektur hybrid dan multicloud, yang membahas beberapa langkah yang mungkin dan direkomendasikan untuk merancang strategi dalam 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 berpotensi mengakibatkan hilangnya peluang untuk meningkatkan atau menggunakan workload yang ada. Workload baru mungkin hanya merupakan sebagian dari keseluruhan lanskap IT, dan dampaknya terhadap pengeluaran dan performa IT mungkin terbatas. Mengalokasikan waktu dan resource untuk memigrasikan workload yang ada berpotensi menghasilkan manfaat atau penghematan biaya yang lebih besar 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 bisa mendapatkan manfaat terbesar dari migrasi atau deployment cloud. Pendekatan ini juga mempertimbangkan modernisasi workload yang sudah ada.

Contoh umum arsitektur hybrid yang mengandalkan cloud adalah saat aplikasi dan layanan lama yang menyimpan data penting harus diintegrasikan dengan data atau aplikasi baru. Untuk menyelesaikan integrasi, Anda dapat menggunakan arsitektur hybrid yang memodernisasi layanan lama 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, serta skalabilitas ke layanan lama.

Migrasi dan modernisasi

Modernisasi multicloud hybrid dan IT 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)
  • Melakukan replatform (lift-and-optimize)
  • Merefaktorisasi (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. Anda dapat mempertimbangkan pendekatan migrasi bertahap, dimulai dengan lift and shift atau replatforming, lalu melakukan refaktorisasi 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 yang mengutamakan cloud. Selain itu, aplikasi ini masih dapat berkomunikasi dengan lingkungan lain melalui koneksi jaringan hybrid.

Misalnya, Anda dapat melakukan refaktorisasi atau merancang ulang aplikasi besar berbasis VM monolitik dan mengubahnya menjadi beberapa microservice independen, berdasarkan arsitektur microservice berbasis cloud. Dalam contoh ini, arsitektur microservice menggunakan Google Cloud layanan container 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 melakukan replatforming, refaktorisasi, atau penataan 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 implementasi prinsip Site Reliability Engineering (SRE) atau DevOps, sehingga Anda mungkin juga perlu memperluas modernisasi aplikasi ke lingkungan pribadi dalam penyiapan hybrid. Meskipun penerapan prinsip SRE melibatkan engineering pada intinya, hal ini lebih merupakan proses transformasi daripada tantangan teknis. Oleh karena itu, kemungkinan akan diperlukan perubahan prosedural dan budaya. Untuk mempelajari lebih lanjut cara mendapatkan dukungan kepemimpinan sebagai langkah pertama dalam menerapkan SRE di organisasi, baca 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 workload dari lingkungan cloud Anda.

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

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

  • Database lokal backend aplikasi dapat diubah platformnya dari MySQL yang dihosting sendiri ke database terkelola menggunakan Cloud SQL di Google Cloud.
  • Virtual machine frontend aplikasi dapat direfaktorisasi untuk dijalankan di container menggunakan GKE Autopilot, tempat Google mengelola konfigurasi cluster, termasuk node, penskalaan, keamanan, dan setelan lain yang telah dikonfigurasi sebelumnya.
  • Solusi load balancing hardware lokal 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 direfaktorisasi, atau refaktorisasi sebelum migrasi tidak memungkinkan.
  • Workload didasarkan pada software pihak ketiga.

Pertimbangkan opsi merefaktorisasi (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 opsi bangun ulang (hapus dan ganti) memenuhi kebutuhan Anda untuk jenis workload berikut:

  • Workload tidak lagi memenuhi persyaratan saat ini.
  • Layanan ini dapat digabungkan dengan aplikasi lain yang memberikan 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 keberhasilan di bidang cloud.

Pertimbangan lainnya

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

Refactor

Dalam migrasi refaktorisasi, Anda memodifikasi workload untuk memanfaatkan kapabilitas cloud, bukan hanya untuk membuatnya berfungsi di lingkungan baru. Anda dapat meningkatkan setiap workload untuk meningkatkan performa, fitur, biaya, dan pengalaman pengguna. Seperti yang dijelaskan dalam Memfaktorkan ulang: move-and-improve, beberapa skenario refaktorisasi memungkinkan Anda mengubah workload sebelum memigrasikannya ke cloud. Pendekatan refaktorisasi ini menawarkan manfaat berikut, terutama jika sasaran Anda adalah membangun arsitektur hybrid 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 refaktorisasi sebagai fondasi untuk membangun dan mengelola arsitektur hybrid dengan portabilitas aplikasi.

Agar berfungsi dengan baik, pendekatan ini biasanya memerlukan investasi tertentu dalam infrastruktur dan alat lokal. Menggabungkan Google Kubernetes Engine (GKE) dengan Google Distributed Cloud dapat berguna dalam pendekatan ini untuk lingkungan hybrid. Informasi selengkapnya tentang GKE dibahas di bagian berikut. Anda juga dapat membaca arsitektur referensi lingkungan hybrid GKE 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 pemindahan workload yang lancar antar-lingkungan, pertimbangkan faktor-faktor berikut:

  • Anda dapat memindahkan aplikasi dari satu lingkungan komputasi ke lingkungan komputasi lain 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 berbasis cloud.

Otomatisasi infrastruktur

Otomatisasi infrastruktur sangat penting untuk portabilitas dalam arsitektur hybrid dan multicloud. Salah satu pendekatan umum untuk mengotomatiskan pembuatan infrastruktur adalah melalui infrastructure as code (IaC). IaC melibatkan pengelolaan infrastruktur Anda dalam file, bukan mengonfigurasi resource secara manual—seperti VM, grup keamanan, atau load balancer—dalam 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 mengetahui 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 membangun proses deployment dan konfigurasi yang umum. Atau, Anda dapat menggunakan alat pembakaran 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 yang benar-benar mengandalkan cloud. Selain itu, hanya menggunakan VM 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 berkembangnya rantai alat, rantai alat dapat mengembangkan kompleksitas unik yang disesuaikan dengan kebutuhan spesifik perusahaan Anda. Peningkatan kompleksitas ini dapat berkontribusi pada kenaikan biaya pelatihan.

Sebelum memutuskan untuk mengembangkan alat dan otomatisasi, pelajari layanan terkelola yang ditawarkan penyedia cloud Anda. Jika penyedia Anda menawarkan layanan terkelola yang mendukung kasus penggunaan yang sama, Anda dapat mengabstraksi beberapa kompleksitasnya. Dengan demikian, Anda dapat berfokus pada workload dan arsitektur aplikasi, bukan pada 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 lain yang didukung Google Cloud (seperti Terraform dan Model Resource Kubernetes) agar portabel saat Anda memublikasikannya.

Anda juga dapat mempertimbangkan untuk mengotomatiskan pembuatan project dan pembuatan resource dalam project tersebut. Otomatisasi ini dapat membantu Anda mengadopsi pendekatan infrastructure as code untuk penyediaan project.

Container dan Kubernetes

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

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 berbagai 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. Penggunaan Kubernetes menyediakan layanan yang menjadi dasar aplikasi yang mengandalkan cloud. 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 container yang:

Saat workload berjalan di Google Cloud, Anda dapat menghindari upaya menginstal dan mengoperasikan Kubernetes menggunakan platform Kubernetes terkelola seperti GKE. Hal ini dapat membantu staf operasi mengalihkan fokus mereka dari membangun dan memelihara infrastruktur ke membangun dan memelihara aplikasi.

Anda juga dapat menggunakan Autopilot, mode operasi GKE yang mengelola konfigurasi cluster Anda, 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, dalam praktiknya, membangun dan mengoperasikan arsitektur semacam itu dapat menimbulkan kompleksitas. Arsitektur menjadi lebih kompleks saat Anda memerlukan kontrol keamanan tingkat container (mesh layanan).

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

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

Diagram tumpukan yang menunjukkan peluang pengelolaan fleet yang ditawarkan oleh GKE.

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

  • Mendesain dan membangun pengalaman seperti cloud di infrastruktur lokal atau solusi terpadu untuk mentransisikan aplikasi ke lingkungan hybrid GKE. Untuk mengetahui informasi selengkapnya, lihat Arsitektur referensi lingkungan hybrid GKE.

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

GKE juga menyediakan pengelompokan logis dari lingkungan serupa dengan keamanan, konfigurasi, dan pengelolaan layanan yang konsisten. Misalnya, GKE dan produk terkait memungkinkan Anda membuat arsitektur terdistribusi zero-trust. Dalam arsitektur terdistribusi zero trust, layanan yang di-deploy di infrastruktur lokal atau di lingkungan cloud lain dapat berkomunikasi di seluruh lingkungan melalui komunikasi layanan ke layanan yang aman mTLS end-to-end.

Pertimbangan portabilitas workload

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

  • Aplikasi mungkin portabel untuk lingkungan yang berbeda dengan perubahan minimal, tetapi itu tidak berarti bahwa aplikasi akan berperforma baik di kedua lingkungan.
    • Perbedaan dalam komputasi yang mendasarinya, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, 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 dan pengelolaan data yang berbeda.
  • Perilaku dan performa load balancer yang disediakan dengan Kubernetes atau GKE mungkin berbeda antar-lingkungan.

Perpindahan data

Karena memindahkan, membagikan, dan mengakses data dalam skala besar di antara lingkungan komputasi bisa jadi rumit, perusahaan tingkat enterprise mungkin ragu untuk membangun arsitektur hybrid atau multicloud. Keraguan ini mungkin meningkat jika mereka sudah menyimpan sebagian besar data mereka di infrastruktur lokal atau di satu cloud.

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

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

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

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

Keamanan

Saat organisasi mengadopsi arsitektur hybrid dan multicloud, permukaan serangan mereka dapat meningkat, bergantung pada cara sistem dan data mereka didistribusikan di berbagai lingkungan. Dikombinasikan dengan lanskap ancaman yang terus berkembang, peningkatan permukaan 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 Pengelolaan Permukaan Serangan untuk Google Cloud.

Saat merancang arsitektur hybrid, tidak selalu memungkinkan atau layak secara teknis untuk memperluas pendekatan keamanan lokal ke cloud. Namun, banyak kemampuan keamanan jaringan dari peralatan hardware merupakan fitur cloud-first dan beroperasi secara terdistribusi. Untuk mengetahui informasi selengkapnya tentang kemampuan keamanan jaringan yang mengutamakan cloud dari 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 model, praktik terbaik, kemampuan keamanan infrastruktur dan aplikasi, kewajiban kepatuhan, dan bahkan nama layanan keamanan yang berbeda. Inkonsistensi ini dapat meningkatkan risiko keamanan. Selain itu, model tanggung jawab bersama setiap penyedia cloud dapat berbeda. Penting untuk mengidentifikasi dan memahami pembatasan tanggung jawab yang tepat dalam arsitektur multicloud.

Kemampuan observasi 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 yang terpisah-pisah, sehingga mencegah pembuatan threat intelligence tingkat lanjut di seluruh lingkungan. Akibatnya, tim keamanan harus beralih di antara alat dan dasbor untuk menjaga keamanan cloud. Tanpa visibilitas keamanan end-to-end yang menyeluruh untuk lingkungan hybrid dan multicloud, akan sulit untuk memprioritaskan dan memitigasi kerentanan.

Untuk mendapatkan visibilitas dan postur penuh dari semua lingkungan Anda, prioritaskan kerentanan, 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 di Google Cloud, serta untuk membantu Anda merencanakan dan mendesain solusi cloud guna memenuhi tujuan keamanan dan kepatuhan, pelajari Google Cloud pusat praktik terbaik keamanan dan 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 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.

    Sangat penting untuk 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.

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

  • Menggunakan beberapa kontrol keamanan.

    Biasanya, tidak ada satu pun kontrol keamanan yang dapat memenuhi 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. Organisasi juga harus mencoba untuk terus meningkatkan postur keamanannya.

  • Pertimbangkan untuk menggunakan manajemen postur keamanan cloud (CSPM) guna mengidentifikasi dan memperbaiki kesalahan konfigurasi keamanan dan ancaman pengamanan cyber. CSPM juga menyediakan 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 serta memberikan rekomendasi untuk memperbaikinya.

Mandiant Attack Surface Management untuk Google Cloud memungkinkan organisasi Anda melihat aset lingkungan multicloud atau hybrid cloud dengan lebih baik. Solusi ini otomatis menemukan aset dari beberapa penyedia cloud, DNS, dan permukaan serangan eksternal yang diperluas untuk memberi perusahaan Anda pemahaman yang lebih mendalam tentang ekosistemnya. Gunakan informasi ini untuk memprioritaskan perbaikan pada kerentanan dan eksposur yang menimbulkan risiko terbesar.

  • Solusi informasi keamanan dan manajemen peristiwa (SIEM) cloud: Membantu mengumpulkan dan menganalisis log keamanan dari lingkungan hybrid dan multicloud untuk mendeteksi dan merespons ancaman. Google Security Operations SIEM dari Google Cloud membantu menyediakan 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 selanjutnya