Pengantar tentang Amazon Fargate: apa itu, mengapa mengagumkan (dan tidak), dan kapan menggunakannya.

Ketika Amazon mengumumkan Fargate pada akhir 2017 di AWS re: Invent (bersama dengan EKS), itu benar-benar tidak terdeteksi. Tak satu pun dari blog atau influencer yang saya ikuti pada saat itu benar-benar membicarakannya selain hal-hal seperti:

Oh ya dan ada hal baru ini yang memungkinkan pengguna ECS untuk menjalankan kontainer langsung di cloud.

Sebagai seorang pengembang, itu benar-benar mengejutkan saya. Mari kita lihat alasannya.

Ledakan produktivitas

Saya merasa ada lima revolusi besar dalam dunia pengembangan perangkat lunak yang secara dramatis meningkatkan produktivitas dan kemampuan pengembang untuk menulis dan menerapkan aplikasi tingkat produksi dengan efisiensi maksimum.

Mereka semua juga memecahkan masalah besar. Inilah rincian revolusi saya dan masalah yang mereka pecahkan:

  • Munculnya Layanan Cloud (IaaS)

    Biaya infrastruktur dan skalabilitas

  • Komunitas open source, Konferensi, Lokakarya, Blog Teknologi, Stack overflow, dan sebagainya

    Akses pengetahuan terbatas

  • Sistem pembuatan versi, alat Kolaborasi, Alat integrasi berkelanjutan

    Rekayasa konkuren Perbedaan sistem dan integrasi neraka

  • Arsitektur kemas

    Kesulitan dalam membangun aplikasi di lingkungan yang tidak konsisten

  • Layanan Komputasi Tanpa Server (PaaS)

    Server dan administrasi sistem

Masing-masing dan setiap revolusi ini memiliki satu ciri umum: semuanya memberikan kontrol lebih kepada insinyur perangkat lunak. Mereka melakukan ini dengan mendorong praktik yang baik dan berbagi kode dengan alur kerja kolaboratif, dan mereka menurunkan kebutuhan akan server khusus yang mahal, administrator Sistem, DevOps, dukungan TI, dan sebagainya.

Bagus, tapi tunggu - di mana Fargate dalam semua ini?

Kapal Anda adalah masalahnya

Lihat, ketika Docker membawa kontainer ke massa, itu dengan cepat menjadi standar baru dalam pengembangan dan diadopsi secara luas.

Segera setelah itu, dan mengikuti kesuksesan Kubernetes , AWS meluncurkan layanan pengelolaan kontainernya sendiri (yang lebih mendasar): Amazon Elastic Container Service (ECS). Itu memperkenalkan konsep Tasks.

Sebuah tugas dapat berupa contoh kontainer apa pun yang bekerja bersama. Dari aplikasi web yang menjalankan web server, beberapa layanan mikro, database dan reverse proxy, hingga daftar kumpulan skrip shell yang akan berjalan secara berkala.

Sebagai pengguna awal ECS, saya sangat menyukainya dan berfungsi dengan baik untuk sementara waktu. Namun pada akhirnya, harus mengelola lapisan ekstra ini (Tugas dan penampung), bukan hanya instans EC2, menjadi semakin rumit.

Saya juga tidak nyaman dengan keamanannya . Semakin banyak lapisan yang Anda miliki di tumpukan, semakin Anda harus waspada. Masing-masing lapisan ini menghadirkan lebih banyak kerumitan seiring dengan meningkatnya kemungkinan kesalahan konfigurasi dan kerentanan keamanan.

Memang, dengan ECS penampung Anda berjalan di instans penampung EC2 dalam kluster yang akan Anda konfigurasikan untuk penskalaan otomatis. Setiap instance dapat menghosting banyak tugas berbeda. Setiap tugas dapat menjalankan banyak kontainer.

Karena tugas Anda akan diterapkan secara acak (secara default) pada jenis instans EC2 yang sama dengan sumber daya yang tersedia , Anda menghadapi masalah berikut:

  • Satu kluster mengikuti aturan yang sama untuk penskalaan otomatis dan secara otomatis menyediakan jenis instans EC2 yang sama.
  • Beberapa penampung akan membutuhkan sumber daya yang sangat berbeda tetapi tetap harus bekerja sama.
  • Beberapa penampung tidak selalu mengikuti aturan yang sama untuk penskalaan otomatis.
  • Terkadang beberapa penampung dalam tugas yang sama membutuhkan penyeimbang bebannya sendiri, dan tidak mungkin memiliki beberapa penyeimbang beban untuk tugas yang sama.

Solusi yang lebih disukai saat menghadapi masalah ini adalah:

  • secara manual menerapkan beberapa instance Anda dengan sumber daya yang berbeda berdasarkan kebutuhan
  • lampirkan instance ini ke cluster Anda
  • menjalankan satu wadah dengan tugas
  • tautkan instans EC2 Anda secara manual bersama-sama
  • tulis batasan penempatan strategi yang rumit pada ECS untuk memastikan tugas yang tepat ada di mesin yang tepat yang memiliki sumber daya yang sesuai tergantung pada apa yang dilakukannya

Itu pekerjaan yang banyak , sangat membosankan , dan sulit untuk dipertahankan. Dan itu seperti mengalahkan tujuan bekerja dengan kontainer di tempat pertama.

Seseorang harus mendapatkan ide yang lebih baik.

Biarkan mereka mengapung

Ternyata, tim AWS memiliki masalah yang sama. Mereka memikirkannya selama setahun terakhir, dan berupaya memecahkan masalah di bawah ini:

Bagaimana kami dapat menjalankan container tanpa harus mengkhawatirkan server dan cluster?

