Why Serverless Is the Right Choice Now: Insights from a Shenzhen Meetup

1、Complexification for Cloud Providers

Serverless is built on a layered architecture: a CaaS (Container-as-a-Service) layer runs on top of Kubernetes, which itself runs on virtual machines and physical hardware. Various implementations (Docker, VM, WebAssembly) can serve as CaaS, while a Component layer handles networking via service mesh and ingress.

Cloud providers treat the entire stack as immutable infrastructure, migrating configurations across Alibaba Cloud, Tencent Cloud, AWS, or private clouds. This shifts complexity down to the K8s layer, making the architecture portable.

Traditional advantages of cloud vendors (VM IaaS and PaaS) diminish as Serverless abstracts services like MySQL or Redis into BaaS, allowing developers to request a database without managing its underlying servers.

In this narrow sense, Serverless combines triggers (or BaaS) with FaaS and BaaS, forming a stack where cloud vendors continuously add new BaaS capabilities.

2、Simplification for Developers

According to Gartner’s 2017 technology adoption curve, Serverless was once a nascent technology in the “climbing” phase; today it has entered a mature “plateau” phase, with clear understanding of its operational benefits and limits.

Serverless now integrates with other domains—micro‑services, low‑code platforms, and frontend‑backend integration—enabling BaaS‑style micro‑services, rapid page deployment, and Serverless‑for‑Frontend (SFF) architectures.

Developer roles evolve: front‑end engineers can now orchestrate backend logic visually, reducing reliance on dedicated backend teams, while backend engineers shift toward building BaaS services, and ops engineers focus on cloud migration.

3、Best‑Practice Scenarios for Serverless

Choosing a Serverless use case starts with the triggers a cloud provider supports; developers package code as functions and invoke them via HTTP, message queues, or other events.

Language is no longer a constraint—Node.js, PHP, Python, or custom runtimes can all run as FaaS, allowing teams to pick the best tool for each task.

1) SFF Data Orchestration

Combining BFF with Serverless is a common pattern: front‑end teams deploy Node.js functions as BFFs without worrying about scaling or cost.

2) GitOps Model

GitOps automates deployment pipelines, especially for small teams, leveraging cloud provider CI/CD capabilities for seamless releases and traffic replay.

3) Small‑but‑Mighty Teams

Serverless enables compact teams to deliver full‑stack features: front‑end engineers handle data orchestration via SFF, GitOps removes operational overhead, and back‑end engineers focus on BaaS services.