Tanpa server di cloud: AWS vs. Google Cloud vs. Microsoft Azure

Jika Anda pernah bangun pukul 3 pagi karena server rusak, Anda akan memahami daya tarik kata kunci seperti "tanpa server". Mesin dapat memakan waktu berjam-jam, berhari-hari, atau kadang-kadang bahkan berminggu-minggu untuk dikonfigurasi dan kemudian mereka perlu diperbarui terus-menerus untuk memperbaiki bug dan lubang keamanan. Pembaruan ini biasanya membawa kerepotan sendiri karena pembaruan baru menyebabkan inkompatibilitas yang memaksa pembaruan lain atau tampaknya ad infinitum.

Rantai sakit kepala yang tak ada habisnya dari menjalankan server adalah salah satu alasan mengapa perusahaan cloud besar telah menganut arsitektur "tanpa server". Mereka tahu bahwa bos telah mendengar alasannya — server ini, server itu — terlalu lama. Jika kami hanya bisa menyingkirkan server tersebut, bos harus berpikir.

Ini adalah istilah penjualan yang bagus dengan satu-satunya masalah karena itu tidak sepenuhnya benar. Aplikasi ini tanpa server dengan cara yang sama seperti restoran tanpa dapur. Jika yang Anda inginkan ada di menu dan Anda menyukai cara juru masak menyiapkannya, duduk di restoran itu bagus. Tapi kalau mau masakan yang beda, kalau mau bumbu beda ya, lebih baik kamu punya dapur sendiri.

Amazon, Google, dan Microsoft adalah tiga dari perusahaan besar yang berjuang untuk menghosting aplikasi di masa depan, yang mereka harap akan ditulis ke API tanpa server mereka dan dikelola melalui lapisan otomatisasi mereka. Jika platform melakukan apa yang Anda inginkan — dan model baru cukup umum — mereka bisa menjadi cara termudah dan tercepat untuk membuat aplikasi web unicorn bernilai miliaran dolar milik Anda sendiri. Anda hanya menulis sedikit logika penting dan platform menangani semua detail.

Fungsi tanpa server menjadi perekat atau bahasa skrip yang menghubungkan semua fitur cloud. Alat pemetaan atau AI yang dulunya cukup independen sekarang ditautkan melalui fungsi tanpa server yang digerakkan oleh peristiwa. Sekarang, lebih banyak pekerjaan Anda dapat diselesaikan dengan permintaan yang mengalir dan memantul melalui berbagai sudut di setiap awan, yang dipicu dan dipicu oleh aliran peristiwa. Jika Anda ingin menjelajahi pembelajaran mesin dan menggunakannya untuk menganalisis data Anda, salah satu cara tercepat untuk melakukannya adalah dengan membuat aplikasi tanpa server dan mulai mengirim peristiwa ke sudut pembelajaran mesin di awan.

Janji tersiratnya adalah bahwa memotong segala sesuatunya lebih tipis membuatnya lebih mudah untuk berbagi sumber daya di awan. Di masa lalu, semua orang akan dengan panik membuat instance baru dengan, katakanlah, Server Ubuntu berjalan di mesin virtualnya sendiri. Semua orang menggunakan OS yang sama dan itu digandakan jutaan kali di kotak nyata yang sama yang berpura-pura menjadi selusin atau lebih kotak Ubuntu virtual. Operasi tanpa server menghindari semua duplikasi itu, membuat komputasi awan jauh lebih murah, terutama untuk pekerjaan yang berjalan secara sporadis dan tidak pernah benar-benar membuat macet kotak lama yang ada di ruang server ber-AC Anda.

Tentu saja semua kemudahan ini memang memiliki biaya tersembunyi. Jika Anda ingin meninggalkan atau memindahkan kode Anda ke situs lain, Anda mungkin akan terjebak menulis ulang sebagian besar tumpukan. API berbeda, dan meskipun ada beberapa standarisasi seputar bahasa populer seperti JavaScript, mereka cukup dekat dengan kepemilikan. Ada banyak kesempatan untuk mengunci.

