105

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

106

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, berarti menyatukan front-end dan back-

end dalam satu kesatuan aplikasi yang sama. (Rizal Yogi Pramata 2018)

Sebagai contoh yaitu aplikasi enterprise sbb.

Gambar 2.13. Enterprise app yang terdiri atas client-side, server-side, dan database.

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.

107

Kekurangan aplikasi monolitik adalah: 1) Ketika aplikasi menjadi besar

(banyak yang mengakses) performa akan menurun (kecuali memiliki server

yang lebih bagus); 2) Ketika pengguna akan mengubah teknologi pada

aplikasi maka hal itu akan megubah secara keseluruhan aplikasi; 3) Jika

terjadi error pada salah satu fungsi maka hal itu mempengaruhi keseluruhan

aplikasi. Kelebihan aplikasi monolitik adalah: a) Mudah dibangun; b)

Mudah diuji; c) Mudah di-deploy ke server atau cloud.

Misalnya sebuah online store mempunyai banyak fitur sbb: 1) Product

catalog; 2) Shopping cart; 3) My order; 4) Product search; 5) Special promo.

Pada gaya monolithic, fitur-fitur ini dibangun dalam single app dan single

database.

Gambar 2.14. Pembangunan fitur dalam monolithic architecture.

108

Micro-services berarti membagi aplikasi menjadi (banyak) layanan

yang lebih kecil dan saling terhubung tidak seperti aplikasi monolitik. Setiap

micro-service merupakan aplikasi kecil yang memiliki arsitektur heksagonal

sendiri yang terdiri atas logika beserta berbagai adapter-nya (bahasa

pemrograman, dll). Pola arsitektur Micro-service secara signifikan

mempengaruhi hubungan antara application dan database. Alih-alih berbagi

skema database tunggal dengan services lainnya, masing-masing services

memiliki skema database tersendiri. Di satu sisi, pendekatan ini bertentangan

dengan gagasan model data enterprise-wide. Selain itu, sering kali

menghasilkan duplikasi beberapa data. Namun, memiliki skema database

per-service sangat penting jika ingin mendapatkan keuntungan dari layanan

micro-service. Masing-masing service memiliki database sendiri. Selain itu,

services dapat menggunakan jenis database dan bahasa pemrograman yang

paling sesuai dengan kebutuhannya.

Gambar 2.15. Contoh arsitektur micro services.

109

intinya micro-service yaitu membagi service ke bagian yang lebih kecil

di mana service — service tersebut saling berhubungan satu sama lain.

Selain itu, dalam setiap services yang dibuat bisa menggunakan teknologi

yang berbeda. 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-service setiap fitur dibangun terpisah dan independen dari

semua fitur lainnya. Untuk komunikasi antar service menggunakan HTTP rest

atau message bus. Terlihat jauh lebih kompleks dan lebih banyak usaha

dalam pengembangannya bukan? Lalu mengapa memilih micro-service?

Gambar 2.16. Micro-service architecture.

110

Kelebihan aplikasi micro-service adalah: 1) Aplikasi scalabale, secure

dan reliable; 2) Setiap service berdiri sendiri; 3) Maintence-nya lebih mudah;

4) Tidak ada hambatan dalam menggunakan teknologi baru; 5) Setiap tim

developer dapat mengembangkan setiap services-nya tanpa mengganggu

services yang lain.

Kekurangan aplikasi micro services adalah: a) Ketika satu entity pada

database berubah maka setiap entity yang sama di setiap database service

harus diubah; b) Untuk beberapa kasus, sulit untuk menerapkan perubahan

services, jadi perlu perancangan yang matang; c) Deployment yang

kompleks, perlu konfigurasi untuk menjalankan setiap services karena

memiliki run time yang berbeda, tidak seperti aplikasi monolitik tinggal upload,

deploy, dan beres; d) Perlu automation yang tinggi dalam melakukan

deployment.

Mengapa menggunakan pendekatan micro services untuk

membangun aplikasi? Untuk software developers, memfaktorkan suatu

aplikasi ke dalam 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)

111

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

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, potongan yang dapat disusun yang mana bekerja bersama. 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)

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;

112

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.

Memecah kompleksitas fitur menjadi layanan-layanan berukuran kecil

(micro-services) memungkinkan pengembang untuk membagi kode manjadi

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 dan tidak terkait dengan seluruh code-

