We Need a Good Developer Cloud

Last week’s outage on the Amazon Cloud reminded the tech world once again that clouds are not reliable platforms for operations. The cause of the shutdown is believed to have been a power outage in the Virginia hub, which took down several developer clouds, most notably Heroku. In what can be described only as a shift-the-blame-to-the-victim response, Amazon stated that companies who had duplicated services into a separate availability zones were able to keep on going without missing a beat due to this redundancy. I’ve been astonished at the generally tepid reply of tech analysts to Amazon’s position. Let’s not forget that the whole point of having a cloud was so that organizations would not have to buy extra resources that would be needed only for quick spikes of activity.

A much better solution is a cloud provider that does not go down because it provides its own redundancy, rather than foisting that on its customers. Two weeks before the Amazon stumble, Oracle unveiled its new cloud with considerable fanfare. (Last month, Hewlett-Packard did the same thing. Before that ATT. And, of course, before them — in roughly reverse chronological order: Apple, VMware, Microsoft, IBM, Google, Salesforce.com, and Amazon.) Oracle promised several things, including high reliability because, in theory, it owns the whole stack (hardware, OS, virtualization software, network, etc.) The company also promised a deep embrace of developers — including support for Java (naturally), JIRA, Git, and many other tools. These claims strike me as suspicious. Numerous post-announcement inquiries by Dr. Dobb’s for more detail on developer support have gone unanswered, even when directed to the head of corporate PR, who was unable to find someone — anyone — to speak on the record about the developer features. As to the reliability, I am equally doubtful. Certainly owning the whole stack is a likely benefit because the vendor can manage the repair cycle, unlike Heroku’s impotent waiting for Amazon to fix the then-unknown problem.

But Oracle has no history of providing uptime services in a large way to its customers, so there’s no reason to believe that because it sells databases and applications, it knows how to keep a cloud platform running. In this regard, I trust HP and IBM more, as they have long been the companies of choice for outsourcing entire data centers. They know how to keep things going. Likewise, I would tend to trust ATT’s cloud based on its long knowledge of running systems through all forms of adversity.

Even if reliability were assured, the options for developer-specific platforms are limited and, to my view, immature. The most prominent developer options are Google App Engine, Heroku, EngineYard, ActiveState Stackato, Zend, and to a lesser extent, Contegix, and Joyent. (For pureplay VMs, of course, Rackspace is the leader.)

Except for the details, I find it hard to distinguish between the features of all these vendors. Some offer built-in tools. For example, Contegix hosts all the JIRA tools; Heroku lets you mix and match dev tools; as do Engine Yard and Active State. Zend, Google, and Joyent provide development environments that you can work with, but not specific developer tools. They all lack features I want as a developer and none of them has a mature feel.

From a coding front end, the cloud should be as ubiquitously accessible as Dropbox is today. I should be able to get to code in my IDE with a back-end on the cloud from anywhere. (Several start ups — notably eXo and Cloud9 — are working on this and have products in various stages of development.) By the use of plugins, my IDEs should be able to allow me to move from home, to work, to mobile devices and pick up exactly where I left off, down to which files are open and exact cursor location. The cloud, however, will need to capture this information and pass it back to the IDEs.

Once coding, I should be able to preserve my changes in a sandbox that is backed up with every save. And then I should be able to commit to a VCS hosted in the cloud or locally. Naturally, I should be able to kick off a full build at any time, which would either use an existing in-cloud server (such as that provided by Cloudbees), or spin up such a server and do the build there. If the organization I work in does continuous deployment, I should be able to deploy the app and run tests on it.

Debugging is an area where the cloud should be able to provide fantastic support, but which no provider has explored in depth. If I’m running the app in a virtual machine, there should be a wealth of information available to me: Anything going in or out of the VM can be logged. Every instruction that the VM executes is loggable. And I should be able to play the actions backwards at a breakpoint. This is not some pipe dream, I should point out. VMware’s Workstation product has offered these features for several years, but to my knowledge, it’s impossible to find such features on the cloud today.

Deployment is probably the area where the cloud is best suited currently. Scalability is good, but everything else is fairly weak. Most developer-oriented clouds provide primarily Java platforms on Linux. If you want to run .NET, then ActiveState, Engine Yard, and Heroku are all useless to you. If you want to use Mac OS X, you’re truly out of luck.

In sum, there are plenty of ways that development clouds could be greatly enhanced to be true universal development, debugging, build, and deployment platforms. While application cloud platforms look a lot alike — new entrants, such as Oracle, have to struggle to find new things to deliver — developer clouds really lack important features and offer only a subset of what would be really useful.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy