100 S. Micro Service(s) Bahasa pola arsitektur micro-service adalah koleksi pola untuk mengaplikasikan arsitektur micro-service. Ia mempunyai dua tujuan: Pertama, Bahasa pola memungkinkan anda memutuskan bila mana micro-services cocok baik untuk aplikasi anda; Kedua, Bahasa pola memungkinkan anda menggunakan arsitektur micro-service secara sukses. (Richardson 2019) Micro-services adalah spesialisasi dari pendekatan implementasi untuk service-oriented architectures (SOA) yang digunakan untuk membangun system peranti lunak yang flexible, independently deployable. Pendekatan micro-services adalah realisasi pertama dari SOA yang diikuti introduksi DevOps dan menjadi lebih popular untuk membangun deployed systems yang berkelanjutan. (W. Authors n.d.) Istilah "arsitektur micro-service" telah bermunculan selama beberapa tahun untuk menggambarkan cara tertentu
59
Embed
Micro services€¦ · Web view2020. 12. 14. · adalah: 1) Redis [PubSub], 2) Apache Kafka, 3) RabbitMQ, 4) NSQ, 5) Google PubSub, 6) Amazon Web Service [AWS] SQS. Tipe-tipe micro
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
100
S. Micro Service(s)
Bahasa pola arsitektur micro-service adalah koleksi pola untuk
mengaplikasikan arsitektur micro-service. Ia mempunyai dua tujuan:
Pertama, Bahasa pola memungkinkan anda memutuskan bila mana micro-
services cocok baik untuk aplikasi anda; Kedua, Bahasa pola memungkinkan
anda menggunakan arsitektur micro-service secara sukses. (Richardson
2019)
Micro-services adalah spesialisasi dari pendekatan implementasi
untuk service-oriented architectures (SOA) yang digunakan untuk
membangun system peranti lunak yang flexible, independently deployable.
Pendekatan micro-services adalah realisasi pertama dari SOA yang diikuti
introduksi DevOps dan menjadi lebih popular untuk membangun deployed
systems yang berkelanjutan. (W. Authors n.d.)
Istilah "arsitektur micro-service" telah bermunculan selama beberapa
tahun untuk menggambarkan cara tertentu merancang aplikasi perangkat
lunak sebagai suite dari layanan yang dapat deployable secara
independen. Meskipun tidak ada definisi yang tepat dari gaya arsitektur ini,
ada karakteristik umum tertentu di sekitar organisasi di sekitar kemampuan
bisnis, otomatis penyebaran, kecerdasan di akhir, dan desentralisasi kontrol
bahasa dan data. (Lewis and Fowler 2014)
101
Sebelum masuk ke ranah micro-service dibahas arsitektur peranti
lunak masa lalu yang masih digunakan sampai saat ini yaitu arsitektur
monolitik, merupakan arsitektur di mana dalam pembuatan aplikasi, semua
komponen menjadi satu kesatuan (Single Deployment Unit), berarti
menyatukan front-end dan back-end dalam satu kesatuan aplikasi yang
sama. (Rizal Yogi Pramata 2018). Semua fitur dibuat dalam sebuah aplikasi
yang besar. Hal ini merupakan saran yang baik untuk pembuatan aplikasi.
Setelah monolith architecture jadi, bisa dilanjutkan dengan microservice
architecture.
Sebagai contoh yaitu aplikasi enterprise sbb.
Gambar 2.12. Enterprise app (application) yang terdiri atas client-side, server-side, dan database.
102
Server-side akan menangani HTTP request dari client-side, kemudian
menjalankan beberapa logika sesuai dengan domain. Dia mengambil dan
memperbarui database, dan mengirim data ke client-side. Hal ini disebut
monolitik. Contoh penyalahgunaan arsitektur ini yaitu menulis query
langsung di client-side.
Gambar 2.13. Arsitektur monolitik, misalnya menggunakan NginX.
Kelebihan aplikasi monolitik adalah: a) Mudah dibangun [di-
develop], cukup buat satu project untuk semua fitur; b) Mudah di-deploy
[ke {private} server atau cloud], c) Mudah di-uji [test], d) Mudah d-scale
[up /down].
Kekurangan aplikasi monolitik adalah:
103
1) Ketika aplikasi menjadi besar (banyak yang mengakses) performa akan
menurun running monolith app (application) sangat berat (kecuali memiliki
server yang lebih bagus);
2) Ketika pengguna akan mengubah teknologi pada aplikasi maka hal itu
akan megubah secara keseluruhan aplikasi scaling pada bagian tertentu
tidak bisa dilakukan harus diperiksa keseluruhan program;
3) Jika terjadi error pada salah satu fungsi maka hal itu mempengaruhi
keseluruhan aplikasi scaling development dengan banyak developer agak
menyulitkan.
4) Hal itu mengintimidasi developer yang baru bergabung dalam pembuatan
dan pengembangan.
5) Butuh kontrak (jangka) Panjang dengan (pemilik) teknologi yang
digunakan (bahasa pemrograman, basis data, dan lain-lain).
Misalnya sebuah online store mempunyai banyak fitur sbb: 1) Product
scalable (mudah di-scale sesuai kebutuhan), secure dan reliable; 2) Setiap
service berdiri sendiri, mudah dimengerti, karena relative kecil ukuran
service-nya; 3) Lebih mudah di-develop, maintenance-nya lebih mudah, di-
107
test, dan di-deploy; 4) Tidak ada hambatan dalam menggunakan (berganti)
teknologi baru; 5) Setiap tim (kecil) developer dapat mengembangkan setiap
services-nya tanpa mengganggu services yang lain.
Gambar 2.17. Contoh arsitektur micro services menggunakan NginX.
Kekurangan aplikasi micro services adalah: a) Ketika satu entity
pada database berubah maka setiap entity yang sama di setiap database
service harus diubah, hal ini dikarenakan distributed system; b) Untuk
beberapa kasus, sulit untuk menerapkan perubahan services, jadi perlu
perancangan yang matang, hal ini dikarenakan komunikasi antar-services
yang rawan error [latency, dll]; c) Deployment yang kompleks, perlu
konfigurasi untuk menjalankan setiap services karena memiliki run time yang
berbeda, integrasi antar-system, error integrasi; d) Perlu automation yang
108
tinggi dalam melakukan deployment, hal ini dikarenakan testing interaksi
antar-service lebih sulit perlu error handling mechanism, mock server.
Mengapa menggunakan pendekatan micro services untuk
membangun aplikasi? Untuk software developers, memfaktorkan
(membagi) suatu aplikasi ke dalam beberapa bagian komponen, tiada yang
baru. Secara tipikal, tiered approach digunakan, dengan back-end store,
middle-tier business logic, dan front-end user interface (UI). Apa yang telah
berubah, selama beberapa tahun terakhir adalah developers membangun
distributed applications untuk cloud. (Fabric 2019)
Gambar 2.18. Pembagian berdasarkan domain business.
Di sini beberapa hal yang mengubah keperluan bisnis: 1) layanan
yang dibangun dan beroperasi pada skala mencapai customer dalam region
geografi baru; 2) Pengiriman fitur dan kemampuan yang lebih cepat untuk
109
merespon permintaan pelanggan dengan cara yang lincah; 3) Peningkatan
pemanfaatan sumber daya untuk mengurangi biaya.
Ide sentral di belakang micro service adalah beberapa tipe aplikasi
menjadi lebih mudah dibangun dan dipelihara ketika mereka dipecah menjadi
lebih kecil (sekecil mungkin sehingga dimengerti oleh satu orang), potongan
yang dapat disusun yang mana bekerja bersama, single responsibility, bisa
dikerjakan oleh sejumlah X developer.
Tiap komponen dikembangan secara kontinyu dan dipelihara secara
terpisah. Aplikasi itu adalah secara sederhana penjumlahan komponen
konstituennya. Ini kontras dengan aplikasi monolitik tradisional yang mana
semua dibangun dalam satu potongan. (Hat 2019)
Gambar 2.19. Perbandingan Monolith dan MicroServices.
110
Membangun micro service sederhana – Termasuk dalam salah satu
arsitektur peranti lunak (software architecture), mengacu pada struktur
dasar dan disiplin dalam menciptakan struktur dan system tersebut. Setiap
struktur terdiri atas: (Take 2019)
1. Elemen peranti lunak;
2. Hubungan di antara mereka;
3. Property di antara keduanya, dan;
4. Hubungannya;
Arsitektur perangkat lunak berfungsi sebagai cetak biru dari
perangkat lunak yang dikembangkan dan menjabarkan tugas-tugas yang
perlu dikerjakan oleh tim (developer). Untuk saat ini ada banyak pola dan
gaya arsitektur peranti lunak yang diakui pola yang umum dan banyak
digunakan di kalangan software developer di antaranya adalah:
1. Layered (n-tier) architecture;
2. Event-driven architecture;
3. Monolithic architecture;
4. Microservices architecture;
5. Space-based architecture dan masih banyak lagi, penggunaan masing-
masing style ini menyesuaikan dengan kebutuhan pengembangan.
111
Memecah kompleksitas fitur menjadi layanan-layanan berukuran
kecil (micro-services) memungkinkan pengembang untuk membagi kode
menjadi bagian-bagian kecil. Pada monolith, setiap fitur berkaitan erat dan
saling mempengaruhi. Membuatnya menjadi lebih ber-resiko, proses update
yang lebih rumit, berpotensi memunculkan banyak bugs dan integrasi yang
lebih susah.
Dengan micro-service, fitur yang telah dipisah memungkinkan untuk
mengembangkan fitur secara individu, termasuk decentralized database-nya
yang terisolasi, dan tidak terkait dengan seluruh code-base, yang berarti lebih
efisien apabila horizontal-scaling().
Gambar 2.20. Basis data terdesentralisasi.
112
Mengapa harus ada basis data per-services? Untuk memastikan
bahwa antar service tiada ketergantungan. Tiap service bisa menggunakan
aplikasi basis data sesuai dengan kebutuhan. Service tidak perlu mengetahui
kompleksitas internal database dari service lain. Kalau suatu service mau
pakai data dari basis data service lain, dia API call ke service tujuan.
Shared Database adalah satu basis data yang dipakai beberapa micro
service Ketika dibahas migrasi dari monolith ke micro services.
Gambar 2.21. Shared database dipakai Ketika integrasi antar-aplikasi (integrasi paling sulit Ketika sharing file, perubahan sulit dideteksi).
113
Kapan harus digunakan shared database? Ketika melakukan transisi
dari aplikasi monolith ke micro services. Ketika memecah data antar-
service. Ketika dikejar (tenggat) waktu, sehingga tidak ada kesempatan untuk
membuat API (call).
Gambar 2.22. Jika tidak sempat kerjakan API Call, seperti dari Ecommerce ke Order Service, maka sementara langsung nembak dulu ke database dari Order Service.
NoSQL, bukan singkatan No (tidak /bukan) SQL, melainkan Not Only
SQL, tidak hanya relational database (tabel), SQL, yaitu: 1) Document
Oriented Database [json, mongoDB, embedded data objek di dalam objek,
micro service, 3) Aggregation micro service. Ciri-ciri tipe pertama: a]
Biasanya tidak memiliki basis data, bisa disimpan di config file untuk
menyimpan userid dan passwd, b] Digunakan untuk melakukan tugas
sederhana, c] Biasa digunakan sebagai app utility untuk micro service lain, d]
Tidak bergantung dengan micro service lain. Contoh micro service tipe
pertama adalah e-mail service dan SMS service, tak pakai satu provider, via
RPI call, message broker.
119
Persistence micro service, ciri-ciri kebalikan yang pertama: a]
Biasanya memiliki basis data, b] Bisa disebut sebagai master data micro
service, c] Biasa digunakan untuk mengolah data di basis data {CRUD}.
Contohnya …
Gambar 2.28. Contoh persistence micro service yang memiliki basis data.
Aggregation micro service, ciri-cirinya: a] Tergantung dengan micro
service lain, b] Biasa digunakan sebagai pusat business logic aplikasi
{service orchestrator}, c] Boleh memiliki basis data atau pun tidak, d] Tidak
bisa berdiri sendiri. Contohnya adalah: pemesanan barang, data product
(service) cart (keranjang belanja) service bikin [data] order
(service) payment service. Contoh kasus sbb.
120
Gambar 2.29. Contoh kasus integrasi ketiga jenis micro service. Penomoran menggambarkan process flow.
Service orchestration. Jika aggregation micro services
berkomunikasi dengan micro services lain menggunakan Remote Procedure
Invocation maka dinamakan Pattern Service Orchestration. Dalam pola ini,
aggregation micro services bertugas untuk mengatur system logic business
flow.
121
Gambar 2.30. Pattern Service Orchestration.
Menurut Lucas Jellema, workflow diperkuat micro services dengan
pendekatan berbasis cloud dan container (Jellema 2018). Suatu workflow
terdiri atas aktivitas bisnis dengan pola ter-orkestrasi dan dapat diulang,
yang dihidupkan oleh organisasi sumber daya yang sistematik menuju
proses-proses yang menransformasi material, menyediakan layanan, atau
memroses informasi.
Ia dapat digambarkan sebagai deretan operasi, kerja seseorang atau
kelompok, kerja organisasi staf, atau satu atau lebih mekanisme sederhana
atau kompleks.
Gambar 2.31. Penampakan posisi orkestrasi layanan mikro (orkestrasi fungsi tanpa server di lokasi). Terlihat posisi di antara keperluan IT hingga business,
122
di antara mili-seconds (always short running) hingga minutes, weeks (long running).
Melihat lokasi orkestrasi layanan mikro di gambar di atas, micro
services dirasakan layak untuk keperluan Technology & Innovation support
Center di Kantor HAKI (Sentra Kekayaan Intelektual). Konstituen workflow
6. State-data associated dengan instance dari workflow termasuk
progress & status dari instance [where are we at?];
7. Business indicators (per-instance dan across instances) dan pemantauan
bisnis.
Pendekatan yang bisa dijalankan oleh para stake holder kekayaan
intelektual Indonesia terkait workflow dalam Microservice Land terdiri atas
tiga macam yaitu orchestration , choreography, dan hybrid (coordinated |
facilitated choreography; mixing orchestration and choreography ). Bisa
dilakukan pemetaan posisi ketiganya dalam diagram sebagai berikut.
123
KANTOR DULU ASKII SEDANG STAKE MASASENTRA HOLDER DEPANHAKI
ASKIINETWORK
DJKINETWORK
RISET DIKAMPUS
Gambar 2.32. Posisi tiga pendekatan terkait workflow dalam Microservice Land, dihubungkan dengan Kantor HAKI, ASKII, dan kampus.
Keuntungan service orchestration: 1) Mudah dibuat karena business
logic code akan terpusat di aggregation micro services, 2) Mudah dimengerti
karena hal yang sama. DJKI Network, terkait dengan orchestration, dengan
keterangan sbb: 1) Koordinasi sentral flow logic, actor invocation
(synchronous?) and communication, transaksi, exception, time out and event
dan signal handling, workflow instance state dan data content; 2) Within
and /or across domain.
Kekurangan service orchestration: a] Aggregation micro services
<Ams> terlalu tergantung kepada micro services lainnya, b] Ams akan lebih
124
lambat karena harus terkoneksi dengan micro services lainnya, c] Ams akan
lebih mudah error jika di micro services lainnya terdapat masalah, d] Jika
perlu micro services baru, maka perlu dilakukan perubahan di Ams.
Tantangan dan hal tak dikehendaki dalam orkestrasi yaitu: 1)
Ketergantungan keras pada actors what, where, how to invoke, setiap
perubahan dalam actor berdampak pada central orchestrator; 2) Monolithic
orchestrator akan menjadi bottle neck physically [defying ops – scale,
patch, …], mentally [god service, omniscient, …]; 3) In the past, sangat tidak
gesit running instance, changing data structure & workflow definitions.
Beberapa produk yang menyediakan kemampuan ini, dan kadang-
kadang membuat hidup berat dan memberikan workflow orchestration suatu
nama buruk yaitu: Oracle BPM Suite, Camunda, jBPM, Activiti, Pega
Systems, Tallyfy, Bizagi, Oracle Integration Cloud (PCS), IBM Business
Process Manager, Red Hat Process Automation Manager.
ASKI Network (seandainya terbangun), bisa dianggap choreography,
tiada satu pihak pun sebagai pemilik workflow instance, bebas penuh di
antara semua actors. Micro services tidak mengetahui satu sama lain: events
memicu mereka menuju aksi, keadaan akhir mereka dipublikasi melalui suatu
event. Workflow tidak secara eksplisit eksis: Terbit sebagai deretan aksi
micro service yang independent; Micro service perlu mengetahui tentang
125
event yang seharusnya memicu mereka. Highly flexible: Sepanjang actors
beraksi pada events; Mereka dapat berada di mana saja, scaled in anyway,
mengerjakan apa pun, dan diimplementasi dalam setiap teknologi.
Tantangan Choreography
How to share the workflow state (“data context”)? Berat untuk
implementasi flow logic (contoh conditional actions atau loops). Berat untuk
menangani aktivitas parallel pada “instance” yang sama state is payload of
event. Mengubah workflow implisit memerlukan mengubah micro services
cara mereka menanggapi events. Menjejaki workflow adalah berat.
Mendeteksi dan fixing stuck and failing workflow instance adalah berat. Siapa
yang menentukan jika the order is completed?
Choreography Terbimbing
Definisi workflow eksis, workflow definition is instantiated as routing
slip that is included in events tersedia untuk setiap actor. Aktor-aktor
menentukan jika routing slip untuk suatu instance mengizinkan | prompts
them to act. If so, they perform work then update routing slip and publish an
event. Extremely flexible: 1) Deploy and redeploy actors as desire; 2) A/B and
Canary testing; 3) Modifikasi definisi workflow potentially event for running
instances.
126
Tantangan dengan Choreography Terbimbing – Routing Slip
Mencegah banyak actor mengambil tugas yang sama dalam suatu
instance (concurrency) exclusively claim a task. Menangani pembaruan
keadaan oleh actor pada tugas parallel (split brain state of routing slip).
Perhaps store state in distributed cache. Tidak efisien secara potensial
sebagai actor yang mengevaluasi semua workflow events untuk semua
workflow dan instances-nya. Mendeteksi failing instance, menangani timers
dan signals.
Best of Both Worlds: Hybrid-Coordinated Choreography
Asynchronous communication based on queues | commands | events.
Distributed, stateless, horizontally scalable workflow engine: 1] Data context
(“state”); 2] State transition (workflow logic); 3] Communication (event)
handling publikasi tugas, menerima pembaruan tugas, handle external and
time triggers; 4] Detect abandoned tasks, failing workflows; 5] Publikasi
metrics untuk pemantauan workflow instances; 6] Tata kelola pada (definisi)
workflows dan events memastikan bahwa events dipahami dan actor
tersedia untuk tiap tugas (event).
127
2.33. Choreography yang difasilitasi, misalnya oleh pimpinan kampus berupa fasilitas dari UPT (Unit Pelaksana Teknik) TIK (Teknologi Informasi & Komunikasi).
Orchestration dengan Proxy Actors untuk Decoupled Actors
Layanan µ, λ bisa digabung langsung atau dengan API Gateway. Kita
tinggal menyiapkan orchestration engine, bisa tergabung SOA, service-
oriented architecture (P) via ESB (Enterprise Service Bus).
128
Gambar 2.34. Orchestration dengan proxy actors untuk actors yang bisa dilepas, dipisahkan.
dalam domain atau konteks dibatasi untuk (bagian dari) aliran yang
menjadi tanggung jawab dalam sebuah domain dan tim. Dan menggunakan
(facilitated) choreography untuk flows stretching lintas domain untuk
mempertahankan decoupling kuat dan fleksibilitas antara domain. Mungkin
Layanan proxy dapat mengkonsumsi “choreographed” event dan
mengubahnya dalam orchestrated logic secara lokal.
Contoh:
129
Gambar 2.35. Cross bounded context | domain
Gambar 2.36. Contoh orcheography dari Camunda.
130
Gambar 2.37. Contoh orcheographed workflow diawali OrderPlaced Event. Di sisi bawah gambar, proses itu berlanjut dari gambar proses di sisi kanan menuju ke sisi kiri.
Workflow eksis juga dalam lingkungan micro services short running
composite transactions long running business process. Tanggung jawab
untuk menjalankan workflow instance dapat menjadi kepedulian cross cutting
– di luar ruang lingkup beberapa micro service individual.
Semua komponen workflow generic perlu menjadi agile, scalable,
distributed, cloud enabled untuk resilience, scale, flexible evolution,
penggunaan optimal sumber daya. Banyak hal dapat terjadi sepanjang life
time of workflow instance – yang harus dilayani untuk:
131
1) Events, berubah dalam data context, modifikasi scenario definisi
workflow; Workflow dengan single bounded context dapat menjadi
pure orchestration;
2) Workflow lintas bounded context seharusnya menggunakan
decoupled, choreographed workflow coordination [di antara bounded
context] dapat menjangkau lintas teknologi, lokasi fisik, vendor, dan
cloud.
Beberapa frameworks, services, dan tools adalah tersedia untuk
mendukung workflow management (contohnya AWS SWF, Zeebe, Camunda,
Baker, Cadence, Conductor, Project Fn Flow, Azure Logic apps). Lahir dari
keperluan hidup nyata. Microservice oriented dan [hybrid] cloud enable. Pada
jantung pre-configured combinations of queue, event bus, NoSQL data store,
rule engine. Roll your own can be fun – and also quite challenging.
Tantangan: Exactly once delivery of task to actor Lock? Queue?
Direct call? Deteksi failed | abandoned task execution (& reschedule)