I keep hearing responses like this about various aspects of serverless, but it makes no sense. If a lot of these serverless operations are "not any different" than various Docker operations, why should I be spending time and money to couple my application to AWS Lambda versus simply running the container myself? Why shouldn't I just deploy a container (pod) for my code if I'm already running kubernetes?
The more I hear people defending serverless, the more it feels like they're asking people to voluntarily increase their time and money costs, learn hyperspecialized and nontransferable skills, and make their application far less adaptable. All of this while accruing tons of technical debt for a pittance of some convenience.
To be clear, I'm not a proponent of serverless at all. I'm just pointing out in isolation that zipping and shipping something is not antiquated, it's just a methodology for shipping code. I guess it feels old because it's not wrapped up in a lickable CLI and online docs with great typography, but it's not fundamentally flawed.
To your point, I don't see any value of serverless over containers today. We are now at a point where container orchestration is mature enough that it's a sane default choice, but it took a while to get here. Serverless is where containers were 5-7 years ago (depending how you squint).
Will serverless ever be a credible replacement for containers? That depends on the vendors working out a whole lot of details. In theory, with the right services around it, serverless can be lighter than containers because they can fully control the baseline environment and build more into it, but that is also less flexible than containers. How much standardization will be possible between vendors? If the price comes down and the tradeoffs look good enough then I could see it eating into container marketshare, but I'm really not holding my breath. It's still 100% in the hype phase.
