3.11 Arsitektur cloud

Tinjauan dan motivasi

Komputasi awan (cloud) adalah menyewa infrastruktur milik orang lain sesuai permintaan, lewat jaringan, ditagih sesuai pemakaian, dan dilepas ketika selesai. Arsitektur cloud adalah disiplin merancang sistem yang memperlakukan sumber daya sewaan itu sebagai rumah aslinya, bukan sebagai salinan sewaan dari pusat data lama Anda. Pembedaan itulah inti bab ini. Anda dapat memindahkan aplikasi warisan ke penyedia cloud dan tidak mengubah apa pun dari desainnya, dan Anda akan mendapat tagihan lebih besar dengan kerapuhan yang kurang lebih sama. Atau Anda dapat merancang untuk cloud dan mendapat elastisitas, layanan terkelola yang menghapus seluruh kategori pekerjaan tak terdiferensiasi, serta kemampuan selamat dari kegagalan seluruh gedung tanpa memanggil siapa pun lewat pager. Ini bertumpu langsung pada dasar-dasar di bab 3.1: arsitektur cloud adalah arsitektur, dengan trade-off dan atribut kualitas yang sama, diterapkan pada substrat yang tidak Anda miliki.

Bagi tim besar taruhannya lebih tinggi karena cloud merombak siapa mengerjakan apa. Ketika tim dapat menyediakan basis data, antrean, dan load balancer global dalam hitungan menit, hambatan berhenti menjadi pengadaan dan menjadi tata kelola: biaya, keamanan, dan konsistensi di puluhan tim yang melakukannya sekaligus. Cloud memberi setiap insinyur kartu kredit perusahaan dan gudang perkakas listrik, yang sama-sama luar biasa dan berbahaya. Mendapatkan arsitektur yang tepat berarti menangkap sisi baiknya (kecepatan, elastisitas, ketahanan) sambil memasang pagar pembatas yang menjaga pengeluaran, postur keamanan, dan residensi data tetap terkendali.

Enterprise dan pemerintah merasakan kedua sisinya dengan tajam. Enterprise datang dengan sistem lama puluhan tahun, sehingga kisah cloud mereka biasanya kisah migrasi, penuh konektivitas hibrida dan keputusan beli-versus-bangun yang sulit. Pemerintah memikul beban tambahan berupa kedaulatan, rezim otorisasi, dan data warga yang secara hukum tidak boleh meninggalkan perbatasan tertentu. Keputusan di sini (model layanan mana, berapa penyedia, di mana domain kegagalan berada, apa yang berjalan sebagai layanan terkelola versus kode Anda sendiri) membentuk biaya dan risiko selama satu dekade.

Prinsip utama

Rancang untuk cloud, jangan memotret pusat data Anda. Elastisitas, layanan terkelola, dan kesadaran domain kegagalan adalah alasan untuk berada di sini; lift-and-shift membuangnya.
Segalanya disediakan sebagai kode. Jika manusia mengeklik sesuatu menjadi ada, ia tak terdokumentasi, tak dapat diulang, dan tak dapat diaudit.
Rancang lintas domain kegagalan dengan sengaja. Wilayah, zona ketersediaan, dan layanan gagal; arsitektur Anda yang menentukan apakah itu angkat bahu atau pemadaman.
Model tanggung jawab bersama adalah kontrak, bukan slogan. Ketahui persis garis mana yang diamankan penyedia dan garis mana yang Anda amankan.
Beli yang tak terdiferensiasi, bangun yang membedakan. Layanan terkelola bernilai uang nyata untuk perpipaan; jaga keunggulan kompetitif Anda di tangan sendiri.
Lock-in adalah biaya untuk dihargai, bukan dosa untuk dihindari. Portabilitas punya harga dan pengaruh punya nilai; putuskan dengan sengaja, bukan secara refleks.
Biaya adalah atribut kualitas kelas satu. Di cloud, arsitektur dan faktur adalah keputusan yang sama.

Rekomendasi

Pilih model layanan dengan sengaja, dan jadikan terkelola sebagai bawaan

Penyedia cloud menjual sepanjang spektrum yang ditangkap model as-a-service: Infrastructure as a Service (IaaS) menyewa komputasi, penyimpanan, dan jaringan mentah; Platform as a Service (PaaS) menyewa runtime terkelola sehingga Anda men-deploy kode tanpa merawat server; Software as a Service (SaaS) menyewa aplikasi jadi. Komputasi serverless, termasuk fungsi dan layanan berbasis peristiwa terkelola, mendorong ini lebih jauh: Anda menyuplai kode atau konfigurasi dan penyedia menangani semua penyediaan, berskala ke nol saat menganggur. Setiap langkah naik spektrum menukar kendali dengan pengungkit, dari IaaS dengan kendali terbanyak dan beban operasional terbanyak hingga serverless dengan keduanya paling sedikit.

