Enterprises are moving to the cloud. This is a simple fact. However, the last holdout is development. Even in the most cloud-focused organizations developers still use desktop IDEs and run their pre-commit code on their localhost.
Why are the people who invented the cloud the last people to move to it?
There are two factors at play:
Developers have a set of tools they love using and don’t want to give up. Organizations have complex development processes built on a set of tools and gates that exist (largely) behind the firewall.
Even for organizations that have a private internal cloud, moving developers to cloud-development is seen as a forced replacement of their existing tool-chain. In the past cloud development tools worked only with other cloud development tools.
But today things have changed and cloud development tools like Codenvy can be installed behind the firewall and integrated with existing enterprise tools:
Desktop IDEs and editors — even vi and emacs. Private git or SVN code repos. Private artifact repositories and container registries. CI systems like Jenkins. Issue management systems like JIRA. Corporate directories like LDAP.
This simplifies the path for teams and enterprises to move to collaborative and agile cloud-based developer workspaces.
Why It’s Worth It
In the enterprises we speak to every day, on-boarding is a slow and tedious process lasting anywhere from a couple days to a couple weeks. This is especially problematic because in most organizations the on-boarding tax is paid not only when new developers are hired, but when contractors are engaged or anytime someone needs to change teams or projects.
For the developer going through the on-boarding pain, these delays replace days of coding with days of frustrated inaction. For the team, it results in delivery delays, kills their productivity (especially since it’s often the most senior dev on the team that is tasked with helping) and results in delivery delays.
The Better Way
Contrast this to a cloud developer workspace which can be started in under a minute and use a replica of the production environment (multiple containers, multiple servers, dedicated networking…). This removes the on-boarding pain entirely.
But what’s more exciting is what this does to the team’s approach to development. When moving from project-to-project is instantaneous (and doesn’t require stashing what you’re working on before) people can quickly “pop in” to another team to provide feedback, guidance or an alternative approach.
Wondering if the new API being developed by a team you’re dependent on has been updated to properly fix an issue your team is having? You could send someone an email and wait for a response or, in less time, you could just fire up a development workspace tailored to that project and run the latest commit on head and see for yourself.
Or, a workspace can be programmatically tailored to a specific work item or issue (by having it open or create the correct branch in the repo) to speed jumping into bug fix or enhancement tasks. You can even have a workspace automatically built to match any successful or failed build from your CI system — it’s much easier to diagnose a build issue if the workspace you are brought into has the correct branch and commitID from the broken build and even pre-opens the file(s) that broke the build.Continue reading