Meninjau kembali filosofi Unix di 2018

Terdengar familiar?

Ya, saya pikir begitu. Seperti itu penjelasan definisi sebenarnya dari kata microservice yang ditawarkan oleh James Lewis dan Martin Fowler:

Singkatnya, gaya arsitektur layanan mikro adalah pendekatan untuk mengembangkan aplikasi tunggal sebagai rangkaian layanan kecil, masing-masing berjalan dalam prosesnya sendiri dan berkomunikasi dengan mekanisme ringan, sering kali merupakan API sumber daya HTTP.

Meskipun satu program *nix atau satu layanan mikro mungkin sangat terbatas atau bahkan tidak terlalu menarik, kombinasi dari unit kerja independen tersebutlah yang mengungkapkan manfaat sebenarnya dan, oleh karena itu, kekuatan mereka.

*nix vs. layanan mikro

Tabel berikut membandingkan program (seperti cat atau lsof ) di lingkungan *nix terhadap program di lingkungan layanan mikro.

Mari kita jelajahi setiap baris dengan sedikit lebih detail.

Unit eksekusi

Selengkapnya tentang Layanan Mikro

• Lembar contekan layanan mikro
• Cara menjelaskan layanan mikro kepada CEO Anda
• eBuku gratis:Layanan mikro vs. arsitektur berorientasi layanan
• Kursus online gratis:Mengembangkan aplikasi cloud-native dengan arsitektur layanan mikro
• Artikel layanan mikro terbaru

Unit eksekusi di *nix (seperti Linux) adalah file yang dapat dieksekusi (skrip biner atau yang ditafsirkan) yang, idealnya, membaca input dari stdin dan menulis output ke stdout . Penyiapan layanan mikro berkaitan dengan layanan yang mengekspos satu atau beberapa antarmuka komunikasi, seperti HTTP atau gRPC API. Dalam kedua kasus tersebut, Anda akan menemukan contoh stateless (pada dasarnya perilaku fungsional murni) dan contoh stateful, di mana, selain input, beberapa state internal (bertahan) memutuskan apa yang terjadi.

Aliran data

Secara tradisional, program *nix dapat berkomunikasi melalui pipa. Dengan kata lain, berkat Doug McIlroy, Anda tidak perlu membuat file sementara untuk diedarkan dan masing-masing dapat memproses aliran data yang hampir tak ada habisnya antar proses. Sepengetahuan saya, tidak ada yang sebanding dengan pipa yang distandarisasi dalam layanan mikro, selain eksperimen kecil berbasis Apache Kafka dari tahun 2017.

Konfigurasi dan parameterisasi

Bagaimana Anda mengonfigurasi program atau layanan—baik secara permanen atau berdasarkan panggilan? Nah, dengan program *nix Anda pada dasarnya memiliki tiga opsi:argumen baris perintah, variabel lingkungan, atau file konfigurasi lengkap. Dalam layanan mikro, Anda biasanya berurusan dengan dokumen YAML (atau lebih buruk lagi, JSON), menentukan tata letak dan konfigurasi layanan mikro tunggal serta dependensi dan komunikasi, penyimpanan, dan pengaturan runtime. Contohnya termasuk definisi sumber daya Kubernetes, spesifikasi pekerjaan Nomad, atau file Docker Compose. Ini mungkin atau mungkin tidak parameter; yaitu, Anda memiliki beberapa bahasa templat, seperti Helm di Kubernetes, atau Anda mendapati diri Anda melakukan banyak sekali sed -i perintah.

Penemuan

Bagaimana Anda mengetahui program atau layanan apa yang tersedia dan bagaimana mereka seharusnya digunakan? Nah, di *nix, Anda biasanya memiliki manajer paket serta orang tua yang baik; di antara mereka, mereka harus dapat menjawab semua pertanyaan yang mungkin Anda miliki. Dalam pengaturan layanan mikro, ada sedikit lebih banyak otomatisasi dalam menemukan layanan. Selain pendekatan yang dipesan lebih dahulu seperti SmartStack Airbnb atau Eureka Netflix, biasanya ada pendekatan berbasis variabel lingkungan atau berbasis DNS yang memungkinkan Anda menemukan layanan secara dinamis. Sama pentingnya, OpenAPI menyediakan standar de-facto untuk dokumentasi dan desain HTTP API, dan gRPC melakukan hal yang sama untuk kasus kinerja tinggi yang digabungkan lebih erat. Last but not least, pertimbangkan pengalaman pengembang (DX), dimulai dengan menulis Makefile yang bagus dan diakhiri dengan menulis dokumen Anda dengan (atau dalam?) gaya .

Pro dan kontra

Baik *nix dan layanan mikro menawarkan sejumlah tantangan dan peluang

Komposabilitas

Sulit untuk merancang sesuatu yang memiliki fokus yang jelas dan tajam dan juga dapat bermain dengan baik dengan orang lain. Bahkan lebih sulit untuk melakukannya dengan benar di berbagai versi dan untuk memperkenalkan kemampuan penanganan kasus kesalahan masing-masing. Dalam layanan mikro, ini bisa berarti coba lagi logika dan batas waktu—mungkin itu opsi yang lebih baik untuk mengalihdayakan fitur-fitur ini ke mesh layanan? Sulit, tetapi jika Anda melakukannya dengan benar, kegunaannya kembali bisa sangat besar.

Observabilitas

Dalam monolit (tahun 2018) atau program besar yang mencoba melakukan semuanya (tahun 1984), agak mudah untuk menemukan pelakunya ketika semuanya berjalan ke selatan. Tapi, dalam

yes | tr \\n x | head -c 450m | grep n

atau jalur permintaan dalam pengaturan layanan mikro yang melibatkan, katakanlah, 20 layanan, bagaimana Anda bahkan memulai untuk mencari tahu mana yang berperilaku buruk? Untungnya kami memiliki standar, terutama OpenCensus dan OpenTracing. Observabilitas mungkin masih menjadi pemblokir tunggal terbesar jika Anda ingin pindah ke layanan mikro.

Negara global

Meskipun mungkin bukan masalah besar untuk program *nix, dalam layanan mikro, status global tetap menjadi bahan diskusi. Yaitu, bagaimana memastikan keadaan lokal (persisten) dikelola secara efektif dan bagaimana membuat keadaan global konsisten dengan upaya sesedikit mungkin.

Menutup

Pada akhirnya, pertanyaannya tetap:Apakah Anda menggunakan alat yang tepat untuk tugas yang diberikan? Artinya, dengan cara yang sama program *nix khusus yang mengimplementasikan berbagai fungsi mungkin merupakan pilihan yang lebih baik untuk kasus penggunaan atau fase tertentu, mungkin monolit adalah pilihan terbaik untuk organisasi atau beban kerja Anda. Terlepas dari itu, saya harap artikel ini membantu Anda melihat banyak persamaan yang kuat antara filosofi Unix dan layanan mikro—mungkin kita dapat belajar sesuatu dari yang pertama untuk memberi manfaat bagi yang terakhir.