418

N. Service Provision

Terdiri atas dua hal yaitu: 1) Basic services, 2) Additional services.

Layanan-layanan dasar minimal adalah:

1) Akses ke online patent database systems dan sumber daya ilmu

pengetahuan dan teknologi;

2) Akses ke industrial property related publications;

3) Asistensi dalam pencarian dan pengambilan teknologi informasi.

Tergantung pada keperluan yang diuji dan ketersediaan kapasitas,

TISC juga menyediakan layanan-layanan tambahan sbb:

1) Pelatihan dalam basis data pencarian;

2) On-demand searches (novelty, state of the art, and infringement);

3) Pemantauan teknologi dan pesaing;

4) Informasi dasar pada industrial property law;

5) Informasi dasar pada industrial property management dan strategi;

6) Informasi dasar pada komersialisasi dan pemasaran teknologi.

Selanjutnya dilakukan pemodelan terhadap semua proses bisnis

tersebut di atas, diawali class MicroService yang memodelkan suatu micro

service serta meliputi nama dan indikasi bila mana micro service adalah

stateful atau tidak.

419

Class MicroserviceInstance adalah spesialisasi dari class

MicroService dan merepresentasi instansi micro service. Contohnya μApp

mencakup berbagai jenis layanan mikro, dan tiap tipe layanan mikro dapat

mempunyai multi replikasi (yaitu micro service instance). Suatu instansi Micro

Service mempunyai jumlah total pesan dan data yang dipertukarkan oleh

replica layanan mikro.

Class Message memodelkan komunikasi di antara μApps, dan

merepresentasi ujung /tepi dalam μApp graph. Setiap pesan mempunyai ID

unik, response time, time stamp, dan ukuran. Himpunan pesan mendeskripsi

aliran kerja μApp.

Class Affinity memodelkan komunikasi di antara dua layanan mikro

berbeda (bukan replikasi mereka) mempertimbangkan jumlah pesan dan

420

jumlah data dipertukarkan. Afinity mempunyai derajat yang merepresentasi

kekuatan relasi di antara dua layanan mikro. Class Cluster mengabstraksi

management tool yang digunakan dan memelihara hosts yang tersedia

dalam cluster. Tiap class host mempunyai himpunan instansi micro service.

Hosts dan instansi layanan mikro mempunyai atribut Resources yang

memelihara informasi sejarah penggunaan, misalnya CPU dan memory

bermakna penggunaan hosts dan micro services, dan keterbatasan sumber

daya. Bagai mana μApp direpresentasi pada runtime oleh model, dan ia

menandai μApp architecture (pandangan aplikasi) dan μApp deployment

(pandangan cluster).

Cluster view memodelkan bagai mana μApp di-deploy melintasi

beberapa hosts dan penggunaan sumber daya oleh hosts dan micro

services. Pandangan ini menunjukkan communication topology dan pesan

yang dipertukarkan oleh micro services. Pandangan cluster adalah volatile

seperti micro services ber-replikasi sering datang dan pergi pada runtime.

Application view memodelkan arsitektur μApp yang berjalan dalam cluster

dan menggaris-bawahi layanan mikro yang membuat aplikasi. Pandangan ini

juga menunjukkan affinity link di antara layanan mikro; Pandangan ini lebih

stabil dari pada cluster view sejak micro service upgrades kurang sering dari

pada micro services scaling.

421

Pemisahan masalah aplikasi dan cluster menciptakan model yang

lebih ekspresif. Ini memungkinkan analisis dan tindakan adaptasi yang akan

dilakukan secara individu di μApp atau cluster tanpa perlu memeriksa

keseluruhan model. Misalnya, Manajer Adaptasi dapat menggunakan file

konfigurasi baru untuk menghitung rencana adaptasi (tampilan cluster),

sedangkan Pelaksana menggunakan informasi cluster untuk menjamin

bahwa hanya perubahan aman yang akan diterapkan di μApp (tampilan

aplikasi).

Monitoring - Komponen Pemantauan dirancang untuk mengumpulkan

data heterogen dari cluster dan menyatukannya dalam API agnostik teknologi

untuk mengisi Model. Data kluster dikumpulkan secara terpisah untuk

menghindari membanjiri Manajer Adaptasi dan akibatnya memicu terlalu

banyak adaptasi.

Komponen Pemantauan menyediakan cara standar untuk mengambil

data yang tidak bergantung pada teknologi pemantauan yang digunakan

dalam cluster. Komponen ini pasif (hanya mengembalikan data sebagai

tanggapan atas permintaan) dan menggabungkan semua data yang

diperlukan untuk menghitung rencana adaptasi. Dalam praktiknya, Manajer

Model menggunakan informasi yang dipantau untuk memperbarui model

runtime.

422

