The OpenShift.io collaborative coding environment and new runtimes for common application types help Red Hat build dev appeal for its PaaS
With OpenShift, Red Hat wants to make its PaaS as friendly to developers as to the rest of an enterprise team.
Hence, Red Hat is adding a pair of developer-focused features to OpenShift: a new cloud-native, browser-based development environment for building automatically containerized code and a set of runtimes for building microservices in OpenShift in a mix of common languages.
The revolution will be developerized
For starters, the new OpenShift.io dev environment lets teams work together on code that’s containerized automatically and deployed continuously. It’s built with open source components, chiefly the Eclipse Che cloud-based IDE and in-browser code editor.
Che was designed to be a workspace server for teams to work on code by popping open a browser and spinning up workspace runtimes in a container. The project recently gained a pair of features that could prove useful in OpenShift.io. One is support for Microsoft’s Language Server Protocol, so an IDE can obtain contextually relevant information about code from a language’s runtime. The other is built-in support for Docker Compose Workspaces, allowing projects to be deployed straight to containers.
Che has been used previously for similar projects. Microsoft and Codenvy, for instance, partnered to create an extension to the Microsoft VSTS (Visual Studio Team Services) cloud IDE that uses Che as the front end for cloud workspaces to work with VSTS projects.
Many of the touted features in Openshift.io seem like direct riffs on the same ideas: development environments on demand, continuous deployment of software as containerized microservices, and so on. They lower the bar for developing and deploying code to OpenShift; this also includes making it easier to bring developers onto a team by requiring nothing more of them than a web browser. This is normally left to whoever provisions developer resources (read: ops), not the developer toolsets themselves.
Plug and run
The other big part of the announcement, the Red Hat OpenShift Application Runtimes, helps developers create microservices that can be deployed in multiple languages.
Right now, most of the planned runtimes are less about different languages than different frameworks in certain languages. WildFly Swarm, Eclipse Vert.x, and Spring Boot, all found in the runtime collection, are Java or Java-centric. But the runtime list also includes Node.js, widely used to create lightweight, simple, responsive services—the polar opposite of the work done with enterprise Java stacks.
Red Hat says the point of including the runtimes isn’t only to have ready-to-use access to those frameworks within OpenShift. It’s also about developing consistently with those frameworks regardless of whether it’s a local OpenShift deployment or one of the cloud versions (OpenShift Online, OpenShift Dedicated).
Ever since OpenShift followed the wind and became a container-focused system, almost all of its biggest changes have been aimed at developers, much as containers themselves have been. But Red Hat’s focus on developers in OpenShift is ostensibly as much about having OpenShift become a new rampart within the enterprise, as Matt Asay has argued.
Red Hat Enterprise Linux provided the company with a solid on-premises presence in the enterprise, but it’s through OpenShift that Red Hat is attempting to build a presence in what’s next: Enterprise apps that run natively in the cloud on containers. The more that can come on board that train—as painlessly as possible—the better for Red Hat.
