Membangun arsitektur hybrid dan multicloud menggunakan Google Cloud

Last reviewed 2024-11-27 UTC

Panduan arsitektur ini memberikan panduan praktis tentang perencanaan dan arsitektur lingkungan hybrid dan multicloud Anda menggunakan Google Cloud. Dokumen ini adalah dokumen pertama dari tiga dokumen dalam set. Dokumen ini mengkaji peluang dan pertimbangan yang terkait dengan arsitektur ini dari sudut pandang bisnis dan teknologi. Panduan 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.

Laju perubahan yang cepat dalam permintaan pasar telah meningkatkan persyaratan dan ekspektasi yang dibebankan pada IT perusahaan, seperti penskalaan dinamis, peningkatan performa untuk pengalaman pengguna yang dioptimalkan, dan keamanan. Banyak perusahaan tingkat enterprise 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 komputasi cloud publik memberikan solusi yang 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 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 panduan arsitektur ini, istilah hybrid cloud menjelaskan arsitektur yang men-deploy workload di beberapa lingkungan komputasi, salah satunya berbasis di cloud publik, dan setidaknya salah satunya adalah pribadi—misalnya, pusat data lokal atau fasilitas kolokasi. Google Cloud

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). Penataan 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:

Pendorong, 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 Anda, dan untuk menetapkan ekspektasi spesifik tentang cara mencapai sebagian atau semua tujuan bisnis Anda. Pertanyaan ini berfokus pada apa yang dibutuhkan 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 dibantu oleh arsitektur hybrid atau multicloud?
  • Apa pendorong bisnis yang memengaruhi tujuan ini?
  • Apa persyaratan bisnis spesifiknya?

Dalam konteks arsitektur hybrid dan multicloud, salah satu sasaran bisnis pelanggan perusahaan mungkin adalah memperluas operasi atau pasar penjualan online dari satu wilayah menjadi salah satu pemimpin global di segmen pasarnya. 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 tujuan teknis utama yang potensial 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, yang secara jelas menentukan cakupan ekspansi dalam hal target wilayah 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 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 alur berikut menggambarkan pendorong bisnis, sasaran, tujuan, dan persyaratan, serta tujuan dan persyaratan teknis, dan bagaimana semua faktor ini saling terkait:

Diagram alur 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 umum yang berpengaruh 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 disiplin ilmu pengelolaan keuangan dan pengoptimalan biaya cloud seperti FinOps.
    • Adopsi cloud dapat didorong oleh skenario yang membantu mengurangi CAPEX, seperti membangun solusi Pemulihan dari Bencana dalam arsitektur hybrid atau multicloud.
  • Meningkatkan pengalaman pengguna.
  • Meningkatkan fleksibilitas dan ketangkasan untuk merespons permintaan pasar yang berubah-ubah.
  • Meningkatkan transparansi tentang 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 organisasi Anda menyadari manfaat cloud, organisasi tersebut dapat memutuskan untuk bermigrasi sepenuhnya jika tidak ada batasan—seperti biaya atau persyaratan kepatuhan tertentu yang mengharuskan data yang sangat aman dihosting di infrastruktur lokal—yang mencegahnya melakukannya.

Meskipun mengadopsi satu penyedia cloud dapat memberikan beberapa manfaat, seperti pengurangan kompleksitas, integrasi bawaan di antara layanan, dan opsi pengoptimalan biaya seperti diskon penggunaan yang di-commit, 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 baru terkait hosting data.
    • Jika penyedia layanan cloud (CSP) yang digunakan saat ini 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 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 menerapkan 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 multicloud dapat menimbulkan biaya tambahan di kemudian hari.