Bawaannya harus naik setinggi mungkin pada spektrum itu sejauh persyaratan Anda mengizinkan. Basis data terkelola yang menangani penambalan, cadangan, failover, dan penskalaan hampir selalu penggunaan insinyur yang lebih baik daripada yang dijalankan sendiri. Sisihkan IaaS tingkat rendah untuk kasus yang benar-benar membutuhkannya: perangkat keras khusus, batas kepatuhan yang tidak biasa, kendala lisensi, atau kinerja yang tak dapat dipenuhi penawaran terkelola. Tuliskan alasannya sebagai catatan keputusan arsitektur (bab 3.1), karena “kami menjalankan broker pesan sendiri” adalah klaim yang harus dibenarkan ulang setiap tahun.

Rancang lintas wilayah dan zona ketersediaan sebagai domain kegagalan eksplisit

Wilayah cloud adalah area geografis; di dalamnya, zona ketersediaan adalah pusat data yang terpisah secara fisik dengan daya, pendinginan, dan jaringan independen, cukup dekat untuk replikasi latensi rendah namun cukup jauh sehingga satu yang gagal tidak menjatuhkan yang lain. Inilah jahitan tempat cloud patah, jadi arsitektur Anda harus memperlakukannya sebagai kelas satu. Garis dasar untuk beban kerja serius apa pun adalah multizona: sebar komputasi dan data lintas setidaknya dua, idealnya tiga, zona agar kehilangan satu menurunkan kapasitas alih-alih menyebabkan pemadaman. Ini asuransi murah yang jarang punya alasan baik untuk dilewatkan.

Multiwilayah adalah keputusan yang lebih berat, terkait sasaran ketahanan dan pemulihan Anda (bab 3.5) dan rencana pemulihan bencana (bab 9.5). Menyebar lintas wilayah membeli keselamatan dari kegagalan seluruh wilayah dan dapat menempatkan data lebih dekat ke pengguna, tetapi memperkenalkan biaya, latensi, dan masalah konsistensi nyata, karena replikasi sinkron lintas wilayah lambat dan replikasi asinkron berarti menerima kehilangan data saat failover. Putuskan berdasarkan sasaran waktu pemulihan dan titik pemulihan yang eksplisit, bukan keinginan samar untuk “sangat tersedia.” Kebanyakan sistem membutuhkan multizona yang kokoh dan jalur pemulihan multiwilayah yang teruji; sedikit yang benar-benar membutuhkan active-active lintas wilayah, dan yang membangunnya tanpa membutuhkan membayar kompleksitas itu setiap hari.

Perlakukan model tanggung jawab bersama sebagai batas arsitektural

Keamanan cloud berjalan di atas model tanggung jawab bersama: penyedia mengamankan cloud (fasilitas fisik, hypervisor, internal layanan terkelola) dan Anda mengamankan apa yang Anda taruh di cloud (data, kendali akses, konfigurasi jaringan, dan kode Anda). Garis persisnya bergeser saat Anda naik spektrum layanan. Dengan IaaS Anda menambal sistem operasi; dengan basis data terkelola tidak, tetapi Anda tetap memiliki siapa yang dapat terhubung dan apakah data terenkripsi. Insiden termahal datang dari salah membaca garis ini, yang paling terkenal bucket penyimpanan terbuka yang membocorkan jutaan catatan karena seseorang mengira penyedia membuatnya privat secara bawaan.

Buat batas itu eksplisit dalam desain Anda dan serahkan detailnya ke bab 4.3, yang membahas keamanan infrastruktur dan cloud secara mendalam. Secara arsitektural, keharusannya konstan: enkripsi data saat disimpan dan saat transit secara bawaan, beri hak istimewa paling sedikit lewat identitas alih-alih posisi jaringan, jaga radius ledakan satu kredensial tetap kecil, dan asumsikan sumber daya yang dapat dijangkau internet apa pun akan diperiksa dalam hitungan menit. Tanamkan ini ke landing zone Anda agar tim mewarisinya.

Sediakan segalanya sebagai kode, di dalam landing zone yang diatur

Dalam praktik cloud yang matang, tidak ada sumber daya produksi yang ada karena seseorang mengeklik konsol. Segalanya dideklarasikan dalam infrastruktur sebagai kode (bab 8.2), dikontrol versinya, ditinjau, dan diterapkan lewat pipeline, sehingga infrastruktur Anda dapat direproduksi, diaudit, dan dibandingkan. Inilah yang membuat multizona, multiwilayah, dan pemulihan bencana nyata alih-alih aspiratif: Anda dapat mendirikan lingkungan identik di wilayah baru karena lingkungan adalah program, bukan ingatan.

