The thing is, everyone has a different don't-reinvent list. And they want to be not reinvented in different ways. Then they discover all the things that they didn't realise they'll need to reinvent.
> The real issue that I feel no-one really answered is who's this for.
I see PaaSes as serving three constituencies.
Operators, who wish to christ that Developers would stop making their lives hell by breaking stuff.
Developers, who wish to christ that Operators would stop making their lives hell by blocking stuff.
Business, who wonder why everything takes so long, costs so much and breaks so often.
I sincerely hope that's not the case anymore but that lasting first impression has stopped me from looking into it since then.
Getting up and running with OpenShift is pretty easy. You can either use the all in one Vagrant VM[1] or you can download the CLI[2] and run `oc cluster up`[3] to install the docker container version.
Either one doesn't give you an "HA" install (probably want a cluster for that). I regularly deliver OpenShift installs, and in most enterprise environments an HA install takes 3-4 weeks, most of which is communicating to all the silos (networking, storage, security, virtualization, etc) what the requirements are.
Disclaimer: I work for Red Hat.
1: https://www.openshift.org/vm/ 2: https://github.com/openshift/origin/releases 3: https://github.com/openshift/origin/blob/master/docs/cluster...
I think #1 and #2 should be the same people. with PaaS I don't see any need for "operators".
If an engineer can't launch a new service with all the requirements EASILY, you're doing something wrong
You're == all of us, myself included.
Yes and no. What we're finding is that you need far fewer operators. But you still need someone to keep an eye on things and run 'bosh deploy' to upgrade the cluster or add a new service. The latter could be automated, but it's one of those things people like to do under supervision.
At Pivotal we run Pivotal Web Services (PWS) -- a version of Cloud Foundry which is usually less than a week behind the current release -- with three shifts of 3-10 people each. Two to five pairs, is how we think of it.
PWS has thousands of VMs and tens of thousands of applications running. Pre-CF, pre-BOSH, an installation of this magnitude would need hundreds of sysadmins to stop it from immediately bursting into pretty but expensive flames.
But in general, you're right. The contract with engineers is "tell me what you want and I'll give it to you". Cloud Foundry does that well.
Here are things that should be standard (IMHO) and you shouldn't reinvent
1. Underlying infrastructure auto scaling (Google, AWS) 2. Service Discovery 3. DNS (internal and external for multiple sources) 4. Networking
The real issue that I feel no-one really answered is who's this for. If a SRE is the target audience than there's a lot more we're missing as a community.