Setiap μApp memiliki stack pemantauan untuk mengumpulkan data.

Biasanya, tumpukan pemantauan mengumpulkan tiga jenis data yang

berbeda: 1) penggunaan sumber daya, 2) log eksekusi, dan 3) pesan yang

dipertukarkan.

Monitor mempertahankan pandangan global lingkungan dengan

mengumpulkan: 1) informasi dari alat manajemen yang digunakan (misalnya,

Kubernetes atau Docker Swarm), 2) penggunaan sumber daya host dan

layanan mikro, dan 3) peristiwa yang dihasilkan oleh operasi DevOps, seperti

pembaruan pada repositori kode dan penyebaran layanan mikro. Data

numerik, biasanya terkait dengan penggunaan sumber daya, dikumpulkan

sebagai rata-rata nilai seketika yang diukur dari komponen μApps. Misalnya,

rata-rata ini dapat mewakili sejarah penggunaan CPU layanan mikro dalam

interval waktu tertentu.

Alat pemantauan mengumpulkan data dan menyimpannya di

penyimpanan data yang berbeda secara terus menerus. Monitor abstrak data

ini menyimpan dengan menggunakan klien yang bertanggung jawab untuk

mengambil dan mengubah data ini menjadi struktur agnostik yang digunakan

untuk mengisi model. Akhirnya, pemantauan menyediakan data sesuai

dengan berbagai aspek seperti metrik sumber daya, pesan, log, dan

peristiwa. Untuk masing-masing, komponen pemantauan memungkinkan

pengambilan sampel data selama periode tertentu.

423

Alat pemantauan mengumpulkan data dan menyimpannya di

penyimpanan data yang berbeda secara terus menerus. Monitor

mengabstraksi penyimpanan data ini dengan menggunakan klien yang

bertanggung jawab untuk mengambil dan mengubah data ini menjadi struktur

agnostik yang digunakan untuk mengisi model. Terakhir, pemantauan

menyediakan data sesuai dengan berbagai aspek seperti metrik sumber

daya, pesan, log, dan peristiwa. Untuk masing-masing ini, komponen

pemantauan memungkinkan pengambilan sampel data selama periode

tertentu.

Analyzer – Komponen Analyzer dirancang untuk memproses model

saat runtime dengan mencari afinitas antara layanan mikro. Didefinisikan

afinitas antara dua layanan mikro menggunakan jumlah pesan dan jumlah

data yang dipertukarkan di antara mereka. Digunakan rasio (pembobotan)

dalam perhitungan afinitas untuk mengarahkan eksekusi Analyzer. Data yang

dipertukarkan oleh layanan mikro tidak sama-sama didistribusikan di antara

semua pesan yang dipertukarkan. Ini mungkin ada alur kerja μApp dengan

beberapa pesan dan sejumlah besar data dan sebaliknya. Oleh karena itu,

nilai rasio tinggi (rasio 0,5) mengarahkan Analyzer untuk menghargai jumlah

pesan atas jumlah data. Nilai kecil (rasio < 0,5) melakukan sebaliknya, dan

rasio 0,5 menyeimbangkan dua atribut secara merata.

424

Komponen Analyzer mendeteksi perilaku tak terduga yang tidak

dirasakan oleh insinyur aplikasi. Analyzer yang berbeda dapat

diimplementasikan dan dicolokkan ke mekanisme adaptasi, tergantung pada

analisis yang diperlukan. Dirancang analyzer affinity yang mendeteksi afinitas

antara layanan mikro. Afinitas digunakan untuk mengoptimalkan penempatan

μApp.

Analyzer memeriksa pesan yang dipertukarkan oleh μApp (disimpan

dalam model) dan menghitung afinitas antara dua layanan mikro.

Perhitungan ini menggunakan jumlah dan ukuran pesan untuk menentukan

afinitas dua arah. Didefinisikan afinitas antara dua jenis layanan mikro a dan

b sebagai Aa, b dan menghitungnya sebagai berikut:

A(a ,b)=m(a ,b)m

.w+d (a , b)d

.(1−w)

Di mana,

m adalah total pesan dipertukarkan oleh semua micro services,

m(a,b) adalah jumlah pesan dipertukarkan di antara micro service a dan b,

d adalah total jumlah data dipertukarkan oleh semua micro services,

d(a,b) adalah jumlah data dipertukarkan di antara micro service a dan b,

w adalah bobot, di mana {w ∈ R | 0 ≤ w ≤ 1}, digunakan untuk mendefinisikan variable mana yang paling penting untuk menghitung affinity, misalnya jumlah pesan atau jumlah yang dipertukarkan.

425

Analyzer menghitung afinitas antara semua instans microservice dan

mengirimkannya ke perencana melalui manajer model. Selain itu, analyzer

