This sounds nice. The reality of "DevOps" in many companies is this, right or wrong: we'll make the development team do operations / infrastructure tasks, and save on hiring real, seasoned ops folks.
The problem is the team building your product often doesn't want to do that work, even if they can...
I don't think the reason companies are moving to devops is to save on ops costs. At most companies their ops guys are cheaper than their devs. They're doing it because there was an unexploited gap between development and ops that has a lot of potential.
I've interviewed many developers and operations folks. The cheap ops folks are cheap for a reason: they can't code and therefore aren't going to be automating much of anything without a lot of effort. The good ones are just as expensive as developers, because that's what they actually are...
Well, even worse, a lot of companies I've been to, are hiring "devops team", that does nothing else rather than involuntary creating yet another bottleneck, it was supposed to eradicate at first place.
That falls under my "hire the devops" criticism. A "devops team" is a bad idea. This is a blurry line, because it's also a good idea - that is, hiring someone (or a team of someones) whose job it is to think about, plan, and implement the devopsy things. But it too often comes with an attitude that development doesn't need to change, and ops doesn't need to change, and can't you just build something to make the stupid stop hurting? And then you spend your day either fighting fires in the build system or surfing Facebook and wondering where you went wrong with your career... but I digress.
The problem is the team building your product often doesn't want to do that work, even if they can...