Memilih Teknologi Database Tanpa Server Baru Di Agensi (Studi Kasus)

Artikel ini telah didukung dengan baik oleh teman-teman terkasih kami di Fauna yang membuat pekerjaan dengan data operasional menjadi produktif, terukur, dan aman untuk setiap tim pengembangan perangkat lunak. Terima kasih!

Mengadopsi teknologi baru adalah salah satu keputusan tersulit bagi seorang teknolog dalam peran kepemimpinan. Ini sering kali merupakan area risiko yang besar dan tidak nyaman, apakah Anda sedang membangun perangkat lunak untuk organisasi lain atau di dalam organisasi Anda sendiri.

Selama dua belas tahun terakhir sebagai insinyur perangkat lunak, saya mendapati diri saya dalam posisi harus mengevaluasi teknologi baru dengan frekuensi yang meningkat. Ini mungkin kerangka kerja frontend berikutnya, bahasa baru, atau bahkan arsitektur yang sama sekali baru seperti tanpa server.

Fase eksperimen seringkali menyenangkan dan mengasyikkan. Di sinilah para insinyur perangkat lunak paling betah, merangkul kebaruan dan euforia momen "aha" sambil mempelajari konsep-konsep baru. Sebagai insinyur, kami suka berpikir dan mengotak-atik, tetapi dengan pengalaman yang cukup, setiap insinyur belajar bahwa bahkan teknologi yang paling luar biasa pun memiliki kekurangannya. Anda hanya belum menemukan mereka.

Sekarang, sebagai salah satu pendiri agensi kreatif, saya dan tim sering berada dalam posisi unik untuk menggunakan teknologi baru. Kami melihat banyak proyek greenfield, yang menjadi peluang sempurna untuk memperkenalkan sesuatu yang baru. Proyek-proyek ini juga melihat tingkat isolasi teknis dari organisasi yang lebih besar dan seringkali tidak terlalu terbebani oleh keputusan sebelumnya.

Dikatakan demikian, seorang pemimpin agensi yang baik dipercayakan untuk mengurus ide besar orang lain dan menyampaikannya kepada dunia. Kita harus memperlakukannya dengan lebih hati-hati daripada proyek kita sendiri. Setiap kali saya akan membuat panggilan terakhir pada teknologi baru, saya sering merenungkan kebijaksanaan dari salah satu pendiri Stack Overflow Joel Spolski:

"Anda harus berkeringat dan berdarah dengan benda itu selama satu atau dua tahun sebelum Anda benar-benar tahu itu cukup baik atau menyadari bahwa tidak peduli seberapa keras Anda mencoba, Anda tidak bisa..."

Ini adalah ketakutan, ini adalah tempat yang tidak diinginkan oleh pemimpin teknologi. Memilih teknologi baru untuk proyek dunia nyata cukup sulit, tetapi sebagai agensi, Anda harus membuat keputusan ini dengan proyek orang lain, seseorang mimpi orang lain, uang orang lain. Di sebuah agensi, hal terakhir yang Anda inginkan adalah menemukan salah satu cacat itu di dekat tenggat waktu sebuah proyek. Jadwal dan anggaran yang ketat membuat hampir tidak mungkin untuk membalikkan arah setelah ambang batas tertentu dilewati, jadi menemukan teknologi tidak dapat melakukan sesuatu yang kritis atau terlambat dapat diandalkan ke dalam suatu proyek dapat menjadi bencana besar.

Sepanjang karir saya sebagai insinyur perangkat lunak, saya telah bekerja di perusahaan SaaS dan agensi kreatif. Ketika datang untuk mengadopsi teknologi baru untuk sebuah proyek, kedua lingkungan ini memiliki kriteria yang sangat berbeda. Ada kriteria yang tumpang tindih, tetapi pada umumnya, lingkungan lembaga harus bekerja dengan anggaran yang kaku dan batasan waktu yang ketat . Meskipun kami ingin produk yang kami bangun menua dengan baik dari waktu ke waktu, seringkali lebih sulit untuk melakukan investasi pada sesuatu yang kurang terbukti atau untuk mengadopsi teknologi dengan kurva pembelajaran yang lebih curam dan tepi yang kasar.

Meskipun demikian, agensi juga memiliki beberapa batasan unik yang mungkin tidak dimiliki oleh satu organisasi. Kita harus bias untuk efisiensi dan stabilitas. Jam yang dapat ditagih sering kali merupakan unit pengukuran terakhir ketika sebuah proyek selesai. Saya telah berada di perusahaan SaaS di mana menghabiskan satu atau dua hari untuk menyiapkan atau membangun pipa bukanlah masalah besar.

Di sebuah agensi, jenis biaya waktu ini membebani hubungan karena tim keuangan melihat margin keuntungan yang menyempit untuk hasil yang sedikit terlihat. Kami juga harus mempertimbangkan pemeliharaan jangka panjang suatu proyek, dan sebaliknya apa yang terjadi jika suatu proyek perlu diserahkan kembali kepada klien. Oleh karena itu kita harus bias untuk efisiensi, kurva belajar, dan stabilitas dalam teknologi yang kita pilih.