Bungkus kode itu dalam landing zone: fondasi terkelola yang sudah dibangun berisi akun (atau langganan atau proyek), jaringan, identitas, pencatatan, dan pagar pembatas yang menjadi dasar setiap tim. Gunakan akun terpisah sebagai batas radius ledakan dan penagihan, agar kesalahan satu tim tidak dapat menjangkau data tim lain dan setiap dolar terlacak ke pemilik. Tegakkan pagar pembatas sebagai policy-as-code yang mencegah konfigurasi terlarang (basis data publik, volume tak terenkripsi, sumber daya di wilayah yang tak diizinkan) alih-alih bergantung pada tinjauan setelah kejadian. Tim platform pusat biasanya memiliki landing zone, menghubungkan bab ini dengan rekayasa platform (bab 8.4) dan kontainer serta runtime cloud-native (bab 8.3).

Hargai lock-in dengan jujur, dan skeptislah terhadap multi-cloud

Vendor lock-in adalah biaya berganti penyedia, dan ia spektrum, bukan biner. Memakai antrean terkelola penyedia menciptakan sedikit lock-in; memakai platform pembelajaran mesin proprietarinya menciptakan banyak. Ketakutan refleksif terhadapnya mendorong tim mengorbankan pengaruh nyata (layanan terkelola yang membuat cloud layak dipakai) demi menjaga portabilitas yang tak akan pernah mereka gunakan. Langkah jujurnya adalah menghargainya: untuk setiap dependensi signifikan, perkirakan berapa sebenarnya biaya meninggalkannya dan timbang terhadap apa yang dihemat layanan itu sekarang. Mengabstraksikan layanan terkelola agar tetap portabel sering memakan biaya lebih, secara permanen, daripada migrasi yang Anda asuransikan.

Inilah mengapa multi-cloud sejati (menjalankan beban kerja yang sama di dua penyedia) biasanya kultus kargo alih-alih strategi. Ia memaksa Anda turun ke penyebut persekutuan terendah, menggandakan permukaan operasional, dan melipatgandakan keahlian yang harus dipegang tim, semuanya untuk melindungi risiko yang jarang terwujud. Ada alasan sah untuk menyentuh lebih dari satu penyedia: SaaS terbaik di kelasnya dari vendor kedua, mandat ketahanan regulator, atau persyaratan kedaulatan yang disengaja (bab 10.11). Cloud hibrida, menjaga sebagian sistem on-premises yang terhubung ke cloud, sering tak terhindarkan selama migrasi enterprise dan untuk data yang secara hukum tidak dapat pindah. Pilih ini dengan mata terbuka dan pembenaran tertulis, bukan karena slide mengatakan “multi-cloud.”

Rancang untuk biaya, dan adopsi pemikiran well-architected

Di cloud, keputusan arsitektural adalah keputusan pengeluaran: penyediaan berlebih “untuk jaga-jaga” muncul di faktur bulan depan. Perlakukan biaya sebagai atribut kualitas yang Anda rancang, dan adopsi praktik FinOps, disiplin akuntabilitas finansial bersama atas pengeluaran cloud (bab 9.4), agar rekayasa, keuangan, dan produk memiliki tagihan bersama. Beri tag setiap sumber daya dengan pemilik, buat biaya terlihat per tim dan per layanan, right-size secara berkelanjutan, gunakan autoscaling agar Anda membayar untuk beban alih-alih untuk puncak, dan manfaatkan tuas harga (diskon penggunaan-terkomitmen, kapasitas spot untuk pekerjaan yang dapat diinterupsi) yang ditawarkan cloud.

Di luar biaya, gunakan kerangka well-architected sebagai daftar periksa tinjauan. Penyedia utama masing-masing menerbitkannya, dan mereka konvergen pada pilar yang sama: keandalan, keamanan, optimasi biaya, efisiensi kinerja, keunggulan operasional, dan keberlanjutan. Jalankan tinjauan ringan saat desain dan berkala sesudahnya, menilai sistem terhadap setiap pilar dan mencatat celah sebagai pekerjaan yang dilacak. Ini cara murah menangkap trade-off yang tidak Anda sadari.

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
Lift-and-shift (rehost)	Cepat, upaya awal rendah, keluar dari pusat data dengan cepat	Mempertahankan kerapuhan lama, melewatkan elastisitas dan layanan terkelola, sering lebih mahal
Desain ulang cloud-native	Elastisitas penuh, ketahanan, pengungkit layanan terkelola	Upaya dan keterampilan di muka lebih tinggi; perubahan lebih besar untuk diserap
Satu cloud, integrasi dalam	Kesederhanaan, pengungkit maksimum, permukaan operasional lebih rendah	Lock-in dan risiko penyedia terkonsentrasi
Multi-cloud (beban kerja sama, dua penyedia)	Perlindungan dari kegagalan penyedia, daya tawar	Desain penyebut persekutuan terendah, ops dan keahlian berlipat ganda
Hibrida (cloud plus on-premises)	Memenuhi kendala residensi data dan warisan, migrasi bertahap	Kompleksitas jaringan, dua model operasi dijalankan sekaligus
Serverless / sangat terkelola	Toil minimal, berskala ke nol, pengiriman cepat	Kendali lebih sedikit, khusus penyedia, batas cold-start dan kuota

