[facebiff]

I think a lot of folks who argue "you should learn how to be a DevOp" are working on a single product that's always in active development. And they tend to see the problem through that lens. (maybe I'm wrong about about the OP, but that's my sense)

If you're a consultant or work on multiple projects, the equation changes significantly. What if you're building a web app for university, for example, with a fixed budget, and once it's feature complete, it goes into "maintenance mode" with very few updates for the next couple years?

Do you want to continually be in charge of DevOps for something that isn't actively being developed for several years, having to ramp back up when issue arises every three months? Is that the best value for the client organization? Or would you rather outsource that? I'd usually choose the latter, and in my experience, it's been a better value for clients.

[ghempton]

DevOps doesn't imply constant maintenance. A basic configuration on a site with low/constant traffic will probably not require many updates.

If anything, using something like Chef will make it easier to perform those updates if the need actually arises.

[jaggederest]

Easier than having someone else maintain it?

The bar is 'If I never ssh into this box and leave this app alone for 3 years, how likely is that box to get rooted?'

[grey-area]

Does heroku ssh in for you and update your rails installation or other custom software? If not there's no way you should leave any software unattended for that length of time. Most java, python, ruby and php frameworks/apps will all have had vulns in that period for example. Also do they upgrade things like ruby without you redeploying?

What heroku buys you is not having to deal with updating the web server and database, as they'll deal with all of that, but I wasn't aware that they provide a fully managed service like say wordpress.com, and I don't see how they could for custom apps.

[ghempton]

If you have left your heroku app alone for 3 years, you are definitely at risk of getting rooted: https://blog.heroku.com/archives/2013/1/11/rails_security_vu...

[jdminhbg]

You don't need to ssh into the box to take care of Rails vulnerabilities; just redeploy. Heroku is taking care of any vulnerabilities in the rest of the stack: Postgres, Nginx, SSH, etc.

[grey-area]

The thing is, that's actually the easy bit - use apt-get upgrade on say Ubuntu lts and you will very rarely see problems with your upgrade of software like Postgres, apache, ssh or nginx - it's so widely used that you're unlikely to run into issues, and upgrading takes a few minutes every few months.

The thing you need to test then deploy are upgrades to your language and framework/app, and those present exactly the same problem on heroku or on say a vps. You can't just redeploy your app without testing on a new config, and deploys to heroku are no easier or harder than deploys to your own server once set up.

[ghempton]

You also don't need to ssh into the box with chef...

[jaggederest]

Technically you're both wrong - both chef and git use ssh as an underlying transport.

[jaggederest]

Who says it's a rails app? I run a couple raw-rack apps that hum along just fine with very, very occasional updates.