Perjalanan Shoprocket ke Mikrolayanan: Bagian 1

Beberapa bulan setelah saya mulai bekerja di Shoprocket, saya mulai merasa frustrasi. Kami memiliki aplikasi PHP yang dikerjakan oleh tim kecil kami yang terdiri dari pengembang berbakat, yang tersebar di seluruh dunia. Mengapa saya merasa frustrasi? Bagi saya, sepertinya perbaikan bug justru menimbulkan lebih banyak bug, mengintegrasikan fitur baru tidak semudah yang seharusnya, dan penyebaran aplikasi jarang dan penuh stres. Penyebab dari masalah ini: kode yang sangat terikat.

Kami memiliki aplikasi monolitik, dan hampir seluruh basis kode kami berada dalam satu repositori Github. Pembaruan atau perbaikan untuk satu fitur sering kali terjadi di beberapa tempat. Untuk pengujian, kami memiliki proses tinjauan rekan, di mana setidaknya dua pengembang lainnya harus menyetujui cabang sebelum digabungkan ke dalam master dan dikerahkan. Semua ini berarti bahwa ketika bug berhasil lolos dari pengawasan, sering kali sulit untuk menemukan perubahan yang menyebabkan kerusakan. Dan setelah kami menemukannya, perbaikan tersebut harus melalui proses yang sama dan seluruh aplikasi harus dikerahkan ulang.

Sebagai pengembang muda yang bersemangat selalu mencari hal baru, ketika saya menemukan mikroservis, saya pikir gaya arsitektur ini akan menyelesaikan semua masalah kami. Tidak ada definisi resmi tentang mikroservis, tetapi dari penelitian saya, saya memahami bahwa arsitektur mikroservis adalah cara mendesain aplikasi perangkat lunak sebagai sistem terdistribusi dari layanan independen, masing-masing sangat khusus dan memiliki siklus hidupnya sendiri. Untuk pembaca yang ingin pengantar lebih detail tentang konsep ini, saya merekomendasikan artikel luar biasa dari Martin Fowler ini.

Ada banyak aspek mikroservis yang menarik bagi saya, tetapi dua yang khusus: Pertama, gagasan memecah aplikasi menjadi layanan-layanan dengan batasan yang sangat ketat. Ini mengurangi kemungkinan logika yang spesifik untuk satu konteks bisnis bocor antara komponen karena antarmuka antara batasan harus direncanakan dengan cermat. Tidak semudah memanggil fungsi lokal; Kedua, setiap komponen dapat memiliki siklus hidupnya sendiri yang independen. Ini memungkinkan tim untuk mengambil kepemilikan atas kode mereka dan menggunakan tumpukan teknologi yang paling sesuai untuk layanan individual. Selain itu, ini memungkinkan kontrol yang lebih terperinci atas aplikasi karena perubahan dapat dikerahkan ke satu layanan pada satu waktu dan dapat dibatalkan tanpa mempengaruhi sisa aplikasi jika sesuatu berjalan tidak sesuai rencana.

Jadi, saya sudah terjual. Shoprocket akan memecah monolit! Ini adalah yang pertama dalam serangkaian posting blog pendek yang mengikuti perjalanan ini. Harapan saya adalah bahwa pembaca yang merencanakan atau menjalani transisi serupa akan belajar dari keberhasilan dan kegagalan kami dan merasa lebih siap untuk menghadapi tantangan ini dalam proyek mereka sendiri.

Tantangan pertama saya bukanlah teknis, tetapi manusia. Saya harus menjual ide ini kepada anggota tim lainnya. Mereka tampak penasaran, tetapi tidak membagikan antusiasme yang sama dan enggan mengorbankan jam pengembangan di tahap awal kehidupan produk kami. Untungnya, CTO ingin saya melihat manajemen sesi kami dan saya mengambil kesempatan ini dengan meyakinkannya bahwa saya bisa memecah layanan sesi.

Dalam retrospeksi, ini mungkin merupakan pilihan komponen yang buruk untuk layanan pertama. Produk kami mencakup plugin javascript yang mengaktifkan ecommerce di situs web mana pun. Kami memperlakukan sesi sebagai sumber daya, menyimpan informasi sesi ke database untuk analisis mendetail KPI seperti tingkat pengabaian keranjang. Namun, sumber daya ini tidak sekonkret sesuatu seperti pesanan atau item garis. Selain itu, kami menggunakan sumber daya sesi hampir untuk setiap perubahan dalam keadaan aplikasi. Ini berarti bahwa layanan tersebut akan menjadi sangat aktif dalam berkomunikasi dengan aplikasi lainnya, yang tidak saya perkirakan, tetapi membuat tugas saya menjadi sulit.

