Layanan Mikro Tahap Akhir

Saya membaca tentang upaya tim Amazon Prime Video untuk menskalakan dan memotong biaya hingga 90% dengan menggabungkan layanan mikro mereka menjadi monolit. Meskipun saya yakin ada lebih banyak cerita di sini, ada cerita serupa yang diterbitkan di Internet; semacam sanggahan terhadap kegemaran layanan mikro dalam dekade terakhir.

Itu mengingatkan saya pada beberapa tahun terakhir yang saya habiskan di Twitter, di mana jumlah layanan mikro (dalam ribuan) memuncak dan kemudian mulai turun, bahkan saat lalu lintas meningkat. Semua jenis logika aplikasi diserap ke dalam satu jenis platform yang dikelola monolitik atau lainnya. Prinsip membuat layanan mikro yang dibuat khusus tidak baik secara intrinsik, dan setelah titik tertentu, tampaknya juga bukan ROI positif bagi banyak tim kami.

Arsitektur layanan mikro bisa jadi mahal. Ada narasi selama dekade terakhir bahwa ini adalah kebijakan alami untuk organisasi teknik besar, karena:

• Tim dapat mengulangi layanan mereka dengan otonomi dari organisasi yang lebih luas dan kodenya
• Komponen kecil dari arsitektur yang melayani dapat dimodifikasi tanpa mengganggu sistem yang lebih besar
• Arsitekturnya memungkinkan definisi aplikasi yang jelas dan domain kegagalan yang dapat dikelola melalui layanan independen
• Arsitekturnya memungkinkan beban kerja yang dapat disetel atau diskalakan secara independen

Kita harus memperhitungkan kerumitan pekerjaan yang dialihkan ke tim pemilik layanan kecil dan ekosistem yang lebih luas sebagai hasilnya — berbeda dengan monolit tunggal atau sejumlah kecil. Pekerjaan yang diturunkan bergantung pada kematangan tumpukan teknologi organisasi; tetapi dapat meliputi:

Mendistribusikan tanggung jawab operasional dan overhead di antara semua tim yang memiliki layanan

• Pemahaman dan konfigurasi komponen infrastruktur layanan dari penjadwalan pekerjaan dan alat penyebaran, penemuan layanan, kerangka kerja RPC, VM dan penyetelan terkait, pemantauan dan pencatatan layanan
• Definisi terdistribusi dan proses pengembangan untuk SLO dan SLI, kegagalan layanan dan penanganan kesalahan, penanganan tekanan balik, dan pensinyalan kesalahan
• Perencanaan kapasitas terdistribusi dan seringkali tidak terkoordinasi, pengujian beban, implementasi pengujian integrasi dan tanggung jawab

• Logika aplikasi yang berinteraksi dengan banyak layanan backend sering menavigasi serangkaian definisi API layanan yang dipesan lebih dahulu, semantik, model data, sistem versi, dan kadang-kadang bahkan protokol yang berbeda
• Insinyur harus memahami dan bernalar tentang keseluruhan arsitektur layanan dan pola lalu lintas untuk membangun hal-hal yang fungsional
• Solusi organik untuk jalur penyajian yang kurang optimal atau macet, replikasi dan konsumsi data terdistribusi, dependensi permintaan melingkar

• Pendekatan yang dilokalkan untuk masalah inferensi dan pemeringkatan, pemrosesan peristiwa, terjemahan HTTP/protokol internal API, dan pemetaan model data
• Fragmentasi umum dan kesulitan mempertahankan standar di tumpukan

Masalahnya adalah proses membuat, membangun, dan mengoperasionalkan layanan baru itu mahal . Integrasi layanan tersebut ke dalam arsitektur layanan produksi sulit dilakukan. Perhatian yang diperlukan untuk menyetel layanan lain untuk pengoperasian yang efisien; untuk menyiapkan akun layanan yang sesuai, profil observabilitas dan logging, pengujian integrasi, rotasi oncall, dan yang lainnya hanya menambah biaya pemeliharaan dan operasional tim. Sebagian besar organisasi tidak memiliki otomatisasi dan perancah end-to-end untuk jenis pekerjaan boilerplate yang rumit ini.

