Mengapa Kami Pindah ke Komputasi Tanpa Server untuk Menyebarkan Pembuatan Kustom

Diterbitkan: 2018-11-22
Pengaturan server untuk komputasi awan tanpa server.

Foto oleh panumas nikhomkhai dari Pexels

Sebagai bagian dari komitmen kami untuk memberdayakan pemasar kinerja untuk Melakukan Lebih Banyak, Dengan Lebih Sedikit, Tanpa Khawatir , tim di TUNE selalu mencari cara baru untuk melayani pelanggan kami. Dalam hal ini, tim Solutions Engineering kami menemukan teknologi yang menyederhanakan cara mereka menerapkan dan mendukung pembuatan kustom di platform kami. Akibatnya, mereka sekarang dapat menghabiskan lebih banyak waktu (dan lebih sedikit uang) bekerja dengan lebih banyak pelanggan untuk membangun solusi yang mereka butuhkan.


Di TUNE, kami bangga menyediakan platform pemasaran kinerja yang fleksibel dan komprehensif yang memungkinkan jaringan dan pengiklan untuk mengelola kampanye pemasaran digital, hubungan penerbit, pembayaran, dan banyak lagi — langsung dari kotak, tanpa harus menulis satu baris kode pun . Namun terkadang, seperti sistem SaaS yang terkelola sepenuhnya lainnya, pelanggan kami memerlukan konfigurasi, fungsionalitas, atau integrasi khusus yang hanya dapat dicapai dengan menyingsingkan lengan baju kami dan mengaktifkan editor kode lama. Baru-baru ini, kami beralih ke teknologi baru yang mengubah cara kami membangun solusi ini: komputasi tanpa server.

Dalam posting ini, saya akan membahas masalah yang kami hadapi dengan pengembangan kustom, langkah-langkah yang kami ambil untuk menyiapkan proses pembuatan tanpa server kami, dan bagaimana metodologi baru ini memecahkan tantangan biaya dan skala.

Tantangan: Mengikuti Permintaan untuk Solusi Kustom

Saat kami pertama kali memulai tim Solutions Engineering di TUNE, kami memperlakukan setiap build pelanggan khusus sebagai build terpisah. Sebagian besar dari build ini memiliki komponen front-end, yang biasanya digunakan sebagai halaman kustom pada platform kami, dan komponen back-end yang terdiri dari server, database, dan infrastruktur lain yang diperlukan untuk menjaga server tetap up-to -tanggal dan operasional.

Pada awalnya, metodologi ini berhasil bagi kami. Dengan memiliki tim kecil yang ramping dengan beberapa build kustom yang kompleks, metode kami dalam menyediakan dan mengonfigurasi server yang berbeda untuk setiap build berhasil bagi kami. Itu memungkinkan kami untuk membuat pengalaman yang luar biasa bagi pelanggan kami.

Namun seiring dengan bertambahnya jumlah build, kami mulai mengalami masalah:

  • Terlalu banyak server! Seperti yang dapat Anda bayangkan, menyediakan minimal dua kotak per build membuat kami memiliki terlalu banyak server. Banyaknya jumlah server dan semua kesulitan yang menyertainya (seperti pembaruan keamanan dan pencadangan) menghabiskan lebih banyak waktu daripada yang ingin kami akui.
  • Pertahankan server itu. Dengan setiap server menjadi entitasnya sendiri, kami bertanggung jawab untuk memastikan bahwa setiap server selalu aktif dan beroperasi.
  • PHP bukan untuk saya. Sebagian besar build kami dipintal dari image Docker PHP dasar. Tetapi seiring pertumbuhan tim kami, kami tahu bahwa memaksa orang untuk menulis pelanggan mereka membangun di PHP 5.0 ketika mereka adalah penyihir Python tidak masuk akal.
  • Ini semakin mahal. Dengan semua server kami dikerahkan pada ec2/RDS, kami mulai melihat biaya bulanan yang signifikan.
  • Keselamatan pertama. Karena layanan ini menangani data pelanggan yang sensitif, kami harus menyediakan metode autentikasi untuk URL publik kami guna memastikan keamanan data tersebut.
  • Cron itu tangguh. Banyak layanan back-end terdiri dari skrip cron, dan kami tidak memiliki cara yang efisien untuk mengelolanya.

Dengan munculnya tantangan ini, kami tahu bahwa kami harus menemukan cara yang lebih sederhana dan lebih hemat biaya untuk menyediakan fungsionalitas back-end ke build pelanggan kami. Tapi setelah banyak perdebatan dan tidak ada solusi terdepan yang jelas, kami mulai kehabisan ide. (Selain itu, dengan permintaan untuk pembuatan kustom baru yang tumbuh seperti orang gila, waktu jelas tidak memihak kami.)

Solusi: Komputasi Tanpa Server untuk Menyelamatkan

Jika Anda belum pernah mendengar tentang komputasi tanpa server , Anda mungkin bertanya-tanya hal yang sama ketika kami pertama kali mendengarnya. Bagaimana Anda bisa mengeksekusi kode tanpa server? (Jangan khawatir; pemahaman dasar Anda tentang pemrograman masih benar, dan tidak, kami tidak menyalahgunakan happy hour khusus sebelum menulis ini.)

"Tanpa server" adalah istilah yang sangat membingungkan untuk teknologi baru, karena — jangan konyol — pasti masih ada kode yang mengeksekusi server. Jadi apa sebenarnya serverless itu ?

Komputasi tanpa server adalah model eksekusi komputasi awan di mana penyedia awan bertindak sebagai server, yang secara dinamis mengelola alokasi sumber daya mesin. Wikipedia

