Arsitektur Backend untuk backend aplikasi web berbasis konten

Arsitektur backend mengacu pada struktur backend aplikasi web Anda. Arsitektur backend menentukan cara bagian aplikasi berkomunikasi satu sama lain untuk memproses permintaan masuk dan membuat respons. Saat mem-build aplikasi web, pilih arsitektur backend berdasarkan persyaratan dan faktor spesifik Anda, termasuk biaya (baik berkelanjutan maupun skala besar), kompleksitas aplikasi, sasaran penskalaan, dan keahlian tim Anda.

Khusus untuk aplikasi web berbasis konten, seperti e-commerce, surat kabar, atau blog, persyaratan penting mencakup konsistensi data dan performa, terutama saat aplikasi Anda tumbuh ke skala global dan mungkin menjadi lebih terdistribusi. Untuk aplikasi web berbasis konten, penyimpanan data yang digunakan oleh aplikasi Anda juga penting dan dibahas secara lebih mendetail dalam panduan penyimpanan data. Tidak sekadar arsitektur aplikasi biasa, menghosting konten, dan membuatnya dapat diakses sangatlah penting saat mengoptimalkan performa aplikasi. Pelajari lebih lanjut cara memilih strategi hosting yang tepat dan mengoptimalkan aplikasi Anda di panduan hosting.

Jika Anda sudah memiliki backend untuk aplikasi web, pertimbangkan batas arsitektur Anda saat ini. Misalnya, seiring peningkatan skala aplikasi dan peningkatan performa serta keandalannya, pertimbangkan apakah bagian aplikasi Anda harus difaktorkan ulang atau dipindahkan ke arsitektur lain yang lebih sesuai dengan skala yang ditingkatkan. Misalnya, Arsitektur hybrid (atau multicloud) memungkinkan Anda mengalihkan beberapa workload ke cloud sebelum melakukan transisi sepenuhnya. Mempertimbangkan biaya, waktu, dan risiko yang terlibat dalam migrasi tersebut juga sangat penting.

Arsitektur Monolitik

Arsitektur monolitik memiliki struktur terpadu, dengan semua komponen aplikasi terintegrasi erat ke dalam satu codebase. Seluruh aplikasi dibuat sebagai unit mandiri. Arsitektur monolitik bersifat multi-tingkat, dengan berbagai lapisan aplikasi menyelesaikan tugas tertentu.

Lapisan Struktural

• Antarmuka Pengguna (UI), yang mencakup komponen untuk menampilkan fitur aplikasi, biasanya berupa aplikasi berbasis web atau desktop yang berinteraksi dengan pengguna.
• Logika aplikasi adalah tempat fungsi inti berada.Bagian codebase ini berisi aturan, penghitungan, dan operasi yang menentukan cara kerja aplikasi.
• Lapisan akses data berisi fungsi untuk membaca dan menulis data serta menerjemahkan antara struktur data aplikasi dan skema database. Lapisan ini bertanggung jawab untuk berinteraksi dengan database atau penyimpanan data aplikasi.
• Database adalah tempat aplikasi menyimpan datanya. Biasanya ada satu database yang menyimpan semua data aplikasi, termasuk data pengguna, konfigurasi, dan informasi lainnya.
• Komponen middleware menangani tugas-tugas seperti autentikasi, pemilihan rute permintaan, dan validasi data. Komponen ini membantu mengelola aliran data dan permintaan.
• Beberapa aplikasi monolitik memiliki titik integrasi dengan layanan eksternal atau API. Titik ini memungkinkan aplikasi berinteraksi dengan layanan pihak ketiga, sumber data, atau sistem lainnya.

Lapisan struktural biasanya merupakan bagian dari codebase tunggal. Codebase ini berisi seluruh aplikasi dan biasanya disusun ke dalam direktori, modul, dan class. Developer mengerjakan berbagai bagian codebase untuk membangun dan mengelola aplikasi. Namun, seluruh aplikasi biasanya di-deploy sebagai unit tunggal. Saat pembaruan atau perubahan dibuat, seluruh aplikasi akan di-deploy ulang.

Potensi Tantangan

