Prinsip pengembangan aplikasi modern dari NGINX. Bagian 1

Halo teman-teman. Untuk mengantisipasi peluncuran kursus "Pengembang PHP Backend" , kami biasanya membagikan terjemahan materi bermanfaat kepada Anda.

Perangkat lunak ini memecahkan lebih banyak tugas sehari-hari, sementara menjadi semakin sulit. Seperti Mark Andressen pernah katakan, itu menelan dunia.



Akibatnya, pendekatan untuk pengembangan dan pengiriman aplikasi telah berubah secara dramatis selama beberapa tahun terakhir. Ini adalah pergeseran skala tektonik, yang akibatnya menyebabkan munculnya seperangkat prinsip. Prinsip-prinsip ini telah terbukti bermanfaat dalam membangun tim, merancang, mengembangkan, dan mengirimkan aplikasi Anda kepada pengguna akhir.

Prinsip-prinsipnya dapat diringkas sebagai berikut: aplikasi harus kecil, berjejaring, dan memiliki arsitektur berorientasi pengembang . Berdasarkan tiga prinsip ini, Anda dapat membuat aplikasi yang andal dan komprehensif yang dapat dengan cepat dan aman dikirim ke pengguna akhir, dan dapat dengan mudah ditingkatkan dan diperluas.



Setiap prinsip yang diusulkan memiliki sejumlah aspek yang akan kita diskusikan untuk menunjukkan bagaimana setiap prinsip berkontribusi terhadap pencapaian tujuan akhir, yaitu dengan cepat memberikan aplikasi yang andal yang mudah dipelihara dan digunakan. Kami akan mempertimbangkan prinsip-prinsip ini dibandingkan dengan kebalikannya untuk menjelaskan apa artinya, katakan, "Pastikan Anda menggunakan prinsip kekecilan ."

Kami berharap bahwa artikel ini akan mendorong Anda untuk menggunakan prinsip-prinsip yang diusulkan untuk membangun aplikasi modern yang akan memberikan pendekatan terpadu untuk merancang dalam konteks tumpukan teknologi yang terus berkembang.

Dengan menerapkan prinsip-prinsip ini, Anda akan mendapati diri Anda mengambil keuntungan dari tren pengembangan perangkat lunak terbaru, termasuk pendekatan DevOps untuk mengembangkan dan mengirimkan aplikasi, menggunakan wadah (seperti Docker ) dan kerangka kerja untuk orkestrasi wadah (seperti Kubernetes ), menggunakan layanan mikro (termasuk NGINX Arsitektur Layanan Mikro) dan arsitektur komunikasi jaringan untuk aplikasi layanan mikro.

Apa itu aplikasi modern?

Aplikasi modern? Tumpukan modern? Apa sebenarnya artinya "modern"?

Sebagian besar pengembang hanya memiliki gambaran umum tentang aplikasi modern, sehingga Anda perlu memberikan definisi yang jelas tentang konsep ini.

Aplikasi modern mendukung beberapa klien, apakah itu antarmuka pengguna di pustaka JavaScript React, aplikasi seluler untuk Android atau iOS, atau aplikasi yang terhubung ke yang lain melalui API. Aplikasi modern menyiratkan adanya jumlah pelanggan yang tidak terbatas untuk siapa ia menyediakan data atau layanan.

Aplikasi modern menyediakan API untuk mengakses data dan layanan yang diminta. API harus tidak berubah dan konstan, dan tidak ditulis secara khusus untuk permintaan spesifik dari klien tertentu. API dapat diakses melalui HTTP (S) dan menyediakan akses ke semua fungsi yang ada di GUI atau CLI.

Data harus dapat diakses dalam format yang diterima secara umum, kompatibel, seperti JSON. API menyediakan objek dan layanan dengan cara yang jelas dan terorganisir, misalnya, RESTful API atau GraphQL menyediakan antarmuka yang layak.

Aplikasi modern dibangun di atas tumpukan modern, dan tumpukan modern adalah tumpukan yang masing-masing mendukung aplikasi tersebut. Tumpukan seperti itu memungkinkan pengembang untuk dengan mudah membuat aplikasi dengan antarmuka HTTP dan menghapus titik akhir API. Pendekatan yang dipilih akan memungkinkan aplikasi Anda untuk dengan mudah menerima dan mengirim data dalam format JSON. Dengan kata lain, tumpukan modern sesuai dengan unsur-unsur aplikasi Dua Belas-Faktor untuk layanan-layanan microser .

