78

J. Micro Service(s)

Microservices adalah gaya arsitektur di mana proses pengembangan

perangkat lunak dilakukan dengan menggunakan komponen otonom yang

mengisolasi fine-grained business functionalities dan berkomunikasi satu

dengan yang lain melalui antarmuka standar [Hassan et al. 2017].

Karena penggunaan yang luas dalam aplikasi berbasis web dan cloud,

dapat diamati migrasi beberapa perusahaan dari arsitektur monolit ke

microservices sejak yang terakhir membawa banyak manfaat seperti

pengaturan yang dapat dikelola sendiri (tata kelola desentralisasi) dan

komponen ringan [Aderaldo et al. 2017].

Tujuan dari pemakaian microservices adalah untuk menggunakan unit

otonom yang terisolasi satu dari lainnya dan mengkoordinasikan mereka ke

dalam infrastruktur terdistribusi oleh teknologi container ringan, seperti

Docker. Biasanya, adopsi model arsitektur ini menyiratkan juga keperluan

mengadopsi praktik lincah, seperti DevOps, yang mengurangi waktu antara

menerapkan perubahan sistem dan mentransfer perubahan ini ke lingkungan

produksi [Aderaldo et al. 2017].

Isolasi fungsi bisnis sangat dianjurkan ketika menggunakan

microservices, dan memungkinkan pengembangan dan penyebaran

independen setiap microservices. Selain itu, isolasi juga mengoptimalkan

79

otonomi dan penggantian layanan. Gaya arsitektur microservices membawa

banyak manfaat bagi pengembang tetapi juga hadir dengan banyak

tantangan.

Keuntungan. Dalam sistem yang terdiri atas beberapa microservices,

pengembang memiliki kemungkinan menggunakan banyak teknologi yang

berbeda [Newman 2015]. Keragaman teknologi (technology diversity) ini

adalah karakteristik yang sangat umum dalam aplikasi menggunakan micro

services dan memungkinkan penggunaan alat yang tepat untuk pekerjaan

yang tepat.

Selain itu, heterogenitas teknologi memungkinkan penambahan

teknologi baru selama pengembangan atau pemeliharaan dalam cara yang

lebih efisien. Misalnya, ini cocok untuk aplikasi web di mana kita dapat

mengamati perubahan konstan dan cepat dalam lingkungan dan kerangka

kerja pengembangan [Ramos et al. 2016].

Manfaat lain yang sering dikaitkan dengan microservices adalah

kemungkinan menyebarkan layanan secara mandiri dari yang lain.

Penyebaran independen (independent deployment) ini dapat menyebabkan

implementasi fitur baru yang lebih cepat [Newman 2015].

Skalabilitas (Scalability) juga disebutkan sebagai keuntungan dari

microservices karena dapat dicapai sesuai permintaan, skala hanya layanan

80

yang berisi fungsionalitas tertentu. Dimungkinkan juga untuk mereplikasi

layanan tertentu, bukan seluruh sistem. Akhirnya, keterpeliharaan

(maintainability) sering dilaporkan sebagai manfaat sejak pengembang dapat

memodifikasi atau mengganti layanan tanpa memengaruhi seluruh aplikasi.

Tantangan. Sering dilaporkan bahwa microservices menuntut

pengelolaan data terdistribusi dan kemudian transaksi terdistribusi

(distributed transactions), yang membuat implementasinya banyak lebih

kompleks. Studi lain [Pahl dan Jamshidi 2016, Aderaldo et al. 2017]

melaporkan bahwa pengujian otomatis sangat penting dalam microservices,

terutama uji integrasi (integration tests), yang bisa lebih kompleks dan

memakan waktu. Selain itu, ketika tes gagal, itu dapat lebih sulit untuk

menentukan fungsionalitas mana yang telah rusak [Newman 2015]. Service

faults juga disebut sebagai tantangan ketika menggunakan microservices

sejak identifikasi kesalahan dalam pengaturan terdistribusi jauh lebih sulit

daripada dalam satu monolitik.

Akhirnya, pengembang sering menyebutkan bahwa Remote

Procedure Calls (RPC) mahal dan mengambil banyak lebih lama dari

panggilan lokal, yang berarti bahwa RPC dapat menjadi tantangan ketika

mengembangkan aplikasi di bawah microservices. Untuk karakter

pengembang, diperlukan: 1) Pengalamanan pengembangan, 2) Pengalaman

81

microservices, 3) Peran pengembang ybs [back-end developer, DevOps

Specialist, Software architect, User-experience designer].

Bahasa pola arsitektur micro-services adalah koleksi pola untuk

