Pada pertengahan 2015, Martin Fowler melalui tulisannya berjudul Monolith First, beliau membahas mengenai arsitektur software yang menurutnya seharusnya diawali dengan arsitektur Monolith meskipun yakin aplikasi akan membesar.

Menurutnya ada pola yang terjadi ketika suatu tim software development menggunakan Microservices architectures:

  1. Tim yang sukses menggunakan Microservice aplikasi yang dikembangkan berawal dari Monolith. Aplikasi Monolith tersebut karena terlalu besar akhirnya dipecah - pecah menjadi Microservice.
  2. Sedangkan yang dari awal menggunakan sistem Microservice justru berakhir dengan masalah serius

This pattern has led many of my colleagues to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.

Masih menurut Martin Fowler ada 2 alasan mengapa harus diawali Monolith

  1. Yagni, yang merupakan kependekan dari “You Aren’t Gonna Need It”, adalah mantra dari metodologi ExtremeProgramming. Yang intinya adalah jangan menambahkan fungsionalitas yang belum dibutuhkan saat ini walaupun nantinya menurut prediksi kita bakal dibutuhkan. Hal ini dapat menghindari kompleksitas diawal project.
  2. Microservices membutuhkan batasan yang jelas tugas masing-masing service. Hal ini dikarenakan refactoring pada microservice lebih sulit dilakukan dibandingkan Monolith. Dengan monolith dari awal, lebih mudah menentukan batasan dari aplikasi.

Sedangkan menurut DHH di tulisannya yang berjudul Majestic Monolith, microservices cocok jika skala development sebesar Amazon dan Google.

If you’re Amazon or Google or any other software organization with thousands of developers, it’s a wonderful way to parallelize opportunities for improvement. Each service can be its own team with its own timeline, staff, and objectives. It can evolve independently, at least somewhat, of whatever else the rest of the constellation is doing.

Where things go astray is when people look at, say, Amazon or Google or whoever else might be commanding a fleet of services, and think, hey it works for The Most Successful, I’m sure it’ll work for me too. Bzzzzzzzzt!! Wrong!

The problem with prematurely turning your application into a range of services is chiefly that it violates the #1 rule of distribute computing: Don’t distribute your computing! At least if you can in any way avoid it.

Saya sendiri juga mendapatkan banyak cerita yang sama mengenai bagaimana nasib aplikasi yang sejak awal dibangun menggunakan arsitektur Microservice:

  • Membuat kode aplikasi terlalu kompleks di awal padahal fitur - fitur masih sederhana.
  • Ada pula yang berakhir dengan rewrite karena sulit untuk refactor dan memiliki performance yang buruk

Kapan dan bagaimana beralih dari Monolith?

Menurut Martin Fowler dan berdasarkan yang saya ketahui, mulai beralih dari Monolith biasanya secara bertahap tergantung kebutuhan dan kompleksitas.

Misal, pada suatu aplikasi ada fitur yang memiliki komputasi yang berat sehingga membebani server yaitu menu rekomendasi. Oleh sebab itu menu tersebut di-ekstrak menjadi service tersendiri agar tidak membebani server utama.

Microservice path

Kesimpulan, lebih baik gunakan arsitektur monolith apalagi saat hendak membangun aplikasi baru. Dengan begitu, tidak perlu menambah kompleksitas di awal dan lebih mudah untuk testing serta refactoring.

Run a small team, not a tech behemoth? Embrace the monolith and make it majestic. You Deserve It! - DHH

Gambar oleh Martin Fowler