menggabungkan afinitas instans microservices, dengan mempertimbangkan

jenisnya dan mengisi model dengan afinitas yang dihitung.

Terakhir, selain komunikasi sinkron melalui REST API, arsitektur

layanan mikro biasanya menggunakan komunikasi asinkron melalui protokol

426

PubSub. REMaP dapat menghitung pengoptimalan untuk μApps

menggunakan komunikasi asinkron karena, seperti penyimpanan data,

middleware perpesanan (mis., RabbitMQ) dibungkus ke dalam wadah. Dalam

kasus ini, penganalisis dapat mengidentifikasi layanan mikro mana yang

memiliki kecepatan komunikasi tinggi dan dapat menempatkannya bersama

dengan middleware. Namun, jika μApp mengalihdayakan middleware

perpesanan, REMaP tidak dapat menghitung afinitas layanan mikro dengan

benar, dan akibatnya, pengoptimalan penempatan tidak dapat diterapkan.

Planner - Komponen Planner memutuskan cara menerapkan adaptasi

ke μApp. Demikian pula dengan analyzer, perencana yang berbeda dapat

diimplementasikan dan dicolokkan ke mekanisme adaptasi, tergantung pada

strategi adaptasi. Diusulkan dua Perencana untuk menghitung penempatan

layanan mikro selama adaptasi: 1) Affinity Planner [HBA] berbasis Heuristik

dan 2) Optimal Affinity Planner [OA].

Kedua perencana itu menghitung penempatan baru untuk μApps

dengan mengurangi masalah ini menjadi masalah bin-packing multi-objektif.

Karena masalah ini NP-hard, kita tahu bahwa untuk μApps besar pendekatan

optimal tidak layak. Oleh karena itu, diterapkan: 1) versi heuristik [HBA] untuk

mencapai perkiraan solusi untuk μApps besar dan 2) versi optimal [OA]

untuk mencapai solusi optimal untuk μApps kecil.

427

Kedua perencana mengakses model untuk mendapatkan informasi

tentang riwayat penggunaan sumber daya dan afinitas antara layanan mikro

untuk menghitung rencana adaptasi. Perlu dicatat bahwa perencana tidak

menggunakan nilai metrik seketika. Sebaliknya, mereka menggunakan data

historis yang dikelola dalam model. Pendekatan ini memberikan batas yang

lebih andal (maks dan min) pada kebutuhan sumber daya setiap layanan

mikro.

Akhirnya, kedua perencana dapat menangani layanan mikro yang

stateful dan penyimpanan data, karena penyimpanan data juga dibungkus

menjadi layanan mikro. Namun, REMaP tidak dapat menangani sinkronisasi

data di host yang berbeda setelah memigrasikan layanan mikro yang stateful.

Oleh karena itu, migrasi layanan mikro yang stateful dapat memimpin μApp

ke dalam keadaan yang tidak konsisten.

Executor – Component Executor dirancang untuk menerapkan

rencana adaptasi yang dihitung oleh Planner di μApps dengan aman. Karena

μApps terus berubah, adaptasi yang dihitung tetapi belum diterapkan bisa

tidak aman untuk diterapkan karena faktor eksternal. Karena Model

terhubung secara sebab-akibat, jika aplikasi ditingkatkan dan memiliki bagian

dari arsitekturnya berubah, model mencerminkan konfigurasi barunya. Oleh

karena itu, Pelaksana memvalidasi perubahan pada Model sebelum

menerapkan perubahan ke μApp. Jika perubahan tidak lagi berlaku, maka

428

akan dibuang. Komponen Executor pada dasarnya menerjemahkan perintah

tingkat tinggi yang didefinisikan oleh perencana sebagai primitif tingkat

rendah dari alat manajemen. Oleh karena itu, seorang eksekutor diperlukan

untuk setiap alat manajemen.

Pelaksana pertama memeriksa apakah mungkin untuk memindahkan

microservice dari satu host ke host lain dalam model atau tidak. Dalam

beberapa situasi, pelaksana tidak dapat melakukan gerakan ini. Sebagai

contoh, menganggap bahwa microservices A dan B memiliki dua contoh, A.1

dan A.2, dan B.1 dan B.2, masing-masing. Selain itu, A.1 dan A.2 memiliki

afinitas tinggi dengan B.1 dan B.2 juga. Analyzer memeriksa dalam model

bahwa microservice tipe A memiliki afinitas tinggi dengan B. Juga, misalkan

bahwa perencana telah menghitung bahwa A.2 harus berlokasi bersama

dengan B.2, tetapi pada saat runtime, A.2 telah dialokasikan karena tindakan

scale-in yang tidak terduga. Oleh karena itu, gerakan untuk bersama-sama

menemukan A.2 dengan B.2 menjadi tidak valid.