base, yang berarti lebih efisien apabila horizontal-scaling().

113

T. Go-lang

Biasa disebut (bahasa) Go, adalah bahasa pemrograman yang

dikembangkan di Google oleh Robert Griesemer, Rob Pike, dan Ken

Thompson pada tahun 2007 dan mulai diperkenalkan ke publik tahun 2009.

Penciptaan bahasa Go-lang didasari bahasa C dan C++, oleh karena itu gaya

syntax-nya mirip.

Go-lang memiliki kelebihan dibanding bahasa lainnya, beberapa di

antaranya: 1) Mendukung konkurensi di level bahasa dengan pengaplikasian

cukup mudah; 2) Mendukung pemrosesan data dengan banyak prosesor

dalam waktu yang bersamaan (parallel processing); 3) Memiliki garbage

collector; 4) Proses kompilasi sangat cepat; 5) Bukan bahasa pemrograman

yang hirarkial, menjadikan developer tidak perlu ribet memikirkan segmen

OOP-nya; 6) Package /modul yang disediakan terbilang lengkap, karena

bahasa ini open source, banyak sekali developer yang juga mengembangkan

modul-modul lain yang bisa dimanfaatkan.

Micro-service telah di-support oleh hampir seluruh bahasa

pemrograman. Micro-service lebih menekankan pada konsep dari pada

framework atau tools yang spesifik. Dikatakan bahwa beberapa bahasa

memiliki dukungan micro-service yang lebih baik dari bahasa lainnya. Salah

satu bahasa yang memiliki dukungan yang bagus adalah Go-lang.

114

Gambar 2.17. Mengapa kita menggunakan Go-lang?

Go-micro adalah sebuah frame-work yang mendukung pengembangan

micro-service. Go-micro telah mengabstraksi detil-detil kebutuhan untuk

membangun system terdistribusi. Berikut adalah beberapa fitur utamanya: 1.

Service discovery; 2. Load balancing; 3. Message encoding; 4. Request

/Response; 5. Async messaging; 6. Plugable interface.

Mengapa kita menggunakan framework? Ada beberapa alasan

mengapa developer menggunakan frame-work yaitu: 1. Menghemat waktu

pembangunan, dengan memanfaatkan library yang telah disediakan

developer cukup berfokus ke proses bisnis yang dikerjakan; 2. Reuse of

code, dengan menggunakan frame-work maka project kita mempunyai

struktur yang baku sehingga kita dapat menggunakannya kembali pada

proyek-proyek selanjutnya.

115

PENGENALAN PROTO-BUF – Frame work bukan tools untuk

memecahkan masalah, tetapi hanya sebagai alat bantu. Frame work hanya

menjadi sebuah konstruksi dasar yang menopang sebuah konsep atau

system yang bersifat “essential support” (penting tetapi bukan komponen

utama).

Karena layanan micro-service dibagi menjadi baris-baris kode yang

terpisah, salah satu hal yang perlu diperhatikan adalah komunikasi antar

service. Dalam pola monolith, komunikasi bukan masalah karena code

dipanggil langsung dari tempat kode berasal. Micro-service tidak memiliki

kemampuan tersebut karena masing-masing service berada di tempat

terpisah. Kita dapat saja menggunakan REST seperti JSON atau XML

melalui http. Namun masalah dengan pendekatan ini adalah service A harus

menyediakan datanya ke JSON /XML, mengirim string ke service B yang

kemudian harus men-decode pesan ini dari JSON. Ini dapat berpotensi

sebagai masalah di kemudian hari.

Protokol buffer, biasanya disebut Proto-buf, adalah protokol yang

dikembangkan oleh Google untuk memungkinkan serialisasi dan de-

serialisasi data terstruktur. Google mengembangkannya dengan tujuan

untuk menyediakan cara yang lebih baik, dibandingkan dengan XML, untuk

membuat sistem berkomunikasi. Jadi mereka fokus untuk membuatnya lebih

sederhana, lebih kecil, lebih cepat, dan lebih mudah dikelola dari pada XML.

116

“Proto-buf performs up to 6 times faster than JSON”, perhatikan contoh

berikut ini:

Bagai mana kita mendefinisikan proto(buf) yang diperlukan? Bahasa

yang digunakan dalam proto cukup mudah untuk dipahami. Pernyataannya:

Syntax = “proto3”;

117