Ketegangan pusatnya adalah kendali versus pengungkit, dan ia mengalir melalui setiap baris. Semakin banyak yang Anda serahkan kepada penyedia, semakin cepat Anda bergerak dan semakin sedikit Anda mengoperasikan, dengan biaya kopling yang lebih dalam. Penyelesaiannya bukan memilih satu kutub melainkan menempatkan setiap beban kerja dengan sengaja: naik tinggi pada spektrum terkelola untuk perpipaan komoditas, tetap lebih rendah di tempat kendali benar-benar layak, dan hargai lock-in ke kedua arah alih-alih memperlakukan portabilitas sebagai gratis dan ketergantungan sebagai dosa. Organisasi besar mendapat masalah ketika membiarkan rasa takut (terhadap lock-in, cloud, biaya) membuat pilihan ini secara refleks alih-alih lewat analisis.

Pertanyaan untuk didiskusikan dengan tim Anda

Beban kerja kita yang mana yang di-lift-and-shift, dan apakah kita membayar harga cloud untuk arsitektur pusat data? Lazim bermigrasi di bawah tenggat, merehost segalanya apa adanya, dan menyatakan kemenangan, lalu menemukan tagihan lebih tinggi daripada pusat data dan tak satu pun manfaat ketahanan atau elastisitas terwujud. Audit jujurnya mendaftar beban kerja utama Anda dan menandai masing-masing sebagai di-rehost, di-re-platform, atau benar-benar didesain ulang, lalu melihat mana yang masih berjalan pada jejak ukuran tetap, selalu hidup, dan satu zona. Sebagian lift-and-shift adalah langkah pertama yang sah, jadi pertanyaannya bukan apakah Anda melakukannya melainkan apakah Anda punya rencana dan garis waktu untuk melangkah lebih jauh. Bawa biaya per beban kerja dan riwayat insiden, karena beban kerja yang sekaligus mahal dan rapuh adalah tempat desain ulang membayar kembali tercepat. Jika segalanya masih berbentuk seperti pusat data lama setahun setelah migrasi, Anda membeli pusat data yang lebih mahal.
Ketika zona ketersediaan atau seluruh wilayah gagal, apa yang sebenarnya terjadi, dan sudahkah kita mengujinya? Banyak tim percaya mereka tangguh karena men-deploy ke cloud, tanpa pernah merancang domain kegagalan mereka atau mencabut steker untuk memeriksa. Versi konkretnya: untuk setiap sistem kritis, berapa zona yang dicakupnya, berapa sasaran waktu pemulihan dan titik pemulihan terdokumentasinya, dan kapan terakhir kita menjalankan game day yang menggagalkan zona atau melatih pemulihan wilayah? Multizona seharusnya garis dasar yang biasa saja, jadi beban kerja kritis satu zona mana pun adalah temuan; multiwilayah adalah keputusan yang lebih berat dan mahal, terkait sasaran pemulihan eksplisit, tidak diadopsi secara bawaan. Bawa peta dependensi Anda, karena kegagalan yang menyakitkan biasanya layanan bersama (basis data, penyedia identitas) yang domain kegagalannya tak dipetakan siapa pun. Ketahanan yang tak pernah Anda uji adalah hipotesis, bukan properti.
Untuk dependensi penyedia terbesar kita, berapa sebenarnya biaya meninggalkannya, dan apakah itu harga yang layak dibayar untuk dihindari? Perdebatan lock-in cenderung berjalan atas ideologi alih-alih angka, dengan satu kubu mengabstraksikan setiap layanan terkelola agar tetap portabel dan kubu lain mengabaikan risiko konsentrasi sepenuhnya. Pijakkan: pilih tiga dependensi terdalam Anda, perkirakan biaya rekayasa nyata dan waktu berlalu untuk mengganti masing-masing, dan timbang terhadap apa yang dihemat layanan hari ini dan seberapa mungkin Anda pernah berpindah. Lapisi risiko yang tidak diperbaiki portabilitas, seperti regulator yang menuntut sumber kedua atau aturan kedaulatan tentang di mana data boleh berada, karena itu dapat membenarkan multi-cloud atau hibrida meski ekonomi murni tidak. Tujuannya posisi tertulis yang disengaja per dependensi, bukan kebijakan menyeluruh. Begitu dihargai, kebanyakan lock-in yang ditakuti ternyata lebih murah diterima daripada lapisan abstraksi yang dibangun untuk menghindarinya.
Layanan apa yang kita jalankan sendiri yang dengan senang hati dioperasikan penyedia untuk kita, dan berapa biaya pilihan itu dalam jam insinyur? Seluruh pengungkit cloud adalah menyerahkan penambalan, cadangan, failover, dan penskalaan kepada seseorang yang pekerjaan penuh waktunya adalah hal-hal itu, namun tim rutin mempertahankan basis data, broker pesan, atau klaster pencarian yang dijalankan sendiri karena kebiasaan atau kebanggaan yang keliru. Bagi organisasi besar biayanya bukan toil satu tim melainkan operasi tak terdiferensiasi yang sama diciptakan ulang di selusin sudut, masing-masing rotasi on-call dan sumber penyimpangan. Pertimbangan yang bersaing itu nyata: perangkat keras khusus, ketentuan lisensi, batas kepatuhan yang tidak biasa, atau kinerja yang tak dapat dipenuhi penawaran terkelola dapat membenarkan tetap lebih rendah pada spektrum, jadi jawabannya per layanan alih-alih menyeluruh. Bawa inventaris layanan yang dioperasikan sendiri, jam insinyur yang dimakan masing-masing dalam pemeliharaan dan insiden, dan harga alternatif terkelola, dan wajibkan catatan keputusan arsitektur untuk setiap “kami menjalankan sendiri” yang dibenarkan ulang tiap tahun. Dalam lingkungan enterprise dan pemerintah, tambahkan apakah pilihan menjalankan sendiri benar-benar kendala kepatuhan atau lisensi atau sekadar inersia yang menyamar sebagai itu, karena auditor dan pemilik anggaran akan menanyakan hal yang sama.
Dapatkah kita melihat berapa biaya setiap tim dan layanan bagi kita bulan ini, dan apakah seseorang yang bernama merasa bertanggung jawab atas angka itu? Pengeluaran cloud membengkak diam-diam karena swalayan yang sama yang memungkinkan insinyur menyediakan basis data global dalam hitungan menit juga memungkinkan mereka membiarkannya berjalan pada ukuran puncak selamanya, dan tak ada satu baris faktur pun yang tampak mengkhawatirkan. Dalam organisasi besar tanpa visibilitas biaya per tim dan per layanan, keuangan menemukan masalah berbulan-bulan terlambat dan reaksinya pembekuan tumpul yang menghukum yang disiplin bersama yang boros. Ketegangannya nyata: mengejar setiap dolar memperlambat pengiriman, sehingga tujuannya akuntabilitas dan right-sizing, bukan penghematan keras, dengan biaya diperlakukan sebagai atribut kualitas yang Anda rancang alih-alih laporan yang dibaca setelah kejadian. Bawa rincian biaya per tim, bagian pengeluaran yang tanpa tag atau tak dapat diatribusikan, utilisasi saat ini terhadap kapasitas yang disediakan, dan di mana diskon penggunaan-terkomitmen atau kapasitas spot dibiarkan terbuang. Untuk enterprise dan badan pemerintah, kaitkan ini dengan praktik FinOps dan pengawasan belanja publik, karena sumber daya tanpa tag bukan sekadar pemborosan melainkan temuan audit yang menunggu terjadi.
Dapatkah sebuah tim mendirikan penyimpanan data publik, volume tak terenkripsi, atau sumber daya di wilayah terlarang sekarang juga, dan akankah kita bahkan mengetahuinya? Insiden cloud termahal kebanyakan salah konfigurasi, bukan pembobolan penyedia, dan model tanggung jawab bersama berarti bucket penyimpanan yang bocor atau basis data terbuka ke internet berada tepat di sisi garis Anda. Mencegah ini pada skala banyak tim adalah pertanyaan landing zone: pagar pembatas yang ditegakkan sebagai policy-as-code yang memblokir konfigurasi terlarang sebelum ada, alih-alih tinjauan setelah kejadian yang menemukannya setelah catatan sudah bocor. Tekanan yang bersaing adalah otonomi pengembang, karena pagar pembatas yang terlalu ketat mendorong tim ke akun bayangan, sehingga desain harus mencegah yang benar-benar berbahaya sambil menyisakan ruang bergerak. Bawa inventaris pagar pembatas yang benar-benar ditegakkan, upaya jujur menyediakan sumber daya tak patuh di akun nyata, dan jeda deteksi ketika pencegahan gagal. Dalam konteks teregulasi dan pemerintah, kaitkan ini dengan residensi data dan rezim otorisasi, karena sumber daya di wilayah yang tak diizinkan bukan pelanggaran gaya melainkan pelanggaran hukum yang akan diperlakukan auditor sebagai peristiwa yang harus dilaporkan.

