Disclaimer: no frogs were hurt in the making of this blog post.

TL;DR

Developer onboarding and development activities are slowed down and complicated by the defacto approach of a user centric IDE: One laptop (or VDI), one IDE. Change that paradigm to a project centric IDE, and you solve so many problems, break project silos, increase security, standardise the environment and more. Solutions like OpenShift Dev Spaces let you do that. Just do it.

Introduction

We developers have evolved our practices over the last decades, to use more and more advanced IDEs on our laptops. For my generation emacs was a great option, still used today, but probably not by younger generations who will find the likes of Eclipse, VSCode, or Intellij more appealing. We also evolved in the number of languages, frameworks, libraries, and backend services we need to understand, use, and master. In the past, being good in one language, say C, C++, or Java was plenty to get any job. Nowadays, the list of technical "must have" and "good to have" requirements in any job advert is insane. This has led to the rise of the full stack developer, the jack of all trades master of none. This got even more complicated with the emergence of the microservices architecture pattern, where microservices are sometimes written in different languages, often in different language versions, using different libraries, also in different versions, relying on different backend services, also in... -you guessed it- different versions. Maintaining a development environment on one's laptop, to cater for this diversity has become a monumental waste of time that unnecessarily adds to the mental load of developers, in-turn reducing creative bandwidth for higher-order executive problem solving. Do you like fixing dependencies and resolving conflicts? No-one does.

I believe, we, the developers have been the victims of the so called boiling frog syndrome: A frog dropped inside a pot full of safe cold water, which temperature has been increased year after year, without the frog sensing the danger of the water temperature raising to boiling level, until that poor amphibian gets cooked to death.

It's time to get out of this cooking pot before it's too late, and fix that once and for all.

Containers to the rescue?

Containerized technology enjoyed a massive growth over the last decade. By encapsulating all the requirements of a given application (think OS, libraries, runtime environment, code), containers ensure safe isolation and portability of that application. Unlike Virtual Machine, containers are a few orders of magnitude faster to start, lighter to store, easier to transport, and agile to work with. It is the supporting technology that has enabled the rise of microservices. Containers are now so ubiquitous, they are the defacto solution for new projects, or the solutions of choice for legacy projects in need of modernisation.

This begs the question: If containers are so ubiquitous, if containerized systems brings so many benefits, why don't we, the developers use a containerized IDE in the first place?

OpenShift solution

There are several solutions that tackle this problem by leveraging the agility of containers. OpenShift Dev Spaces is one of them. It uses two upstream open source projects:

Devfile is an open standard that let you codify your Developement Environment. Red Hat, IBM, AWS, JetBrains and Gitlab are contributing this CNCF project.
Eclipse che provides your IDE in Kubernetes, leveraging Devfiles.

Together this solution provides major benefits as explained below.

Standardized IDE as code

The same way containers are codified via Dockerfiles, Dev Spaces are codified via devfile.yaml. This file typically sits inside your project git repo, but can also be hosted in a devfile registry provided by OpenShift Dev Spaces. This file is typically customized for each project language and requirements, and lets you, among other things:

Define some components (think sidecar containers) providing you with the services (think Databases, Message Brokers, CLI tools etc...) required for development purposes.
Define your library of useful commands: Those helper commands that developers constantly rely for their work (compile command lines, debugs, test, cleanup and load db etc...)

You can also tailor the base image used to deliver the workspace (in OpenShift, that's the Red Hat Universal Developer Image, the upstream project can be found here)

With a codified IDE, you have a standardised development platform across all the devs of a given project. All developers can contribute to this devfile, adding, and hence, sharing their best practice.

One project, one IDE, instant onboarding

This is probably the most important benefit. Most (all?) developers struggle to maintain their IDE on their laptop, when juggling across projects, languages, libraries all in different versions. The amount of time and frustration spent on framework conflicts, setting up a build toolchain for a new project, and maintaining that, fixing dependencies, fighting version conflicts, adding that Database or that message broker to it in the right version for that project... That's enough.

For the Python language, this issue has been captured a while back by this xkcd comic

What's crazy? Nowadays, each git project has typically a lengthy, out-of-date README to help setup the environment. This README is the hint that a developer environment should be project specific. It then makes perfect sense to containerise such a developer environment, for each project, right?

Breaking silos

Forgive me for using a buzz word, but it's just true, our current approach leads to silos. One reason teams and projects are siloed is the difficulty to get started on another teams project. Just to be in a position to make some small changes or sort bug fixes or to learn from that other project you face a cost of admission to that developer environment which is motivationally prohibitive. Being able to start a configured and ready to use IDE for any project, at the click of a button (last buzzword today I promiss) is an invitation to explore and collaborate on anyone's project. Break that silo, now!

Security

It may sound obvious, but not having to checkout the git project on personal laptop just add another layer of security. The code now lives only on the git repository, and on the Dev Spaces workspace on that OpenShift cluster. So much easier and safer.

Cost savings

There is a huge cost saving opportunity, it depends on your organizations situation. First of all, for OpenShift customers, OpenShift Dev Spaces is included in your subscription. You can get started immediatly.

Efficiency is time, time is money, teams that effectively adopt Dev Spaces (or other similar solutions, do your research) will save money:

onboarding is much faster
developers will jump more easily from project to project
developers laptop can be lighter (in price, but also, in kg)
developer environment maintenance is now centralized via the devfile. Only one team lead needs to maintain it for everyone, yet every team member can contribute and improve it! Hello colaborative Development Environment.
Kubernetes will make CPU usage more elastic, providing more resources when developers need it (compile, build and test time), yet use little resources when iddle.

For none OpenShift users, well, Devfile and eclipse Che are open source, you could leverage them, build a solution around them, and maintain them as needed.

Limitations

In all honestly, the only limitations I could find are:

native apps, such as the postman app, can't be containerized to run on OpenShift. Only CLI tools, or web based applications can run as side care containers. That covers the majority of devtools in my opinion, as for that postman example, it has had a web based offering for a while. Postman alternatives can be used as VSCode extensions too. Obviously, Postman may still run on a Developer's laptop.
VSCode extensions that can be run are available on the open vsx site. It covers most of VSCode extensions, yet a few are missing. On a related note, it's possible to create a private registry (think disconnected environment) when needed. Dev Spaces can run disconnected.
OpenShift Dev Spaces offers the choice of VSCode and Intellij, with the later in tech preview as of now.

Next step

For OpenShift customers, you will need to install the Dev Spaces operator, and instanciate a Che cluster resource. That's enough to get started. For none OpenShift customers, you can try Dev Spaces via the Red Hat OpenShift Developer Sandbox

Conclusion

In this current decade, we are at the intersection of two things:

developers are in urgent need of better working paradigm
the technology has now matured to support this paradigm

It's time to change habits, take a leap frog, and embrace a new and modern way to deliver IDEs. It's time to let go of the era of the beeffy laptop, and instead harvest the power and convenience of kubernetes platforms such as OpenShift.

Change is hard, change takes time, but ultimatly, once change happens and we look back at the old way of doing things, we always smile and think "how did we do that in the past??"... How did we do music before audio streaming platforms? Ah yes, we had those vinyl records, clunky cassette tapes, then later CDs to carry around with us, life is so convenient these days with streaming platforms. How did we do software before the likes of office 365, google doc etc... Ah yes, we had to copy that floppy disk, burn that DVD, install that software, and upgrade regularly. Life is so convenient these days, but only through adaptation and adoption. Here adoption is the key, the solution is ready, it's time for you to make the shift to DevSpaces on OpenShift. Now.