Disclosure: I work as a devops coach 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. Continuously improving how your product runs, and is monitored, and tested, and patched, and secured while continuously expanding and adding new business features requires discipline, skill and hard effort.
It 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 continuously 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 open-sourced all the scripts that we use to sync yaml in git into our Kubernetes on AWS as a project called OCD. (Our business doesn't use functions yet so currently, it's OKD Kubernetes automation but the principle would be the same). I migrated the startup to the open-source version in the evenings. So during the day I was doing devops coaching work with traditional tools (Git, Jenkins, Ansible et al) and in the evenings I do devops work with the very latest tools (Git Circleci, Helmfile). 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”. To distinguish between old and new sets of tools we might call the new style "no ops" or "git ops".
The same can be said about Site Reliability Engineering. With the old tools, you are watching VMs. With new tools, you are watching higher-level metrics such as service mesh traffic. A cloud provider cannot gift you large set of dashboards that show you how your business is running under load and diagnose and rebalance things when an intermittant bug is put live.
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 and deployment 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 plain old ops. When you replace that team with self-service automaton it becomes devops.