Tanpa pelayan di awan: AWS vs Google Cloud vs Microsoft Azure

Sekiranya anda pernah bangun pada pukul 3 pagi kerana pelayan tidak berfungsi, anda akan memahami tarikan kata kunci seperti "tanpa pelayan." Mesin boleh memakan masa berjam-jam, berhari-hari, atau kadang-kadang bahkan berminggu-minggu untuk dikonfigurasikan dan kemudian mereka perlu sentiasa dikemas kini untuk memperbaiki bug dan lubang keselamatan. Kemas kini ini biasanya menimbulkan kerumitan kerana kemas kini baru menyebabkan ketidaksesuaian yang memaksa kemas kini lain atau sehingga nampaknya tidak terhingga.

Rantai pening kepala yang tidak berkesudahan dari menjalankan pelayan adalah salah satu sebab syarikat awan utama menerapkan seni bina "tanpa pelayan". Mereka tahu bahawa bos telah mendengar alasan - pelayan ini, pelayan yang - terlalu lama. Sekiranya kita hanya dapat menyingkirkan pelayan tersebut, bos mesti berfikir.

Ini adalah istilah penjualan yang indah dengan satu-satunya masalah kerana ia tidak benar. Aplikasi ini tanpa pelayan dengan cara yang sama seperti restoran tanpa dapur. Sekiranya apa yang anda mahukan ada di menu dan anda suka bagaimana tukang masak menyiapkannya, duduk di restoran sangat bagus. Tetapi jika anda mahukan hidangan yang berbeza, jika anda mahukan rempah yang berbeza, lebih baik anda mendapatkan dapur anda sendiri.

Amazon, Google, dan Microsoft adalah tiga syarikat besar yang berjuang untuk menjadi tuan rumah aplikasi masa depan, syarikat yang mereka harapkan akan ditulis ke API tanpa pelayan mereka dan dikendalikan melalui lapisan automasi mereka. Sekiranya platform melakukan apa yang anda mahukan - dan model baru cukup umum - mereka boleh menjadi kaedah termudah dan terpantas untuk membuat aplikasi web unicorn bernilai berbilion dolar anda sendiri. Anda hanya menulis logik penting dan platform menangani semua butirannya.

Fungsi tanpa server menjadi gam atau bahasa skrip yang menghubungkan semua ciri awan. Alat pemetaan atau AI yang dulunya cukup bebas kini dihubungkan melalui fungsi tanpa pelayan yang digerakkan oleh acara. Kini lebih banyak kerja anda dapat diselesaikan dengan permintaan yang bergelombang dan melantun di pelbagai sudut setiap awan, memicu dan dipicu oleh arus peristiwa. Sekiranya anda ingin meneroka pembelajaran mesin dan menggunakannya untuk menganalisis data anda, salah satu kaedah terpantas untuk melakukannya adalah dengan membuat aplikasi tanpa pelayan dan mula menghantar acara ke sudut pembelajaran mesin di awan.

Janji tersirat adalah bahawa memotong segala sesuatu yang lebih tipis menjadikannya lebih mudah untuk berkongsi sumber di awan. Pada masa lalu, semua orang dengan panik akan membuat contoh baru dengan, katakanlah, Ubuntu Server berjalan di mesin maya sendiri. Semua orang menggunakan OS yang sama dan digandakan sebanyak zillion kali pada kotak sebenar yang sama yang berpura-pura menjadi belasan atau lebih kotak Ubuntu maya. Operasi tanpa server mengelakkan semua penduaaan itu, menjadikan pengkomputeran awan jauh lebih murah, terutamanya untuk pekerjaan yang berjalan secara sporadis dan tidak pernah benar-benar menyekat kotak lama yang duduk di ruang pelayan berhawa dingin anda.

Sudah tentu semua kemudahan ini mempunyai kos tersembunyi. Sekiranya anda ingin meninggalkan atau memindahkan kod anda ke laman web lain, anda mungkin akan tersekat menulis semula sebahagian besar timbunan. API berbeza, dan walaupun terdapat beberapa penyeragaman di sekitar bahasa popular seperti JavaScript, API tersebut hampir sama dengan hak milik. Terdapat banyak peluang untuk kunci masuk.

