Kemampuan ulang untuk masa depan: Mengapa pengembang dan profesional infrastruktur perlu melarikan diri dari zona nyaman mereka

Matthew Finio: Bagaimana hubungan antara pengembang dan profesional infrastruktur berubah?

Miha Kralj: Seluruh profesi pengembangan berubah dengan dimulainya “segala sesuatu yang ditentukan oleh perangkat lunak”—jaringan yang ditentukan oleh perangkat lunak, penyimpanan yang ditentukan oleh perangkat lunak, komputasi yang ditentukan oleh perangkat lunak.

Di masa lalu, kami memiliki orang-orang infrastruktur di sebelah kiri dan orang-orang pengembangan perangkat lunak di sebelah kanan dan mereka hampir tidak berbicara satu sama lain. Satu melayani semua plumbing dan aset yang mendasarinya, dan yang lainnya melakukan semua pengodean dan mewujudkan impian.

Sekarang, semua itu runtuh. Tidak ada pihak yang siap untuk era yang kita jalani sekarang. Dan tidak ada yang memahami keamanan, jadi kita bisa membawanya ke dalam ini juga. Mereka perlu mulai belajar dari satu sama lain, dan itu sulit bagi kedua belah pihak.

Ini seperti buku Who Moved My Cheese—tidak ada pihak yang merasa sangat nyaman jika mereka berasal dari dunia tradisional yang lama. Generasi muda yang tumbuh dengan Gmail dan YouTube hidup di dunia gabungan yang baru. Namun, orang-orang dari sisi infrastruktur tradisional atau pengembangan kesulitan karena mereka tidak mempelajari sisi lain di tahun-tahun awal karir mereka.

MF: Jadi, baik pengembang maupun orang infrastruktur harus memikirkan kembali deskripsi pekerjaan mereka?

MK: Tepat. Pengembang seharusnya tidak lagi berpikir bahwa mereka hanya pengembang aplikasi. Orang-orang infrastruktur seharusnya tidak lagi berpikir bahwa mereka hanya orang-orang operasi. Konstruksi kerja sama tim modern dari lingkungan rekayasa produk berlaku di sini, di mana setiap orang dapat melakukan pekerjaan orang lain jika diperlukan. Masih ada spesialisasi, tetapi seorang pengembang, jika diperlukan, harus dapat terjun dan menulis beberapa skrip Terraform, yang secara tradisional merupakan tugas yang sangat berfokus pada infrastruktur.

Jadi, ketika Anda bertanya kepada seseorang apa pekerjaan mereka, mereka tidak boleh mengatakan “Saya seorang pengembang perangkat lunak” atau “Saya orang infrastruktur/operasional.” Semuanya membangun sebuah produk atau membantu menciptakan layanan dan tidak akan pernah diluncurkan tanpa semua potongan-potongan itu disatukan dengan benar. Setiap orang perlu memahami rantai penuh, siklus hidup penuh, semuanya dari bawah ke atas.

MF: Anda menyebutkan Terraform. Apa saja konsep infrastruktur lain yang perlu dipelajari pengembang?

MK: Para pengembang sering kali tidak memahami secara pasti bagaimana infrastruktur yang mendasarinya bekerja dan apa yang bisa tahan lama, apa yang bisa bersifat sementara.

Jika Anda membuat beberapa perubahan pada host, kontainer, atau komponen tanpa server yang menjalankan sesuatu, apakah perubahan itu akan bertahan ketika komponen tersebut atau mesin virtual berpindah ke tempat lain? Konsep sistem yang menyimpan statusnya di tempat lain, yaitu sistem tanpa status, adalah salah satu konsep dasar yang perlu dipahami oleh para pengembang. Bagaimana Anda membuatnya dapat diskalakan tanpa batas? Bagaimana Anda membuat sistem yang sangat tahan lama dan elastis? Semua konsep arsitektur tersebut diimplementasikan dalam perangkat lunak, tetapi sebenarnya didasarkan pada pola infrastruktur.

Selain itu, penting untuk memahami pola keamanan dalam membuat area permukaan minimum pada kode agar kemungkinan serangan menjadi paling kecil. Juga, penting untuk berkomunikasi dengan benar dengan beberapa layanan jarak jauh. Apakah Anda akan menulis layanan yang cerewet dan mengirimkan seratus pertanyaan setiap detik? Atau Anda lebih memilih mengemas semua permintaan dan mengirimkannya dalam potongan yang lebih besar dan lebih jarang?