• Seiring berkembangnya aplikasi monolitik, codebase cenderung menjadi kompleks dan sulit untuk dikelola. Hal ini dapat mengakibatkan siklus pengembangan yang panjang dan kesulitan dalam memahami seluruh codebase.
• Men-deploy perubahan pada aplikasi monolitik dapat berisiko karena perubahan yang dilakukan di satu bagian kode dapat secara tidak sengaja memengaruhi bagian lain aplikasi. Hal ini dapat menciptakan proses deployment yang panjang dan rentan terhadap error.
• Aplikasi monolitik bisa menjadi sulit untuk diskalakan karena di-deploy sebagai satu unit. Anda harus menskalakan seluruh aplikasi meskipun hanya satu komponen yang mengalami peningkatan permintaan.
• Aplikasi monolitik sering kali mengandalkan satu technology stack atau bahasa pemrograman. Kemampuan Anda dalam menggunakan alat terbaik untuk tugas tertentu dalam aplikasi mungkin terbatas.
• Bahkan selama periode permintaan rendah, aplikasi monolitik memerlukan resource yang signifikan untuk beroperasi. Biaya pemeliharaan juga meningkat seiring usia aplikasi karena update dan patch aplikasi menjadi semakin sulit tanpa menyebabkan regresi.
• Tim pengembangan yang menangani aplikasi monolitik sering kali disusun di seluruh aplikasi, sehingga menghasilkan tim yang lebih besar dan koordinasi yang lebih kompleks di antara anggota tim.

Penggunaan yang Disarankan

Arsitektur monolitik cocok jika aplikasi memiliki persyaratan yang sederhana dan tim pengembangannya kecil. Seiring dengan perkembangan kompleks dan skala aplikasi, atau ketika berbagai bagian aplikasi memerlukan teknologi atau strategi deployment yang berbeda, arsitektur monolitik dapat menjadi kurang fleksibel dan lebih sulit untuk dikelola.

Anda dapat membuat dan mengelola virtual machine yang dapat menjalankan aplikasi monolitik di Compute Engine. Anda memiliki kontrol penuh atas sistem operasi, software, dan pengelolaan mesin virtual tersebut untuk menjalankan aplikasi monolitik.

Dengan layanan platform-as-a-service, seperti App Engine, Anda dapat membangun aplikasi dan menjalankannya di infrastruktur terkelola sepenuhnya yang otomatis diskalakan dengan permintaan.

Jika aplikasi monolitik Anda berada dalam container, Anda dapat menjalankannya menggunakan Google Kubernetes Engine (GKE) atau Cloud Run. Layanan seperti Cloud SQL atau Cloud Spanner dapat digunakan untuk menyimpan data untuk aplikasi monolitik. Pertimbangkan kombinasi layanan dan sistem berdasarkan persyaratan spesifik aplikasi Anda.

Arsitektur Serverless

Dengan arsitektur serverless, Anda dapat membangun dan menjalankan aplikasi tanpa mengelola server fisik atau virtual. Penyedia cloud secara otomatis mengelola infrastruktur, penskalaan, dan alokasi resource sehingga developer dapat fokus pada penulisan kode untuk aplikasi mereka. Arsitektur serverless dapat menyederhanakan pengembangan, mengurangi overhead operasional, dan mengoptimalkan biaya dengan meniadakan kebutuhan untuk memelihara server. Layanan ini sangat cocok untuk microservice, pemrosesan data real-time, aplikasi web dengan workload variabel, dan pemrosesan peristiwa.

Arsitektur serverless berbasis peristiwa

Arsitektur serverless berbasis peristiwa adalah jenis arsitektur komputasi serverless tertentu yang mengandalkan peristiwa atau pemicu untuk memulai eksekusi fungsi atau microservice. Komponen sistem berkomunikasi melalui peristiwa, dan fungsi dipanggil sebagai respons terhadap peristiwa tersebut. Fungsi ini sering kali mengandalkan komunikasi asinkron karena fungsi dipicu oleh peristiwa, lalu memprosesnya secara independen, dan dapat menghasilkan peristiwa yang kemudian memicu tindakan berikutnya. Jenis arsitektur serverless ini adalah opsi yang bagus untuk mem-build sistem yang skalabel, responsif, dan dikaitkan secara longgar.