Artinya versi proto yang digunakan adalah “proto3”. Digunakan package

“tutorial” untuk set nama file yang nantinya akan di-generate. Selanjutnya

ditambahkan “message” untuk setiap struktur data yang ingin kita serialize,

kemudian tentukan nama dan tipe data masing-masing field dalam message.

Dapat ditambahkan struktur data lain ke dalam message dengan

menggunakan tipe data dari message lain sebagai tipe field sbb:

message PhoneNumber {string number = 1; PhoneType type = 2;}

Jadi protocol buffers adalah metode serialisasi data terstruktur. Ia

berguna dalam mengembangkan program berkomunikasi dengan bagian lain

melalui kabel atau untuk menyimpan data. Protocol buffers adalah Google's

language-neutral, platform-neutral, extensible mechanism for serializing

structured data – think XML, but smaller, faster, and simpler. Anda definisikan

bagaimana anda ingin data distrukturkan sekali, kemudian anda dapat

gunakan special generated source code untuk menulis dengan mudah dan

membaca struktur data itu ke dan dari variety of data streams dan

menggunakan bahasa bervariasi. (Developer n.d.) Metode itu melibatkan

bahasa deskripsi antar-muka yang mendeskripsikan struktur beberapa data

dan program yang membangkitkan kode sumber dari deskripsi itu untuk

membangkitkan atau parsing a stream of bytes yang merepresentasi data

terstruktur. (Developer 2016)

118

U. POOLING TASKS

WIPO membangun infra-struktur KI (Kekayaan Intelektual) untuk

mengkoneksikan sistem dan berbagi pengetahuan. Teknologi digital telah

mengkreasi kemungkinan tak terbatas untuk berbagi kerja, data, dan

pengetahuan tanpa kendala lokasi geografis. Meningkat, Kantor KI dalam

negara berbeda melakukan pooling tasks untuk menghindari duplikasi

usaha-usaha mereka dan menolong mempercepat pemrosesan paten. Di

Indonesia Kantor KI bisa disebut sentra kekayaan intelektual sudah

mempunyai ASKII (Asosiasi Sentra Kekayaan Intelektual Indonesia) yang

berdiri sejak 30 Oktober 2017.

Banyak negara juga setuju berbagi basis data mereka tentang

dokumen paten, membuka akses ke informasi teknologi (dapat) bernilai untuk

para inovator sedunia. Untuk membuat kerja ini, kantor KI perlu standar

teknis umum sehingga sistem teknologi informasi dalam negara berbeda

dapat “berbicara” satu dengan lainnya dan pertukaran data. Di sini celah

masuk penelitian disertasi ini.

Peralatan yang baik juga diperlukan untuk secara bebas tersedia

sehingga orang dapat mengakses, bernavigasi, dan menggunakan data itu.

Standar teknis dan toolbox seperti apa yang bisa meningkatkan

keterpercayaan kantor KI untuk mengimplementasikan TISC?

119

Menurut Bing Translator, “pooling tasks” diterjemahkan sebagai

“penggabungan tugas”, sedangkan “pooled task” diterjemahkan sebagai

“tugas dikumpulkan”. Jadi, tugas dikumpulkan adalah tugas di alur kerja Anda

yang memiliki swimlane yang terdiri atas salah satu grup atau beberapa

orang. Hal ini adalah pemaknaan yang paling mendekati apa yang

dimaksudkan. (Teasdale 2019) Swimlane process diagram (SPD) adalah

sebuah diagram flow proses yang menggambarkan interaksi dari beberapa

bagian yang berbeda yang terlibat dalam sebuah lini proses bisnis. Diagram

ini menggunakan format jalur hubungan (swimlane). Penggambarannya

dilakukan dengan cara menampilkan stakeholder pada baris diagram serta

kerangka waktu pada kolom diagram; dan kemudian aktivitasnya ditampilkan

menggunakan simbol flowchart. SPD adalah diagram yang menggambarkan

aktivitas dari setiap stakeholder yang terlibat di dalam kegiatan bisnis

perusahaan; diagram ini merepresentasikan flow proses yang

menggambarkan interaksi dari beberapa bagian yang berbeda dan

bagaimana perkembangan proses melalui beberapa phase yang berbeda.

SPD yaitu bagan yang menggambarkan setiap stakeholder yang ada di Line

of Business (LOB) perusahaan tersebut, yang digambarkan dengan symbol

