Sementara sebagian besar startup SaaS tahap awal mengelola server dan merencanakan cluster Kubernetes, Enterpret diam-diam melakukan sebaliknya. Tim tersebut, yang saat itu hanya terdiri dari tiga orang, memutuskan untuk membangun platform umpan balik AI tingkat perusahaan terutama di AWS Lambda.
Itu adalah taruhan yang berlawanan. Lima tahun kemudian, hal ini tetap menjadi salah satu keputusan mendasar yang membentuk arsitektur, budaya, dan momentum perusahaan.
Startup yang digerakkan oleh interupsi
Pada awalnya, Enterpret perlu menyerap sejumlah besar data masukan pelanggan — teks, konteks, dan metadata yang datang secara tiba-tiba setiap kali klien menyinkronkan data historis atau saat acara publik menjadi viral. Perhitungan berat dilakukan pada akuisisi dan revisi; Pertanyaan sebenarnya yang dihadapi pengguna relatif ringan.
Persediaan modal terbatas, apalagi kapasitas teknik. “Kami tidak memiliki kemewahan komputasi yang selalu aktif,” kenang kepala arsitek Anshal Dwivedi.
Lambda menawarkan sesuatu yang tidak dapat dilakukan oleh komputasi tradisional: fleksibilitas tanpa hambatan biaya. Anda hanya membayar ketika terjadi sesuatu. Menganggur adalah menganggur.
Enterpret diluncurkan dengan delapan layanan mikro dan sekitar 35 fungsi Lambda, area permukaan yang kecil, namun cepat untuk dikembangkan. Hal ini memungkinkan tim untuk bergerak cepat, tanpa membakar landasan infrastruktur.
Yang membuat keputusan ini penting bukanlah komitmen awal terhadap tanpa server; Pihaknya sengaja merancang jalan keluar. Jika beban kerja memerlukan hal lain, migrasi ke ECS hanya memerlukan pertukaran pembungkus penerapan. Logika bisnis tidak akan tersentuh.
Dia akan menjadi salah satu pilihan terpenting yang dibuat oleh tim visioner.
Monorepo yang menjaga sistem tetap konsisten
Seiring dengan meluasnya jejak produk, Perusahaan menghadapi masalah baru: mengelola pengembangan tanpa memisahkan basis kode. Jawabannya adalah keputusan lain yang bertentangan dengan saran startup konvensional – monorepo tunggal untuk setiap layanan mikro backend, perpustakaan bersama, dan konfigurasi infrastruktur.
Alih-alih kekacauan, hal ini memberikan konsistensi.
Perubahan pada model dapat dilakukan satu kali, ditinjau satu kali, dan diterapkan di mana saja. Kode kesalahan, format logging, dan standar penelusuran tetap konsisten di seluruh layanan—sebuah keuntungan dalam sistem terdistribusi di mana proses debug biasanya melibatkan spelunking ke dalam repo dan aliran log.
Refactoring menjadi rutin, tidak berisiko. Pemeriksaan tipe tingkat IDE mencegah jeda senyap. Penerapannya tetap dapat diprediksi.
Monorepo yang sama kini memiliki 26 layanan, naik dari delapan layanan sebelumnya. Dengan penerapan yang dilakukan beberapa kali dalam seminggu, tim bergerak cepat karena infrastruktur yang mendasarinya tidak pernah rusak.
Lapisan RPC ringan yang masih utuh
Dengan sangat cepat, tim mengalami keterbatasan: AWS API Gateway tidak mendukung gRPC secara asli, namun Enterpret memerlukan lapisan komunikasi kompak dan mengutamakan biner yang kompatibel dengan Lambda.
Jalur umum akan melibatkan adopsi atau penerapan struktur berat. Sebaliknya, mereka membuat abstraksi RPC ramping yang mendukung banyak pengkodean — Protobuf melalui HTTP untuk efisiensi, JSON untuk fleksibilitas, dan kompatibilitas untuk gRPC downstream.
Butuh waktu berhari-hari, bukan berbulan-bulan, untuk membentuknya. Namun masih tetap menjadi tulang punggung komunikasi layanan. Kompresi, penelusuran terdistribusi, metrik, dan pembuatan klien dilakukan berlapis-lapis tanpa menyentuh layanan individual – yang merupakan efek gabungan yang kini sengaja dioptimalkan oleh tim.
Ketika Lambda berhenti merespons dengan benar
Pengembangan akhirnya mengungkap keterbatasan tanpa server.
Analisis frontend mengungkapkan celah pertama; Cold menambahkan latensi yang nyata ketika dasbor menjalankan lusinan kueri paralel. Konkurensi yang disediakan akan mengurangi latensi, namun bukan berarti membuat sistem menjadi lebih mahal untuk dijalankan. Memigrasikan beban kerja tersebut ke ECS telah mengurangi P95 dan biaya yang menyertainya.
Pekerjaan lama menyusul. Batas waktu 15 menit Lambda berfungsi untuk sebagian besar tugas asinkron, namun pembuatan laporan dan ekspor membutuhkan lebih banyak ruang untuk bernapas. Enterpret beralih ke AWS Batch yang didukung oleh instans Spot, sehingga mencapai fleksibilitas yang sama dengan biaya yang lebih murah.
Ada batasan lain seperti batas muatan Lambda sebesar 6 MB, batas waktu API Gateway sebesar 29 detik. Tim mengatasi hal ini dengan pembongkaran respons berbasis S3 dan pengelompokan permintaan, namun pelajaran yang didapat jelas: alat yang tepat berubah seiring waktu.
Karena cara tim merancang sistem, migrasi jarang ditulis ulang. Seringkali, itu adalah satu jam.
Disiplin biaya sebagai filosofi
Dalam fase kecepatan bootstrap, biaya bukanlah sebuah metrik namun sebuah batasan kelangsungan hidup. Tafsirkan semua yang diaudit: alokasi memori, komputasi idle, cold start, obrolan lintas layanan. Banyak fungsi Lambda yang masih berjalan pada 128MB, dimungkinkan oleh efisiensi Go.
Pada suatu saat, tagihan CloudWatch melebihi total pembelanjaan komputasi. Hal ini tidak berakar pada idealisme tetapi pada realitas operasional, kebersihan auditabilitas yang ketat, ambang batas peringatan, tinjauan penagihan, dan pilihan arsitektur.
Disiplin macet.
Playbook Enterpret sekarang memberikan yang lain
Melihat ke belakang, Dwivedi mengatakan perusahaan akan mengambil pilihan yang sama lagi. Kecepatan pengiriman tanpa server, pengendalian biaya, dan fokus saat tim sangat membutuhkannya. Monorepo, abstraksi RPC, desain siap migrasi, semuanya akan tetap sama.
Namun perusahaan akan lebih berhati-hati dalam menerapkan beban kerja yang tidak terkait dengan Lambda. Sebelumnya, salah satu layanan pengumpulan datanya perlu berjalan dalam waktu lama, sehingga tim menggabungkannya dengan fungsi langkah AWS dan logika pos pemeriksaan untuk melewati waktu tunggu. Itu berhasil, tetapi sulit untuk mempertahankannya. AWS Batch seharusnya menjadi keputusan yang tepat sejak hari pertama.
Nasihatnya kepada tim teknik lainnya bermuara pada beberapa prinsip:
Jaga agar infrastruktur tetap sederhana. Enterpret tidak menjadi tuan rumah satu infrastruktur pun selama empat tahun. Layanan terkelola dan teknologi yang membosankan selalu mengalahkan solusi cerdas. “Startup yang bertahan bukanlah startup yang memiliki infrastruktur yang cerdas; mereka adalah startup yang tetap fokus pada produk mereka sementara cloud melakukan pekerjaan berat,” kata Dwivedi.
Bersikaplah kejam terhadap biaya. Hal ini berdampak langsung pada landasan pacu. Tetapkan peringatan pengeluaran, tinjau tagihan mingguan, pertanyakan setiap item baris. Kebocoran kecil bercampur dengan pendarahan.
Desain untuk skala horizontal sejak hari pertama. Perbedaan upaya yang dirasakan antara “cepat dan kotor” dan “dapat diskalakan” sering kali hanya berupa ilusi. Beberapa abstraksi yang baik dan batasan layanan yang jelas memerlukan waktu lebih lama dibandingkan sebelumnya, namun menghemat waktu Anda untuk menulis ulang nanti.
Jangan terlalu cepat mengejar agnostisisme cloud. Perusahaan berkomitmen penuh terhadap AWS. Saat Anda membatasi diri pada apa yang berhasil di mana pun, Anda mengoptimalkan untuk penyebut terkecil yang umum. Anda mendapatkan sistem yang lebih baik dengan mengadopsi keunggulan cloud Anda, bukan apa yang dilakukan setiap cloud secara memadai.
Lima tahun kemudian, arsitekturnya masih bertahan.
Perjalanan berlanjut
Saat ini, Enterpret memproses jutaan catatan umpan balik pelanggan. Banyak sistem yang ditulis tim pada tahun pertama masih berjalan – tidak hanya berjalan, namun terus berkembang. Mereka telah berevolusi, berkembang, dan beradaptasi karena tim menemukan ambang batas campuran tersebut sejak dini dan tetap menggunakannya.
Perusahaan ini kini membangun arsitektur agen, mendorong bidang-bidang baru mengenai apa yang dapat dilakukan AI dengan umpan balik pelanggan. Lanskapnya terus berkembang, dan tim masih mempelajari apa yang berhasil.
“Beberapa pola perjalanan tanpa server kami diterjemahkan dengan indah. Pola lainnya perlu dipikirkan ulang sepenuhnya,” kata Dwivedi.
Pelajarannya bukanlah bahwa tanpa server adalah jawaban untuk semua orang. Keputusan-keputusan kecil dan bijaksana itulah yang bertambah seiring berjalannya waktu. Rancang sistem yang berkembang, bukan menyebar. Pilihlah kejelasan daripada kepintaran. Dan ketika Anda mencapai batas suatu teknologi, bermigrasilah; Jangan menulis ulang.
Ini hanya sekilas tentang apa yang dilakukan Enterpret. Baca lebih lanjut tentang hal ini di blog teknik mereka Di Sini.