Saat mengevaluasi teknologi baru, saya melihat tiga area menyeluruh:

1. Teknologi
2. Pengalaman Pengembang
3. Bisnis

Masing-masing area ini memiliki serangkaian kriteria yang ingin saya penuhi sebelum saya mulai benar-benar menyelami kode dan bereksperimen. Dalam artikel ini, kita akan melihat kriteria ini dan menggunakan contoh mempertimbangkan database baru untuk sebuah proyek dan meninjaunya pada tingkat tinggi di bawah setiap lensa. Mengambil keputusan nyata seperti ini akan membantu menunjukkan bagaimana kita dapat menerapkan kerangka kerja ini di dunia nyata.

Teknologi

Hal pertama yang harus dilihat saat mengevaluasi teknologi baru adalah apakah solusi tersebut dapat memecahkan masalah yang diklaimnya dapat diselesaikan. Sebelum menyelami bagaimana suatu teknologi dapat membantu proses dan operasi bisnis kami, penting untuk terlebih dahulu memastikan bahwa teknologi tersebut memenuhi persyaratan fungsional kami . Ini juga tempat saya ingin melihat solusi apa yang ada yang kami gunakan dan bagaimana solusi baru ini melawannya.

Saya akan bertanya pada diri sendiri pertanyaan seperti:

1. Apakah ini setidaknya menyelesaikan masalah yang dilakukan oleh solusi saya yang ada?
2. Dengan cara apa solusi ini lebih baik?
3. Dalam hal apa lebih buruk?
4. Untuk daerah yang lebih parah, apa yang diperlukan untuk mengatasi kekurangan tersebut?
5. Apakah itu akan menggantikan banyak alat?
6. Seberapa stabil teknologinya?

Kami Mengapa?

Pada titik ini, saya juga ingin meninjau mengapa kami mencari solusi lain. Jawaban sederhananya adalah kita menghadapi masalah yang tidak dapat dipecahkan oleh solusi yang ada . Namun, hal ini sering jarang terjadi. Kami telah memecahkan banyak masalah perangkat lunak selama bertahun-tahun dengan semua teknologi yang kami miliki saat ini. Apa yang biasanya terjadi adalah kita beralih ke teknologi baru yang membuat sesuatu yang kita lakukan saat ini lebih mudah, lebih stabil, lebih cepat, atau lebih murah.

Mari kita ambil React sebagai contoh. Mengapa kami memutuskan untuk mengadopsi React ketika jQuery atau Vanilla JavaScript melakukan pekerjaan itu? Dalam hal ini, menggunakan kerangka kerja menyoroti bagaimana ini adalah cara yang jauh lebih baik untuk menangani frontend stateful. Menjadi lebih cepat bagi kami untuk membangun hal-hal seperti fitur pemfilteran dan pengurutan dengan bekerja dengan struktur data alih-alih manipulasi DOM langsung. Ini adalah penghematan waktu dan peningkatan stabilitas solusi kami.

TypeScript adalah contoh lain di mana kami memutuskan untuk mengadopsinya karena kami menemukan peningkatan stabilitas kode dan pemeliharaan kami. Dengan mengadopsi teknologi baru, seringkali tidak ada masalah yang jelas yang ingin kita pecahkan, melainkan hanya mencari untuk tetap terkini dan kemudian menemukan solusi yang lebih efisien dan stabil daripada yang kita gunakan saat ini.

Dalam hal database, kami secara khusus mempertimbangkan untuk pindah ke opsi tanpa server . Kami telah melihat banyak keberhasilan dengan aplikasi dan penerapan tanpa server yang mengurangi overhead kami sebagai sebuah organisasi. Satu area di mana kami merasa ini kurang adalah lapisan data kami. Kami melihat layanan seperti Amazon Aurora, Fauna, Cosmos, dan Firebase yang menerapkan prinsip tanpa server ke database dan ingin melihat apakah sudah waktunya untuk melakukan lompatan sendiri. Dalam hal ini, kami ingin menurunkan biaya operasional dan meningkatkan kecepatan dan efisiensi pengembangan kami.

Penting pada tingkat ini untuk memahami alasan Anda sebelum Anda mulai menyelami penawaran baru. Ini mungkin karena Anda memecahkan masalah baru, tetapi jauh lebih sering Anda ingin meningkatkan kemampuan Anda untuk memecahkan jenis masalah yang sudah Anda pecahkan. Dalam hal ini, Anda perlu menginventarisir tempat-tempat yang pernah Anda kunjungi untuk mencari tahu apa yang akan memberikan peningkatan yang berarti pada alur kerja Anda. Berdasarkan contoh kami dalam melihat database tanpa server, kami perlu melihat bagaimana kami saat ini memecahkan masalah dan di mana solusi tersebut gagal.

Dimana kita telah…

