Hierarki Resource Google Cloud

Hierarki resource di Google Cloud dimulai dengan organisasi yang berfungsi sebagai simpul utama. Disarankan bagi bisnis untuk memiliki satu simpul utama, kecuali dalam keadaan tertentu yang mengharuskan sebaliknya. Folder dan proyek digunakan untuk mendefinisikan tingkatan hierarki yang lebih rendah, memungkinkan pembuatan folder bertingkat untuk membangun struktur yang diinginkan. Proyek, yang menyimpan beban kerja, dapat dibuat pada tingkat apa pun dalam hierarki.

Decide a resource hierarchy for your Google Cloud landing zone

Hierarki Berdasarkan Lingkungan Aplikasi

Di banyak organisasi, kebijakan dan kontrol akses yang berbeda ditetapkan untuk lingkungan aplikasi yang berbeda, seperti pengembangan, produksi, dan pengujian. Mengadopsi hierarki berdasarkan lingkungan aplikasi menyederhanakan pengelolaan dan konfigurasi dengan menerapkan kebijakan standar untuk setiap lingkungan. Misalnya, lingkungan produksi mungkin memiliki kebijakan keamanan yang lebih ketat dibandingkan dengan lingkungan pengujian.

Gunakan hierarki berdasarkan lingkungan aplikasi ketika kondisi berikut terpenuhi:

• Anda memiliki lingkungan aplikasi terpisah dengan kebutuhan kebijakan dan administrasi yang berbeda.
• Anda memiliki kasus penggunaan yang membutuhkan keamanan yang sangat disesuaikan atau persyaratan audit.
• Peran Manajemen Identitas dan Akses (IAM) yang berbeda diperlukan untuk mengakses resource Google Cloud di lingkungan yang berbeda.

Hindari hierarki ini jika kondisi berikut berlaku:

• Anda tidak mengoperasikan beberapa lingkungan aplikasi.
• Tidak ada dependensi aplikasi yang berbeda atau proses bisnis yang berbeda di antara lingkungan.
• Terdapat perbedaan kebijakan yang signifikan di antara wilayah, tim, atau aplikasi.

Diagram di bawah ini menggambarkan contoh hierarki untuk perusahaan teknologi keuangan fiktif, example.com.

Decide a resource hierarchy for your Google Cloud landing zone

Seperti yang terlihat dalam diagram di atas, example.com memiliki tiga lingkungan aplikasi yang berbeda dengan kebijakan, kontrol akses, persyaratan peraturan, dan proses yang berbeda. Lingkungan ini adalah:

• Lingkungan Pengembangan dan QA: Dikelola oleh karyawan internal dan konsultan, lingkungan ini melibatkan penyebaran kode yang berkelanjutan dan jaminan kualitas. Lingkungan ini tidak dapat diakses oleh konsumen bisnis. Persyaratan integrasi dan autentikasi kurang ketat dibandingkan dengan lingkungan produksi, dan pengembang diberikan peran yang sesuai dengan izin yang tepat. Lingkungan Pengembangan dan QA secara eksklusif melayani penawaran aplikasi standar dari example.com.
• Lingkungan Pengujian: Diperuntukkan untuk pengujian regresi dan aplikasi, lingkungan ini mendukung klien example.com yang menggunakan API perusahaan untuk penawaran B2B mereka. example.com membuat dua jenis proyek untuk tujuan ini:
  • Proyek pengujian internal untuk regresi internal, kinerja, dan konfigurasi terkait penawaran B2B.
  • Proyek UAT klien dengan dukungan multi-penyewa, yang memungkinkan klien B2B memvalidasi konfigurasi mereka dan menyelaraskan dengan persyaratan example.com untuk pengalaman pengguna, branding, alur kerja, laporan, dan lainnya.
• Lingkungan Produksi: Lingkungan ini menjadi tuan rumah penawaran produk yang telah divalidasi, diterima, dan diluncurkan. Lingkungan ini mematuhi standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), menggunakan modul keamanan perangkat keras (HSM), dan terintegrasi dengan pemroses pihak ketiga untuk autentikasi dan penyelesaian pembayaran. Tim audit dan kepatuhan memainkan peran penting dalam lingkungan ini, yang memiliki akses yang ketat terutama melalui proses penyebaran otomatis.

Hierarki Berdasarkan Wilayah atau Anak Perusahaan

