Solution Architect Cheatsheet — Part 1

Membangun Sistem dengan Pengetahuan dan Cara yang Benar

Menjadi seorang Solution Architect (SA) merupakan salah satu tujuan dalam karir yang ingin dicapai oleh hampir semua software developer. SA merupakan salah satu posisi tertinggi berdasarkan skill kemampuan. Selain memberikan level salary yang di atas rata-rata ,SA juga memiliki tanggung jawab yang lumayan tinggi tidak seperti software engineering biasa.

Untuk menjadi seorang SA, software developer harus memiliki pengetahuan dan pengalaman bagus dan biasanya memerlukan waktu cukup lama sehingga dapat fit dan proper. Berikut adalah hal-hal yang mesti diketahui oleh setiap SA atau setidaknya seorang Senior Software Engineering.

Apa Itu CAP Theorema

Teorema CAP pada komputasi terdistribusi dicetuskan oleh Eric Brewer. Teorema ini menyatakan bahwa tidak mungkin suatu sistem komputer terdistribusi secara bersamaan mencapai atau memenuhi ketiga kondisi Consistency, Availability,dan Partition Tolerance maksimal.

1. Consistency, dicapai apabila kita mendapatkan semua data sama pada setiap node pada waktu yang sama.
2. Availability, jaminan bahwa setiap request menerima tanggapan dari sistem berupa non error sistem.
3. Partition Tolerance, suatu sistem masih dapat bekerja walaupun komunikasi antar node terganggu. Masing-masing node mengetahui terjadi permasalah komunikasi misalkan antara node 1 dan node 2 dan ketika komunikasinya berjalan dengan baik kembali maka data dapat disiskronikasi ulang.

Teorema ini telah menjadi dasar untuk pendekatan komputasi terdistribusi modern. Perusahaan dengan lalu lintas data dan request dengan volume paling tinggi di dunia (misalnya Amazon, Google, Facebook) menggunakannya sebagai dasar untuk memutuskan arsitektur aplikasi mereka.

Penting untuk dipahami bahwa hanya dua dari tiga kondisi ini yang dapat dijamin dipenuhi oleh sistem. Untuk lebih detil bisa dipelajari pada link CAP Theorem.

Asynchronous dan Parallel Programming

Mengapa asynchronous disandingkan dengan parallel? Mengapa tidak membahas asynchronous vs synchronous atau concurrent vs parallel? Disini saya mencoba membandingkannya, karena ada hubungan yang erat antar proses asynchronous dan paralel proses.

Asynchronous adalah proses pengeksekusian kode yang tidak sesuai dengan urutan yang ada atau bisa disebut menjalankan perintah selanjutnya tanpa menunggu perintah sebelumnya selesai.Paralelisme berarti menjalankan banyak hal pada waktu yang sama, secara paralel. Paralelisme berfungsi dengan baik ketika kita dapat memisahkan task menjadi bagian-bagian task yang independen.

Async dan Callback umumnya merupakan cara (alat atau mekanisme) untuk mengekspresikan konkurensi, yaitu sekumpulan entitas yang mungkin berbicara satu sama lain dan berbagi sumber daya.

Ambil contoh rendering frame animasi 3D. Untuk merender animasi biasanya membutuhkan waktu lama. Jadi, jika melakukan proses rendering animasi, kita harus memastikannya berjalan secara asinkron sehingga tidak mengunci UI kita dan selama proses rendering itu juga kita dapat melakukan hal-hal lainnya.

Sekarang, setiap frame dari animasi itu juga dapat dianggap sebagai tugas individual. Jika kita memiliki beberapa CPU / Core atau beberapa mesin yang tersedia, kami dapat membuat beberapa frame secara paralel untuk mempercepat beban kerja secara keseluruhan.

Dengan demikian dapat kita pahami kalau proses asynchronous akan berhubungan erat juga dengan proses paralel.

Apa Itu Scalability

Scalability adalah kemampuan dari sistem, jaringan, software, atau proses untuk dapat menangani jumlah beban request yang terus menerus bertambah. Untuk mendapatkan sistem dengan scalability yang tinggi biasanya dengan cara menambahkan sumber daya (hardware ) lebih banyak dan lebih tinggi.

Proses atau cara penambahan resource hardware ini dapat dilakukan dengan dua cara.

