The big voices in serverless present a false dichotomy. Pay-per-execution systems don’t really care if your thing is architected as a FaaS or a monolith or a microservice. Monoliths are awesome when they work. Use them on lambda, cloud and azure functions when the bill is right. Microservices don’t really address performance as much as (usually political rather than technical) coupling, and serverless can be viewed as providing additional avenues for decoupling.
The complexity that requires, as the article says, “uber-architects” is mostly going to come down to one-time-costs implemented by the frameworks and cloud providers. The problems are not hard to solve, we just haven’t churned out one that achieves critical buy-in yet. That will come for most of these issues in the next year or two.
Devops won’t die, just like the old DBA’s and perl slinging ops folk never died. Container orchestration is not really what most businesses (who have no infrastructure identity) care about. That’s OK. The world moves forward. But we’ll see a lot of angry, confused people who just learned Go, escaped their enterprise java prison, built a docker container, got an infrastructure job, and then realized that they are not the sexy hot things that such a skillset communicated. I get it. I’m an infrastructure person too, and it can be scary to think that the future may not care what I am knowledgeable about now. Life moves on.
It seems a PaaS like Google App Engine fullfills most promises of serverless computing (scalability and not having to deal with machines, storage, etc.) without having to switch to a FaaS architecture completely based on serverless functions.