Membela Arsitektur Sederhana (2022)

• Wave adalah perusahaan bernilai $1.7B (2,3 triliun won) dengan 70 engineer (menyediakan layanan mobile banking untuk Afrika)
• Menggunakan arsitektur aplikasi CRUD standar berupa monolit Python berbasis Postgres
• Dengan memulai dari arsitektur sederhana dan memecahkan masalah sambil meminimalkan kompleksitas, engineer dapat fokus pada pekerjaan yang memberi nilai bagi pengguna
• Stackoverflow berhasil tumbuh dengan sukses hingga diakuisisi senilai 1,8 miliar dolar dengan menskalakan satu monolit

Meski arsitektur sederhana efisien, sebagian besar media lebih menyukai arsitektur yang kompleks

• Di konferensi teknologi ada banyak presentasi tentang arsitektur kompleks berbasis microservices, tetapi tidak ada presentasi tentang monolit sederhana
• Banyak perusahaan meniru teknologi kompleks meskipun aplikasinya masih kecil, lalu menjadi populer di konferensi dan HN karenanya
• Arsitektur yang kami gunakan begitu sederhana sehingga bahkan tidak perlu membuat diagram arsitektur

Cara mempertahankan kesederhanaan

• Wave menggunakan Python sinkron, yang berarti proses server akan terblokir saat menunggu I/O
• Mereka sempat mencoba framework asinkron seperti Eventlet, tetapi bug-nya terlalu banyak sehingga biayanya dinilai tidak sepadan dengan penderitaan operasional yang ditimbulkan
• Alih-alih menambah kompleksitas, tugas yang membutuhkan waktu eksekusi panjang dipisahkan ke antrean untuk diproses
• Untuk mematuhi regulasi residensi data, di beberapa negara mereka harus mengoperasikan data center on-premises
  • Senegal/Pantai Gading menggunakan cloud, tetapi Uganda dan negara lain memerlukan on-premises karena regulasi
  • Dalam situasi seperti ini, arsitektur sederhana jauh lebih mudah daripada arsitektur kompleks

Membangun alih-alih membeli

• Karena timnya kecil, pada awalnya mereka lebih memilih membeli software, tetapi ketika bug penting tidak dapat diperbaiki, mereka mengembangkan tool sendiri
• Membangun tool sendiri adalah kompleksitas yang sebenarnya tidak ingin mereka tanggung, tetapi di beberapa kategori produk, bahkan setelah riset yang cukup luas, mereka tidak dapat menemukan vendor yang mampu menyediakan produk yang cocok untuk mereka
• Di luar kompetensi inti pun, kadang perlu mengembangkan tool sendiri dan mempertahankan keahlian internal

Pilihan yang sedang dipertimbangkan ulang

• Mereka sedang meninjau ulang pilihan teknologi seperti RabbitMQ, Celery, SQLAlchemy, dan Python, karena teknologi-teknologi ini menambah kompleksitas atau meningkatkan beban pemeliharaan
• Jika memulai codebase baru, mereka akan mempertimbangkan pilihan teknologi ini dengan hati-hati

Pilihan yang memuaskan

• Mereka puas dengan pilihan seperti GraphQL, protokol transport kustom, dan Kubernetes
• GraphQL memiliki keunggulan seperti dokumentasi mandiri, code generation, dan penjelajah interaktif GraphiQL.
• Mereka menilai kelebihan GraphQL lebih besar daripada kekurangannya
  • Kelebihan
    • Dokumentasi mandiri untuk tipe hasil yang akurat
    • Klien menjadi lebih aman berkat code generation untuk tipe hasil yang akurat
    • Produktivitas meningkat dengan penjelajah interaktif GraphiQL
    • Berbagai aplikasi (aplikasi pengguna, aplikasi dukungan, aplikasi agen Wave, dll.) sebagian besar dapat berbagi satu API sehingga kompleksitas berkurang
    • Dengan bahasa kueri yang dapat dikonfigurasi, klien bisa mengambil data yang dibutuhkan secara tepat dalam satu packet round-trip tanpa perlu membangun banyak endpoint untuk tujuan khusus
    • Menghilangkan bikeshedding tentang apa yang dianggap sebagai RESTful API (membahas hal yang kurang penting secara mendalam dan menghabiskan waktu sambil menunda agenda yang lebih penting)
  • Kekurangan
    • Library GraphQL tidak terlalu bagus pada saat mereka mengadopsi GraphQL
    • Encoding GQL bawaan bersifat redundan, dan karena banyak pelanggan menggunakan bandwidth rendah, mereka sangat memperhatikan batas ukuran
• Kubernetes digunakan untuk memenuhi kebutuhan operasional data center per negara

Kesimpulan

• Dengan menjaga arsitektur aplikasi sesederhana mungkin, mereka bisa mengalokasikan anggaran kompleksitas (dan tenaga kerja) ke area yang kompleksitasnya benar-benar membantu bisnis
• Dengan gagasan untuk melakukan segala sesuatu sesederhana mungkin kecuali ada alasan kuat untuk menambah kompleksitas, mereka dapat membangun bisnis yang cukup besar dengan jumlah engineer yang tidak banyak, meskipun menjalankan bisnis keuangan Afrika yang umumnya dianggap sebagai bisnis yang sulit