Dengan Google Cloud Functions dan Cloud Functions for Firebase, Anda dapat membangun dan men-deploy fungsi berbasis peristiwa di lingkungan yang terkelola sepenuhnya dan serverless. Ini dapat digunakan untuk menjalankan kode sebagai respons terhadap beragam peristiwa dan pemicu, termasuk permintaan HTTP, pesan Cloud Pub/Sub, perubahan Google Cloud Storage, update Firebase Realtime Database, tanpa perlu mengelola infrastruktur. Fitur utamanya mencakup dukungan beberapa bahasa, skalabilitas, penagihan terperinci, integrasi pihak ketiga, logging dan pemantauan yang andal, serta integrasi dengan layanan Google dan Firebase lainnya.

Arsitektur serverless dapat menghemat biaya untuk banyak kasus penggunaan, terutama untuk aplikasi dengan berbagai workload, kebutuhan pengembangan yang cepat, dan traffic yang tidak dapat diprediksi. Keandalan bergantung pada penyedia cloud, dengan diterapkannya perjanjian tingkat layanan (SLA) untuk memastikan target performa dan keandalan yang spesifik. Anda harus menilai kasus penggunaan dan persyaratan khusus Anda untuk menentukan apakah arsitektur serverless adalah pilihan terbaik Anda.

Containerization

Dengan containerization, aplikasi dan dependensinya dapat dikemas ke dalam container yang ringan dan portabel. Keduanya menyediakan lingkungan aplikasi yang konsisten yang mendukung pengembangan dan deployment di berbagai sistem dan platform. Beberapa platform serverless menawarkan kemampuan untuk menjalankan workload dalam container. Menjalankan container dalam lingkungan serverless bisa bermanfaat saat Anda memiliki beban kerja yang kompleks atau stateful yang tidak dapat dinyatakan sebagai fungsi dasar. Hal ini memberikan fleksibilitas dalam hal dukungan bahasa dan lingkungan runtime.

Cloud Run adalah platform komputasi serverless yang memungkinkan developer men-deploy dan menjalankan aplikasi dalam container di lingkungan yang terkelola sepenuhnya. Solusi ini menyediakan cara mudah untuk membangun, men-deploy, dan menskalakan aplikasi tanpa mengelola infrastruktur yang mendasarinya. Layanan ini cocok untuk berbagai aplikasi web dan microservice, terutama aplikasi dengan workload yang bervariasi, dan containerization menawarkan manfaat dalam hal pemaketan dan konsistensi aplikasi.

Arsitektur Microservice

Aplikasi dibagi menjadi bagian-bagian kecil yang dikaitkan secara longgar dan menerapkan fitur atau kemampuan yang berbeda. Layanan ini dapat berkomunikasi melalui pesan asinkron, saluran berbasis peristiwa, atau secara langsung dengan mengekspos antarmuka. Setiap layanan dikembangkan, diuji, dan diskalakan secara terpisah dalam container-nya, yang sering dikelola melalui layanan orkestrasi, seperti Kubernetes, atau di-deploy menggunakan platform terkelola, seperti Cloud Run.

Deployment microservice biasanya juga memanfaatkan paradigma aplikasi tanpa server dengan tidak mengandalkan server terpusat.

Memisahkan aplikasi menjadi layanan otonom dapat menyederhanakan sistem yang kompleks. Batasan dan tujuan yang ditetapkan dengan baik dapat mempercepat pengembangan dan meningkatkan pemeliharaan. Setiap microservice dapat dikembangkan secara independen menggunakan framework atau alat yang paling efektif. Komunikasi antarlayanan sering kali ditangani menggunakan peristiwa, komunikasi publikasi-langganan, pipeline pesan, atau panggilan prosedur jarak jauh seperti gRPC.

Untuk orkestrasi tugas dalam arsitektur microservice, sebaiknya gunakan framework yang mendukung platform yang Anda targetkan, kedalaman yang cukup untuk tugas dan jenis alur kerja yang Anda orkestrasi, serta penanganan error dan telemetri untuk men-debug masalah. Pilihan populer mencakup Conduktor atau penawaran dari penyedia cloud seperti Google Workflows.

