Apa itu infrastruktur yang tidak dapat diubah?

Organisasi dapat mengelola infrastruktur melalui dua pendekatan: dapat diubah dan tidak dapat diubah. Infrastruktur yang tidak dapat diubah menggantikan server sepenuhnya, tidak memodifikasinya. Infrastruktur yang dapat diubah memodifikasi server yang ada, menerapkan pembaruan, tambalan, dan perubahan konfigurasi secara langsung ke server produksi.

Karena infrastruktur ini terutama memodifikasi server yang ada, infrastruktur yang dapat berubah dapat tampak lebih efisien. Namun, dua faktor sering membuat infrastruktur yang tidak dapat diubah lebih praktis dan lebih disukai.

Pertama, komputasi cloud dan kontainerisasi telah mengubah kecepatan penerapan. Organisasi sekarang dapat mengganti mesin virtual (VM) dan kontainer dalam hitungan menit, bukan berjam-jam seperti yang diperlukan untuk server fisik. Alat otomatisasi infrastruktur dapat menyediakan dan mengonfigurasi server dan sumber daya TI baru serta menerapkan perubahan yang seragam dalam skala besar.

Kedua, infrastruktur yang tidak dapat diubah dapat secara signifikan mengurangi penyimpangan konfigurasi, sebuah fitur umum dari infrastruktur yang dapat diubah, di mana sebuah sistem secara bertahap menyimpang dari kondisi yang seharusnya seiring dengan perubahan yang terakumulasi. Penyimpangan konfigurasi sangat umum terjadi ketika masalah jaringan mengganggu proses penerapan, menyebabkan pembaruan sebagian atau gagal. Penyimpangan ini dapat menyebabkan kinerja yang buruk, kerentanan keamanan, dan pelanggaran kepatuhan. 

Misalnya, saat menerapkan pembaruan keamanan di 100 server produksi, otomatisasi dapat membuat 100 server baru dengan pembaruan yang sudah diinstal sebelumnya dan memvalidasi server ini secara terpisah. Setelah divalidasi, mereka mengarahkan lalu lintas dan menonaktifkan server lama—semuanya dalam hitungan menit tanpa waktu henti.

Infrastruktur yang tidak dapat diubah mengikuti alur kerja tiga fase: menyediakan sumber daya baru, menerapkan, dan mengaktifkan pemulihan instan bila diperlukan.

Alur kerja ini berlaku untuk server, kontainer, VM, fungsi, atau sumber daya infrastruktur lainnya di sepanjang siklus hidupnya.

Penyediaan secara otomatis membuat komponen infrastruktur TI baru yang menggunakan infrastruktur sebagai kode (IAC)—praktik yang menggunakan templat deklaratif atau kode untuk menentukan status infrastruktur yang dimaksud.

Untuk memperbarui lingkungan yang tidak dapat diubah, tim membuat sumber daya yang sama sekali baru dengan konfigurasi yang ditentukan alih-alih menggunakan SSH (protokol jaringan untuk akses server jarak jauh yang aman) untuk memodifikasi sumber daya yang sudah ada. 

Semua perubahan infrastruktur kemudian didokumentasikan dalam sistem kontrol versi seperti Git, untuk memastikan perubahan tersebut teruji dan dapat direproduksi.

Alat penyediaan umum meliputi: 

• Terraform: Platform infrastruktur sebagai kode dari HashiCorp menyediakan dan mengelola infrastruktur di seluruh AWS, Google Cloud, Azure dan on premises melalui API mereka, dengan sintaksis HCL deklaratif dan file status untuk melacak perubahan.

• Docker: Membangun gambar kontainer ringan berdasarkan sistem file berlapis dan virtualisasi tingkat OS, terutama pada sistem Linux tetapi juga Windows dan macOS, yang memungkinkan penerapan lebih cepat daripada VM tradisional.

• Packer: Alat HashiCorp yang membuat gambar mesin identik secara bersamaan untuk beberapa penyedia cloud dan platform (AMI untuk AWS, templat VMware, kontainer Docker) dari konfigurasi tunggal JSON atau HCL.

• AWS CloudFormation: Alat asli AWS berdasarkan templat JSON/YAML untuk menyediakan sumber daya AWS dengan rollback dan deteksi penyimpangan bawaan. 