Untuk memahami daya tarikan pilihan tanpa pelayan, saya meluangkan masa untuk membina beberapa fungsi dan menoleh di sekitar timbunan. Saya tidak menulis banyak kod, tetapi itulah intinya. Saya menghabiskan lebih banyak masa untuk mengklik butang dan menaip borang web untuk mengkonfigurasi semuanya. Adakah anda ingat ketika kami mengkonfigurasi semuanya dengan XML dan kemudian JSON? Sekarang kami mengisi borang web dan awan melakukannya untuk kami. Anda masih perlu berfikir seperti pengaturcara, untuk memahami apa yang berlaku di sebalik tabir dan di luar kawalan anda.

AWS Lambda

AWS Lambda berkembang menjadi lapisan skrip shell untuk seluruh awan Amazon. Ini adalah sistem asas yang membolehkan anda menyematkan fungsi yang bertindak balas terhadap peristiwa yang mungkin dihasilkan oleh hampir semua bahagian infrastruktur awan Amazon yang luas. Sekiranya fail baru diunggah ke S3, anda mungkin memicu fungsi yang melakukan sesuatu yang menarik dengannya. Sekiranya beberapa video sedang di-transkod oleh Amazon Elastic Transcoder, anda mungkin mempunyai fungsi Lambda yang menunggu untuk dicetuskan ketika selesai. Fungsi-fungsi ini, pada gilirannya, dapat mencetuskan operasi Lambda yang lain atau mungkin hanya memberi kemas kini kepada seseorang.

Anda boleh menulis fungsi Lambda dalam JavaScript (Node.js), Python, Java, C #, dan Go. Memandangkan bahasa-bahasa ini dapat menyematkan banyak bahasa lain, sangat mustahil untuk menjalankan kod lain seperti Haskell, Lisp, atau bahkan C ++. (Lihat kisah ini tentang menyusun C ++ warisan ke perpustakaan untuk digunakan dengan AWS Lambda.)

Menulis fungsi Lambda sering terasa jauh lebih kompleks daripada yang anda jangkakan kerana Amazon menawarkan begitu banyak pilihan untuk konfigurasi dan pengoptimuman. Walaupun secara teknikalnya benar bahawa anda boleh menulis beberapa baris kod dan menyelesaikan perkara-perkara hebat, saya rasa saya terpaksa memperuntukkan lebih banyak masa untuk mengkonfigurasi bagaimana kod tersebut berjalan. Sebilangan besar ini dapat dicapai dengan mengisi borang di penyemak imbas dan bukannya menaip fail teks. Kadang-kadang terasa seperti kita baru saja memperdagangkan editor teks untuk borang penyemak imbas, tetapi itulah harga untuk mengekalkan semua fleksibiliti yang diberikan oleh Amazon kepada pengguna Lambda.

Beberapa langkah tambahan adalah kerana Amazon mendedahkan lebih banyak pilihan kepada pengguna dan mengharapkan lebih banyak penulis fungsi kali pertama. Setelah selesai menulis fungsi di Google atau Microsoft, saya dapat mengarahkan penyemak imbas saya ke URL yang betul dan segera mengujinya. Amazon meminta saya mengklik untuk mengkonfigurasi gerbang API dan membuka lubang kanan di firewall.

Pada akhirnya, semua klik ini menambahkan lapisan pegangan tangan yang menjadikan pekerjaan sedikit lebih mudah daripada bermula dengan fail teks. Ketika saya membuat satu fungsi, penyemak imbas mempunyai peringatan, "Fungsi ini berisi perpustakaan luaran." Kembali pada hari-hari Node yang murni, itu adalah sesuatu yang diharapkan saya tahu, atau saya akan mempelajarinya dengan Googling mesej ralat sambil menyilangkan jari saya dan berharap jawapannya ada di luar sana. Kini awan bergegas masuk untuk membantu.

Amazon mempunyai sejumlah pilihan lain yang hampir sama seperti "tanpa pelayan" seperti AWS Lambda, jika tanpa pelayan bermaksud melepaskan anda dari tugas pengurusan pelayan. Ia mempunyai alat elastik seperti Amazon EC2 Auto Scaling dan AWS Fargate yang berputar dan mematikan pelayan, dan AWS Elastic Beanstalk, yang mengambil kod yang anda muat naik, menyebarkannya ke pelayan web, dan menangani pengimbangan dan penimbangan beban. Sudah tentu, dengan banyak alat automasi ini, anda masih bertanggungjawab untuk membuat imej pelayan.