Lensa sektor

Startup. Pilih cloud-native pada satu penyedia sejak hari pertama dan terima lock-in dengan sengaja. Jalankan di serverless dan layanan terkelola yang berskala ke nol dan biarkan dua insinyur memiliki seluruh platform, karena sumber daya Anda yang paling langka adalah perhatian, bukan portabilitas. Batasi pengeluaran dengan keras, simpan segalanya dalam infrastruktur-sebagai-kode agar momen viral tidak menjadi pemadaman, dan tuliskan keputusan lock-in yang disengaja untuk ditinjau pada skala besar alih-alih berpura-pura ia sementara.

Bisnis kecil. Tanpa insinyur platform dan dengan anggaran ketat, perlakukan cloud sebagai sesuatu yang Anda konsumsi alih-alih operasikan. Pilih SaaS dan layanan terkelola penuh daripada apa pun yang Anda jalankan sendiri, bersandarlah pada bawaan aman penyedia, dan biarkan basis data terkelola menangani cadangan dan failover agar tak seorang pun harus melakukannya. Bingkai pilihan sebagai beli-versus-bangun dengan ibu jari kuat di beli, setel peringatan tagihan agar sumber daya yang terlupakan tidak dapat menguras bulan itu, dan raih opsi kode-rendah atau terkelola sebelum mendirikan server yang tak sanggup Anda isi stafnya.

