Cara Mudah untuk Komputasi Tanpa Server

Komputasi tanpa server itu sendiri (secara harfiah "tanpa server") mendapatkan popularitas yang luas pada tahun 2014 setelah pengumuman AWS Lambda - salah satu platform Tanpa Server pertama. Sejak saat itu, popularitas pendekatan Tanpa Server hanya tumbuh, tetapi perkembangan alat, sayangnya, tidak mengimbangi.



Nama saya Vladislav Tankov, pada 2018-2020 saya belajar di program master perusahaan JetBrains di ITMO, dan sejak 2017 saya telah bekerja di JetBrains .



Pada musim panas 2018, di hackathon JetBrains, beberapa rekan saya dan saya mencoba membuat alat untuk bahasa Kotlin yang menyederhanakan pembuatan aplikasi Tanpa Server dengan menganalisis kode aplikasi.



Setelah hackathon, sudah dalam kerangka kerja ilmiah dalam program master korporat di JetBrains, saya memutuskan untuk melanjutkan pengembangan proyek ini. Dalam dua tahun, fitur tersebut telah memperluas dan memperoleh fungsionalitas secara signifikan, tetapi tetap menggunakan namanya - Kotless , atau Kotlin Serverless Framework.



Apa itu Tanpa Server



Pertama, mari kita ingat apa yang terdiri dari platform komputasi Tanpa Server yang paling sederhana. Platform semacam itu mencakup tiga komponen utama:



  • sistem eksekusi fungsi Tanpa server - aplikasi kecil yang memproses peristiwa tertentu;
  • sekumpulan antarmuka yang berbeda dari dunia luar (atau platform cloud seperti AWS) ke sistem acara platform, seperti antarmuka HTTP;
  • sistem peristiwa itu sendiri, yang menyediakan transfer peristiwa dari antarmuka ke fungsi dan hasil pemrosesan dari fungsi ke antarmuka.


Ketiga komponen ini cukup untuk membangun aplikasi yang cukup kompleks. Misalnya, aplikasi web hanyalah antarmuka HTTP eksternal (dalam kasus AWS, ini akan menjadi APIGateway ) dan untuk setiap sumber daya yang diproses (seperti / rute / my ) fungsi penanganan Serverless-nya sendiri. Anda dapat membuat aplikasi yang lebih kompleks yang menggunakan database dan memanggil sendiri fungsi Tanpa Server lainnya, seperti pada gambar.



Oke, Anda bisa membangun aplikasi seperti itu, tapi kenapa?



Aplikasi tanpa server memiliki beberapa keunggulan menarik yang membenarkan arsitektur yang jongkok.



  • Fungsi tanpa server tidak berfungsi saat tidak diperlukan. Memang, fungsi hanya memproses peristiwa - mengapa harus menggunakan sumber daya komputasi jika tidak ada peristiwa?
  • Fungsi tanpa server dapat menangani acara dengan jenis yang sama secara paralel. Artinya, jika / route / my telah menjadi sangat populer dan ribuan pengguna memintanya sekaligus, maka platform Tanpa Server dapat dengan mudah meluncurkan 1000 penangan, satu per acara.


Bersama-sama, poin-poin ini menambahkan hingga, mungkin, salah satu mantra terpenting Tanpa Server: aplikasi Tanpa Server berskala dari nol hingga tak terbatas. Aplikasi semacam itu tidak menghabiskan uang saat tidak diminati, dan mampu memproses ribuan permintaan per detik saat dibutuhkan.



Masalah



Mari kita lihat contoh yang sangat sederhana dalam bahasa Kotlin:



@Get("/my/route")
fun handler() = "Hello World"


Sangat jelas bahwa aplikasi semacam itu dapat diimplementasikan dengan menggunakan pendekatan Tanpa Server. Sekilas, cukup membuat antarmuka HTTP dengan beberapa alamat DNS dan memetakan / my / route ke fun handler () .



Faktanya, membuat aplikasi seperti itu membutuhkan lebih dari sekadar menambahkan satu anotasi. Misalnya, dalam kasus AWS:



  • Anda perlu menerapkan antarmuka penangan kejadian tertentu, dalam hal ini RequestStreamHandler.
  • Anda perlu mendeskripsikan infrastruktur aplikasi Tanpa Server: mendeskripsikan HTTP API aplikasi, mendeskripsikan semua fungsi handler, dan mengaitkan fungsinya dengan antarmuka, dengan hati-hati memilih izin.
  • Terakhir, Anda harus mengumpulkan semua fungsi penangan, memuat ke dalam platform Tanpa Server, dan menerapkan infrastruktur yang sesuai.