Sebagai agensi, kami sebelumnya telah menggunakan berbagai database termasuk namun tidak terbatas pada MySQL, PostgreSQL, MongoDB, DynamoDB, BigQuery, dan Firebase Cloud Storage. Sebagian besar pekerjaan kami berpusat di sekitar tiga database inti: PostgreSQL, MongoDB, dan Firebase Realtime Database. Masing-masing memang, pada kenyataannya, memiliki penawaran semi-server, tetapi beberapa fitur utama dari penawaran yang lebih baru membuat kami mengevaluasi kembali asumsi kami sebelumnya. Mari kita lihat pengalaman historis kita dengan masing-masing ini terlebih dahulu dan mengapa kita dibiarkan mempertimbangkan alternatif di tempat pertama.

Kami biasanya memilih PostgreSQL untuk proyek jangka panjang yang lebih besar, karena ini adalah standar emas yang teruji pertempuran untuk hampir semua hal. Ini mendukung transaksi klasik, data yang dinormalisasi, dan sesuai dengan ACID. Ada banyak alat dan ORM yang tersedia di hampir setiap bahasa dan bahkan dapat digunakan sebagai basis data NoSQL ad-hoc dengan dukungan kolom JSON-nya. Ini terintegrasi dengan baik dengan banyak kerangka kerja, perpustakaan, dan bahasa pemrograman yang ada menjadikannya pekerja keras yang benar-benar dapat dibawa ke mana saja. Itu juga open-source dan karena itu tidak membuat kita terkunci ke salah satu vendor. Seperti yang mereka katakan, tidak ada yang pernah dipecat karena memilih Postgres.

Karena itu, kami secara bertahap menemukan diri kami menggunakan PostgreSQL semakin sedikit karena kami menjadi lebih dari toko yang berorientasi pada Node. Kami telah menemukan bahwa ORM untuk Node kurang bersemangat dan membutuhkan lebih banyak kueri khusus (walaupun ini sekarang menjadi kurang bermasalah) dan NoSQL merasa lebih cocok secara alami saat bekerja dalam runtime JavaScript atau TypeScript. Karena itu, kami sering memiliki proyek yang dapat diselesaikan dengan cukup cepat dengan pemodelan relasional klasik seperti alur kerja e-niaga. Namun, berurusan dengan pengaturan lokal database, menyatukan aliran pengujian di seluruh tim, dan menangani migrasi lokal adalah hal-hal yang tidak kami sukai dan dengan senang hati kami tinggalkan karena NoSQL, database berbasis cloud menjadi lebih populer.

MongoDB semakin menjadi database masuk kami karena kami mengadopsi Node.js sebagai back end pilihan kami. Bekerja dengan MongoDB Atlas memudahkan pengembangan cepat dan pengujian database yang dapat digunakan tim kami. Untuk sementara, MongoDB tidak sesuai dengan ACID, tidak mendukung transaksi, dan tidak mendukung terlalu banyak operasi seperti penggabungan dalam, sehingga untuk aplikasi e-niaga kami masih menggunakan Postgres paling sering. Karena itu, ada banyak perpustakaan yang menyertainya dan bahasa kueri Mongo serta dukungan JSON kelas satu memberi kami kecepatan dan efisiensi yang belum pernah kami alami dengan database relasional. MongoDB telah menambahkan dukungan untuk transaksi ACID baru-baru ini, tetapi untuk waktu yang lama, inilah alasan utama kami memilih Postgres.

MongoDB juga memperkenalkan kami ke tingkat fleksibilitas baru. Di tengah proyek agensi, persyaratan pasti akan berubah. Tidak peduli seberapa keras Anda mempertahankannya, selalu ada persyaratan data menit terakhir . Dengan database NoSQL, secara umum, fleksibilitas struktur data membuat jenis perubahan tersebut tidak terlalu keras. Kami tidak berakhir dengan folder penuh file migrasi untuk mengelola kolom yang ditambahkan dan dihapus dan ditambahkan lagi sebelum sebuah proyek bahkan melihat siang hari.

Sebagai layanan, Mongo Atlas juga cukup dekat dengan apa yang kami inginkan dalam layanan cloud database. Saya suka menganggap Atlas sebagai penawaran semi -serverless karena Anda masih memiliki beberapa biaya operasional dalam mengelolanya. Anda harus menyediakan database ukuran tertentu dan memilih jumlah memori di muka. Hal-hal ini tidak akan menskala untuk Anda secara otomatis sehingga Anda perlu memantaunya ketika saatnya untuk menyediakan lebih banyak ruang atau memori. Dalam database yang benar-benar tanpa server, ini semua akan terjadi secara otomatis dan sesuai permintaan.

Kami juga menggunakan Firebase Realtime Database untuk beberapa proyek. Ini memang penawaran tanpa server di mana basis data meningkat dan turun sesuai permintaan, dan dengan harga bayar sesuai pemakaian , masuk akal untuk aplikasi yang skalanya tidak diketahui di awal dan anggaran terbatas. Kami menggunakan ini sebagai ganti MongoDB untuk proyek berumur pendek yang memiliki persyaratan data sederhana.

