142 W. SOA vs MicroServices Seseorang melihat microservices sebagai ekstensi service- oriented architecture (SOA). Orang lain akan mengatakan bahwa perbedaan terlalu banyak. Ada realitas yang perlu dinegosiasi ketika bekerja dengan microservices. Aspek paling penting ketika menjalankan aplikasi microservices adalah bagai mana anda memantau mereka. (Taylor 2018) Definisi Layanan Berbeda Perbedaan kunci di antara SOA dan microservices adalah bagai mana mereka melihat layanan. Dalam SOA, focus pada service reusability, sedangkan dalam microservices, service decoupling is the order of the day. Ketika suatu hari ada perubahan dibuat dalam SOA- based application, monolith-nya dimodifikasi. Dengan microservices, fitur baru akan didekomposisi menuju layanan milik kita. Ini memiliki kaitan tentang bagaimana tata kelola dan pemantauan bekerja untuk sistem ini. Dengan SOA, ini adalah model top-down di mana seluruh dipantau dan masing-masing bagian dipantau sehubungan dengan keseluruhan. Dengan microservices, setiap layanan memerlukan pemantauan tersendiri. Setiap layanan berada di bawah radar ketika menilai kinerja. Karena layanan lebih terfokus, dan setiap fitur baru menjadi layanan baru, seiring waktu setiap layanan menjadi fokus laser pada satu
43
Embed
W. SOA vs MicroServices service- oriented …staff.unila.ac.id/rasp/files/2018/04/BAB-II-C-rev-1.pdf142 W. SOA vs MicroServices Seseorang melihat microservices sebagai ekstensi service-oriented
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
142
W. SOA vs MicroServices
Seseorang melihat microservices sebagai ekstensi service-
oriented architecture (SOA). Orang lain akan mengatakan bahwa
perbedaan terlalu banyak. Ada realitas yang perlu dinegosiasi ketika
bekerja dengan microservices. Aspek paling penting ketika menjalankan
aplikasi microservices adalah bagai mana anda memantau mereka.
(Taylor 2018)
Definisi Layanan Berbeda
Perbedaan kunci di antara SOA dan microservices adalah bagai
mana mereka melihat layanan. Dalam SOA, focus pada service
reusability, sedangkan dalam microservices, service decoupling is the
order of the day. Ketika suatu hari ada perubahan dibuat dalam SOA-
based application, monolith-nya dimodifikasi. Dengan microservices, fitur
baru akan didekomposisi menuju layanan milik kita.
Ini memiliki kaitan tentang bagaimana tata kelola dan pemantauan
bekerja untuk sistem ini. Dengan SOA, ini adalah model top-down di mana
seluruh dipantau dan masing-masing bagian dipantau sehubungan
dengan keseluruhan. Dengan microservices, setiap layanan memerlukan
pemantauan tersendiri. Setiap layanan berada di bawah radar ketika
menilai kinerja.
Karena layanan lebih terfokus, dan setiap fitur baru menjadi
layanan baru, seiring waktu setiap layanan menjadi fokus laser pada satu
143
tugas khusus yang melakukan secara eksklusif. Hal ini menghasilkan
banyak layanan kecil yang lebih ringan, lebih cepat dan lebih mudah untuk
dikelola dan dipantau. Diambil bersama-sama, semua layanan akan churn
(dikocok) keluar lebih metrik dalam sistem Layanan mikro dari pada
sistem SOA. Ini adalah anugerah, karena menyediakan lebih banyak
visibilitas dan kontrol granular di setiap tingkat. Jadi, ketika mencoba
untuk memahami perbedaan antara pemantauan aplikasi yang
berarsitektur SOA dan aplikasi arsitektur layanan mikro, bagai mana
mereka melihat layanan memainkan peran kunci. Perbedaannya tidak
berhenti di sini. Mereka melanjutkan ke jaringan layanan, dan unit
infrastruktur yang mendasari.
Pemantauan Komunikasi Layanan
SOA menggunakan enterprise service bus (ESB, lihat Gambar
2.29) untuk menangani komunikasi secara internal di antara variasi
layanan yang membuat suatu aplikasi, dan secara eksternal dengan
aplikasi dan klien lain. ESB memainkan peran sentral dalam
memfungsikan aplikasi SOA. Ia menghidupkan keaneka-ragaman dalam
protocol yang melayani penggunaan komunikasi dengan yang lain. Ia
bertindak sebagai mediator pusat di antara semua layanan dan bertujuan
menyediakan dukungan out-of-the-box untuk variasi protocol dan, dalam
cara ini, mempercepat komunikasi.
144
Pemantauan SOA berkisar di sekitar pengolahan pesan antar
layanan. ESB adalah lapisan yang mentransmisikan pesan antar layanan,
sehingga jika Layanan berjalan lambat atau gagal, jumlah pesan ke
layanan menumpuk di ESB. Oleh karena itu, penting untuk melacak
jumlah pesan dalam antrean untuk menemukan latensi atau kegagalan
dalam layanan. (Metrik terkait untuk melacak adalah pesan tertua dalam
antrian untuk mengetahui sejauh mana latensi). Selain itu, untuk setiap
layanan ini membantu untuk melacak pesan yang diproses per-menit atau
per-lima-menit dan memantau penyimpangan dari rerata.
Layanan mikro berangkat dari rute ESB tradisional untuk
mengadopsi layanan API Gateway. Dalam microservices, setiap layanan
menggunakan API untuk mengekspos dirinya ke layanan lain dan
konsumen. API layanan ini terdesentralisasi, tidak seperti di ESB, namun
masih memerlukan pemantauan untuk memahami jika API berkomunikasi
secara efektif dengan sisa layanan yang berjalan dalam kontainer. Jika
tidak, API menjadi blind spot dalam memonitor Layanan mikro Anda.
Infrastruktur Pemantauan
SOA telah lazim dari zaman server perangkat keras ke era
virtualisasi dan mempertimbangkan kendala tertentu dari infrastruktur
yang kekuasaan itu. VM lebih besar dalam ukuran dan membutuhkan
waktu untuk mengonfigurasi. Setiap kali ada update ke VM, itu
dimodifikasi dan berjalan meninggalkan, dan VM secara tipikal akan
145
berjalan selama berbulan-bulan atau bahkan bertahun-tahun dengan
beberapa perubahan. Ini berarti bahwa layanan dirantai ke infrastruktur,
dan perubahan hanya dapat dibuat sebanyak infrastruktur memungkinkan.
Perubahan drastis dalam jumlah host yang mendasari atau volume
penyimpanan historis belum mungkin. Konfigurasi Drift adalah tantangan
konstan sebagai VM dan Perpustakaan di dalamnya menjadi usang
dengan cepat. Pemantauan stack berbasis VM melibatkan menonton
metrik statis termasuk latensi, throughput dan IOPS. Komponen yang
mempengaruhi metrik ini lebih seperti kotak hitam dengan kontrol terbatas
untuk berubah. Hal ini telah menyebabkan pergeseran dalam fokus dalam
pertempuran kontainer versus VM, dengan kontainer yang keluar di atas.
Microservices dan kontainer pergi bersama-sama. Pada era
modern aplikasi Cloud-Native saat ini, kontainer telah menjadi infrastruktur
pilihan untuk menjalankan aplikasi Layanan mikro. Kontainer membawa
banyak manfaat atas VM: mereka jauh lebih kecil daripada VM-hanya
beberapa megabyte ukuran dibandingkan dengan banyak gigabyte yang
menempati VM di server. Mereka diciptakan dalam beberapa detik, tidak
seperti VM, yang dapat mengambil menit berharga. Kontainer dapat
dibuat dan dihancurkan dengan mudah, dan mereka mengaktifkan
infrastruktur yang tidak berubah di mana pembaruan dikirim tidak dalam
suntingan untuk instance yang ada tetapi dengan membuat instance yang
sama sekali baru. Tumpukan kontainer juga jauh lebih rumit daripada
146
tumpukan VM, dengan komponen baru seperti registri kontainer, alat
orkestrasi dan volume penyimpanan terpisah.
Microservices dan kontainer pergi bersama-sama. Pada era
modern aplikasi Cloud-Native saat ini, kontainer telah menjadi infrastruktur
pilihan untuk menjalankan aplikasi Layanan mikro. Kontainer membawa
banyak manfaat atas VM: mereka jauh lebih kecil daripada VM-hanya
beberapa megabyte ukuran dibandingkan dengan banyak gigabyte yang
menempati VM di server. Mereka diciptakan dalam beberapa detik, tidak
seperti VM, yang dapat mengambil menit berharga. Kontainer dapat
dibuat dan dihancurkan dengan mudah, dan mereka mengaktifkan
infrastruktur yang tidak berubah di mana pembaruan dikirim tidak dalam
suntingan untuk instance yang ada tetapi dengan membuat instance yang
sama sekali baru. Tumpukan kontainer juga jauh lebih rumit daripada
tumpukan VM, dengan komponen baru seperti registri kontainer, alat
orkestrasi dan volume penyimpanan terpisah.
Pemantauan kontainer melibatkan pelacakan setiap bagian dari
sistem, termasuk mesin kontainer, registri, gambar yang di-download,
contoh kontainer yang dibuat dan pensiunan, volume penyimpanan yang
ditetapkan secara dinamis untuk kontainer, permintaan jaringan antara
kontainer, keamanan dan kontrol akses dan banyak lagi. Containers
membawa visibilitas mendalam ke setiap langkah dari pembangunan pipa,
dan mereka melibatkan berbagai metrik yang lebih luas untuk melacak,
147
tetapi mereka juga memberikan kemungkinan pengembangan dan
pengiriman fitur jauh lebih cepat daripada SOA.
Ada perbedaan yang jelas antara SOA dan microservices. Ketika
pemantauan aplikasi ini masing-masing, pendekatan bervariasi sesuai.
Micro services tidak hanya berbeda tetapi juga lebih berevolusi dan maju
daripada mitra-nya yang lebih tua, yaitu SOA. Ketika Anda transisi dari
SOA untuk layanan mikro, mempertimbangkan bagaimana Anda dapat
mengadopsi karakteristik yang menentukan ini dari pemantauan Layanan
mikro untuk melihat hasil yang lebih baik dan memiliki kejelasan lebih ke
dalam kinerja aplikasi di setiap tingkat.
X. Memelihara Konsistensi Data Melintasi Micro-services
Ini terkait Bab I, C. Tujuan Penelitian, butir ke-1, terkait konsistensi
data. Sudah dibahas di Bab II, N. Tinjauan Hasil Penelitian, bahwa ada 6
pertimbangan desain arsitektur microservices, 1 di antaranya terkait data
integrity. Karena setiap microservice memiliki database sendiri,
memastikan konsistensi data di seluruh transaksi yang menjangkau
beberapa layanan dapat menjadi tantangan. Pola seperti Event Sourcing,
CQRS dan Saga, membantu mencapai konsistensi data. Ketika aplikasi
microservice dibangun sebagai 1 set komponen modular, mereka lebih
mudah untuk dipahami, sederhana untuk diuji dan mudah untuk
mempertahankan selama hidup aplikasi. Mereka memungkinkan
148
organisasi untuk mencapai kelincahan dan dapat meningkatkan waktu
yang dibutuhkan untuk mendapatkan peningkatan kerja untuk produksi.
Pada sisi negatifnya, ada cukup banyak tantangan — setiap
layanan memiliki database sendiri dan di mana pun transaksi bisnis
menjangkau beberapa layanan, Anda memerlukan mekanisme untuk
memastikan konsistensi data di seluruh layanan. Misalnya, jika Anda
sedang membangun aplikasi Toko Web di mana pelanggan memiliki batas
kredit, aplikasi harus memastikan bahwa pesanan baru tidak akan
melebihi batas kredit pelanggan. Karena pesanan dan pelanggan dalam
database yang berbeda, aplikasi tidak hanya dapat menggunakan
Dalam pendekatan ini, menerapkan setiap transaksi bisnis yang
mencakup beberapa layanan sebagai urutan transaksi lokal. Setiap
transaksi lokal Update database dan menerbitkan pesan atau peristiwa
untuk memicu transaksi lokal berikutnya. Jika transaksi lokal gagal karena
melanggar aturan Bisnis, kemudian menjalankan serangkaian kompensasi
transaksi yang membatalkan perubahan yang dibuat oleh transaksi lokal
sebelumnya. Ada dua cara untuk melakukannya:
1. Untuk setiap transaksi lokal, publikasikan peristiwa domain yang
memicu transaksi lokal di setiap layanan lainnya. Misalnya, jika
149
Anda sedang membangun aplikasi toko yang menggunakan
pendekatan ini, langkah berikut ini harus diambil:
a. The Order Service creates an Order in a pending state and publishes
an ORDER_CREATED event;
b. The Customer Service receives the ORDER_CREATED event and
attempts to reserve credit for that Order. It publishes either
a CREDIT_RESERVED event or a CREDIT_LIMIT_EXHAUSTED event;
c. The Order Service receives the event and changes the state of the
order to either approved or cancelled.
2. Gunakan semacam orkestrasi layanan untuk memberitahu peserta
apa transaksi lokal untuk mengeksekusi:
a. The Order Service creates an Order in a pending state and creates
a CreateOrderOrchestration;
b. The CreateOrderOrchestration sends a ReserveCredit command to
the Customer Service; The Customer Service attempts to reserve credit
for that Order and sends back a reply;
c. The CreateOrderOrchestration receives the reply and sends either
an ApproveOrder or RejectOrder command to the Order Service;
d. The Order Service changes the state of the order to
either approved or canceled.
Masalah dan pertimbangan
Logika kompensasi tidak mudah digeneralisasi. Transaksi
kompensasi khusus untuk aplikasi; itu bergantung pada aplikasi yang
150
memiliki informasi yang cukup untuk dapat membatalkan efek dari setiap
langkah dalam operasi yang gagal.
Semua langkah dalam transaksi kompensasi harus didefinisikan
sebagai perintah idempotent. Hal ini memungkinkan langkah diulang
bahkan jika kompensasi transaksi itu sendiri gagal.
Penentuan ketika langkah yang mengimplementasikan konsistensi
akhirnya telah gagal yaitu, salah satu langkah mungkin tidak gagal dengan
segera, tetapi sebaliknya dapat memblokir atau waktu habis. Mungkin
perlu menerapkan beberapa bentuk mekanisme time-out.
Sebuah transaksi kompensasi tidak selalu mengembalikan data
dalam sistem ke negara itu di awal operasi asli. Sebaliknya, ini
mengkompensasi pekerjaan yang dilakukan oleh langkah yang berhasil
diselesaikan sebelum operasi gagal.
Urutan langkah dalam transaksi kompensasi tidak harus menjadi
cermin kebalikan dari langkah dalam operasi yang asli. Sebagai contoh,
satu penyimpanan data mungkin lebih sensitif terhadap inkonsistensi
daripada yang lain, dan jadi langkah dalam transaksi kompensasi yang
membatalkan perubahan ke penyimpanan ini akan terjadi terlebih dahulu.
Rencanakan untuk menggunakan logika pengulangan. Sebagai
contoh, jika langkah dalam operasi yang menerapkan konsistensi akhirnya
gagal, cobalah menangani kegagalan sebagai pengecualian sementara
dan ulangi langkah.
151
GRIT: protokol transaksi terdistribusi
eBay telah mengembangkan protokol GRIT untuk mencapai
transaksi terdistribusi yang konsisten secara global di seluruh layanan
microservices dengan banyak basis data yang mendasari. Diagram
berikut menggambarkan protokol GRIT dalam aplikasi layanan
microservices dengan dua database:
Gambar 2.33. Untuk memahami lebih baik, mari kita lihat komponen kunci yang membentuk transaksi terdistribusi yang konsisten secara global yaitu: GTM, GTL, DBTM, DBTL, LogPlayer.
Global Transaction Manager (GTM): ini mengkoordinasikan
transaksi global di beberapa database. Bisa ada satu atau lebih GTMs.
Global Transaction Log (GTL): Ini mewakili antrian permintaan transaksi
152
untuk GTM. Urutan permintaan transaksi dalam GTL menentukan urutan
relatif di antara transaksi global.
Ketika kita mencari GTM Indonesia, tidak ditemukan satu pun
entitas dimaksud. Dikonfirmasi singkatannya oleh suatu laman dengan
Measurement Model, Development Model). Aplikasi yang terkait dengan
protocol itu bersifat global, penyesuaian Entity Services (ES) dan Global
Transaction Manager (GTM).
Dilakukan juga penyesuaian model arsitektur referensi awan
terhadap karakteristik IPO (Sentra HAKI) yang ada di perguruan tinggi
responden (misalnya Universitas Hasanuddin, Universitas
Muhammadiyah, Universitas Indonesia Timur, dan lain-lain yang
tergabung dalam ASKII (Asosiasi Sentra Kekayaan Intelektual Indonesia).
Bagai mana konfigurasi interkoneksi horizontal Cross SaaS /PaaS /IaaS
Integration dengan interkoneksi vertical Downstream SaaS – PaaS
Integration dan Downstream PaaS – IaaS Integration? Perlu penyusunan
ulang sesuai kondisi dan karakteristik Sentra HAKI.
184
DAFTAR PUSTAKA
Pahl, Claus, and Pooyan Jamshidi. 2016. “Microservices: A Systematic Mapping Study.” CLOSER 2016 - Proceedings of the 6th International Conference on Cloud Computing and Services Science 1(May): 137–46. https://www.researchgate.net/publication/302973857_Microservices_A_Systematic_Mapping_Study.
Paolo Di Francesco, Patricia Lago, and Ivano Malavolta. 2019. “Architecting with Microservices: A Systematic Mapping Study.” Journal of Systems and Software 150: 77–97. https://www.sciencedirect.com/science/article/pii/S0164121219300019.
Sekkal, Nawel et al. 2019. “Proactive and Reactive Context Reasoning Architecture for Smart Web Services.” International Journal of Data Mining, Modelling and Management X(Superieure, Ecole Ci, The Informatique, Département): 1–27. https://www.inderscience.com/admin/ospeers/getInProduction.php?id=81425&fid=4484&fromonsusy=yes.
Taylor, Twain. 2018. “SOA vs . Microservices Monitoring Different Definitions Monitoring.” Container Journal October(12): 5. https://containerjournal.com/topics/container-management/soa-vs-microservices-monitoring/.
Vizard, Mike. 2017. “How Microservices Are Transforming Big Data Analytics.” Container Journal: 4. https://containerjournal.com/features/microservices-big-data-analytics/.