Red Hat OpenShift.io – Free, end-to-end, cloud-native development

Hi @toddmorey - I am founder / CEO of Codenvy. Eclipse Che is our open source kernel and we had the opportunity to collaborate intimately with Red Hat's engineering teams in the design and development of OpenShift.io.

Let me share some of the perspective that we have on what they are building.

What happens if your app dev lifecycle tools (git, issue management, IDE, CI / pipeline) runs on the same platform that is running your production applications?

From a market point of view, openshift.io is an approach to developing containerized applications in a way where the development team does not need to setup the infrastructure and tools required to create those workloads.

Red Hat has:

1. Created their own agile issue management offering, competitive to Jira, GitHub issues, or Gitlab issues, based around the concept of a "work item".

2. A context-aware browser IDE based upon Eclipse Che, which "dev modes" a workspace based upon the containerized version of the application you are building. This injects things devs need for writing code including SSH, language intelligence like auto complete, debuggers. The workspaces are configured for the developer in-context based upon the work item that is under taken (ie, which branch, which repository, which languages, which files are referenced).

3. A continuous integration pipeline designed around building, testing, and deploying containerized servies built for the project using pipelines tailored for the team and for the individual. The pipeline capability is built from within, but takes advantage of a containerized Jenkins under the cover.

4. Deployment of the application to OpenShift. The application is packaged as a set of containers, which (OpenShift) is powering all the underlying services (Che workspaces, work items, pipelines, etc). The deployment automates complexity about how to set up a deployment profile, automatically adds canary deployment mechanisms (deploy for only the developer, for the team, or for production users (portion of users, etc)). Why not use canary deployment for managing the builds of commits for individual engineers along with your end users?

5. Analytics built in for doing intelligence of the code base that is being built to do analysis of the open source libraries included in the project you are creating to identify if any of those libraries are potential security issues, as identified through community flagging or a white / black list provided by an enterprise.

6. By building all of this on a common underlying infrastructure, there is additional context associations that are understood, so pipelines are connected to work items and the workspace, and vice versa. This alleviates certain overhead and setup requirements of developers long term.

I am excited personally about this product because it solves the biggest pain that Codenvy sees with our paying customers. We have a number of F500 customers who pay and deploy a private Codenvy.

But they are all becoming DevOps infrastructure wizards. It's hard for them having to figure out how to wire together Jenkins, Gitlab, Kubernetes, their IDE. They can do it, but they are seeking a DevOps in a box solution that makes that sort of setup effortless for the dev team, self-service (so that the DevOps team doesn't have to spend weeks getting it configured), and production grade (lets dev teams build enterprise applications that will be packaged as container workloads).

So openshift.io is what happens when an organization tries to remove the effort out of DevOps, and they ultimately make optimizations and workflows based upon that point of view.

I am also project leader for Eclipse Che, and we are making a commitment to migrating the management of our open source project (4K github stars and >100 contributors now from a diverse set of companies) onto openshift.io. It will be really interesting.

> What makes it a PaaS is that it integrates Jenkins

Not just Jenkins. There is a Jenkins button and you can use Jenkins for CI/CD, but you can define BuildConfig and ImageStream through their point-and-click interface without ever adding Jenkins or writing a line of config by hand.

You just need to use one of their built-in ImageStreams and DeploymentConfigs. I got my first exposure to OpenShift through the Developer Preview/OpenShift Console beta. At the time I was testing it out, deployment of Jenkins was outright broken, but I was able to get my app working and builds automatically generated in response to GitHub webhooks (eg, CD without Jenkins.)

The Developer Preview was a very interesting experience, and their support people were quite responsive in #openshift-dev, but I'm giving them some latitude in that it was clearly labeled as Preview / Beta and a totally free product with built-in expiration date.

I would not have been likely to call it a good experience except that it was clearly labeled beta. But if it says Beta on the tin, and I am able to complain until it works, that's about where I set the bar for good experience. It was a good beta experience.

If I had to guess, OpenShift.io is the next phase of this:

https://console.preview.openshift.com/console/

(I am certain that you will not need to use OpenShift.io online IDE to get "batteries included" OpenShift from RedHat.)

BUT DOES IT SCALE ON THE CLOUD

There is more chance of the pope converting to Islam, then MS acquiring Red Hat. That is one acquisition that would turn to shit over night, and MS would be left with just some logos, as the companies main assets (its engineering) would all walk out the door, followed by customers not renewing subscriptions.

I wish I could join in, but this stuff is par for the course. Every time I raise A Platform I Am Notorious For Mentioning, it is pointed out to me that the website is kinda indirect and that my employers' website has a similar degree of obliquity.

I expect Red Hat engineers will be here to help us parse it.

Disclosure: I work for Pivotal, we compete, etc etc