Satu hal yang tidak kami nikmati tentang Firebase adalah rasanya jauh dari model relasional khas yang dibangun di sekitar data normal yang biasa kami gunakan. Menjaga struktur data tetap datar berarti kami sering memiliki lebih banyak duplikasi, yang bisa berubah menjadi sedikit buruk seiring pertumbuhan proyek. Anda akhirnya harus memperbarui data yang sama di banyak tempat atau mencoba menggabungkan referensi berbeda yang menghasilkan banyak kueri yang bisa menjadi sulit untuk dijelaskan dalam kode. Meskipun kami menyukai Firebase, kami tidak pernah benar-benar jatuh cinta dengan bahasa kueri dan terkadang menemukan dokumentasinya kurang menarik.

Secara umum, MongoDB dan Firebase memiliki fokus yang sama pada data yang didenormalisasi , dan tanpa akses ke transaksi yang efisien, kami sering menemukan banyak alur kerja yang mudah dimodelkan dalam database relasional, yang menyebabkan kode yang lebih kompleks pada lapisan aplikasi dengan Rekan-rekan NoSQL. Jika kita bisa mendapatkan fleksibilitas dan kemudahan dari penawaran NoSQL ini dengan kekokohan dan pemodelan relasional dari database SQL tradisional, kita akan benar-benar menemukan kecocokan yang hebat. Kami merasa MongoDB memiliki API dan kemampuan yang lebih baik, tetapi Firebase memiliki model yang benar-benar tanpa server secara operasional.

Ideal kami

Pada titik ini, kita dapat mulai melihat opsi baru apa yang akan kita pertimbangkan. Kami telah dengan jelas mendefinisikan solusi kami sebelumnya dan kami telah mengidentifikasi hal-hal yang penting untuk kami miliki minimal dalam solusi baru kami. Kami tidak hanya memiliki persyaratan dasar atau minimum, tetapi kami juga memiliki serangkaian masalah yang ingin kami atasi dengan solusi baru. Berikut adalah persyaratan teknis yang kami miliki:

1. Tanpa server secara operasional dengan skala sesuai permintaan
2. Pemodelan fleksibel (tanpa skema)
3. Tidak bergantung pada migrasi atau ORM
4. Transaksi yang sesuai dengan ACID
5. Mendukung hubungan dan data yang dinormalisasi
6. Bekerja dengan backend tanpa server dan tradisional

Jadi sekarang kami memiliki daftar must-have, kami benar-benar dapat mengevaluasi beberapa opsi. Mungkin tidak terlalu penting bahwa solusi baru itu memakukan setiap target di sini. Mungkin saja itu mengenai kombinasi fitur yang tepat di mana solusi yang ada tidak tumpang tindih. Misalnya, jika Anda menginginkan fleksibilitas tanpa skema , Anda harus menghentikan transaksi ACID. (Ini adalah kasus untuk waktu yang lama dengan database.)

Contoh dari domain lain adalah jika Anda ingin memiliki validasi TypeScript dalam rendering template Anda, Anda harus menggunakan TSX dan React. Jika Anda menggunakan opsi seperti Svelte atau Vue, Anda dapat memiliki ini — sebagian tetapi tidak sepenuhnya — melalui rendering template . Jadi solusi yang memberi Anda jejak kecil dan kecepatan Svelte dengan pemeriksaan tipe level template dari React dan TypeScript bisa cukup untuk diadopsi meskipun fitur lain hilang. Keseimbangan dan keinginan dan kebutuhan akan berubah dari proyek ke proyek. Terserah Anda untuk mencari tahu di mana nilainya akan berada dan memutuskan bagaimana menandai poin terpenting dalam analisis Anda.

Sekarang kita dapat melihat sebuah solusi dan melihat bagaimana solusi tersebut dievaluasi terhadap solusi yang kita inginkan. Fauna adalah solusi database tanpa server yang menawarkan skala sesuai permintaan dengan distribusi global. Ini adalah database tanpa skema, yang menyediakan transaksi yang sesuai dengan ACID, dan mendukung kueri relasional dan data yang dinormalisasi sebagai fitur. Fauna dapat digunakan di kedua aplikasi tanpa server serta backend yang lebih tradisional dan menyediakan perpustakaan untuk bekerja dengan bahasa paling populer. Fauna juga menyediakan alur kerja untuk otentikasi serta multi-tenancy yang mudah dan efisien. Keduanya adalah fitur tambahan yang solid untuk diperhatikan karena keduanya bisa menjadi faktor yang mempengaruhi ketika dua teknologi saling berhadapan dalam evaluasi kami.

