If you're just using a cloud provider as a remote VM farm, you'll still need devops, sure. If you're using an automatic container scaling solution, such as AWS

If you're just using a cloud provider as a remote VM farm, you'll still need devops, sure. If you're using an automatic container scaling solution, such as AWS' Elastic Beanstalk, you can still benefit from devops, but I'd argue you don't need it; all the difficulty resides in structuring your application to be able to handle that environment, a problem for your software devs. The devops burden is low, and the time to communicate what a developer needs to the devops is likely going to trump the time taken for the developer to just do it. If you're looking to use a containerless solution using cloud resources (like AWS' Lambda, API Gateway, and Dynamo to create a CRUD app), you don't need devops. All your difficulty resides in reducing and/or handling state between functions (well, and any other shortcomings in the actual implementation of the service); again, a software problem. Basically, Amazon, at least (what I have the most experience with) seems to be looking to remove the need for devops by creating standard workflows and mechanisms to bind services together with arbitrary code, and to be able to inherently scale out. The remaining devops burden is sufficiently small, and so tightly integrated with the nature of the software involved, that it's oftentimes more effective to just have the devs handle it. While sufficient amounts of code might turn that into a devops role, what I meant by scaling out is a particular app handling a given amount of load. In a classical datacenter environment, moving from an app on one box to an app that spans many is something both the software devs and devops have to concern themselves with, but in the cloud it's mostly just a dev consideration; if the app is written to handle multiple copies of itself, spinning up those extra copies should be close to if not actually trivial. That was all that I was saying; the move from one to many doesn't require devops any longer, as "how do I make sure all of these boxes are set up properly, get deployed onto, are kept in sync, load is shared between them, etc" are problems that cloud providers have provided tools to solve, and what they leave out doesn't require dedicated devops to address.