Until that question is answered, you have ZERO patience for any marketing you read: especially fluffy visionary commentary about "digital transformation". You are quite literally making your readers angry because you are not answering their questions.
For anyone launching anything:
1. Make the first goal of your homepage just explaining what the thing is. Be clear. Be specific. People just want to know how to reason about it.
2. Show photos, video, or screenshots. (Even if you don't think it's amazingly sexy.) Seeing the product makes it so much more real.
3. Compare it liberally with what's out in the market now: this is your chance to show how it's similar and why it's different. Can be chart or table.
Then and only then, can you move on to how your product improves the lives of devs, chefs, athletes, etc. who uses it. (But you may not even need to.)
- It is a PaaS, which would compete with Docker, EC2, and Heroku.
- It's development environment. Sublime?
- It's a collaboration tool. Github?
More to the point, it probably doesn't do any of those things in particular quite as well as those specific solutions do, but they're hoping you see the value in everything together. Would there be value in an IDE that had a deploy button that automatically marked a task as done?
I'm not sure that's exactly it, and I agree that this site isn't wonderfully done, but it's hard to get across "the thing" when there isn't a perfect comp to "the thing" already out there. Bad comparisons will pigeonhole your product forever.
We see similar value in it, but so far I've seen it explained more via products that play nicely together versus packaging a single platform.
I guess the question to ask is: if I take away this part of the circle, how much worse off am I? The anticipated pain gives some inkling of how important it is to provide it. Take any of Tracker, Cloud Foundry or Concourse away and it all becomes much harder.
Where I personally differ is that I like plain ol' IDEs and text editors. The web-based IDE thing keeps coming up. It may be that it's one of those ideas waiting for its time. Or may be one of those ideas that is a bad idea. I personally think the latter, but my predictions about technology are so frequently wrong that I should write for Wired. (Edit: it's also possible that I don't understand what Eclipse Che is)
Kudos to Red Hat for tying it all together. People forget how many smart PMs, designers and engineers love working there.
Disclosure: I work on Cloud Foundry on behalf of Pivotal. I'm just an engineer, I shouldn't be cited as authority about plans or whathaveyou.
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.
One quick question for them to address is if the entire stack (suite?) will be runnable on your own hardware or if it can only be consumed as a service.
As for your question - initially it will be released as a service. But it's Red Hat, and their customers are primarily on-premises with OpenShift sales, so the demand for on-premises deployment on your own hardware will be through the roof. So we'll see if RHT targets that demand.
You'll literally be able to demo it yourself for free, on demand, in production (IF YOU DARE!), within the next few days.
Furthermore, I would probably have to read the manual, etc before I can do anything useful with it. A good screenshot or even video can really help you with that impression
There is now openshift.com (enterprise), openshift.org (OSS), and openshift.io (???) and none of these websites do a great job of explaining why you should be on that website and not the others.
If you want customers, you have to actually convince them to try your product.
The expectation of a customer that they might want to understand what the heck they're signing up for... before they sign up for it is hardly controversial.
I think this thread makes it abundantly clear that a days work creating some screen casts instead of fluffing out some marketing fairyfloss would have significantly improved the reception of this product.
It's just plain marketing fail.
A missed opportunity, but there is still time to recover.
Digital transformation is about evolving into a technology
business in order to compete in the digital economy.
Businesses can’t transform without relying on the developer
to implement the transformation strategy and deliver value.
I expect Red Hat engineers will be here to help us parse it.
Disclosure: I work for Pivotal, we compete, etc etc
Here are just some of the influences of OpenShift on Kubernetes that I'm aware of:
* RBAC model (https://github.com/kubernetes/features/issues/2#issuecomment...)
* Kubernetes notion of namespaces was largely influenced by RedHat and Open Shift team experiences in the enterprise AFAIK
* Continuous ongoing work by RedHat team on both OpenShift and Kubernetes on the security and performance (https://github.com/kubernetes/kubernetes/issues/12742)
I'm sure there are many more improvements to Kubernetes to OpenShift that I'm not aware of.
- An IDE
- A platform for running containers
- A set of productivity and collaboration tools
- CI service
- Deployment tools
Really? I'm scratching my head over this one.
I really respect the work RedHat do, but there's this idea of picking one thing and doing it well... but heck, I mean, you can also just do everything as well, and hope one bit or another sticks I guess.
? ...but why would you? How can you expect to offer all of that at any kind of acceptable level of quality?
Why would I pick this up? It feels like if you do, you're basically going to play in some walled garden where the rules might change at any time, and you'll be out in the cold when they do.
All of our work is open on github under the OpenShift Origin project, Kubernetes, and other projects. We push most of changes upstream.
Doing containers at a scale of 10,000+ running containers would be unimaginably hard without something like OpenShift. Clusters of 1,000s of nodes, Security, RBAC throughout our supported tools, optional SCM (git via GOGS), optional integrated local Docker Registry, optional CI/CD (Jenkins), optional build/artifact repo (Nexus), optional basic metrics (Hawkular, Heapster, Cassandra), optional monitoring (CloudForms, Cockpit), optional EFK logging stack, (Elasticsearch, FluentD, Kibana), horizontal autoscaling, support for NFS, NetApp, OpenStack, RHEV, KVM, VMware, AWS, GCE, Azure, Ceph, GlusterFS, BIG-IP F5, iSCSI, FibreChannel, dynamic node provisioning, dynamic storage provisioning, OAuth2 authentication and app integration, LDAP authentication, SAML2 authentication, Okta, auto SDN creation, SDN segregation, application load balancing, multiple encryption flow options, HTTP/2 support, internally secured communications, Ansible integration. For a solution so encompassing, you need something that marks the way. Most of our customers exchange several parts for what they have or what they want.
And we do all of this with Quality as we develop in the open & commit to upstream projects. We spend $100Ks (probably more) on R&D and testing every release (every 3-4 months). The benefits, again, are usually committed upstream. You have Red Hat's award winning Customer Support. I'll personally vouch for our OpenShift Customer Support Teams. Absolutely amazingly talented and insightful engineers from all over the globe.
One of our biggest customer concerns is in integrating customers' code to run on the Platform, aka, the Last Mile of Integration. IMO, OpenShift.io is intended to reduce that barrier. We support just about all the popular languages, frameworks, and platforms. We have examples & templates for Perl, PHP, Python, Ruby, nodejs, Java (Spring Boot, JBoss, xPaaS, FUSE), and even .Net Core, MySQL, PostgreSQL, MongoDB, CouchDB. Figuring out how to integrate legacy CI/CD, monitoring, logging, IDEs, etc. with OpenShift takes the most time. In choosing OpenShift.io, in return, you get an environment that is built from the get-go to work together.
Openshift.IO makes all them work as a SaaS for production use.
I believe OpenShift has a buildpack-like onramp now, I am not qualified to name it or describe it.
Deis takes the Heroku buildpacks from upstream and so is more-or-less plug compatible with Heroku. Cloud Foundry does something similar, though with extra wrapping to allow it to work smoothly in disconnected environments. Some of those buildpacks are being rewritten, but I expect they'd be compatible with Deis too.
Disclosure: I work on Cloud Foundry for Pivotal. I've been on CF Buildpacks twice.
From a naïve user experience perspective, OpenShift is probably a bit more like Heroku. Workflow does not (yet) have service brokers or add-ons that provide sidecars like a MySQL database or a Redis server. OpenShift provides those things in a manner more similar to Heroku's add-ons.
OpenShift also provides users with a point-and-click interface, but Deis Workflow expects you to use a command-line interface or bring your own dashboard (deisdash is a thing).
Deis Workflow depends on Kubernetes, and OpenShift =~(subsumes/supplants) Kubernetes in a marginally incompatible way, but to my knowledge Heroku has no relationship at all with Kubernetes. At least if it does, it's very opaque about it. (I couldn't tell you either way because it is opaque.)
Edit: Thanks. Feels like better wording on the page would have helped. "Online IDE" or something. Or rolling screenshots that show what it does, like Cloud9 has.
Or maybe I'm too old to grok all this new cloud terminology.
Developer Workspace Management
Application Coding and Testing
Runtime Stack Analysis
Continuous Integration and Delivery
All of it running on and targeting OpenShift.
Hope that helps.
That'll help attract talent.
It's seriously a question; and if the answer is yes, then the following statement applies (the one about attracting talent).
But yes, it came off pretty cynical and sarcastic, but if someone is going to try to force me to use a particular IDE, it would piss me off (and the thought of it did too).
Not at all pleasant :(
Is this a special case for Google mail or do you assume email@example.com is the same as firstname.lastname@example.org ? Why?
"You may not (or permit third parties to) create multiple accounts or otherwise access the Services in a manner that is intended to avoid Fees or to circumvent maximum capacity thresholds for the Services."
I think it is OK to make a special case for Gmail and Google mail but it is counterproductive to try to crown it as a de facto standard.
The + sign is not anything to do with Google.
I just assumed + is a valid character and email@example.com would be a valid email address independent of a or b. But it seems we shouldn't allow + or -- when people sign up for a new email address?
Openshift.io is the end-to-end development environment which is built over the OpenShift PaaS.
OpenShift is a Platform-as-a-Service offering from RedHat.
It provides a fully integrated solution to building and deploying applications on Docker and Kubernetes. What makes it a PaaS is that it integrates Jenkins, so you can build images from source and promote them though environments.
OpenShift is a private cloud offering, so it is something you install and run yourself on your own infrastructure or in a public cloud.
So OpenShift.io is the "battery-included" version that is already installed on a public cloud, managed by RedHat?
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:
(I am certain that you will not need to use OpenShift.io online IDE to get "batteries included" OpenShift from RedHat.)
This is openshift + planner + code editor + pipelines + 'analytics'.
Here analytics does code quality checks and lets you, the developer know, if they should be using a different Jar/package ( example: the one used by the developer might have a security vulnerability reported which the developer was unaware of )
It will answer a lot of questions :)
Service Unavailable - Zero size object
The server is temporarily unable to service your request. Please try again later.
Internal Server Error - Read
The server encountered an internal error or misconfiguration and was unable to complete your request.
Based on everyone’s feedback, we redid the homepage last night. We hope this does a better job explaining the benefits and why you would want to try OpenShift.io. Please give it a look and let us know how we did.
I know there are a lot of people who want to give OSIO a try. We will be onboarding customers as soon as we can. We are putting in the finishing touches and ramping our capacity to meet the demand. We will be keeping everyone updated on our progress through email, twitter (@rhdevelopers) and our developer blog - https://developers.redhat.com/blog
In the meantime, replacing characters in your name like "Ł" with "L" will fix the issue. You can update your name and account settings here: https://developers.redhat.com/auth/realms/rhd/account/
What is it?
C'mon, RedHat. Throw me a bone here.
Show HN: Tux.io – a (now working) Linux desktop in your browser | https://news.ycombinator.com/item?id=14245447
My first instinct trying OpenShift v3 Developer Preview was to slap helm on it and see if I could deploy my Kubernetes projects. Turns out that Helm does not have much of a security model to speak of, and this was problematic to enabling support for Helm in OpenShift v3 where multi-tenancy was one of the concerns they wanted to address right away.
I got with claytonc in the #openshift-dev channel on freenode and he explained all of this to me, the long story short is that Helm on OpenShift is not well supported but that you can use it if you are willing to give it a service account with editor access to the whole cluster and make some other small changes like setting TILLER_NAMESPACE to something other than kube-system.
Instead, OpenShift basically uses the Kubernetes model with some additional primitives for deployments and builds. You define a BuildConfig (or let the point-and-click interface do it for you). Builds produce images, and images go into an ImageStream. A DeploymentConfig maps deployments to ImageStreams. 
The rest of the way down the stack, your deployment looks very similar to a regular Kubernetes deployment (except it's not using the Kubernetes deployment primitive, I believe that OpenShift implemented their own formal concept of Rolling Updates on DeploymentConfig before Kubernetes released the modern Deployment/ReplicaSet primitives that many k8s users are using for this now.) It is almost Kubernetes under the hood (but not quite, in subtly incompatible ways that depending on your size and current level of investment into Kubernetes, you might have an easy time or a hard time getting over.)
If you're looking for a short list of things that have changed from OpenShift v2 to v3, there isn't one because they are not really directly related products other than by name.
Ever since it dumped the desktop years ago, I switched to the deb ecosystem and never looked back, do not want to have anything to do with Redhat,including this openshift thing, one reason is for the "dump-the-desktop"(please don't mention Fedora), another is that, DEB is so much better than RPM for my daily life.
I also hate the Redhat-intrusively-forced-on-SystemD to my heart.
That been said, I appreciate what Redhat have been doing to the open source, I guess it is win-win for the community and its own business goals.
The second a Microsoft (or worse, an Oracle) tried to acquire Red Hat, a huge portion of that talent would walk out the door.
Oracle is notorious for buying companies for their clients, even if everyone quits (eg, hostile takeover of Sieble)