Disclosure: I work as a devops coach (and player) at a global company with over a thousand developers.
TL;DR It depends whether you think devops is a particular set of skills and tools, or whether you think devops is a culture and way of working. It you look at the “what is devops” questions and answers, in one interesting answer here, they give some insights as to whether it’s just a tick box exercise of using certain sorts of tooling, or more a change in focus, behaviour and responsibilities over the previous ways of developing, releasing and supporting software. Cloud providers can give us better tools but we will still need devops skills to make best use of them. Any set of tools can be used badly and we shouldn’t expect Serverless to be any different.
I think that your colleague is thinking is that devops is a current set of skills to setup a current set of tools. Then their argument is that with the serverless movement cloud vendors are setting up ci/cd and all the tools with good defaults that means you don’t need to have expertise in setting up such tooling yourself.
Yet you can still end up with a giant ball of configuration mud and inconsistencies between all your components when you get beyond "hello lambda" and are running a business pumping out features. Continously improving how your product runs, and is monitored, and tested, and patched, and secured while continously expanding and adding new business features requires discipline, skill and hard effort.
It’s has often been said in the past “there will be no developers anymore as business people can now buy our tools to design the solution and the tool generates the code”. That will make anyone who has lived through such an implementation flinch or laugh. If the customer of the tools doesn't hire people with the development skills to use the tools they get a giant ball of mud and frustrated end users.
I would argue that just like “developers won’t disappear” as the tooling changes with “devops” we will simply see both old and new problems, and see skills and practices adapt and evolve to the new tools. Some problems go away (elasticity, provisioning VMs) but new ones take their place (chaining functions, monitor business KPIs across the distributed application).
By way of an example one form of serverless in the generic sense, which isn’t only functions or lambda, is to define your entire system in git using yaml and have git webhooks sync the configuration into a cloud provider managed Kubernetes to create your running system. You don't use servers you rent cpu and ram quota a managed cluster to host your containers. Then you can automate both creating releases and promoting releases using a slack chatbot. Whether your yaml is chaining together functions, or starting containers in kubernetes, depends on what you need to run. As soon as you get beyond a simple “hello world” webapp you need to define a whole host of yaml and workflow that “run your business” that a cloud provider cannot just gift you.
I think everyone can agree that that work of “just configuring yaml” to deploy multiple APIs and web frontends you can monitor and continously improve is “devops work”. The fact that that tools are cutting edge and can use SaaS based CI/CD, functions, rent cpu and memory quota on a shared kubernetes, use managed cloud database, etc just means it’s devops with new tools not devops with traditional tools.
I am a tech advisor at a startup where that’s exactly what we have setup. We are in the process of open sourcing the scripts that we use as OCD (our business doesnt use functions yet so currently it's OKD Kubernetes automation). I am migrating the startup to the open source version in the evenings. So during that day I do devops work with traditional tools (Jenkins et al) and in the evenings I do devops work with the very latest tools. Adding a ton of serverless lambda into the things that our startup does won’t suddenly mean that the minimal viable product would magically set itself up. As long we we need to improve our product and deploy new user experiences and configure our use of APIs we will continue to “do devops”.
I personally don’t believe in “devops teams” or “devops roles”. Devops is a way of working and it’s not working if development teams are not empowered to “design, build, deploy and support” what they make. You might hire people with technical specialists skills such as build automation and agile coaching. The tests of whether it’s “devops” or “ops” is whether they automate things so that teams are empowered and made self-sufficient. A “devops” team clicking a mouse setting up IaaS for developer teams isn’t devops it’s ops. When you replace that team with automaton it becomes devops.