Layanan microser dalam implementasi Docker

Kami menulis layanan mikro pertama kami menggunakan wadah Docker menggunakan Amazon fargate. Kami memiliki banyak keraguan pada level implementasi menggunakan Spring Boot

Kami akan memiliki beberapa layanan mikro dalam proyek ini, apakah ini praktik yang baik kami menulis semua layanan mikro dalam satu wadah atau saya harus membuat wadah Docker terpisah untuk layanan mikro terpisah. Dengan cara yang hemat biaya kami menggunakan wadah tunggal tetapi apakah itu membuat masalah bagi struktur proyek kami di masa depan?

Kami berencana untuk menyebarkan aplikasi dalam AWS Fargate dan aplikasi kami akan memiliki opsi besar untuk memperpanjang di masa depan dan mengharapkan sekitar 100 hingga 150 layanan mikro yang berbeda. Dalam hal ini apakah hemat biaya jika kita mengunggah semua layanan microser ini dalam wadah yang berbeda juga?

Hal yang paling penting untuk diingat dengan layanan mikro adalah bahwa mereka bukan terutama tentang memecahkan masalah teknis tetapi masalah organisasi. Jadi ketika kita melihat apakah suatu organisasi harus menggunakan layanan-layanan microser, dan bagaimana layanan-layanan itu digunakan, kita perlu melihat apakah org memiliki masalah yang dipecahkan oleh gaya layanan-mikro.

Maka, jawaban atas pertanyaan Anda tentang arsitektur Anda sebagian besar akan tergantung pada ukuran tim teknologi Anda, struktur organisasi, usia produk Anda, praktik penerapan Anda saat ini, dan bagaimana hal itu cenderung berubah dalam jangka menengah.

Sebagai contoh, jika organisasi Anda:

• memiliki kurang dari 25 staf teknologi,
• diorganisir menjadi 1 atau 2 tim,
• masing-masing bekerja pada bagian mana pun dari produk,
• yang berumur kurang dari 12 bulan,
• dan digunakan sekaligus secara teratur (mis. harian, mingguan, bulanan),
• dan org tidak akan tumbuh dengan cepat,

maka Anda hampir pasti ingin melupakan microservices untuk saat ini. Dalam situasi seperti ini, tim masih baru dalam mempelajari tentang domain, jadi kemungkinan tidak tahu semua yang mereka perlu ketahui untuk benar-benar memahami apa yang akan menjadi cara yang bagus untuk membagi sistem menjadi arsitektur yang didistribusikan. Itu berarti jika mereka membaginya sekarang, mereka mungkin akan ingin mengubah batas nanti, dan itu menjadi sangat mahal ketika Anda sudah memiliki sistem terdistribusi, sementara menjadi jauh lebih sederhana dalam monolit. Terlebih lagi, dengan hanya tim kecil yang semuanya dapat bekerja pada (dan mendukung) bagian mana pun dari sistem, ada sedikit alasan untuk berinvestasi dalam membangun platform di mana masing-masing tim dapat menggunakan dan mempertahankan layanan individual. Suatu organisasi pada tahap ini biasanya akan jauh lebih peduli dengan menemukan pelanggan dan mengiterasi produk dengan cepat, bahkan mungkin memutar produk, sebagai lawan membuat tim otonom dan membangun arsitektur tangguh skala tinggi. Arsitektur monolitik masuk akal pada saat ini, tetapi amonolith yang dirancang dengan baik, dengan batas-batas komponen yang jelas ditegakkan oleh API, dan merangkum akses data, membuatnya mudah untuk menarik layanan ke dalam proses terpisah nanti.

Mari kita lihat lebih jauh dan pertimbangkan sebuah organisasi yang ...

• lebih dari 50 staf teknologi,
• diorganisir menjadi 7 tim,
• masing-masing hanya bekerja pada area spesifik produk,
• yang berusia 3 tahun,
• dan memiliki tim yang ingin menyebarkan pekerjaan mereka secara independen dari apa yang dilakukan tim lain.

Organisasi seperti itu tentunya harus membangun arsitektur yang terdistribusi. Jika tidak, dan sebaliknya semua tim ini bekerja dalam monolit, mereka akan mengalami semua jenis masalah organisasi, dengan tim yang perlu mengoordinasikan pekerjaan mereka, pelepasan ditunda sementara satu tim menyelesaikan QA pada fitur baru mereka, tambalan menyebarkan menjadi masalah besar bagi staf dan pelanggan. Terlebih lagi, dengan produk yang matang, organisasi harus cukup tahu tentang domain untuk dapat membagi domain dan tim secara masuk akal (dalam urutan itu; lihat Hukum Conway) menjadi unit yang masuk akal dan otonom yang dapat membuat kemajuan sambil meminimalkan koordinasi.

Anda tampaknya sudah memilih layanan microser. Tergantung di mana Anda duduk di skala di atas, mungkin Anda ingin meninjau kembali keputusan itu.

Jika Anda ingin terus mengembangkan dengan layanan Microsoft tetapi menggunakan semuanya dalam satu wadah, ketahuilah bahwa tidak ada yang salah dengan itujika itu sesuai dengan cara organisasi Anda bekerja saat ini. Apakah itu akan membuat masalah untuk struktur proyek Anda di masa depan? Nah, jika Anda berhasil dan organisasi Anda tumbuh, mungkin akan tiba saatnya penempatan satu-wadah ini tidak lagi paling cocok, khususnya ketika tim mulai memiliki layanan dan ingin menggunakan layanan mereka tanpa menggunakan seluruh aplikasi . Tetapi otonomi itu akan datang dengan biaya kerja ekstra dan kompleksitas, dan itu mungkin tidak memberi Anda manfaat pada saat ini. Hanya karena itu tidak akan menjadi pendekatan yang tepat untuk sistem Anda di masa depan tidak berarti bahwa itu bukan pendekatan yang tepat untuk hari ini. Caranya adalah dengan mengawasi dan mengetahui kapan harus melakukan investasi ekstra.

Tidak masalah jika Anda menggunakan wadah tunggal untuk layanan microser Anda tetapi tujuan utama dari layanan microser adalah untuk mempertahankan setiap layanan secara terpisah, setiap layanan harus digabungkan secara longgar dan setiap layanan harus memiliki basis data terpisah (jika Anda ingin mencapai basis data per arsitektur layanan). Jadi cobalah untuk mencapai hal ini menjalankan layanan Anda dalam wadah terpisah dan mengatur layanan tersebut dengan gerombolan buruh pelabuhan atau Kubernetes. Saya tahu masalah biaya tetapi jika Anda melakukannya dengan cara yang benar maka Anda akan melihat kekuatan arsitektur layanan microser.