micro services€¦ · web view2020. 12. 14. · adalah: 1) redis [pubsub], 2) apache kafka, 3)...
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
catalog [service]; 2) Shopping cart [plus accounting service]; 3) My order; 4)
Product search; 5) Special promo [plus customer service]. Pada gaya
monolithic, fitur-fitur ini dibangun dalam single app dan single database.
Micro-services berarti membagi aplikasi (tunggal, besar) menjadi
(banyak) layanan-layanan yang lebih kecil dan saling terhubung tidak seperti
104
aplikasi monolitik. Setiap micro-service merupakan aplikasi kecil yang
memiliki arsitektur heksagonal sendiri yang terdiri atas logika beserta
berbagai adapter-nya (bahasa pemrograman, dll).
Gambar 2.14. Pembangunan fitur dalam monolithic architecture.
Pola arsitektur Micro-service secara signifikan mempengaruhi
hubungan antara application dan database. Alih-alih berbagi skema database
tunggal dengan services lainnya, masing-masing (micro) services memiliki
skema database tersendiri. Di satu sisi, pendekatan ini bertentangan
dengan gagasan model data enterprise-wide.
Selain itu, hal itu sering kali menghasilkan duplikasi beberapa data.
Namun, memiliki skema database per-service sangat penting jika ingin
105
mendapatkan keuntungan dari layanan micro-service. Masing-masing (micro)
service memiliki database sendiri. Selain itu, tiap (micro) services dapat
menggunakan jenis database dan bahasa pemrograman yang paling sesuai
dengan kebutuhannya.
Gambar 2.15. Contoh arsitektur micro services.
Intinya micro-service yaitu membagi service (besar) ke bagian
(aplikasi) yang lebih kecil di mana service — service tersebut saling
berhubungan (bekerja sama) satu sama lain. Selain itu, dalam setiap (micro)
services yang dibuat bisa menggunakan teknologi yang berbeda.
Independen, dapat di-deploy dan diubah tanpa tergantung dengan aplikasi
lain. Setiap komponen pada system dibuat dalam service.
Sedangkan untuk implementasi ke web, android, iOS, dll tidak
bisa secara langsung. Kita harus membuat terlebih dahulu yang namanya
106
API Gateway. API ini memiliki tugas seperti load balancing, caching, access
controll , API metering, dan monitoring.
Pada micro-service setiap fitur dibangun terpisah dan independen dari
semua fitur lainnya, focus mengerjakan satu pekerjaan dengan baik. Untuk
komunikasi antar-service digunakan HTTP rest atau message bus.
Komunikasi antar-service biasanya melalui network call. Terlihat jauh lebih
kompleks dan lebih banyak usaha dalam pengembangannya.
Gambar 2.16. Micro-service architecture.
Kelebihan aplikasi (arsitektur) micro-service adalah: 1) Aplikasi
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,
product service, atribut bervariasi], 2) [primary] Key-Value Database {Redis,
basis-nya di memory}, 3) Column Families Database [Apache Cassandra], 4)
114
Graph Database [Neo4J, social network], 5) Search Database [ElasticSearch,
kencang, catalog service, tuning ], 6) Time Series Database [InfluxDB,
berbasis waktu].
Eksistensi NoSQL, agar: bisa (pemrograman) disesuaikan dengan
kebutuhan; bisa mencari alternatif cara mengolah data; mempercepat dalam
proses penulisan (aktivitas user) atau pencarian (data).
Gambar 2.23. Pemanfaatan NoSQL dan kebutuhan yang dilayani.
Remote Procedure Invocation (RPI). Misalnya Order Service
membutuhkan Data Product dari Product Service. Di sini pentingnya
komunikasi antar service misalnya RPI atau RPC (Remote Procedure Call),
membuat API. Tidak direkomendasi komunikasi via basis data. Contoh RPI
yaitu: 1) RESTful API [http], 2) gRPC, 3) Apache Thrift, 4) SOAP [Simple
115
Object Access Protocol], 5) Java RMI [Remote Method Invocation], 6) Corba
[Common Object Request Broker Architecture].
Bagian a
Bagian b
116
Gambar 2.24. Ketika service membutuhkan data service lain.
Keuntungan menggunakan RPI yaitu: 1) Sederhana dan mudah, 2)
Biasanya digunakan untuk komunikasi Request-Replay, 3) Untuk proses
Sync [butuh menunggu jawaban]. Itulah cara komunikasi antar services yang
pertama.
Cara kedua adalah messaging. Berikut contoh kasus terkait sbb.
Gambar 2.25. Kasus terkait messaging.
Ketika selesai pembuatan pesanan, kirim e-mail /SMS ke customer,
kirim data penjualan ke Finance Service dan Report Service. Misalnya
digunakan RPI, diperoleh gambaran sbb.
117
Gambar 2.26. Komunikasi antar service menggunakan Remote Procedure Invocation.
Ada masalah di komunikasi RPI yaitu: 1) Proses lama [nembak
kepada Email Service dan SMS Service], 2) Mengirim data berkali-kali [pada
Finance Service dan Report Service], 3) Membuat parallel process sangat
rumit [ada yang tidak support].
Oleh karena itu digunakan komunikasi dengan cara messaging,
biasanya digunakan untuk async, artinya komunikasi dilakukan tanpa harus
menunggu selesai diproses. Dalam async, kadang tidak perlu peduli balasan
dari service yang dituju. Biasanya komunikasi messaging membutuhkan
Message Channel sebagai jembatan untuk mengirim dan menerima data.
Direkomendasi menggunakan aplikasi Message Broker untuk channel itu.
118
Gambar 2.27. Pentingnya message broker pada message channel.
Format message channel Email, SMS, Order seperti log (book)
dengan FIFO (First In First Out). Contoh message broker adalah: 1) Redis
[PubSub], 2) Apache Kafka, 3) RabbitMQ, 4) NSQ, 5) Google PubSub, 6)
Amazon Web Service [AWS] SQS.
Tipe-tipe micro services: 1) Stateless micro service, 2) Persistence
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
terdiri atas:
1. Activities [dan peran actor];
2. Flow logic sequence, conditional, events [termasuk waktu], loop,
parallelism, deadlines;
3. Events dan signals yang terpicu atau terpengaruh;
4. Transaction boundaries sukses atau rollback bersama;
5. Exceptions, non-happy-flow, compensation handlers;
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.
Hybrid
Merangkul (atau setidaknya memungkinkan) orkestrasi sinkron
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)
Heartbeat? Time-out? Compensation (for failed transaction). Timer events.
Handle signals /Events to impact running instance correlation (tags
/indexes) to locate impacted instances; communicate with /interrupt actors.
Deal with peak load and high priority instances and tasks. Distributed, scaled,
& ephemeral actors and workflow engine. How to design workflow in a way
that users understand, IT-staff can create and workflow engines can process.
132
Service Choreography: 1) Pattern ini berbeda dengan Service
Orchestration, 2) Dalam choreography, komunikasi aggregation service
dengan micro service lain menggunakan messaging, 3) Dalam orchestration,
aggregation micro service adalah service yang sangat komplek dan mengerti
semua business logic (work) flow, 4) Dalam choreography, semua micro
service dituntut untuk menjadi pintar, tidak hanya diperintah oleh aggregation
micro services.
Gambar 2.38. Service choreography.
Keuntungan service choreography: 1) Aggregation micro services
<Ams> tidak tergantung dengan micro service lain, 2) Ams akan lebih cepat,
karena tidak perlu berkomunikasi dengan micro service lain, 3) Jika ada
133
micro service baru, Ams tidak perlu melakukan perubahan lagi. Kekurangan
service choreography: a] Lebih sulit di-debug ketika terjadi masalah, b]
Business logic {work} flow akan terdistribusi di semua micro services
sehingga sulit untuk dimengerti secara keseluruhan, c] Ketergantungan pada
message broker.
API Gateway. Bagai mana cara meng-ekspos micro services yang
aman? User mengakses micro services melalui internet. Masalah meng-
ekspos tersebut: 1) Semua service bisa diakses dari luar, 2) Jika butuh
autentikasi, harus diimplementasi di semua service, 3) Rawan terjadi
kebocoran data.
Gambar 2.39. Bagai mana cara meng-ekspos yang aman? Dengan API Gateway.
134
API Gateway adalah aplikasi yang bertugas sebagai gerbang dari luar
(akses dari internet) ke dalam (aplikasi micro services), sebagai proxy server
ke semua aplikasi micro services. Jadi aplikasi micro services hanya bisa
diakses dari luar melalui API Gateway.
Gambar 2.40. API Gateway.
Keuntungan API Gateway: 1) Lebih aman karena satu gerbang, 2)
Service tidak perlu implementasi autentikasi, cukup dilakukan di API
Gateway, 3) API Gateway sebagai load balancer, rate limiter, pengaman
sehingga error dari service tidak terekspos. Contoh API Gateway: a] Nginx, b]
Apache HTTP, c] Kong, d] Netflix Zuul, e] Spring Cloud Gateway.
135
Authentication & Authorization. Perhatikan table sebagai berikut.
Tabel 2.20. Otentikasi dan otorisasi.
Perihal Authentication Authorization
Pengertian Proses yang dilakukan setelah authentication.
Memvalidasi kredensial (hp, otp) untuk verifikasi pemilik identitas.
Memvalidasi apakah pemilik identitas memiliki hak akses untuk resource yang diminta.
Contoh Proses login menggunakan username dan password.
Access Control List.
Gambar 2.41. Integrasi auth service, di API Gateway ada casing misal 5 menit untuk mengurangi trafik ke auth service.
136
Di tiap micro services ada perlakuan middleware sebagai berikut.
Gambar 2.42. Request ditambah auth data (JWT).
Teknologi pendukung: 1) Secure cookie, 2) Oauth, 3) JSON web token
[JWT], 4) Basic Auth, 5) API /Secret key.
Backend for Frontend. Permasalahan banyak jenis frontend adalah:
1) Tiap frontend punya mekanisme authentikasi berbeda, 2) Kecepatan
bandwidth tiap frontend berbeda, 3) API yang dibutuhkan tiap frontend
berbeda, 4) Kebutuhan semua jenis frontend harus diimplementasi di satu
API Gateway.
137
Backend for Frontend: a] Menyediakan backend khusus untuk frontend
tertentu, b] Biasanya satu backend akan melayani satu frontend secara
spesifik, c] Makin banyak jenis frontend, makin banyak backend yang dibuat.
Gambar 2.43. Perlu disiapkan backend khusus untuk setiap frontend yang mengakses.
Keuntungan backend for frontend: 1) Pengembangan backend untuk
tiap frontend bisa terisolasi, 2) Logic untuk frontend tidak tercampur di satu
backend.
GraphQL, alternatif backend for frontend. GraphQL adalah query
language untuk API. GraphQL dapat digunakan untuk memanipulasi
138
response API secara runtime. Frontend bebas menentukan data apa saja
yang didapatkan. Backend hanya perlu menyediakan data lengkap.
Gambar 2.44. GraphQL alternatif backend for frontend.
Kekurangan menggunakan GraphQL: 1) Butuh development GrapQL
Server di backend, 2) Butuh development GraphQL Client di frontend.
CQRS (Command Query Responsibility Segregation) adalah proses
membedakan operasi Command dan operasi Query. Operasi Command
adalah operasi mengubah data (Create, Update, Delete). Operasi Query
adalah operasi mengambil data (Get, [Read], Search). Dalam CQRS,
139
biasanya service atau database dibedakan untuk kebutuhan Command dan
Query.
Gambar 2.45. Persistence micro services.
140
Gambar 2.46. Penyiapan mySQL sebagai primary database, peningkatan proses query.
Keuntungan CQRS: 1) Bisa memilih basis data berbeda yang optimal
untuk proses Command dan Query sehingga operasinya bisa lebih cepat
karena database sudah disesuaikan dengan kebutuhan, 2) Membedakan
model untuk Command dan Query di aplikasi akan lebih mudah dibanding
digabung di satu model yang sama untuk proses Command dan Query, 3)
Performa aplikasi akan lebih baik karena dibedakan komponen untuk
Command dan Query.
Gambar 2.47. Pemecahan menjadi product search service karena pencarian produk bisa terjadi tiap detik lebih banyak dari update produk baru.
141
Keuntungan CQRS menggunakan messaging: 1) Aplikasi Command
dan Query terpisah sehingga bisa dikerjakan oleh tim yang berbeda secara
parallel, 2) Aplikasi Command tidak perlu memikirkan struktur data aplikasi
Query hanya cukup mengirimkan datanya ke message broker, 3) Scaling
kedua aplikasi bisa sesuai dengan kebutuhan, 4) Jika aplikasi Query sedang
stop atau error, data dari aplikasi Command akan tetap aman tersimpan di
message broker, 5) Mekanisme retry akan lebih mudah dilakukan jika melalui
message broker.
142
REFERENSI
Authors, Cloud CMS. “Workflow.” : 3.
https://www.cloudcms.com/documentation/workflow.html.
Authors, Wikipedia. “Microservices.” : 14.
https://en.wikipedia.org/wiki/Microservices.
Developer, Google. 2016. “Protocol Buffers.” Wikipedia: 5.
https://en.wikipedia.org/wiki/Protocol_Buffers.
———. “What Are Protocol Buffers ? Pick Your Favorite Language How Do I
Start ?” : 1. https://developers.google.com/protocol-buffers/.
Fabric, Azure Service. 2019. “Why Use a Microservices Approach to Building
Applications ?” Azure Service Fabric (Microsoft Azure): 13.
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-
overview-microservices.
Hat, Red. 2019. “What Are Microservices?” Weekly Newsletter: 7.
https://opensource.com/resources/what-are-microservices.
Jellema, Lucas. 2018. “A Cloud- and Container- Based Approach to Micro
Services- Powered Workflows.” : 55.
https://www.slideshare.net/lucasjellema/a-cloud-and-containerbased-
approach-to-microservicespowered-workflows-codeone-2018-san-
143
francisco.
Lewis, James, and Martin Fowler. 2014. “Microservices.” : 17.
https://www.martinfowler.com/articles/microservices.html.
Meilia, Fenny, Jatniko Nur Mutaqin, and Tri Pujadi. 2014. “Diagram
Swimlane.” : 1–5. https://sis.binus.ac.id/2014/04/30/diagram-swimlane/.
Richardson, Chris. 2019. “What Are Microservices? | AWS.” Aws: 12.
https://aws.amazon.com/microservices/.
Rizal Yogi Pramata. 2018. “Apa Itu Monolitik Arsitektur?” : 5.
https://medium.com/codelabs-unikom/microservices-apaan-tuh-
b9f5d56e8848.
Take, Silvester Yacoubus. 2019. “Membangun Microservice Sederhana.” : 7.
https://refactory.id/post/111-part-1-membangun-microservice-sederhana-
menggunakan-go-go-micro.
Teasdale, Malcolm. 2019. “What Is a Pooled Task ?” : 3.
https://support.cloudcms.com/hc/en-us/articles/115004923713-What-is-
a-pooled-task-.