Dan inilah yang dimaksud dengan AWS Fargate . Ini benar-benar mengabstraksi infrastruktur yang mendasarinya, dan Anda melihat setiap container Anda sebagai satu mesin.

Anda hanya perlu menentukan sumber daya apa yang Anda butuhkan untuk setiap kontainer dan itu akan melakukan pekerjaan berat untuk Anda. Anda tidak perlu lagi mengelola aturan akses berlapis-lapis. Anda dapat menyesuaikan izin antara penampung Anda seperti yang akan Anda lakukan antara satu instans EC2.

Ini seperti kontainer Anda menjadi kapal dengan layar, kemudi, dan kru mereka sendiri dan mampu mengapung ke tujuan mereka sendiri.

Kontainer sebagai Layanan (CaaS)

Saya benar-benar percaya bahwa Containers as a Service (CaaS) adalah PaaS nyata yang telah ditunggu-tunggu oleh pengembang selama bertahun-tahun. Ini memungkinkan pengembang untuk menyebarkan kontainer mereka langsung di cloud tanpa harus mengkhawatirkan semua yang ada di antaranya.

Tentu saja sudah ada banyak teknologi di luar sana yang memungkinkan Anda menjalankan kode dengan mulus di cloud tanpa harus mengkhawatirkan skala atau administrasi server (seperti Heroku , Lambda, atau bahkan mesin aplikasi Google dengan caranya sendiri yang menakjubkan) . Tetapi semua memiliki keterbatasan.

  • Anda harus memilih antara kehilangan sedikit fleksibilitas
  • Anda harus tetap menggunakan bahasa yang didukung
  • Anda tidak dapat menggunakan bahasa yang didukung karena project Anda memerlukan library native level rendah yang hanya tersedia di sistem yang sangat spesifik
  • Proyek Anda menggunakan teknologi canggih yang tidak akan tersedia untuk umum dalam beberapa tahun mendatang
  • Beberapa dari platform ini sangat (sangat) mahal, terutama saat ditingkatkan

Fargate (Or CaaS) memberi Anda yang terbaik dari kedua dunia.

Arsitektur dalam container memberi Anda fleksibilitas dan kontrol yang Anda butuhkan. Ini memungkinkan Anda untuk menggunakan segala jenis teknologi yang berjalan di semua jenis sistem yang Anda inginkan. Aspek penampung akan memastikan bahwa Anda akan memiliki perilaku yang sama pada setiap host, baik itu lingkungan dev, pengujian, pementasan, atau prod.

Saya menemukan poin ini penting untuk banyak startup teknologi. Faktanya, terkadang salah satu keunggulan kompetitif Anda adalah penggunaan teknologi mutakhir yang telah Anda kembangkan, atau penggunaan kembali teknologi lain secara cerdas dalam konteks yang benar-benar baru dan revolusioner.

Penerapan tanpa server memungkinkan Anda untuk fokus pada penulisan kode yang hebat. Tidak ada penyediaan, penskalaan mudah.

Batasan

CaaS vs PaaS

Memang benar Anda melepaskan beberapa aspek keren dari PaaS yang sebenarnya. Ya, Anda masih harus memperbarui gambar penampung Anda secara manual , dan terkadang Anda harus menulis gambar Docker Anda sendiri. Ini bisa menjadi perjuangan pada awalnya jika Anda tidak mengetahui dasar-dasar administrasi sistem .

Tetapi, ini juga berarti bahwa Anda dapat melakukan hampir semua hal yang dapat Anda pikirkan dan memiliki fleksibilitas dan kebebasan penuh dalam sistem, bahasa, alat, pustaka, dan versi yang ingin Anda gunakan.

Biaya

Mari kita hadapi itu, layanan Cloud (IaaS) lebih mahal daripada memiliki infrastruktur Anda sendiri (jika Anda dapat menaikkan dan menurunkannya sesuai permintaan). Untuk alasan yang sama, tidak harus menyediakan, mengelola, dan menskalakan server Anda memiliki biaya. Ini mungkin belum menjadi solusi terbaik untuk beberapa kasus penggunaan Anda yang paling sederhana.

Mari berharap mereka akan bekerja untuk menurunkan biaya. Sebagus produknya, sulit untuk membenarkan hampir 4 kali harga instans EC2 yang setara sesuai permintaan (misalnya untuk t2.medium).

Haruskah saya mengalihkan semua tugas ECS saya ke Fargate?

Belum. Seperti yang dinyatakan di atas, dalam beberapa kasus, Anda akan menambah lebih dari tiga kali lipat biaya Anda. Sampai mereka menurunkan biaya, Anda mungkin lebih baik menggunakan instan EC2 standar.

Namun, Fargate mungkin lebih bermanfaat bagi Anda dalam kasus penggunaan berikut:

  • Jika Anda mengalami masalah penskalaan otomatis tugas ECS Anda secara efisien dan sering kali berakhir dengan banyak CPU atau Memori yang tidak terpakai . Dengan Fargate, Anda hanya membayar sumber daya yang telah Anda tentukan dalam tugas Anda .
  • Untuk tugas Anda yang akan berjalan sesuai permintaan atau jadwal dan tidak memerlukan instans EC2 khusus. Dengan Fargate, Anda hanya membayar saat tugas Anda sedang berjalan.
  • Untuk tugas Anda yang memiliki puncak penggunaan Memori dan / atau CPU . Hanya karena itu akan menghemat waktu dan kerumitan konfigurasi dan pengelolaan kasus semacam itu.

Bonus

Bagi mereka yang lebih memilih Kubernetes daripada ECS , Fargate akan segera dapat menjalankan Layanan Kontainer Elastis untuk Kubernetes.