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