Halo kolega. Hari ini kami menerbitkan terjemahan dari ulasan selanjutnya dari situs Ben Neidel - situs ini pasti akan menarik bagi Anda dalam aslinya. Kali ini kita akan berbicara tentang buku "
Sistem Terdistribusi. Pola Desain ", yang melengkapi buku "
Master Kubernetes " yang diterbitkan pada awal tahun ini, dan, pada dasarnya, adalah analog dari GoF untuk desain sistem terdistribusi.
Selamat membaca.
Selama akhir pekan, saya membaca buku Sistem Terdistribusi. Pola Desain, oleh
Brendan Burns . Saya sangat menyukai buku itu, meskipun, saya harus akui, saya berharap menemukan sedikit materi yang berbeda di dalamnya. Jadi, dalam uraian buku kontainer disebutkan hanya secara sepintas. Pada saat yang sama, meskipun pola yang dijelaskan dalam buku ini berlaku tidak hanya untuk kontainerisasi, hampir semua pola yang dijelaskan di sini diberikan dalam konteks wadah, dan setelah itu mereka dipertimbangkan dalam pipa penyebaran Kubernet. Ternyata omong-omong. Saya baru mulai berkenalan dengan pengembangan dan penyebaran yang berorientasi pada wadah, dan mendiskusikan pola-pola arsitektur dari sudut pandang “wadah” seperti itu merupakan sebuah wahyu bagi saya. Pendekatan ini membantu saya untuk mendapatkan pemahaman yang baik tentang bagaimana dalam lanskap layanan mikro layanan kecil dibedakan dengan benar, yang masing-masing memiliki peluang khusus.
Penulis buku ini, Brendan Burns, adalah salah satu pendiri proyek sumber terbuka Kubernetes. Oleh karena itu, tidak mengherankan bahwa semua contoh aplikasinya dibangun di sekitar penyebaran kontainer berdasarkan file konfigurasi Kubernet. Pada saat membaca buku itu, saya sedikit berpengalaman di Docker dan tidak tahu apa-apa tentang Kubernetes. Jadi, saya mencoba mencari tahu "tujuan" dari file konfigurasi Kubernetes hanya dengan membacanya. Namun, saya percaya bahwa buku ini akan lebih bermanfaat jika pembaca memiliki setidaknya beberapa pengalaman dengan Kubernetes.
Membaca buku itu, saya tidak bisa menyingkirkan asosiasi dengan karya "
Template Integrasi untuk Aplikasi Perusahaan " oleh Gregor Hope dan Bobby Wolf. Banyak pola yang dibahas oleh Burns sangat mirip dengan pola antrian pesan yang dibahas oleh Hope dan Wolfe. Bahkan, saya harus mengatakan bahwa banyak pola bahkan disebut dalam kedua buku dengan cara yang sama (misalnya, Scatter / Gather). Ini logis, karena tema kedua buku tersebut adalah partisi dari sistem monolitik yang kompleks menjadi satu set layanan kecil yang dapat digunakan kembali dan dirancang secara ketat. Saya pikir bahkan dapat diperdebatkan bahwa Burns menguraikan pendekatan spesifik yang akan berguna dalam mengimplementasikan layanan Produser dan layanan Konsumen yang terlibat dalam berfungsinya alur kerja berbasis pesan, yang sama seperti yang dijelaskan dalam buku "Enterprise Application Integration Templates".
Sekali lagi, saya percaya bahwa kesejajaran yang dilacak antara kedua buku ini bersaksi tentang kekuatan pola desain. Baik dalam seberapa baik mereka mengarahkan kita ke solusi yang terbukti, dan pada kenyataan bahwa pola desain memfasilitasi komunikasi teknis, karena mereka memungkinkan kita untuk bernalar dalam bahasa yang sama.
Pada saat yang sama, salah satu pendekatan yang paling saya sukai dijelaskan dalam buku “Sistem Terdistribusi. Pola Desain ”justru terkait dengan konsumsi antrian pesan. Burns menyarankan untuk tidak memaksa wadah kerja untuk menarik pesan langsung dari sistem (mirip dengan bagaimana hal itu dilakukan dalam sistem Simple Queue Service (SQS) Amazon), tetapi untuk menciptakan "duta besar" (pola Duta Besar). Wadah “duta besar” seperti itu akan digunakan bersama dengan wadah kerja dan menyediakan API umum untuk memanipulasi antrian. Wadah Duta Besar memungkinkan Anda untuk meringkas detail implementasi yang terkait dengan penyimpanan permanen elemen dalam antrian pesan, sehingga wadah yang berfungsi benar-benar independen dari solusi teknologi spesifik apa pun.
"Duta Wadah-Sumber Antrian Kerja" hanyalah salah satu contoh dari topik lintas sektoral yang berjalan di dalam buku ini sebagai benang merah: gunakan set wadah kecil sehingga setiap wadah individu dapat fokus sebanyak mungkin pada tugas tertentu dan berubah menjadi dapat digunakan kembali sebanyak mungkin. Burns mengeksplorasi konsep ini di tingkat wadah individu, berbicara tentang parameter wadah menggunakan argumen baris perintah dan variabel lingkungan. Kemudian ia naik satu tingkat, berbicara tentang pola sisi-mobil multi-kontainer dan duta besar dalam konteks single-node. Akhirnya, ia menunjukkan cara membuat arsitektur microservice yang kuat menggunakan pola multi-kontainer.
Saya pikir Burns dapat dengan sempurna mengartikulasikan "mimpi" dari seluruh lanskap layanan-mikro:
Pendekatan layanan mikro memiliki banyak keunggulan, banyak di antaranya terkait dengan keandalan dan fleksibilitas. Layanan microsoft membagi aplikasi menjadi bagian-bagian kecil, yang masing-masing bertanggung jawab untuk penyediaan layanan tertentu. Dengan mempersempit ruang lingkup layanan, setiap layanan dapat mengembangkan dan mempertahankan tim yang dapat diberi makan dengan dua pizza.
Mengurangi ukuran tim juga mengurangi biaya mempertahankan kegiatannya.
Selain itu, munculnya antarmuka formal antara layanan microsoft melemahkan saling ketergantungan tim dan membuat kontrak yang dapat diandalkan antara layanan. Kontrak formal semacam itu mengurangi perlunya sinkronisasi tim yang ketat, karena tim yang menyediakan API memahami sejauh mana diperlukan untuk memastikan kompatibilitas, dan tim yang mengonsumsi API dapat mengandalkan layanan yang stabil tanpa khawatir tentang detail implementasi layanan yang dikonsumsi. Dekomposisi semacam itu memungkinkan tim untuk secara independen mengendalikan laju perkembangan dan jadwal untuk rilis versi baru, yang memberi mereka kesempatan untuk mengulang, sehingga meningkatkan kode layanan.
Akhirnya, membaginya menjadi layanan microser meningkatkan skalabilitas. Karena setiap komponen dialokasikan ke layanan yang terpisah, maka dapat ditingkatkan secara terpisah dari yang lain
(hal. 79-80 dalam terjemahan Rusia)
Saya berbicara tentang "mimpi" karena, seperti yang diakui Burns, sulit untuk merancang sistem layanan mikro dan merancang arsitekturnya. Dan memantau dan men-debug sistem seperti itu jauh lebih rumit daripada memantau dan men-debug analog monolitik. Hanya dengan ini saya dapat dengan mudah setuju. Menurut pengalaman saya sendiri yang terbatas bekerja dengan layanan mikro, saya mengkonfirmasi bahwa layanan bersama dengan cepat menjadi sangat terhubung, dan "kontrak yang dapat diandalkan" antara layanan dengan cepat berubah menjadi target bergerak, mengalami perubahan baru yang semakin banyak.
Sebagai kesimpulan, saya ingin menyentuh konsep FaaS - “berfungsi sebagai layanan”. Sistem seperti Layanan Lambda Amazon membuat saya merasa campur aduk. Dalam arti yang sangat abstrak, saya suka sistem seperti itu, tetapi saya tidak tahu bagaimana mereka memanifestasikan diri dalam aplikasi tertentu. Burns menyentuh FaaS di Bagian II tentang "Pola Merancang Sistem Penyajian," tetapi sayangnya itu tidak sepenuhnya menjelaskan masalah Faas bagi saya.
Saya sangat suka bahwa Burns merekomendasikan menggunakan FaaS untuk menyelesaikan hanya sebagian dari masalah yang diketahui:
Seperti alat-alat lain untuk mengembangkan sistem terdistribusi, Anda mungkin ingin menggunakan solusi tertentu (misalnya, pemrosesan berorientasi peristiwa) sebagai alat universal. Yang benar adalah bahwa solusi tertentu biasanya menyelesaikan masalah-masalah tertentu. Dalam konteks tertentu, itu akan terbukti menjadi alat yang kuat, tetapi menariknya ke telinga untuk memecahkan masalah umum menciptakan arsitektur yang kompleks dan rapuh.
(hal. 135 dalam terjemahan Rusia)
Selain itu, banyak terima kasih kepadanya karena menyebutkan kesulitan yang muncul saat menggunakan FaaS:
Seperti disebutkan di bagian sebelumnya, pengembangan sistem menggunakan pendekatan FaaS memaksa Anda untuk membuat komponen sistem secara longgar digabungkan. Setiap fungsi independen menurut definisi. Semua interaksi dilakukan melalui jaringan. Instance fungsi tidak memiliki memori sendiri, oleh karena itu, mereka memerlukan penyimpanan bersama untuk menyimpan status. Pelemahan paksa dari elemen-elemen sistem dapat meningkatkan fleksibilitas dan kecepatan pengembangan layanan, tetapi pada saat yang sama dapat secara signifikan mempersulit dukungannya.
Secara khusus, cukup sulit untuk melihat struktur layanan yang komprehensif, untuk menentukan bagaimana fungsi-fungsi terintegrasi satu sama lain, untuk memahami apa dan mengapa kesalahan terjadi jika terjadi kegagalan. Selain itu, fungsi yang berorientasi pada permintaan dan fungsi tanpa server berarti bahwa beberapa masalah akan sulit dideteksi.
(hal. 136-137 dalam terjemahan Rusia)
Sekali lagi, saya terkejut oleh kenyataan bahwa sebagian besar sistem FaaS tidak terlalu bagus untuk menyelesaikan tugas yang membutuhkan pemrosesan aktif:
... selain itu, karena implementasi layanan tanpa server, waktu eksekusi instance fungsi biasanya terbatas. Ini berarti bahwa pendekatan FaaS biasanya tidak cocok untuk aplikasi yang membutuhkan pemrosesan data latar belakang yang panjang. (P. 138 dalam terjemahan Rusia)
Akhirnya, saya senang dengan pernyataan bahwa FaaS menjadi tidak ekonomis secara ekonomis jika tidak mungkin untuk memastikan operasi prosesor yang tidak terputus lama:
Tetapi jika Anda memiliki begitu banyak permintaan sehingga fungsi ini terus-menerus aktif, Anda cenderung membayar lebih untuk jumlah permintaan yang diproses.
... saat layanan tumbuh, jumlah permintaan yang diproses tumbuh ke tingkat yang membuat prosesor terus sibuk memprosesnya. Pada titik ini, biaya untuk jumlah permintaan mulai menjadi tidak menguntungkan. Biaya per unit waktu CPU mesin virtual cloud berkurang karena inti ditambahkan, serta dengan memesan sumber daya dan diskon untuk penggunaan jangka panjang. Biaya untuk membayar jumlah permintaan biasanya meningkat seiring dengan jumlah permintaan.
(hal. 139-140 dalam terjemahan Rusia)
Akibatnya, saya masih tidak mengerti: kapan lebih baik menggunakan "fungsi sebagai layanan"? Saya perhatikan bahwa Burns secara singkat menjelaskan bekerja dengan tugas jangka pendek yang berorientasi pada peristiwa yang tidak memuat prosesor banyak, seperti otentikasi dua faktor (2FA). Namun, mengingat bahwa kita berbicara tentang tugas jangka pendek kecil dengan biaya rendah, muncul pertanyaan: mengapa mereka harus ditingkatkan secara independen? Mengapa tidak memasukkan saja fitur-fitur ini ke dalam layanan peti kemas lain yang terkait erat dengan yang pertama?
Saya berharap dapat menangani masalah ini dengan lebih baik ketika saya menggunakan teknologi FaaS dalam praktiknya.
Terlepas dari beberapa kebingungan dengan FaaS, saya sangat menyukai buku itu. Itu dibaca dengan cepat, mudah dirasakan. Sekali lagi mengingatkan kita tentang potensi besar melemahkan koneksi antara komponen di semua tingkat pengembangan aplikasi. Akhirnya, sekarang akan jauh lebih mudah bagi saya untuk terus berkomunikasi dengan rekan-rekan saya tentang topik-topik seperti "wadah sespan."