The promise of both Kubernetes and serverless was to abstract away the infrastructure from the developer, who can stick to writing line-of-business code. In bot

The promise of both Kubernetes and serverless was to abstract away the infrastructure from the developer, who can stick to writing line-of-business code. In both cases, companies end up needing to hire infrastructure teams to manage the underlying infrastructure. Author is making a moot argument that doesn't resonate. The real struggle is about steady-state load versus spiky load. The best place to run steady-state load is on-prem (it's cheapest). The best place to run spiky workloads is in the cloud (cheapest way of eliminating exhausted capacity risk). Then you have crazy cloud egress networking costs throwing a wrench into things. Then you have C-suite folks concerned about appearances and trading off stability (functional teams) versus agility (feature teams) with very strong arguments for treating infrastructure teams not as feature teams ("platform teams") but as functional teams (the "Kubernetes team" or the "serverless team"). And yes, there woukd be a "serverless" team, because somebody has to debug why DynamoDB is so expensive (why is there a table scan here...?!) and cost-optimize provisioned throughput, and somebody has to look at those ECS Fargate steady-state costs and wonder if managing something like auto-patching Amazon Linux is really that hard considering the cost savings. At the end of the day, infrastructure teams are cost centers, and knowing how to reduce costs while supporting developer agility is the whole game.