Developers spend an inordinate amount of time configuring their workbench in a typical day. This is because it is composed on an IDE and often dozens of other tools that are part of the tool chain used to plan, design, construct, test, and debug the code they are writing.
"The way most organizations handle this today is a Wiki hell," said Tyler Jewell, CEO of Codenvy, a cloud IDE provider. Developers in a typical projects are often told to go to a wiki page with 30-100 instructions they have to follow on their own. When these are followed to perfection, the developer environment will compile and run. But this is kind of ridiculous in light of the trend towards DevOps principles that advocate the seamless development of code and treating the configuration as code in and of itself.
Cloud based IDEs help to automate these configurations so the project can be set up and run the right way. This gives developers a self contained environment where the developers can get started without installing any prerequisite software on their machines. A good practice is to save the configuration for a project in the cloud. This lets developers move between machines more easily. It also streamlines the process of bringing new developers into a particular project. "By removing the setup costs, you make access to the technology more frictionless and the usage goes up," said Jewell.
Stage demanding tasks off the desktop
One benefit of a cloud based IDE is that it can off-load much of the processing work in the development lifecycle to the cloud. When working on the desktop, a developer is limited by the amount of RAM, CPU, and network capacity. This forces the company to purchase ever larger machines to have the CPU-performance, RAM and storage for whatever functions a developer might require. Once developers start leveraging cloud networking speeds, browser performance becomes a bigger determinant in programming fluidity. In a public cloud, the enterprise can simply leverage the scalability of the service provider, but may face limits caused by the back and forth communications with public servers.
A private IDE cloud
Some of the newer cloud-based IDEs allow organizations to provision the backend for the developer environment on a private cloud. This can help to safeguard sensitive code and reduce the networking delays that could slow the developer experience. In these cases, the team needs to consider how to get the best performance-to-cost ratio by leveraging a few dedicated servers configured with maximum resources for a team. These computers can be provisioned and shared based on the estimated workload.
Building up the RAM and CPU on dedicated servers also tends to be more cost effective than provisioning the same resources on laptops requiring physically smaller components. In essence, the enterprise can benefit by reusing high-performance compiling servers across developers and a lower cost of provisioning additional RAM, CPUs, and GPUs on these much larger boxes. A few more might be required if these processes are often occurring in parallel during particularly busy release times.
Cloud lock-in is expensive and limits choices.
Dave Cope, CliQr
Some cloud IDE platforms can even help to allocate computationally intensive processes across multiple servers when tasks can be performed in parallel. This means that developers can spend more time coding and less time waiting for a compile job. When these are done locally, it may take 3-5 minutes or more, and the developer can't do any other work since the operation can consume 100% of the CPU during the cycle.
Looking at the IDE user experience
One of the challenges of implementing a cloud-based IDE well lies in reducing the perceptible delay between inputting new lines of code and features like intellisense. Even a few hundred milliseconds of delay can slow development speed, since developers will have to wait a bit before going back to fix an obvious problem, rather than addressing it as they are typing out the line. This type of delay can be caused by the way the IDE caches the user experience logic and also the networking delay across the Internet. If the cloud IDE server is running in another country, there could be over a second of lag, while one running off a server in the same region could be as little as 14 milliseconds. The best option is when the cloud IDE platform can be implemented on a private cloud so that the enterprise can stage the servers just down the hall from developers. In this case, the latency could be as little as a few milliseconds.
In a distributed environment, there are many user experience elements that can be implemented directly in the browser to reduce these delays, which can eliminate latency caused by network delays completely. When some portion of the logic has to run on the server, the networking handshakes can slow things down signficantly.
Build a better workflow
It is also important to look at the cloud-IDE support for integration with the larger workflow, including a code repository like GitHub, a continuous integration server like Jenkins, a hosted issue management tracker like Jira, and a hosted cloud-IDE front end. When these elements can be hosted together it is easier to wire them together for a smoother workflow. This allows an administrator to create new projects that are automatically connected to all of the other systems the developer needs.
However, development managers might cautiously consider cloud IDE environments tied to a single PaaS, argued Dave Cope, executive VP of corporate development at CliQr, a hybrid cloud management service. "Cloud lock-in is expensive and limits choices. The last thing an IT executive wants to do is go to the board of directors to justify the cost of undoing the cloud project they justified to the board 18 months ago."
What's stopping you from adopting a cloud based IDE? Let us know.