Tantangan umum yang terkait dengan pengembangan strategi multicloud meliputi 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 memerlukan perluasan tim, kecuali jika dikelola oleh perusahaan pihak ketiga.
  • Mengelola alat penetapan harga dan pengelolaan 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 kerumitan yang tidak terduga, lakukan penilaian kelayakan dan efektivitas terhadap potensi tantangan Anda, termasuk tantangan umum yang disebutkan sebelumnya.
  • Menghindari ketergantungan pada vendor: Terkadang, perusahaan ingin menghindari keterikatan 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 kemampuan pengelolaan yang konsisten
  • Meningkatkan tingkat keandalan dan ketersediaan aplikasi yang penting bagi bisnis: Dalam beberapa skenario, arsitektur multicloud dapat memberikan ketahanan terhadap gangguan. Misalnya, jika satu region CSP mengalami gangguan, traffic dapat dirutekan ke CSP lain di region yang sama. Skenario ini mengasumsikan 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)—di lokasi tersebut, pendekatan multicloud dapat memberikan solusi yang sesuai. Dengan menggunakan dua CSP dalam satu region untuk memberikan ketahanan terhadap gangguan, Anda dapat memfasilitasi kepatuhan terhadap pembatasan peraturan sekaligus memenuhi persyaratan ketersediaan.

Berikut beberapa pertimbangan ketahanan yang perlu dinilai sebelum menerapkan arsitektur multicloud:

  • Perpindahan data: Seberapa sering data dapat berpindah dalam lingkungan multicloud Anda?
    • Apakah pemindahan data dapat menimbulkan biaya transfer data yang signifikan?
  • Keamanan dan kemudahan pengelolaan: Apakah ada potensi kerumitan keamanan atau pengelolaan?
  • Paritas kemampuan: Apakah kedua CSP di wilayah 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 multicloud 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 meningkatkan biaya dalam jangka pendek, tetapi dapat mencegah pemadaman layanan atau kegagalan. Kegagalan tersebut dapat menyebabkan kerusakan finansial dan reputasi dalam jangka panjang. Oleh karena itu, penting untuk mempertimbangkan biaya jangka pendek terhadap potensi nilai jangka panjang pengadopsian multicloud. Selain itu, potensi nilai 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 penghubung untuk mengubah cara tim internal dalam organisasi Anda melayani bisnis selama transisi Anda ke cloud. COE adalah salah satu cara organisasi Anda dapat mengadopsi cloud dengan 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 umum meliputi:

  • Kebutuhan untuk mengurangi CAPEX atau pengeluaran IT umum untuk proyek jangka pendek.
  • Kemampuan untuk menyediakan infrastruktur tersebut dengan cepat untuk mendukung kasus penggunaan bisnis. Contoh:
    • Arsitektur ini dapat digunakan untuk project berbatas waktu. Hal ini dapat digunakan untuk mendukung project yang memerlukan infrastruktur terdistribusi berskala tinggi dalam durasi terbatas, sekaligus tetap menggunakan data yang ada di lokal.
  • Kebutuhan akan proyek transformasi digital multi-tahun yang mengharuskan perusahaan besar untuk membangunnya dan menggunakan arsitektur hybrid selama beberapa waktu untuk membantu mereka menyelaraskan modernisasi infrastruktur dan aplikasi dengan prioritas bisnis mereka.
  • Kebutuhan untuk membuat arsitektur sementara hybrid, multicloud, atau campuran setelah merger perusahaan. Dengan demikian, organisasi baru dapat menentukan strategi untuk status akhir arsitektur cloud barunya. Dua perusahaan yang bergabung biasanya 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.

Pendorong teknis

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

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

Pendorong teknis 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 secara alami mengarah ke penyiapan hybrid cloud. 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 yang didorong bisnis dan untuk 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 kasus ini adalah memiliki penyiapan hybrid cloud sementara. Pendorong tujuan teknis ini adalah untuk memanfaatkan model harga on-demand cloud guna memenuhi persyaratan bisnis yang disebutkan sebelumnya. Pendorong lainnya dipengaruhi oleh persyaratan teknologi spesifik 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 potensi kompleksitas berikut saat merencanakan arsitektur:

  • Interoperabilitas
  • Kemudahan dikelola
  • Biaya
  • Keamanan