mengaplikasikan arsitektur micro-services. Ia mempunyai 2 tujuan: Pertama,

Bahasa pola memungkinkan anda memutuskan bila mana micro-services

cocok baik untuk aplikasi anda; Kedua, Bahasa pola memungkinkan anda

menggunakan arsitektur micro-services secara sukses. (Richardson 2019)

Micro-services adalah spesialisasi dari pendekatan implementasi

untuk services-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-services" 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)

82

Sebelum masuk ke ranah micro-services 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 microservices

architecture.

Sebagai contoh yaitu aplikasi enterprise sbb.

Gambar 2.10. Enterprise app (application) yang terdiri atas: client-side, server-side, dan database.

83

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

84

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 system, demikian pula dengan operator system tersebut;

5) Butuh kontrak (jangka) panjang dengan (pemilik) teknologi yang digunakan

(bahasa pemrograman, basis data, dan lain-lain), juga kontrak dengan

expertis tenaga kerja yang mengoperasikan teknologi tersebut.

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.

85

Micro-services berarti membagi aplikasi (tunggal, besar) menjadi

(banyak) layanan-layanan yang lebih kecil dan saling terhubung tidak seperti

aplikasi monolitik. Setiap micro-services merupakan aplikasi kecil yang

memiliki arsitektur heksagonal sendiri yang terdiri atas logika beserta

berbagai adapter-nya (bahasa pemrograman, dll).

Gambar 2.12. Pembangunan fitur dalam monolithic architecture.

Pola arsitektur micro-services 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.

86

Selain itu, hal itu sering kali menghasilkan duplikasi beberapa data.

Namun, memiliki skema database per-service sangat penting jika ingin

mendapatkan keuntungan dari layanan micro-services. Masing-masing

(micro) services memiliki database sendiri. Selain itu, tiap (micro) services

dapat menggunakan jenis database dan bahasa pemrograman yang paling

sesuai dengan kebutuhannya.

Gambar 2.13. Contoh arsitektur micro services.

Intinya micro-services 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.

87

Sedangkan untuk implementasi ke web, android, iOS, dll tidak

bisa secara langsung. Kita harus membuat terlebih dahulu yang namanya

API Gateway. API ini memiliki tugas seperti load balancing, caching, access

controll , API metering, dan monitoring.

Pada micro-services 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.14. Micro-service architecture.

Kelebihan aplikasi (arsitektur) micro-service adalah: 1) Aplikasi

scalable (mudah di-scale sesuai kebutuhan), secure dan reliable; 2) Setiap

88

service berdiri sendiri, mudah dimengerti, karena relative kecil ukuran

service-nya; 3) Lebih mudah di-develop, maintenance-nya lebih mudah, di-

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

89

berbeda, integrasi antar-system, error integrasi; d) Perlu automation yang

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: 1) back-end store,

2) middle-tier business logic, dan 3) front-end user interface (UI). Apa

yang telah berubah, selama beberapa tahun terakhir adalah developers

membangun distributed applications untuk cloud. (Fabric 2019)

Gambar 2.16. Pembagian berdasarkan domain business.

Di sini beberapa hal yang mengubah keperluan bisnis: 1) layanan

yang dibangun dan beroperasi pada skala mencapai customer dalam region

90

geografi baru; 2) Pengiriman fitur dan kemampuan yang lebih cepat untuk

merespon permintaan pelanggan dengan cara yang lincah; 3) Peningkatan

pemanfaatan sumber daya untuk mengurangi biaya.

Ide sentral di belakang micro services 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.17. Perbandingan Monolith dan MicroServices.

91

Membangun micro services 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.

92

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-services, 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.18. Basis data terdesentralisasi.

93

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 mengeksekusi API call ke service

tujuan.

Shared Database adalah satu basis data yang dipakai beberapa micro

service Ketika dibahas migrasi dari monolith ke micro services.

94

Gambar 2.19. Shared database dipakai ketika integrasi antar-aplikasi (integrasi paling sulit ketika sharing file, perubahan sulit dideteksi).

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.20. 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 object di dalam

object, product service, atribut bervariasi], 2) [primary] Key-Value Database

95

{Redis, basis-nya di memory}, 3) Column Families Database [Apache

Cassandra], 4) 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.21. Pemanfaatan NoSQL dan kebutuhan yang dilayani.

Remote Procedure Invocation (RPI). Misalnya Order Service

membutuhkan Data Product dari Product Service. Di sini pentingnya (cara

pertama yaitu) komunikasi antar service misalnya: RPI atau RPC (Remote

Procedure Call), membuat API (call). Tidak direkomendasi komunikasi via

