Kami memiliki masalah yang menarik beberapa tahun yang lalu. Kami adalah perusahaan yang sepenuhnya jarak jauh dengan semua perangkat lunak kami di cloud. Dan kami memiliki rangkaian aplikasi Spring Boot yang berjalan pada wadah dengan Infrastructure as Code. Namun kami membutuhkan kelincahan bisnis.

Pasar tenaga kerja global bergerak cepat, dan selalu ada permintaan untuk produk baru. Kami harus menemukan cara untuk mempertahankan keunggulan kami di industri ini.

Kami adalah perusahaan teknologi dengan strategi yang berani

Dalam 2022, kami membuat ADR (Architecture Decision Record) yang menyatakan, "serverless-first dan container-as-needed." Dan memicu perdebatan di hampir tim teknik 40.

Mari kita jelaskan beberapa terminologi terlebih dahulu

Serverless-first tidak hanya berfungsi sebagai layanan. Ini juga merupakan sekelompok layanan terkelola dari penyedia cloud yang: 

  • Biaya operasional yang lebih rendah dengan tidak mengelola infrastruktur

  • Skala sesuai kebutuhan, termasuk skala ke nol untuk membuatnya sepenuhnya elastis

  • Memiliki harga yang elastis (Anda hanya membayar apa yang Anda gunakan) 

Di G-P, serverless-first mengacu pada penggunaan AWS Lambda, EventBridge, Step Functions, Fargate, SQS, SNS, Antarmuka Pemrograman Aplikasi Gateway, S3, DynamoDB, dan lainnya.

Serverless-first berarti bahwa ketika kami memilih solusi untuk Compute, Storage, Messaging, atau sejenisnya, kami ingin tim memulai dengan opsi tanpa server. Catatan penting: Jika layanan tanpa server tidak memenuhi kebutuhan, tim harus kembali ke layanan yang lebih berat — layanan yang membutuhkan lebih banyak investasi operasional.

"Wadah sesuai kebutuhan" menjelaskan bahwa serverless-first bukan berarti serverless saja. Ada kalanya kita membutuhkan kontainer (misalnya, menginstal produk perangkat lunak COTS) - dan tidak masalah.

Strategi teknologi yang memprioritaskan pelanggan

Kami bergerak dengan kecepatan yang gesit untuk memenuhi kebutuhan pelanggan dan pengguna kami. Layanan seperti Lambda, S3, dan DynamoBD sangat tangguh dan cepat. Dengan melepaskan beban berat yang tidak perlu, kita bisa menghabiskan lebih banyak waktu untuk membangun fitur bagi pengguna, daripada mengerjakan konfigurasi infrastruktur umum.

Prinsip utama di G-P adalah: " Anda membangunnya, Anda menjalankannya. " Tim kami memiliki perangkat lunak mereka. Jadi, kami tidak hanya melemparkan perangkat lunak ke dinding ke tim DevOps. 

Manfaat dari "serverless-first"

Tanpa server secara inheren didorong oleh peristiwa.

Arsitektur kami sepenuhnya didorong oleh peristiwa. Dengan menggunakan EDA (Event-Driven Architecture), kita dapat menskalakan organisasi dan perangkat lunak kita. Tanpa server memaksa kita untuk menjaga radius ledakan kecil dan berkomunikasi dengan cara yang sepenuhnya cloud-native melalui acara.

Kendala yang memungkinkan

Sebagai platform ketenagakerjaan global, kami menangani kepatuhan dengan serius. Infrastruktur cloud kami dirancang dengan baik, dan kami menggunakan strategi multi-akun yang memisahkan beban kerja dan mengotomatiskan kepatuhan cloud. Tanpa server membantu kami menegakkan standar tinggi dengan mengendalikan cara kami menyediakan sumber daya cloud.

Bongkar pekerjaan

Penyedia cloud kami mengelola layanan tanpa server kami. Satu set blok bangunan — terintegrasi, diamankan, disetel, diaktifkan, dan dikelola oleh AWS — membebaskan kami untuk fokus lebih tinggi pada rantai nilai bagi pelanggan.

Beban kerja yang dirancang dengan baik

Setiap beban kerja yang kami buat ditinjau dengan AWS Well-Architected Framework. Kami fokus pada skala, keamanan, keandalan, dan pengoptimalan biaya untuk memastikan bahwa kami tidak hanya memenuhi, tetapi juga melampaui SLA (Perjanjian Tingkat Layanan) kami. Ini memberdayakan tim teknik kami saat kami terus berkembang dengan lingkungan cloud. 

Tentang tim kami

Strategi Teknologi Kita ambisius, dan itu membuatnya menantang. Banyak insinyur yang belum pernah bekerja dalam arsitektur tanpa server (atau arsitektur terdistribusi). Transisi ke arsitektur tanpa server tidaklah mudah, dan kami mencari insinyur yang nyaman belajar, berpikir besar, dan bergerak cepat.

Beberapa insinyur tidak yakin dengan istilah serverless (ya, kami tahu ada server) karena pendekatannya lebih dari sekadar menulis kode dalam fungsi. Strategi kami membutuhkan pendekatan holistik terhadap prinsip-prinsip cloud-native klasik.

Hasilnya

Kami telah membuat kemajuan yang luar biasa dalam dua tahun. Ada banyak manfaat untuk modernisasi (lihat artikel kami tentang AWS/nilai bisnis yang diketahui dari modernisasi cloud). Secara khusus, kami telah mengamati hal-hal berikut ini:

1. Kecepatan: Cara kami memecah sistem kami memungkinkan tim dan produk untuk berinovasi dan berkembang secara mandiri. Hal ini berdampak besar pada kelincahan bisnis.

2. Kepatuhan: Kami menggunakan AWS Well-Architected Framework untuk meninjau semua beban kerja. Karena kami menggunakan banyak AWS Managed Services, kami dapat mengandalkan keunggulan operasional mereka dan memulai dari tempat yang berkualitas tinggi.

3. Pemikiran sistem: Kami harus menstandarkan banyak proses kami sehingga kami dapat berpikir tentang sistem, keandalan, dan nilai bisnis. Kami tidak menghabiskan waktu untuk mengerjakan komponen bernilai rendah.

4. Inov asi: Tanpa server berarti semuanya adalah Antarmuka Pemrograman Aplikasi. Kendala paksa ini membutuhkan pendekatan Antarmuka Pemrograman Aplikasi-first. Ketika kita menganggap diri kita sebagai platform, kita dapat mencapai tingkat inovasi baru dengan mudah menghubungkan sistem melalui Antarmuka Pemrograman Aplikasi, seperti mencolokkan G-P Gia™ ke basis pengetahuan baru.

5. Kepemilikan: AWS memiliki infrastruktur kami, tetapi kami memiliki domain bisnis kami. Serverless-first dengan desain berbasis domain telah memaksa kami untuk fokus pada masalah bisnis. Ini membuat kepemilikan kemampuan tetap jelas.

Serverless-first tidak selalu lebih cepat, tetapi lebih menguntungkan. Kami lebih suka mengoptimalkan untuk kecepatan sistem daripada kecepatan pengembang individu. Serverless-first tidak terlalu banyak menggunakan fungsi dan lebih banyak berpikir, "Kode adalah sebuah kewajiban. Sistem adalah aset." Semakin sedikit kode yang harus kita tulis, semakin banyak yang dapat kita pertimbangkan dan bentuk dari sistem bisnis yang kita bangun.

Saat kami membagikan kisah kami, akan terlihat jelas kecepatan yang kami kerjakan, yang merupakan hasil langsung dari serverless-first. Tetap disini.