• Pulumi: Platform IaC yang menggunakan bahasa pemrograman yang sudah dikenal (Python, TypeScript, Go) alih-alih bahasa khusus domain, sehingga pengembang dapat menggunakan konstruksi pemrograman standar seperti perulangan dan bersyarat.

Perlu disebutkan bahwa Puppet dan Chef pada awalnya dirancang untuk infrastruktur yang dapat diubah, di mana mereka memperbarui server yang ada, meskipun beberapa tim sekarang mengadaptasikannya di samping pendekatan yang tidak dapat diubah.

Penerapan dalam infrastruktur yang tidak dapat diubah bersifat atomik—mereka berhasil sepenuhnya atau tidak terjadi sama sekali. Pendekatan ini selaras dengan praktik DevOps dan saluran integrasi berkelanjutan, yang menekankan pengujian otomatis, iterasi cepat, dan penerapan yang andal.

Alat otomatisasi menerapkan versi baru sumber daya, mengarahkan lalu lintas ke sana, lalu menonaktifkan yang lama. Jika masalah muncul selama penerapan, sumber daya lama tetap tidak tersentuh dan beroperasi, sehingga menghilangkan risiko waktu henti dan ketergantungan.

Alat penerapan dan orkestrasi umum meliputi: 

• Kubernetes: Platform orkestrasi kontainer sumber terbuka yang mengelola aplikasi cloud native dalam kontainer dalam skala besar melalui penyembuhan mandiri, penskalaan otomatis, dan pembaruan bergulir di seluruh klaster mesin.

• Jenkins: Saluran CI/CD berbasis server yang mengotomatiskan pembuatan, pengujian, dan penerapan dengan ekosistem plug-in yang ekstensif (lebih dari 1.800 plug-in) untuk menyesuaikan saluran pembuatan, pengujian, dan penerapan.

• Tindakan GitHub: Platform CI/CD berbasis peristiwa yang dibangun ke dalam repositori GitHub, dipicu oleh penerapan kode, permintaan penarikan, atau jadwal tanpa memerlukan server eksternal.

• Ansible (Red Hat): Fungsi utama adalah alat manajemen konfigurasi, tetapi juga digunakan untuk penerapan. Alat ini menggunakan pedoman YAML untuk otomatisasi tanpa agen dan tidak memerlukan instalasi perangkat lunak pada node yang dikelola, tidak seperti Puppet atau Chef. 

Karena server dalam infrastruktur yang tidak dapat diubah bersifat fana—diganti secara konstan—data persisten harus disimpan secara eksternal. Organisasi menggunakan layanan cloud databases, block storage, atau object storage untuk memelihara data secara terpisah dari server yang diganti. 

Ketika server baru online, server tersebut terhubung kembali ke data yang ada melalui sistem penyimpanan eksternal ini. Konfigurasi dan metadata sering berada di sistem kontrol versi seperti Git. 

Setiap pembaruan membuat instans baru, mempertahankan gambar sederhana untuk rollback. Alat otomatisasi yang sama yang menyediakan dan menerapkan dapat memulihkan versi sebelumnya dalam hitungan menit. Tim menyebarkan ulang gambar sebelumnya alih-alih melakukan debug dan pemecahan masalah pada server yang dimodifikasi — sangat mengurangi pekerjaan detektif yang secara tradisional diperlukan ketika perubahan manajemen konfigurasi gagal.

Manfaat dari infrastruktur yang tidak dapat diubah sebagian besar terkait dengan proses penerapan, di mana imutabilitas membuatnya lebih sederhana dan lebih konsisten.

Infrastruktur yang tidak dapat diubah menghilangkan status server yang ambigu melalui penerapan atomik—pembaruan bisa berhasil sepenuhnya atau tidak sama sekali.

Infrastruktur yang dapat diubah berisiko mengalami pembaruan parsial yang mengarah pada kondisi "antara" yang tidak dapat diprediksi, dengan karakteristik yang tidak sepenuhnya diketahui oleh administrator. Situasi ini dapat membuat pemecahan masalah menjadi sulit dan meningkatkan risiko keamanan.