Versi populer dari tipe tumpukan ini didasarkan pada Java , Python , Node , Ruby , PHP, dan Go . Arsitektur NGINX Microservice mewakili contoh tumpukan modern yang diterapkan pada masing-masing bahasa yang disebutkan.

Harap dicatat bahwa kami tidak secara eksklusif menganjurkan pendekatan layanan-mikro. Banyak dari Anda bekerja dengan monolit yang perlu berevolusi, sementara yang lain berurusan dengan aplikasi SOA yang berkembang dan berevolusi menjadi aplikasi layanan-mikro. Yang lain bergerak menuju aplikasi tanpa server, dan beberapa memperkenalkan kombinasi di atas. Prinsip-prinsip yang ditetapkan dalam artikel ini berlaku untuk masing-masing sistem ini dengan hanya beberapa perubahan kecil.

Prinsip

Sekarang kita memiliki pemahaman bersama tentang apa itu aplikasi modern dan tumpukan modern, sekarang saatnya untuk membenamkan diri dalam prinsip arsitektur dan pengembangan, yang akan membantu Anda dengan baik dalam pengembangan, implementasi, dan dukungan aplikasi modern.

Salah satu prinsipnya adalah "buat aplikasi kecil", sebut saja prinsip kekecilan . Ada aplikasi yang sangat kompleks yang terdiri dari sejumlah besar komponen bergerak. Pada gilirannya, membangun aplikasi dari komponen diskrit kecil menyederhanakan desain, pemeliharaan, dan bekerja dengannya secara keseluruhan. (Catatan, kami mengatakan "menyederhanakan", bukan "membuatnya sederhana.")

Prinsip kedua adalah kita dapat meningkatkan produktivitas pengembang dengan membantu mereka fokus pada fungsi yang mereka kembangkan, sekaligus membebaskan mereka dari kekhawatiran tentang infrastruktur dan CI / CD selama implementasi. Singkatnya, pendekatan kami difokuskan pada pengembang .

Akhirnya, segala sesuatu tentang aplikasi Anda harus terhubung ke jaringan. Selama 20 tahun terakhir, kami telah membuat langkah besar menuju masa depan jaringan, karena jaringan lebih cepat dan aplikasi lebih kompleks. Seperti yang telah kita ketahui, aplikasi modern harus digunakan melalui jaringan oleh banyak klien yang berbeda. Penggunaan pemikiran jaringan dalam arsitektur memiliki keuntungan signifikan yang berjalan baik dengan prinsip kekecilan dan konsep pendekatan yang berorientasi pada pengembang .

Jika selama pengembangan dan implementasi aplikasi Anda akan memperhatikan prinsip-prinsip ini, Anda akan memiliki keuntungan yang tidak dapat disangkal dalam pengembangan dan pengiriman produk Anda.

Mari kita lihat tiga prinsip ini secara lebih rinci.

Prinsip kekecilan

Sulit bagi otak manusia untuk menerima sekaligus sejumlah besar informasi. Dalam psikologi, istilah muatan kognitif berarti jumlah total upaya mental yang diperlukan untuk menyimpan informasi dalam memori. Mengurangi beban kognitif pada pengembang adalah prioritas, karena dalam hal ini mereka dapat fokus pada penyelesaian masalah, alih-alih mengingat model kompleks saat ini dari seluruh aplikasi dan fungsi yang sedang dikembangkan.



Aplikasi didekomposisi untuk alasan berikut:

• Penurunan beban kognitif pada pengembang;
• Percepat dan sederhanakan pengujian;
• Pengiriman cepat perubahan dalam aplikasi.

Ada beberapa cara untuk mengurangi beban kognitif pada pengembang, dan di sinilah prinsip ketiadaan berperan.

Jadi, ada tiga cara untuk menurunkan muatan kognitif:

1. Kurangi kerangka waktu yang harus mereka perhitungkan ketika mengembangkan fungsi baru - semakin pendek kerangka waktu, semakin rendah beban kognitif.
2. Kurangi jumlah kode di mana pekerjaan satu kali dilakukan - kode kurang - lebih sedikit beban.
3. Sederhanakan proses membuat perubahan tambahan pada aplikasi.

