Terjemahan artikel disiapkan untuk siswa kursus Praktek dan Alat DevOps dalam proyek pendidikan OTUS .

Ketika tutorial pertama mulai menggunakan AWS Lambda dan Gateway API pada tahun 2015, tidak mengherankan bahwa mereka terutama berfokus pada menyalin arsitektur layanan microser. Tetapi bagi mereka yang menggunakan AWS Lambda dalam skala besar, menjadi jelas dari waktu ke waktu bahwa ada batasan yang signifikan untuk menerapkan pendekatan microservice ke AWS Lambda ... Setidaknya ada pembatasan pada apa yang kebanyakan orang maksudkan dengan dibangunnya layanan microser yang benar.

Mari kita bicara tentang mengapa untuk layanan mikro

Layanan Microsoft muncul terutama karena frustrasi dengan aplikasi monolitik. Monolith adalah aplikasi di mana semua logika berada dalam satu basis kode logis.

Ada saat-saat ketika, karena tingginya biaya server, itu biasa untuk menyebarkan seluruh aplikasi pada satu server. Menyebarkan monolith berarti bahwa pada server Anda menyebarkan sebagian atau seluruh aplikasi.

Selain itu, menggunakan monolith berarti Anda harus yakin bahwa Anda tidak akan merusak apa pun. Sangat sering, perubahan kecil menyebabkan kegagalan seluruh server dan seluruh aplikasi.

Oleh karena itu, ketika awan muncul dengan kemampuan untuk memberikan contoh dengan satu klik dalam hitungan menit (bukan hari atau minggu), kemungkinan pemisahan tugas menjadi jelas.
Penghancuran monolit menjadi ide yang jelas, dan ide layanan mikro lahir.

Alih-alih membuat monolit dengan semua logika pada satu server / instance, Anda dapat menempatkan bagian-bagian aplikasi pada server yang berbeda dan menghubungkannya bersama-sama menggunakan semacam protokol ringan - biasanya HTTP API.

Dengan demikian, arsitektur aplikasi telah berpindah dari monolit ke layanan microser.

Meskipun, saya bertanya-tanya mengapa? Nilai dari pendekatan ini adalah bahwa ketika mengedit kode Anda mengubah basis kode bukan seluruh aplikasi, tetapi microservice - hanya bagian komponen dari aplikasi. Ini berarti Anda tidak dapat merusak seluruh aplikasi.

Meskipun ini hanya secara teoritis, tetapi teori ini lebih baik daripada monolit, meskipun tidak ideal.

Elemen kunci untuk setiap layanan adalah ...

Antarmuka layanan

Ini sering merupakan beberapa bentuk antarmuka HTTP (setidaknya ini adalah pendekatan yang paling umum). Sebagai aturan, ini bukan masalah, kecuali ketika Anda memiliki sejumlah besar layanan dan mungkin ada masalah koordinasi mereka.

Bergerak menuju arsitektur tanpa server

Oleh karena itu, pendekatan awal untuk membangun aplikasi tanpa server di AWS adalah "mari kita buat microservices" ...

Ini berarti membuat Gateway API dengan fungsi Lambda di belakangnya dan pernyataan switch yang bertindak sebagai router.

Setiap Gateway API menjadi antarmuka layanan, dan itu tampak logis.

Anda dapat membuat beberapa layanan yang skala terpisah satu sama lain, yang dalam beberapa kasus bisa sangat penting.

Kecuali bahwa tidak masuk akal ketika Anda menyadari bahwa fungsi AWS Lambda dan FaaS secara umum tidak boleh dianggap sebagai instance / server.

Karena meskipun mereka memiliki server di bawah tenda (hei, ada server di bawah sebagian besar hal yang berfungsi di Internet, tetapi tidak ada yang mengatakan "S3 masih memiliki server" atau "BigTable masih memiliki server" atau "Azure Active Directory all masih memiliki server "...), ada pendapat bahwa Anda harus memperlakukan fungsi FaaS sama dengan layanan ..." minilith ", sebagaimana beberapa orang menyebutnya.

Masalahnya adalah bahwa di sini tidak ada apa, menurut pendapat saya, adalah kunci untuk arsitektur tanpa server:

Arsitektur serverless adalah semua tentang peristiwa

Arsitektur tanpa server, acara, dan pemicu

Sistem serverless pada dasarnya adalah sistem yang digerakkan oleh peristiwa, dan karenanya merupakan perwakilan dari arsitektur yang digerakkan oleh peristiwa. Ini mengubah pendekatan Anda untuk desain, manajemen dan arsitektur.

Dalam hal layanan microser, intinya adalah menanggapi antarmuka - ini adalah mekanisme utama untuk berinteraksi dengan logika.

Solusi tanpa server adalah tentang menanggapi peristiwa, dan API sebenarnya hanyalah mekanisme untuk menghasilkan acara.

Sebagai bagian dari ekosistem AWS, yang merupakan solusi serverless yang paling matang, API tidak dipandang sebagai antarmuka utama. Peristiwa jauh lebih penting.

Dan itulah sebabnya ada sekitar 50 peristiwa yang dapat memicu fungsi Lambda dari layanan AWS lainnya.