Membangun platform cloud yang berkontribusi dan mendukung open source dapat membantu menyederhanakan jalur Anda untuk mengadopsi arsitektur hybrid dan multicloud. Cloud terbuka memberi Anda pendekatan yang memberikan pilihan maksimum dan menyederhanakan 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 ekosistem open source dan bekerja sama dengan komunitas open source untuk mengembangkan teknologi open source terkenal seperti Kubernetes. Jika di-roll out 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 sebelumnya saat merencanakan strategi hybrid dan multicloud. Bagian 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 menyetujui visi dan tujuan

Pada akhirnya, tujuan utama strategi hybrid atau multicloud adalah untuk mencapai persyaratan bisnis yang telah 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:

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, mulailah dengan merumuskan pernyataan visi yang menjawab pertanyaan berikut (setidaknya):

  • 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 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 selanjutnya dalam proses perencanaan. Untuk menyelaraskan solusi yang diusulkan 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, penting untuk mengidentifikasi dan menyetujui batasan arsitektur dan operasional project Anda.

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

  • Mengelola dan mengonfigurasi beberapa cloud secara terpisah versus membangun model holistik untuk mengelola dan mengamankan lingkungan cloud yang berbeda.
  • Memastikan autentikasi, otorisasi, audit, dan kebijakan yang konsisten di seluruh lingkungan.
  • Menggunakan alat dan proses yang konsisten di seluruh lingkungan untuk memberikan gambaran menyeluruh 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 terkait portabilitas workload, pemindahan data, dan aspek keamanan, lihat Pertimbangan lain.

Merancang strategi arsitektur hybrid dan multicloud

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

Diagram alur berikut merangkum langkah-langkah logis untuk membangun 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 alur 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 Bermigrasi ke Google Cloud.

Jalur migrasi dengan empat fase.

Bagian ini memberikan panduan tentang fase "Menilai", "Merencanakan", "Men-deploy", dan "Mengoptimalkan" dalam diagram sebelumnya. Informasi ini disajikan 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 terpisah, bukan untuk semua workload sekaligus. Kapan saja, beberapa workload mungkin berada dalam fase yang berbeda:

Fase penilaian

Pada tahap Menilai, 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 memperoleh manfaat dari deployment atau migrasi ke cloud publik.