Enterprise. Kisah cloud Anda adalah kisah migrasi lintas banyak tim, jadi arsitekturnya sesungguhnya masalah tata kelola. Dirikan landing zone terkelola dengan akun per unit sebagai batas radius ledakan dan penagihan, pagar pembatas terenkripsi-secara-bawaan, dan policy-as-code yang memblokir penyimpanan data publik, dan biarkan tim platform pusat memiliki fondasi itu. Jalankan FinOps dengan showback per tim, gerbangi desain signifikan dengan tinjauan well-architected, dan kelola konektivitas hibrida ke sistem pencatat warisan yang tidak akan pindah selama bertahun-tahun.

Pemerintah. Aturan pengadaan, transparansi, dan kedaulatan membentuk setiap keputusan. Deploy ke wilayah cloud yang berotorisasi atau pemerintah, dokumentasikan garis batas tanggung jawab bersama baris demi baris untuk auditor, dan kunci penyimpanan dan pemrosesan ke zona dalam negeri dengan policy-as-code yang memblokir sumber daya apa pun di wilayah yang tak diizinkan. Kejar rezim otorisasi yang dituntut, simpan bukti audit sebagai riwayat git alih-alih perebutan, dan pilih layanan terkelola yang postur kepatuhannya akan dibuktikan penyedia daripada infrastruktur pesanan yang harus Anda sertifikasi sendiri.

Contoh

Startup. Sebuah startup beranggotakan dua belas orang membangun cloud-native sejak hari pertama pada satu penyedia dan tidak merasa bersalah. API berjalan pada fungsi serverless yang berskala ke nol semalaman, data hidup di Postgres terkelola dengan cadangan otomatis dan failover multizona, dan pekerjaan latar belakang berjalan pada antrean terkelola. Semuanya didefinisikan dalam infrastruktur-sebagai-kode, dan dua insinyur memiliki seluruh platform karena penyedia mengoperasikan bagian-bagian sulitnya. Ketika momen viral membuat lalu lintas naik lima puluh kali lipat dalam satu jam, autoscaling menyerapnya dan tagihan naik sebanding dengan pemakaian nyata, lalu turun lagi. Para pendiri dengan sengaja menerima lock-in sebagai harga bergerak cepat dengan tim kecil, dan mereka menuliskan keputusan itu untuk ditinjau pada skala besar.

