[caw]

If you take your definition as "ops people who code and automate", you get a really efficient ops team who can orchestrate several hundred or thousand servers.

You still then have a friction point between "dev" and "ops" relating to hand off. Ops could go full PaaS, but more than likely you'll end up with a "cloud" infrastructure where your dev team will have to learn ops, or the traditional model where stuff gets thrown over the fence. Good luck deploying that service because there was no capacity planning and it'll take 6-8 weeks to get hardware from the vendor, regardless of whether ops can rack it and build it in under a day.

It's far better to have an org overlap so that ops is involved in dev planning to help address roadblocks, assist in capacity planning and management, as well as help reduce friction in tasks.

[late2part]

But, the purists would reply, if you simply outsource all your hardware to AWS or another place, you don't ned that ops or capacity planning. Until you do. This weekend AWS ran out of i2.2xlarge instances in a particular AZ, for example.

[ecnahc515]

Hate to tell ya, but at anything other than the 'prototyping stage', you'll probably need a dedicated OPs guy, AWS or not.

[dreamfactory2]

that's noops/movedops not devops