Insinyur produk median harus mempertimbangkan aplikasi sebagai komposit balok Lego fungsional tingkat tinggi di mana detail teknis tingkat rendah tidak terlihat. Tanpa server mewakili abstraksi utama dari pola pikir ini. Mempertimbangkan AWS Lambdanada elevator: “Anda mengatur kode Anda ke dalam fungsi Lambda (yang berjalan) hanya bila diperlukan dan menskalakan secara otomatis. Anda hanya membayar waktu komputasi yang Anda gunakan”. Insinyur bisa lolos tanpa memperhatikan infrastruktur, alokasi sumber daya, manajemen runtime, optimasi biaya, atau masalah serupa seperti mereka tidak mengkhawatirkan algoritma koherensi cache CPU atau jaringan listrik. .
Namun, meskipun terdapat proposisi nilai yang menarik, industri ini beralih ke komputasi tanpa server sebagai pola arsitektur default untuk aplikasi cloud, belum benar-benar terjadi. Sebagai AWS Lambda berusia 10 tahun
November lalu, Will Larson
diposting:
Sesuatu yang masih sulit saya percayai adalah bahwa alur kerja yang kompleks akan dipindahkan ke misalnya AWS Lambda daripada kontainer tanpa kewarganegaraan yang diatur oleh misalnya Amazon EKS. Menurut saya 0-1 masuk akal, tetapi pengoperasian/penskalaan secara efisien tampaknya sulit. (…)
Skeptisisme ini tampaknya beralasan. Pada tahun 2023 Datadog melaporkan adopsi tanpa server tumbuh antara 3-7% di antara penyedia cloud besar, dengan lebih dari 50% pelanggan mereka menggunakan beberapa versinya. Namun, masih ada perjalanan panjang dari “kami menggunakan lambda” menjadi “alur kerja kompleks kami semuanya tanpa server”, dan tingkat pertumbuhan tampaknya terlalu bertahap untuk menunjukkan bahwa eksodus akan segera terjadi. Tren umum dari perangkat lunak memakan dunia adalah penjelasan yang lebih sederhana dan masuk akal untuk tingkat pertumbuhan tersebut, terutama dengan AI yang memberikan tekanan pada biaya dan overhead kognitif untuk menghasilkan potongan-potongan kecil kode yang spesifik untuk tujuan tertentu (titik terbaik untuk tanpa server). Jika tidak, angka-angka tersebut tidak benar-benar menandakan adanya migrasi massal.
Apa saja sumber gesekan terhadap serverless?
Pada bagian ini akan dibahas dua faktor. Pertama, kelelahan akibat pergeseran paradigma terakhir ke layanan mikro (istilah yang akan saya gunakan sebagai singkatan untuk arsitektur yang didasarkan pada layanan kecil yang digabungkan secara longgar dengan konteks terbatas). Transisi tersebut jauh lebih sulit dari yang diperkirakan karena ketidakmatangan dalam peralatan, infrastruktur, dan juga adanya kesenjangan kritis antara kesiapan teknis dan organisasi. Kedua, meskipun beberapa orang mungkin menganggap industri ini terlalu konservatif, kehati-hatian sebenarnya masuk akal karena tanpa server akan memperburuk tantangan yang sama seperti yang ditimbulkan oleh layanan mikro (banyak di antaranya masih belum terselesaikan sepenuhnya).
Sindrom layanan mikro pasca-trauma
Sebuah tren teknologi bisa saja mempunyai arah yang benar, namun arah tidak banyak bicara mengenai waktu, dan hal inilah yang membuat sebagian besar orang merasa kecewa. Para pengguna awal sama-sama menanggung sebagian biaya yang harus dikeluarkan industri untuk mematangkan suatu teknologi, jadi, setiap migrasi menyiratkan taruhan bahwa rasio biaya/manfaat akan berhasil karena kesenjangan kematangan sudah cukup kecil, atau karena teknologi baru akan memberikan manfaat yang sangat besar. manfaat.
Layanan mikro memberikan contoh kanonik tentang betapa mudahnya salah mengkalibrasi taruhan itu. Sejak tren dimulai ~15 tahun yang laluarsitektur ini terbukti efektif untuk memecahkan masalah nyata dalam skala, keandalan, atau produktivitas. Namun juga menunjukkan ketergantungan yang besar pada infrastruktur penahan beban dan kompetensi organisasi yang belum ada pada saat itu. FAANG dan penyedia layanan mensubsidi peralatan dan infrastruktur. Industri lainnya mengeluarkan uang mereka sendiri untuk proyek-proyek dunia nyata di mana solusi diuji pada kasus penggunaan yang lebih panjang dan satu generasi insinyur dilatih mengenai hal tersebut. (Buat perkiraan Anda sendiri mengenai berapa % pendanaan industri teknologi yang mungkin digunakan untuk proyek “menghancurkan monolit”.)
Sisi positif dari gelembung layanan mikro adalah mensosialisasikan biaya pendewasaan teknologi. Pada tahun 2025 kita menikmati basis pengetahuan kolektif mengenai manfaat, trade-off, risiko dan, khususnya, kontraindikasi (mengetahui kapan bukan menggunakan suatu teknologi merupakan penanda kedewasaan yang baik, dan penting bahwa baru dalam beberapa tahun terakhir dikatakan bahwa monolit biasanya merupakan titik awal yang lebih baik). Sisi negatifnya adalah, jika dipikir-pikir lagi, banyak organisasi lebih memilih untuk tidak mengikuti bagian pengujian pertempuran, dan menunggu di sisi kurva adopsi yang membosankan.
Tren tanpa server mungkin juga tepat arahnya. Namun pengambil keputusan teknis yang mempertimbangkan untuk mensponsori migrasi akan merasa khawatir karena salah mengkalibrasi taruhan tersebut dan meremehkan biaya yang menunggu untuk menjembatani kesenjangan kedewasaan yang tersisa. Dengan bekas luka microservice yang masih segar, dan direndam dalam a
pasca-ZIRP
lingkungan ekonomi, hal ini sudah merupakan proposisi yang berisiko.
Di manakah kompleksitas peralihan ke tanpa server?
Infrastruktur penahan beban
Model mental yang naif untuk transisi ke tanpa server melibatkan penempatan setiap layanan mikro ke dalam talenan dan memecah komponen logis penyusunnya menjadi kumpulan fungsi yang lebih kecil. Pada ketinggian tinggi, hal ini tidak membuat perubahan mendasar: blok Lego yang berfungsi secara konseptual sama baik diimplementasikan sebagai titik akhir dalam layanan mikro atau fungsi lambda. Namun mobil listrik dan mobil pembakaran secara konsep sama, setidaknya sampai Anda mencoba mengisi bahan bakar.
Abstraksi tingkat tinggi selalu didukung oleh infrastruktur penahan beban yang mungkin (dan seharusnya) tidak terlihat, namun tidak pernah relevan. Transisi ke mobil listrik bergantung pada adaptasi atau pembangunan kembali jaringan distribusi energi yang dianggap remeh pada mobil pembakaran. Transisi ke layanan mikro bergantung pada penyediaan tumpukan infrastruktur teknis baru untuk memecahkan masalah sistem terdistribusi yang muncul segera setelah komunikasi antar blok Lego dilakukan melalui jaringan dan bukan melalui motherboard (yaitu: format on-wire, latensi, keandalan, data integritas, penemuan layanan, penerapan, kemampuan observasi, pemecahan masalah, dll.). Dengan cara yang sama, memecah layanan mikro menjadi lambda menyiratkan lompatan jauh dari sebagian besar infrastruktur penahan beban sebelumnya.
Contoh dasarnya adalah kerangka injeksi ketergantungan
Belati, Kawat Google, Uber FXatau sepatu bot musim semiyang menyederhanakan pengkabelan dependensi di antara segelintir komponen internal yang membentuk layanan mikro pada umumnya. Setelah komponen-komponen tersebut terpecah menjadi kumpulan lambda, cakupannya meluas dari masalah sempit pembukuan referensi lokal dalam suatu proses, ke masalah pengorganisasian sumber daya cloud menggunakan API cloud mentah.
Percakapan serupa muncul di banyak domain lain selain kerangka aplikasi: observabilitas, pengiriman berkelanjutan, dll. Mendukung peralatan dan infrastruktur untuk arsitektur stateless tidak cukup untuk mendukung arsitektur besar tanpa server. Membangun abstraksi yang memiliki tujuan khusus untuk mengisi kesenjangan tersebut merupakan tantangan teknik yang menarik, namun setiap pengambil keputusan yang mempertimbangkan migrasi ke tanpa server akan melihatnya sebagai tanggung jawab yang merepotkan, dengan biaya yang tidak pasti, dan dengan terlalu banyak peluang untuk mengunci kapasitas teknik yang mungkin diperlukan. lebih baik digunakan untuk tujuan menghasilkan pendapatan.
Kesiapan organisasi
Menutup kesenjangan kematangan teknis bukan hanya soal membangun alat, namun juga mempersiapkan individu dan organisasi untuk menerapkannya secara efektif. Pada tahun 2010-an, Netflix menjadi salah satu rujukan utama dalam menerapkan layanan mikro dalam skala besar berkat open source yang luas. portofolio alat dan infrastruktur internal. Arsitek cloud mereka saat itu, Adrian Cockcroft, berkata dalam a Retrospektif layanan mikro tahun 2023: “mungkin (…) kami menemukan sesuatu dan membaginya dengan orang-orang dan beberapa orang membawanya pulang dan mencoba menerapkannya sebelum organisasi mereka benar-benar siap.”
Sebagian besar organisasi menginginkan kecepatan dan pertumbuhan. Namun memperkenalkan inovasi teknis yang mengoptimalkan skala, kecepatan, dan produktivitas memberikan tekanan pada organisasi untuk terus melakukan dan menegosiasikan kembali trade-off seputar struktur pengambilan keputusan, dinamika komunikasi, kemampuan operasional, toleransi risiko, standar kualitas, dan faktor serupa agar tetap bertahan. selaras dengan aspek teknis semata.
Menurut pengalaman saya, kesiapan organisasi ini memiliki kelambatan signifikan yang paling sering terlihat pada jalur pengiriman. Saat ini sangat mudah untuk menemukan sistem teknis yang terlihat di papan tulis seperti struktur kanonik layanan independen dan terdesentralisasi di atas segalanya. kartu bingo perkakas modern. Namun di balik permukaan, banyak yang menyembunyikan proses pengiriman monolitik di mana tim yang seharusnya otonom dipaksa untuk melakukan parade perubahan secara bersamaan melalui masa-masa sulit yang memerlukan banyak pemeliharaan melalui lingkungan “dev”, “staging” atau “pre-prod” di mana rangkaian pengujian yang luas memvalidasi masing-masing tim. perubahan terhadap keseluruhan sistem sebelum mencapai produksi. Model ini jelas memiliki masalah skalabilitas yang membatalkan sebagian besar potensi arsitektur layanan mikro (dan terkadang memperburuk keadaan). Namun membuat organisasi yang lebih luas mau menerima cara-cara lain dalam merencanakan, mengembangkan, menguji, menyampaikan, dan mengoperasikan sistem terdistribusi yang kompleks adalah hal yang sulit.
Tanpa server memperkuat tantangan layanan mikro
Diagram “Death Star” yang umum digunakan pada awal tahun 2010-an mewakili peningkatan kompleksitas yang melekat pada arsitektur layanan mikro. Jika tanpa server menyiratkan bahwa masing-masingnya terpecah menjadi fungsi lambda yang sangat granular, maka aplikasi tersebut menjadi Death Star of Death Stars, yang pasti akan memperburuk masalah yang sama yang telah dihadapi industri ini selama ~15 tahun terakhir. Masalah teknis mungkin dapat diselesaikan melalui investasi besar pada peralatan dan infrastruktur, namun hanya sedikit organisasi yang bersedia mengambil bagian tanpa batas dari biaya tersebut. Memperbaiki kerangka mental individu dan kolektif yang dapat menerapkan dan mengoperasikannya secara efektif akan memakan waktu lebih lama.
Apa saja vektor yang efektif untuk adopsi tanpa server?
Angin kencang dapat berarti bahwa migrasi beban kerja secara besar-besaran tidak mungkin terjadi dalam jangka pendek-menengah. Ini tidak berarti bahwa tanpa server tidak memiliki proposisi nilai yang solid (Simon Wardley telah mengartikulasikannya kasusnya beberapa
kali), sehingga masih layak untuk menemukan vektor adopsi yang memungkinkan dilakukannya langkah-langkah bertahap yang selektif, berisiko rendah. Cetak biru saya pada dasarnya adalah ini:
- Fokus pada domain yang dimiliki oleh tim yang sepenuhnya otonom, yang sudah fasih dalam mengembangkan, menerapkan, menguji pengoperasian semua perangkat lunak mereka secara independen dari anggota organisasi lainnya, dan di mana pemangku kepentingan produk sama-sama merasa nyaman dengan otonomi tersebut.
- Memigrasikan beban kerja yang sudah ada yang memiliki cakupan logika yang baik dan mandiri, tidak memerlukan manajemen status yang rumit, memiliki lalu lintas tingkat rendah hingga menengah, dan profil bursty yang sesuai dengan trade-off biaya/kinerja tanpa server (paragraf tersebut berfungsi sebagai prompt ke LLM favorit Anda, yang akan mengeluarkan beberapa kombinasi tugas latar belakang yang digerakkan oleh peristiwa, perekat untuk orkestrasi ringan, alur otentikasi pengguna, dll.)
- Integrasi AI dan LLM layak mendapatkan kategorinya sendiri. Seperti yang saya sebutkan di atas, ini cukup memenuhi semua properti di atas, cenderung muncul dalam konteks yang lebih eksperimental dan mengurangi ketergantungan lama. Dengan Agen AI yang menjadi topik tren tahun 2025, jenis arsitektur yang dijelaskan dalam Anthropic’s “Membangun agen yang efektif” cocok untuk gabungan bisnis kecil yang dikemas dalam fungsi.
Saya akan menutup dengan menyoroti argumen utama dalam kasus Simon Wardley tentang tanpa server:
Masa depan mengkhawatirkan hal-hal seperti aliran modal melalui aplikasi Anda, di mana uang sebenarnya dibelanjakan dan apa fungsinya, memantau aliran modal tersebut, mengaitkannya dengan nilai sebenarnya yang Anda ciptakan (…) Tiba-tiba, kita punya penagihan berdasarkan fungsi, kita dapat melihat aliran modal dalam aplikasi, kita dapat mengaitkan nilai dengan biaya sebenarnya.” (sumber)
Sejauh insentif utama untuk adopsi tanpa server secara luas bukanlah bersifat teknis, melainkan finansial, maka sponsornya kemungkinan besar tidak berasal dari departemen teknik. Ini mempunyai implikasi yang tidak sepele, tapi saya akan meninggalkannya untuk lain waktu.
Ada pemikiran? kirimi saya email!