Kurangi garis waktu pengembangan

Mari kita kembali ke hari-hari ketika metodologi waterfall adalah standar untuk proses pengembangan, dan jangka waktu dari enam bulan hingga dua tahun untuk mengembangkan atau memperbarui aplikasi adalah praktik umum. Biasanya, para insinyur pertama-tama membaca dokumen yang relevan, seperti persyaratan produk (PRD), dokumen rujukan sistem (SRD), rencana arsitektur, dan mulai menggabungkan semua hal ini menjadi satu model kognitif, yang dengannya mereka menulis kode. Sebagai persyaratan dan, oleh karena itu, arsitektur berubah, upaya serius harus dilakukan untuk memberi informasi kepada seluruh tim tentang pembaruan model kognitif. Dalam kasus terburuk, pendekatan semacam itu bisa melumpuhkan pekerjaan.

Perubahan terbesar dalam proses pengembangan aplikasi adalah pengenalan metodologi tangkas. Salah satu fitur utama dari metodologi agile adalah pengembangan berulang. Pada gilirannya, ini menyebabkan penurunan beban kognitif pada insinyur. Alih-alih mengharuskan tim pengembangan untuk mengimplementasikan aplikasi dalam satu siklus panjang, pendekatan agile memungkinkan Anda untuk fokus pada sejumlah kecil kode yang dapat dengan cepat diuji dan digunakan, sementara juga menerima umpan balik. Beban kognitif aplikasi telah bergeser dari jangka waktu dari enam bulan menjadi dua tahun, dengan mempertimbangkan sejumlah besar spesifikasi untuk penambahan dua minggu atau perubahan fitur, yang bertujuan untuk pemahaman yang lebih samar tentang aplikasi besar.

Mengubah fokus dari aplikasi besar ke fungsi kecil spesifik yang dapat diselesaikan dalam sprint dua minggu, melihat ke depan untuk tidak lebih dari satu fungsi dari sprint berikutnya di kepala, adalah perubahan signifikan. Ini memungkinkan kami untuk meningkatkan produktivitas pengembangan sambil mengurangi beban kognitif, yang terus berfluktuasi.

Metodologi agile mengasumsikan bahwa aplikasi akhir akan menjadi versi yang sedikit dimodifikasi dari konsep asli, sehingga titik pengembangan akhir harus ambigu. Hanya hasil dari setiap sprint tertentu yang bisa jelas dan tepat.

Basis kode kecil

Langkah selanjutnya dalam mengurangi beban kognitif adalah mengurangi basis kode. Sebagai aturan, aplikasi modern sangat besar - aplikasi perusahaan yang andal dapat terdiri dari ribuan file dan ratusan ribu baris kode. Bergantung pada organisasi file komunikasi dan dependensi kode dan file, mereka mungkin jelas atau sebaliknya. Bahkan debugging kode itu sendiri dapat menyebabkan masalah, tergantung pada perpustakaan yang digunakan dan seberapa baik alat debugging membedakan antara perpustakaan / paket / modul dan kode pengguna.

Membangun model mental yang berfungsi dari kode aplikasi dapat memakan waktu yang mengesankan, dan sekali lagi menempatkan beban kognitif yang besar pada pengembang. Hal ini terutama berlaku untuk basis kode monolitik, di mana ada sejumlah besar kode, interaksi antara komponen fungsional yang tidak didefinisikan dengan jelas, dan pemisahan objek perhatian sering kabur, karena batas-batas fungsional tidak dihormati.

Salah satu cara efektif untuk mengurangi beban kognitif pada insinyur adalah transisi ke arsitektur layanan mikro. Dalam pendekatan microservice, setiap layanan berfokus pada satu set fungsi; arti dari layanan ini biasanya didefinisikan dan dimengerti. Batas-batas layanan juga jelas - ingat bahwa komunikasi dengan layanan dilakukan menggunakan API, sehingga data yang dihasilkan oleh satu layanan dapat dengan mudah ditransfer ke layanan lain.

