Fallacy #5: The network topology won't change

Dengan berkembangnya teknologi network dan cloud maka network topology juga menjadi sangat volatile terhadap perubahan. Jumlah server, dimana lokasinya dan banyak lagi sangat mudah untuk berubah. Banyak hal yang dapat berubah dikarenakan server down atau perubahan subnet atau pemindahan data center.

Di setiap system ketika kita bergantung kepada suatu alamat atau ip address suatu mesin, maka kita akan terpengaruh jika mesin tersebut down atau tidak lagi dapat di akses. Salah satu yang dapat terjadi adalah timeout exception. Hal ini diperburuk lagi jika method invocation yang kita lakukan adalah synchronous dan blocking. Hal ini akan dapat menjajah thread yang anda miliki di server pada periode waktu yang tak terbatas. HTTP timeout contohnya akan terjadi setelah 30s. Dan juga kemungkinan hal ini akan dimanfaatkan oleh hacker untuk menyerang availability dari system.

Jadi berhati-hatilah jika anda melakukan hardcoding network ip dan target system. Jika anda melakukan full duplex atau request response communication selalu lakukan pengecekan terhadap hal ini. Hal ini dapat menyebabkan efek pada performance runtime dari system kita.

Salah satu solusi yang kita dapat lakukan adalah jangan melakukan hardcode terhadap IP Address. Atau gunakan multicast dan mekanisme discovery. Mekanisme discovery ini sangat keren tetapi sangat sulit dilakukan dengan benar di production.

Pertanyaan terbesar adalah apakah kita dapat mempertahankan response time yang sama dengan adanya perubahan topology tersebut. Karena hal ini akan berpengaruh sangat besar terhadap keseluruhan performance dari system yang kita bangun. Hal ini mungkin tidak terlihat jelas jika kita melakukan performance test. Karena dengan performance test kita juga menghidupkan semua sistem pada satu saat dengan precondition yang benar. Tetapi pada kenyataaan ada saja kemungkinan salah satu node down atau system tidak berfungsi dengan baik karena ada failure di network dan sebagainya.

Kita harus melakukan test terhadap hal tersebut di awal-awal, karena hal ini sangat kritikal dan kemungkinan nya besar terjadi di lingkungan production.

Hal yang sangat sering terjadi adalah kita terlambat melakukan performance test dan pada akhirnya kita sadar bahwa performance nya tidak memenuhi karakteristik yang kita inginkan. Jadi solusi yang paling tepat dilakukan karena kita tidak dapat lagi mengubah architecture dan melakukan rewrite. Kita dapat saja membeli machine yang besar dan melakukan deployment semua komponen menjadi monolitik system. Biasanya hal ini dapat menghilangkan cost terhadap network calls dan memberikan solusi terhadap performance.

Untuk mengatasi masalah tersebut lakukanlah performance test secara berkala dan mulai lah dari awal project. Karena hal ini akan memberikan feedback yang baik untuk project anda. Sehingga tidak ada kejutan pada akhir project yang menyebabkan delay ataupun terminate.