Dengan hanya menggunakan gerakan yang valid menjamin bahwa

hanya perubahan yang aman terjadi di μApp. Jika gerakan valid, pelaksana

melampirkan microservice ke host tujuan dan unsets microservice ini dari

host sumber. Akhirnya, pelaksana berurusan dengan contoh layanan mikro

yang muncul selama proses adaptasi. Setelah model memiliki layanan mikro

yang dihubungkan oleh afinitas, pelaksana dapat menggunakan informasi ini

429

untuk mendorong di mana replika baru akan ditempatkan. Misalnya, diberikan

dua layanan mikro A dan B dengan afinitas tinggi. Awalnya, mungkin hanya

ada replika A.1 dan B.1. Namun, selama adaptasi untuk co-locate A.1 dan

B.1, skala b microservice keluar, dan replika B.2 yang dihasilkan. Pelaksana

akan memeriksa model dan menemukan afinitas antara A dan B. Pertama

Executor akan mencoba untuk co-locate B.2 dengan A.1, tetapi memeriksa

ulang model, dan host di mana A.1 ditempatkan tidak sesuai dengan replika

lain dari B. Jadi, eksekutor akan mencoba untuk co-locate B.2 dengan

microservice lain sehingga keduanya memiliki afinitas. Jika microservice

tersebut tidak ada, pelaksana mempertahankan replika B.2 di host di mana

itu instantiated.

Rencananya, skema dari Gambar tentang Model Referensi MAPE-K

akan dicoba realisasi TISC sebagai Managed System, yaitu micro-service

based platform, mulai dari Monitoring, Analysis, Planning, Executing, dan

Knowledge Based. Tentu dengan menganalisis peran fitur-fitur aplikasi yang

bisa diakses.

O. Model manager

Model Manager adalah komponen inti dari REMaP. Ini

mengimplementasikan hubungan sebab akibat antara model dan instance

430

dari microservices yang menyusun μApp. Pada dasarnya, manajer model

memicu adaptasi dengan mengoordinasikan elemen MAPE-K, dan dengan

mempertahankan model saat runtime. Jadi, manajer model pun akan dicoba

diimplementasikan menggunakan sarana yang mungkin.

Model Manager memiliki dua elemen kunci: Model Handler dan

Adaptation Engine (engine). Model handler mengisi model menggunakan

data yang dikumpulkan oleh monitor. Pada runtime, model diwakili sebagai

grafik, dan model handler melakukan perubahan pada grafik ini, misalnya,

dimasukkannya afinitas, dan microservices bergerak.

Mesin adaptasi mengoordinasikan tindakan komponen MAPE-K dan

menyediakan antarmuka untuk menambahkan penganalisis dan perencana

baru. Selain itu, mesin ini memicu adaptasi. Adaptasi yang dilakukan adalah

optimalisasi penempatan yang diterapkan pada layanan mikro. Adaptasi

dipicu dalam interval waktu yang ditetapkan oleh insinyur μApp, dan setiap

μApp memiliki timer. Namun, ketika μApp ditingkatkan (misalnya, versi baru

dari layanan mikro yang digunakan), timer reset untuk menunggu versi baru

ini menghasilkan data yang cukup untuk mengisi model. Ketika interval waktu

tercapai, loop kontrol dimulai. Analyzer menghitung afinitas, memperbarui

model, dan memberi tahu perencana. Perencana menggunakan afinitas

untuk menghitung rencana adaptasi. Perencana mengirimkan rencana

adaptasi ke pelaksana yang bermigrasi microservices.

431

P. Architectonic Support

Dukungan yang berelasi ke, atau karakteristik arsitektur, desain, dan

konstruksi, berelasi ke scientific systematization of the totality of knowledge

pada tiga dukungan yaitu:

1. Design patterns, yang paling penting yaitu: a] Singleton, b] Factory

method, c] Strategy, d] Observer, e] Builder, f] Adapter, g] State.

(Team 2018)

2. Reference architecture, focus pada implementasinya untuk cyber

physical systems (CPS IoT & cloud technology) untuk mendukung

condition based maintenance (CBM). Pemeliharaan adalah esensial

untuk meningkatkan kinerja asset industry dan proses reactive

/proactive maintenance. Yang pertama focus pada perbaikan asset

ketika kerusakan terjadi. Yang kedua focus pada pencegahan

perbaikan dan kerusakan asset melalui metode preventif dan prediktif.

(Larrinaga et al. n.d.)

3. Model-driven (approaches) ke teknik software telah memperluas

pengaruhnya dengan Object Management Group's Model-Driven

Architecture (MDA). Ternyata MDA tidak cocok lagi untuk software

system development karena tidak menyediakan concrete and

comprehensive process untuk governing software development

activities. Penggantinya adalah Model-Driven Development.