Panduan referensi ini adalah bagian pertama dari empat bagian tentang merancang, membangun, dan men-deploy microservice. Rangkaian ini menjelaskan berbagai elemen arsitektur microservice. Seri ini mencakup informasi tentang kelebihan dan kekurangan pola arsitektur microservice, dan cara menerapkannya.
- Pengantar microservice (dokumen ini)
- Memfaktorkan ulang monolit menjadi microservice
- Komunikasi antarlayanan dalam penyiapan microservice
- Pelacakan terdistribusi di aplikasi microservice
Seri ini ditujukan untuk developer dan arsitek aplikasi yang merancang dan mengimplementasikan migrasi untuk memfaktorkan ulang aplikasi monolit ke aplikasi microservice.
Aplikasi monolitik
Aplikasi monolitik adalah aplikasi software satu tingkat yang berbeda modulnya digabungkan ke dalam satu program. Misalnya, jika Anda mem-build aplikasi e-commerce, aplikasi tersebut diharapkan memiliki arsitektur modular yang selaras dengan prinsip pemrograman berorientasi objek (OOP). Diagram berikut menunjukkan contoh penyiapan aplikasi e-commerce, yang terdiri dari berbagai modul dalam setiap aplikasi. Dalam aplikasi monolitik, modul ditentukan menggunakan kombinasi konstruksi bahasa pemrograman (seperti paket Java) dan artefak build (seperti file JAR Java).
Gambar 1. Diagram aplikasi e-commerce monolitik dengan beberapa modul yang menggunakan kombinasi konstruksi bahasa pemrograman.
Pada Gambar 1, modul yang berbeda dalam aplikasi e-commerce sesuai dengan logika bisnis untuk pembayaran, pengiriman, dan pengelolaan pesanan. Semua modul ini dipaket dan di-deploy sebagai satu file logis yang dapat dieksekusi. Format yang sebenarnya bergantung pada bahasa dan framework aplikasi. Misalnya, berbagai aplikasi Java dipaketkan sebagai file JAR dan di-deploy di server aplikasi seperti Tomcat atau Jetty. Demikian pula, aplikasi Rails atau Node.js dikemas sebagai hierarki direktori.
Manfaat monolit
Arsitektur monolitik adalah solusi konvensional untuk mem-build aplikasi. Berikut ini beberapa keuntungan mengadopsi desain monolitik untuk aplikasi Anda:
- Anda dapat menerapkan pengujian aplikasi monolitik secara menyeluruh dengan menggunakan alat seperti Selenium.
- Untuk men-deploy aplikasi monolitik, Anda cukup menyalin aplikasi yang dipaketkan ke server.
- Semua modul dalam aplikasi monolitik berbagi memori, ruang, dan resource, sehingga Anda dapat menggunakan satu solusi untuk mengatasi masalah lintas sektor seperti logging, caching, dan keamanan.
- Pendekatan monolitik dapat memberikan keuntungan performa, karena modul dapat memanggil satu sama lain secara langsung. Sebaliknya, microservice biasanya memerlukan panggilan jaringan untuk berkomunikasi satu sama lain.
Tantangan monolit
Monolit yang kompleks sering kali menjadi semakin sulit untuk di-build, di-debug, dan dijadikan alasan. Pada titik tertentu, masalah lebih besar daripada manfaatnya.
- Aplikasi biasanya berkembang seiring waktu. Ini dapat menjadi rumit untuk mengimplementasikan perubahan dalam aplikasi besar dan kompleks serta sangat ketat saat memiliki modul yang digabungkan. Karena setiap perubahan kode memengaruhi seluruh sistem, Anda harus mengoordinasikan perubahan secara menyeluruh. Mengkoordinasikan perubahan membuat keseluruhan proses pengembangan dan pengujian jauh lebih lama dibandingkan dengan aplikasi microservice.
- Sangat sulit untuk mencapai continuous integration dan deployment (CI/CD) dengan monolit yang besar. Kompleksitas ini terjadi karena Anda harus men-deploy ulang seluruh aplikasi untuk memperbarui salah satu bagiannya. Selain itu, Anda mungkin harus melakukan pengujian manual yang ekstensif pada seluruh aplikasi untuk memeriksa regresi.
- Aplikasi monolitik dapat menjadi sulit untuk diskalakan saat modul yang berbeda memiliki persyaratan resource yang bertentangan. Misalnya, satu modul mungkin mengimplementasikan logika pemrosesan gambar yang menggunakan CPU secara intensif. Modul lain mungkin berupa database dalam memori. Karena modul ini di-deploy bersama-sama, Anda harus menyusupi pilihan hardware.
- Karena semua modul berjalan dalam proses yang sama, bug dalam modul apa pun, seperti kebocoran memori, berpotensi merusak seluruh sistem.
- Aplikasi monolitik menambah kompleksitas ketika Anda ingin mengadopsi framework dan bahasa baru. Misalnya, akan mahal (dalam hal waktu dan uang) untuk menulis ulang seluruh aplikasimenggunakan kerangka kerja baru, bahkan jika kerangka kerja itu jauh lebih baik.
Aplikasi berbasis microservice
Microservice biasanya mengimplementasikan serangkaian fitur atau fungsi yang berbeda. Setiap microservice adalah aplikasi mini yang memiliki arsitektur dan logika bisnisnya sendiri. Misalnya, beberapa microservice menampilkan API yang digunakan microservice lain atau klien aplikasi, seperti integrasi pihak ketiga dengan gateway pembayaran dan logistik.
Gambar 1 menunjukkan aplikasi e-commerce monolitik dengan beberapa modul. Diagram berikut menunjukkan kemungkinan dekomposisi aplikasi e-commerce menjadi microservice:
Gambar 2. Diagram aplikasi e-commerce dengan area fungsional yang diterapkan oleh microservice.
Pada Gambar 2, microservice khusus menerapkan setiap area fungsional aplikasi e-commerce. Setiap layanan backend dapat mengekspos API, dan layanan menggunakan API yang disediakan layanan lain. Misalnya, untuk merender halaman web, layanan UI memanggil layanan checkout dan layanan lainnya. Layanan mungkin juga menggunakan komunikasi berbasis pesan asinkron. Untuk mengetahui informasi selengkapnya tentang cara layanan berkomunikasi satu sama lain, baca dokumen ketiga dalam seri ini, Komunikasi antarlayanan dalam penyiapan microservice.
Pola arsitektur microservice secara signifikan mengubah hubungan antara aplikasi dan database. Daripada berbagi satu database dengan layanan lain, sebaiknya setiap layanan memiliki database sendiri yang paling sesuai dengan kebutuhan. Jika memiliki satu database untuk setiap layanan, Anda memastikan pengaitan longgar antar layanan karena semua permintaan data melewati API layanan, bukan melalui database bersama secara langsung. Diagram berikut menunjukkan pola arsitektur microservice dengan setiap layanan yang memiliki database sendiri:
Gambar 3. Setiap layanan dalam arsitektur microservice memiliki database sendiri.
Pada Gambar 3, layanan pesanan pada aplikasi e-commerce berfungsi dengan baik menggunakan database berorientasi dokumen yang memiliki kemampuan penelusuran real-time. Layanan pembayaran dan pengiriman bergantung pada atomisitas, konsistensi, isolasi, ketahanan (ACID) yang kuat dari database relasional.
Manfaat microservice
Pola arsitektur microservice mengatasi masalah kompleksitas yang dijelaskan di bagian Tantangan Monolit sebelumnya. Arsitektur microservice memberikan manfaat berikut:
- Meskipun total fungsionalitas tidak berubah, Anda menggunakan microservice untuk memisahkan aplikasi menjadi potongan atau layanan yang dapat dikelola. Setiap layanan memiliki batas yang jelas dalam bentuk RPC atau API berbasis pesan. Oleh karena itu, setiap layanan dapat dikembangkan lebih cepat, serta lebih mudah dipahami dan dikelola.
- Tim otonom dapat mengembangkan setiap layanan secara independen. Anda dapat mengatur microservice di seputar batas bisnis, bukan kemampuan teknis produk. Anda mengatur tim untuk tanggung jawab independen atas seluruh siklus proses software yang ditetapkan bagi mereka, mulai dari pengembangan, pengujian, deployment, hingga pemeliharaan serta pemantauan.
- Dengan proses pengembangan microservice independen, developer juga dapat menulis setiap microservice dalam bahasa pemrograman berbeda, sehingga membuat aplikasi polyglot. Saat menggunakan bahasa paling efektif untuk setiap microservice, Anda dapat mengembangkan aplikasi lebih cepat dan mengoptimalkan aplikasi untuk mengurangi kompleksitas kode serta meningkatkan performa dan fungsi.
- Saat memisahkan kemampuan dari monolit, Anda dapat meminta tim independen merilis microservice mereka secara independen. Siklus rilis independen dapat membantu meningkatkan kecepatan tim dan waktu penyiapan produk Anda.
- Arsitektur microservice juga memungkinkan Anda menskalakan setiap layanan secara independen. Anda dapat men-deploy jumlah instance dari setiap layanan yang memenuhi batasan kapasitas dan ketersediaan. Anda juga dapat menggunakan hardware yang paling cocok dengan persyaratan resource layanan. Saat menskalakan layanan secara independen, Anda membantu meningkatkan ketersediaan dan keandalan seluruh sistem.
Berikut adalah beberapa instance tertentu yang berguna untuk bermigrasi dari monolit ke arsitektur microservice:
- Menerapkan peningkatan dalam skalabilitas, pengelolaan, fleksibilitas, atau kecepatan penayangan.
- Secara bertahap menulis ulang aplikasi lama yang besar ke bahasa dan technology stack modern untuk memenuhi permintaan bisnis baru.
- Mengekstrak aplikasi bisnis lintas sektor atau layanan lintas sektor sehingga Anda dapat menggunakannya kembali di beberapa saluran. Contoh layanan yang mungkin ingin Anda gunakan kembali meliputi layanan pembayaran, layanan login, layanan enkripsi, layanan penelusuran penerbangan, layanan profil pelanggan, dan layanan notifikasi.
- Mengadopsi bahasa atau framework yang dibuat khusus untuk fungsi tertentu dari monolit yang sudah ada.
Tantangan microservice
Microservice memiliki beberapa tantangan jika dibandingkan dengan monolit, termasuk hal berikut:
- Tantangan utama microservice adalah kompleksitas yang ditimbulkan karena aplikasi tersebut merupakan sistem terdistribusi. Developer harus memilih dan menerapkan mekanisme komunikasi antar-layanan. Layanan juga harus menangani kegagalan parsial dan ketidaktersediaan layanan upstream.
Tantangan lain pada microservice adalah Anda perlu mengelola transaksi di berbagai microservice (disebut juga sebagai transaksi terdistribusi). Operasi bisnis yang mengupdate beberapa entity bisnis sudah umum, dan biasanya diterapkan dengan cara atomik, di mana semua operasi diterapkan atau semuanya gagal. Saat menggabungkan beberapa operasi dalam satu transaksi database, Anda akan memastikan atomicity.
Dalam aplikasi berbasis microservice, operasi bisnis mungkin tersebar di berbagai microservice, sehingga Anda perlu mengupdate beberapa database yang dimiliki berbagai layanan. Jika terjadi kegagalan, tidaklah mudah untuk melacak kegagalan atau keberhasilan panggilan ke microservice yang berbeda dan status roll back. Skenario terburuk dapat menyebabkan data yang tidak konsisten di antara layanan saat rollback status karena kegagalan tidak terjadi dengan benar. Untuk mengetahui informasi tentang berbagai metodologi dalam menyiapkan transaksi terdistribusi antarlayanan, baca dokumen ketiga dalam rangkaian ini, Komunikasi antarlayanan dalam penyiapan microservice.
Pengujian menyeluruh pada aplikasi berbasis microservice lebih kompleks daripada pengujian aplikasi monolitik. Misalnya, untuk menguji fungsi pemrosesan pesanan di layanan e-commerce monolitik, Anda perlu memilih item, menambahkannya ke keranjang, lalu melakukan check out. Untuk menguji alur yang sama dalam arsitektur berbasis microservice, beberapa layanan - seperti frontend, pesanan, dan pembayaran - saling memanggil untuk menyelesaikan pengujian.
Men-deploy aplikasi berbasis microservice lebih kompleks daripada men-deploy aplikasi monolitik. Aplikasi microservice biasanya terdiri dari berbagai layanan,masing-masing memiliki beberapa instance runtime. Anda juga perlu mengimplementasikan mekanisme penemuan layanan yang memungkinkan layanan menemukan lokasi layanan lain yang perlu berkomunikasi.
Arsitektur microservice menambahkan beban operasi karena ada lebih banyak layanan untuk dipantau dan pemberitahuan. Arsitektur microservice juga memiliki lebih banyak titik kegagalan karena peningkatan titik komunikasi layanan ke layanan. Aplikasi monolitik mungkin di-deploy ke cluster server aplikasi yang kecil. Aplikasi berbasis microservice mungkin memiliki puluhan layanan terpisah untuk di-build, diuji, di-deploy, dan dijalankan, kemungkinan dalam berbagai bahasa dan lingkungan. Semua layanan ini perlu dikelompokkan untuk failover dan ketahanan. Untuk memproduksi aplikasi microservice, Anda memerlukan infrastruktur operasi dan pemantauan berkualitas tinggi.
Pembagian layanan dalam arsitektur microservice memungkinkan aplikasi menjalankan lebih banyak fungsi secara bersamaan. Namun, karena modul berjalan sebagai layanan terisolasi, latensi muncul dalam waktu respons karena panggilan jaringan antarlayanan.
Tidak semua aplikasi cukup besar untuk dipecah menjadi microservice. Selain itu, beberapa aplikasi memerlukan integrasi yang erat antar-komponen misalnya, aplikasi yang harus memproses aliran data real-time yang cepat. Setiap lapisan komunikasi tambahan antarlayanan dapat memperlambat pemrosesan real-time. Memikirkan komunikasi antarlayanan sebelumnya dapat memberikan insight bermanfaat dalam menandai batas layanan dengan jelas.
Saat menentukan apakah arsitektur microservice terbaik untuk aplikasi Anda, pertimbangkan hal-hal berikut:
- Praktik terbaik microservice memerlukan database per layanan. Saat melakukan pemodelan data untuk aplikasi Anda, perhatikan apakah database per layanan cocok dengan aplikasi Anda.
- Saat mengimplementasikan arsitektur microservice, Anda harus menginstrumentasikan dan memantau lingkungan agar dapat mengidentifikasi bottleneck, mendeteksi dan mencegah kegagalan, serta mendukung diagnostik.
- Dalam arsitektur microservice, setiap layanan memiliki kontrol akses terpisah. Untuk membantu memastikan keamanan, Anda perlu mengamankan akses ke setiap layanan baik di dalam lingkungan maupun dari aplikasi eksternal yang menggunakan API.
- Komunikasi sinkron antarlayanan biasanya mengurangi ketersediaan aplikasi. Misalnya, jika layanan pesanan dalam aplikasi e-commerce memanggil layanan upstream lain secara sinkron, dan jika layanan tersebut tidak tersedia, pesanan tidak dapat dibuat. Oleh karena itu, sebaiknya terapkan komunikasi berbasis pesan asinkron.
Kapan harus melakukan migrasi aplikasi monolitik ke microservice
Jika sudah berhasil menjalankan monolit, mengadopsi microservice adalah biaya investasi yang signifikan bagi tim Anda. Setiap tim menerapkan prinsip microservice dengan cara yang berbeda. Setiap tim engineering memiliki hasil unik terkait seberapa kecil microservice mereka, atau jumlah microservice yang mereka butuhkan.
Untuk menentukan apakah microservice adalah pendekatan terbaik untuk aplikasi Anda, pertama-tama identifikasi sasaran bisnis utama atau poin masalah yang ingin Anda tangani. Mungkin ada cara yang lebih sederhana untuk mencapai sasaran atau mengatasi masalah yang Anda identifikasi. Misalnya, jika ingin meningkatkan skala aplikasi dengan lebih cepat, Anda mungkin mendapati bahwa penskalaan otomatis adalah solusi yang lebih efisien. Jika menemukan bug dalam produksi, Anda dapat memulai dengan menerapkan pengujian unit dan continuous integration (CI).
Jika Anda yakin bahwa pendekatan microservice adalah cara terbaik untuk mencapai tujuan, mulailah dengan mengekstrak satu layanan dari monolit lalu kembangkan, uji, dan deploy dalam lingkungan produksi. Untuk mengetahui informasi selengkapnya, lihat dokumen berikutnya dalam rangkaian ini, Memfaktorkan ulang monolit menjadi microservice. Setelah Anda berhasil mengekstrak satu layanan dan menjalankannya dalam produksi, mulailah ekstraksi layanan berikutnya dan lanjutkan mempelajari setiap siklus.
Pola arsitektur microservice mengurai sistem menjadi sekumpulan layanan yang dapat di-deploy secara independen. Saat mengembangkan aplikasi monolitik, Anda harus mengoordinasikan tim besar, yang dapat menyebabkan pengembangan software melambat. Saat menerapkan arsitektur microservice, Memungkinkan tim otonom kecil Anda untuk bekerja secara paralel, sehingga dapat mempercepat pengembangan.
Dalam dokumen berikutnya pada seri ini, Memfaktorkan ulang monolit menjadi microservice, Anda akan mempelajari berbagai strategi untuk memfaktorkan ulang aplikasi monolitik ke dalam microservice.
Langkah selanjutnya
- Baca dokumen berikutnya dalam seri ini untuk mempelajari strategi pemfaktoran ulang aplikasi untuk menguraikan microservice.
- Baca dokumen ketiga dalam seri ini untuk mempelajari komunikasi antar-layanan dalam penyiapan microservice.
- Baca dokumen terakhir keempat dalam seri ini untuk mempelajari penelusuran permintaan terdistribusi antar microservice.