Aplikasi berbasis microservice dapat sangat rumit untuk dikembangkan dan dipelihara karena sifatnya yang terdistribusi dan kebutuhan akan komunikasi intra-layanan. Oleh karena itu, pengelolaan deployment, pemantauan, dan logging lebih kompleks daripada opsi arsitektur lainnya. Karena keandalan bergantung pada arsitektur setiap layanan, sifat yang terdistribusi dapat menawarkan ketahanan tambahan, terutama jika pemantauan dan telemetri di-deploy dan diaktifkan jika diperlukan.

Perbandingan berbagai arsitektur untuk backend aplikasi web berbasis konten

Tabel berikut membandingkan arsitektur dengan persyaratan utama untuk backend aplikasi web berbasis konten.

	Arsitektur Monolitik	Arsitektur berbasis peristiwa dan serverless	Arsitektur microservice tanpa server
Kompleksitas dan pemeliharaan	Kemudahan implementasi untuk project mandiri yang kecil, tetapi kompleksitasnya meningkat seiring dengan skala. Membutuhkan pemeliharaan dan koordinasi manual.	Penskalaan didukung dengan baik dan terintegrasi ke dalam platform. Pemecahan masalah dan proses debug dapat menjadi tantangan. Tidak perlu mengelola infrastruktur.	Layanan mandiri yang diuji dan di-deploy secara independen, sehingga mempermudah pemeliharaan untuk setiap unit. Memerlukan komunikasi antarlayanan yang cermat. Memerlukan alat pengelolaan dan orkestrasi untuk mengelola pada skala yang lebih besar.
Skalabilitas dan performa	Efisien dalam skala kecil, sulit untuk diskalakan di luar ukuran tertentu. Kebutuhan infrastruktur yang spesifik, yang membatasi opsi penskalaan dinamis. Penskalaan manual (atau menggunakan layanan manual) dalam arsitektur, misalnya melalui load balancing.	Skalabilitas bawaan melalui penggunaan platform terkelola. Menskalakan di salah satu arah.	Setiap layanan disesuaikan dengan kebutuhan tertentu dan dapat diskalakan serta dioptimalkan secara terpisah.
Strategi penggantian dan ketahanan	Deployment rumit dan dapat menyebabkan periode nonaktif ("semua atau tidak sama sekali").	Melekat pada penyedia cloud. Setiap fungsi independen dapat dicoba ulang secara independen.	Setiap layanan bersifat mandiri, sehingga menjadikan sistem secara keseluruhan lebih tahan melalui pengujian dan pengembangan independen.
Pengalaman pengembangan	Pengembangan cepat dalam skala kecil melalui pengaitan erat arsitektur (misalnya melalui kueri yang efisien). Waktu build yang lama serta kolaborasi dan pengujian yang sulit seiring dengan makin kompleksnya kompleksitas.	Tidak ada infrastruktur yang harus dipelihara dan dikelola, sehingga pengembangan berjalan lebih cepat. Pengujian dan proses debug aplikasi aktif bergantung pada layanan penyedia cloud.	Layanan bersifat mandiri dan dapat dikembangkan secara terpisah satu sama lain. Sejumlah besar layanan perlu dikoordinasikan dan dikelola.
Biaya	Pengembangan yang kompleks dapat mengakibatkan peningkatan biaya. Memerlukan investasi hardware atau infrastruktur yang signifikan, terutama pada skala yang lebih besar. Efisiensi biaya dari peningkatan dan penurunan skala sulit diwujudkan.	Tidak ada biaya hardware khusus. Menaikkan dan menurunkan skala untuk mengoptimalkan penggunaan dan biaya resource (dari nol).	Tidak ada biaya hardware khusus. Menaikkan dan menurunkan skala untuk mengoptimalkan penggunaan dan biaya resource sesuai batas. Biaya tambahan dari pemantauan dan pengelolaan sekumpulan besar layanan independen.

Pelajari lebih lanjut arsitektur backend untuk aplikasi web berbasis konten

Berikut ini beberapa referensi untuk mempelajari lebih lanjut arsitektur untuk aplikasi web berbasis konten, termasuk cara memigrasikan aplikasi Anda ke arsitektur yang berbeda:

• Pelajari lebih lanjut arsitektur backend aplikasi web yang dikaitkan secara longgar, termasuk aplikasi web monolitik bertingkat dan serverless.

• Memigrasikan aplikasi monolitik ke arsitektur microservice.

• Kasus penggunaan umum untuk Cloud Functions serverless.