How Red Hat OpenShift saves your developers time

The feedback loop for a single developer building desktop software can be quite short. If you're using a dynamic language like JavaScript or something that can be compiled just-in-time, the space between coding and testing can be as short as the time it takes to type in a command.

Alan Kay understood the necessity of this tight feedback loop all the way back at Xerox PARC. He created the Smalltalk programming language because he saw the value in a dynamic language and the immediate feedback it provides to developers. Kay believed seeing your changes instantly and taking actions based upon them was an essential part of graphical user interface (GUI) development.

The widening gap

Anyone who's written a GUI application can tell you that aligning buttons, windows, and images requires fiddling with percentages, pixels, and primitives. "This button needs to move five pixels to the right. No, maybe it’d be better at four pixels. Wait, five was better. I wonder what six looks like?"

Now, imagine that each time you move that button one pixel to the left, you have to wait for an hour to see if it looks better. This was the state of affairs in the 80s and 90s for some application developers. These feedback loops got so strung out that developers would do insane things, like cross-compile assembly language for the MOS 6510 on a Motorola 68000 machine, simply because the C64 was less powerful than the Sun Workstation, but the C64 had millions of end users.

Enter the Web (2.0)

Until the Web 2.0 revolution, most enterprise developers didn't use dynamic languages. It was all Java and C++ and .NET and COBOL. Those environments normalized the "compiler break," where developers would send their code to compile and head to get coffee or to take a walk around the corporate campus.

After AJAX and the Web 2.0 revolution became fashionable, the Web emerged as a viable platform for application development. With JavaScript, the dynamic language at the heart of the revolution, developers rediscovered the joys of instantaneous feedback on their code changes.

Thus, for a while, we all lived in Alan Kay's dream world. Indeed, Kay even funded the launching of DynamicLand during this time—a research project based on the idea of hanging code on pieces of paper on the walls of an office. Cameras aimed at the code would send that information to a server, where that code would run as a basis for the entire environment's interactive displays and projects. A whole room as code, as it were. Until someone walks in front of the camera and the server crashes.

That is, perhaps, a spurious example of the hazards of dynamism. In fact, the drift away from dynamic development hasn't truly occurred because of any shortcomings of the model or the vision. Modern enterprise developers now face a totally different reason for the delays between development and feedback: complexity.

A friend of mine once said that 5 to 10 percent of software development is writing code. Everything that's left is figuring out why it doesn't work. When the software is on a desktop, the possible reasons for failure are generally limited to that desktop.

The Web: Enterprise edition

Today, enterprise software developers aren't building applications for desktop computers. They are building cloud-based services that are talking to other cloud-based services, which are talking to still other cloud-based services, which are talking to even more cloud-based services. Even the once simple act of logging into a server can now require interacting with myriad third-party cloud vendors and services. 

The idea is that all of these individual component services can now innovate on their own timeline, with their own agenda. Service-oriented architecture best practices dictate that each discrete service should be compartmentalized as much as possible to provide maximum value to the business through modularity. Unleashed from the monolith, we're told, services can innovate at scale, across the business, instead of at pace inside a singular project.

But with so many layers of complexity in the development stack, that 90% of time developers spend tracking down errors and fixing problems can balloon exponentially until innovation is not even on the schedule anymore. Instead, they spend all of their time putting out fires, reading documentation, and chasing bugs.

How Red Hat OpenShift can help

While we may never get back to that instantaneous feedback loop of the Xerox Alto and Smalltalk, there is hope for the enterprise developer. And as you would expect, it involves abstractions. But not abstractions in the sense of learning a new programming language. Very much the opposite, in fact.

Enterprises can increase innovation while decreasing time-to-market by building their own application platforms. Even better, they need to build one unified platform for all of their applications. The basics for that platform have existed for some time as Kubernetes and Linux container-based cloud architectures. The open source Kubernetes community has solidified the foundations of such a platform inside hundreds of subprojects.

Tied together into a cohesive application platform like Red Hat OpenShift, these diverse open source projects enable an enterprise to build a services-based, on-demand cloud experience for their developers that abstracts away fiddly details involved with cloud providers, hardware setup, and even systems provisioning.

The key is to focus such a platform on developer enablement and shortening the code-compile-test feedback loop. In the modern cloud environment, that means providing tooling and observability throughout the services and systems that make up an enterprisel’s digital estate.

How an application platform helps developers

Modern problems, such as differences between development and production environments, can be automated out of the picture with a cohesively designed and deployed application platform. Kubernetes and Kubernetes Operators enable developers to deploy their own systems on-demand and in ways that can prevent them from accidentally opening unintentional security holes.

That also means entire environments can be provisioned on-demand from immutable architectural automation sourced from Git. And as the one place where developers send most of their work, Git is often a reliable source of truth. Unifying on GitOps can give your developers and administrators a unified deployment pipeline—one place to be sure that all software deployed to production has passed checks, tests, validation, and certification.

And even better, your developers only need to worry about building their containers. They no longer need to meet with administrators to agree on packaging standards, deployment artifacts, and supported languages. With container-based deployment, your developers can even use older versions of languages or just older languages. 

Imagine packaging up a COBOL application as a container and sending it through the same software build, test, and deploy pipeline as your mainline Java applications. Now imagine accessing that COBOL application as a RESTful API hosted in a compliant, more secure, modern computing environment that can scale that application up and down on demand.

Now, imagine that building any and all of these applications takes only as long as your GitOps pipeline requires. That pipeline is a cloud-based, scalable operation that can provide burst compute as needed, thanks to the underpinnings provided by OpenShift. Your teams can focus on developer enablement within the pipeline and optimizing that single pipeline. 

Wrap up

All of this translates to time saved for your developers at every step of the process:

• Faster build times.
• Eliminating the need to open a ticket just to provision a database for a test.
• Faster debugging thanks to better observability.
• Native benefits of keeping developers in the language and environments of their own choosing.

Red Hat OpenShift provides an application platform for your developers to accelerate their cloud-based innovation. Unleash their creativity by removing the barriers and giving them back the time they need to deliver more innovative applications more quickly.