Coming from a background of having to deal with the highest level of PCI-DSS scrutiny, this makes total sense. It would have been soooooo much easier to just point the auditors to the managed hosting service and say, "ask them, they're the experts." Leaving myself and the other devs to just worry about software security.

What happens if/when an issue comes up that the managed service can't/won't resolve? If you can move to another provider that will, you'll have some leverage. But there's always headaches associated with any move/migration and a possibility of lock-in to the provider's platform.

Yes, I certainly agree. One of the major problems with taking an application implemented on a PaaS solution to production scale is that you essentially join at the hip the continued success of your core product to the eventual fate of an outside vendor's platform. What's worse is that by the time you realise you've grown too big for the PaaS you may have to expend a huge amount of engineering effort and customer good will to move off, if you even can. Indeed, PaaS providers will try to make it /easy/ for you to make engineering decisions which lock you into their platforms -- and they will present those choices as helpful at the time, which makes them quite insidious partners.

This is a very valid concern. We are in the early stages of this transformation and naturally winners and losers will emerge as the market becomes more mature and the big guys begin to purchase and consolidate PaaS.

Rewind N years and you can replace PaaS with some other technology that eventually matured and is now considered ubiquitous.

Good point. Two companies I know of (Expensify.com and Trap.it) get around this to a certain degree by hosting on multiple vendors. With that they are better able to account for sudden changes to the market if one goes down or drastically raises their prices.

No, this article is talking about the first stage in Pinboard's piece, 'The Monastery':

"You run your site on an 'application platform' like Heroku, Azure, or Google App Engine. You design your application around whatever metaphors and APIs the service lays out, and in return you are veiled from all the mysteries of implementation. You never interact with the computer directly, but upload your code to the platform with the proper incantations and it runs. The orders vary in strictness, with GAE requiring that you purify yourself of all worldly design habits before writing your app, Azure insisting you renounce the demon Unix, and Heroku somewhat more welcoming to the fallen. On all three platforms, when your application needs more resources, you press the 'more resources' button. A lot of fancy sandboxing, monitoring and administration tools come standard, and it's very easy to deploy and test different versions of your app."

I think the whole point is the developer no longer have to be concerned about the day to day management of the server (e.g. tuning disk I/O, manually deploying applications and services, setting affinity on processes, managing logs), as that will be shifted completely to the infrastructure managers. And that is fine. Infrastructure should be devolved completely back to the administrators and developers should just write code that runs automatically with no modification in the cloud.*

I am not sure what the last question supposed to be, but I assumed it implies that systems administration will be obsolete. It is possible that it will change,but consider this: in the past, most sysadmins worth their salt should at some point be able to write code. It is only recently (it seems around the late 90s) that there was a generation of admins that didn't have the technical chops to write code or even simple scripts. With the advent of cloud and the management tools that comes with it that requires a significant programming background to manage (e.g. writing Puppet or Chef code), this is a welcome return to the past.