Kami telah menyiapkan terjemahan sebuah artikel oleh Neil Ford, seorang arsitek sistem dan otak ideologis di ThoughtWorks, sebuah perusahaan pengembangan perangkat lunak yang mengotomatiskan pengujian perangkat lunak dan proses penyebaran.
Neil adalah pakar pengembangan perangkat lunak yang diakui yang bekerja di persimpangan desain lincah dan arsitektur sistem. Dia adalah penulis berbagai artikel, buku, puluhan presentasi video, membuat presentasi di konferensi pengembang terkemuka. Anda dapat melihat karyanya di
nealford.com .
Layanan microser sebagai arsitektur evolusioner
Arsitektur microservice dengan cepat menaklukkan dunia. Pada bulan Maret, perusahaan penerbitan O'Reilly menyelenggarakan Konferensi Arsitektur Perangkat Lunak O'Reilly yang pertama. Dan hampir 60% dari laporan dikhususkan untuk aspek-aspek tertentu dari penggunaan layanan-mikro. Mengapa gaya arsitektur khusus ini tiba-tiba menjadi begitu populer?
Arsitektur Microservice adalah gaya desain arsitektur baru yang muncul setelah DevOps dan menggabungkan praktik pengiriman perangkat lunak berkelanjutan. Ini juga merupakan contoh arsitektur evolusi yang mengikuti prinsip perubahan bertahap dan berkesinambungan dalam beberapa dimensi pada tingkat struktural aplikasi. Artikel ini membahas beberapa fitur unik dan prinsip keluarga gaya arsitektur ini.
Arsitektur evolusioner
Sebelumnya diyakini bahwa unsur-unsur arsitektur "sangat sulit untuk berubah setelah penciptaannya." Perubahan bertahap adalah prinsip utama arsitektur evolusi. Ini menarik perhatian umum justru karena perubahan dalam arsitektur selalu sulit untuk diramalkan dan sangat mahal untuk dilakukan. Jika kemungkinan perubahan evolusioner dibangun ke dalam arsitektur itu sendiri, maka implementasinya menjadi jauh lebih sederhana dan lebih murah, berkontribusi terhadap perubahan dalam pengembangan perangkat lunak dan praktik rilis, serta meningkatkan tingkat fleksibilitas proses secara keseluruhan.
Arsitektur Microservice sepenuhnya konsisten dengan ide ini karena ia memiliki
Bounded Contexts yang dialokasikan secara logis sesuai dengan Eric Evans 'Domain Driven Design dan diimplementasikan sebagai komponen yang terpisah secara fisik. Pemisahan ini dicapai melalui penerapan praktik-praktik DevOps seperti penyediaan mesin virtual, pengujian, dan penyebaran otomatis. Karena setiap layanan dipisahkan dari semua layanan lain (pada tingkat struktural), mengganti satu layanan mikro dengan yang lain semudah menukar lego cubes.
Fitur arsitektur evolusioner
Arsitektur evolusi memiliki sejumlah karakteristik umum. Semua fitur ini akan dijelaskan dalam buku yang akan datang tentang arsitektur evolusi. Dalam artikel ini kami hanya memberikan beberapa di antaranya.
Modularitas dan konektivitas
Kemampuan untuk berbagi komponen dalam batas-batas yang ditentukan dengan baik memberi pengembang manfaat dari perubahan berkelanjutan jika perlu. Jika arsitekturnya tidak dirancang dan sistemnya tampak seperti bola lumpur
besar (
arsitektur Bola Besar Lumpur ), maka perubahan evolusioner tidak mungkin, karena tidak ada bagian yang dapat dibedakan dalam struktur seperti itu.
[Hubungan antara kelas (menunjuk sekeliling) dalam segumpal besar kotoran dari proyek klien yang tidak disebutkan namanya.]Interkoneksi komponen yang salah menghambat evolusi sistem karena fakta bahwa membuat perubahan dapat secara tak terduga mempengaruhi bagian lain dari sistem. Semua arsitektur evolusi menyediakan beberapa tingkat modularitas, biasanya pada tingkat arsitektur teknis (misalnya, arsitektur berlapis).
Organisasi di sekitar peluang bisnis
Dipengaruhi oleh prinsip-prinsip desain berorientasi subjek dalam arsitektur sukses modern, modularitas di tingkat domain semakin banyak digunakan. Arsitektur berbasis layanan berbeda dari arsitektur berorientasi layanan tradisional (SOA) terutama dalam strategi alokasi layanannya. Arsitektur berorientasi layanan secara ketat dibagi oleh tingkat teknis, sedangkan arsitektur berbasis layanan dibangun terutama di bagian-bagian dari area subjek yang ditentukan oleh layanan-layanan microser.
Eksperimennya
Melakukan eksperimen adalah salah satu keuntungan signifikan yang diberikan arsitektur evolusi pada bisnis. Kemampuan untuk dengan mudah melakukan perubahan kecil pada aplikasi menyediakan penggunaan praktik penerapan terus menerus yang umum seperti pengujian A / B, pengujian untuk sekelompok pengguna terbatas (Canary release), dan lainnya. Arsitektur microservice sering dibangun berdasarkan routing layanan panggilan, yang memungkinkan untuk menggunakan beberapa versi layanan dalam seluruh ekosistem. Ini pada gilirannya membuka peluang besar untuk eksperimen dan perubahan fungsionalitas yang ada. Pada akhirnya, ketika mengembangkan aplikasi bisnis, lebih sedikit waktu yang dihabiskan untuk membahas rencana dan simpanan, dan pengembangan dilakukan terutama dalam mode pengujian hipotesis cepat.
Prinsip Arsitektur Evolusi
Gambaran arsitektur evolusi yang lebih lengkap dapat diperoleh dengan mengenal prinsip-prinsip dasarnya. Prinsip-prinsip ini berkaitan dengan berbagai karakteristik arsitektur itu sendiri dan metode desainnya. Bagian dari prinsip-prinsip berkaitan dengan pilihan saat membuat keputusan arsitektur dalam proses perancangan sistem.
Fungsi kebugaran
Penting untuk membedakan antara yang muncul (terbentuk sebagai hasil dari proses desain) dan arsitektur evolusioner - ini sangat penting. Seperti metode perhitungan evolusioner (seperti algoritma genetika), fungsi kebugaran arsitektur menetapkan tujuan dalam desain arsitektur. Untuk beberapa sistem, persyaratan utama adalah waktu kerja yang lama, untuk yang lain, kinerja tinggi atau keamanan.
[Grafik radar digunakan untuk menyoroti fungsi kebugaran penting yang relevan dengan sistem perangkat lunak ini.]
Jika Anda menentukan terlebih dahulu fungsi kebugaran untuk sistem tertentu, ini akan membantu di masa depan untuk membuat keputusan yang tepat secara tepat waktu. Untuk solusi arsitektur yang berbeda, Anda dapat menghitung fungsi kebugaran, dan jika nilainya menjadi lebih baik, ini berarti bahwa arsitektur berkembang ke arah yang benar.
Perhatian pada poin nyeri
Banyak metode kerja yang digunakan dalam penyediaan perangkat lunak yang berkelanjutan dan pengembangan arsitektur yang berkembang didasarkan pada prinsip "perhatian pada titik-titik nyeri" yang dirumuskan oleh komunitas Pemrograman eXtreme. Ketika momen muncul dalam karya desain yang dapat menjadi sumber masalah (titik nyeri), perlu untuk memperhatikan mereka sesegera mungkin. Ini akan membantu untuk mengidentifikasi potensi masalah di muka dan menghilangkannya dalam urutan kerja. Praktik pengiriman kontinu yang umum, seperti pipa penempatan, penyediaan otomatis mesin virtual, dan migrasi basis data, ketika merancang arsitektur evolusi, sangat menyederhanakan penghapusan titik nyeri selama fase perubahan.
Titik keputusan
Perbedaan utama antara arsitektur tradisional dan evolusi adalah ketika keputusan penting dibuat. Keputusan ini mungkin terkait dengan struktur aplikasi, tumpukan teknologi, alat individu, atau pola komunikasi. Dalam hal merancang arsitektur tradisional, keputusan seperti itu dibuat pada tahap awal, sebelum menulis kode. Dalam proses pengembangan arsitektur evolusioner, setiap keputusan dibuat selambat mungkin, pada saat terakhir, ketika itu masih dapat diterima. Keuntungan dari pengambilan keputusan nanti adalah bahwa informasi tambahan mungkin tersedia pada saat ini. Biaya metode ini termasuk biaya kemungkinan perbaikan arsitektur setelah keputusan dibuat. Biaya-biaya ini dapat dikurangi dengan menggunakan abstraksi yang sesuai, tetapi mereka masih bisa terjadi. Namun, biaya pengambilan keputusan pada tahap awal juga cukup nyata. Ambil, misalnya, keputusan untuk memilih alat pengiriman pesan. Alat yang berbeda mendukung fungsi yang berbeda. Jika kita memilih alat yang lebih kuat dari yang diperlukan, kita mendapatkan arsitektur yang salah yang pasti akan membutuhkan pengembangan lebih lanjut. "Hutang teknis" ini, yang timbul dari pemilihan alat yang salah, akan menjadi beban tambahan bagi pengembang.
Tentu saja, masalah utama dengan momen terakhir yang memungkinkan untuk mengambil keputusan adalah menentukan kapan saatnya tiba. Untuk melakukan ini, fokuslah pada fungsi kebugaran. Pertama-tama, perlu untuk membuat keputusan yang dapat memiliki dampak signifikan pada pilihan arsitektur atau elemen desain, serta keputusan yang secara signifikan mempengaruhi keberhasilan keseluruhan proyek. Dampak negatif dari penundaan keputusan seperti itu seringkali lebih besar daripada manfaat yang mungkin diperoleh dari keputusan selanjutnya.
Kesimpulan
Arsitek perangkat lunak harus menjelaskan keputusan yang dibuat tentang desain sistem yang dikembangkan, sebagai aturan, menggunakan berbagai macam diagram. Pengembang arsitektur sering jatuh ke dalam perangkap menyajikan arsitektur perangkat lunak sebagai persamaan yang harus mereka selesaikan. Banyak alat komersial yang ditawarkan oleh arsitek perangkat lunak memungkinkan Anda untuk mendeskripsikan arsitektur secara formal dalam bentuk kuadrat, garis, dan panah. Meskipun diagram semacam itu mungkin berguna, mereka hanya menawarkan tampilan dua dimensi, potret dunia yang ideal, tetapi kita hidup dalam realitas empat dimensi.
Untuk mengisi diagram dua dimensi dengan kehidupan, perlu untuk menentukannya. Label
ORM dalam diagram dua dimensi menjadi
Hibernate v4.2.17 , membuat dunia menjadi tiga dimensi. Ketika Anda memiliki rencana untuk penerapannya dalam produksi dan memperbarui enam bulan kemudian ke versi
Hibernate v4.3.0.1 yang tak terhindarkan, Anda akan siap untuk dunia empat dimensi. Banyak arsitek tidak menyadari bahwa pandangan statis arsitektur memiliki umur yang pendek. Alam semesta perangkat lunak ada dalam keadaan aliran; ia dinamis, bukan statis. Arsitektur bukanlah sebuah persamaan, melainkan potret dari proses yang sedang berlangsung.
Praktik pengiriman perangkat lunak berkelanjutan dan DevOps telah menunjukkan masalah yang muncul dari kurangnya pemahaman tentang upaya yang diperlukan untuk menerapkan dan mendukung arsitektur. Menerapkan arsitektur hanyalah langkah pertama.
Arsitektur tetap merupakan abstraksi sampai diterapkan. Dengan kata lain, kelayakan arsitektur apa pun dalam jangka panjang hanya dapat dinilai jika Anda tidak hanya mengimplementasikannya, tetapi juga memodifikasinya setidaknya sekali. Dan mungkin mereka berhasil mengatasi kejutan di sepanjang jalan.
Pemahaman seorang arsitek perangkat lunak tentang kemampuan operasional sangat penting untuk mengembangkan arsitektur evolusi. Perkembangan evolusi arsitektur memengaruhi fitur-fitur implementasinya, dan karenanya harus diperhitungkan dalam proses penyelesaiannya. Persyaratan proses pengiriman berkelanjutan untuk arsitektur ditujukan untuk meningkatkan visualisasi dan menyederhanakan perubahan. Dengan cara ini, pengiriman terus menerus meningkatkan arsitektur evolusioner.
Pada 19 November, Neil Ford tiba di Moskow dengan kelas master
untuk menciptakan arsitektur perangkat lunak evolusioner .