Salah satu tawaran yang lebih berguna ialah AWS Step Functions, sejenis alat carta alir tanpa kod untuk membuat mesin keadaan untuk memodelkan apa yang disebut oleh arkitek perisian aliran kerja. Sebahagian daripada masalahnya adalah bahawa semua fungsi tanpa pelayan dimaksudkan untuk bebas sepenuhnya dari keadaan, sesuatu yang berfungsi ketika anda menerapkan logik perniagaan yang cukup asas tetapi itu boleh menjadi mimpi buruk ketika anda menjalankan beberapa pelanggan melalui senarai semak atau carta alir. Anda sentiasa pergi ke pangkalan data untuk memuatkan maklumat mengenai pelanggan. Fungsi Langkah-langkah melekatkan fungsi Lambda dengan keadaan.

Fungsi Awan Google dan Firebase

Sekiranya menghilangkan kerumitan dalam mengkonfigurasi pelayan adalah tujuan anda, Google Cloud mempunyai sejumlah perkhidmatan yang menawarkan pelbagai kebebasan dari perkara seperti memerlukan kata laluan root atau bahkan menggunakan baris perintah sama sekali.

Bermula dengan Google App Engine pada tahun 2008, Google perlahan-lahan menambahkan pilihan "tanpa server" yang berbeza dengan pelbagai kombinasi pemesejan dan ketelusan data. Satu yang dipanggil Google Cloud Pub / Sub menyembunyikan barisan pesanan dari anda sehingga yang perlu anda lakukan hanyalah menulis kod untuk pengeluar data dan pengguna. Google Cloud Functions menawarkan perhitungan berdasarkan acara untuk banyak produk utama termasuk beberapa alat dan API tenda. Dan kemudian ada Google Firebase, pangkalan data mengenai steroid yang membolehkan anda mencampurkan kod JavaScript ke lapisan penyimpanan data yang menyampaikan data kepada pelanggan anda.

Daripada jumlah ini, Firebase adalah yang paling menarik bagi saya. Sebilangan orang berpendapat bahawa pangkalan data adalah aplikasi tanpa pelayan yang asli, mengasingkan struktur data dan tugas penyimpanan cakera untuk menyampaikan semua maklumat melalui port TCP / IP. Firebase mengambil penekanan ini secara ekstrim dengan menambahkan kod JavaScript dan pesanan untuk melakukan hampir semua perkara yang mungkin anda mahu lakukan dengan infrastruktur sisi pelayan termasuk pengesahan. Secara teknikal, ia hanya pangkalan data tetapi ia boleh mengendalikan banyak logik dan pesanan perniagaan untuk timbunan anda. Anda benar-benar dapat melepaskan diri dengan sedikit HTML klien, CSS, JavaScript, dan Firebase.

Anda mungkin tergoda untuk memanggil lapisan JavaScript Firebase sebagai "prosedur tersimpan," seperti yang dilakukan Oracle, tetapi itu akan kehilangan gambaran yang lebih besar. Kod Firebase ditulis dalam JavaScript sehingga akan berjalan dalam versi tempatan Node.js. Anda boleh menanamkan banyak logik perniagaan di lapisan ini kerana dunia Node sudah dipenuhi dengan perpustakaan untuk menangani aliran kerja ini. Anda juga akan menikmati keseronokan kod isomorfik yang dijalankan pada pelanggan, pelayan, dan sekarang pangkalan data.

Bahagian yang menarik perhatian saya adalah lapisan penyegerakan yang dibina di Firebase. Ia akan menyegerakkan salinan objek dari pangkalan data di seluruh rangkaian. Caranya ialah anda boleh menyiapkan aplikasi pelanggan anda sebagai simpul pangkalan data lain yang melanggan semua perubahan untuk data yang relevan (dan hanya data yang relevan). Sekiranya data berubah di satu tempat, ia berubah di mana sahaja. Anda boleh mengelakkan semua kerumitan pemesejan dan menumpukan perhatian hanya pada menulis maklumat tersebut kepada Firebase kerana Firebase akan menirunya di tempat yang sepatutnya.