Setelah meyakinkan bos saya, saya meningkatkan penelitian saya tentang mikroservis. Selain artikel yang telah disebutkan, saya juga menemukan 'Building Microservices' oleh Sam Newman sebagai sumber daya yang sangat berharga. Saya akan sering merujuk keduanya dalam posting saya.

Dalam bukunya, Newman merekomendasikan untuk pertama kali merestrukturisasi aplikasi yang ada menjadi modul-modul yang mencerminkan konteks terbatasi dari domain. Kemudian, setelah para pengembang merasa puas, modul-modul tersebut dapat dipisahkan menjadi layanan-layanan mereka sendiri. Alasannya adalah bahwa jauh lebih mudah untuk membongkar dan menulis ulang modul jika batasannya ditentukan dengan buruk daripada untuk membongkar dan menulis ulang seluruh layanan, dengan semua kode pipa dan sumber daya persisten tambahan mereka. Namun, karena keterbatasan waktu dan semangat saya untuk membangun komponen saya sendiri, saya melanjutkan dengan layanan pertama.

Saya memilih tumpukan yang hanya sedikit berbeda dari yang kami gunakan untuk monolit kami dan mulai membangunnya. Proses pembangunan itu sendiri berlangsung cukup cepat, memakan waktu beberapa minggu untuk menghasilkan aplikasi mandiri dengan API REST. Hanya kemudian tantangan sebenarnya dimulai.

Saya harus membuat layanan tersebut berbicara dengan monolit. Pada saat ini, saya belajar betapa eratnya manajemen sesi terikat dengan sisa kode lainnya. Saya memerlukan waktu untuk memecah panggilan fungsi yang ada dan menerjemahkannya ke dalam panggilan API. Ini cukup sulit. Karena layanan sesi dan monolit memiliki skema database mereka sendiri, saya harus menulis ulang logika di monolit yang menggunakan sumber daya sesi dari database lama, merestrukturisasi data di batas aplikasi untuk mempertahankan kompatibilitas dengan klien seperti plugin javascript kami.

Mengintegrasikan layanan dengan aplikasi kami yang ada memakan waktu lebih lama daripada menulis layanan itu sendiri, dan ini tidak termasuk banyak overhead tambahan yang biasanya dibawa oleh mikroservis, seperti penemuan layanan, logging, dan pemantauan. Selain itu, karena adanya keterikatan yang erat, perubahan dilakukan di banyak area kode. Karena tim telah bekerja di berbagai area kode secara paralel selama waktu ini, akan sangat banyak pekerjaan yang diperlukan untuk menggabungkan perubahan dan memasukkan layanan sesi ke dalam produksi.

Layanan mungkin segera masuk ke produksi, namun, sekarang saya merasa bahwa saya seharusnya mengikuti nasihat Newman dan mengalihkan usaha saya untuk memodulasi aplikasi kami yang ada. Manfaat memiliki satu layanan yang berdiri sendiri sangat kecil. Manfaat nyata akan datang dari memecah seluruh hal ini, setidaknya menjadi layanan-layanan yang lebih besar, yang saling berkomunikasi sesedikit mungkin. Ini memerlukan batas komponen yang sangat dipikirkan dengan baik, dan kami belum sepenuhnya ada di sana.

Saya masih percaya pada ide mikroservis, dan saya melihat upaya saya untuk memecah layanan sebagai eksperimen yang sukses. Saya belajar banyak tentang arsitektur aplikasi dan pemodelan domain dalam proses ini, dan meningkatkan pemahaman saya tentang prinsip-prinsip REST, di antara hal-hal lainnya. Ini memiliki efek langsung di area lain dari kode kami.

Untuk pembaca yang mencari untuk beralih, saya pasti akan membaca sebanyak mungkin tentang subjek ini, dan menunda pekerjaan hingga Anda sangat percaya diri dengan basis kode yang ada dan model domain Anda. Ada cara lain untuk memperkenalkan stabilitas dan ketahanan ke dalam aplikasi monolitik. Pengembangan berbasis pengujian dan pengujian unit dan fungsional otomatis sangat membantu. Skala horizontal juga membantu membuat penyebaran sedikit lebih lancar.

Shoprocket akan melanjutkan perjalanan menuju mikroservis. Kami berharap dapat memberi tahu Anda lebih banyak di bagian 2!