Seni Bina Serverless-First

Serverless-first kurang sesuai untuk proses yang berjalan lama melebihi 15 minit, beban kerja yang memerlukan sambungan WebSocket berterusan, aplikasi dengan trafik high-throughput yang konsisten di mana reserved capacity adalah lebih murah, dan sistem yang memerlukan konfigurasi OS atau network peringkat rendah. MicrocosmWorks menilai setiap beban kerja berdasarkan kekangan ini semasa reka bentuk seni bina dan mengesyorkan pendekatan hibrid di mana serverless mengendalikan API endpoints dan event processing manakala containers atau VMs menjalankan beban kerja yang memerlukan persistent compute. Pendekatan pragmatik ini mengelakkan kesilapan biasa memaksa setiap komponen ke dalam serverless apabila ia tidak sesuai.

MicrocosmWorks mengurangkan cold start Lambda melalui provisioned concurrency untuk titik akhir kritikal, pengoptimuman bundel fungsi untuk mengurangkan masa inisialisasi, dan penggunaan strategik Lambda SnapStart untuk beban kerja Java yang memendekkan cold start dari saat ke milisaat. Kami juga mereka bentuk aplikasi supaya laluan sensitif kependaman menggunakan runtime ringan seperti Node.js atau Python dengan kebergantungan minimum, mengekalkan cold start di bawah 200ms walaupun tanpa provisioned concurrency. Untuk titik akhir di mana kependaman sedemikian pun tidak dapat diterima, kami menggunakan Lambda@Edge atau CloudFront Functions untuk respons di bawah 10ms.

MicrocosmWorks menyiapkan persekitaran pembangunan tempatan menggunakan alat seperti SST (Serverless Stack), LocalStack, atau Serverless Framework's offline mode yang meniru perkhidmatan awan pada mesin pembangun dengan ketepatan hampir seperti pengeluaran. Kami melaksanakan suite ujian integrasi yang berjalan terhadap persekitaran awan sementara yang diwujudkan bagi setiap pull request, supaya pembangun dapat mengesahkan terhadap perkhidmatan AWS sebenar tanpa berkongsi persekitaran staging. Pendekatan dwi ini memberikan gelung lelaran tempatan yang pantas untuk pembangunan sambil mengesan isu khusus awan sebelum kod mencapai pengeluaran.

MicrocosmWorks telah mendapati bahawa serverless jauh lebih murah untuk aplikasi dengan corak trafik berubah-ubah atau memuncak—selalunya 70-90% kurang daripada penempatan kontena 'always-on' yang setara—tetapi kelebihan kos berkurang pada kadar pemprosesan berterusan melebihi 10-20 juta invocations sebulan. Kami membina model unjuran kos semasa reka bentuk architecture yang membandingkan harga per-invocation serverless dengan kapasiti kontena yang ditempah untuk corak trafik khusus anda, termasuk kos tersembunyi seperti caj API Gateway dan yuran pemindahan data. Perkhidmatan optimization kami, tersedia pada kadar perundingan $10-$35/jam, sentiasa menyemak bil serverless untuk mengenal pasti pembaziran daripada memori yang terlebih peruntukan (over-provisioned memory), tempoh fungsi yang berlebihan (excessive function durations), atau penggunaan API Gateway yang tidak perlu.

MicrocosmWorks menggunakan proksi pengumpulan sambungan (connection pooling proxies) seperti Amazon RDS Proxy atau PgBouncer yang digunakan sebagai lapisan berterusan antara fungsi Lambda dan pangkalan data, yang memultipleks beribu-ribu sambungan Lambda ke dalam kumpulan sambungan pangkalan data sebenar yang boleh diurus. Kami juga mereka bentuk aplikasi tanpa pelayan (serverless applications) untuk mengutamakan DynamoDB atau pangkalan data tanpa sambungan (connection-less databases) lain untuk beban kerja berketumpatan tinggi (high-concurrency workloads) di mana pengumpulan sambungan (connection pooling) masih akan menimbulkan kesesakan. Untuk aplikasi yang mesti menggunakan pangkalan data relasional (relational databases), kami melaksanakan had penskalaan yang peka sambungan (connection-aware scaling limits) yang mengehadkan invokasi Lambda serentak untuk memadankan kapasiti sambungan pangkalan data.