Anda tidak perlu fokus hanya pada Firebase. Fungsi Awan Google yang lebih asas adalah pendekatan yang lebih mudah untuk memasukkan kod tersuai di seluruh awan Google. Pada masa ini, Cloud Functions sebahagian besarnya hanyalah pilihan untuk menulis kod Node.js yang akan dijalankan dalam persekitaran Node yang telah dikonfigurasi sebelumnya. Sementara Google Cloud Platform yang lain menyokong pelbagai bahasa — dari Java dan C # hingga Go, Python, dan PHP — Cloud Functions hanya terhad pada JavaScript dan Node. Terdapat petunjuk bahawa pilihan bahasa lain akan datang dan saya tidak akan terkejut jika mereka segera muncul.

Fungsi Awan Google tidak sampai ke Awan Google sedalam AWS Lambda menjangkau AWS, sekurang-kurangnya pada ketika ini. Ketika saya melihat-lihat bagaimana membina fungsi untuk berinteraksi dengan Google Docs, saya mendapati bahawa saya mungkin perlu menggunakan REST API dan menulis kod dalam sesuatu yang disebut Apps Script. Dengan kata lain, dunia Google Docs mempunyai REST API sendiri yang tidak dilayan lama sebelum kata kunci diciptakan.

Perlu diingat bahawa Google App Engine terus maju. Pada awalnya, ia hanya menawarkan untuk menambah aplikasi Python untuk memenuhi permintaan siapa pun yang datang ke laman web, tetapi telah diperpanjang selama bertahun-tahun untuk menangani banyak masa berjalan bahasa yang berbeza. Sebaik sahaja anda menggabungkan kod anda menjadi yang dapat dieksekusi, App Engine menangani proses memulakan node yang cukup untuk menangani lalu lintas anda, menaikkan atau turun ketika pengguna anda mengirim permintaan.

Masih ada beberapa rintangan yang perlu diingat. Seperti Cloud Functions, kod anda mesti ditulis dengan cara yang tidak bernegara, dan mesti menyelesaikan setiap permintaan dalam jangka masa yang terhad. Tetapi App Engine tidak membuang semua perancah atau melupakan semua permintaan. App Engine adalah sebahagian besar dari revolusi tanpa pelayan dan ia tetap paling mudah diakses oleh mereka yang menggunakan satu kaedah untuk menggunakan timbunan mereka sendiri di Python, PHP, Java, C #, atau Go.

Fungsi Microsoft Azure

Microsoft, tentu saja, bekerja sama seperti yang lain untuk memastikan bahawa orang dapat melakukan semua perkara tanpa pelayan pintar ini dengan awan Azure juga. Syarikat ini telah mencipta fungsi asasnya sendiri untuk acara juggling - Azure Functions - dan membina beberapa alat canggih yang bahkan lebih mudah diakses oleh separa programmer.

Kelebihan terbesar yang mungkin dimiliki Microsoft adalah koleksi aplikasi Office, bekas eksekutif desktop yang perlahan tetapi pasti berpindah ke awan. Sesungguhnya satu perakaunan pendapatan awan meletakkan Microsoft lebih awal daripada Amazon, sebahagiannya dengan memasukkan sebahagian hasil Pejabatnya ke rubrik singkat "awan."

Salah satu contoh terbaik dari dokumentasi Fungsi Azure menunjukkan bagaimana fungsi awan dapat dicetuskan ketika seseorang menyimpan spreadsheet ke OneDrive. Tiba-tiba bunian kecil di awan menjadi hidup dan melakukan perkara ke hamparan. Ini pasti menjadi anugerah kepada kedai IT yang menyokong pasukan yang menyukai spreadsheet Excel mereka (atau dokumen Office lain). Mereka boleh menulis Fungsi Azure untuk melakukan apa sahaja. Kami sering berfikir bahawa HTML dan web adalah satu-satunya antara muka ke awan tetapi tidak ada sebab mengapa ia tidak dapat melalui format dokumen seperti Microsoft Word atau Excel.