dari flowchart. SPD merupakan activity diagram dari para stakeholder

yang memperlihatkan stakeholder yang terlibat di dalam proses LOB, dan

waktu pada interaksinya. (Meilia, Mutaqin, and Pujadi 2014)

120

Setiap tugas dalam alur kerja Anda memiliki swimlane yang terkait

dengannya. Swimlane menentukan siapa yang akan ditugaskan tugas

ketika tugas dialihkan ke- (Dalam kasus Sentra HAKI, penugasan

manajemennya terutama diberikan oleh Ketua LP2M). Jika swimlane terdiri

atas satu pengguna (misalnya seorang inventor terhadap system di Sentra

HAKI), maka tugas akan secara otomatis ditetapkan. Ini adalah kasus yang

biasa. Saat alur kerja ditetapkan, itu muncul di tampilan "Tugas yang

Ditugaskan" dari kotak masuk tugas Anda. Namun, akan ada saat-saat

ketika Anda (misalnya manajemen Sentra HAKI) akan ingin merutekan alur

kerja ke grup pengguna (misalnya inventor, desainer, pencipta, dll).

Misalnya, Anda (manajemen Sentra HAKI) mungkin memiliki tim

desainer yang menangani konten web untuk situs web Anda. Anda mungkin

tidak tahu sebelumnya di mana salah satu dari mereka akan melakukan

pekerjaan yang diperlukan. Dengan menetapkan "Designer" swimlane ke

"Tim Designer", semua orang di Tim Designer dapat menerima

pemberitahuan dari tugas pada saat yang sama. Dan siapa pun yang

tersedia dapat mengklaim tugas untuk bekerja di atasnya. Mekanisme ini

secara kolektif disebut sebagai "pooled task". Sebuah pool (kolam) karena

dikirim ke kolam pengguna. Dan hanya salah satu dari mereka yang

kemudian dapat melompat dan mengklaim swimlane (mirip system lelang via

internet → yang dilelang yaitu: tugas).

121

Pada setiap tingkat, ketika seseorang dari kolam "mengklaim tugas",

mereka menjadi petugas. Tugas ditugaskan kepadanya. Pada saat itu,

tugas ditampilkan dalam tampilan "tugas yang ditetapkan" oleh pengguna

yang ditetapkan dari kotak masuk tugas mereka. Anggota lain dari tim akan

tetap melihat tugas tetapi mereka akan melihat bahwa itu sedang dikerjakan

dan mereka juga akan melihat siapa yang mengerjakannya.

Tugas gabungan adalah unik karena mempertahankan gagasan

"delegasi". Delegasi adalah orang lain di dalam kelompok yang kepadanya

tugas itu dapat ditugaskan. Ketika tugas gabungan muncul pertama kali,

semua anggota kumpulan (tim atau grup) adalah delegasi. Setiap delegasi

dapat mengerjakan tugas itu.

Ketika seseorang akhirnya "mengklaim" tugas itu, dia menjadi yang

ditugaskan. Delegasi sekarang terdiri atas semua anggota tim atau kelompok

yang tersisa. Pada titik mana pun, penerima hak dapat "membatalkan klaim"

tugas di mana tugas tersebut akan dialihkan kembali agar tersedia bagi

delegasi mana pun untuk dijemput dan dikerjakan. Atau, penerima hak dapat

"mendelegasikan" tugas tersebut kepada salah satu dari delegasi yang

tersisa. Mendelegasikan tugas menugaskan kembali tugas kepada orang lain

dari tim atau grup. Dengan cara ini, tim dapat berkoordinasi ketika sumber

daya mengizinkan untuk memastikan tugas tersebut selesai.

122

Riwayat alur kerja menangkap semua peristiwa klaim, pembatalan

klaim, dan pendelegasian ini sehingga Anda dapat melacak siapa yang

mengerjakan sesuatu. Tugas gabungan (atau node peserta dalam model alur

kerja dengan grup di swimlane) memberikan cara bagi sekelompok pengguna

untuk berkolaborasi ketika ketersediaan tidak sepenuhnya diketahui

sebelumnya. Dalam menjelaskan alur kerja, mari kita lihat beberapa hal

berikut: Workflow Models, Workflow Instances, Workflow Tasks, Workflow

Payload Resources, Workflow Comments, Workflow History Item,

