Blog AWS Indonesia
AWS Lambda untuk para developer container
Pengenalan
Ketika membangun sebuah aplikasi di AWS, salah satu hal umum yang customer harus putuskan adalah membangun di AWS Lambda atau membangun di layanan berbasis container seperti Amazon Elastic Container Service (Amazon ECS) atau Amazon Elastic Kubernetes Service (Amazon EKS). Untuk membuat keputusan ini, ada banyak faktor yang perlu diperhatikan seperti biaya, scaling, dan bagaimana kontrol developer atas pilihan-pilihan hardware. Secara objektif tidak ada yang lebih baik atau buruk dari model function-based atau service-based. Tetapi, lebih kepada bagaimana kecocokan antara aplikasi dan layanan tersebut. Tapi satu yang lebih membingungkan dari pilihan ini adalah perbedaan model pemrograman antara paradigma berbasis function dari AWS Lambda dan yang tradisional, paradigma service-based dari Amazon ECS atau Amazon EKS.
Perbedaan dalam model pemrograman antara AWS Lambda dan Amazon ECS atau Amazon EKS telah sering dibahas. Tapi apa yang dimaksud dengan model pemrograman? Model pemrograman dari sebuah produk ada dua aspek. Pertama adalah caller melakukan request ke aplikasi. Kedua adalah kode didalam aplikasi menerima sebuah request dari sebuah service dan mengembalikan respon. Pada artikel ini kita akan membahas keduanya tapi akan lebih fokus ke yang kedua. Kita lihat dibelakang layar bagaimana cara kerja sebuah aplikasi AWS Lambda dan coba memahami bagaimana aplikasi yang berjalan di AWS Lambda berinteraksi dengan service AWS Lambda dalam mengirim dan menerima respon terhadap request.
Tujuan dari artikel ini adalah dua hal. Pertama, kami berhadap dapat menjelaskan model pemrograman di AWS Lambda dan menunjukkan bagaimana “Lambda magic” sebenarnya adalah kontrak sederhana antara aplikasi dan service. Kedua, kami berharap untuk, menunjukkan pada developer yang datang dari background container tradisional, bahwa AWS Lambda tidaklah begitu berbeda. Semua produk compute menyediakan sebuah kontrak antara kode aplikasi dan service. Memindahkan aplikasi antar produk compute — diharapkan hanya memerlukan sedikit — perubahan pada aplikasi menyesuaikan model pemrograman yang sesuai dengan produk tersebut.
Panduan
Mari kita mulai!
Seperti yang kita tahu, AWS Lambda berjalan pada server (!) dan menerima aplikasi dalam bentuk ZIP atau Open Container Initiative (OCI). Meskipun kita dapat menggunakan bentuk ZIP untuk melakukan hal yang sama (lebih detil pada akhir), pada artikel ini kita konfigurasi AWS Lambda menggunakan contaimer image. Menyangkut tentang workload, kita akan membuatnya dengan salah satu bahasa pemrograman yang paling sederhana: bash script. Kita ingin melihat sedekat mungkin ke server-server tersebut untuk mendemonstrasikan interaksi antara kode yang berjalam di dalam container dan model pemrograman dari AWS Lambda.
Untuk memulai, kita akan menggunakan Dockerfile sederhana berikut:
Jika Anda berpikir bahwa AWS Lambda adalah sesuatu yang susah dimengerti, pikir lagi. Ini adalah Docker file standar yang dimulai FROM dari image Amazon Linux 2023 dan menginstal beberapa tools didalamnya (AWS Command Line Interface [AWS CLI], tar, git, dsb.) AWS Lambda menjalankan container image ini dan script startup.sh sama seperti ketika Anda menjalankan pada Laptop Anda (atau pada AWS Fargate).
Ada tiga catatan yang membuat container spesial di AWS Lambda:
- Limitasi dari container instance
- Bagaimana container instance mulai dijalankan
- Apa yang kita jalankan pada script startup.sh (dan script businesscode.sh)
Mari kita lihat satu per satu.
Limitasi dari container
Mesin atau virtual machine akan menentukan kapabilitas dari sebuah container. Jika Anda menjalankan container pada laptop Anda kemungkinan ia tidak akan mendapat Graphics Processing Unit (GPU). Jika Anda menjalankan container menggunakan AWS Fargate Anda tidak dapat menjalankan privileged container. Setiap lingkungkan ekskusi memiliki batasannya masing-masing. Lingkungan eksekusi di AWS Lambda memiliki batasan berikut:
- lama waktu ekskusi dibatasi
- container dikonfigurasi dari ukuran memory dan kapasitas CPU mengikuti secara proporsional sesuai alokasi memory
- container berjalan dengan read-only filesystem (hanya path /tmp yang dapat ditulis)
- Anda tidak bisa menjalankan privileged container
- Anda tidak bisa mengekspos GPU ke container
Banyak dari limitasi diatas adalah umum pada container managed service tradisional dan/atau eksekusi lokal. Limitasi lama waktu eksekusi dan read-only filesystem adalah yang paling relevan dengan artikel ini dan kita akan membahasnya lagi nanti.
Bagaimana container mulai dijalankan
Pada bagian ini kita akan melihat bagaimana aspek pertama dari model pemrograman – bagaimana caller memanggil aplikasi. Setiap lingkungan punya cara sendiri bagaimana menjalankan container. Jika Anda ingin menjalankan container di laptop, Anda mungkin menggunakan docker run atau finch run. Jika Anda ingin menjalankan container di AWS Fargate, maka Anda mungkin menggunakan Amazon ECS API, seperti runTask atau createService. AWS Lambda, pada bagian intinya, adalah sebuah sistem event-driven dan semuanya (termasuk cara menjalankan container diatas) terjadi karena event. AWS Lambda mendukung ratusan event berbeda yang datang dari berbagai layanan AWS. Even classic dapat berupa sebuah pesan pada Amazon SQS queue sebagai bagian dari aplikasi asynchronous. Tapi event juga bisa berupa Amazon API Gateway (atau Elastic Load Balancing) HTTP call sebagai bagian dari interaksi aplikasi web. Apapun itu, event akan tersedia untuk AWS Lambda untuk pemrosesan (lebih lanjut tentang ini nanti). Sebuah proses container AWS Lambda setidaknya akan memproses satu event dalam satu waktu. Tetapi, bisa juga memproses banyak event secara berurutan selama proses tersebut berjalan.
Orkestrasi container AWS Lambda kurang lebih mengikuti alur berikut ketika merespon terhadap sebuah event:
- Jika ada container yang sudah inisialisasi dan siap mengeksekusi event, maka AWS Lambda akan meneruskan event ke container tersebut dan mengeksekusinya.
- Jika tidak ada container yang sudah diinisialisasi dan siap mengeksekusi event, maka AWS Lambda akan menjalankan container baru
- AWS Lambda mungkin memilih untuk tetap menjalankan container tersebut untuk waktu yang lebih lama dari hanya satu eksekusi sehingga untuk event berikutnya tidak perlu menjalankan container baru
- Jika beberapa event datang secara simultan, maka AWS Lambda meluncurkan container secara paralel untuk setiap event tersebut, sampai batas konfigurasi account concurrency atau burst limit.
Apa yang kita jalankan pada script startup.sh
Sampai disini kita sudah mengenali lingkungan eksekusi dari container pada AWS Lambda (dan batasannya) dan alur eksekusi dari lingkungan tersebut (orkestrasi). Sekarang mari kita perhatikan apa yang kode didalam container lakukan (model pemrograman).
Anda mungkin sudah mengetahui tentang Lambda runtime API. Cara termudah untuk menjelaskan API ini adalah mereka memberikan aplikasi sebuah cara untuk mengambil event dan merespon terhadap event. Pikirkan bahwa container Anda adalah sebuah long-running process yang selalu mengecek apakah ada event untuk diproses, jika ada maka lakukan sesuatu, kemudian beritahu AWS Lambda hasil pemrosesan tersebut.
Dengan pemodelan seperti ini, kita menulis startup.sh yang mengimplementasi alur diatas. Pada contoh ini, business logic yang digunakan pada AWS Lambda kita adalah meng-clone website Hugo dari sebuah GitHub repository, membangunnya menjadi kumpulan file-file Javascripts, dan menyalinnya ke Amazon Simple Storage Service (Amazon S3) bucket. Kita memasukkan business logic tersebut pada sebuah script bernama businesscode.sh. Script startup.sh memanggil businesscode.sh, ia menjadi jembatan antara model pemrograman AWS Lambda dan business logic kita. Bagian business logic sama sekali tidak perlu tahu apapun tentang AWS Lambda.
Penting: Contoh kasus ini tidaklah penting, fokus pada alur dan mekanisme bagaimana kode berjalan daripada perintah aktual yang dijalankan.
Ini adalah isi dari startup.sh:
#!/bin/sh
set -euo pipefail
###############################################################
# The container initializes before processing the invocations #
###############################################################
echo Installing the latest version of Hugo...
cd /tmp
export LATESTHUGOBINARYURL=$(curl -s https://api.github.com/repos/gohugoio/hugo/releases/latest | jq -r '.assets[].browser_download_url' | grep Linux-64bit.tar.gz | grep extended)
export LATESTHUGOBINARYARTIFACT=${LATESTHUGOBINARYURL##*/}
curl -LO $LATESTHUGOBINARYURL
tar -zxvf $LATESTHUGOBINARYARTIFACT
./hugo version
###############################################
# Processing the invocations in the container #
###############################################
while true
do
# Create a temporary file
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
############################
# Run my arbitrary program #
############################
/businesscode.sh
############################
# Send the response
curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d '{"statusCode": 200}'
doneIsi dari businesscode.sh:
#!/bin/sh
set -euo pipefail
rm -rf hugo-sample-site
git clone https://github.com/${AWS_LAMBDA_FOR_THE_CONTAINERS_DEVELOPER_BLOG_GITHUB_USERNAME}/aws-lambda-for-the-containers-developer-blog
cd aws-lambda-for-the-containers-developer-blog/hugo_web_site
/tmp/hugo
aws s3 cp ./public/ s3://${AWS_LAMBDA_FOR_THE_CONTAINERS_DEVELOPER_BLOG_BUCKET}/ --recursiveScript startup.sh dimulai dengan bagian yang hanya dijalankan ketika container berjalan. Bagian dari script tersebut (init) adalah yang menentukan cold start dari container instance AWS Lambda. Pada contoh kita, ia mendownload versi terbaru dari runtime hugo. Kita bisa saja memasukkannya kedalam Dockerfile yang ditunjukkan sebelumnya, tapi itu akan membuat kita harus build ulang image setiap kali kita menginginkan versi terbaru. Disini, kita memanfaatkan alur inisialisasi kode di AWS Lambda ketika container dijalankan, agar kita selalu mendapat versi terbaru dari Hugo segara dinamis. Yang menentukan sebuah bagian code harus ada di Dockerfile, di fase init atau pada business logic tergantung kebutuhan Anda sendiri.
Perlu dicatat bahwa operasi dilakukan pada folder /tmp karena hanya ini folder yang bisa ditulis didalam container Lambda. Karena alasan ini, akan lebih mudah untuk menginstal tools tersebut pada Dockerfile.
Bagian script berikutnya (berlabel “Processing the invocations in the container”) adalah bagian kode yang memasuki infinite loop yang berjalan selama masa hidup container. Kode akan terus melakukan cek (via curl ke AWS lokal Lambda runtine API endpoint) apakah ada event untuk diproses. Disinilah letak “magic” dari AWS Lambda — ia mengekspos dan mengelola runtime API endpoint dalam setiap lingkungan eksekusi. Ketika event datang ia mengirimkan event kembali ke endpoint yang melakukan polling dan jika tidak ada event yang menunggu, maka AWS Lambda akan menghentikan sementara lingkungan eksekusi sampai ada event yang datang. Pada setiap event yang diterima, kode kita mengambilnya dan berlanjut ke bagian script (berlabel “Run my arbitrary program”) pada event tersebut. Ini adalah bagian script yang agnostic terhadap AWS Lambda dimana kita mengeksekusi business logic (script businesscode.sh). AWS Lambda membatasi bagian ini dengan execution timeout (dapat dikonfigurasi hingga 15 menit). Artinya kode yang menjadi bagian “Run my arbitrary program” tidak dapat berjalan melebihi timeout yang telah dikonfigurasi.
Ketika business logic selesai, script mengirimkan pesan melalui HTTP POST ke endpoint yang sama untuk memberitahu AWS Lambda service bahwa pemrosesan event telah selesai. AWS Lambda tidak memperdulikan output apa yang dikembalikan asalkan Anda mengembalikan sesuatu. Pada script kita mengembalikan {“statusCode”: 200}, karena kita menggunakan API Gateway untuk men-trigger fungsi ini dan API Gateway mengharap kode tersebut pada output. Anda juga dapat mengembalikan sebuah teks seperti “hey I am done” dan AWS Lambda tidak mempermasalahkan hal itu (tapi tidak begitu pada API Gateway).
Jangan bingung dengan lama waktu durasi container dengan AWS Lambda timeout. Waktu durasi container adalah seberapa lama container menjalankan loop sejak mulai dijalankan. Waktu durasi ini tidak termasuk dalam “kontrak” di AWS Lambda dan developer harusnya tidak berasumsi berapa lama container berjalan hingga akhirnya dimatikan. Timeout di AWS Lambda adalah bagian dari “kontrak”, saat tulisan ini dibuat, dapat dikonfigurasi hingga maksimum 15 menit. Jika saat menerima event dari runtime API kode container memakan waktu lebih lama dari timeout yang dikonfigurasi untuk mengembalikan response, request akan dikembalikan ke caller sebagai timeout dan container akan direstart.
Hal penting lain yang perlu dicatat adalah pada script ini kita mengabaikan payload dari event, yang membawa informasi dari request tersebut. Dengan kata lain, kita hanya tertarik pada trigger event dan bukan informasi yang dibawa oleh trigger tersebut. Kita memproses HEADERS untuk mengambil request ID yang kita gunakan pada akhir loop untuk memberi tahu AWS Lambda service bahwa event selesai diproses. Di arstektur event-driven umumnya, kita akan memproses payload dari event tersebut dan menggunakannya pada business logic.
Diagram berikut adalah representasi visual dari bagian-bagian dari kode diatas:
Mari menggabungkan semuanya
Kita akan mulai mendeskripsikan bagian high level, apa yang terjadi dibalik layar ketika Anda men-deploy AWS Lambda ini dan mengeksekusinya.
Anda membangun container image dari sebuah Dockerfile diatas dan membuat sebuah fungsi AWS Lambda dengan image tersebut. Kemudian Anda membuat dua trigger untuk AWS Lambda ini: sebuah API Gateway endpoint dan sebuah Amazon SQS queue. Sampai saat ini, belum ada yang berjalan dan container belum dijalankan.
Kemudian Anda membuka API Gateway endpoint tersebut dengan sebuah request dari terminal (curl <api gateway endpoint>). API Gateway mengubah HTTP request tersebut menjadi sebuah event AWS Lambda dan itu otomatis menjalankan container karena respon terhadap event tersebut. Container kemudian masuk pada tahap inisialisasi (pada kasus ini mengambil binari hugo). Ia kemudian masuk ke event loop dan mengambil event yang ada di AWS Lambda dan menunggu container tersedia. Container menghabiskan beberapa detik melakukan cloning repository dan membangun website kemudian menyalin kontennya ke Amazon S3. AWS Lambda memberi tahu API Gateway secara synchronous dan terminal prompt kembali (tidak ada output pada respon karena kita tidak mengembalikan apapun pada body pesan dari HTTP POST pada script).
Proses ini kurang lebih akan memakan waktu 30 detik karena, pada kasus kita, kita menggunakan AWS Lambda sebagai suatu build system. Anda mungkin tidak akan menggunakan AWS Lambda untuk hal ini dalam sebuah pola synchronous request/respon. Business logic harusnya lebih ringan: Seperti sebuah web yang merespon dalam milidetik. Sekali lagi, contoh ini hanya digunakan untuk mengilustrasikan kepada Anda mekanisme apa yang terjadi dalam sebuah instance Lambda.
Pada tahap ini, container telah memanggil runtime API untuk event berikutnya dan menunggu respon dari runtime API. Container sekarang di-pause sampai ada event lain yang datang, dalam masa ini kita tidak membayar biaya. Jika Anda membuat pesan di queue, AWS Lambda mengetahui ada lingkungan yang sedang aktif dan idle, kemudian container di-unpause dan event akan diteruskan ke AWS Lambda tersebut. Container menerima event sebagai respon dari pemanggilan runtime API dan melalui proses yang sama yaitu menjalankan business logic dan kemudian merespon dengan mengembalikan sebuah hasil.
Dalam contoh ini event payload akan berbeda dengan apa yang dihasilkan oleh API Gateway, tapi untuk contoh ini, kita tidak memperdulikannya karena kita tidak membaca payload tersebut dan tidak mengirimkannya ke container. Kita hanya peduli tentang trigger dan bukan isi dari event itu sendiri.
Setelah beberapa waktu tidak ada request yang masuk, maka AWS Lambda mematikan container diatas dan tidak ada container yang berjalan pada fungsi Lamba tersebut. Pada tahap ini, Anda mengirim 100 request simultan ke API Gateway endpoint. AWS Lambda melihat terdapat 100 request yang masuk dan menjalankan 100 container secara paralel untuk memproses request (semuanya akan masuk ke tahap inisialisasi “cold-start” dulu). Ketika request telah diproses dan website telah dibangun dan disalin 100 kali, ke-100 container tersebut akan tetap berjalan dan siap menerima event lagi melalui loop yang berjalan (sampai AWS Lambda memutuskan untuk mematikan container tersebut).
Menjalankan container image diluar Lambda
Jika diperhatikan Dockerfile yang kita gunakan tidaklah berbeda dengan Dockerfile yang ada pada umumnya. Perbedaan terbesar ada pada bagaimana script startup.sh menginisialisasi container dan bagaimana ia berinteraksi dengan API AWS Lambda (baik mengambil event dan mengirimkan hasil dalam sebuah loop). Ini adalah bagian yang sangat spesifik ke model pemrograman AWS Lambda. Kita membangun script ini supaya business logic (businesscode.sh) terpisah dengan model pemrograman (startup.sh). Oleh karena itu, akan lebih mudah menggunakan container image yang sama dan menjalankannya ditempat lain dengan tidak perlu menjalankan bagian yang spesifik dengan AWS Lambda dan langsung menjalankan business logic saja. Cara termudah untuk mencapai hal ini adalah dengan menjalankan perinah Docker secara local:
Kita hanya mengubah entrypoint dan merujuk pada script businesscode.sh.
Anda mungkin bertanya mengapa kita melakukan mapping local folder ke folder /tmp di container. Hal ini karena kita mem-bypass fase inisialisasi pada container image yang tidak menginstal binary hugo saat startup. Kita menggantinya dengan binary dari /tmp yang sudah ada pada laptop kita. Dalam skenario kasus nyata Anda mungkin membangun binary hugo dalam container image atau memisah kode download dari startup.sh jika ia dapat dijalankan diluar konteks AWS Lambda. Sekali lagi, contoh ini hanyalah untuk tujuan demo dan ubah sesuai dengan skenario kasus Anda.
Tapi tunggu, ini bukanlah AWS Lambda yang kita tahu!
Benar. Seperti yang dijanjikan, ini adalah penjelasan mekanisme low-level dari AWS Lambda dimana model eksekusi bertemu dengan model pemrograman. Jika Anda pernah menggunakan AWS Lamda, semua detil ini telah diabstraksi untuk Anda. Penting untuk dicatat bahwa ketika AWS Lambda diluncurkan ia dimulai dengan level abstraksi yang tertinggi dan perlahan memperkenalkan dukungan untuk mendapatkan visibilitas apa yang kita bicarakan pada artikel ini. Sekarang bagaimana kita menyatukan apa yang kita deskripsikan diartikel ini dengan abstraksi high-level yang telah Anda ketahui? Mari kita mulai dengan apa yang kami jelaskan pada artikel ini, sampai kepada AWS Lambda yang Anda tahu.
Kebanyakan developer tidak ingin berurusan dengan loop dan HTTP GET dan POST ketika mereka menulis kode business logic. Disinilah abstraksi dan konvensi yang sering Anda lihat di Lambda muncul – AWS Lambda Runtime Interface Client (RIC). RIC adalah utilitas (binary atau library) yang disediakan oleh AWS untuk bahasa pemrograman tertentu yang mengimplementasikan loop yang menangani event. Bagaimana cara event ini masuk pada kode Anda adalah dari objek yang diberikan pada fungsi dari program tersebut. RIC mengambil HEADERS dan BODY yang disebutkan diatas. Ia akan mengambil konten dari event dan konteks dari lingkungan eksekusi dan mengirimkannya sebagai objek kepada fungsi Anda. Dengan kata lain, container yang dijalankan dengan RIC sebagai program utama maka pada setiap event RIC akan memanggil fungsi pada program tersebut dengan informasi event yang telah didapat. Dengan demikian, developer dapat mengambil event langsung dari fungsi tanpa harus memanggil endpoint dan melakukan parsing HEADERS dan BODY.
Kita telah berhasil membangun sebuah bash script (startup.sh) yang didalamnya mengimplementasi cara kerja dari RIC. Perlu diketahui bahwa kita tidak ingin meniru konvensi dari sebuah “fungsi” pada contoh kita karena kita ingin contoh ini sebagai “container reguler biasa dengan sedikit penambahan” daripada “ini cara mengimplementasi RIC dalam bash”. Sebagai catatan, tutorial pada dokumentasi Lambda ini (yang menginspirasi artikel ini) melakukan hal tersebut dan menunjukkan pada Anda bagaimana membuat sebuah fungsi bash dan bagaimana mengimpornya dalam script Anda!
Ya, meskipun AWS Lambda adalah Function as a Service (FaaS), keseluruhan fungsi pada konteks AWS Lambda adalah sebuah konvensi dimana kita membangun diatas loop dan dua operasi curl dalam sebuah container yang kita abstraksi penggunaannya untuk mempermudah kerja developer.
Kembali ke topic RIC, kami memiliki RIC standalone (untuk beberapa bahasa terpilih) jika Anda ingin membangun container image Anda sendiri, atau kami juga menyediakan AWS Lambda managed base images (yang didalamnya terdapat RIC dan lainnya) yang dapat digunakan sebagai basis untuk membangun. Apapun yang Anda pilih, ketika Anda memilih menggunakan container image maka Anda bertanggung jawab terhadap perawatannya. Dengan kata lain, Anda perlu mengelola agar image selalu up-to-date dengan fungsi Anda.
Alternatif lain, dan level abstraksi yang lebih tinggi, adalah memaket custom runtime dan business logic dalam sebuah ZIP file dan membiarkan AWS mengelola sistem operasi tempat fungsi Anda berjalan.
Untuk level abstraksi terbaik dan terkelola, Anda hanya perlu memaket business logic sebagai ZIP file dan membiarkan AWS mengelola keseluruhan runtime untuk Anda. Seperti yang sudah dijelaskan, inilah bagaimana AWS Lambda dulu dimulai dan telah terjadi beberapa proses panjang untuk menambahkan fleksibilitas dan kontrol ke dalamnya. Kami menambahkan dukungan untuk layers dan kami menambahkan dukungan untuk container image.
Selama bertahun-tahun, komunitas Lambda telah membangun abstraksi diatas model pemrograman Lambda yang telah dijelaskan di atas. Salah satu abstraksi itu adalah Lambda Web Adapter yang membuat customer dapat menjalankan aplikasi web tradisional di Lambda. Anda dapat membayangkan Web Adapter ini sebagai custom runtime yang menjadi interface antara model pemrograman Lambda dan web framework tradisional yang listen pada port. Dengan model ini, alur event-driven pada Lambda diabstraksi, infrastruktur secara virtual dipisah dari model pemrograman.
Tes prototipe ini sendiri
Bagi Anda yang suka untuk bereksperimen, kami telah membuat GitHub repository yang berisi semua kode dan instruksi bagaimana membuat ulang prototipe ini. Silahkan kunjungi link ini jika Anda ingin mencobanya sendiri.
Kesimpulan
Pada artikel ini, kita membahas AWS Lambda dalam perspektif yang berbeda dari biasanya. Meskipun contoh yang digunakan tidak konvensional dan mungkin tidak sesuai dengan skenario real-life dari AWS Lambda, kami harap artikel ini membantu customer untuk mengapresiasi cara kerja AWS Lambda dibelakang layar. Kami juga berharap bahwa kami telah memberikan kejelasan perbedaan antara AWS Lambda dan sistem container tradisional. Ternyata perbedaannya tidak terlalu signifikan seperti kelihatannya.
Artikel ini diterjemahkan dari artikel asli dengan judul “AWS Lambda for the containers developer” yang ditulis oleh Massimo Re Ferre, Senior Principal Technologist di AWS dan Chris Greenwood, Principal Engineer di AWS.