Empat pilihan arsitektur untuk pengembangan aplikasi dalam era digital

Kita semua tahu tentang arsitektur aplikasi 3 tingkat—ini adalah arsitektur server klien dengan struktur khas yang terdiri dari lapisan presentasi, lapisan aplikasi, dan lapisan basis data.

Arsitektur ini memiliki antarmuka pengguna, logika akses bisnis/data, dan akses data. Banyak aplikasi perusahaan dibuat menggunakan arsitektur aplikasi 3 tingkat yang sederhana.

Sederhananya, model aplikasi 3 tingkat sudah ketinggalan zaman. Aplikasi ini dirancang untuk pengembangan aplikasi sebelum perkembangan pesat cloud publik dan aplikasi mobile dan telah mengalami kesulitan beradaptasi dengan cloud.

Seiring waktu, aplikasi bisa menjadi terlalu besar dan kompleks untuk sering melakukan perubahan. Tidak hanya itu, aplikasi ini juga membutuhkan pemeliharaan setidaknya tiga lapisan perangkat keras dan perangkat lunak, yang bisa jadi tidak efisien untuk bisnis. 

Model aplikasi 3 tingkat juga sering disebut arsitektur monolitik. Saat ini, kami memiliki beberapa model arsitektur baru dan di bawah ini kami akan menggali beberapa yang kini tersedia dalam era cloud.

Dalam model cloud, aplikasi kompleks yang dirancang sebagai kumpulan layanan dan data sepenuhnya terpisah dari aplikasi. Layanan mikro adalah gaya arsitektur yang menyusun aplikasi sebagai kumpulan layanan. Setiap layanan dapat ditulis dalam bahasa pemrograman yang berbeda dan diuji secara terpisah. Mereka dapat digunakan secara independen dan diatur di sekitar kemampuan bisnis.

Ambil contoh aplikasi e-commerce yang dikembangkan menggunakan arsitektur layanan mikro. Setiap layanan mikro dapat berfokus pada kemampuan bisnis tunggal (misalnya, keranjang belanja, pencarian, ulasan pelanggan). Masing-masing dapat menjadi layanan terpisah yang ditulis dalam bahasa pemrograman yang berbeda, diterapkan dalam infrastruktur yang berbeda, dan dikelola oleh tim yang berbeda.

Setiap layanan berkomunikasi dengan yang lain menggunakan protokol ringan. Untuk aplikasi 3 tingkat, kita semua mengetahui kerangka kerja Model View Controller (MVC). Sidecar, Ambassador, dan Adapter adalah beberapa kerangka kerja yang mendukung arsitektur layanan mikro.

Arsitektur layanan mikro vs arsitektur monolitik

Dalam arsitektur monolitik, semua komponen ini hidup berdampingan sebagai satu modul yang dikelola (sebagian besar) oleh satu tim—semuanya digabungkan. Jika perlu memperbarui, Anda harus menerapkan seluruh aplikasi dan ini memperlambat perubahan untuk aplikasi kompleks yang lebih besar. Untuk aplikasi yang lebih kecil, arsitektur monolitik sering kali merupakan solusi terbaik.

Layanan mikro, kontainer, dan Kubernetes

Salah satu pilihan terbaik untuk membuat dan menjalankan arsitektur aplikasi layanan mikro adalah dengan menggunakan kontainer. Kontainer menggabungkan lingkungan waktu proses virtualisasi yang ringan untuk aplikasi Anda dan memungkinkan Anda untuk memindahkan aplikasi dari desktop pengembang hingga ke penerapan produksi. Anda dapat menjalankan kontainer pada mesin virtual atau mesin fisik di sebagian besar sistem operasi yang tersedia. Kontainer menyajikan lingkungan perangkat lunak yang konsisten, dan Anda dapat menggabungkan semua dependensi aplikasi Anda sebagai unit yang dapat diterapkan. Kontainer dapat berjalan pada laptop, bare metal server, atau di cloud publik.

Banyak organisasi menggunakan Kubernetes untuk mengelola kontainer dan memastikan tidak ada waktu henti. Kubernetes menyediakan orkestrasi kontainer di beberapa host dan digunakan untuk manajemen siklus hidup kontainer. Anda dapat mengotomatiskan penerapan, menskalakan aplikasi secara otomatis, serta membangun dan mengirim dengan cepat menggunakan Kubernetes.

Untuk menyelami Kubernetes lebih dalam, lihat video kami “Penjelasan Kubernetes”:

