# Perjalanan Shoprocket menuju microservices, bagian 1: yang saya salah soal memecah monolit

> Tulisan tim engineering dari tahun-tahun awal Shoprocket tentang percobaan pertama mengekstrak satu layanan dari monolit PHP. Mengapa saya memilih layanan pertama yang salah, apa yang diajarkan kopling erat, dan nasihat Newman yang seharusnya saya ikuti lebih awal.

Winston Berty  - 17 Maret 2016 - 5 menit baca

Beberapa bulan setelah bekerja di Shoprocket, saya mulai frustrasi. Kami punya aplikasi PHP yang dikerjakan tim kecil developer tangguh yang tersebar di seluruh dunia, dan bagi saya perbaikan bug malah melahirkan bug baru, mengintegrasikan fitur baru tidak sesederhana seharusnya, dan deployment jarang terjadi serta menegangkan. Penyebabnya: kode yang sangat terkopel.

Kami punya aplikasi monolitik, hampir seluruhnya di satu repositori GitHub. Pembaruan atau perbaikan pada satu fitur sering membutuhkan perubahan di beberapa tempat. Untuk pengujian, kami punya proses peninjauan sejawat di mana setidaknya dua developer lain harus menyetujui sebuah branch sebelum digabung ke master dan di-deploy. Semua ini berarti ketika sebuah bug lolos, sering sulit menemukan perubahan yang merusak. Setelah ketemu, perbaikannya melewati proses yang sama, dan seluruh aplikasi harus di-deploy ulang.

Sebagai developer muda yang antusias dan selalu mencari hal baru, ketika saya menemukan microservices, saya mengira ini akan menyelesaikan semua masalah kami.

## Yang saya kira microservices itu