Sekarang setelah melihat semua kekuatan ini kita harus mengevaluasi kelemahannya . Salah satunya adalah Fauna yang tidak open source. Ini berarti bahwa ada risiko penguncian vendor, atau perubahan bisnis dan harga yang berada di luar kendali Anda. Open source bisa menyenangkan karena Anda sering dapat meningkatkan dan membawa teknologi ke vendor lain jika Anda berkenan atau berpotensi berkontribusi kembali ke proyek tersebut.

Di dunia agensi, penguncian vendor adalah sesuatu yang harus kita perhatikan dengan cermat, bukan karena harga, tetapi kelangsungan bisnis yang mendasarinya adalah penting. Harus mengubah database pada proyek yang sedang dalam pengembangan atau berumur beberapa tahun adalah bencana bagi sebuah agensi. Seringkali klien harus membayar tagihan untuk ini, yang bukan percakapan yang menyenangkan untuk dilakukan.

Satu kelemahan lain yang kami khawatirkan adalah fokus pada JAMstack . Meskipun kami menyukai JAMstack, kami lebih sering membangun berbagai macam aplikasi web tradisional. Kami ingin memastikan bahwa Fauna terus mendukung kasus penggunaan tersebut. Kami memiliki pengalaman buruk di masa lalu dengan penyedia hosting yang menggunakan JAMstack dan akhirnya kami harus memigrasikan sebagian besar situs dari layanan tersebut, jadi kami ingin merasa yakin bahwa semua kasus penggunaan akan terus terlihat. dukungan yang solid. Saat ini, tampaknya demikian, dan alur kerja tanpa server yang disediakan oleh Fauna sebenarnya dapat melengkapi aplikasi yang lebih tradisional dengan cukup baik.

Pada titik ini, kami telah melakukan penelitian fungsional kami dan satu-satunya cara untuk mengetahui apakah solusi ini layak adalah dengan turun dan menulis beberapa kode. Dalam lingkungan agensi, kita tidak bisa hanya mengambil beberapa minggu dari jadwal bagi orang-orang untuk mengevaluasi berbagai solusi. Ini adalah sifat bekerja di agensi vs. lingkungan SaaS . Dalam yang terakhir, Anda dapat membuat beberapa prototipe untuk mencoba mendapatkan solusi yang tepat. Di agensi, Anda akan mendapatkan beberapa hari untuk bereksperimen, atau mungkin kesempatan untuk melakukan proyek sampingan, tetapi pada umumnya kami benar-benar harus mempersempitnya menjadi satu atau dua teknologi pada tahap ini dan kemudian meletakkan jari ke keyboard.

Pengalaman Pengembang

Menilai dari sisi pengalaman teknologi baru mungkin yang paling sulit dari ketiga bidang tersebut karena pada dasarnya bersifat subjektif. Ini juga akan memiliki variabilitas dari tim ke tim. Misalnya, jika Anda bertanya kepada programmer Ruby, programmer Python, dan programmer Rust tentang pendapat mereka tentang fitur bahasa yang berbeda, Anda akan mendapatkan cukup banyak tanggapan. Jadi, sebelum Anda mulai menilai sebuah pengalaman, Anda harus terlebih dahulu memutuskan karakteristik apa yang paling penting bagi tim Anda secara keseluruhan.

Untuk agensi, saya pikir ada dua hambatan utama yang muncul terkait dengan pengalaman pengembang:

1. Waktu pengaturan dan konfigurasi
2. Kemampuan untuk dipelajari

Kedua hal ini mempengaruhi kelangsungan hidup jangka panjang dari sebuah teknologi baru dengan cara yang berbeda. Menjaga tim pengembang sementara tetap sinkron di sebuah agensi bisa menjadi sakit kepala. Alat yang memiliki banyak biaya penyiapan dan konfigurasi di muka sangat sulit untuk dikerjakan oleh agensi. Yang lainnya adalah kemampuan untuk dipelajari dan betapa mudahnya bagi pengembang untuk mengembangkan teknologi baru. Kami akan membahas ini lebih detail dan mengapa mereka menjadi dasar saya ketika mulai mengevaluasi pengalaman pengembang.

Pengaturan Waktu Dan Konfigurasi

Agen cenderung memiliki sedikit kesabaran dan waktu untuk konfigurasi. Bagi saya, saya menyukai alat tajam, dengan desain ergonomis, yang memungkinkan saya untuk menyelesaikan masalah bisnis dengan cepat. Beberapa tahun yang lalu saya bekerja untuk perusahaan SaaS yang memiliki pengaturan lokal kompleks yang melibatkan banyak konfigurasi dan sering kali gagal secara acak dalam proses pengaturan. Setelah Anda mengatur, kebijaksanaan konvensional adalah tidak menyentuh apa pun , dan berharap Anda tidak berada di perusahaan cukup lama sehingga harus memasangnya lagi di komputer lain. Saya telah bertemu pengembang yang sangat menikmati mengonfigurasi setiap bagian kecil dari pengaturan emacs mereka dan tidak memikirkan kehilangan beberapa jam karena lingkungan lokal yang rusak.