Untuk memulai, pilih workload yang tidak terlalu penting bagi bisnis atau terlalu sulit untuk dimigrasikan (dengan sedikit atau tanpa dependensi pada workload 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 terukur pada bisnis setelah selesai.

Untuk mengevaluasi dan memitigasi potensi risiko migrasi, lakukan penilaian risiko migrasi. Penting untuk menilai beban kerja kandidat Anda untuk menentukan kesesuaiannya untuk migrasi ke lingkungan multicloud. Penilaian ini melibatkan evaluasi berbagai aspek aplikasi dan infrastruktur, termasuk hal-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 berbagai lingkungan cloud. Risiko yang Anda identifikasi dapat memengaruhi beban kerja yang Anda pilih untuk dimigrasikan atau dioperasikan.

Ada beberapa jenis alat, seperti Pusat Migrasi Google Cloud, 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 modernisasi ke container atau untuk migrasi ke Compute Engine.

Fase rencana

Pada fase Plan, mulailah dengan aplikasi yang teridentifikasi 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 arsitektur hybrid dan multicloud secara keseluruhan. Desain memerlukan integrasi yang lancar dengan pola ini. Jangan mendesain zona landing secara terpisah. Pertimbangkan pola jaringan ini sebagai subset desain zona pendaratan.

Landing zone dapat terdiri dari berbagai aplikasi, yang masing-masing memiliki pola arsitektur jaringan yang berbeda. Selain itu, pada tahap ini, penting untuk memutuskan desain hierarki organisasi, project, dan resource untuk menyiapkan zona landing lingkungan cloud Anda bagi integrasi dan deployment hybrid atau multicloud.Google Cloud

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

  • Tentukan pendekatan migrasi dan modernisasi. Ada informasi selengkapnya tentang pendekatan migrasi di bagian selanjutnya dalam panduan ini. Hal ini juga dibahas lebih mendetail di bagian jenis migrasi di Bermigrasi ke Google Cloud.
  • Gunakan temuan fase penilaian dan penemuan Anda. Sejajarkan dengan beban kerja kandidat yang ingin Anda migrasikan. Kemudian, buat rencana gelombang migrasi aplikasi. Rencana ini harus menggabungkan perkiraan persyaratan penentuan ukuran resource yang Anda tentukan selama fase penilaian.
  • Tentukan model komunikasi yang diperlukan antara aplikasi terdistribusi dan antar-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. Arketipe yang Anda pilih menjadi dasar untuk membangun 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 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.

Tahap deployment

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

Prioritaskan beban kerja 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 Anda, 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 kesuksesan aplikasi yang ditentukan. Idealnya, kriteria ini harus mencakup persyaratan pengujian beban (non-fungsional) dan 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 pemantauan dan visibilitas cloud, seperti Cloud Monitoring, dapat memberikan insight tentang performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda, dan membantu Anda mengoptimalkan tempat yang diperlukan.

Untuk mengetahui informasi selengkapnya, lihat Migrasi 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 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 Migrasi ke Google Cloud .

Seperti yang dibahas di bagian Pendorong bisnis dan teknis, ada berbagai jenis pendorong dan pertimbangan untuk arsitektur hybrid dan multicloud.

Daftar faktor yang diringkas 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 pemulihan dari bencana (DR) di cloud.
  • Potensi percepatan proses pengembangan dan rilis—misalnya, membangun lingkungan pengembangan dan pengujian Anda 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.
  • Setiap batasan 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 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 serta terbukti untuk memigrasikan workload Anda ke cloud. Dokumen ini memperluas panduan dalam Mendesain strategi arsitektur hybrid dan multicloud, yang membahas beberapa langkah yang mungkin dan direkomendasikan untuk mendesain 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 modern sekaligus menghindari (atau setidaknya meminimalkan) kerepotan memigrasikan workload yang sudah ada.

Meskipun pendekatan cloud-first dapat memberikan keuntungan tertentu, pendekatan ini berpotensi menyebabkan hilangnya peluang untuk meningkatkan atau menggunakan workload yang ada. Workload baru mungkin hanya sebagian kecil dari lanskap IT secara keseluruhan, dan pengaruhnya terhadap pengeluaran dan performa IT bisa 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 dapat memperoleh manfaat terbesar dari deployment atau migrasi cloud. Pendekatan ini juga mempertimbangkan modernisasi workload yang sudah ada.

Contoh umum arsitektur hybrid yang mengutamakan 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 hibrida yang memodernisasi layanan lama dengan menggunakan antarmuka API, sehingga layanan tersebut dapat digunakan oleh layanan dan aplikasi cloud baru. Dengan platform pengelolaan API berbasis 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 IT dan multicloud hybrid adalah konsep berbeda yang saling terkait dalam lingkaran kebaikan. Penggunaan cloud publik dapat memfasilitasi dan menyederhanakan modernisasi workload IT. Memodernisasi 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 Anda.
  • Meningkatkan keandalan dan ketahanan untuk meminimalkan risiko.

Namun, memodernisasi setiap aplikasi dalam proses migrasi secara bersamaan mungkin tidak dapat dilakukan. 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 (lift-and-optimize)
  • Memfaktorkan ulang (move-and-improve)
  • Merancang ulang (melanjutkan modernisasi)
  • Build ulang (hapus dan ganti, terkadang disebut bongkar dan ganti)
  • 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 mengangkat dan memindahkan atau mengganti platform, 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 menggunakan dan mengintegrasikan layanan cloud untuk mengoptimalkannya lebih lanjut menggunakan arsitektur dan kemampuan cloud-first. Selain itu, aplikasi ini tetap 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 layanan container terkelola seperti Google Kubernetes Engine (GKE) atau Cloud Run. Google Cloud Namun, jika arsitektur atau infrastruktur aplikasi tidak didukung di lingkungan cloud target sebagaimana adanya, Anda dapat mempertimbangkan untuk memulai dengan mengubah platform, memfaktorkan ulang, atau mendesain ulang strategi migrasi Anda untuk mengatasi batasan tersebut jika memungkinkan.

Saat menggunakan salah satu pendekatan migrasi ini, pertimbangkan untuk memodernkan 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 pada dasarnya melibatkan teknik, SRE lebih merupakan proses transformasi daripada tantangan teknis. Oleh karena itu, kemungkinan akan memerlukan perubahan prosedural dan budaya. Untuk mempelajari lebih lanjut cara mendapatkan dukungan kepemimpinan sebagai langkah pertama dalam menerapkan SRE di organisasi, lihat artikel 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 alur yang menunjukkan berbagai pendekatan untuk memigrasikan workload dari lingkungan cloud Anda.

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

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

  • Database lokal backend aplikasi dapat di-platform ulang dari MySQL yang dihosting sendiri ke database terkelola menggunakan Cloud SQL di Google Cloud.
  • Virtual machine frontend aplikasi dapat di-refactor untuk dijalankan di kontainer 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 firewall aplikasi web WAF 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 opsi 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 membangun ulang (menghapus dan mengganti) memenuhi kebutuhan Anda untuk jenis workload berikut:

  • Workload tidak lagi memenuhi persyaratan saat ini.
  • API 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 keberhasilan di bidang cloud.

Pertimbangan lainnya

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

Refactor

Dalam migrasi pemfaktoran ulang, Anda memodifikasi workload untuk memanfaatkan kemampuan cloud, bukan hanya 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 pemfaktoran ulang memungkinkan Anda mengubah workload sebelum memigrasikannya ke cloud. Pendekatan refactoring ini menawarkan manfaat berikut, terutama jika tujuan Anda adalah membangun arsitektur hibrida sebagai arsitektur target 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 refactoring sebagai dasar untuk membangun dan mengelola arsitektur hibrida 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 hybrid. 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 perpindahan workload yang lancar antar-lingkungan, pertimbangkan faktor-faktor berikut:

  • Anda dapat memindahkan aplikasi dari satu lingkungan komputasi ke lingkungan komputasi lain tanpa memodifikasi 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 infrastruktur sebagai kode (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. Selain itu, Anda dapat 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 berkembangnya rantai alat, rantai alat dapat mengembangkan kompleksitas unik yang disesuaikan dengan kebutuhan spesifik perusahaan Anda. Peningkatan kompleksitas ini dapat berkontribusi pada peningkatan 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 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 lain yang didukung Google Cloud (seperti Terraform dan Model Resource Kubernetes) sehingga dapat dipindahkan saat Anda memublikasikan.

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

Container dan Kubernetes

Penggunaan 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 berbasis cloud. 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. Penggunaan Kubernetes menyediakan layanan yang membentuk dasar aplikasi yang mengutamakan cloud. Karena Anda 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 beban kerja berjalan di Google Cloud, Anda dapat menghindari upaya penginstalan dan pengoperasian Kubernetes menggunakan platform Kubernetes terkelola seperti Google Kubernetes Engine (GKE). Dengan demikian, staf operasi dapat 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 lain 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 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 mencakup komponen open source terkelola yang canggih untuk mengamankan workload, menerapkan kebijakan kepatuhan, serta menyediakan 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 susun yang menunjukkan peluang pengelolaan fleet yang ditawarkan oleh GKE Enterprise.

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

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

  • Rancang dan bangun solusi untuk mengatasi kompleksitas multicloud dengan postur tata kelola, operasi, dan keamanan 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 secara lokal atau di lingkungan cloud lain dapat berkomunikasi di seluruh lingkungan melalui komunikasi layanan ke layanan yang aman dengan mTLS end-to-end.

Pertimbangan portabilitas workload

Kubernetes dan GKE Enterprise 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 berperforma baik di kedua lingkungan.
    • Perbedaan dalam komputasi yang mendasarinya, kemampuan keamanan infrastruktur, atau infrastruktur jaringan, serta kedekatan dengan layanan yang 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 Enterprise mungkin berbeda antar-lingkungan.

Perpindahan data

Karena memindahkan, membagikan, dan mengakses data dalam skala besar antarlingkungan 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 penyimpanan 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 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 merupakan pertimbangan penting untuk perencanaan strategi dan arsitektur hybrid dan multicloud. Tim Anda perlu mengidentifikasi berbagai kasus penggunaan bisnis Anda dan data yang mendukungnya. Anda juga harus memikirkan jenis penyimpanan, kapasitas, aksesibilitas, dan opsi pergerakan.

Jika perusahaan memiliki klasifikasi data untuk industri yang diatur, klasifikasi tersebut dapat membantu mengidentifikasi lokasi penyimpanan dan batasan pergerakan data lintas region untuk kelas data tertentu. Untuk mengetahui informasi selengkapnya, lihat Sensitive Data Protection. Sensitive Data Protection 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 menerapkan rencana, lihat Migrasi ke Google Cloud: Mentransfer set data besar.

Keamanan

Seiring organisasi mengadopsi arsitektur hybrid dan multicloud, permukaan serangan mereka dapat meningkat, bergantung pada cara sistem dan data mereka didistribusikan di berbagai lingkungan. Jika digabungkan 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 Attack Surface Management untuk Google Cloud.

Saat merancang arsitektur hybrid, tidak selalu layak atau memungkinkan secara teknis untuk memperluas pendekatan keamanan lokal ke cloud. Namun, banyak kemampuan keamanan jaringan dari perangkat hardware merupakan fitur cloud-first dan beroperasi secara terdistribusi. Untuk mengetahui 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 kemampuan observasi. Setiap penyedia cloud publik memiliki pendekatan sendiri terhadap keamanan, termasuk model, praktik terbaik, kemampuan keamanan aplikasi dan infrastruktur, kewajiban kepatuhan, dan bahkan nama layanan keamanan yang berbeda. Ketidaksesuaian 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 pengamatan 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 terisolasi, yang mencegah pembentukan intelijen ancaman 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, sulit untuk memprioritaskan dan memitigasi kerentanan.

Untuk mendapatkan visibilitas dan postur lengkap semua lingkungan Anda, prioritaskan kerentanan Anda, dan mitigasi kerentanan yang Anda identifikasi. Sebaiknya gunakan model visibilitas terpusat. Model visibilitas terpusat menghilangkan kebutuhan akan korelasi manual antara berbagai alat dan dasbor dari berbagai platform. Untuk 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 untuk memenuhi tujuan keamanan dan kepatuhan Anda, 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 berbeda-beda 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 yang terpadu dan 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.

  • Menstandardisasi desain dan deployment cloud, terutama desain dan kemampuan keamanan. Tindakan ini dapat meningkatkan efisiensi dan memungkinkan tata kelola dan 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.

  • Pantau dan terus tingkatkan 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 siber. 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 banyak lagi. Security Health Analytics adalah alat pemindaian penilaian kerentanan terkelola. Fitur ini adalah bagian dari Security Command Center yang mengidentifikasi risiko dan kerentanan keamanan di lingkunganGoogle Cloud Anda serta memberikan rekomendasi untuk memulihkannya.

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

  • Solusi informasi keamanan dan manajemen peristiwa (SIEM) berbasis 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