Workflow Events, Workflow Event Handlers (monitor?). (C. C. Authors n.d.)

Item riwayat alur kerja adalah objek yang dikelola secara otomatis

yang dibuat di latar belakang setiap kali seseorang berinteraksi dengan alur

kerja. Ini memasok catatan setiap perubahan pada tugas alur kerja dan

contoh alur kerja, memungkinkan Anda melihat riwayat yang sempurna ketika

orang memodifikasi properti (data), sumber daya muatan yang diperbarui

(konten), menambahkan komentar, aksi yang ditembakkan, atau dipindahkan

di antara tugas-tugas alur kerja. Sebuah swimlane digunakan untuk

mendefinisikan seorang aktor yang berpartisipasi dalam alur kerja. Secara

umum, Anda akan perlu memiliki satu swimlane per-peserta dalam alur kerja.

Sebuah swimlane mendapatkan nama warna-warni dari jalur dalam kolam

renang di mana hanya satu orang yang diperbolehkan untuk berenang di jalur

pada satu waktu.

123

V. Workflows Diperkuat Micro Services

Menurut Lucas Jellema, alur kerja 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.

Objektif yang diinginkan antara lain: 1) flows lengkap, tepat waktu,

mengikuti rencana, menangani situasi yang tidak menyenangkan; 2) eksekusi

efisien, mengenai penggunaan sumber daya [komputasi dan manusia]; 3)

Kelincahan, dapat beradaptasi secara mudah.

Contohnya: CQRS-style refresh dari query-stores setelah

pembaharuan command-database. CQRS adalah command and query

responsibility segregation. Sumber yang bisa diacu pada URL

https://github.com/Chinchilla-Software-Com/CQRS, Sebuah perusahaan

ringan fungsi sebagai layanan (FaaS) kerangka untuk menulis fungsi

berbasis tanpa server dan aplikasi micro-services dalam multi-Datacentre

hibrida, di tempat dan lingkungan Azure.

124

Gambar 2.18. Penampakan posisi orkestrasi layanan mikro (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 layanan mikro di Gambar 2.18, 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.

125

Workflow design | blue print, komunikasi dengan bisnis, masukan

untuk: 1) Implementasi workflow; 2) Implementasi pemantauan dan laporan

bisnis; 3) Workflow engine – to execute.

Contoh metode notasi formal:

1) BPMN [business process model and notation];

2) BPEL [business process execution language];

3) CMMN [case management model and notation];

4) Harel state charts;

5) State diagrams;

6) Petri net.

Pada intinya, definisi logika workflow, dikombinasi dengan kondisi

sekarang instance dan waktu sekarang (atau kondisi eksternal lain),

memproduksi satu atau lebih TO DO ITEMS untuk tipe-tipe aktivitas dalam

konteks workflow instance, termasuk non-happy exception items (untuk

contoh ketika to do item terdahulu sudah time out). To do items

seharusnya dibuat tersedia ke actors (untuk contoh micro services),

termasuk (reference to the) state. Actors dapat mengambil to do item,

ekslusif secara tipikal. Mereka dapat membaca dan memperluas keadaan

workflow instance (termasuk completing | failing | returning the task).

126

Tasks berjalan melalui keadaan: Tasks == workflow step == activity.

Setiap perubahan state memerlukan re-evaluasi workflow instance.

Gambarannya seperti berikut.

Gambar 2.19. Siklus hidup suatu tugas alur kerja.

Workflow instance berjalan melalui keadaan-keadaan berikut:

business state dan operational state; dengan tahapan-tahapan berikut: new,

running, waiting on actors /events, failed, completed. Gambarannya seperti

berikut.

127

Business state

Operational state

Workflow instante

Gambar 2.20. Keterkaitan workflow instance dengan business state dan operational state.

128

Hal-hal penting terkait micro services yaitu: 1) Business agility

[kelincahan], dengan fungsionalitas → quick, cheap, effortless, dan risk free;

2) IT Agility, dengan non-fungsionalitas → scale, resilience, infrastructure,

and location; 3) Independent components → asynchronous communication –

whenever possible, encapsulated, location does not matter; 4) Strictly with

one domain, owned by one team → tidak terlalu besar atau kompleks; 5)

Horizontally scalable → multiple instances; 6) Ephemeral, stateless; 7)

Menghidupkan Automated DevOps.

Berikut ini dalam diagram Workflow in Microservices Land, diuraikan

