If you're just replacing hardware, yeah, cost isn't an advantage. Because you still have your datacenter (or not enough hardware to have ever required one), you still have your IT department (or not enough systems to have ever required one), you still have to have your devops team (or not enough software/instances to have ever require one), etc.
The advantage of a lot of these is that you don't need any of that. You can have just a dev team, nothing else, and be up and running at any scale. At that point cost comparisons may come out in favor of a cloud solution (or at any rate are so close that the tradeoffs become acceptable, hence their popularity)
> You can have just a dev team, nothing else, and be up and running at any scale.
Has anyone done this in practice at significant scale? Every shop I know of with a big cloud deployment has armies of devops people managing the deployment, and further reserve armies on pager-duty standby in case something blows up. They're certainly doing different things than if you had an in-house datacenter (less hardware maintenance, more cloud orchestration), but I'm not convinced the sysadmin/devops headcount has actually gone down.
There are plenty of examples at this point. A few I can think of off the top of my head -
TwitPic relied on it and operated as basically a one or few person shop the entire time. At the peak, before Twitter came up with their own solution, it was a relatively large service.
Instagram, Imgur, and Reddit all had/have (Instagram of course moved to FB) small teams operating at vast scale with the help of AWS.
Slack has probably benefited a lot from leaning on AWS for scaling purposes, given their rapid growth. I'd place a bet that they have managed to achieve their scale with a relatively small team managing their infrastructure.
You mean Imgur and Reddit that keep going down and have always been notoriously bad at staying up? Not a good example at all.
Also Twitpic didn't reduce their sysops, they simply kept it low, AWS didn't do that, a server which serves much more complex stuff and many more people than twitpic can be run by one person, see stackoverflow.
There are a lot of people out there who don't realize what can be done with one or two dedicated servers and one or a handful of good developers without ever mucking around with cloud. Cloud can just add yet another point of failure to a small business if it wasn't worth it in the first place.
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.
I'm not saying you can't run a large business in the cloud, what I'm skeptical of is whether you can run a large business in the cloud without devops staff, having only developers while the cloud 100% takes care of devops for you.
That's not how I interpreted the comment you responded to. I thought it meant that you didn't mean IT staff, which is true. When you use cloud services, someone else is yanking dead drives and replacing them, someone else has a 24/7 on-call rotation for dealing with power outages and fiber cuts, someone else is responsible for hardware at all levels and lower-level software stuff. That's how I understood that comment.
Now you're talking about DevOps, which is short for Development Operations, which is a developer role, not an IT role. DevOps people automate your buildchain and that kind of stuff. No one is saying that using cloud services means you don't need DevOps, though there are some cloud services that will handle at least part of what is traditionally in the realm of DevOps for you.
The advantage of a lot of these is that you don't need any of that. You can have just a dev team, nothing else, and be up and running at any scale. At that point cost comparisons may come out in favor of a cloud solution (or at any rate are so close that the tradeoffs become acceptable, hence their popularity)