I wouldn't consider serverless to be the opposite of DevOps. I'd actually consider those concepts to be largely orthogonal.
Serverless and classic server environments are different kinds of system to manage. Classic operations vs. DevOps is about how you manage your systems, and who has responsibility for them.
In classic operations, software development and operations are separate teams with different responsibilities. DevOps combines these two functions into a single team (hence DevOps).
Serverless applications are still a system that needs to be managed; it's just less responsibility and effort than the traditional model. Consider: if newly released code contains a defect that's impacting the larger system, who has responsibility for detecting the problem and rolling it back? This concern exists with both server and serverless platforms, and DevOps vs. classic operations would have different answers.
I'm retired and we had separate teams with a liaison between the two, pretty much since our inception. A part of me thinks it's a good idea, but I'd worry about depth of knowledge in both disciplines, but I digress.
To this layman it seems to fit like a tee with devops, as it allows the devs to get the ops out of their hair by having them reside in a different company altogether.
Thus there is no ops to go "no way no how" where devs want to introduce some new shiny to the stack, as their only interaction is over a web api...