[secret3056]

Sepertinya yang tepat adalah "bangun alih-alih beli", bukan "beli alih-alih bangun".

> Another area is with software we’ve had to build (instead of buy).

[xguru]

Ah, saat mau menekankan sesuatu judulnya malah jadi aneh. Sudah saya perbaiki. Terima kasih.

[savvykang]

Apakah tren berubah mengikuti siklus ekonomi? Terlepas dari tren, memulai dengan monolit lebih menguntungkan untuk mengurangi biaya tetap dan mempermudah pemeliharaan.

[aer0700]

Arsitektur yang mudah dipahami juga lebih mudah dirawat.

[mhj5730]

Menurut saya, untuk layanan apa pun, sebaiknya mulai dengan monolitik. Kalau sejak awal langsung menetapkan MSA, itu cuma buang-buang uang.

[dhlee0305]

"Ketika kompleksitas meningkat, biaya (uang, orang, waktu...) juga meningkat"
"Jangan mencoba menyelesaikan masalah yang bisa diatasi dengan arsitektur sederhana menggunakan arsitektur yang rumit."

[xguru]

Opini Hacker News

• Saran engineer tentang microservices

  • Microservices bukan strategi peningkatan performa, melainkan strategi pengurangan biaya potensial dan strategi koordinasi engineering.
  • Tidak ada perbedaan besar antara aplikasi monolitik yang dapat diskalakan secara horizontal dan microservices, kecuali ketika ingin mengecilkan fungsi tertentu.
  • Dalam aplikasi monolitik, mustahil mengecilkan hanya sebagian aplikasi.
  • Penghematan biaya mulai terasa pada skala besar, dan membutuhkan setidaknya 3 replika.
  • Bagi sebagian besar perusahaan, manfaat nyata ada pada koordinasi engineering.
  • Dalam monolitik dengan satu repository, satu tim dapat memiliki dan mengelolanya, tetapi dalam monolitik bersama, tidak ada yang benar-benar memilikinya sehingga sulit dikelola.

• Ceramah tentang microservices

  • Di konferensi teknologi umum, ada beberapa presentasi tentang kompleksitas dan efek samping arsitektur microservices, tetapi tidak ada presentasi tentang membangun monolitik yang sederhana.
  • Ceramah David Schmitz yang membahas kiat tentang kegagalan microservices sangat mengesankan, dan gaya presentasinya yang humoris sangat menarik.

• Bias kognitif dan kesederhanaan

  • Orang sering berfokus pada menambahkan sesuatu dan mengabaikan solusi yang sederhana.
  • Penelitian menunjukkan bahwa memecahkan masalah dengan menghapus balok, alih-alih menambahkannya pada struktur LEGO, adalah solusi yang lebih baik.

• Overengineering dan kurangnya pengalaman

  • Arsitektur harus "cukup sederhana namun cukup kompleks sesuai kebutuhan", tetapi untuk mencapainya dibutuhkan pengalaman.
  • Industri TI cenderung kekurangan pengalaman, dan pengalaman membutuhkan waktu.
  • Engineer dan manajer yang kurang berpengalaman sering menggunakan teknologi atau metrik yang tidak perlu.

• Perusahaan yang menghargai keseimbangan kerja dan hidup

  • Sedang mencari perusahaan yang ingin fokus pada peningkatan produk dan mengalokasikan sisa waktunya untuk kehidupan pribadi.

• Pengalaman pribadi tentang Dan Luu

  • Dan Luu sangat murah hati dalam berinteraksi dengan penggemar blognya dan memiliki keahlian tentang batas antara software dan hardware.
  • Ia sangat dermawan dalam membagikan wawasan dan keahliannya, dan belajar darinya adalah pengalaman yang sangat menyenangkan.

• Pentingnya arsitektur yang sederhana

  • Dalam kebanyakan kasus, arsitektur yang dibutuhkan adalah komponen dasar seperti load balancer dengan dukungan SSL, beberapa app server, database yang di-shard, message queue, dan sebagainya.

• Arsitektur dan struktur sosial tim engineering

  • Arsitektur harus mencerminkan struktur sosial tim engineering, dan jika ini tidak dipertimbangkan, dapat timbul kekacauan dan inefisiensi.
  • Repository monolitik berskala besar dan arsitektur sederhana bisa sulit dikelola, dan perusahaan seperti Google dan Meta juga mengembangkan banyak tool secara internal.
  • Arsitektur dapat mendukung atau menghambat kolaborasi antar tim, sehingga kepemimpinan teknis harus mempertimbangkan hal ini.

• Preferensi terhadap arsitektur sederhana

  • Arsitektur sederhana dan monolitik cocok untuk sebagian besar kasus, tetapi perlu berhati-hati agar tidak muncul masalah akibat I/O sinkron.
  • Bug integritas data adalah masalah penting yang harus dihindari dalam sistem keuangan.

[dangyup]

Bolehkah saya meminta tautan ke presentasi yang membahas tips David Schmitz tentang kegagalan microservices.

[xguru]

https://www.youtube.com/watch?v=r8mtXJh3hzM adalah