• Scale Up, yaitu cara atau teknik untuk meningkatkan scalability dari sistem dengan cara menambahkan kapasitas dan kualitas hardware. Bisa dengan menambahkan ram, menambahkan media penyimpanan atau mengganti cpu dengan yang lebih tinggi atau lebih bagus. Bisanya cari ini juga disebut sebagai vertical scalability.
• Scale-Out, yaitu cara atau teknik untuk meningkatkan scalability dengan cara menambahkan node. Kita dapat menambahkan mesin dengan kualitas yang sama atau lebih sehingga kita mempunyai banyak mesin yang dapat menangi banyaknya request yang masuk. Biasanya dibutuhkan pembagi beban baik itu load balancing mesin, software, server side atau client side load balancing. Scale out disebut juga sebagai horizontal scalability dan proses scale yang paling disarankan karena sekaligus dapat meningkatkan availability dari sistem kita.

Fahami permasalahan yang Anda hadapi! Apabila untuk satu user sistem Anda berjalan cepat dan responsip, tetapi ketika user bertambah banyak sistem menjadi lambat sekali. Ini adalah permasalahan dari scalability. Apabila untuk satu user saja sistem Anda bejalan lambat, ini menunjukkan terjadi masalah performa pada sistem.

Apa itu Availability

Availability adalah kemampuan sistem untuk tetap dapat menyediakan layanan walaupun salah satu sistem kita down atau tidak dapat memberikan layanan. Umumnya untuk mendapatkan availability minimal harus ada dua node dan kita pasang sebuah load balancer. Akan tetapi, pada sistem komputer untuk menghandle availability rata-rata disarankan jumlah node adalah ganjil guna menghindari terjadinya split brain problem.

Perlu diperhatikan walaupun memiliki makna yang hampir sama tetapi maksud availability di sini agak berbeda dengan makna availability pada CAP Theorem.

Kalau sistem yang Anda miliki sering down ini menunjukkan permasalahan pada Availability dan Stability. Pelajarilah di kedua hal tersebut dan tetaplah tenang. Karena dengan ketenangan Anda dapat membangun kembali sistem yang lebih bagus.

No SQL vs RDBMS

NoSql lebih baik daripada RDBMS karena untuk hal-hal berikut.

• Support terhadap data dengan semi terstruktur bahkan yang tidak terstruktur serta volatil data.
• Tidak memerlukan skema.
• Horizontal scalability dapat di capai dengan mudah.
• Mendukung big data.
• Mendukun tool untuk menganalisa data.
• Dapat di host pada hardware yang murah sekalipun.
• Menyediakan caching pada level memory untuk meningkatkan performance dari query.
• Lebih memberikan balikan yang cepat pada proses development.
• Apalagi jika proses development masih sering terjadi perubahan business proses

RDBSM masih dapat dipandang lebih bagus untuk hal-hal berikut

• Transaksi dengan sifat ACID — Atomicity, Consistency, Isolasi, dan Durability. Akan tetapi, untuk sekarang MongoDB sudah mensupport juga ACID.
• Membutuhkan schema yang pasti ketika terjadi penulisan dan pencarian data.
• Query real time data untuk ukuran data kira-kira masih di bawah 10 Tera,
• Complex query yang melibatkan join dan group by,

Akan tetapi, untuk kondisi sekarang dimana microservice lebih banyak digunakan daripada monolith arsitektur maka disarankan lebih baik menggunakan No SQL daripada RDBMS.

Apa itu Domain-Driven Design

Domain-driven design (DDD) adalah metodologi atau cara proses untuk membuat dan mengembangkan sistem yang kompleks dengan pendekatan fokus untuk memetakan aktivitas, interaksi, tugas, event, dan data dari proses business yang ada.

Solusi domain ini akan kita petakan kepada solusi teknologi yang di tawarkan. Dengan demikian kita dapat membuat model software yang kita buat menjadi semakin mendekati real world process.

Apa itu Prinsip KISS

KISS adalah kependekan dari Keep it simple and stupid. Ini memberikan arahan kepada kita yang bertugas merancang dan membuat sistem harus lebih menguntamkan sistem yang mudah dan tidak kompleks. Apabila kita mendapatkan atau menghadapi sistem yang komplek maka kita harus berusaha membuat menjadi lebih simple.

Konon salah satu cara unutk menyelesaikan satu sistem yang berat adalah dengan cara politik perang Deivede at Impera. Pecah belah lalu seselaikan satu persatu.

Apa itu Prinsip DRY dan DIE

Dalam dunia software engineering jangan lah kita melakukan sesuatu berulang ulang (Don’t Repeat Yourself) karena duplikasi itu adalah bencana. (Duplicate is Evil).

Janganlah kita membuat lagi sesuatu yang sudah ada kecuali apa yang kita buat adalah menyelesaikan sebuah masalah atau meningkatkan performance.

Don’t Reinvent The wheel!!!

Pada artikel selanjutnya kita akan membahas bagian kedua Solution Architect Cheatsheet.