Enterprise. Sebuah perusahaan asuransi multinasional dengan tiga ratus aplikasi warisan menjalankan migrasi multitahun yang diatur oleh “6 R” (rehost, re-platform, repurchase, refactor, retire, retain). Aplikasi komoditas bernilai rendah di-rehost dengan cepat untuk keluar dari dua pusat data sesuai tenggat; platform polis inti direfaktor menjadi cloud-native; perkakas buatan sendiri dibeli ulang sebagai SaaS; dan sistem usang dipensiunkan. Tim platform pusat memiliki landing zone dengan akun per unit bisnis, pagar pembatas terenkripsi-secara-bawaan, dan policy-as-code yang memblokir penyimpanan data publik, sementara konektivitas hibrida menghubungkan cloud ke sistem pencatat mainframe yang tidak akan pindah selama bertahun-tahun. Biaya diatur lewat praktik FinOps dengan showback per unit, dan tinjauan well-architected menggerbangi peluncuran produksi setiap aplikasi.

Pemerintah. Sebuah lembaga nasional yang menyampaikan layanan tunjangan warga secara hukum wajib menjaga data penduduk di dalam perbatasan nasional dan berjalan di infrastruktur berotorisasi. Ia men-deploy ke wilayah cloud pemerintah penyedia dan mengejar otorisasi di bawah rezim seperti FedRAMP di Amerika Serikat (dengan pekerjaan kepatuhan di bab 4.6), mendokumentasikan batas tanggung jawab bersama baris demi baris untuk auditor. Residensi data dan kekhawatiran kedaulatan yang lebih luas (bab 10.11) mendorong arsitektur yang mengunci penyimpanan dan pemrosesan ke zona dalam negeri dan memblokir, lewat policy-as-code, sumber daya apa pun di wilayah yang tak diizinkan. Sistem mencakup tiga zona ketersediaan dengan rencana pemulihan lintas zona yang teruji dan menyediakan segalanya sebagai kode, sehingga bukti audit adalah riwayat git alih-alih perebutan.

Kasus bisnis: motivasi, ROI, dan TCO

Janji utama cloud adalah mengubah belanja modal menjadi belanja operasional: alih-alih membeli server bertahun-tahun mendahului permintaan dan menjalankannya pada utilisasi rendah, Anda membayar untuk apa yang Anda pakai dan berskala bersama bisnis. Itu nyata, tetapi imbal hasil yang lebih dalam adalah kecepatan dan fokus. Layanan terkelola yang menghapus penambalan, cadangan, dan failover mengembalikan jam insinyur itu ke pekerjaan produk, dan penyediaan dalam menit alih-alih bulan memampatkan waktu dari gagasan ke produksi. Elastisitas berarti Anda berhenti membayar kapasitas puncak yang dipakai dua kali setahun. Ketika arsitektur tepat, ini berlipat menjadi total biaya kepemilikan yang mengalahkan pusat data baik dalam biaya maupun kemampuan.

Biaya salah melakukannya sama nyatanya, jadi kasus bisnis harus jujur. Lift-and-shift tanpa desain ulang sering menaikkan biaya sambil tidak memberikan manfaat apa pun, dan pengeluaran tak terkelola dapat membengkak diam-diam di puluhan tim sampai keuangan membunyikan alarm. Bingkai kasus kepada pimpinan di sekitar tiga tuas: kecepatan (pengiriman lebih cepat dan penyediaan lebih singkat), ketahanan (insiden besar lebih sedikit dan lebih pendek), dan opsionalitas (memasuki pasar atau wilayah baru tanpa proyek pusat data). Beri angka pada refresh pusat data yang dihindari, headcount yang berkurang untuk infrastruktur komoditas, dan menit pemadaman yang dicegah, dan hadapkan dengan biaya migrasi serta investasi FinOps dan platform yang berkelanjutan. Argumen terkuat jarang penghematan biaya mentah; melainkan nilai opsi dari bergerak lebih cepat daripada pesaing yang masih menunggu perangkat keras.

Anti-pola dan jebakan

Lift-and-shift lalu menyebutnya “cloud.” Merehost desain pusat data ke infrastruktur sewaan menangkap biayanya dan tak satu pun manfaatnya.
Infrastruktur yang diklik di konsol. Sumber daya yang dibuat dengan tangan tak dapat diulang, tak terdokumentasi, dan mustahil dipulihkan atau diaudit; perlakukan perubahan produksi manual apa pun sebagai cacat.
Multi-cloud kultus kargo. Menjalankan beban kerja yang sama di dua penyedia untuk melindungi risiko yang jarang, membayar dengan kompleksitas dan desain penyebut persekutuan terendah setiap hari.
“Ketersediaan tinggi” satu zona. Percaya cloud tangguh secara bawaan sambil menjalankan beban kerja kritis di satu zona tanpa failover teruji.
Salah membaca tanggung jawab bersama. Mengasumsikan penyedia mengamankan apa yang sebenarnya Anda miliki, jalan klasik menuju bucket publik yang membocorkan jutaan catatan.
Biaya sebagai renungan belakangan. Merancang tanpa memperhatikan pengeluaran, lalu menemukan faktur telah membuat keputusan arsitektural Anda.