Ini adalah keputusan yang sangat penting yang harus diambil oleh setiap pengembang perangkat lunak, tetapi mereka tidak akan mengerti mengapa mereka harus mengambil keputusan tersebut jika mereka tidak memahami hal yang tersembunyi—bagaimana cara kerja sistem yang sebenarnya. Pemahaman sistem dari bawah ke atas sangat penting. Pengembang perlu menulis kode yang baik dan bersih, yang tidak menghambat sistem, tidak mengunci basis data, dan tidak melakukan hal-hal yang merugikan.

Jika Anda kembali ke 20 atau 30 tahun lalu, ada profesi khusus yang mengoptimalkan kueri basis data untuk meminimalkan siklus CPU dan penguncian data. Banyak pengetahuan berharga itu kini hilang. Namun, penting untuk tetap memahami cara membuat sistem berkinerja tinggi dan sistem dengan biaya optimal. Semua pelajaran tersebut tidak boleh dilupakan.

Anda berpikir, “Oh, hei, ini tahun 2025, pak tua, duduklah! Dunia modern benar-benar berbeda. Kamu tidak tahu!” Nah, kami membangun dunia modern ini, dan kami di sini untuk membantu pengembang baru dan orang-orang infrastruktur baru menggunakannya seefisien mungkin.

MF: Dapatkah Anda menjelaskan beberapa cara pengembang dapat menggunakan infrastruktur sebagai alat kode untuk meningkatkan alur kerja mereka?

MK: Ya. Contoh yang bagus adalah bagaimana pengembang dapat membuat alur kerja yang tepat untuk kode mereka agar diuji secara otomatis, kemudian dikompilasi dan dikemas setiap kali mereka membuat bagian kode dan mengirimkannya ke repositori. Pengembang tidak perlu bergantung pada tim infrastruktur untuk melakukan hal itu untuk mereka. Membuat skrip YAML yang baik di GitHub adalah tugas infrastruktur sebagai kode yang bisa dioptimalkan oleh setiap pengembang agar proses tersebut berjalan seefisien mungkin.

Jadi, sebagai contoh, seorang pengembang tidak perlu melakukan pengemasan penuh dan validasi penuh serta pengujian penuh jika mereka hanya duduk di cabang pengembangan. Pengembang tersebut akan berkata, "Hei, saya berada di cabang pengembangan, saya bisa mengabaikan semua 20 tugas yang hanya ditujukan untuk cabang produksi."

Jika Anda berada dalam produksi, Anda perlu melakukan banyak otomatisasi, menjalankan mesin yang melakukan pemeriksaan keamanan penuh dan validasi kode, serta proses lainnya. Setiap keputusan kecil akan memengaruhi seberapa cepat kompilasi selesai dan seberapa cepat Anda melihat hasil setelah membuat kode—setiap pengembang harus bisa mengubah infrastruktur menjadi skrip kode dan menyesuaikannya dengan alur kerja mereka sendiri.

Ini seperti bagaimana para pengembang yang sama ingin menyempurnakan lingkungan pengembangan terintegrasi mereka sendiri. Mereka memilih font, warna, dan pintasan keyboard sesuai preferensi. Mereka juga harus bisa mengonfigurasi alur kerja mereka sendiri—termasuk apa yang terjadi setelah kode dikomit. Itu semua adalah pengetahuan yang berasal dari konsep Infrastruktur sebagai Kode (IaC).

MF: Hal-hal spesifik apa yang harus dipahami oleh para profesional infrastruktur tentang pengembangan aplikasi saat ini?

MK: Infrastruktur sebagai kode—IaC—secara harfiah berarti bahwa orang-orang infrastruktur menjadi pembuat kode. Infrastruktur didefinisikan dengan skrip, data, dan kode, sehingga skrip atau kode infrastruktur harus melalui siklus pengembangan perangkat lunak yang sama dengan kode apa pun yang ditulis oleh pengembang:

• Metode ini didokumentasikan dengan baik.
• Itu perlu disimpan dengan benar ke dalam repositori.
• Solusi ini harus memiliki versi yang tepat.