Secara umum, saya menemukan bahwa para insinyur agensi meremehkan hal-hal semacam ini dalam pekerjaan sehari-hari mereka. Saat di rumah, mereka mungkin bermain-main dengan jenis alat ini, tetapi ketika di tenggat waktu tidak ada alat yang hanya berfungsi. Di agensi, kami biasanya lebih suka mempelajari beberapa hal baru yang bekerja dengan baik, konsisten, daripada dapat mengonfigurasi setiap bagian teknologi sesuai selera pribadi masing-masing individu.

Satu hal yang baik tentang bekerja dengan platform cloud yang bukan open source adalah mereka memiliki pengaturan dan konfigurasi sepenuhnya. Sementara kelemahan dari ini adalah penguncian vendor, keuntungannya adalah bahwa jenis alat ini sering melakukan hal yang mereka atur untuk melakukannya dengan baik. Tidak ada mengutak-atik lingkungan, tidak ada pengaturan lokal, dan tidak ada pipa penyebaran. Kami juga memiliki lebih sedikit keputusan untuk dibuat.

Ini adalah daya tarik dari serverless . Tanpa server secara umum memiliki ketergantungan yang lebih besar pada layanan dan alat berpemilik. Kami memperdagangkan fleksibilitas hosting dan kode sumber sehingga kami dapat memperoleh stabilitas yang lebih besar dan fokus pada masalah domain bisnis yang kami coba selesaikan. Saya juga akan mencatat bahwa ketika saya mengevaluasi suatu teknologi dan saya merasa bahwa migrasi dari suatu platform mungkin diperlukan, ini sering kali merupakan pertanda buruk di awal.

Dalam kasus database, setup set-it-and-forget-it sangat ideal ketika bekerja dengan klien di mana kebutuhan database dapat menjadi ambigu. Kami memiliki klien yang tidak yakin seberapa populer suatu program atau aplikasi nantinya. Kami memiliki klien yang secara teknis tidak kami kontrak untuk mendukung dengan cara ini, tetapi tetap memanggil kami dengan panik ketika mereka membutuhkan kami untuk menskalakan basis data atau aplikasi mereka.

Di masa lalu, kami selalu harus mempertimbangkan hal-hal seperti redundansi, replikasi data , dan sharding untuk menskalakan saat kami membuat SOW kami. Mencoba untuk menutupi setiap skenario sambil juga bersiap untuk memindahkan buku bisnis lengkap jika database tidak scaling adalah situasi yang tidak mungkin untuk dipersiapkan. Pada akhirnya, database tanpa server membuat hal-hal ini lebih mudah.

Anda tidak pernah kehilangan data , Anda tidak perlu khawatir tentang mereplikasi data di seluruh jaringan, atau menyediakan database dan mesin yang lebih besar untuk menjalankannya – semuanya berfungsi. Kami hanya fokus pada masalah bisnis yang dihadapi, arsitektur teknis dan skala akan selalu dikelola. Untuk tim pengembangan kami, ini adalah kemenangan besar; kami memiliki lebih sedikit latihan kebakaran, pemantauan, dan pengalihan konteks.

Kemampuan untuk dipelajari

Ada ukuran pengalaman pengguna klasik, yang menurut saya berlaku untuk pengalaman pengembang, yaitu kemampuan belajar . Saat mendesain untuk pengalaman pengguna tertentu, kami tidak hanya melihat apakah ada sesuatu yang terlihat atau mudah pada percobaan pertama. Teknologi hanya memiliki lebih banyak kompleksitas daripada itu sebagian besar waktu. Yang penting adalah seberapa mudah pengguna baru dapat mempelajari dan menguasai sistem.

Ketika datang ke alat teknis, terutama yang kuat, akan banyak yang meminta agar tidak ada kurva belajar . Biasanya yang kami cari adalah adanya dokumentasi yang bagus untuk kasus penggunaan yang paling umum dan agar pengetahuan itu dapat dengan mudah dan cepat dibangun saat dalam sebuah proyek. Kehilangan sedikit waktu untuk belajar pada proyek pertama dengan teknologi tidak apa-apa. Setelah itu, kita akan melihat efisiensi meningkat dengan setiap proyek berturut-turut.

Apa yang saya cari secara khusus di sini adalah bagaimana kita dapat memanfaatkan pengetahuan dan pola yang sudah kita ketahui untuk membantu mempersingkat kurva belajar. Misalnya, dengan database tanpa server, hampir tidak ada kurva pembelajaran untuk menyiapkannya di cloud dan diterapkan. Ketika menggunakan database, salah satu hal yang saya suka adalah ketika kita masih dapat memanfaatkan bertahun-tahun untuk menguasai database relasional dan menerapkan pembelajaran tersebut ke pengaturan baru kita. Dalam hal ini, kami mempelajari cara menggunakan alat baru, tetapi itu tidak memaksa kami untuk memikirkan kembali pemodelan data kami dari awal.