Tidak sedikit langkah untuk aplikasi sederhana seperti itu, bukan?



Bagi mereka yang diinisiasi ke dalam Sakramen Infrastruktur sebagai Kode, saya akan mencatat bahwa, tentu saja, sebagian dari proses dapat diotomatiskan, tetapi otomatisasi ini sendiri memerlukan studi tentang pendekatan yang benar-benar baru (pada kenyataannya, menggambarkan infrastruktur sebagai kode) dan bahasa baru. Ini sepertinya tugas sulit yang tidak perlu bagi pengembang yang ingin menerapkan aplikasi yang belum sempurna.



Apakah mungkin melakukan sesuatu yang lebih mudah? Dalam beberapa kasus (dan khususnya dalam hal ini) - ya!



Infrastruktur dalam Kode



Mari kita lihat sisi lain: alih-alih memaksa pengguna untuk mendeskripsikan infrastruktur, kami akan mencoba mengambilnya dari kode pengguna yang sudah tertulis.



Perhatikan lagi contoh yang sama:



@Get("/my/route")
fun handler() = "Hello World"


Kita tahu pengguna ingin permintaan ke / my / route ditangani oleh fungsi ini - jadi mari kita sintesis infrastruktur yang akan membuat HTTP API dengan / my / route , buat fungsi Serverless yang diperlukan, dan lakukan semua keajaiban yang diperlukan untuk menghubungkannya!



Dalam artikel saya di Automated Software Engineering 2019, saya menyebut pendekatan ini Infrastruktur dalam Kode. Faktanya, kami mengekstrak deskripsi infrastruktur dari kode aplikasi yang mendefinisikannya secara implisit, yaitu, itu sebenarnya berisi "di dalam" kode.



Perlu dicatat bahwa selanjutnya, hanya sintesis aplikasi HTTP API yang dipertimbangkan. Pendekatan serupa dapat digunakan untuk memproses antrian dan untuk memproses peristiwa di platform cloud, tetapi ini adalah masalah pengembangan Kotless lebih lanjut.



Penerapan



Semoga pada poin ini idenya jelas dan ada tiga pertanyaan utama yang tersisa:



  • Bagaimana cara mengekstrak informasi dari kode?
  • Bagaimana cara membuat infrastruktur berdasarkan informasi ini?
  • Bagaimana cara menjalankan aplikasi di cloud?


Analisis



Kotlin Compiler Embeddable akan membantu kita dalam hal ini.



Terlepas dari kenyataan bahwa contohnya adalah tentang anotasi, pada kenyataannya, API HTTP dari aplikasi, bergantung pada pustaka yang digunakan, dapat didefinisikan dengan cara yang sangat berbeda, misalnya:



//ktor-like style
get("my-route") {
    "Hello World"
}


Untuk menganalisis kode arbitrer, Kotlin Compiler Embeddable ternyata lebih familiar dan lebih nyaman (karena banyaknya contoh).



Saat ini, Kotless dapat menganalisis tiga framework utama:



  • Kotless DSL - framework anotasi milik Kotless sendiri
  • Spring Boot adalah kerangka kerja Web yang populer, anotasi diurai;
  • Ktor adalah kerangka kerja Kotlin Web yang populer, fungsi ekstensi dianalisis.


Dalam proses menganalisis kode, Skema Kotless dikumpulkan - ini adalah representasi aplikasi Tanpa Server yang tidak bergantung platform. Ini digunakan untuk mensintesis infrastruktur dan membuat proses analisis tidak bergantung pada platform cloud tertentu.



Perpaduan



Kami akan mensintesis kode Terraform. Terraform dipilih sebagai salah satu Infrastruktur terpopuler sebagai alat Kode dengan berbagai platform cloud yang didukung, yang memastikan Kotless mampu mendukung platform cloud baru dan stabilitas dalam penerapan aplikasi.



Sintesis dibuat dari Skema Kotless, yang berisi deskripsi API HTTP aplikasi dan fungsinya, serta beberapa data tambahan (misalnya, nama DNS yang diinginkan).



Untuk sintesis itu sendiri, perpustakaan DSL Terraform yang dibuat khusus digunakan. Kode sintesis terlihat seperti ini:



val resource = api_gateway_rest_api("tf_name") {
    name = "aws_name"
    binary_media_types = arrayOf(MimeType.PNG)
}


DSL menjamin pemformatan dan integritas referensial antara resource Terraform yang berbeda, yang sangat menyederhanakan perluasan kumpulan resource yang disintesis.



Kode yang disintesis disebarkan ke platform awan dengan aplikasi Terraform sederhana.



