Hacker News Reader

Comment by jacques_chester | Hacker News Reader

I think Red Hat's problem with OpenShift is getting out from under the brand-masking power of tech they chose. Too many engineers want to roll their own Docker+Kubernetes platform and underestimate the difficulty of doing so.

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.

View on HN

Maybe (hopefully!) things have improved since I last looked at it, but OpenStack is (was?) a complicated, unorganized, over-engineered conglomeration of independent parts.

I sincerely hope that's not the case anymore but that lasting first impression has stopped me from looking into it since then.

OpenStack (IaaS) != OpenShift (PaaS)

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...

At GitLab we use OpenShift Origin (self-hosted) for our idea to production demo https://about.gitlab.com/handbook/sales/idea-to-production-d... It has been a great experience. Easy to set up and rock solid.

Ahhh, yeah, I totally misread that. Sorry!

It sounds like you're building from the IaaS layer up, is that correct?

It depends on what the customer has already. We (Red Hat) support installing OpenShift anywhere that RHEL x86-64 is supported, whether that is bare metal, vms, private/public cloud, etc. For example, our hosted "Heroku like" OpenShift Online is on AWS (https://www.openshift.com/devpreview/).

Thanks. It makes sense that Red Hat would make that guarantee.

This!

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.

> with PaaS I don't see any need for "operators".

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.

Reply on news.ycombinator.com