[3amOpsGuy]

Skills.

Most developers are not full-stack aware - nor should they be. Having a pack of generalists drive a product is sure to reduce momentum.

Better that the contract is "here's a platform you can deploy to" than "here's some CPU time, break it and you get to keep both pieces"

[vidarh]

Everywhere I've worked, the developers have needed to figure out the dependencies requires to get the software working. Sometimes with the assistances of a dev-ops or ops guy.

All this does is say "while you figure that out, put it in a script". First, it means we can test the dependencies easily by re-running the script to see that it actually accurately reflects what needs to be done.

Secondly, when you're done, you have a reproducible deployment environment that massively simplifies ops and dev: Ops can decide on upgrades, re-run the scripts, have QA run their tests and know the upgrade won't break stuff in production. Dev can make code changes and be confident that what they hand off will actually work in the production environment because they've test deployed it on VMs built from identical templates.

As long as your team can figure out how to deploy the software they write, they can do this. If they can't, you have bigger problems.

[3amOpsGuy]

That's just the dev concerns.

Here's a rather contrived example but it illustrates the idea i'm getting at: "Will the inventory agent software be able to login to audit this container environment when they're done building their release?"

[jacques_chester]

PaaS is definitely something I didn't foresee. Happily, I think it proves my case, if only indirectly, that shared hosting is a dead end.

[waxzce]

The point is : PaaS give you the advantages of shared hosting, but a good PaaS isolate properly all apps. It's definitively a good way to focus on dev and let a ops and constraint on trained teams.