Overhead ini merupakan disinsentif utama bagi tim untuk tetap berpegang pada prinsip arsitektur layanan mikro yang diilhami UNIX yaitu “ melakukan satu hal dengan baik ”. Lebih mudah membangun kasus penggunaan baru ke dalam layanan yang sudah ada. Di ujung terjauh spektrum, tim mengoperasikan layanan "makro" yang mulai merangkum semua yang menjadi tanggung jawab mereka sebagai sebuah tim, yang mungkin mencakup berbagai produk atau kemampuan. Kualitas kepemilikan turun dari waktu ke waktu, karena reorganisasi adalah kejadian yang relatif umum. Anda bekerja dengan bola lumpur.

Penghentian layanan makro tidak terbatas pada satu rangkaian fitur tertentu, tetapi sebaliknya petak sistem yang tidak dapat diprediksi atau tidak berprinsip, yang mungkin menyerupai bagan organisasi historis. Situs mungkin atau mungkin tidak mentolerir layanan ini tidak tersedia. Lebih sulit untuk mengoptimalkan layanan untuk beban kerja yang heterogen; jalur panggilan tidak dapat dipisahkan. Seorang mantan kolega menciptakan "mikrolit" ini.

Layanan mikro menyandikan dan memberi insentif pengoptimalan lokal ke dalam arsitektur penyajian. Sulit untuk meminta pertanggungjawaban tim pada desain berprinsip untuk melayani arsitektur ketika tujuannya adalah federasi pengembangan layanan. Demikian pula, sulit untuk memecahkan masalah pengoptimalan backend-wide ketika properti layanan dependen dipesan lebih dahulu. Tanpa arsitektur layanan yang dirancang dengan hati-hati dan platform layanan pendukung, leverage sulit ditemukan — kode platform produk yang dapat digunakan kembali tersebar di serangkaian layanan berukuran besar atau pustaka bersama ; layanan frontend biasanya dipesan lebih dahulu.

Leverage layanan mikro telah ditemukan di lapisan komputasi (apa pun yang mendalangi dan menjalankan tugas atau wadah layanan), penemuan layanan, VM (berlaku dalam konteks tertentu), kerangka layanan (seperti gRPC , Finagle atau Rest.Li ) dan perkakas pengembang terpusat. Tentu saja, jaring layanan dengan baik merangkum beberapa masalah ini.

Cara lain untuk mendekati masalah ini adalah mengurangi overhead fungsional. Jadi daripada mencoba mengurangi overhead infrastruktur yang berulang untuk menjalankan layanan , Anda dapat mengurangi biaya tim yang mengimplementasikan ulang kelas pekerjaan umum . Inilah sebabnya platform terkelola sangat sukses — bahkan jika membuat atau mengoperasikan layanan itu mahal, jika kita dapat mengurangi logika aplikasinya dengan melakukan outsourcing ke platform yang dikelola publik atau swasta, itu menjadi lebih sedikit beban bagi tim pemiliknya.

Penting bagi organisasi untuk secara hati-hati mengevaluasi trade-off arsitektur berdasarkan kebutuhan spesifik, tujuan, dan kematangan tumpukan teknologi mereka. Layanan mikro memberikan keuntungan tertentu. Mereka juga memperkenalkan kerumitan dan biaya operasional yang tampaknya dapat dikelola pada awalnya, tetapi bertambah seiring waktu. Kegagalan untuk mengatasi masalah tersebut membuat proses pengembangan end-to-end sedikit lebih mudah daripada bekerja secara monolit.

Beberapa hal yang perlu diingat, terutama jika Anda bekerja dengan microlith lawas:

• “Layanan besar” atau monolit tidak selalu buruk; mereka memerlukan jenis perkakas, dukungan infra, dan serangkaian prinsip yang berbeda dari layanan mikro, tetapi mereka harus dibangun untuk menangkap elemen umum yang terdefinisi dengan baik dari arsitektur penyajian
• Mengadvokasi prinsip "satu tugas, satu layanan" cenderung jauh lebih praktis daripada menggambar batasan intuitif di sekitar area kolaborasi yang erat, masalah kinerja, dan domain kegagalan yang berbeda — dan mendorong tim untuk tetap berpegang pada rencana
• Anda dapat mengurangi kerumitan dan overhead dari "terlalu banyak layanan" dengan mengurangi kedalaman vertikal tumpukan yang menjadi tanggung jawab pemilik layanan (kerangka layanan, mesh layanan, komputasi), serta rentang ruang aplikasi melalui layanan terkelola atau platform untuk alur kerja umum