Lari



Tetap menjalankan aplikasi pada platform Tanpa Server. Seperti yang telah disebutkan, semua fungsi Tanpa Server pada dasarnya adalah penangan untuk beberapa acara, dalam kasus kami, permintaan HTTP.



Diperlukan untuk menghubungkan kerangka kerja yang digunakan untuk membuat aplikasi (misalnya, Spring Boot) dan platform Tanpa Server. Untuk melakukannya, pada saat membuat aplikasi, Kotless menambahkan "petugas operator" khusus ke kode aplikasi - penangan kejadian khusus platform yang berfungsi sebagai adaptor antara kerangka kerja yang digunakan dalam aplikasi dan platform awan.



Alat



Alat itu sendiri, yang menyertakan seluruh pipeline yang dijelaskan untuk membuat infrastruktur, diimplementasikan sebagai plugin ke sistem build Gradle. Selain itu, semua modul utama adalah pustaka terpisah, yang sangat menyederhanakan dukungan sistem build lain.



Menggunakan plugin itu mudah. Setelah konfigurasi, pengguna hanya memiliki satu tugas Gradle - terapkan , yang mengambil semua langkah yang diperlukan untuk menerapkan aplikasi saat ini ke awan.



Kustomisasi dari sisi pengguna juga cukup mudah. Plugin itu sendiri diterapkan terlebih dahulu:



plugins {
  io("io.kotless") version "0.1.5" apply true
}


Setelah itu, pengguna menambahkan kerangka kerja yang dia butuhkan:



dependencies {
  //Kotless DSL 
  implementation("io.kotless", "lang", "0.1.5")
}


Terakhir, ini menyiapkan akses ke AWS sehingga Kotless dapat menerapkan:



kotless {
  config {
    bucket = "kotless.s3.example.com"

    terraform {
      profile = "example"
      region = "us-east-1"
    }
  }
}


Peluncuran lokal



Sangat mudah untuk melihat bahwa poin terakhir mengharuskan pengguna untuk terbiasa dengan AWS dan memiliki setidaknya akun AWS. Persyaratan tersebut membuat takut pengguna yang ingin mencoba secara lokal terlebih dahulu jika alat tersebut tepat untuk mereka.



Inilah mengapa Kotless mendukung mode peluncuran lokal. Dengan menggunakan fitur standar dari framework yang dipilih (baik Ktor, Spring Boot, dan Kotless DSL, tentu saja, dapat menjalankan aplikasi secara lokal), Kotless menerapkan aplikasi ke mesin pengguna.



Selain itu, Kotless dapat menjalankan emulasi AWS (digunakan oleh LocalStack ) sehingga pengguna dapat memeriksa secara lokal bahwa aplikasi tersebut berperilaku seperti yang diharapkan.



Pengembangan lebih lanjut



Saat menulis Kotless (beserta tesis master saya), saya berhasil mempresentasikannya di ASE 2019, KotlinConf 2019 dan di podcast Talking Kotlin. Secara umum, alat tersebut diterima dengan baik, meskipun pada akhir 2019 tidak lagi tampak seperti hal baru (pada saat itu, Zappa, Claudia.js, dan AWS Chalice telah menjadi populer).



Namun, saat ini, Kotless mungkin adalah alat paling terkenal di kelasnya di dunia Kotlin, dan saya pasti berencana untuk mengembangkannya.



Dalam waktu dekat, saya berencana untuk menstabilkan API dan fungsionalitas saat ini, menyiapkan tutorial dan proyek demo untuk membuat mempelajari alat ini lebih mudah bagi pengguna baru.



Misalnya, kami berencana untuk menyiapkan satu set tutorial tentang cara membuat bot obrolan menggunakan Kotless. Tampaknya teknologi Tanpa Server sangat bagus untuk kasus penggunaan ini (dan pengguna Kotless sudah menulis bot Telegram), tetapi kurangnya alat yang sesuai secara signifikan menghalangi penggunaan yang luas.



Terakhir, salah satu aspek terpenting dari keseluruhan arsitektur alat ini adalah kemandirian platformnya. Dalam waktu yang tidak terlalu lama, saya berharap dapat mendukung Google Cloud Platform dan Microsoft Azure, yang akan memungkinkan aplikasi berpindah dari cloud ke cloud hanya dengan satu tombol.



Saya berharap Kotless dan alat serupa akan benar-benar membantu pengenalan teknologi Tanpa Server kepada banyak orang, dan semakin banyak aplikasi akan menghabiskan sumber daya hanya saat berjalan, sedikit mengurangi entropi alam semesta :)



All Articles