syarat-syarat untuk membuat workflow bekerja dalam arena micro services

yang terdiri atas empat bagian (warna).

Gambar 2.21. Workflow dalam Microservices Land.

129

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.

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

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.

KANTOR DULU ASKII SEDANG STAKE MASA

SENTRA HOLDER DEPAN

HAKI

ASKII

NETWORK

DJKI

NETWORK

RISET DI

KAMPUS

130

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

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.

131

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.

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

132

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

Decider-state engine

Take workflow definition, take state & state change [events], take

context (time). Memperoleh keadaan baru (dari): status of workflow instance,

status of activities. Pemutakhiran keadaan yang bertahan, menginformasikan

task dispatcher (pemberangkat tugas).

Berikut ini dua diagram terkait workflow definition management dan

task dispatcher & actors.

133

Gambar 2.23. Diagram terkait workflow definition management dan task dispatcher.

Manajemen definisi workflow, memegang definisi banyak workflow,

termasuk struktur data yang terasosiasi dan event messages; Mengatur

banyak versi tiap definisi workflow, periode validitas untuk tiap versi;

Menolong meng-upgrade instances sedang berjalan. Dengan manajemen ini

kegiatan suatu Sentra KI bisa dipantau bersama.

Secara mandiri Kantor HAKI itu bisa membangun task queue

/dispatcher, melibatkan para actors yaitu mitra kerja-nya, bisa dari para

komunitas inventor, desainer, creator, dan para calon ketiganya. Bisa melalui

mekanisme lelang online untuk mengizinkan actors mengambil (dan meng-

klaim) suatu tugas. Mekanisme deteksi menjamin penanganan tugas.

134

2.24. Choreography yang difasilitasi, misalnya oleh pimpinan kampus berupa fasilitas dari UPT (Unit Pelaksana Teknik) TIK (Teknologi Informasi & Komunikasi).

Tambahan dalam Workflow Execution Toolset

Partisipasi manusia: allocate, notify, provide multi-channel Task UI,

task management. Indikator bisnis: menemukan WIP (Work in Process

/Progress), Waste, Bottlenecks. Pemantauan: individual instance &

aggregates per-workflow; Technical /IT perspective & Business Activity. Rule

engine → untuk logika bisnis di dalam workflow.

Melibatkan Actors Manusia dalam Workflow

Di sini pentingnya manajemen Kantor KI mengatur keterlibatan itu.

135

Gambar 2.25. Melibatkan actors manusia dalam workflow.

Siapa yang seharusnya mengerjakan tugas? Tergantung kriteria yang

sudah ditentukan. Bagai mana menginformasikan pemegang tugas tentang

new | expiring to do item? Tergantung perangkat komunikasi yang bisa

diakses. Memungkinkan manusia mengerjakan tugas (data, status)?

Seandainya kecerdasan buatan belum mampu mengerjakan tugas dimaksud.

Memungkinkan manusia mengatur semua tugas? Dalam hal ini adalah

manajemen Kantor KI yang melakukan selama otomasi belum terinstalasi

dengan sempurna.

Micro-services adalah Aktor yang Berlaku sebagai Workflow Engines

136

Dia seharusnya mengetahui workflow, memutuskan jika & bagaimana

melibatkan manusia?

Gambar 2.26. Micro services melibatkan manusia.

Micro-service adalah actor sebagai proxy untuk kotributor manusia.

Gambar 2.27. Microservice sebagai proxy contributor manusia.

137

Gambar 2.28. Keterlibatan manusia, dalam hal ini manajemen Kantor KI dalam system mengandung microservices.

Manajemen KI /HAKI tidak harus memiliki server sendiri untuk

menjalankan microservices yang dibangunnya. Mereka bisa menggunakan

Grizzly-API, Microsoft Azure, atau rangkaian Github, CognitiveClass.AI, dan

IBM Cloud. Bisa juga dicari provider lainnya baik di Indonesia mau pun di

luar negeri.

Orchestration dengan Proxy Actors untuk Decoupled Actors

Layanan µ, λ bisa digabung langsung atau dengan API Gateway. Kita

tinggal menyiapkan orchestration engine, bisa tergabung SOA(P) via ESB.

138

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

139

Gambar 2.30. Cross bounded context | domain

Gambar 2.31. Contoh orcheography dari Camunda.

140

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

141

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.

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