Tidak ada definisi formal microservices, tetapi dari riset saya, saya menyimpulkan bahwa arsitektur microservice adalah cara merancang aplikasi perangkat lunak sebagai sistem terdistribusi dari layanan-layanan independen, masing-masing sangat terspesialisasi dan punya siklus hidupnya sendiri. Untuk pengantar mendetail, [artikel](https://martinfowler.com/articles/microservices.html) Martin Fowler sangat bagus.

Dua aspek membuat saya terpikat. Pertama, gagasan memecah aplikasi menjadi layanan dengan batas yang ketat. Ini menurunkan kemungkinan logika yang spesifik pada satu konteks bisnis bocor antarkomponen, karena antarmuka antarbatas harus direncanakan dengan cermat. Tidak sesederhana memanggil fungsi lokal. Kedua, setiap komponen bisa punya siklus hidup independen. Tim bisa memiliki kodenya dan memakai stack yang paling cocok untuk layanan itu, dan perubahan bisa di-deploy satu layanan sekali waktu dan di-rollback tanpa memengaruhi yang lain.

Saya sudah yakin. Shoprocket akan memecah monolit. Ini bagian 1 dari seri pendek yang mengikuti perjalanannya. Harapan saya, pembaca yang sedang merencanakan atau menjalani transisi serupa bisa belajar dari keberhasilan dan kegagalan kami.

## Tantangan pertama adalah manusia, bukan teknis

Saya harus menjual gagasan ini kepada anggota tim lainnya. Mereka penasaran tetapi tidak berbagi antusiasme itu, dan enggan merelakan jam kerja developer pada tahap awal umur produk ini. Untungnya, CTO ingin saya menelaah manajemen sesi kami, jadi saya memanfaatkan momen itu: saya meyakinkannya bahwa saya bisa memisahkan layanan sesi.

Dalam retrospeksi, ini pilihan buruk untuk layanan pertama. Produk kami menyertakan widget JavaScript yang [memungkinkan ecommerce di situs web mana pun](https://v3.shoprocket.io/id/fitur/jual-di-situs-web-mana-pun.md). Kami memperlakukan sesi sebagai sebuah resource, menyimpan informasi sesi ke database untuk menganalisis keranjang terbengkalai dan KPI lainnya. Tetapi resource ini tidak sekonkret pesanan atau item baris, dan kami memakai sesi pada hampir setiap perubahan status aplikasi. Artinya layanan itu pasti akan sangat cerewet dengan sisa aplikasi, yang tidak saya antisipasi dan membuat tugas saya lebih sulit.

## Yang saya pelajari saat benar-benar membangunnya

Saya mempertebal riset. Di samping Fowler, **Building Microservices** karya Sam Newman ternyata menjadi sumber yang tak tergantikan.

Nasihat Newman, dalam kilas balik, adalah nasihat yang seharusnya saya ikuti: pertama-tama susun ulang aplikasi yang ada menjadi modul-modul yang mencerminkan bounded context domain. Setelah para developer puas dengan batas-batasnya, *baru* pisahkan modul menjadi layanan sendiri. Alasannya, jauh lebih mudah memecah dan menulis ulang modul dengan batas yang buruk daripada memecah dan menulis ulang seluruh layanan beserta kode pipa tambahan dan resource persistennya.

Saya tidak mengikuti nasihat itu. Karena ingin sekali membangun komponen milik saya sendiri, saya meneruskan layanan sesi.

Saya memilih stack yang hanya sedikit berbeda dari monolit dan mulai membangun. Layanannya sendiri selesai dengan cepat, memakan beberapa minggu untuk menghasilkan aplikasi mandiri dengan REST API. Bukan di situ bagian sulitnya. Bagian sulitnya adalah membuat layanan itu berbicara dengan monolit.

Manajemen sesi ternyata terkopel erat dengan sisa basis kode. Mengganti pemanggilan fungsi dengan pemanggilan API adalah pekerjaan lambat. Karena layanan sesi dan monolit punya skema database terpisah, saya harus menulis ulang logika apa pun di monolit yang memakai resource sesi dari database lama, menata ulang data di batas aplikasi agar klien seperti widget JavaScript kami tetap kompatibel.

Mengintegrasikan lebih lama daripada membangun. Dan itu pun belum termasuk sebagian besar overhead yang biasanya dibawa microservices: service discovery, logging, monitoring, distributed tracing. Lebih buruk lagi, kopling erat berarti perubahan menyebar ke banyak area kode. Karena tim bekerja paralel selama waktu itu, menggabungkan dan membawa layanan sesi ke produksi akan membutuhkan koordinasi jauh lebih banyak daripada yang saya perkirakan.

## Penilaian yang jujur

Layanan itu mungkin segera masuk produksi. Tetapi sekarang saya merasa seharusnya mengikuti nasihat Newman dan lebih dulu memusatkan upaya pada memodularkan aplikasi yang ada. Manfaat dari satu layanan yang hidup sendiri itu marginal. Manfaat sesungguhnya datang dari memecah seluruhnya, setidaknya menjadi layanan berbutir kasar yang sesedikit mungkin berbincang satu sama lain. Itu memerlukan batas komponen yang dipikirkan matang, dan kami belum sampai di sana.

Saya masih terpikat pada microservices sebagai gagasan. Saya memandang percobaan saya sebagai eksperimen yang berguna. Saya belajar banyak tentang arsitektur aplikasi, pemodelan domain, dan prinsip REST, dan pelajaran itu berdampak berantai pada bagian lain kode kami.

Bagi siapa pun yang mempertimbangkan transisi serupa, rekomendasi jujur saya:

- Baca sebanyak mungkin tentang topik ini sebelum berkomitmen
- Tunda pekerjaannya sampai Anda benar-benar percaya diri dengan basis kode dan model domain Anda yang ada
- Ingat ada cara lain untuk membawa stabilitas dan ketahanan ke monolit. Pengujian unit dan fungsional otomatis sangat membantu. Test-driven development mengurangi regresi. Penskalaan horizontal membuat deployment tidak terlalu menyakitkan
- Mulailah dengan memodularkan monolit Anda sebelum mengekstrak layanan

Shoprocket akan melanjutkan perjalanannya. Bagian 2 adalah saat segalanya menjadi lebih menarik.

---

*Awalnya diterbitkan sebagai yang pertama dari seri pendek yang mendokumentasikan migrasi awal Shoprocket dari monolit PHP. Perjalanan lengkapnya, termasuk kesalahan yang dikoreksi pada iterasi berikutnya, terus berlanjut di setiap penulisan ulang besar platform sejak itu.*

---

- HTML version: https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit
- Language: Bahasa Indonesia (id)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)