Model kematangan

Tingkat 1, Memulai: Penggunaan cloud ad hoc dan reaktif. Tim mengeklik sumber daya menjadi ada di akun bersama, beban kerja di-lift-and-shift, dan tidak ada landing zone, tidak ada visibilitas biaya, dan ketahanan diasumsikan alih-alih dirancang. Pemadaman serius pertama atau kejutan tagihan adalah kejutan.
Tingkat 2, Mengembangkan: Praktik dasar muncul tetapi bervariasi menurut tim. Sebagian infrastruktur inti disediakan sebagai kode dan sebagian beban kerja berjalan multizona, beberapa akun dipisahkan, tetapi cakupannya tidak merata: pilihan model layanan dan lock-in dibuat karena kebiasaan, biaya dipantau setelah kejadian, pagar pembatas tidak konsisten, dan pemulihan multiwilayah tidak teruji.
Tingkat 3, Membakukan: Landing zone terkelola dengan pagar pembatas policy-as-code terdokumentasi dan ditegakkan di seluruh organisasi. Tim platform memiliki fondasi, segala yang produksi disediakan sebagai kode, tinjauan well-architected menggerbangi desain signifikan, dan keputusan beli-versus-bangun serta domain kegagalan disengaja dan dicatat konsisten di setiap tim.
Tingkat 4, Mengelola: Properti diukur dan dikendalikan terhadap garis dasar. Biaya per tim dan per layanan dilacak lewat FinOps terhadap target, sasaran waktu pemulihan dan titik pemulihan diverifikasi alih-alih ditegaskan, pelanggaran pagar pembatas dan penyimpangan konfigurasi dimunculkan sebagai metrik, right-sizing digerakkan data utilisasi, dan setiap keputusan go atau no-go didukung bukti dari dasbor biaya, keandalan, dan keamanan.
Tingkat 5, Mengorkestrasi: Arsitektur cloud terus diperbaiki dan terintegrasi dengan perencanaan bisnis dan risiko. Domain kegagalan dilatih lewat game day rutin, right-sizing dan harga diotomatisasi, kedaulatan dan residensi ditegakkan oleh kebijakan, posisi model layanan dan lock-in dihargai ulang secara berkala, dan portofolio beban kerja diseimbangkan ulang secara adaptif seiring bergesernya pasar, harga, dan gambaran risiko.

Gagasan untuk didiskusikan

Di mana pada spektrum IaaS-ke-serverless setiap beban kerja utama Anda berada, dan dapatkah ada yang naik lebih tinggi untuk membuang toil operasional tanpa kehilangan kendali yang benar-benar Anda butuhkan?
Jika penyedia utama Anda menaikkan harga tajam atau mengalami pemadaman wilayah berhari-hari, apa rencana nyata Anda, dan apakah itu membenarkan kompleksitas multi-cloud atau hibrida yang Anda bawa?
Siapa yang memiliki landing zone dan pagar pembatasnya, dan dapatkah sebuah tim mengirim sumber daya tak patuh (penyimpanan data publik, volume tak terenkripsi, wilayah tak diizinkan) hari ini?
Untuk beban kerja teregulasi atau berdaulat, dapatkah Anda menghasilkan batas tanggung jawab bersama dan konfigurasi berotorisasi sebagai bukti tanpa latihan darurat?

Poin-poin utama

Rancang untuk cloud alih-alih memotret pusat data Anda; elastisitas, layanan terkelola, dan kesadaran domain kegagalan adalah alasan untuk berada di sini.
Naiklah spektrum model layanan ke arah terkelola dan serverless untuk kerja komoditas, dan pertahankan kendali lebih rendah hanya di tempat ia benar-benar layak biayanya.
Jadikan wilayah dan zona ketersediaan domain kegagalan eksplisit: multizona sebagai garis dasar, multiwilayah terkait sasaran pemulihan yang teruji.
Sediakan segalanya sebagai kode di dalam landing zone terkelola dengan pagar pembatas policy-as-code, akun terpisah, dan tim platform yang memiliki fondasi.
Hargai vendor lock-in dengan jujur ke kedua arah, dan skeptislah terhadap multi-cloud kecuali alasan regulasi, kedaulatan, atau terbaik-di-kelasnya yang konkret menuntutnya.
Perlakukan biaya sebagai atribut kualitas kelas satu lewat FinOps, dan jalankan tinjauan well-architected untuk menangkap trade-off yang terlewat.

Referensi dan bacaan lanjutan

Peter Mell dan Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework dan Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (dan strategi migrasi “6 R”)
J.R. Storment dan Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, dokumentasi program FedRAMP dan garis dasar keamanan
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing