Tentang apa semua ini?  Setiap hari, setiap saat selama karier teknik kami, kami menghadapi banyak masalah dengan berbagai kompleksitas dan situasi yang mengharuskan kami mengambil keputusan atau menundanya karena kurangnya data. Setiap kali kami membangun layanan baru, membangun infrastruktur, atau bahkan membentuk proses pengembangan, kami menghadapi berbagai tantangan yang sangat besar.  Sulit, dan mungkin bahkan mustahil, untuk mencantumkan semua masalah. Anda akan menemui beberapa masalah ini hanya jika Anda bekerja di bidang tertentu. Di sisi lain, ada banyak masalah yang harus kita semua pahami cara penyelesaiannya, karena masalah-masalah tersebut sangat penting dalam membangun sistem TI. Dengan kemungkinan besar, Anda akan menemuinya di semua proyek.  Dalam artikel ini, saya akan berbagi pengalaman saya dengan beberapa masalah yang saya temui saat membuat program perangkat lunak.  Apa itu Kepedulian Lintas Sektor?  Jika kita melihat di Wikipedia, kita akan menemukan definisi berikut  Dalam pengembangan perangkat lunak berorientasi aspek, masalah lintas sektor adalah aspek program yang memengaruhi beberapa modul, tanpa kemungkinan dirangkum dalam salah satu modul. Masalah ini sering kali tidak dapat dipisahkan dengan jelas dari sistem lainnya baik dalam desain maupun implementasi, dan dapat mengakibatkan penyebaran (duplikasi kode), kekusutan (ketergantungan signifikan antar sistem), atau keduanya.  Ini menggambarkan dengan jelas apa itu, tetapi saya ingin memperluas dan menyederhanakannya sedikit:    merupakan suatu konsep atau komponen sistem/organisasi yang mempengaruhi (atau 'melintasi') banyak bagian lainnya. Keprihatinan lintas sektor  Contoh terbaik dari masalah tersebut adalah arsitektur sistem, pencatatan, keamanan, manajemen transaksi, telemetri, desain basis data, dan masih banyak lagi. Kami akan menguraikan banyak di antaranya nanti dalam artikel ini.  Pada level kode, masalah lintas sektor sering kali diimplementasikan menggunakan teknik seperti   , di mana masalah-masalah ini dimodularisasi menjadi komponen-komponen terpisah yang dapat diterapkan di seluruh aplikasi. Hal ini menjaga logika bisnis tetap terisolasi dari masalah-masalah ini, sehingga kode menjadi lebih mudah dibaca dan dipelihara. Aspect-Oriented Programming (AOP)  Klasifikasi Aspek  Ada banyak cara yang memungkinkan untuk mengklasifikasikan aspek dengan mengelompokkannya berdasarkan properti yang berbeda seperti cakupan, ukuran, fungsionalitas, kepentingan, target, dan lain-lain, tetapi dalam artikel ini, saya akan menggunakan klasifikasi cakupan yang sederhana. Yang saya maksud dengan ini adalah ke mana aspek spesifik ini diarahkan, apakah itu keseluruhan organisasi, sistem tertentu, atau elemen tertentu dari sistem tersebut.  Jadi, saya akan membagi aspek menjadi   dan   . Makro Mikro  Yang saya maksud dengan aspek   adalah pertimbangan-pertimbangan yang kita terapkan pada keseluruhan sistem, seperti arsitektur sistem yang dipilih dan desainnya (monolitik, layanan mikro, arsitektur berorientasi layanan), tumpukan teknologi, struktur organisasi, dsb. Aspek   terutama terkait dengan keputusan-keputusan strategis dan tingkat tinggi. Makro makro  Sementara itu, aspek   lebih dekat dengan level kode dan pengembangan. Misalnya, kerangka kerja mana yang digunakan untuk berinteraksi dengan basis data, struktur folder dan kelas proyek, atau bahkan pola desain objek tertentu. Mikro  Meskipun klasifikasi ini tidak ideal, klasifikasi ini membantu menyusun pemahaman tentang kemungkinan masalah dan pentingnya serta dampak solusi yang kita terapkan pada masalah tersebut.  Dalam artikel ini, fokus utama saya akan tertuju pada aspek makro.  Aspek Makro  Struktur organisasi  Ketika saya baru mulai belajar tentang arsitektur perangkat lunak, saya membaca banyak artikel menarik tentang hukum Conway dan dampaknya terhadap struktur organisasi. Terutama   . Jadi, hukum ini menyatakan bahwa yang satu ini  Setiap organisasi yang merancang suatu sistem (didefinisikan secara luas) akan menghasilkan desain yang strukturnya merupakan salinan dari struktur komunikasi organisasi.  Saya selalu percaya bahwa konsep ini memang sangat universal dan mewakili Aturan Emas.  Kemudian saya mulai mempelajari pendekatan Domain-Driven Design (DDD) milik Eric Evans untuk memodelkan sistem. Eric Evans menekankan pentingnya identifikasi Konteks Terbatas. Konsep ini melibatkan pembagian model domain yang kompleks menjadi beberapa bagian yang lebih kecil dan lebih mudah dikelola, yang masing-masing memiliki pengetahuan yang terbatas. Pendekatan ini membantu komunikasi tim yang efektif, karena mengurangi kebutuhan akan pengetahuan yang luas tentang seluruh domain dan meminimalkan peralihan konteks, sehingga membuat percakapan menjadi lebih efisien. Peralihan konteks adalah hal terburuk dan paling menghabiskan sumber daya. Bahkan komputer pun kesulitan mengatasinya. Meskipun tidak mungkin mencapai ketiadaan peralihan konteks sepenuhnya, saya rasa itulah yang harus kita perjuangkan.   Kembali ke Hukum Conway, saya menemukan beberapa masalah dengannya.    yang saya temui dengan Hukum Conway, yang menyatakan bahwa desain sistem mencerminkan struktur organisasi, adalah potensi untuk membentuk Konteks Terbatas yang kompleks dan komprehensif. Kompleksitas ini muncul ketika struktur organisasi tidak selaras dengan batasan domain, yang mengarah ke Konteks Terbatas yang sangat saling bergantung dan sarat dengan informasi. Hal ini menyebabkan seringnya terjadi pergantian konteks bagi tim pengembangan. Masalah pertama    adalah bahwa terminologi organisasi bocor ke tingkat kode. Ketika struktur organisasi berubah, hal itu memerlukan modifikasi basis kode, yang menghabiskan sumber daya yang berharga. Masalah lainnya  Dengan demikian, mengikuti   membantu membangun sistem dan organisasi yang mendukung arsitektur perangkat lunak yang diinginkan. Akan tetapi, perlu dicatat bahwa pendekatan ini tidak akan bekerja dengan baik dalam arsitektur dan struktur yang sudah terbentuk karena perubahan pada tahap ini bersifat jangka panjang, tetapi sangat efektif dalam perusahaan rintisan karena mereka cepat dalam memperkenalkan perubahan apa pun. Inverse Conway Maneuver  Bola Lumpur Besar  Pola atau "anti-pola" ini mendorong pembangunan sistem tanpa arsitektur apa pun. Tidak ada aturan, tidak ada batasan, dan tidak ada strategi tentang cara mengendalikan kompleksitas yang tak terelakkan. Kompleksitas adalah musuh yang paling tangguh dalam perjalanan membangun sistem perangkat lunak.   Untuk menghindari pembangunan sistem jenis seperti itu, kita perlu mengikuti aturan dan batasan khusus.  Arsitektur sistem  Ada banyak sekali definisi untuk Arsitektur Perangkat Lunak. Saya menyukai banyak definisi karena mencakup berbagai aspeknya. Akan tetapi, untuk dapat bernalar tentang arsitektur, kita perlu secara alami membentuk beberapa definisi di dalam pikiran kita. Dan perlu dicatat bahwa definisi ini dapat berkembang. Jadi, setidaknya untuk saat ini, saya memiliki deskripsi berikut untuk diri saya sendiri.    adalah tentang keputusan dan pilihan yang Anda buat setiap hari yang memengaruhi sistem yang dibangun. Arsitektur Perangkat Lunak  Untuk membuat keputusan, Anda perlu memiliki prinsip dan pola dalam "tas" Anda untuk memecahkan masalah yang timbul, penting juga untuk menyatakan bahwa memahami persyaratan adalah kunci untuk membangun apa yang dibutuhkan bisnis. Namun, terkadang persyaratan tidak transparan atau bahkan tidak didefinisikan, dalam hal ini, lebih baik menunggu untuk mendapatkan klarifikasi lebih lanjut atau mengandalkan pengalaman Anda dan memercayai intuisi Anda. Namun, bagaimanapun, Anda tidak dapat membuat keputusan dengan benar jika Anda tidak memiliki prinsip dan pola untuk diandalkan. Di situlah saya sampai pada definisi  Gaya Arsitektur Perangkat Lunak.    adalah serangkaian prinsip dan pola yang menentukan cara membangun perangkat lunak. Gaya Arsitektur Perangkat Lunak  Ada banyak gaya arsitektur berbeda yang difokuskan pada berbagai sisi arsitektur yang direncanakan, dan menerapkan beberapa di antaranya sekaligus adalah situasi yang normal.  Misalnya saja seperti:  Arsitektur monolitik  Desain berbasis domain  Berbasis komponen  Layanan mikro  Pipa dan filter  Berbasis pada peristiwa  Mikrokernel  Berorientasi pada layanan  dan sebagainya…  Tentu saja, mereka memiliki kelebihan dan kekurangan, tetapi hal terpenting yang saya pelajari adalah bahwa arsitektur berevolusi secara bertahap sambil bergantung pada masalah aktual. Memulai dengan arsitektur monolitik adalah pilihan yang bagus untuk mengurangi kompleksitas operasional, kemungkinan besar arsitektur ini akan sesuai dengan kebutuhan Anda bahkan setelah mencapai tahap Product-market Fit (PMI) dalam membangun produk. Dalam skala besar, Anda dapat mempertimbangkan untuk beralih ke pendekatan berbasis peristiwa dan layanan mikro untuk mencapai penerapan independen, lingkungan tumpukan teknologi heterogen, dan arsitektur yang kurang terhubung (dan kurang transparan untuk sementara waktu karena sifat pendekatan berbasis peristiwa dan pub-sub jika ini diadopsi). Kesederhanaan dan efisiensi dekat dan memiliki dampak besar satu sama lain. Biasanya, arsitektur yang rumit memengaruhi kecepatan pengembangan fitur baru, mendukung dan memelihara yang sudah ada, dan menantang evolusi alami sistem.  Akan tetapi, sistem yang kompleks sering kali memerlukan arsitektur yang kompleks dan komprehensif, yang tidak dapat dihindari.  Ini adalah topik yang sangat luas, dan ada banyak ide hebat tentang cara menyusun dan membangun sistem untuk evolusi alami.  Berdasarkan pengalaman saya, saya telah menyusun pendekatan berikut:  Hampir selalu dimulai dengan gaya arsitektur monolitik karena menghilangkan sebagian besar masalah yang timbul karena sifat sistem terdistribusi. Mengikuti monolit modular juga masuk akal untuk fokus membangun komponen dengan batasan yang jelas. Menerapkan pendekatan berbasis komponen dapat membantu mereka berkomunikasi satu sama lain dengan menggunakan peristiwa, tetapi memiliki panggilan langsung (alias RPC) menyederhanakan banyak hal di awal. Namun, penting untuk melacak ketergantungan antar komponen karena jika komponen A mengetahui banyak tentang komponen B, mungkin masuk akal untuk menggabungkannya menjadi satu.  Saat Anda mendekati situasi saat Anda perlu meningkatkan skala pengembangan dan sistem Anda, Anda dapat mempertimbangkan untuk mengikuti pola   untuk secara bertahap mengekstrak komponen yang perlu diterapkan secara independen atau bahkan ditingkatkan dengan persyaratan tertentu. Stangler  Sekarang, jika Anda memiliki visi yang jelas tentang masa depan, yang merupakan sedikit keberuntungan yang luar biasa, Anda dapat memutuskan arsitektur yang diinginkan. Saat ini, Anda dapat memutuskan untuk beralih ke arsitektur layanan mikro dengan juga menerapkan pendekatan Orkestrasi dan Koreografi, menggabungkan pola CQRS untuk operasi penulisan dan pembacaan skala independen, atau bahkan memutuskan untuk tetap menggunakan arsitektur monolitik jika sesuai dengan kebutuhan Anda.  Penting juga untuk memahami angka dan metrik seperti   (Pengguna Aktif Harian),   (Pengguna Aktif Bulanan),   (Permintaan Per Detik), dan   (Transaksi Per Detik) karena ini dapat membantu Anda membuat pilihan karena arsitektur untuk 100 pengguna aktif dan 100 juta pengguna aktif berbeda. DAU MAU RPC TPC  Sebagai catatan akhir, saya akan mengatakan bahwa arsitektur memiliki dampak yang signifikan terhadap keberhasilan produk. Arsitektur yang dirancang dengan buruk untuk produk diperlukan dalam penskalaan, yang kemungkinan besar mengarah pada kegagalan karena pelanggan tidak akan menunggu saat Anda menskalakan sistem, mereka akan memilih pesaing, jadi kita harus berada di depan potensi penskalaan.   Di sisi lain, memiliki sistem yang sangat rumit dan sudah diskalakan tanpa pelanggan atau rencana untuk mendapatkan banyak pelanggan akan menghabiskan uang Anda untuk bisnis Anda tanpa hasil. Meskipun saya akui bahwa terkadang itu bukan pendekatan yang ramping, idenya adalah memiliki sistem yang dapat diskalakan tetapi belum diskalakan.  Pemilihan tumpukan teknologi  Memilih tumpukan teknologi juga merupakan keputusan tingkat makro karena memengaruhi perekrutan, perspektif evolusi alami sistem, skalabilitas, dan kinerja sistem.  Berikut adalah daftar pertimbangan dasar untuk memilih tumpukan teknologi:    Misalnya, aplikasi web sederhana dapat dibangun dengan kerangka kerja Blazor jika pengembang Anda memiliki pengalaman dengannya, tetapi karena kurangnya kematangan WebAssembly, memilih React dan TypeScript untuk kesuksesan jangka panjang bisa menjadi keputusan yang lebih baik. Persyaratan dan kompleksitas proyek.    Jika Anda mengantisipasi menerima sejumlah besar lalu lintas, memilih ASP.NET Core daripada Django bisa menjadi pilihan yang bijak karena kinerjanya yang unggul dalam menangani permintaan bersamaan. Namun, keputusan ini bergantung pada skala lalu lintas yang Anda harapkan. Jika Anda perlu mengelola miliaran permintaan dengan latensi rendah, kehadiran Garbage Collection bisa menjadi tantangan. Skalabilitas dan Kebutuhan Performa.    Dalam kebanyakan kasus, faktor-faktor inilah yang perlu kita perhatikan. Waktu untuk memasarkan, Biaya pemeliharaan, dan Stabilitas perekrutan mendorong kebutuhan bisnis Anda tanpa hambatan. Perekrutan, Waktu Pengembangan, dan Biaya.    Keahlian tim pengembangan Anda merupakan faktor yang krusial. Umumnya lebih efektif untuk menggunakan teknologi yang sudah familier bagi tim Anda kecuali ada alasan kuat untuk berinvestasi dalam mempelajari tumpukan baru. Keahlian dan Sumber Daya Tim.    Komunitas yang kuat dan ekosistem pustaka serta perangkat yang lengkap dapat sangat memudahkan proses pengembangan. Teknologi populer sering kali memiliki dukungan komunitas yang lebih baik, yang dapat sangat berharga untuk memecahkan masalah dan menemukan sumber daya. Dengan demikian, Anda dapat menghemat sumber daya dan berfokus terutama pada produk. Kematangan.    Pertimbangkan keberlangsungan teknologi dalam jangka panjang. Teknologi yang diadopsi dan didukung secara luas cenderung tidak akan usang dan umumnya menerima pembaruan dan perbaikan secara berkala. Pemeliharaan dan Dukungan Jangka Panjang.   Bagaimana memiliki berbagai tumpukan teknologi dapat memengaruhi pertumbuhan bisnis?  Dari satu perspektif, memperkenalkan satu tumpukan lagi dapat meningkatkan skala perekrutan Anda, tetapi di sisi lain, hal itu akan menimbulkan biaya pemeliharaan tambahan karena Anda perlu mendukung kedua tumpukan tersebut. Jadi, seperti yang saya katakan sebelumnya, menurut sudut pandang saya, hanya kebutuhan tambahan yang seharusnya menjadi argumen untuk menggabungkan lebih banyak tumpukan teknologi.   Tetapi bagaimana dengan prinsip pemilihan alat terbaik untuk masalah tertentu?  Terkadang Anda tidak punya pilihan lain selain menghadirkan alat baru untuk memecahkan masalah tertentu berdasarkan pertimbangan yang sama yang disebutkan di atas, dalam kasus seperti itu, masuk akal untuk memilih solusi terbaik.  Penciptaan sistem tanpa keterkaitan yang tinggi dengan teknologi tertentu bisa menjadi tantangan. Namun, akan sangat membantu jika kita mengupayakan kondisi di mana sistem tidak terlalu erat kaitannya dengan teknologi, dan sistem tidak akan mati jika besok, kerangka kerja atau alat tertentu menjadi rentan atau bahkan tidak digunakan lagi.  Pertimbangan penting lainnya terkait dengan ketergantungan perangkat lunak sumber terbuka dan perangkat lunak berpemilik. Perangkat lunak berpemilik memberi Anda lebih sedikit fleksibilitas dan kemungkinan untuk disesuaikan. Namun, faktor yang paling berbahaya adalah ketergantungan pada vendor, di mana Anda menjadi tergantung pada produk, harga, ketentuan, dan peta jalan vendor. Ini bisa berisiko jika vendor mengubah arah, menaikkan harga, atau menghentikan produk.   Menghilangkan satu titik kegagalan di semua level adalah kunci untuk membangun sistem yang andal untuk pertumbuhan. Perangkat lunak sumber terbuka mengurangi risiko ini, karena satu entitas tidak mengendalikannya.  Titik Kegagalan Tunggal (SPOF)  Titik kegagalan tunggal (SPOF) merujuk pada setiap bagian dari sistem yang, jika gagal, akan menyebabkan seluruh sistem berhenti berfungsi. Menghilangkan SPOF di semua tingkatan sangat penting untuk sistem apa pun yang membutuhkan ketersediaan tinggi. Segala hal, termasuk pengetahuan, personel, komponen sistem, penyedia cloud, dan kabel internet, dapat gagal.  Ada beberapa teknik dasar yang bisa kita terapkan untuk menghilangkan titik kegagalan tunggal:    Terapkan redundansi untuk komponen-komponen penting. Ini berarti memiliki komponen cadangan yang dapat mengambil alih jika komponen utama gagal. Redundansi dapat diterapkan di berbagai lapisan sistem, termasuk perangkat keras (server, disk), jaringan (tautan, sakelar), dan perangkat lunak (basis data, server aplikasi). Jika Anda menghosting semuanya di satu Penyedia Cloud dan bahkan memiliki cadangan di sana, pertimbangkan untuk membuat cadangan tambahan secara berkala di penyedia lain untuk mengurangi biaya yang hilang jika terjadi bencana. Redundansi.    Distribusikan sistem Anda ke beberapa lokasi fisik, seperti pusat data atau wilayah cloud. Pendekatan ini melindungi sistem Anda dari kegagalan di lokasi tertentu seperti pemadaman listrik atau bencana alam. Pusat Data.    Terapkan pendekatan failover untuk semua komponen Anda (DNS, CDN, Load balancer, Kubernetes, API Gateway, dan Database). Karena masalah dapat muncul secara tiba-tiba, penting untuk memiliki rencana cadangan guna mengganti komponen apa pun dengan klonnya sesuai kebutuhan dengan cepat. Failover.    Pastikan layanan Anda dibangun agar dapat diskalakan secara horizontal dan memiliki ketersediaan tinggi sejak awal dengan mematuhi prinsip-prinsip berikut: Layanan dengan ketersediaan tinggi.  Terapkan statelessness layanan dan hindari menyimpan sesi pengguna dalam cache dalam memori. Sebaliknya, gunakan sistem cache terdistribusi, seperti Redis.  Hindari ketergantungan pada urutan kronologis konsumsi pesan saat mengembangkan logika.  Minimalkan perubahan yang merusak untuk mencegah gangguan pada pengguna API. Jika memungkinkan, pilih perubahan yang kompatibel dengan versi lama. Pertimbangkan juga biaya karena terkadang, penerapan perubahan yang merusak mungkin lebih hemat biaya.  Gabungkan eksekusi migrasi ke dalam alur penyebaran.  Tetapkan strategi untuk menangani permintaan bersamaan.  Terapkan penemuan, pemantauan, dan pencatatan layanan untuk meningkatkan keandalan dan pengamatan.  Mengembangkan logika bisnis agar idempoten, dengan mengakui bahwa kegagalan jaringan tidak dapat dihindari.    Tinjau dan minimalkan ketergantungan eksternal secara berkala. Setiap ketergantungan eksternal dapat menimbulkan potensi SPOF, jadi penting untuk memahami dan mengurangi risiko ini. Tinjauan ketergantungan.    Jangan pernah lupakan pentingnya menyebarkan pengetahuan di dalam organisasi Anda. Orang-orang tidak dapat diprediksi, dan mengandalkan satu orang saja sangatlah berisiko. Dorong anggota tim untuk mendigitalkan pengetahuan mereka melalui dokumentasi. Namun, berhati-hatilah agar tidak mendokumentasikan secara berlebihan. Manfaatkan berbagai alat AI untuk menyederhanakan proses ini. Berbagi pengetahuan secara berkala.  Kesimpulan  Dalam artikel ini, kami membahas beberapa aspek   utama dan bagaimana kita dapat menangani kompleksitasnya. Makro  Terima kasih telah membaca! Sampai jumpa di lain waktu!

Read My Stories

Audio ini diproduksi dalam bahasa asli cerita!

Terlalu panjang; Untuk membaca

Make resilience your competitive advantage

Cara Menangani Kompleksitas Saat Mendesain Sistem Perangkat Lunak

About Author

KOMENTAR

HANG TAG

ARTIKEL INI DISAJIKAN PADA

Related Stories

THE CAVERNS OF VENUS

Building an API-Powered Platform

Why do you need JWT in your ASP.NET Core project?

Invest With Purpose: Interview with Arian Adeli, CEO at Rivo Trading

THE CAVERNS OF VENUS

Building an API-Powered Platform

Why do you need JWT in your ASP.NET Core project?

Invest With Purpose: Interview with Arian Adeli, CEO at Rivo Trading

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps