Fallacy # 9: The System is Atomic

Kita menganggap semua sistem tersebut hanya merupakan satu kesatuan sehingga kita tidak dapat memecahnya. Dan hal ini menyebabkan big ball of mud. Dimana perubahan di satu tempat menyebabkan kerusakan di tempat yang lain. Kebanyakan error yang terjadi bukan merupakan compile error sehingga menjadi sangat sulit untuk diperbaiki. Kebanyakan error tersebut merupakan logic error dan runtime error yang menyebabkan behaviour system menjadi berubah. Hal ini tentu saja disebabkan oleh coupling yang tidak dapat dilihat oleh compiler.

Saya tidak akan bosan-bosan nya mengulang mengenai masalah coupling dalam distributed system. Anda bisa saja membuat system monolith yang terdistribusi secara fisik. Begitu juga dengan system yang terpisah secara logical di dalam mesin yang sama. Dari beberapa kali pembahasan kita sudah mengetahui bahwa akan lebih baik jika kita dapat memisahkan secara logical dan kemudian mendeploynya di fisik mesin yang sama. JIka dibutuhkan maka kita akan membuat dan memisahkannya ke mesin yang berbeda.

Dari paragraph di atas anda dapat melihat bahwa banyak kesalahan yang dilakukan dalam pembuatan system adalah mendistribusikan big ball of mud dalam mesin yang terpisah secara fisik. Berhati-hatilah jangan sampai anda masuk ke dalam jebakan ini. Jadi buatlah pemisahan secara logically sehingga anda tidak jatuh ke big ball of mud. Saya akan menjelaskan bagaimana hal ini bisa kita terapkan pada penjelasan bagian berikutnya pada buku ini.

Tidak ada seorang developer pun yang ada di dunia ini ingin menciptakan software yang berakhir sebagai big ball of mud dan membuat banyak coupling dan juga complex dan sulit dimengerti. Semua pasti berawal dari niat baik untuk membuat software. Tetapi banyak sekali software yang dimulai dengan design yang baik tetapi kemudian bergeser ke design yang buruk seiring dengan berjalannya waktu.

Salah satu hal yang menyebabkan hal tersebut adalah integrasi melalui database. Kita perlu berhati-hati mengenai hal ini dan jangan sampai coupling tersebut menjadi tersembunyi. Kita harus membuat coupling tersebut terlihat ke permukaan. Sehingga lebih mudah mengaturnya. Jika kita menyembunyikan hal tersebut di struktur data yang ada di database kita akan menghadapi dua kelompok code yang akan coupling secara logic. Hal ini yang tidak dapat ditangkap oleh compiler. Jika struktur data tersebut berubah maka kedua kelompok code tersebut akan break.

Hal ini di buat semakin parah ketika Database Administrator menjaga supaya design dari database tidak berubah. Developer dengan segala trik nya akan mencoba mengelabui hal tersebut dengan menyimpan data structure dalam bentuk JSON atau XML dalam satu field tertentu. Ini dilakukan tanpa menyadari coupling menjadi semakin parah. Makin parah lagi dengan nested schema. :)

Masalah yang lain adalah mengenai scale out. Jika system tidak di design untuk scale out maka system tersebut akan menjadi lebih buruk jika kita menambahkan server lebih banyak lagi.Hal ini berhubungan dengan network reliability, latency, bandwith dan hal yang kita pelajari sebelumnya. Jika semua service tersebut merujuk ke satu database yang sama. Maka bottleneck yang ada di level database. Sedangkan sebelumnya saja databse tersebut tidak dapat menangani request yang banyak apalagi ditambah dengan banyak server web farm. Scaling out the database juga menjadi hal yan g sulit dilakukan dan biasanya mahal. Jika kita melakukan vertical scaling hal ini sangat mahal. Jika kita menggunakan distributed database hal ini akan tergantung ke license cost dan juga memerlukan teknik design yang berbeda pula.

Arsitektur dengan monolithic data merupakan hal yang sangat sering kita lakukan dan kadang tanpa berpikir dua kali. Hal ini akan sangat sulit dipisahkan di kemudian hari. Refactoring yang paling sulit dilakukan bukanlah code tetapi database. Hal ini juga menjadi bermasalah jika kita ingin melakukan join dan transaction antar database. Semuanya dikarenakan system tersebut tidak di design untuk scaling.

Kita harus memulai dari batasan-batasan logical sehingga data tersebut dapat kita pisahkan dengan benar dan tidak terjadi transaksi antar service yang berbeda. Sehingga kita dapat mengatasi masalah performance tanpa menambah masalah baru.

Solusinya adalah kembali ke loose coupling, modularisasi, dan design untuk scale out dari awal. Intinya adalah menentukan boundary dari service-service yang ada. Dekomposisi secara logical seperti yang sangat sering saya ulang-ulang menjadi sangat penting. Business logic yang seperti apa yang ada di satu bagian dan yang ada dibagian yang lain.

Biasanya kita hanya mengikuti kaidah Object Oriented Software Analysis and Design. Yang sering kita awali dengan temukan noun pada domain yang sedang anda kerjakan dan buatlah data strukturnya. Anda akan menemukan customer services, order service, product and banyak entity type services. Entity type services hanya dapat bekerja dengan baik untuk satu masa tetapi tidak dalam level scale yang besar. Metode design ini lah yang akan kita bahas pada buku ini.