DevOps as a Service?

Sorry, but the sheer number of people out there working in jobs with "DevOps" as their title and the thousands and thousands of positions that recruiters are trying to fill at the moment means that this idea, which you're far from the first to posit, is simply not correct anymore (if it ever was).

A DevOps is a sysadmin who can program. That's it, end of story. This puts these people in contrast to the non-programming sysadmin (e.g. perhaps of the Windows era of expecting a proper UI to configure things), and the non-administrative developer (again, also very much of the Windows era of producing enterprise software that is "thrown over the fence" to Ops).

The Unix administrators who scripted things in the past are the direct spiritual predecessors of the modern "DevOps" who simply have newer and better tools to accomplish the same goals.

> This means a number of tools can be DevOps as a service.

No, that doesn't make any sense at all. Tools merely provide capabilities; these must be exercised by people who understand them in order to realize value. Even as basic things are automated away, there is still a considerable role for the people who are able to knit systems together, especially for being able to unblock pure-Dev teams (for which there is still a tremendous role), facilitate test engineering and QA needs (again, a specific skillset that shouldn't always be lumped upon developers), and so forth.

Put differently: when you want to take a shop to the level of maturity to have proper automated deployment, or you get stuck with some broken CI problem you cannot figure out, when you need to make your existing product multi-region, when your org acquires some other org and you need to bridge the products together, when you need to expand to a hybrid or multi-cloud system... all of these kinds of situations require the kinds of skillsets that are labelled as "devops" today.

Don't confuse the map for the territory.