96

basis data. Contoh RPI yaitu: 1) RESTful API [http], 2) gRPC, 3) Apache

Thrift, 4) SOAP [Simple Object Access Protocol], 5) Java RMI [Remote

Method Invocation], 6) Corba [Common Object Request Broker Architecture].

Bagian a

97

Bagian b

Gambar 2.22. 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.23. Kasus terkait messaging.

98

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.

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

99

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.

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

100

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, tidak pakai satu provider,

via RPI call, message broker.

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

Gambar 2.26. Contoh persistence micro service yang memiliki basis data.

Aggregation micro service, ciri-cirinya: 4] Tergantung dengan micro

service lain, 2] Biasa digunakan sebagai pusat business logic aplikasi

101

{service orchestrator}, 1] Boleh memiliki basis data atau pun tidak, 3] Tidak

bisa berdiri sendiri. Contohnya adalah: pemesanan barang, data product

(service) cart (keranjang belanja) service bikin [data] order

(service) payment service. Contoh kasus sbb.

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

102

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

103

Gambar 2.29. Penampakan posisi orkestrasi micro services (orkestrasi fungsi tanpa server di lokasi). Terlihat posisi di antara keperluan IT hingga business, di antara mili-seconds (always short running) hingga minutes, weeks (long running).

Melihat lokasi orkestrasi micro services di gambar, 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;

104

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.

KANTOR DULU ASKII SEDANG STAKE MASASENTRA HOLDER DEPANHAKI

ASKIINETWORK

DJKINETWORK

RISET DIKAMPUS

Gambar 2.30. Posisi tiga pendekatan terkait workflow dalam Microservice Land, dihubungkan dengan Kantor HAKI, ASKII, dan kampus.

105

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

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

106

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

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.

107

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.

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.

108

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

109

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

110

Gambar 2.32. 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:

111

Gambar 2.33. Cross bounded context | domain

Gambar 2.34. Contoh orcheography dari Camunda.

112

Gambar 2.35. 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:

113

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.

114

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

115

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.37. Bagai mana cara meng-ekspos yang aman? Dengan API Gateway.

116

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.38. API Gateway.

Keuntungan API Gateway: 1) Lebih aman karena satu gerbang, 2)

Service tidak perlu implementasi autentikasi, cukup dilakukan di API

Gateway, 3) 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.

117

Authentication & Authorization. Perhatikan table sebagai berikut.

Tabel 2.4. 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.39. Integrasi auth service, di API Gateway ada casing misal 5 menit untuk mengurangi trafik ke auth service.

118

Di tiap micro services ada perlakuan middleware sebagai berikut.

Gambar 2.40. Request ditambah auth data (JWT).

Teknologi pendukung: 1) Secure cookie, 2) Oauth, 3) JSON web token

[JWT], 4) Basic Auth, 5) API /Secret key.

Back-end for Front-end. Permasalahan banyak jenis front-end

adalah: 1) Tiap front-end punya mekanisme authentikasi berbeda, 2)

Kecepatan bandwidth tiap front-end berbeda, 3) API yang dibutuhkan tiap

front-end berbeda, 4) Kebutuhan semua jenis front-end harus diimplementasi

di satu API Gateway.

Back-end for Front-end: a] Menyediakan back-end khusus untuk front-

end tertentu, b] Biasanya satu back-end akan melayani satu front-end secara

119

spesifik, c] Makin banyak jenis front-end, makin banyak back-end yang

dibuat.

Gambar 2.41. Perlu disiapkan back-end khusus untuk setiap front-end yang mengakses.

Keuntungan back-end for front-end: 1) Pengembangan back-end untuk

tiap front-end bisa terisolasi, 2) Logic untuk front-end tidak tercampur di satu

back-end.

GraphQL adalah alternatif back-end for front-end. GraphQL adalah

query language untuk API. GraphQL dapat digunakan untuk memanipulasi

120

response API secara runtime. Front-end bebas menentukan data apa saja

yang didapatkan. Back-end hanya perlu menyediakan data lengkap.

Gambar 2.42. GraphQL alternatif backend for frontend.

Kekurangan menggunakan GraphQL: 1) Butuh development GrapQL

Server di back-end, 2) Butuh development GraphQL Client di front-end.

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,

121

biasanya service atau database dibedakan untuk kebutuhan Command dan

Query.

Gambar 2.43. Persistence micro services.

122

Gambar 2.44. 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.45. Pemecahan menjadi product search service karena pencarian produk bisa terjadi tiap detik lebih banyak dari update produk baru.

123

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.

124

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-

125

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