Untuk memahami daya tarik opsi tanpa server, saya meluangkan waktu untuk membangun beberapa fungsi dan melihat-lihat tumpukan. Saya tidak menulis banyak kode, tapi itulah intinya. Saya menghabiskan lebih banyak waktu untuk mengklik tombol dan mengetik ke dalam formulir web untuk mengkonfigurasi semuanya. Apakah Anda ingat ketika kami mengonfigurasi semuanya dengan XML dan kemudian JSON? Sekarang kami mengisi formulir web dan cloud melakukannya untuk kami. Anda masih harus berpikir seperti seorang programmer, untuk memahami apa yang terjadi di balik layar dan di luar kendali Anda.

AWS Lambda

AWS Lambda berkembang menjadi lapisan skrip shell untuk seluruh cloud Amazon. Ini adalah sistem dasar yang memungkinkan Anda menyematkan fungsi yang merespons peristiwa yang mungkin dihasilkan oleh hampir semua bagian dari infrastruktur cloud Amazon yang luas. Jika file baru diunggah ke S3, Anda bisa membuatnya memicu fungsi yang melakukan sesuatu yang menarik dengannya. Jika beberapa video sedang ditranskode oleh Amazon Elastic Transcoder, Anda mungkin memiliki fungsi Lambda yang menunggu untuk dipicu saat selesai. Fungsi-fungsi ini, pada gilirannya, dapat memicu operasi Lambda lainnya atau mungkin hanya mengirim pembaruan kepada seseorang.

Anda dapat menulis fungsi Lambda di JavaScript (Node.js), Python, Java, C #, dan Go. Mengingat bahwa bahasa-bahasa ini dapat menyematkan banyak bahasa lain, sangat mungkin untuk menjalankan kode lain seperti Haskell, Lisp, atau bahkan C ++. (Lihat cerita ini tentang mengompilasi C ++ lama ke pustaka untuk digunakan dengan AWS Lambda.)

Menulis fungsi Lambda seringkali terasa jauh lebih rumit daripada yang Anda harapkan karena Amazon menawarkan begitu banyak opsi untuk konfigurasi dan pengoptimalan. Meskipun secara teknis benar bahwa Anda dapat menulis hanya beberapa baris kode dan mencapai hal-hal hebat, saya merasa seperti saya kemudian harus mengalokasikan lebih banyak waktu untuk mengonfigurasi cara kode berjalan. Banyak dari ini dilakukan dengan mengisi formulir di browser alih-alih mengetik ke dalam file teks. Terkadang terasa seperti kami baru saja menukar editor teks untuk formulir browser, tetapi itulah harga untuk mempertahankan semua fleksibilitas yang diperluas Amazon kepada pengguna Lambda.

Beberapa langkah tambahan disebabkan Amazon memaparkan lebih banyak opsi kepada pengguna dan mengharapkan lebih banyak dari penulis fungsi pertama kali. Setelah saya selesai menulis fungsi di Google atau Microsoft, saya dapat mengarahkan browser saya ke URL yang benar dan segera mengujinya. Amazon meminta saya mengklik untuk mengonfigurasi gateway API dan membuka lubang yang tepat di firewall.

Pada akhirnya, semua klik ini menambahkan lapisan pegangan yang membuat pekerjaan sedikit lebih mudah daripada memulai dengan file teks. Saat saya membuat satu fungsi, browser mendapat peringatan, "Fungsi ini berisi pustaka eksternal". Kembali ke masa Node murni, itu adalah sesuatu yang saya harapkan untuk mengetahuinya, atau saya akan mempelajarinya dengan Googling pesan kesalahan sambil menyilangkan jari saya dan berharap jawabannya ada di luar sana. Sekarang awan sedang bergegas untuk membantu.

Amazon memiliki sejumlah opsi lain yang sama "tanpa server" seperti AWS Lambda, jika tanpa server berarti membebaskan Anda dari pekerjaan manajemen server. Ini memiliki alat elastis seperti Amazon EC2 Auto Scaling dan AWS Fargate yang memutar dan mematikan server, dan AWS Elastic Beanstalk, yang mengambil kode yang Anda unggah, menyebarkannya ke server web, dan menangani load balancing dan penskalaan. Tentu saja, dengan banyak alat otomasi ini, Anda masih bertanggung jawab untuk membuat image server.