Sebagai contoh, saat menggunakan Firebase, MongoDB, dan DynamoDB, kami menemukan bahwa itu mendorong data yang didenormalisasi daripada mencoba menggabungkan dokumen yang berbeda. Ini menciptakan banyak gesekan kognitif saat memodelkan data kami karena kami perlu memikirkan pola akses daripada entitas bisnis. Di sisi lain Fauna ini memungkinkan kami untuk memanfaatkan pengetahuan relasional kami selama bertahun-tahun serta preferensi kami untuk data yang dinormalisasi dalam hal pemodelan data.

Bagian yang harus kami biasakan adalah menggunakan indeks dan bahasa kueri baru untuk menyatukan bagian-bagian itu. Secara umum, saya telah menemukan bahwa melestarikan konsep yang merupakan bagian dari paradigma desain perangkat lunak yang lebih besar memudahkan tim pengembangan dalam hal kemampuan belajar dan adopsi.

Bagaimana kita tahu bahwa sebuah tim mengadopsi dan mencintai teknologi baru? Saya pikir tanda terbaiknya adalah ketika kita bertanya pada diri sendiri apakah alat itu terintegrasi dengan teknologi baru tersebut? Ketika sebuah teknologi baru mencapai tingkat yang diinginkan dan dinikmati oleh tim yang sedang mencari cara untuk memasukkannya ke dalam lebih banyak proyek, itu pertanda baik Anda memiliki pemenang.

Bisnis

Di bagian ini, kita harus melihat bagaimana teknologi baru memenuhi kebutuhan bisnis kita. Ini termasuk pertanyaan seperti:

• Seberapa mudah harganya dan diintegrasikan ke dalam rencana dukungan kami?
• Bisakah kita mentransisikannya ke klien dengan mudah?
• Bisakah klien di-onboard ke alat ini jika perlu?
• Berapa banyak waktu yang benar-benar dihemat alat ini jika ada?

Munculnya tanpa server sebagai paradigma sangat cocok dengan agensi. Ketika kita berbicara tentang database dan DevOps, kebutuhan akan spesialis di bidang ini di agensi terbatas. Seringkali kita menyerahkan sebuah proyek ketika kita selesai dengannya atau mendukungnya dalam kapasitas terbatas dalam jangka panjang. Kami cenderung bias terhadap full-stack engineer karena kebutuhan ini melebihi kebutuhan DevOps dengan selisih yang besar. Jika kami menyewa seorang insinyur DevOps, mereka kemungkinan akan menghabiskan beberapa jam untuk menjalankan proyek dan lebih banyak jam menunggu api.

Dalam hal ini, kami selalu memiliki beberapa kontraktor DevOps yang siap, tetapi tidak staf untuk posisi ini penuh waktu. Ini berarti kami tidak dapat mengandalkan insinyur DevOps untuk siap menghadapi masalah yang tidak terduga. Bagi kami, kami tahu bahwa kami bisa mendapatkan tarif hosting yang lebih baik dengan membuka AWS secara langsung, tetapi kami juga tahu bahwa dengan menggunakan Heroku, kami dapat mengandalkan staf kami yang ada untuk men-debug sebagian besar masalah. Kecuali kami memiliki klien yang kami perlukan untuk mendukung jangka panjang dengan kebutuhan backend tertentu, kami ingin menggunakan platform terkelola sebagai layanan default.

Database tidak terkecuali. Kami senang bersandar pada layanan seperti Mongo Atlas atau Heroku Postgres untuk membuat proses ini semudah mungkin. Saat kami mulai melihat semakin banyak kepala tumpukan kami ke alat tanpa server seperti Vercel, Netlify, atau AWS Lambda – kebutuhan database kami harus berkembang dengan itu. Basis data tanpa server seperti Firebase, DynamoDB, dan Fauna sangat bagus karena terintegrasi dengan baik dengan aplikasi tanpa server, tetapi juga membebaskan bisnis kami sepenuhnya dari penyediaan dan penskalaan.

Solusi ini juga bekerja dengan baik untuk aplikasi yang lebih tradisional, di mana kami tidak memiliki aplikasi tanpa server tetapi kami masih dapat memanfaatkan efisiensi tanpa server di tingkat basis data. Sebagai bisnis, lebih produktif bagi kami untuk mempelajari satu database yang dapat diterapkan ke kedua dunia daripada beralih konteks. Ini mirip dengan keputusan kami untuk mengadopsi Node dan JavaScript isomorfik (dan TypeScript).

Salah satu kelemahan yang kami temukan dengan tanpa server adalah penetapan harga untuk klien yang kami kelola untuk layanan ini. Dalam arsitektur yang lebih tradisional, tingkat tarif tetap membuatnya sangat mudah untuk menerjemahkannya ke dalam tarif untuk klien dengan keadaan yang dapat diprediksi untuk menimbulkan kenaikan dan kelebihan. Ketika berbicara tentang tanpa server, ini bisa menjadi ambigu. Orang-orang keuangan biasanya tidak suka mendengar hal-hal seperti kami mengenakan biaya 1/10 sen untuk setiap pembacaan melebihi 1 juta, dan seterusnya dan seterusnya.

