Solving the Two Week Problem by Developing in the Cloud

A developer walks into an enterprise software shop. Two weeks later, she's ready to start working.

This joke is tragically true. It has become the obligatory first stage in developing software. During this time developers are not programming, they are configuring. Hours are spent overcoming platform differences and scratching heads, rooting out why this or that build process fails for the new developer, but not everyone else.

Then an unfortunate reality sets in. As every seasoned developer already knows, configuration management and dependency hell continue long after the first two weeks.

To overcome these issues and make more responsible decisions for our dev teams, we first need to reality check the status quo of developer tooling. Then, we can look with fresh eyes at how Cloud9 IDE and OpenShift have created a novel solution to the “two week” problem.

Watch this quick demo on how to develop a consistent development environment using Cloud9 IDE and OpenShift.

Roots

When powerful-enough desktops appeared back in the 1980s, it was a boon for programmers who had been parceling their time on centralized mainframes. The desktop market exploded and over the last 3 decades the freedom to customize our personal hardware and software stacks has grown.

But it’s exactly this independent, desktop model of development that is giving developers their biggest headaches. The tooling you use and the software you build are at the mercy of the stacks they run on. All those differences in dependencies and system configurations that cause a build to break ? these are our agents of distraction.

From Chaos to Consistency

The solution is to bring consistency to your development platform. But how can we do this if we have wildly different stacks on each developer’s computer? The isolated model of desktop development doesn’t work, because the code is always competing with the system.

At Cloud9 IDE, we thought about this problem for a long time. And then we thought, What happens when you separate the interface from the IDE? With the interface gone you are left with everything else: the code and the processes you run against the code (building, compiling, etc). That “everything else” is what demands consistency. So what we needed was a durable platform we could put “everything else” on, and deliver the interface as a separate component.

This is what we have achieved with c9.io. Your code and processes are run securely in the cloud ? on a powerful, Enterprise Linux back-end. Separately, we serve the interface over the web to your browser.

Think about this again: your team never has to worry about configuring their local desktops, because that’s not where the code exists. In fact, every developer on the team can use any modern OS (Linux, Mac, Windows or even ChromeOS) from anywhere in the world. They simply log in to c9.io on FireFox, Safari or Chrome, and their projects are right where they left off.

OpenShift Cloud 9 IDE screen shot image

The browser is only the interface. The real power comes from the back-end, where the code is hosted, built and run.

OpenShift: Powering Cloud9 Workspaces

How is Cloud9 IDE able to claim such consistency on the back-end? To answer that, we first look at OpenShift, the platform as a service (PaaS) offering from Red Hat.

When developers think PaaS, they usually consider it the endgame of the software development process. This is where the completed application is hosted, where it becomes accessible to the world. In a normal PaaS scenario your application is run in a container with a set of resources to power that application: hard drive space, memory capacity, and software like Node.JS or the Java Virtual Machine.

Cloud9 IDE takes those same containers, and repurposes them to store your code and the processes being run against the code. For every project you start on Cloud9, there is an Enterprise Linux container powering it.

For this reason we call a project on Cloud9 a “workspace.” A workspace is more than your code, it is also the underlying infrastructure that powers your code. It means that every developer on Cloud9 gets the same, consistent foundation provided by OpenShift.

Consistency in Development, Consistency in Deployment

With every workspace on Cloud9 powered by OpenShift, developers open themselves up to an incredible opportunity: deploy their applications directly from OpenShift to OpenShift. That is, you can use your Cloud9 workspace to develop on, and when it’s ready to go live, push your code to a production OpenShift container for hosting.

At first glance this seems redundant. Why duplicate your application from one container to another? There are two good reasons:

  1. To keep your production and development code separate
  2. The production container may need to scale

The first point won’t be lost on anyone who develops applications for a living; modifying live code is a recipe for disaster. To the second point, OpenShift allows you to allocate resources for your application so it scales to customer demand. Check out their documentation.

Consider the gains in stability and efficiency when your development environment is the same as your hosting environment. When you hit “run” to test your application, you can be considerably more confident that a successful pass of the integration server is a green light to update the production server.

? Check out OpenShift’s article on adding a container URL to your git remotes.

 

The Future: Customizing Containers with Cartridges

If your application requires popular software that isn’t available in your container by default, OpenShift offers cartridges. These are installable pieces of software you can plug in to your OpenShift container.

For example, you can install a MongoDB cartridge or a PHPMyAdmin cartridge. OpenShift is actively expanding the list of available cartridges, and offers documentation on how you can create your own.

In the future Cloud9 will offer the option to install and manage these cartridges directly from the IDE. We are focused on making the management of your software stack as simple as possible.

Final Thoughts

We didn’t create a cloud-based IDE because it was novel. We did it because the consistency of the development experience is orders of magnitude better than current options.

It’s only getting better from here. With our enterprise-class foundation in OpenShift, the Cloud9 platform is setting the stage for the future of development. Start your next application today at c9.io.

 

Any plans to support OpenShift as a Deployment Target in C9? At the moment, there is only Heroku and Windows Azure. Heroku didn't work for me (yet) because of lack of proper socket.io support. OpenShift looks like a good alternative. However, more (technical) details on the integration of C9 and OpenShift would be welcome (for example, how to connect a C9 repository to a OpenShift app). Thanks.

Right now you can add OpenShift as a git remote, so you can push directly to another container. This article describes the process:

https://www.openshift.com/blogs/look-ma-no-hands-developing-for-the-cloud-in-the-cloud-with-cloud9-ide

(as a side note, the problem users noted in the comments section has since been resolved)

More from this author