Itu perlu diperlakukan dengan cara yang sama persis. Orang-orang infrastruktur tradisional tidak memahami hal ini atau mampu melakukannya. Orang-orang infrastruktur dapat mengonfigurasi berbagai hal, klik-klik melalui mouse, dan mungkin mereka dapat menulis beberapa skrip Bash atau semacamnya.

Tetapi sekarang sangat diharapkan bahwa orang-orang infrastruktur adalah pembuat kode infrastruktur yang sebenarnya. Mereka harus memahami Git. Mereka perlu memahami cara melakukan pemindaian keamanan infrastruktur mereka sebagai aset kode. Aset mereka harus memiliki versi yang tepat dan ditinjau oleh rekan kerja, dan mereka perlu memahami konsep pull request. Semua ini adalah persyaratan dan aktivitas standar yang sudah dikenal oleh setiap pengembang perangkat lunak secara default.

Orang-orang infrastruktur perlu menjadi keseluruhan lapisan. Dan insinyur keseluruhan lapisan sulit dibangun dan sulit ditemukan. Ada kekurangan orang yang memahami segala hal secara menyeluruh—mulai dari bagaimana paket data mengalir, cara kerja jaringan—hingga bagaimana kernel dalam sistem operasi berfungsi. Misalnya, bagaimana cara saya benar-benar menulis beberapa dependensi perangkat lunak? Gunakan paket yang bersifat sumber terbuka atau internal? Bagaimana cara menulis kode asinkron? Semua pertanyaan tentang pengembangan perangkat lunak murni. Dua domain besar runtuh menjadi satu. Manajemen perubahan dan keterampilan ulang dan peningkatan keterampilan untuk bakat tidak ada di sana.

MF: Jika pelatihan ulang dan peningkatan keterampilan saja sudah menjadi tantangan, lalu bagaimana para profesional infrastruktur dapat mengikuti perkembangan tren dan teknologi?

MK: Ya, tidak ada lagi orang yang khusus menangani infrastruktur dan orang yang khusus menangani pengembang, semua itu dilebur menjadi satu domain. Mereka semua mempelajari tren-tren baru tersebut-perubahan dalam siklus pengembangan perangkat lunak dan terutama perubahan dengan AI.

Ketika masuk ke pengembangan AI-native, baik tim infrastruktur maupun pengembang aplikasi harus mempelajarinya. Semua orang mengalami FOMO dan merasa tertinggal. Mereka baru saja belajar rekayasa prompt, kini harus belajar menulis agen menggunakan Semantic Kernel atau alat lain.

Orang-orang perlu saling membantu dan menemukan keseimbangan yang tepat. Berapa banyak waktu yang harus dihabiskan untuk tetap mengikuti perkembangan terkini agar tetap memiliki keunggulan? Dulu 5%, sekarang menjadi 10%. AI generatif membantu. Namun, rasio antara waktu yang dibutuhkan untuk belajar dan waktu yang digunakan untuk belajar serta menghasilkan sesuatu yang memberikan nilai bisnis atau nilai TI semakin condong ke arah pembelajaran.

MF: Dan sebelum kita mengakhiri, apa saja hal-hal penting yang harus diingat oleh para pengembang dan profesional infrastruktur tentang aplikasi modern?

MK: Tidak ada tugas terpisah lagi. Aplikasi modern hampir selalu memiliki infrastruktur yang sudah terpasang. Misalnya, pengembang modern menulis kode dan langsung meminta pembuatan kontainer. Tidak ada orang infrastruktur yang membuat kontainer untuk mereka. Beberapa pekerjaan lebih banyak berfokus pada infrastruktur sekaligus pengembangan. Dan beberapa pekerjaan lebih membutuhkan pengembangan perangkat lunak dengan pengetahuan dan akses infrastruktur.

Jadi, yang perlu dipertimbangkan oleh para profesional infrastruktur adalah menjadi pengembang perangkat lunak. Dan hal yang sama untuk pengembang perangkat lunak, mereka perlu menjadi profesional infrastruktur.

Peran-peran tersebut tidak terpisah, melainkan menyatu. Ini mirip dengan kondisi satu dekade atau lebih lalu, ketika setiap tim pengembangan perangkat lunak profesional memiliki pengembang dan penguji yang terpisah. Tidak ada lagi yang membicarakan tentang penguji karena kedua peran tersebut telah digabungkan. Jenis penggabungan dan penggabungan peran yang sama—kali ini antara pengembang dan orang-orang infrastruktur—sedang terjadi sekarang.