Gagasan microservices bukanlah hal baru. Orang tua mungkin pernah bekerja dengan
EJB di masa kejayaannya. Apa itu, sudah
Samuel Colt menggunakan pendekatan modular untuk memproduksi revolvernya. Bagian pistolnya yang standar dan dibuat dengan presisi dapat dipertukarkan, yang sangat menyederhanakan produksi dan perawatan. Jadi mengapa infrastrukturnya tidak modular?
Tidak ada keberatan mendasar untuk ini, dan idenya sendiri terletak di permukaan. Tetapi topik layanan mikro telah menjadi relatif populer baru-baru ini. Dan ada alasan untuk ini.
Untuk waktu yang lama, pemeliharaan infrastruktur tetap menjadi tugas yang melelahkan dan agak khusus. Hanya admin yang terampil yang dapat menggunakan cache atau antrian di infrastruktur. Bahwa setiap bagian dari aplikasi memiliki infrastruktur sendiri, dan tidak ada pertanyaan - siapa yang akan melayani seluruh kebun binatang ini ?!
Tetapi teknologi virtualisasi, wadah, dan alat manajemen konfigurasi infrastruktur telah berjalan jauh. Dan sekarang untuk menggunakan infrastruktur independen untuk layanan aplikasi terpisah menjadi lebih mudah dan lebih murah daripada mendorong semua layanan dalam infrastruktur umum. Kemajuan!
Aplikasi ini dengan mudah dibagi menjadi beberapa bagian independen, termasuk untuk alasan organisasi. Dalam hal ini, interaksi antara bagian dilakukan melalui satu atau lain API. Intinya adalah layanan. Dari sini mulailah proses membagi aplikasi menjadi layanan makro, layanan metroservice, layanan mikro, layanan nano, layanan picoservice dan fungsi lambda baris tunggal di Amazon.
Tampaknya apa yang salah di sini?
Sayangnya, membagi aplikasi menjadi beberapa bagian tidak gratis. Pertama-tama, biaya untuk mendukung API di dalam infrastruktur meningkat.
Misalkan aplikasi perlu bekerja dengan file. Tugas yang khas. Layanan microser yang mengimplementasikan infrastruktur penyimpanan file dialokasikan, menyediakan dua operasi: baca dan tulis. Dan tanpa perubahan signifikan pada API, layanan seperti itu dapat tumbuh dari antarmuka ke folder di disk lokal ke infrastruktur pusat data yang didistribusikan secara geografis. Skenario yang sempurna.
Tetapi bagaimana jika aplikasi tersebut dibagi ke dalam layanan sedemikian rupa sehingga garis aneh logika bisnis berakhir pada satu layanan dan garis genap di layanan lain? Pemisahan seperti itu tidak hanya akan memperlambat aplikasi secara signifikan, karena sekarang alih-alih memanggil metode secara langsung, komunikasi jaringan akan terjadi, sehingga API antar layanan akan sering berubah sehingga cocok dengan versi panjang untuk nomor versi API.
Ini semua, tentu saja, berlebihan. Namun, ini memberikan gambaran yang jelas tentang kemungkinan konsekuensi negatif. Aplikasi yang dibangun dengan cara ini sangat mahal untuk dikembangkan.
Sebelum membagi aplikasi menjadi beberapa bagian, dua aspek harus dipertimbangkan.
Yang pertama. Seberapa sering komponen-komponen ini berinteraksi dalam satu operasi? Apakah mungkin untuk setiap tindakan Anda harus melakukan ratusan, jika tidak ribuan panggilan jaringan. Ini dapat mematikan kinerja aplikasi.
Yang kedua Seberapa sering API akan berubah antar komponen? Jika cerita git menunjukkan bahwa API akan berubah setiap hari, biaya dukungannya kemungkinan akan menjadi penghalang. Ini dapat membunuh produktivitas pengembangan.
Namun demikian, dengan pembagian aplikasi yang benar ke dalam layanan, Anda bisa mendapatkan manfaat yang signifikan. Hanya saja layanan ini tidak harus berupa mikro.