Salah satu penawaran yang lebih berguna adalah AWS Step Functions, semacam alat diagram alur tanpa kode untuk membuat mesin status guna memodelkan alur kerja yang oleh arsitek perangkat lunak disebut. Sebagian dari masalahnya adalah bahwa semua fungsi tanpa server dimaksudkan untuk sepenuhnya bebas dari status, sesuatu yang berfungsi ketika Anda menerapkan logika bisnis yang cukup mendasar tetapi itu bisa menjadi sedikit mimpi buruk ketika Anda menuntun beberapa klien melalui sebuah daftar periksa atau diagram alur. Anda terus-menerus membuka database untuk memuat ulang informasi tentang klien. Step Functions merekatkan fungsi Lambda dengan status.

Google Cloud Functions dan Firebase

Jika Anda ingin menghilangkan kerumitan mengonfigurasi server, Google Cloud memiliki sejumlah layanan yang menawarkan berbagai kebebasan dari hal-hal seperti memerlukan kata sandi root atau bahkan menggunakan baris perintah sama sekali.

Dimulai dengan Google App Engine pada tahun 2008, Google perlahan-lahan menambahkan berbagai opsi "tanpa server" dengan berbagai kombinasi perpesanan dan transparansi data. Yang disebut Google Cloud Pub / Sub menyembunyikan antrean perpesanan dari Anda sehingga yang perlu Anda lakukan hanyalah menulis kode untuk produsen data dan konsumen. Google Cloud Functions menawarkan penghitungan berbasis peristiwa untuk banyak produk utama termasuk beberapa alat marquee dan API. Lalu ada Google Firebase, database tentang steroid yang memungkinkan Anda mencampur kode JavaScript ke dalam lapisan penyimpanan data yang mengirimkan data ke klien Anda.

Dari jumlah tersebut, Firebase adalah yang paling menarik bagi saya. Beberapa menyarankan bahwa database adalah aplikasi tanpa server asli, yang mengabstraksi struktur data dan tugas penyimpanan disk untuk mengirimkan semua informasi melalui port TCP / IP. Firebase mengambil abstraksi ini secara ekstrem dengan menambahkan kode JavaScript dan perpesanan untuk melakukan hampir semua hal yang mungkin ingin Anda lakukan dengan infrastruktur sisi server termasuk otentikasi. Secara teknis ini hanya database tetapi ini adalah salah satu yang dapat menangani banyak logika bisnis dan perpesanan untuk tumpukan Anda. Anda benar-benar bisa mendapatkan sedikit HTML klien, CSS, JavaScript, dan Firebase.

Anda mungkin tergoda untuk menyebut lapisan JavaScript Firebase sebagai "prosedur tersimpan", seperti yang dilakukan Oracle, tetapi itu akan kehilangan gambaran yang lebih besar. Kode Firebase ditulis dalam JavaScript sehingga akan berjalan di versi lokal Node.js. Anda dapat menyematkan banyak logika bisnis di lapisan ini karena dunia Node sudah diisi dengan pustaka untuk menangani alur kerja ini. Ditambah Anda akan menikmati kesenangan kode isomorfik yang berjalan di klien, server, dan sekarang database.

Bagian yang menarik perhatian saya adalah lapisan sinkronisasi yang dibangun ke dalam Firebase. Ini akan menyinkronkan salinan objek dari database di seluruh jaringan. Triknya adalah Anda dapat menyiapkan aplikasi klien Anda hanya sebagai node database lain yang berlangganan semua perubahan untuk data yang relevan (dan hanya data yang relevan). Jika data berubah di satu tempat, itu berubah di mana-mana. Anda dapat menghindari semua kerumitan pengiriman pesan dan berkonsentrasi hanya untuk menulis informasi ke Firebase karena Firebase akan mereplikasi di tempat yang diperlukan.