Beberapa organisasi beroperasi di berbagai wilayah atau memiliki anak perusahaan yang menjalankan bisnis di lokasi geografis yang berbeda sebagai hasil dari penggabungan atau akuisisi. Organisasi-organisasi ini memerlukan hierarki resource yang memanfaatkan skalabilitas dan pilihan manajemen Google Cloud sambil mempertahankan otonomi wilayah atau anak perusahaan dengan proses dan kebijakan yang berbeda. Dalam hierarki ini, anak perusahaan atau wilayah berfungsi sebagai folder tingkat tertinggi. Prosedur penyebaran umumnya fokus pada wilayah-wilayah spesifik.

Pilih hierarki berdasarkan wilayah atau anak perusahaan jika kondisi berikut terpenuhi:

• Anak perusahaan atau wilayah beroperasi secara independen.
• Anak perusahaan atau wilayah memiliki infrastruktur operasional, penawaran platform digital, dan proses yang berbeda.
• Bisnis Anda mematuhi standar peraturan dan kepatuhan yang berbeda untuk anak perusahaan atau wilayah.

Diagram berikut ini menggambarkan contoh hierarki dari sebuah organisasi global dengan dua anak perusahaan dan sebuah grup induk yang terstruktur berdasarkan wilayah.

Decide a resource hierarchy for your Google Cloud landing zone

Pada diagram di atas, struktur hierarki sebagai berikut:

• Tingkat pertama terdiri dari folder Subsidiary 1 dan Subsidiary 2, yang mewakili dua anak perusahaan perusahaan tersebut. Folder ini memiliki izin akses dan kebijakan yang berbeda dibandingkan dengan bagian lain dari organisasi. Setiap anak perusahaan menggunakan IAM untuk membatasi akses ke proyek dan resource Google Cloud mereka.
• Folder Holding Group mewakili kelompok-kelompok yang memiliki kebijakan tingkat tinggi yang sama di seluruh wilayah.
• Folder Bootstrap mewakili resource umum yang diperlukan untuk melakukan penyebaran infrastruktur Google Cloud, seperti yang dijelaskan dalam blueprint dasar keamanan.
• Di dalam folder Holding Group, pada tingkat kedua, terdapat folder-folder berikut:
• Folder APAC, EMEA, dan Americas mewakili berbagai wilayah dalam grup tersebut, masing-masing dengan tata kelola, izin akses, dan kebijakan mereka sendiri.
• Folder Shared infrastructure mewakili resource yang digunakan secara global di semua wilayah.
• Setiap folder berisi berbagai proyek yang bertanggung jawab atas resource yang terkait dengan anak perusahaan atau wilayah tersebut.

Folder tambahan dapat ditambahkan untuk memisahkan entitas hukum, departemen, dan tim yang berbeda dalam organisasi.

Hierarki Berdasarkan Kerangka Akuntabilitas

Hierarki berdasarkan kerangka akuntabilitas paling cocok ketika produk Anda beroperasi secara independen, dan unit organisasi memiliki tim yang jelas yang bertanggung jawab atas siklus hidup setiap produk. Dalam organisasi ini, pemilik produk bertanggung jawab atas seluruh siklus hidup produk, termasuk proses, dukungan, kebijakan, dan hak akses. Produk dalam organisasi Anda beragam, dengan hanya sedikit pedoman organisasi yang berlaku.

Pertimbangkan untuk menerapkan hierarki ini ketika kondisi berikut terpenuhi:

• Organisasi Anda memiliki kepemilikan dan akuntabilitas yang jelas untuk setiap produk.
• Beban kerja Anda independen dan tidak membagi banyak kebijakan umum.
• Proses dan platform pengembang eksternal Anda ditawarkan sebagai layanan atau penawaran produk.

Diagram berikut ini menggambarkan contoh hierarki untuk penyedia platform e-commerce.

Decide a resource hierarchy for your Google Cloud landing zone

Diagram di atas menggambarkan struktur hierarki sebagai berikut:

• Tingkat pertama mencakup folder bernama Modul Ecommerce Modules dan Logistics and Warehousing Modules dan Gudang, yang mewakili modul dalam penawaran platform yang membutuhkan izin akses dan kebijakan yang sama sepanjang siklus hidup produk.
• Folder Reconciliation and Billing mewakili tim produk yang bertanggung jawab atas modul-modul end-to-end untuk komponen bisnis tertentu dalam penawaran platform.
• Folder Bootstrap mewakili resource umum yang diperlukan untuk melakukan penyebaran infrastruktur Google Cloud, seperti yang dijelaskan dalam blueprint dasar keamanan.
• Setiap folder berisi berbagai proyek yang menampung modul-modul independen yang dikelola oleh tim produk yang berbeda.

Referensi

https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy