BAB V Kesimpulan dan Saran
5.2. Saran
Berdasarkan hasil pengujian dan pengukuran yang dilakukan pada penelitian ini, untuk mendapatkan hasil yang lebih baik maka peneliti menyarankan:
1) Penambahan parameter pengujian seperti Disk I/O, Disk space , application error rate dll.
2) Melakukan pengukuran untuk parameter kinerja Komputer dalam keadaan idle.
3) Penambahan perlakuan pengujian seperti endurance test atau stress test.
4) Penggunaan resource sungguhan pada prototipe sistem seperti penggunaan MySQL, Redis, RabbitMQ dll .
5) Menggunakan Framework RPC dengan binary protocol lainnya seperti ProtoBuff
6) Menggunakan arsitektur microservice yang lebih lebih besar, dalam hal jumlah servis didalamnya.
54 Daftar Pustaka
Aigner, M., & Baumgartner, A. (2010). Google Go!. Retrieved September 03, 2016, from http://go-lang.cat-v.org/talks/slides/seminar-aus-informatik- aigner-baumgartner.pdf
Babović, J., Raičević, V., & Carić, M. (2012). Benchmarking as a function of competitiveness and efficiency in business. Econ Agric, 59, 115-126.
Birrell, A. D., & Nelson, B. J. (1983). Implementing Remote procedure calls.
ACM SIGOPS Operating Systems Review SIGOPS Oper. Syst. Rev., 17(5), 3. doi:10.1145/773379.806609
Boettiger, C. (2015). An introduction to Docker for reproducible research. ACM SIGOPS Operating Systems Review SIGOPS Oper. Syst. Rev., 49(1), 71- 79. doi:10.1145/2723872.2723882
Bui, T. (2015). Analysis of docker security. arXiv preprint arXiv:1501.02967.
Clark, K. L., & McCabe, F. G. (2004). Go!—a multi-paradigm programming language for implementing multi-threaded agents. Annals of Mathematics and Artificial Intelligence, 41(2-4), 171-206.
Datadog, Inc. (n.d.). Getting Started with the Agent. Retrieved September 03, 2016, from http://docs.datadoghq.com/guides/basic_agent_usage/
Elmuti, D., & Kathawala, Y. (1997). An overview of benchmarking process: A tool for continuous improvement and competitive advantage.
Benchmarking Qual Mgmt & Tech Benchmarking for Quality Management & Technology, 4(4), 229-243.
doi:10.1108/14635779710195087
Flanagan, D., & Matsumoto, Y. (2008). The Ruby programming language.
Beijing: O'Reilly.
Florent Bruneau (2013). Memory – Part 2: Understanding Process memory.
Retrieved September 03, 2016, from
https://techtalk.intersec.com/2013/07/memory-part-2-understanding- process-memory/.
Halili, E. H. (2008). Apache JMeter: A practical beginner's guide to automated testing and performance measurement for your websites. Birmingham: Packt Pub.
Hussain, S., Wang, Z., Toure, I. K., & Diop, A. (2013). Web service testing tools: A comparative study. arXiv preprint arXiv:1306.4063.
Ian Molyneaux (2009). The Art of Application Performance Testing. Auckland:
O'Reilly Media.
55 Jeff Atwood (2008). Understanding User and Kernel Mode. Retrieved September
03, 2016, from https://blog.codinghorror.com/understanding-user-and- kernel-mode.
Kamburugamuve, S., Fox, G., Leake, D., & Qiu, J. (2013). Survey of Apache Big Data Stack (Doctoral dissertation, Ph. D. Qualifying Exam, Dept. Inf.
Comput., Indiana Univ., Bloomington, IN).
Lenz, P. (2008). Simply Rails 2. SitePoint.
Massé, M. (2012). REST API design rulebook. Sebastopol, CA: O'Reilly.
Matthias, K., & Kane, S. P. (2015). Docker: Up and running. Sebastopol, CA:
O’Reilly
Meade, P. (1998). A guide to benchmarking. Dunedin, N.Z.: University of Otago.
Nevedrov, D. (2006). Using JMeter to Performance Test Web Services.Published on dev2dev (http://dev2dev. bea. com/).
Slee, M., Agarwal, A., & Kwiatkowski, M. (2007). Thrift: Scalable Crosslanguage Services Implementation.
Tate, B. (2006). From Java to Ruby: Things every manager should know. Raleigh, NC: Pragmatic Bookshelf.
Thomas, D., & Hunt, A. (2001). Programming in Ruby. Dr. Dobb’s Journal, 5.
Tilkov, S., & Vinoski, S. (2010). Node.js: Using JavaScript to Build High-
Performance Network Programs. IEEE Internet Computing, 14(6), 80-83.
doi:10.1109/mic.2010.145
Turnbull, J. (2014). The Docker book. James Turnbull.
Watson, G. H. (1993). Strategic benchmarking: How to rate your company's performance against the world's best. New York: J. Wiley and Sons
56
Lampiran A
Surat Keterangan Bimbingan
Skripsi
57
58
Lampiran B
Hasil Wawancara
59 Narasumber : John Doe (Nama Alias)
Jabatan : Software Engineer Tanggal : 24 Februari 2016
Tempat : Ruang Meeting 1 PT. XYZ
Tujuan : Mengetahui Arsitektur sistem didalam PT. XYZ dan aspek apa yang bisa diimprovisasi didalamnya.
Pertanyaan 1 : Arsitektur sistem apa yang di terapkan didalam keseluruhan sistem PT. XYZ ?
Jawaban 1 : Sebenarnya secara desain pertama sejak awal perusahaan ini dibangun oleh CEO kita, nggak pernah ada omongan kalau kita pakai arsitektur A, B atau C, kita jalan aja dengan kerangka dasar sistem yang sudah ada. namun seiring berjalanya waktu, sistem kami terus berevolusi menyesuaikan dengan terapan teknologi yang terus berkembang sampai pada akhirnya keadaan sistem kami saat ini yang biasanya disebut dengan arsitektur microservice.
Pertanyaan 2 : Mengapa arsitektur tersebut cocok bagi organisasi anda ?
Jawaban 2 : Kalau dibilang cocok, saya hanya mau tegaskan, saat ini kami cocok dengan arsitektur ini, tapi bukan berarti kami akan terus implement arsitektur ini tanpa
60 mempertimbangkan perkembangan teknologi di kemudian hari. kalau mengapa cocok saat ini?, hmmm ... mungkin karena kebutuhan bisnis yang sangat cepat, yang mana kadang kala dalam hal bisnis kita butuh experimen. karena hal itu kami butuh sistem yang dapat mudah menerapkan eksperimen tersebut. untuk dapat membuat yang seperti itu, kami perlu membagi atau memecah domain-domain masalah menjadi lebih kecil, semakin kecil domain masalahnya semakin kecil solusinya, semakin kecil effort nya dan semakin kecil pula juga resikonya terhadap keseluruhan sistem.
disamping itu dengan microservice kita tidak terikat dengan satu stack ataupun bahasa pemrograman, kita bisa pilih bahasa pemrograman atau stack apa saja yang paling sesuai untuk menjadi solusi bagi domain masalah tersebut. ditambah semakin polyglot kita semakin mudah kami merekrut talent, karena kami menerima banyak bahasa pemrograman hahaha.
Pertanyaan 3 : Keuntungan apa yang ada dapatan dengan mengimplementasikan arsitektur microservice yang tidak di dapat dari arsitektur lainya?
Jawaban 3 : Seperti yang saya jelaskan barusan, untuk hal yang lebih technical lagi, dengan arsitektur microservice
61 karena yang nature sifatnya memecahkan domain masalah menjadi lebih kecil, maka dengan automatis semakin kecil juga scope masalah yang harus kita perbaiki ketika terjadi incident dalam sistem kita.
perumpamaan saja sebuah mesin motor, kalau saja mesin motor itu tidak modular semisal fungsi piston dan karburator itu terdapat dalam satu modul katakan saja modul A, maka apabila karburator tidak berfungsi dengan baik maka yang akan kita perbaiki adalah si modul A. memperbaiki modul A dengan tujuan membuat karburator kembali berfungsi dengan baik kita harus tetap memperhatikan fungsi piston juga, karena fungsi pisto dan karburator dalam contoh ini berada dalam satu modul yang saling terikat. untungnya di dunia nyata tidak begitu, karburator dan piston adalah modul yang terpisah yang bisa kita optimalkan masing-masing, menurut saya itulah microservice dalam contoh sehari-hari.
Pertanyaan 4 : Menurut anda adakah kelemahan dari arsitektur ini ?
Jawaban 4 : No rose without thorn, media komunikasi salah satunya, karena setiap service dalam arsitektur ini saling berkomunikasi antar service lainya, dimana
62 hampir semua pasti berkomunikasi over network, dan ketika kita bicara soal network ada latency dan lain sebagainya. sebagus atau seoptimal apapun sevice yang dibuat akan tetap underperform secara the whole system apabila komunikasinya tidak optimal. dan disini kami umumnya dan bisanya memilih HTTP untuk media komunikasi antar sevice dengan pendekatan REST API
Pertanyaan 5 : Mengapa HTTP dengan REST API menjadi pilihan populer sebagai media komunikasi dalam sistem yang organisasi anda kembangkan ?
Jawaban 5 : karena konsep HTTP adalah konsep paling umum dan dasar menurut saya ya. semua backend engineer pasti tau bagaimana konsep HTTP, karena ini diterapkan dimana-mana kan, di browser, mobile dan lain sebagainya.
Pertanyaan 6 : Menurut anda apa yang bisa di maximalkan dari arsitektur sistem yang organisasi anda kembangkan
?
Jawaban 6 : Pastinya media komunikasi, semakin optimal performa media komunikasinya sudah pasti otomatis semakin optimal sistem kita perform secara keseluruhan. sebagai contoh HTTP, sesuai namanya HyperText Transfer
63 Protocol. media ini menggunakan format text yang mana secara ukuran paket data dalam network lebih besar jika dibandingkan dengan protocol dengan format lain, semisal Apache Thrift dengan binary protocol- nya.
Pertanyaan 7 : Parameter apa saja yang bisa dijadikan ukuran untuk sebuah media komunikasi dalam arsitektur sistem yang organisasi and kembangkan ?
Jawaban 7 : Hmm ... pertanyaan bagus. pastinya harus cepat, untuk cepat pastinya harus memiliki ukuran packet data over network yang kecil, low CPU dan memory usage, dan pastinya meningkatkan response time secara keseluruhan sistem dan juga semakin banyak jumlah transaksi dalam satu detik yang dapat diprosess sistem secara bersamaan atau kami biasa sebut TPS (transacion per second).
64
Lampiran C
Hasil Pengamatan Eksperimen
65
66 Lampiran JMeter – Response Time untuk 10 Concurrency
Lampiran JMeter – Throughtput untuk 10 Concurrency
67 Lampiran JMeter – Response Time untuk 20 Concurrency
Lampiran JMeter – Throughtput untuk 20 Concurrency
68 Lampiran JMeter – Response Time untuk 40 Concurrency
Lampiran JMeter – Throughtput untuk 40 Concurrency
69 Lampiran JMeter – Response Time untuk 60 Concurrency
Lampiran JMeter – Throughtput untuk 60 Concurrency
70 Lampiran JMeter – Response Time untuk 80 Concurrency
Lampiran JMeter – Throughtput untuk 80 Concurrency
71 Lampiran JMeter – Response Time untuk 100 Concurrency
Lampiran JMeter – Throughtput untuk 100 Concurrency
72 Lampiran JMeter – Response Time untuk 120 Concurrency
Lampiran JMeter – Throughtput untuk 120 Concurrency
73 Lampiran JMeter – Response Time untuk 140 Concurrency
Lampiran JMeter – Throughtput untuk 140 Concurrency
74 Lampiran JMeter – Response Time untuk 160 Concurrency
Lampiran JMeter – Throughtput untuk 160 Concurrency
75 Lampiran JMeter – Response Time untuk 180 Concurrency
Lampiran JMeter – Throughtput untuk 180 Concurrency