Anda tidak perlu fokus hanya pada Firebase. Google Cloud Functions yang lebih mendasar adalah pendekatan yang lebih sederhana untuk menyematkan kode khusus di seluruh Google cloud. Saat ini, Cloud Functions sebagian besar hanya merupakan opsi untuk menulis kode Node.js yang akan berjalan di lingkungan Node yang telah dikonfigurasi sebelumnya. Sementara Google Cloud Platform lainnya mendukung berbagai bahasa — dari Java dan C # hingga Go, Python, dan PHP — Cloud Functions sangat terbatas pada JavaScript dan Node. Ada petunjuk bahwa pilihan bahasa lain akan datang dan saya tidak akan terkejut jika mereka segera muncul.

Google Cloud Functions tidak menjangkau Google Cloud sedalam seperti yang dijangkau AWS Lambda ke AWS, setidaknya pada saat ini. Ketika saya melihat-lihat untuk membangun sebuah fungsi untuk berinteraksi dengan Google Docs, saya menemukan bahwa saya mungkin harus menggunakan REST API dan menulis kode dalam sesuatu yang disebut Apps Script. Dengan kata lain, dunia Google Docs memiliki REST API-nya sendiri yang tidak memiliki server jauh sebelum kata kunci diciptakan.

Perlu dicatat bahwa Google App Engine terus berkembang pesat. Pada awalnya, ia hanya menawarkan untuk menjalankan aplikasi Python untuk memenuhi permintaan siapa pun yang datang ke situs web, tetapi telah diperpanjang selama bertahun-tahun untuk menangani banyak runtime bahasa yang berbeda. Setelah Anda memaketkan kode menjadi file yang dapat dieksekusi, App Engine menangani proses memulai cukup node untuk menangani lalu lintas Anda, meningkatkan atau menurunkan skala saat pengguna mengirim permintaan.

Masih ada beberapa rintangan yang perlu diingat. Seperti Cloud Functions, kode Anda harus ditulis dengan cara yang relatif tanpa kewarganegaraan, dan harus menyelesaikan setiap permintaan dalam waktu yang terbatas. Tetapi App Engine tidak membuang semua perancah atau melupakan semuanya di antara permintaan. App Engine adalah bagian besar dari revolusi tanpa server dan tetap menjadi yang paling mudah diakses oleh mereka yang tidak pernah berhenti menggunakan metode jadul untuk membuat tumpukan mereka sendiri dengan Python, PHP, Java, C #, atau Go.

Fungsi Microsoft Azure

Microsoft, tentu saja, bekerja sama kerasnya dengan yang lain untuk memastikan bahwa semua orang dapat melakukan semua hal cerdas tanpa server ini dengan awan Azure juga. Perusahaan telah membuat fungsi dasarnya sendiri untuk menyulap acara — Fungsi Azure — dan membuat beberapa alat canggih yang bahkan lebih dapat diakses oleh semi-pemrogram.

Keuntungan terbesar yang mungkin dimiliki Microsoft adalah kumpulan aplikasi Office-nya, eksekutabel desktop sebelumnya yang perlahan tapi pasti bermigrasi ke cloud. Memang, salah satu penghitungan pendapatan cloud menempatkan Microsoft di atas Amazon, sebagian dengan menggabungkan sebagian pendapatan Office-nya ke dalam rubrik singkat "cloud".

Salah satu contoh terbaik dari dokumentasi Azure Functions memperlihatkan bagaimana fungsi cloud dapat dipicu saat seseorang menyimpan spreadsheet ke OneDrive. Tiba-tiba peri kecil di cloud menjadi hidup dan melakukan berbagai hal ke spreadsheet. Ini pasti akan menjadi berkah bagi toko-toko TI yang mendukung tim yang menyukai spreadsheet Excel mereka (atau dokumen Office lainnya). Mereka dapat menulis Azure Functions untuk melakukan apa saja. Kami sering berpikir bahwa HTML dan web adalah satu-satunya antarmuka ke cloud, tetapi tidak ada alasan mengapa tidak dapat melalui format dokumen seperti Microsoft Word atau Excel.