Red Hat OpenShift adalah salah satu platform kontainer perusahaan hybrid cloud terkemuka yang paling populer. Banyak penyedia cloud menawarkan Kontainer sebagai Layanan (CaaS). Beberapa mesin Kubernetes lain yang tersedia adalah IBM® Cloud Kubernetes Service, Kubernetes sumber terbuka, AWS (EKS, ECS, dan Fargate), Google GKS, dan Azure AKS.

Biasanya setiap layanan mikro dibangun oleh tim kecil yang berbeda dan mereka memilih bahasa pemrograman dan jadwal penerapannya. Jaring layanan seperti Istio digunakan oleh perusahaan untuk mengatur komunikasi antara layanan mikro dan manajemen. Dalam jaring layanan, permintaan dialihkan melalui proxy (seperti Sidecar) antara layanan mikro.

Arsitektur cloud native dirancang khusus untuk aplikasi yang direncanakan untuk diterapkan di cloud dan layanan mikro merupakan bagian yang penting.

Cloud native adalah pendekatan untuk membangun dan menjalankan aplikasi yang mengeksploitasi keunggulan model pengiriman komputasi cloud. Cloud native adalah istilah yang digunakan untuk menggambarkan lingkungan berbasis kontainer dan ini menyangkut bagaimana aplikasi dibuat dan diterapkan, bukan di mana.

Teknologi cloud native memberdayakan kami untuk menjalankan aplikasi di cloud publik, cloud pribadi, dan hybrid cloud. Pengembangan cloud native sangat penting untuk meluncurkan aplikasi ke pasar dengan cepat; ini membantu orang, proses, dan teknologi untuk membangun, menerapkan, dan mengelola aplikasi yang siap untuk cloud.

Model arsitektur cloud native menggunakan DevOps, integrasi berkelanjutan (CI), pengiriman berkelanjutan (CD), layanan mikro, dan kontainer. Sebagian besar perusahaan menggunakan metodologi dua belas faktor untuk merancang aplikasi cloud native yang dapat diskalakan dan kuat.

Di cloud, aplikasi harus dapat berjalan secara bersamaan di beberapa node, berbagi status konfigurasi/sesi, memiliki mekanisme pencatatan terpusat, dan dapat menerapkan menggunakan DevOps dan proses CI/CD. Banyak penyedia cloud memberikan pedoman untuk pengembangan cloud native—Amazon Web Services (AWS) memiliki kerangka kerja yang dirancang dengan baik, Google memiliki berbagai panduan tentang cara membangun aplikasi cloud native, dan Microsoft Azure memiliki panduan pola cloud.

Biasanya, aplikasi cloud native secara alami tidak menyimpan status. Layanan berkomunikasi satu sama lain menggunakan protokol atau pesan berbasis REST. API Gateway, container registry, middleware berorientasi pesan (MOM: Publish/Subscribe atau Request/Response), jaring layanan, dan orkestrasi dapat menjadi bagian dari arsitektur cloud native.

Arsitektur berbasis peristiwa (EDA) didasarkan pada sistem yang dipisahkan yang berjalan sebagai respons terhadap peristiwa. Arsitektur berbasis peristiwa menggunakan peristiwa untuk memicu dan berkomunikasi antara layanan yang dipisahkan. EDA telah tersedia sejak lama, tetapi sekarang memiliki lebih banyak relevansi di cloud.

Jadi, apa yang baru? Jika digunakan dengan benar, dapat memberikan peningkatan yang signifikan dalam ketangkasan, penghematan biaya, dan manfaat operasional. EDA nirserver terdistribusi dapat mengeksekusi kode yang dikenal sebagai fungsi yang diskalakan secara otomatis sebagai respons terhadap REST API atau pemicu peristiwa.

Untuk model nirserver, tidak ada manajemen server yang diperlukan. Model nirserver juga dapat diskalakan dengan cepat (sehingga memungkinkan pembaruan dan penerapan cepat) dan tidak menyimpan status.

Berikut adalah beberapa layanan nirserver cloud yang tersedia saat ini dari penyedia cloud yang berbeda:

Jenis nirserver

• Fungsi sebagai Layanan (FaaS): Unggah bagian fungsionalitas ke cloud dan biarkan bagian ini dieksekusi secara independen.
• Backend sebagai Layanan (BaaS): Memanfaatkan layanan dari pihak ketiga, seperti manajemen aplikasi, manajemen basis data, dan penyimpanan cloud.
• Backend Mobile sebagai Layanan (MBaaS): Fungsi untuk aplikasi mobile.

