Pada bulan November, OTUS meluncurkan program pendidikan baru "Arsitek Perangkat Lunak" , dalam hal ini, kami melanjutkan serangkaian publikasi untuk calon siswa kursus dan pembaca blog kami.
Baca bagian pertama
Arsitektur microservice
Microservices adalah jenis arsitektur perangkat lunak berorientasi layanan yang berfokus pada pembuatan sejumlah komponen yang berdiri sendiri yang membentuk aplikasi. Tidak seperti aplikasi monolitik yang dibuat secara keseluruhan, aplikasi microservice terdiri dari beberapa komponen independen yang direkatkan bersama melalui API.
Struktur layanan mikro dan arsitektur monolitik dibandingkanPendekatan layanan mikro berfokus terutama pada prioritas dan peluang bisnis, sementara pendekatan monolitik diorganisasikan di sekitar tingkat teknologi, antarmuka pengguna, dan basis data. Pendekatan layanan mikro telah menjadi tren dalam beberapa tahun terakhir karena semakin banyak perusahaan menjadi lebih fleksibel dan beralih ke DevOps.
Layanan microsoft penting hanya karena mereka menambah nilai pelanggan yang unik dengan menyederhanakan sistem. Dengan memecah sistem atau aplikasi Anda menjadi banyak bagian yang lebih kecil, Anda menerapkan cara untuk mengurangi duplikasi, meningkatkan konsistensi, dan mengurangi komunikasi antara bagian-bagian, yang membuat bagian umum sistem Anda lebih mudah dimengerti, lebih skalabel, dan lebih mudah untuk diubah.
Lucas Kraus, penulis dari Microservices
Ada banyak contoh perusahaan yang telah berkembang dari pendekatan monolitik ke layanan-mikro. Di antara yang paling terkenal adalah Netflix, Amazon, Twitter, eBay dan PayPal. Untuk menentukan apakah layanan microser sesuai untuk proyek Anda, mari kita mengidentifikasi pro dan kontra dari pendekatan ini.
Pro layanan microser
Mudah dikembangkan, diuji, dan digunakan
Keuntungan terbesar dari layanan microser dibandingkan dengan arsitektur lain adalah bahwa layanan individual kecil dapat dibuat, diuji, dan digunakan secara mandiri. Karena unit penyebarannya kecil, itu membuat pengembangan dan rilis lebih mudah dan lebih cepat. Selain itu, pelepasan satu unit tidak terbatas pada rilis yang lain, yang belum selesai. Dan nilai tambah terakhir di sini adalah bahwa risiko penyebaran berkurang karena pengembang merilis bagian dari perangkat lunak, bukan keseluruhan aplikasi.
Peningkatan fleksibilitas
Dengan bantuan layanan mikro, beberapa tim dapat mengerjakan layanan mereka secara mandiri dan cepat. Setiap bagian aplikasi dapat dibangun secara independen karena isolasi komponen layanan mikro. Misalnya, Anda mungkin memiliki tim yang terdiri dari 100 orang yang mengerjakan seluruh aplikasi (seperti dalam pendekatan monolitik), atau Anda mungkin memiliki 10 tim yang terdiri dari 10 orang yang mengembangkan berbagai layanan.
Mari kita bayangkan secara visual.
Peningkatan fleksibilitas memungkinkan pengembang untuk memperbarui komponen sistem tanpa mematikan aplikasi. Selain itu, fleksibilitas memberikan proses penyebaran yang lebih aman dan peningkatan waktu kerja. Fitur-fitur baru dapat ditambahkan sesuai kebutuhan tanpa menunggu seluruh aplikasi diluncurkan.
Kemampuan untuk skala secara horizontal
Penskalaan vertikal (menggunakan perangkat lunak yang sama, tetapi pada mesin yang lebih kuat) mungkin dibatasi oleh bandwidth setiap layanan. Tetapi penskalaan horizontal (membuat lebih banyak layanan dalam satu kelompok) tidak terbatas dan dapat bekerja dengan layanan microsecara dinamis. Selain itu, penskalaan horizontal dapat sepenuhnya otomatis.
Kontra layanan microser
Kesulitan
Kerugian terbesar dari layanan-layanan mikro adalah kompleksitasnya. Pemisahan aplikasi ke dalam microservices independen memerlukan lebih banyak artefak kontrol. Jenis arsitektur ini membutuhkan perencanaan yang cermat, upaya luar biasa, sumber daya dan keterampilan tim. Alasan untuk kompleksitas tinggi adalah sebagai berikut:
- Permintaan otomatisasi yang meningkat, karena setiap layanan harus diperiksa dan dikendalikan
- Alat yang tersedia tidak berfungsi dengan dependensi layanan
- Konsistensi data dan manajemen transaksi semakin sulit karena setiap layanan memiliki database
Masalah keamanan
Dalam aplikasi microservice, setiap fungsionalitas yang berinteraksi melalui API dari luar meningkatkan kemungkinan serangan. Serangan-serangan ini hanya dapat terjadi jika langkah-langkah keamanan yang tepat tidak diambil saat membuat aplikasi.
Bahasa pemrograman yang berbeda
Kemampuan untuk memilih bahasa pemrograman yang berbeda adalah pedang bermata dua. Menggunakan berbagai bahasa mempersulit penerapan. Selain itu, lebih sulit untuk mengganti pemrogram antara tahap pengembangan, ketika setiap layanan ditulis dalam bahasa yang berbeda.
Pada akhirnya
Layanan microsoft baik, tetapi tidak untuk semua jenis aplikasi. Template ini sangat bagus untuk mengembangkan aplikasi dan sistem yang kompleks. Anda dapat berpikir tentang memilih arsitektur layanan mikro ketika Anda memiliki beberapa tim yang berpengalaman dan ketika aplikasi cukup kompleks untuk memecahnya ke layanan. Ketika aplikasi besar dan perlu fleksibel dan terukur, arsitektur layanan mikro bermanfaat.
Sekarang kita dapat membandingkan ketiga arsitektur perangkat lunak ini untuk secara visual mengidentifikasi perbedaan di antara mereka.
Aplikasi monolitik terdiri dari blok yang tidak dapat dipisahkan dan tidak dapat dipisahkan serta memiliki kecepatan pengembangan yang sangat rendah. SOA terurai menjadi layanan yang lebih kecil, terkait sedang dan lambat berkembang. Layanan Microsoft sangat kecil, layanan independen yang digabungkan secara longgar yang ditandai dengan pengembangan yang cepat dan integrasi yang berkelanjutan.
Arsitektur tanpa server
Arsitektur serverless adalah pendekatan komputasi awan untuk membangun dan menjalankan aplikasi dan layanan tanpa memerlukan manajemen infrastruktur. Dalam aplikasi tanpa server, eksekusi kode digerakkan oleh platform, memungkinkan pengembang untuk menyebarkan kode tanpa khawatir tentang pemeliharaan dan pemeliharaan server. Bahkan, serverlessness tidak berarti "tidak ada server." Aplikasi masih berjalan di server, tetapi layanan cloud pihak ketiga seperti AWS bertanggung jawab penuh untuk server ini. Arsitektur tanpa server menghilangkan kebutuhan akan sumber daya tambahan, penskalaan aplikasi, pemeliharaan server, dan sistem penyimpanan dan basis data.
Arsitektur tanpa server mencakup dua konsep:
- FaaS (Function as a Service) adalah model komputasi awan yang memungkinkan pengembang untuk mengunggah sebagian fungsionalitas ke cloud dan memungkinkan bagian-bagian ini dijalankan secara mandiri
- BaaS (Backend as a Service) adalah model komputasi awan yang memungkinkan pengembang untuk mengalihdayakan aspek backend (manajemen basis data, penyimpanan cloud, hosting, otentikasi pengguna, dll.), Serta menulis dan mendukung hanya sebagian antarmuka eksternal.
Beginilah struktur struktur tanpa serverMenggunakan arsitektur tanpa server, pengembang dapat fokus pada produk itu sendiri tanpa khawatir tentang manajemen server atau runtime. Ini memungkinkan pengembang untuk fokus pada pengembangan produk dengan keandalan dan skalabilitas tinggi.
Ada banyak penyedia solusi cloud di pasaran. Berikut adalah beberapa penyedia komputasi tanpa server terkemuka:
Penyedia komputasi tanpa server terkemukaUntuk mengetahui apakah jenis arsitektur ini diperlukan untuk proyek Anda, mari kita tentukan kelebihan dan kekurangan penerapan model tanpa server.
Kelebihan arsitektur tanpa server
Mudah digunakan
Dalam aplikasi tanpa server, pengembang tidak perlu khawatir tentang infrastruktur. Ini memungkinkan mereka untuk fokus pada kode itu sendiri. Arsitektur tanpa server memungkinkan Anda untuk menyebarkan aplikasi dengan cepat, karena penyebaran hanya membutuhkan beberapa jam atau hari (dibandingkan dengan hari atau minggu dengan pendekatan tradisional).
Pengurangan biaya
Pindah ke arsitektur tanpa server mengurangi biaya. Karena Anda tidak perlu memproses database, beberapa logika dan server, Anda tidak hanya dapat membuat kode yang lebih baik, tetapi juga mengurangi biaya. Saat menggunakan model tanpa server, Anda hanya membayar untuk siklus CPU dan memori yang sebenarnya Anda gunakan.
Skalabilitas yang ditingkatkan
Banyak pemilik bisnis ingin aplikasi mereka menjadi kuat dan terukur, seperti Google atau Facebook. Komputasi tanpa server membuat penskalaan otomatis dan halus. Aplikasi Anda akan secara otomatis skala ketika beban atau basis pengguna meningkat, tanpa mempengaruhi kinerja. Aplikasi tanpa server dapat menangani sejumlah besar permintaan, sementara aplikasi tradisional akan kelebihan beban dengan peningkatan mendadak mereka.
Kerugian dari arsitektur tanpa server
Pengikatan pemasok
Pengikatan pemasok menjelaskan situasi di mana Anda memberi pemasok kendali penuh atas operasi Anda. Akibatnya, perubahan dalam logika bisnis terbatas, dan migrasi dari satu penyedia ke penyedia lainnya bisa menjadi sulit.
Bukan untuk tugas jangka panjang.
Model serverless tidak cocok untuk operasi lama. Aplikasi tanpa server bagus untuk proses singkat dalam waktu nyata, tetapi jika tugas tersebut membutuhkan waktu lebih dari lima menit, aplikasi tanpa server akan membutuhkan fitur FaaS tambahan.
Pada akhirnya
Arsitektur perangkat lunak tanpa server berguna untuk menyelesaikan tugas satu kali dan proses pendukung. Ini berfungsi baik untuk aplikasi dan aplikasi yang kaya pelanggan yang tumbuh dengan cepat dan membutuhkan skala yang tidak terbatas.
Akhirnya, mari kita lihat gambar berikut untuk mencari tahu kapan harus memilih masing-masing dari keempat jenis arsitektur ini:
Memilih arsitektur yang tepat untuk MVP Anda memang sulit, tetapi RubyGarage memiliki pengalaman bertahun-tahun untuk membantu Anda dengan pilihan Anda. Penulis artikel akan dengan senang hati menjawab semua pertanyaan Anda tentang topik ini.