If you ask three people what they think DevOps is, you’ll get three answers: “a way of running an IT department”, “a culture”, “something to do with Phoenix”. Ask a fourth person and you might hear “You can use OpenShift for that”.
To see what DevOps has to do with the world’s favourite PaaS, I went along to the “OpenShift By Red Hat: The PaaS for DevOps” technical deep dive in Brisbane that was given as part of a road show in Australia and New Zealand in July and August 2014.
The session was held at Brisbane’s Treasury Hotel, an early 19th century building with an Edwardian-Baroque exterior and the type of pre-air conditioning climate control features that play havoc on wireless signals (thick walls). There were about 50 people there, with an approximate average age somewhere between late 30s and 40s. About 8 in the crowd were Red Hatters in support our very own Katie Miller, who literally wrote the book on OpenShift. Of those 50ish people, five were in DevOps environments and an additional five were experienced with PaaS.
Using DevOps as a “filter for accessing usefulness of PaaS” was Change Architect Stefano Picozzi, the main presenter of the session. From the beginning, he made it clear he wouldn’t make the case for DevOps, that it would be a given. He also described OpenShift in a way I hadn’t heard before, as the “voice of the customer, telling Red Hat what to do”. The OpenShift Online offering makes that uniquely true for OpenShift, as feedback from the mass market version quickly makes its way into the Enterprise version running behind corporate firewalls. Stefano also suggested what the technologist inside of all of us hopes is true; that access the right tech and tools can encourage good decisions, practice, and process.
For those who haven’t been following the ongoing DevOps revolution, or had The Phoenix Project thrown at them, DevOps is a way of resolving the classic tension between developers and system administrators: fast versus predictable. The extent to which a PaaS supports a DevOps team can be measured by the extent to which it increases the velocity of software releases, improves the quality of each release, and reduces waste. As the DevOps army are quick to point out, DevOps is about culture: the DevOps PaaS should also support teaming, regular feedback, and experimentation.
Stefano introduced the work of B.F. Skinner to address OpenShift’s potential cultural impact, in particular the idea that behavior is a result of the feedback loop between antecedent and consequence. To an operator the consequence of deploying software as an OpenShift gear is consistency in managing gears, which is the same regardless regardless of what the gear contains. The consequence of OpenShift on developers is a (potentially) self service development environment that lets you choose the way you work, with IDE integrations, a CLI, a web interface, and stable REST APIs. Developing on OpenShift means six steps to get from app to done: idea, budget, code, test, launch, scale (and the OpenShift handles the scaling part for you by including HA Proxy and integrating with existing load balancers).
Katie Miller then showed the audience how easy it is to get an app running, using one command to set up DNS, a Git repository, ssh access to the Gear set up, and a local clone of the gear’s Git repository. If you’ve seen it before, you might have forgotten how impressive it is to watch that happen, or to see how easy it is to relate to what’s inside the gear. Same goes for watching the app scale in real time.
Stefano followed Katie’s demo Insulter app (insults you in Shakespearean fashion) with some real life examples. Cisco has seen benefits from using OpenShift as their environment for developing lightweight mobile apps, like the ability to use existing yum update infrastructure, to use OpenShift REST APIs to integrate with their existing development infrastructure, and the density of apps they can deploy on a small number of nodes (242 to date). Stefano mentioned one company where the TCO for PaaS versus more traditional deployment scenarios became cheaper when they reached 6 apps.
Project Atomic and Docker showed up toward the end of the session when talking about the future of OpenShift, in the context of pushing more functionality out of OpenShift itself into the operating system so that the OpenShift developers can focus on delivering value at the top of the stack in the form of a better user (developer / operator) experience. Coming soon is the ability to consume more of Red Hat’s middleware projects (BRMS, etc), niche 3rd party capabilities (SAP, Hortonworks, and .NET support thanks to a company called Uhuru (the Swahili word for freedom, also the name of a pan-African movement).
If innovation is creativity at commercial scale, and DevOps is a path to business agility, then OpenShift is especially compelling if it can help address the behavioral anti-patterns that impede DevOps. Stefano and Katie made a compelling case for “OpenShift By Red Hat: The PaaS for DevOps” that seemed to resonate well with the audience in Brisbane, and got me excited about the possibilities OpenShift could open up.