Interaksi dengan layanan lain biasanya terbatas pada beberapa layanan pengguna dan beberapa layanan penyedia yang menggunakan panggilan API sederhana dan bersih, misalnya, menggunakan REST. Ini berarti bahwa beban kognitif pada insinyur berkurang secara serius. Tugas yang paling sulit adalah memahami model interaksi antara layanan dan bagaimana hal-hal seperti transaksi terjadi di beberapa layanan. Akibatnya, penggunaan layanan mikro mengurangi beban kognitif, mengurangi jumlah kode, menunjukkan batas layanan yang jelas dan memberikan pemahaman tentang hubungan antara pengguna dan penyedia.

Perubahan inkremental kecil

Elemen terakhir dari prinsip smallness adalah manajemen perubahan. Ini adalah godaan khusus bagi pengembang untuk melihat basis kode (bahkan, mungkin, pada kode mereka yang lebih tua) dan mengatakan: "Ini omong kosong, kita perlu menulis ulang semuanya." Terkadang ini adalah keputusan yang tepat, dan terkadang tidak. Ini menempatkan beban perubahan model global pada tim pengembangan, yang pada gilirannya menyebabkan beban kognitif besar. Lebih baik bagi para insinyur untuk fokus pada perubahan yang dapat mereka lakukan selama sprint, untuk kemudian meluncurkan fungsionalitas yang diperlukan pada waktu yang tepat, meskipun secara bertahap. Produk akhir harus mengingatkan pada yang direncanakan, tetapi dengan beberapa modifikasi dan pengujian untuk memenuhi kebutuhan pelanggan.

Ketika menulis ulang sebagian besar kode, terkadang tidak mungkin untuk dengan cepat mengirimkan perubahan, karena ketergantungan sistem lainnya ikut berperan di sini. Untuk mengontrol aliran perubahan, Anda dapat menggunakan fitur bersembunyi. Pada prinsipnya, ini berarti fungsionalitasnya pada produksi, tetapi tidak tersedia menggunakan pengaturan variabel lingkungan (env-var) atau mekanisme konfigurasi lainnya. Jika kode telah melewati semua proses kontrol kualitas, maka mungkin dalam produksi dalam keadaan tersembunyi. Namun, strategi ini hanya berfungsi jika fitur tersebut pada akhirnya diaktifkan. Jika tidak, itu hanya akan membuang kode dan menambah beban kognitif, yang harus dihadapi pengembang untuk pekerjaan yang produktif. Manajemen perubahan dan perubahan bertahap dalam dan dari mereka sendiri membantu menjaga beban kognitif pengembang pada tingkat yang terjangkau.

Insinyur harus mengatasi banyak kesulitan bahkan dengan implementasi sederhana dari fungsi tambahan. Pada bagian manajemen, akan masuk akal untuk mengurangi beban tambahan pada tim sehingga dapat fokus pada elemen-elemen kunci fungsional. Ada tiga hal yang dapat Anda lakukan untuk membantu tim pengembangan Anda:

1. Gunakan metodologi agile untuk membatasi kerangka waktu di mana tim harus fokus pada fungsi-fungsi utama.
2. Terapkan aplikasi Anda sebagai beberapa layanan mikro. Ini akan membatasi jumlah fitur yang diimplementasikan dan memperkuat batas-batas yang menahan beban kognitif selama bekerja.
3. Lebih suka perubahan inkremental ke besar dan besar, ubah potongan kode kecil. Gunakan fitur persembunyian untuk mengimplementasikan perubahan, bahkan jika itu tidak terlihat segera setelah ditambahkan.

Jika Anda menerapkan prinsip kekecilan dalam pekerjaan Anda, tim Anda akan menjadi jauh lebih bahagia, lebih fokus pada implementasi fungsi yang diperlukan dan lebih mungkin untuk melakukan perubahan kualitatif lebih cepat. Tetapi ini tidak berarti bahwa pekerjaan tidak dapat menjadi rumit, kadang-kadang sebaliknya, pengenalan fungsionalitas baru memerlukan modifikasi beberapa layanan dan proses ini bisa lebih rumit daripada yang serupa dalam arsitektur monolitik. Bagaimanapun, manfaat dari pendekatan kecil sepadan.

Akhir dari bagian pertama.

Segera kami akan menerbitkan bagian kedua dari terjemahan, dan sekarang kami menunggu komentar Anda dan kami mengundang Anda untuk membuka hari , yang akan diadakan hari ini pukul 20.00.