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-.