Ask HN: Skeptical about my company going “full serverless”. What am I missing?

An Azure Cloud Architect has joined our company. They are recommending that all our web apps that are currently deployed in Azure App Services/ VMs should be (gradually) split up into Azure Functions going forward.

I'm skeptical - I was under the impression that serverless was for small "burstable" apps with relatively low traffic, or background processing.

The two products I work on are both REST APIs that send and receive data from a user interface (react) with roughly 60 API routes each. They have about 100 concurrent users but those users use the apps heavily.

The consensus on the internet seems to be "serverless has its use cases" but it's not clear to me what those use cases are. Are the apps I'm working on good use cases?

Depending on the use pattern, with 100 concurrent users, the serverless functions might not go "cold" often. In that setup, it's not technically much different from running REST services on a traditional server.

Whether or not it's for you has a lot to do with what's important to you. How much weight you put on runtime cost, versus ease of development / deployment, versus whatever other benefits it might bring (integrated logging, monitoring, multi-region deployment, etc). And, of course, whatever downsides it brings...like cold starts, team ramp up on how it works, etc.

Several of our portfolio companies have gone completely serverless (admittedly on AWS) and it has been working well for them. If endpoints are stateless and independent being able to scale them all separately and only paying for use (where usage is far less than 100%) it can be a huge win.

I think there's a lot of nuance to this. You may not keep any explicit state, but you may keep a lot of implicit state (often in frameworks and libraries). This state can include: database connections, cache connections, HTTP connections to downstream services, local LRU caches for computations, compiled regexes, import caches, and much more depending on the language and infra being used.

It's common for servers to take a while to start up, it's common to see the first request to each endpoint take a bit longer, it's a common optimisation to add keepalive to downsteam services, or tweak your database connection pooling. These issues are normally straightforward optimisations, and startup time isn't usually too much of an issue. With FaaS platforms these become significant hurdles that take engineering work to overcome, require introducing more services, more cost, etc.

> all our web apps that are currently deployed in Azure App Services/ VMs

What problem does migrating to a new architecture solve? Does the current deployment have scaling, maintenance, or other troubles? Going from something that's broken to something that works is one thing, but going from something that works to something else that works is pointless unless there are tangible benefits.

If the only reason is to make the Cloud Architect feel better or pad people's resumes, the correct answer is no.