Ini sulit untuk diterjemahkan ke dalam angka tetap bahkan untuk para insinyur karena kami sering membangun aplikasi yang kami tidak yakin apa penggunaannya . Kita sering kali harus membuat tingkatan sendiri tetapi banyak variabel yang masuk ke dalam perhitungan biaya lambda bisa jadi sulit untuk dipikirkan. Pada akhirnya, untuk produk SaaS, model penetapan harga bayar sesuai penggunaan ini bagus, tetapi untuk agensi, akuntan menyukai angka yang lebih konkret dan dapat diprediksi.

Ketika datang ke Fauna, ini jelas lebih ambigu untuk diketahui daripada mengatakan database MySQL standar yang memiliki hosting flat-rate untuk jumlah ruang yang ditentukan. Keuntungannya adalah Fauna menyediakan kalkulator bagus yang dapat kami gunakan untuk menyusun skema harga kami sendiri.

Aspek lain yang sulit dari serverless adalah bahwa banyak dari penyedia ini tidak mengizinkan pemecahan yang mudah dari setiap aplikasi yang dihosting. Misalnya, platform Heroku membuatnya cukup mudah dengan membuat saluran dan tim baru. Kami bahkan dapat memasukkan kartu kredit klien untuk mereka jika mereka tidak ingin menggunakan paket hosting kami. Ini semua dapat dilakukan dalam dasbor yang sama juga sehingga kami tidak perlu membuat banyak login.

Ketika datang ke alat tanpa server lainnya, ini jauh lebih sulit. Dalam mengevaluasi database tanpa server, Firebase mendukung pemisahan pembayaran berdasarkan proyek . Dalam kasus Fauna atau DynamoDB, ini tidak mungkin jadi kami harus melakukan beberapa pekerjaan untuk memantau penggunaan di dasbor mereka, dan jika klien ingin meninggalkan layanan kami, kami harus mentransfer database ke akun mereka sendiri.

Pada akhirnya, alat tanpa server memberikan peluang bisnis yang besar dalam hal penghematan biaya, manajemen, dan efisiensi proses. Namun, seringkali mereka terbukti menantang bagi agensi dalam hal penetapan harga dan manajemen akun. Ini adalah salah satu area di mana kami harus memanfaatkan kalkulator biaya untuk membuat tingkat harga kami sendiri yang dapat diprediksi atau mengatur klien dengan akun mereka sendiri sehingga mereka dapat melakukan pembayaran secara langsung.

Kesimpulan

Ini bisa menjadi tugas yang sulit untuk mengadopsi teknologi baru sebagai agen. Sementara kami berada dalam posisi yang unik untuk bekerja dengan proyek-proyek lapangan hijau baru yang memiliki peluang untuk teknologi baru, kami juga harus mempertimbangkan investasi jangka panjangnya. Bagaimana kinerja mereka? Akankah orang-orang kita menjadi produktif dan senang menggunakannya? Bisakah kita memasukkannya ke dalam penawaran bisnis kita?

You need to have a firm grasp of where you have been before you figure out where you want to go technologically. When evaluating a new tool or platform it's important to think of what you have tried in the past and figure out what is most important to you and your team. We took a look at the concept of a serverless database and passed it through our three lenses – the technology, the experience, and the business. We were left with some pros and cons and had to strike the right balance.

After we evaluated serverless databases, we decided to adopt Fauna over the alternatives. We felt the technology was robust and ticked all of our boxes for our technology filter. When it came to the experience, virtually zero configuration and being able to leverage our existing knowledge of relational data modeling made this a winner with the development team. On the business side serverless provides clear wins to efficiency and productivity , however on the pricing side and account management there are still some difficulties. We decided the benefits in the other areas outweighed the pricing difficulties.

Overall, we highly recommend giving Fauna a shot on one of your next projects. It has become one of our favorite tools and our go-to database of choice for smaller serverless projects and even more traditional large backend applications. The community is very helpful, the learning curve is gentle, and we believe you'll find levels of productivity you hadn't realized before with existing databases.

When we first use a new technology on a project, we start with something either internal or on the smaller side. We try to mitigate the risk by wading into the water rather than leaping into the deep end by trying it on a large and complex project. As the team builds understanding of the technology, we start using it for larger projects but only after we feel comfortable that it has handled similar use cases well for us in the past.

In general, it can take up to a year for a technology to become a ubiquitous part of most projects so it is important to be patient. Agencies have a lot of flexibility but also are required to ensure stability in the products they produce, we don't get a second chance. Always be experimenting and pushing your agency to adopt new technologies, but do so carefully and you will reap the benefits.

Bacaan lebih lanjut

• Serverless Database Wishlist - What's Missing Today
• Relational NoSQL: Yes, that is an option
• Concerning toolkits - A great piece about the merits of zero configuration on developer experience