Solusi cloud tanpa server memungkinkan Anda membangun dan menjalankan aplikasi dan layanan tanpa memikirkan kerumitan yang terkait dengan server. Pada dasarnya, komputasi tanpa server memungkinkan Anda melakukan yang terbaik: menulis kode.

Proses Pengaturan Tanpa Server

Untuk menunjukkan kepada Anda inti dari cara kerja teknologi tanpa server, saya akan membahas langkah-langkah yang kami gunakan untuk menyiapkan fungsi ini.

Catatan: Ada banyak penyedia cloud dengan fungsionalitas tanpa server. Dalam contoh ini, kami menggunakan AWS Lambda .

    1. Pertama, buat fungsi Lambda baru dan pilih " Cetak Biru ." Kemudian, ketik " http " di bidang kata kunci, dan pilih titik akhir layanan mikro Python atau Node. (Cetak biru adalah blok kode yang dibuat sebelumnya yang dimaksudkan untuk membuat pengembangan lebih cepat. Betapa hebatnya itu?) Setelah Anda membuat pilihan, klik " Konfigurasi ."
      Cara mengonfigurasi fungsi di AWS Lambda.

      Cara mengonfigurasi fungsi di AWS Lambda.

    2. Tambahkan nama fungsi dan peran. Kemudian pilih pemicu API Gateway dengan opsi keamanan " Buka dengan Kunci API ." Gateway API ini akan menyediakan URL publik yang akan memicu fungsi Lambda Anda. Menambahkan kunci API menyediakan metode autentikasi, yang sangat disarankan.
      Menyiapkan kunci gerbang API terbuka di AWS Lambda.

      Menyiapkan kunci gerbang API terbuka di AWS Lambda.

    3. Setelah Anda membuat fungsi, Anda sekarang dapat membuat konfigurasi pada kode Anda. Seperti yang Anda lihat, cetak biru telah memberi Anda kait titik masuk keren yang memungkinkan Anda berinteraksi dengan tabel Dynamo (jika Anda ingin menambahkan database). Apa pun yang ada di bawah lambda_handler akan dieksekusi ketika URL publik dimuat. Karena kita juga menambahkan database, mari kita masuk ke Dynamo dan membuatnya.
      Membuat tabel database Dynamo di AWS Lambda.

      Membuat tabel database Dynamo di AWS Lambda.

    4. Setelah tabel Dynamo dibuat, mari lakukan panggilan ke fungsi Lambda ini dari URL publik. Kembali ke fungsi Anda dan klik ikon “ API Gateway ” di bagian atas. Anda akan melihat bahwa titik akhir dan kunci API telah dibuat untuk Anda.
      Di mana menemukan ikon API Gateway di fungsi AWS Lambda.

      Di mana menemukan ikon API Gateway di fungsi AWS Lambda.

    5. Sekarang buka terminal dan tambahkan kunci API di bawah header “ x-api-key” , lalu tambahkan nama tabel yang Anda buat di bawah parameter string kueri TableName .
      Masukkan kunci dan nama database Anda di terminal untuk menyelesaikan penyiapan build tanpa server di AWS Lambda.

      Masukkan kunci dan nama database Anda di terminal untuk menyelesaikan.

Itu dia! Anda sekarang memiliki bagian belakang yang berfungsi dan aman yang terhubung ke database. Yang dibutuhkan hanyalah lima langkah mudah.

Bagaimana Komputasi Tanpa Server Mengatasi Tantangan Kami

Sekarang setelah kami menunjukkan kepada Anda cara menyiapkan build tanpa server, mari kita lihat dan lihat bagaimana model berbasis cloud ini sesuai dengan daftar masalah kami.

  • Terlalu banyak server! Tanpa server… artinya tidak ada lagi server, kan?
  • Pertahankan server itu. Karena komputasi tanpa server dikelola oleh penyedia cloud, Anda mendapatkan manfaat dari memiliki penyedia ini (bersama dengan metode mereka yang terbukti dan tangguh) untuk memantau server Anda. Bagi Anda yang ingin bermain Sherlock Holmes, Anda juga dapat melihat semua output log server dengan fungsi Anda di Cloudwatch .
  • PHP bukan untuk saya. Model tanpa server memungkinkan Anda menulis dalam C#, Python, NodeJS, Go, dan bahkan Java.
  • Ini semakin mahal. Dengan solusi tanpa server, biaya diukur berdasarkan waktu eksekusi (per 100 milidetik) dan jumlah data yang ditransfer. Tidak seperti membayar per bulan, yang mencakup waktu server Anda menganggur, Anda hanya membayar untuk apa yang Anda gunakan. Dengan biaya serendah $0,000000208 per 100 ms eksekusi, komputasi tanpa server dapat menghemat banyak uang.
  • Keselamatan pertama. Apakah tanpa server aman? Dengan sistem otentikasi kunci API bawaan, Anda yakin itu.
  • Cron itu tangguh. Dengan sistem manajemen cron yang dibangun secara native di Cloudwatch, cukup atur jendela waktu dan lupakan saja. Cloudwatch menangani semua pencatatan dan eksekusi.

Pikiran Akhir

Untuk tim Solutions Engineering di TUNE, pindah ke komputasi tanpa server telah menjadi pengubah permainan. Kemudahan penggunaan, penghematan biaya, dan fitur ramah-gesit telah mengubah cara kami menangani semua build pelanggan baru. Solusi berbasis cloud tanpa server diatur untuk mengubah dunia komputasi sisi server. Saya tidak tahu tentang Anda, tetapi satu hal yang pasti: tim TUNE Solutions Engineering sudah siap.

Untuk mempelajari lebih lanjut tentang platform TUNE dan layanan pengembangan khusus yang kami sediakan, kunjungi halaman Layanan Profesional kami .