Micro services
2
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)
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.
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.
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.
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. Lalu mengapa
dimilih micro-service?
Gambar 2.16. Micro-service architecture.
Kelebihan aplikasi micro-service adalah: 1) Aplikasi scalable,
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)
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;
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().
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 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.
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, project kita mempunyai
struktur yang baku sehingga kita dapat menggunakannya kembali pada
proyek-proyek selanjutnya.
PENGENALAN PROTO-BUF – Framework bukan tools untuk memecahkan
masalah, tetapi hanya sebagai alat bantu. Framework 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.
“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”;
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)
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,
(jumlah) 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?
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)
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 me-rute-kan 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).
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.
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.
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.
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.
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]; BPEL [business
process execution language]; CMMN [case management model and
notation];
2) Harel state charts [The diagram type allows the modeling of
superstates, orthogonal regions, and activities as part of a
state];
3) State diagrams [a type of diagram used in computer science
and related fields to describe the behavior of systems];
4) Petri net [model untuk merepresentasikan sistem terdistribusi
diskret].
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 items, ekslusif secara tipikal. Mereka
dapat membaca dan memperluas keadaan workflow instance (termasuk
completing | failing | returning the task).
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.
Business state
Operational state
Workflow instante
Gambar 2.20. Keterkaitan workflow instance dengan business state
dan operational state.
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.
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.
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.
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).
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.
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.
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.
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
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.
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,
service-oriented architecture (P) via ESB (Enterprise Service
Bus).
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:
Gambar 2.30. Cross bounded context | domain
Gambar 2.31. Contoh orcheography dari Camunda.
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:
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.
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-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-.
KANTORDULUASKIISEDANGSTAKEMASA
SENTRAHOLDERDEPAN
HAKI
ASKII
NETWORK
DJKI
NETWORK
RISET DI
KAMPUS