Poin utama:
- Interaksi antar komponen secara langsung satu sama lain dapat menyebabkan perilaku tidak terduga yang sulit dipahami oleh pengembang, operator, dan analis bisnis.
- Untuk memastikan keberlanjutan bisnis Anda, Anda perlu melihat semua interaksi yang muncul di sistem.
- : , -; , ; , ; (process mining), ; , .
- , , , .
Pada tahun 2018, saya bertemu dengan seorang arsitek dari sebuah perusahaan internet besar. Dia mengatakan kepada saya bahwa mereka mengikuti semua pedoman yang benar dan membagi fungsionalitas menjadi bagian-bagian kecil dalam area yang berbeda, meskipun mereka tidak menyebut gaya arsitektur ini "layanan mikro". Kemudian kami berbicara tentang bagaimana layanan ini berinteraksi satu sama lain untuk mendukung logika bisnis yang melampaui batas layanan, karena di sinilah teori dipraktikkan. Dia mengatakan bahwa layanan mereka berinteraksi menggunakan acara yang dipublikasikan di bus - pendekatan ini disebut " koreografi " (saya akan membicarakannya lebih detail di bawah). Perusahaan menilai hal ini optimal dalam hal mengurangi kohesi. Tetapi mereka menghadapi masalah: sulit untuk memahami apa yang terjadi dalam sistem, dan bahkan lebih sulit untuk mengubahnya. " Ini bukan tarian koreografi yang Anda lihat di presentasi layanan mikro, ini lompatan pogo yang tidak terkendali! "
Semua ini selaras dengan apa yang dikatakan klien lain kepada saya, misalnya, Josh Wolf dari Credit Sense :" Sistem yang kami gantikan menggunakan koreografi peer-to-peer kompleks yang membutuhkan analisis beberapa codebase untuk memahami. "
Mari kita pahami situasi ini menggunakan contoh yang disederhanakan. Katakanlah Anda sedang membangun aplikasi pemenuhan pesanan. Anda telah memilih untuk menggunakan arsitektur berbasis peristiwa dan telah memilih, katakanlah, Apache Kafka sebagai bus peristiwa. Ketika seseorang memesan, layanan checkout menghasilkan acara yang diambil oleh layanan pembayaran. Layanan pembayaran ini menerima uang dan menghasilkan peristiwa yang diambil oleh layanan inventaris.
Aliran acara yang dikoreografikan.
Keuntungan dari pendekatan ini adalah Anda dapat dengan mudah menambahkan komponen baru ke sistem. Katakanlah Anda ingin membuat layanan notifikasi yang mengirimkan email ke pelanggan Anda. Anda cukup menambahkan layanan baru dan berlangganan ke acara yang sesuai tanpa menyentuh bagian sistem lainnya. Dan sekarang Anda dapat mengelola pengaturan interaksi Anda secara terpusat dan kompleksitas pemberitahuan yang memenuhi persyaratan GDPR (regulasi perlindungan data UE).
Gaya arsitektur ini disebut koreografi karena tidak perlu seorang orchestrator memberi tahu komponen lain apa yang harus dilakukan. Di sini, setiap komponen menghasilkan peristiwa yang dapat bereaksi dengan komponen lain. Gaya ini seharusnya mengurangi kopling antar komponen dan memudahkan untuk merancang dan memodifikasi sistem, seperti yang berlaku untuk garis besar layanan notifikasi kami.
Hilangnya transparansi dalam arus peristiwa
Saya ingin fokus pada pertanyaan yang paling sering muncul ketika saya berpartisipasi dalam diskusi tentang arsitektur ini: "Bagaimana cara menghindari kehilangan transparansi (dan mungkin kendali) dari aliran peristiwa?" Dalam sebuah penelitian , Camunda (tempat saya bekerja) bertanya tentang penggunaan layanan mikro. 92% responden setidaknya telah mempertimbangkannya, dan 64% telah menggunakannya dalam satu bentuk atau lainnya. Ini bukan lagi hype. Namun dalam studi tersebut, kami juga menanyakan tentang kesulitan, dan menerima konfirmasi yang jelas tentang kekhawatiran kami: paling sering kami diberi tahu tentang hilangnya transparansi ujung ke ujung dari proses bisnis yang melibatkan banyak layanan.
Ingat arsitektur berdasarkan beberapa pemicu database? Arsitektur di mana Anda tidak pernah tahu persis apa yang akan terjadi sebagai tanggapan atas beberapa tindakan, dan mengapa ini terjadi? Kadang-kadang saya diingatkan akan hal ini oleh kesulitan yang terkait dengan layanan mikro reaktif, meskipun perbandingan seperti itu jelas tidak tepat.
Menjamin transparansi
Apa yang bisa dilakukan dalam situasi seperti ini? Pendekatan berikut akan membantu Anda mendapatkan kembali transparansi, tetapi masing-masing memiliki kelebihan dan kekurangannya sendiri:
- Pelacakan terdistribusi (seperti Zipkin atau Jaeger).
- Danau data atau alat analitik (seperti Elastis).
- Proses kontrol dan analisis penambangan (misalnya ProM).
- Pelacakan menggunakan otomatisasi alur tugas (seperti Camunda).
Perhatikan bahwa semua pendekatan ini melibatkan pengamatan sistem yang sedang berjalan dan memeriksa aliran data di dalamnya. Saya tidak tahu alat analisis statis apa pun yang dapat mengekstrak informasi berguna.
Pelacakan terdistribusi
Pendekatan ini memantau tumpukan panggilan antara sistem dan layanan yang berbeda. Untuk ini, pengenal unik digunakan, biasanya ditambahkan ke header tertentu (misalnya, di HTTP atau header pesan). Jika semua orang di sistem Anda memahami atau setidaknya menyampaikan header ini, Anda dapat melacak pertukaran permintaan antar layanan.
Biasanya, pelacakan terdistribusi digunakan untuk memahami bagaimana permintaan mengalir dalam sistem, untuk menemukan di mana ada kegagalan dan untuk menyelidiki penyebab penurunan kinerja. Keuntungan dari pendekatan ini termasuk kematangan perangkat dan ekosistem yang menyertainya. Oleh karena itu, akan relatif mudah bagi Anda untuk mulai menggunakan pelacakan terdistribusi, meskipun Anda biasanya harus (mungkin secara agresif) menginstruksikan aplikasi atau container Anda.
Jadi mengapa tidak menggunakan pendekatan ini untuk memahami bagaimana proses bisnis menghasilkan peristiwa? Biasanya ada dua alasan untuk ini:
- . , , . . , -.
- . , , 90 % . Three Pillars with Zero Answers — towards a New Scorecard for Observability. .
Jadi, dengan sendirinya, penelusuran hampir tidak cocok untuk kami. Adalah logis untuk beralih ke pendekatan serupa, tetapi dengan mempertimbangkan tugas khusus kita. Ini biasanya berarti mengumpulkan bukan jejak, tetapi acara bisnis atau tematik penting yang mungkin pernah Anda temui. Seringkali solusinya bermuara pada pembuatan layanan yang mendengarkan semua kejadian dan menyimpannya dalam database, yang dapat meningkatkan beban pada sistem. Saat ini banyak orang menggunakan Elastis untuk ini.
Ini adalah mekanisme yang kuat yang relatif mudah diterapkan. Dan itu telah diterapkan oleh sebagian besar klien kami yang digerakkan oleh peristiwa. Hambatan utama implementasi biasanya menjadi pertanyaan siapa dalam organisasi besar yang akan mengelola alat seperti itu, karena tentunya perlu dikelola secara terpusat. Mudah bagi Anda untuk membuat antarmuka pengguna Anda sendiri untuk bekerja dengan mekanisme ini, memungkinkan Anda dengan cepat menemukan informasi yang relevan dengan kueri tertentu.
Contoh antarmuka pemantauan acara .
Kerugiannya termasuk kurangnya grafik yang membuatnya lebih mudah untuk bekerja dengan daftar peristiwa. Tapi Anda bisa menambahkannya ke infrastruktur, misalnya dengan memproyeksikan kejadian ke perender seperti BPMN. Kerangka kerja kecil seperti bpmn.io memungkinkan Anda menambahkan informasi ke diagram yang ditampilkan sebagai halaman HTML sederhana ( contoh ) yang dapat dikemas ke dalam plugin Kibana.
Model ini tidak dapat dijalankan dengan modul manajemen proses bisnis, itu hanya diagram yang digunakan untuk memvisualisasikan peristiwa yang dicatat. Dari sudut pandang ini, Anda memiliki kebebasan tertentu dalam memilih detail tampilan. Dan jika Anda tertarik secara khusus pada gambaran lengkapnya, maka Anda dapat membuat model yang menampilkan kejadian dari layanan mikro yang berbeda pada satu diagram. Diagram seperti ini tidak akan menghalangi Anda untuk membuat perubahan pada layanan individu, sehingga fleksibilitas perusahaan Anda tidak akan terpengaruh. Namun ada risiko diagram akan menjadi usang dibandingkan dengan kondisi sistem operasi saat ini.
Proses alat penambangan
Dalam pendekatan sebelumnya, Anda harus secara eksplisit memodelkan diagram yang akan digunakan untuk rendering. Tetapi jika kita tidak dapat mengetahui sebelumnya sifat aliran peristiwa, pertama-tama kita harus menyelidikinya.
Ini dapat dilakukan dengan menggunakan alat untuk memantau dan menganalisis proses. Mereka dapat membuat dan menampilkan diagram lengkap secara grafis, sering kali memungkinkan Anda menjelajahi detailnya, terutama yang terkait dengan kemacetan sistem atau potensi pengoptimalan.
Kedengarannya seperti solusi sempurna untuk masalah kita. Sayangnya, fitur tersebut paling sering digunakan untuk menyelidiki proses dalam arsitektur lama, sehingga mereka berfokus pada analisis log dan bekerja biasa-biasa saja dengan streaming langsung acara. Kerugian lain adalah bahwa mereka murni alat ilmiah yang sulit digunakan (misalnya ProM) atau sangat berat (misalnya Celonis). Menurut pengalaman saya, tidak praktis menggunakan alat jenis ini dalam upaya layanan mikro yang khas.
Bagaimanapun, eksplorasi proses dan analisis data membawa kemungkinan menarik untuk menyediakan visibilitas ke aliran peristiwa dan proses bisnis. Mudah-mudahan akan segera ada teknologi dengan fungsi serupa, tetapi lebih ringan, lebih ramah pengembang, dan lebih mudah diterapkan.
Pelacakan dengan otomatisasi alur tugas
Pendekatan lain yang menarik adalah memodelkan alur tugas dan kemudian menerapkan dan mengeksekusinya melalui modul kontrol. Model ini istimewa dalam arti hanya melacak peristiwa, dan tidak aktif melakukan apa pun. Artinya, ia tidak mengelola apa pun - ia hanya mendaftar. Saya membicarakan hal ini di Kafka Summit San Francisco 2018 , menggunakan Apache Kafka dan modul alur kerja Zeebe open source untuk demonstrasi .
Kesempatan ini sangat menarik. Banyak inovasi di bidang modul kontrol, yang mengarah pada munculnya alat-alat yang kompak, mudah dikembangkan, dan sangat scalable. Saya menulis tentang ini di Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation . Kerugian yang jelas termasuk kebutuhan untuk pemodelan awal aliran tugas. Namun di sisi lain, model ini dapat dieksekusi menggunakan modul kontrol proses, berbeda dengan pemantauan peristiwa. Pada dasarnya, Anda memulai proses instance untuk acara masuk, atau memetakan acara ke sebuah instance. Ini juga memungkinkan Anda untuk memeriksa apakah realitas cocok dengan model Anda.
Selain itu, pendekatan ini memungkinkan Anda memanfaatkan seluruh rantai alat yang disediakan oleh platform otomatisasi alur tugas. Anda dapat melihat status sistem yang sebenarnya, melacak SLA, mendeteksi kegagalan contoh proses, atau melakukan analisis menyeluruh terhadap data audit historis.
Contoh pemantauan aliran tugas.
Saat saya menguji pendekatan ini dengan klien kami, mudah untuk disiapkan. Kami baru saja mengumpulkan komponen generik yang menerima kejadian dari bus dan mencocokkannya dengan modul kontrol aliran tugas. Jika peristiwa tidak dapat direkonsiliasi, kami menggunakan tabel keputusan kecil untuk menentukan apakah peristiwa itu dapat diabaikan atau peristiwa tersebut akan mengarah pada peristiwa yang harus diselidiki nanti. Kami juga meningkatkan modul kontrol aliran tugas yang digunakan dalam layanan mikro untuk menjalankan logika bisnis sehingga mereka menghasilkan peristiwa tertentu (misalnya, contoh proses dimulai, diselesaikan, atau telah menyelesaikan beberapa tahap) yang akan menjadi bagian dari gambaran besar.
Semua ini mirip dengan pemantauan peristiwa, tetapi dengan penekanan pada proses bisnis. Tidak seperti penelusuran, pendekatan ini menangkap semua peristiwa bisnis dan menampilkan gambaran besar dalam berbagai format yang sesuai untuk pemangku kepentingan yang berbeda.
Outlook Bisnis
Ketersediaan proses bisnis untuk pemantauan memungkinkan Anda memahami konteksnya. Anda dapat melihat secara spesifik bagaimana, kapan dan dalam keadaan apa itu berakhir. Ini berarti Anda dapat memahami jalur mana yang tidak diikuti proses ini (dan yang lainnya sering kali mengikutinya), dan peristiwa atau data apa yang mengarah pada keputusan tertentu. Anda juga akan dapat memahami apa yang kemungkinan besar akan terjadi dalam waktu dekat. Jenis pemantauan lain tidak mengizinkan hal ini. Meskipun saat ini sering kali tidak menjadi kebiasaan untuk membahas masalah konsistensi antara bisnis dan TI, sangat penting bahwa non-spesialis juga dapat memahami proses bisnis dan bagaimana peristiwa mengalir melalui layanan mikro yang berbeda.
Dari pelacakan hingga pengelolaan
Pelacakan proses adalah alat yang hebat untuk menyediakan pemantauan operasional, pelaporan, KPI, dan transparansi; ini semua adalah faktor penting dalam menjaga fleksibilitas perusahaan. Namun dalam proyek saat ini, pelacakan hanyalah langkah pertama menuju pengelolaan dan orkestrasi yang lebih dalam di ekosistem layanan mikro Anda.
Misalnya, Anda dapat memulai dengan memantau waktu tunggu dalam proses ujung ke ujung. Ketika waktu tunggu terjadi, tindakan dilakukan secara otomatis. Pada contoh di bawah, setelah 14 hari kami akan memberi tahu klien tentang penundaan, tetapi kami akan tetap menunggu. Dan setelah 21 hari kami akan membatalkan pesanan.
Anehnya, mengirim tim untuk membatalkan pesanan di sini merupakan orkestrasi yang kerap dibicarakan secara kontroversial.
Orkestrasi
Saya sering mendengar bahwa orkestrasi harus dihindari karena mengarah pada koherensi atau mengganggu otonomi layanan mikro individu, dan tentu saja dapat diimplementasikan dengan buruk. Tetapi dimungkinkan juga untuk menerapkan orkestrasi dengan cara yang konsisten dengan prinsip layanan mikro dan membawa nilai besar bagi bisnis. Saya membicarakan hal ini secara detail di InfoQ New York 2018 .
Bagi saya, orkestrasi berarti bahwa satu layanan dapat memerintahkan layanan lainnya untuk melakukan sesuatu. Dan itu saja. Ini bukan koneksi dekat, tetapi koneksi yang berbeda. Mari kita ingat contoh kita saat memesan. Mungkin disarankan agar layanan kasir hanya membuat pesanan dan meletakkannya di bus acara tanpa mengetahui siapa yang akan memprosesnya. Layanan pesanan mengambil acara tentang pesanan yang telah muncul. Penerima belajar tentang acara tersebut dan memutuskan untuk melakukan sesuatu tentangnya. Artinya, kohesi hadir di sisi penerima.
Dengan pembayaran, situasinya berbeda, karena agak aneh jika layanan pembayaran mengetahui untuk apa pembayaran telah diterima. Tetapi dia akan membutuhkan pengetahuan ini untuk bereaksi terhadap peristiwa yang tepat seperti menempatkan atau melakukan pemesanan. Ini juga berarti bahwa layanan harus diubah setiap kali Anda ingin menerima pembayaran untuk produk atau layanan baru. Dalam banyak proyek, hubungan yang tidak menyenangkan ini dilewati dengan menghasilkan peristiwa pembayaran yang diperlukan, tetapi ini bukanlah peristiwa, karena pengirim ingin seseorang melakukan sesuatu tentang hal itu. Ini adalah tim! Layanan pemesanan memerintahkan layanan pembayaran untuk menerima uang. Dalam hal ini, pengirim mengetahui perintah mana yang akan dikirim dan melakukannya, yaitu, kohesi ada di pihak pengirim.
Agar setiap interaksi antara dua layanan menjadi efektif, ini menyiratkan tingkat penggabungan tertentu. Tetapi tergantung pada tugas spesifiknya, mungkin disarankan untuk mengimplementasikan konektivitas di salah satu sisi.
Layanan pesanan bahkan dapat bertanggung jawab atas orkestrasi dan layanan lainnya, melacak tahapan pemenuhan pesanan. Saya membahas manfaat dari pendekatan ini secara rinci dalam pembicaraan di atas. Triknya adalah bahwa arsitektur yang baik membutuhkan keseimbangan antara orkestrasi dan koreografi, yang tidak selalu mudah dilakukan.
Namun, dalam artikel ini, saya ingin fokus pada transparansi. Dan ada keuntungan nyata dari orkestrasi menggunakan modul aliran tugas: model bukan hanya kode untuk dieksekusi oleh orkestrator, tetapi juga dapat digunakan untuk memberikan transparansi aliran.
Kesimpulan
Sangat penting untuk memastikan transparansi proses bisnis Anda, apa pun implementasinya. Saya mempertimbangkan pendekatan yang berbeda, dan dalam proyek nyata semuanya biasanya bermuara pada semacam pemantauan peristiwa menggunakan alat seperti Elastis, atau untuk melacak proses menggunakan modul kontrol. Sebagian, pilihan mungkin bergantung pada kasus spesifik dan peran orang yang terlibat. Misalnya, seorang analis bisnis perlu memahami data yang dikumpulkan dari semua contoh proses dengan tingkat detail yang diperlukan, sementara petugas operasi perlu menganalisis proses tertentu dalam berbagai tingkat detail dan, mungkin, memperoleh alat untuk menyelesaikan insiden dengan cepat di tingkat sistem.
Jika proyek Anda sangat bergantung pada koreografi, pelacakan proses dapat mengarahkan Anda untuk menambahkan orkestrasi. Dan menurut saya ini adalah langkah yang sangat penting dalam mempertahankan kendali jangka panjang atas proses bisnis Anda. Jika tidak, Anda dapat "membuat sistem yang digerakkan oleh peristiwa yang dipisahkan dengan hati-hati tanpa menyadari bahwa Anda akan kehilangan transparansi karena jumlah peristiwa dan proses meningkat, dan dengan demikian memberikan masalah pada diri Anda sendiri di tahun-tahun mendatang," seperti yang dikatakan Martin Fowler . Jika Anda mengerjakan sistem yang benar-benar baru, temukan keseimbangan antara orkestrasi dan koreografi sejak awal.
Namun, terlepas dari spesifikasi penerapan sistem, pastikan untuk menyediakan bisnis dengan tampilan proses bisnis yang dapat dipahami yang diimplementasikan menggunakan layanan yang berinteraksi.