Infrastruktur yang tidak berubah menghilangkan kemungkinan keadaan seperti itu. Jika pembaruan gagal, server tetap dalam keadaan terdokumentasi dengan baik. Jika berhasil, server baru akan dikonfigurasi dan diuji sepenuhnya.

Infrastruktur yang tidak dapat diubah membantu memungkinkan penskalaan horizontal cepat, praktik memenuhi permintaan dengan menambahkan sejumlah besar mesin yang lebih kecil ke jaringan (bukan dari satu mesin besar). Sistem yang diskalakan secara horizontal lebih toleran terhadap kesalahan dan dapat mengurangi kemacetan pemrosesan dengan mendistribusikan beban kerjanya.

Pendekatan ini dicapai dengan menggunakan penyeimbang beban yang mendistribusikan lalu lintas jaringan di beberapa server untuk meningkatkan kinerja. Berbagai alat seperti Nginx dan AWS Elastic Load Balancing (ELB) dari Amazon membantu mendukung praktik ini dengan menggunakan algoritma untuk menetapkan permintaan pengguna ke server yang paling efisien pada saat tertentu.

Kombinasi penyeimbangan beban dan orkestrasi kontainer ini menjadikan infrastruktur yang tidak dapat diubah, dengan templat yang dapat direproduksi, sangat penting untuk menyiapkan beberapa server yang sama dalam waktu singkat. Pengaturan ini bisa sangat berguna ketika jaringan mengalami lonjakan lalu lintas yang sangat besar, seperti selama periode promo belanja atau penjualan tiket. Hal ini juga membantu ketika berkoordinasi di seluruh wilayah global di mana lalu lintas mencapai puncaknya pada jam yang berbeda dan terkadang tumpang tindih.

Infrastruktur yang tidak dapat diubah memperkuat keamanan dengan menghilangkan "kondisi kepingan salju" yang tidak dapat diprediksi — server dengan konfigurasi yang tidak diketahui setelah pembaruan yang gagal — dan mempertahankan jejak audit lengkap dari semua perubahan.

Setiap server sama persis dengan file gambar sumber yang menggambarkannya, sehingga lebih mudah untuk mengidentifikasi kerentanan keamanan—seperti instalasi perangkat lunak yang tidak sah atau eskalasi hak istimewa—dan menjalankan audit keamanan. Sistem kontrol versi melacak setiap perubahan yang dilakukan pada sistem, termasuk siapa yang membuatnya, kapan, dan mengapa. Riwayat yang tidak dapat diubah ini memungkinkan analisis forensik yang lebih cepat dan respons insiden. Tim dapat segera mengidentifikasi konfigurasi yang disusupi dan kembali ke status yang diketahui baik jika perlu.

Infrastruktur yang tidak dapat diubah juga menghilangkan kebutuhan untuk menggunakan login Secure Shell (SSH) untuk mengedit server yang ada, sehingga mengurangi permukaan serangan jaringan secara keseluruhan.

Imutabilitas juga memiliki kelemahan dibandingkan dengan infrastruktur yang lebih tradisional dan dapat diubah, terutama dalam hal penyimpanan data.

Dalam infrastruktur yang dapat diubah, server mungkin menulis data aplikasi penting ke disk lokal—membuatnya berbahaya atau berpotensi merusak sistem untuk menghapus dan mengganti server dan disk itu. Oleh karena itu, dalam infrastruktur yang tidak dapat diubah, data harus disimpan secara eksternal yang menambah tingkat kerumitan pada sistem.

Metode ini dapat dilakukan dengan menggunakan penyimpanan data eksternal seperti cloud databases, block storage, atau object storage. Ketika mesin virtual baru online, mesin virtual tersebut dapat terhubung kembali dengan data yang ada melalui penyimpanan ini dengan lancar. Organisasi umumnya mempertahankan konfigurasi dan metadata dalam sistem kontrol versi seperti Git.

Namun, “imutabilitas” sebenarnya dari infrastruktur yang tidak dapat diubah terkadang diperdebatkan. Keterbatasan ini disebabkan karena data pengguna jaringan yang disimpan secara eksternal selalu berubah-ubah sehingga tidak dapat dibandingkan dengan kondisi yang sudah diketahui.