Bagaimana kita bisa membuat aplikasi monolitik bekerja dengan baik di lingkungan cloud? Arsitektur berbasis cloud paling cocok untuk membangun aplikasi web modern (situs web statis/dinamis), menerapkan aplikasi web, menghubungkan ke basis data, dan menganalisis perilaku pengguna.

Arsitektur aplikasi berbasis cloud tradisional melibatkan penyeimbang beban, server web, server aplikasi, dan basis data. Arsitektur ini dapat memanfaatkan fitur cloud seperti elastisitas sumber daya, jaringan yang ditentukan perangkat lunak, penyediaan otomatis, ketersediaan tinggi, dan skalabilitas.

Jenis arsitektur ini sangat ideal untuk organisasi yang tidak perlu mengkhawatirkan pemeliharaan server. Fungsi nirserver mendukung bahasa pemrograman berbeda, seperti PHP, Java, .NET, Node.js, Python, Ruby, Docker, dan Go.

API Gateway adalah layanan penting yang memudahkan pengembang untuk membuat dan menerbitkan API yang aman. API akan bertindak sebagai pintu depan bagi aplikasi untuk mengakses data dan logika bisnis. API juga mengurus otorisasi dan kontrol akses. Pengembang menggunakan API Gateway untuk memanggil fungsi nirserver berbeda untuk panggilan API yang berbeda.

Keputusan yang Anda buat ketika memilih model arsitektur dapat memengaruhi keberhasilan atau kegagalan proyek Anda. Anda harus membuat pilihan berdasarkan aplikasi Anda dan persyaratan nonfungsional. Misalnya, Anda tidak memilih transportasi pesawat ketika ingin melakukan perjalanan beberapa mil saja.

Pertimbangkan hal berikut sebelum memilih arsitektur untuk proyek aplikasi Anda:

• Apakah proyek ini mengutamakan monolitik atau layanan mikro? (Untuk proyek yang lebih kecil dengan persyaratan aplikasi sederhana, monolitik mungkin merupakan pilihan yang tepat.)
• Apakah tim Anda siap menggunakan layanan mikro?
• Apakah tim Anda sudah memiliki proses DevOps dan CI/CD berbasis cloud?
• Apa model hosting Anda? Pribadi, publik, hybrid?
• Bagaimana arsitektur aplikasi memengaruhi proyek Anda?
• Apakah kombinasi beberapa model arsitektur cocok untuk Anda?
• Apakah Anda membutuhkan ketekunan dan sesi untuk aplikasi Anda?

Arsitektur aplikasi web terus berkembang untuk memenuhi persyaratan bisnis digital dan mengubah lingkungan infrastruktur TI. Teknologi seperti Kecerdasan buatan, Analitik, Otomatisasi, Robotika Canggih, Komputasi Tepi, Blockchain, Internet of Things (IoT), dan API merombak kemungkinan di banyak industri. Peningkatan kompleksitas dalam infrastruktur, aplikasi, dan ukuran data membutuhkan pendekatan arsitektur baru. Sebagian besar perusahaan mengadopsi pendekatan multicloud dengan menggunakan satu penyedia cloud atau lebih. Perusahaan menggunakan layanan cloud dengan menggunakan model pribadi, publik, atau hybrid dengan model SaaS, PaaS, atau IaaS.

Dahulu penerapan aplikasi adalah proses yang sulit dan tidak dapat dilakukan selama jam kerja normal. Namun, metode penerapan yang berbeda (seperti penyebaran blue-green dan penyebaran canary) serta DevOps dan CI/CD (integrasi berkelanjutan dan pengiriman berkelanjutan) sekarang memungkinkan penerapan kapan saja tanpa gangguan aplikasi.

Arsitektur monolitik masih berlaku untuk banyak aplikasi tetapi arsitektur yang tepat harus digunakan untuk contoh penggunaan digital Anda guna mencapai ketangkasan dan penyiapan produk. Untuk aplikasi sederhana, pertimbangkan untuk memilih pendekatan monolitik tradisional. Pola cloud native atau layanan mikro bekerja sangat baik untuk mengembangkan aplikasi dengan kompleksitas. Masuk akal untuk menggunakan arsitektur layanan mikro jika Anda memiliki beberapa tim berpengalaman yang menggunakan berbagai bahasa dan jadwal penerapan. Perbandingan antara aplikasi tradisional tingkat 3/N vs model arsitektur berbasis cloud diberikan di bawah ini sebagai referensi.

Untuk mulai membangun, daftar IBMid dan buat akun IBM Cloud Anda.