Kiatnya adalah jika Anda dapat menjalankan fungsi Lambda tanpa melalui Gateway API, itu akan jauh lebih cepat dan lebih efisien daripada menggunakan Gateway API, terutama jika Anda menjalankannya dari antarmuka AWS lain.

Lihatlah Praktik Terbaik Tanpa Server , Anda akan melihat sejumlah poin yang berbeda dari berapa banyak desain layanan mikro.

Pertama-tama, fungsi searah. Sebagian besar layanan microser biasanya menggunakan arsitektur permintaan-respons karena sebagian besar aplikasi web bekerja dengan cara ini. Fungsi dalam aplikasi tanpa server, sebagai aturan, adalah searah, dan antrian digunakan sebagai "pemutus sirkuit", sehingga permintaan-respons menjadi kurang umum.

Lapisan data juga dikelola dan dipahami dengan berbagai cara. Praktik terbaik adalah memiliki beberapa fungsi, bukan satu fungsi proksi dengan pernyataan beralih.

Gagasan beberapa fungsi juga memberikan keuntungan tambahan dibandingkan layanan microser. Jika suatu fungsi melempar kesalahan, maka ini hanya akan mempengaruhi fungsi ini, dan bukan sisa aplikasi, karena fungsi tersebut tidak memiliki keadaan (setidaknya seharusnya!). Dan ini adalah alasan yang sangat bagus untuk tidak melakukan "minilith"!

Oleh karena itu, meskipun pengalaman dalam membangun layanan microser memberi Anda beberapa keuntungan ketika merancang solusi tanpa server, pada kenyataannya Anda dapat melewatkan sebagian besar dari apa yang membuat aplikasi tanpa server berharga.

Layanan microser biasanya berbeda dari aplikasi tanpa server yang dirancang dengan baik dalam beberapa hal. Ini berarti bahwa meskipun dimungkinkan untuk membuat layanan microser dengan backend tanpa server, pada kenyataannya tidak ada jalur langsung dari layanan microser ke arsitektur tanpa server.

Jalur dari microservices ke arsitektur tanpa server

Jadi, apa jalan dari microservices ke solusi serverless? Apakah ada cara cepat untuk mempelajari dasar-dasar untuk menyederhanakan transisi dari satu ke yang lain, karena layanan mikro tersebar luas?

Saya pikir inilah yang membuat dunia tanpa server bingung. Baru-baru ini, ada diskusi besar di Twitter di mana kami berbicara tentang topik ini. Di sini ada baiknya merujuk padanya, jika hanya untuk melihat apa yang dibicarakan komunitas (lihat berbagai jawaban dan Anda akan melihat banyak pendapat tentang topik ini, meskipun tidak ada yang secara langsung menyebutkan layanan mikro).

Mereka berbicara tentang beberapa alat yang akan diberitahu untuk memfasilitasi pembuatan aplikasi tanpa server, tetapi pada akhirnya mereka akan menjadi platform di mana Anda harus membangun semuanya. Saya tidak berpikir itu akan bermanfaat atau membantu seseorang lebih memahami gaya arsitektur.

Sebagai sebuah komunitas, kami memahami bahwa arsitektur tanpa server adalah masa depan. Tetapi transisi dari gaya arsitektur lama tidak akan selalu mudah, bahkan ketika arsitektur tanpa server adalah pilihan yang tepat (dan terkadang tidak tepat).

Ada alasan untuk ini. Tidak mudah mengubah pemikiran seseorang. Sangat mudah untuk membangun fungsi Lambda. Tetapi membuat aplikasi tanpa server yang dirancang dengan baik tidaklah mudah. Karena itu memerlukan perubahan dalam berpikir, dan itu relatif sulit.

Dan seperti yang telah saya katakan beberapa kali, kita harus berhenti mengajar orang-orang aplikasi "halo dunia" dan berhenti pada ini karena banyak orang berpikir bahwa ini akan cukup untuk mereka.

Alasan saya menulis Serverless Best Practices adalah untuk membantu orang memahami bahwa mereka tidak boleh membuat asumsi tentang cara membuat aplikasi tanpa server berdasarkan pengetahuan saat ini.

Alat yang sekarang kami gunakan untuk membuat solusi tanpa server adalah alat yang sama yang kami gunakan untuk membuat aplikasi "cloud 1.0", tetapi mereka tidak sepenuhnya cocok untuk tujuan ini. Alat-alat ini tidak sempurna, tetapi kami mencoba menjelaskan dan membuatnya sebaik mungkin.

Apa yang kami butuhkan dari Anda

Saya pikir bahwa komunitas, pada kenyataannya, sangat terbuka untuk membantu orang dalam pelatihan dan pengembangan dalam menciptakan solusi tanpa server.

Jadi kami, sebagai komunitas, membutuhkan pertanyaan Anda:
- Apa kesulitanmu?
- Di mana celahnya?
- Tutorial apa yang tidak ada?

Dan sesuatu seperti itu.

Saya siap membantu perusahaan melakukan transisi ini. Saya bekerja dengan manajemen senior, CTO dan CEO untuk membantu menentukan nilai apa yang diciptakan perusahaan menggunakan pendekatan tanpa server, dan saya senang membantu perusahaan lain.

Saya sangat senang membantu. Hubungi LinkedIn di sini .